Bug#903698: sphinxbase: build appears broken for multiple python3 versions
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
