Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2019-01-19 Thread Samuel Thibault
Control: tags -1 + patch - moreinfo

Hello,

anarcat, le sam. 19 janv. 2019 12:42:44 -0500, a ecrit:
> On Thu, Jan 03, 2019 at 10:16:13AM +0100, Samuel Thibault wrote:
> > Oops, this bug was erroneously closed because its mention was remaining
> > in the sphinxbase changelog.
>
> So after reviewing this bug during the montreal BSP, I'm a little
> confused - it shows up in the "sponsor" UDD dashboard because it's
> marked as affecting buster and sid but with a patch.
>
> Yet, I don't see a recent patch that will fix the issue in dh-python.
> I'm not even sure there *is* an issue in dh-python at all anymore...
>
> Could someone summarize the current state of this bug report?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903698#140 , attached
here, contains the proper information and patch.

Basically, the issue is that dh_python3's handling depends on the
order in which the installed files are processed in the for i in
os.listdir(srcdir): loop. When the target of a symlink is processed
before the symlink, the symlink is considered as non-existing,
because exists(fpath1) returns False in that case. Changing that into
lexists(fpath1), which does return True in that case, fixes things, and
I believe that's should just be done.

Samuel
--- Begin Message ---
Control: reassign -1 dh-python
Control: tags -1 + patch

Samuel Thibault, le mar. 16 oct. 2018 22:13:59 +0200, a ecrit:
> Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> > This is driving me crazy :)
> > 
> > I have uploaded the VM images on
> > https://people.debian.org/~sthibault/tmp/fails.img.gz
> > https://people.debian.org/~sthibault/tmp/works.img.gz
> > 
> > Booting one or the other does not matter. What does matter is the
> > disk image used to store the chroot. Each VM image has its own
> > /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> > same), and it does not matter which of the two I copy, if I copy it
> > inside the fails.img disk I'm getting the lintian issue, and if it's
> > inside the works.img disk I'm not getting it (there's a fresh checkout
> > of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> > own main system is in the fails case, thus preventing me from building
> > the package :) tune2fsk does not show any difference between the two
> > filesystem options, just creation time, mount count & such.
> > 
> > Any other idea of what could be different between the two filesystems?
> 
> It could very well be e.g. the resulting inode numbers and such, thus my
> hypothesis at the top of the quotes above. Python people can have a look
> at the fails.img.gz image, where the issue is notably reproducible from
> the chroot in /var/cache/pbuilder/sphinxbase-build , building for
> instance in /tmp/sphinxbase.

I overrided dh_python3 into /bin/false to catch the result just before
running dh_python3, the two build trees are similar except the .pyc
timestamps which are a few seconds apart in the 2.7 and 3.6 trees.

I then tried to pass -v to dh_python3, and got differing results,
as attached.  It seems in the failure case it indeed doesn't do
everything for 3.6: there are 4 lines less which rename the .so to a 36
variant.  I looked deeper in fs.py, and I found that in the succeeding
case, the main loop inside share_files sees _sphinbase.so before
_sphinxbase.so.0.0.0, and thus renames it, and in the failing case, that
loop sees _sphinxbase.so.0.0.0 before _sphinxbase.so.0, and when it
looks at _sphinxbase.so.0, exits() fails, because the target was moved,
and thus the symlink is now broken. I changed that exists() call into
lexists() to allow for broken symlinks, as the attached patch does, and
things got fixed. This seems like a logical thing to do, and possibly
needed in a few other places in fs.py

Samuel
D: dh_python3 dh_python3:161: version: 3.20180927
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-v']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private': 
False, 'verbose': True, 'arch': None, 'package': None, 'no_package': None, 
'compile_all': False, 'vrange': None, 'regexpr': None, 
'accept_upstream_versions': False, 'depends': None, 'depends_section': None, 
'recommends': None, 'recommends_section': None, 'suggests': None, 
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs': 
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite': 
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:166: supported Python versions: 3.6,3.7 (default=3.6)
D: dh_python3 debhelper:100: skipping package libsphinxbase-doc (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase-dev (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package sphinxbase-utils (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase3 (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:1

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2019-01-19 Thread anarcat
user debian-rele...@lists.debian.org
usertag nn + bsp-2019-01-ca-montreal   
tags -1 -patch +moreinfo
thank you

On Thu, Jan 03, 2019 at 10:16:13AM +0100, Samuel Thibault wrote:
> Oops, this bug was erroneously closed because its mention was remaining
> in the sphinxbase changelog.

So after reviewing this bug during the montreal BSP, I'm a little
confused - it shows up in the "sponsor" UDD dashboard because it's
marked as affecting buster and sid but with a patch.

Yet, I don't see a recent patch that will fix the issue in dh-python.
I'm not even sure there *is* an issue in dh-python at all anymore...

Could someone summarize the current state of this bug report?

Thanks!

-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde


signature.asc
Description: PGP signature


Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2019-01-03 Thread Samuel Thibault
Control: reopen -1
Control: affects -1 + sphinxbase

Oops, this bug was erroneously closed because its mention was remaining
in the sphinxbase changelog.



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-11-03 Thread Samuel Thibault
Samuel Thibault, le lun. 29 oct. 2018 01:01:34 +0100, a ecrit:
> I looked deeper in fs.py, and I found that in the succeeding
> case, the main loop inside share_files sees _sphinbase.so before
> _sphinxbase.so.0.0.0, and thus renames it, and in the failing case, that
> loop sees _sphinxbase.so.0.0.0 before _sphinxbase.so.0, and when it
> looks at _sphinxbase.so.0, exits() fails, because the target was moved,
> and thus the symlink is now broken.

Interestingly enough, this is caught by the reproducible build test, as
currently seen on

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/sphinxbase.html

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-28 Thread Samuel Thibault
Control: reassign -1 dh-python
Control: tags -1 + patch

Samuel Thibault, le mar. 16 oct. 2018 22:13:59 +0200, a ecrit:
> Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> > This is driving me crazy :)
> > 
> > I have uploaded the VM images on
> > https://people.debian.org/~sthibault/tmp/fails.img.gz
> > https://people.debian.org/~sthibault/tmp/works.img.gz
> > 
> > Booting one or the other does not matter. What does matter is the
> > disk image used to store the chroot. Each VM image has its own
> > /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> > same), and it does not matter which of the two I copy, if I copy it
> > inside the fails.img disk I'm getting the lintian issue, and if it's
> > inside the works.img disk I'm not getting it (there's a fresh checkout
> > of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> > own main system is in the fails case, thus preventing me from building
> > the package :) tune2fsk does not show any difference between the two
> > filesystem options, just creation time, mount count & such.
> > 
> > Any other idea of what could be different between the two filesystems?
> 
> It could very well be e.g. the resulting inode numbers and such, thus my
> hypothesis at the top of the quotes above. Python people can have a look
> at the fails.img.gz image, where the issue is notably reproducible from
> the chroot in /var/cache/pbuilder/sphinxbase-build , building for
> instance in /tmp/sphinxbase.

I overrided dh_python3 into /bin/false to catch the result just before
running dh_python3, the two build trees are similar except the .pyc
timestamps which are a few seconds apart in the 2.7 and 3.6 trees.

I then tried to pass -v to dh_python3, and got differing results,
as attached.  It seems in the failure case it indeed doesn't do
everything for 3.6: there are 4 lines less which rename the .so to a 36
variant.  I looked deeper in fs.py, and I found that in the succeeding
case, the main loop inside share_files sees _sphinbase.so before
_sphinxbase.so.0.0.0, and thus renames it, and in the failing case, that
loop sees _sphinxbase.so.0.0.0 before _sphinxbase.so.0, and when it
looks at _sphinxbase.so.0, exits() fails, because the target was moved,
and thus the symlink is now broken. I changed that exists() call into
lexists() to allow for broken symlinks, as the attached patch does, and
things got fixed. This seems like a logical thing to do, and possibly
needed in a few other places in fs.py

Samuel
D: dh_python3 dh_python3:161: version: 3.20180927
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-v']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private': 
False, 'verbose': True, 'arch': None, 'package': None, 'no_package': None, 
'compile_all': False, 'vrange': None, 'regexpr': None, 
'accept_upstream_versions': False, 'depends': None, 'depends_section': None, 
'recommends': None, 'recommends_section': None, 'suggests': None, 
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs': 
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite': 
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:166: supported Python versions: 3.6,3.7 (default=3.6)
D: dh_python3 debhelper:100: skipping package libsphinxbase-doc (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase-dev (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package sphinxbase-utils (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase3 (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:107: skipping package: python-sphinxbase
D: dh_python3 debhelper:100: skipping package swig-sphinxbase (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:153: source=sphinxbase, binary 
packages=['python3-sphinxbase']
D: dh_python3 dh_python3:183: processing package python3-sphinxbase...
D: dh_python3 fs:49: moving files from 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages to 
debian/python3-sphinxbase/usr/lib/python3/dist-packages/
I: dh_python3 fs:312: removing symlink: 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
I: dh_python3 fs:314: renaming 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
 to _sphinxbase.so
D: dh_python3 tools:230: invoking: python3.6 -c 'import sysconfig as 
s;print("__SEP__".join(i or "" for i in s.get_config_vars("SOABI", "MULTIARCH", 
"INCLUDEPY", "LIBPL", "LDLIBRARY")))'
I: dh_python3 fs:329: renaming _sphinxbase.so to 
_sphinxbase.cpython-36m-x86_64-linux-gnu.so
D: dh_python3 fs:49: moving files from 
debian/python3-sphinxbase/usr/lib/python3.7/site-packages to 
debian/python3-sphinxbase/usr/lib/python3/dist-packages/
I: dh_python3 fs:312: removing symlink: 
debian/python3-sphinxbase/usr/lib/python3.7/site-packages/sphinxbas

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-16 Thread Samuel Thibault
Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 04:12:08 +0200, a ecrit:
> > I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be
> > that python somehow gets lost between /lib/python* and /usr/lib/python*,
> > and dependending on e.g. inode number or directory order, we could have
> > one way or the other?
> > 
> > Right now I have two VMs with almost the same chroot (differences
> > notably lie in .pyc files), one works, the other doesn't. When I mount
> > the chroot of one on the other, the chroot behavior holds (i.e. the
> > failing chroot keeps failing on the VM which produced a working chroot).
> 
> This is driving me crazy :)
> 
> I have uploaded the VM images on
> https://people.debian.org/~sthibault/tmp/fails.img.gz
> https://people.debian.org/~sthibault/tmp/works.img.gz
> 
> Booting one or the other does not matter. What does matter is the
> disk image used to store the chroot. Each VM image has its own
> /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> same), and it does not matter which of the two I copy, if I copy it
> inside the fails.img disk I'm getting the lintian issue, and if it's
> inside the works.img disk I'm not getting it (there's a fresh checkout
> of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> own main system is in the fails case, thus preventing me from building
> the package :) tune2fsk does not show any difference between the two
> filesystem options, just creation time, mount count & such.
> 
> Any other idea of what could be different between the two filesystems?

It could very well be e.g. the resulting inode numbers and such, thus my
hypothesis at the top of the quotes above. Python people can have a look
at the fails.img.gz image, where the issue is notably reproducible from
the chroot in /var/cache/pbuilder/sphinxbase-build , building for
instance in /tmp/sphinxbase.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-15 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 04:12:08 +0200, a ecrit:
> I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be
> that python somehow gets lost between /lib/python* and /usr/lib/python*,
> and dependending on e.g. inode number or directory order, we could have
> one way or the other?
> 
> Right now I have two VMs with almost the same chroot (differences
> notably lie in .pyc files), one works, the other doesn't. When I mount
> the chroot of one on the other, the chroot behavior holds (i.e. the
> failing chroot keeps failing on the VM which produced a working chroot).

This is driving me crazy :)

I have uploaded the VM images on
https://people.debian.org/~sthibault/tmp/fails.img.gz
https://people.debian.org/~sthibault/tmp/works.img.gz

Booting one or the other does not matter. What does matter is the
disk image used to store the chroot. Each VM image has its own
/var/cache/pbuilder/sphinxbase-build directory (almost exactly the
same), and it does not matter which of the two I copy, if I copy it
inside the fails.img disk I'm getting the lintian issue, and if it's
inside the works.img disk I'm not getting it (there's a fresh checkout
of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
own main system is in the fails case, thus preventing me from building
the package :) tune2fsk does not show any difference between the two
filesystem options, just creation time, mount count & such.

Any other idea of what could be different between the two filesystems?

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 03:27:47 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 03:02:32 +0200, a ecrit:
> > Samuel Thibault, le ven. 12 oct. 2018 00:55:47 +0200, a ecrit:
> > > Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> > > > To be sure, I have installed a VM from scratch with stretch (default
> > > > install, just not the graphical desktop task), created a chroot with
> > > > pbuilder there, and ran in it, and got the issue there too...
> > 
> > (actually I can't reproduce the issue with the stretch VM, I guess I
> > read wrongly previously)
> > 
> > > Doing the same with a VM with buster, I don't get the issue... I'll now
> > > be able to check what differences there can be in the chroots.
> > 
> > I dugged more and more... It seems the issue is... that my box hostname
> > is "function"...
> 
> Mmm, no, I have changed the hostname of my new "function" VM back to
> something else than "function" and I still have the issue there.
> 
> I have checked the chroot's dpkg -l, the environment, / is ext4 with
> relatime in both case, the kernel is the same, I even used -cpu host
> -smp 4 to expose the same CPU. What else?

I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be
that python somehow gets lost between /lib/python* and /usr/lib/python*,
and dependending on e.g. inode number or directory order, we could have
one way or the other?

Right now I have two VMs with almost the same chroot (differences
notably lie in .pyc files), one works, the other doesn't. When I mount
the chroot of one on the other, the chroot behavior holds (i.e. the
failing chroot keeps failing on the VM which produced a working chroot).

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 03:02:32 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 00:55:47 +0200, a ecrit:
> > Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> > > To be sure, I have installed a VM from scratch with stretch (default
> > > install, just not the graphical desktop task), created a chroot with
> > > pbuilder there, and ran in it, and got the issue there too...
> 
> (actually I can't reproduce the issue with the stretch VM, I guess I
> read wrongly previously)
> 
> > Doing the same with a VM with buster, I don't get the issue... I'll now
> > be able to check what differences there can be in the chroots.
> 
> I dugged more and more... It seems the issue is... that my box hostname
> is "function"...

Mmm, no, I have changed the hostname of my new "function" VM back to
something else than "function" and I still have the issue there.

I have checked the chroot's dpkg -l, the environment, / is ext4 with
relatime in both case, the kernel is the same, I even used -cpu host
-smp 4 to expose the same CPU. What else?

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 00:55:47 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> > To be sure, I have installed a VM from scratch with stretch (default
> > install, just not the graphical desktop task), created a chroot with
> > pbuilder there, and ran in it, and got the issue there too...

(actually I can't reproduce the issue with the stretch VM, I guess I
read wrongly previously)

> Doing the same with a VM with buster, I don't get the issue... I'll now
> be able to check what differences there can be in the chroots.

I dugged more and more... It seems the issue is... that my box hostname
is "function"...

I have just installed that new laptop, I knew that that hostname could
pose problem, I didn't think it'd be so soon :)

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> To be sure, I have installed a VM from scratch with stretch (default
> install, just not the graphical desktop task), created a chroot with
> pbuilder there, and ran in it, and got the issue there too...

Doing the same with a VM with buster, I don't get the issue... I'll now
be able to check what differences there can be in the chroots.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> To be sure, I have installed a VM from scratch with stretch (default
> install, just not the graphical desktop task)

Not completely default actually, I installed in french.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Samuel Thibault, le jeu. 11 oct. 2018 19:02:10 +0200, a ecrit:
> Emilio Pozuelo Monfort, le jeu. 11 oct. 2018 18:33:10 +0200, a ecrit:
> > Weird. I just did:
> > 
> > sudo cowbuilder --update
> > debcheckout sphinxbase
> > cd sphinxbase
> > pdebuild
> > 
> > And it was fine. No idea what we're doing differently.
> 
> Ok. I have run it on a chroot on the barriere porter machine, and it was
> fine too. I'll see what is different on my system.

Mmm...

To be sure, I have installed a VM from scratch with stretch (default
install, just not the graphical desktop task), created a chroot with
pbuilder there, and ran in it, and got the issue there too...

Yes, debian/python-sphinxbase.install does contain

debian/tmp/usr/lib/python2*

without usr/lib.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Emilio Pozuelo Monfort, le jeu. 11 oct. 2018 18:33:10 +0200, a ecrit:
> Weird. I just did:
> 
> sudo cowbuilder --update
> debcheckout sphinxbase
> cd sphinxbase
> pdebuild
> 
> And it was fine. No idea what we're doing differently.

Ok. I have run it on a chroot on the barriere porter machine, and it was
fine too. I'll see what is different on my system.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Emilio Pozuelo Monfort
On 11/10/2018 14:03, Samuel Thibault wrote:
> Emilio Pozuelo Monfort, le jeu. 11 oct. 2018 10:08:45 +0200, a ecrit:
>> On 11/10/2018 03:21, Samuel Thibault wrote:
>>> Samuel Thibault, le mer. 10 oct. 2018 18:33:18 +0200, a ecrit:
 Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> debian/tmp/usr/lib/python3* usr/lib
>
> That is causing both the python3.6/ and python3.7/ contents to be moved to
> usr/lib,

 D'oh!

 Thanks for the fix, I have pushed it to our tree.
>>>
>>> Mmm, we still have an issue:
>>>
>>> W: python3-sphinxbase: python-module-in-wrong-location 
>>> usr/lib/python3.6/site-packages/sphinxbase/ 
>>> usr/lib/python3/dist-packages/sphinxbase/
>>> W: python3-sphinxbase: python-module-in-wrong-location 
>>> usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so 
>>> usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so
>>>
>>> These are indeed completely bogus.
>>
>> That's weird. I don't get those lintian warnings (lintian 2.5.108) and I 
>> don't
>> have any files in /usr/lib/python3.6 either. Those are the old warnings that 
>> you
>> get without my debdiff, which my changes should fix. Are you somehow running
>> lintian on the old changes, or did you forget to apply my diff?
> 
> I checked it again, it's all correct. I can use this to reproduce it:
> 
> $ pbuilder create  # clean sid chroot
> $ wget 
> http://ftp.debian.org/debian/pool/main/s/sphinxbase/sphinxbase_0.8+5prealpha+1.orig.tar.gz
> $ debcheckout sphinxbase   # to get latest git
> $ cd sphinxbase
> $ pdebuild --debbuildopts --check-command=lintian -- --extrapackages lintian

Weird. I just did:

sudo cowbuilder --update
debcheckout sphinxbase
cd sphinxbase
pdebuild

And it was fine. No idea what we're doing differently.

Emilio



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-11 Thread Samuel Thibault
Emilio Pozuelo Monfort, le jeu. 11 oct. 2018 10:08:45 +0200, a ecrit:
> On 11/10/2018 03:21, Samuel Thibault wrote:
> > Samuel Thibault, le mer. 10 oct. 2018 18:33:18 +0200, a ecrit:
> >> Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> >>> debian/tmp/usr/lib/python3* usr/lib
> >>>
> >>> That is causing both the python3.6/ and python3.7/ contents to be moved to
> >>> usr/lib,
> >>
> >> D'oh!
> >>
> >> Thanks for the fix, I have pushed it to our tree.
> > 
> > Mmm, we still have an issue:
> > 
> > W: python3-sphinxbase: python-module-in-wrong-location 
> > usr/lib/python3.6/site-packages/sphinxbase/ 
> > usr/lib/python3/dist-packages/sphinxbase/
> > W: python3-sphinxbase: python-module-in-wrong-location 
> > usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so 
> > usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so
> > 
> > These are indeed completely bogus.
> 
> That's weird. I don't get those lintian warnings (lintian 2.5.108) and I don't
> have any files in /usr/lib/python3.6 either. Those are the old warnings that 
> you
> get without my debdiff, which my changes should fix. Are you somehow running
> lintian on the old changes, or did you forget to apply my diff?

I checked it again, it's all correct. I can use this to reproduce it:

$ pbuilder create  # clean sid chroot
$ wget 
http://ftp.debian.org/debian/pool/main/s/sphinxbase/sphinxbase_0.8+5prealpha+1.orig.tar.gz
$ debcheckout sphinxbase   # to get latest git
$ cd sphinxbase
$ pdebuild --debbuildopts --check-command=lintian -- --extrapackages lintian

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-10 Thread Samuel Thibault
Samuel Thibault, le mer. 10 oct. 2018 18:33:18 +0200, a ecrit:
> Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> > debian/tmp/usr/lib/python3* usr/lib
> > 
> > That is causing both the python3.6/ and python3.7/ contents to be moved to
> > usr/lib,
> 
> D'oh!
> 
> Thanks for the fix, I have pushed it to our tree.

Mmm, we still have an issue:

W: python3-sphinxbase: python-module-in-wrong-location 
usr/lib/python3.6/site-packages/sphinxbase/ 
usr/lib/python3/dist-packages/sphinxbase/
W: python3-sphinxbase: python-module-in-wrong-location 
usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so 
usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so

These are indeed completely bogus.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-10 Thread Samuel Thibault
Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> debian/tmp/usr/lib/python3* usr/lib
> 
> That is causing both the python3.6/ and python3.7/ contents to be moved to
> usr/lib,

D'oh!

Thanks for the fix, I have pushed it to our tree.

Samuel



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-10-10 Thread Emilio Pozuelo Monfort
Control: reassign -1 src:sphinxbase

On Tue, 25 Sep 2018 23:55:56 +0200 Andreas Beckmann  wrote:
> Followup-For: Bug #903698
> 
> There is still something broken in python3-sphinxbase:
> 
> The package ships
>   /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
> ans the dangling symlink
>   /usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so -> 
> _sphinxbase.so.0.0.0

It's still broken because this is a packaging bug in sphinxbase.
debian/python3-sphinxbase.install has:

debian/tmp/usr/lib/python3* usr/lib

That is causing both the python3.6/ and python3.7/ contents to be moved to
usr/lib, causing files with the same name (most or all) to be overwritten,
and ending up with this content after the dh_python3 magic:

./usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so -> 
_sphinxbase.so.0.0.0
./usr/lib/python3/dist-packages/sphinxbase/__init__.py
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-37m-i386-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
./usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py

Note how there's only one shared module, because the rename happens at
dh_python3 and before that, both the 3.6 and the 3.7 had the same name and one
overwrote the other. With the attached debdiff, we keep python3.6 and python3.7
as they should be, which allows dh_python3 to do its job, ending up with:

./usr/lib/python3/dist-packages/sphinxbase/__init__.py
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-36m-x86_64-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-37m-x86_64-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py

And this gives the proper dependencies:

Depends: [...], python3 (<< 3.8), python3 (>= 3.6~), python3:any (>= 3.0~)

Cheers,
Emilio
diff -Nru sphinxbase-0.8+5prealpha+1/debian/changelog 
sphinxbase-0.8+5prealpha+1/debian/changelog
--- sphinxbase-0.8+5prealpha+1/debian/changelog 2018-04-28 11:53:25.0 
+0200
+++ sphinxbase-0.8+5prealpha+1/debian/changelog 2018-10-10 12:38:01.0 
+0200
@@ -1,3 +1,10 @@
+sphinxbase (0.8+5prealpha+1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix python3 bindings.
+
+ -- Emilio Pozuelo Monfort   Wed, 10 Oct 2018 12:38:01 +0200
+
 sphinxbase (0.8+5prealpha+1-2) unstable; urgency=medium
 
   * Make testsuite just fail on big-endian archs, which just don't work yet.
diff -Nru sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install 
sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
--- sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
2018-04-28 11:41:31.0 +0200
+++ sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
2018-10-10 12:37:44.0 +0200
@@ -1 +1 @@
-debian/tmp/usr/lib/python3* usr/lib
+debian/tmp/usr/lib/python3*
diff -Nru sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 
sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install
--- sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 2015-09-19 
16:35:52.0 +0200
+++ sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 2018-10-10 
12:37:58.0 +0200
@@ -1 +1 @@
-debian/tmp/usr/lib/python2* usr/lib
+debian/tmp/usr/lib/python2*


Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-09-25 Thread Andreas Beckmann
Followup-For: Bug #903698

There is still something broken in python3-sphinxbase:

The package ships
  /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
ans the dangling symlink
  /usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so -> 
_sphinxbase.so.0.0.0


Andreas



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-08-05 Thread Andreas Beckmann
Followup-For: Bug #903698
Control: tag -1 sid buster

Since this bug seems to require more than one supported python 3.x
version to show up, I'm tagging it sid+buster, because we have only
one python 3.x version in (old)stable.

Please fix the tags if I misunderstood something.


Andreas



Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-07-15 Thread Samuel Thibault
Control: reassign -1 dh-python
Control: affect -1 sphinxbase

AFAIU the issue is in dh_python3 then, thus reassigning for now.

Samuel Thibault, le sam. 14 juil. 2018 22:52:16 +0200, a ecrit:
> Paul Gevers, le ven. 13 juil. 2018 13:46:45 +0200, a ecrit:
> > I think this is caused by the fact that we loop over $pyver in the
> > d/rules file, but apparently that is broken for multiple python3 versions.
> 
> I don't think that's the problem: I tried to pause after the
> dh_install step, and we have this:
> 
> € find debian | grep pyt
> debian/tmp/usr/lib/python2.7
> debian/tmp/usr/lib/python2.7/dist-packages
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
> debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
> debian/tmp/usr/lib/python3.6
> debian/tmp/usr/lib/python3.6/site-packages
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.pyc
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.opt-1.pyc
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.opt-1.pyc
> debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.pyc
> debian/tmp/usr/lib/python3.7
> debian/tmp/usr/lib/python3.7/site-packages
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/sphinxbase.py
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__init__.py
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0.0.0
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.opt-1.pyc
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.opt-1.pyc
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.pyc
> debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.pyc
> debian/python3-sphinxbase.debhelper.log
> debian/python3-sphinxbase.install
> debian/python-sphinxbase
> debian/python-sphinxbase/usr
> debian/python-sphinxbase/usr/lib
> debian/python-sphinxbase/usr/lib/python2.7
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
> debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
> debian/python3-sphinxbase
> debian/python3-sphinxbase/usr
> debian/python3-sphinxbase/usr/lib
> debian/python3-sphinxbase/usr/lib/python3.6
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
> debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sp

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-07-14 Thread Samuel Thibault
Paul Gevers, le ven. 13 juil. 2018 13:46:45 +0200, a ecrit:
> I think this is caused by the fact that we loop over $pyver in the
> d/rules file, but apparently that is broken for multiple python3 versions.

I don't think that's the problem: I tried to pause after the
dh_install step, and we have this:

€ find debian | grep pyt
debian/tmp/usr/lib/python2.7
debian/tmp/usr/lib/python2.7/dist-packages
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
debian/tmp/usr/lib/python3.6
debian/tmp/usr/lib/python3.6/site-packages
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.opt-1.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.opt-1.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.pyc
debian/tmp/usr/lib/python3.7
debian/tmp/usr/lib/python3.7/site-packages
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.opt-1.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.opt-1.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.pyc
debian/python3-sphinxbase.debhelper.log
debian/python3-sphinxbase.install
debian/python-sphinxbase
debian/python-sphinxbase/usr
debian/python-sphinxbase/usr/lib
debian/python-sphinxbase/usr/lib/python2.7
debian/python-sphinxbase/usr/lib/python2.7/dist-packages
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
debian/python3-sphinxbase
debian/python3-sphinxbase/usr
debian/python3-sphinxbase/usr/lib
debian/python3-sphinxbase/usr/lib/python3.6
debian/python3-sphinxbase/usr/lib/python3.6/site-packages
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.pyc
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.opt-1.pyc
debian/python3-sphinxbase/usr

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

2018-07-13 Thread Paul Gevers
Source: sphinxbase
Version: 0.8+5prealpha+1-2
Severity: serious

Hi all,

sphinxbase is currently involved in the python3.7 "transition"¹. I
noticed that sphinxbase was rebuild, but that is was still listed in the
"bad" category. I took a look at the amd64 build log² and spotted the
following some oddities in python3-sphinxbase.

1) it has only has the 3.6 dependencies (hence listed as bad)
2) it only has 3.7 site-packages files
3) _sphinxbase.cpython-37m-x86_64-linux-gnu.so points to a non-exitent
file. The file is in the 3.7 site-packages directory.
4) python3 versions in the build are first 3.7 and then 3.6, they seem
to be using the same build directory.

I think this is caused by the fact that we loop over $pyver in the
d/rules file, but apparently that is broken for multiple python3 versions.

I think the package is probably not working currently hence I file this
bug. (I don't know how to fix it properly yet, maybe Samuel has ideas?).

Paul

¹ https://release.debian.org/transitions/html/python3.7.html
²
https://buildd.debian.org/status/fetch.php?pkg=sphinxbase&arch=amd64&ver=0.8%2B5prealpha%2B1-2%2Bb1&stamp=1530298945&raw=0



signature.asc
Description: OpenPGP digital signature