.so-files are not installed anymore for xpra-0.7.0 using gentoo-distutils installation

[olifre]

My other problems with 0.7.0 appear to be related to all .so-files from xpra missing which are generated through cython.
As you can see in the attached build-log (from a build on Gentoo using a minimalistic ebuild), cython actually runs and the .so-files are generated, but not installed as in 0.6.0.
For comparison, I also attached a build-log from 0.6.0 from the same system.

[olifre]

Build log of version 0.6.0 (on Gentoo)

[olifre]

Build log of version 0.7.0 (on Gentoo)

[olifre]

I actually had a closer look at the problem now. Gentoo distutils uses this call for installation to a temporary directory:
setup.py build -b build-2.7 install --no-compile --root=/var/tmp/portage/x11-wm/xpra-0.7.0/temp/images/2.7

For xpra 0.6.0, this also installes the .so-files if they have been compiled before using the build-call.
For xpra 0.7.0, this IGNORES the already built .so-files and they are not installed.

You can see this problem in the attached build-logs.

[Antoine Martin]

Hah, ok, this is due to this changeset: r1748

It works fine on other distros (..): we build first, then the install step does not repeat the cython step (already done by build step)

Any ideas?

[Antoine Martin]

Does this patch to setup.py help?

Index: src/setup.py
===================================================================
--- src/setup.py	(revision 1793)
+++ src/setup.py	(working copy)
@@ -131,7 +131,10 @@
                  % (cython_version, ".".join([str(part) for part in min_version])))
 
 def cython_add(extension, min_version=(0, 14, 0)):
-    if "--no-compile" in sys.argv:
+    #gentoo does weird things, calls --no-compile with build *and* install
+    #then expects to find the cython modules!? ie:
+    #python2.7 setup.py build -b build-2.7 install --no-compile --root=/var/tmp/portage/x11-wm/xpra-0.7.0/temp/images/2.7
+    if "--no-compile" in sys.argv and not ("build" in sys.argv and "install" in sys.argv):
         return
     global ext_modules, cmdclass
     cython_version_check(min_version)

[olifre]

It does help perfectly well :).
I just added it to my hacky ebuild to apply it before compilation, and the .so-files are back.
I am also wondering why gentoo calls the setup.py with such funny parameters, this appears to be triggered by the function "distutils_src_install" of the distutils-eclass there... Mystical.
But with the patch, it is fine ;).

Thanks for the very fast response and the quick fix!

[Antoine Martin]

Merged in r1889, I've also put an updated gentoo-only 0.7.0 archive with those patches applied here: ​http://xpra.org/dists/gentoo/xpra-0.7.0-r1.tar.bz2

Unfortunately, I can't figure out how to get the ebuild to apply the patches from the archive - has it really been broken for that long?
Can you share you hacked ebuild?

[olifre]

Thanks for the new archive,
I actually used the ebuild from the portage tree (so xpra is kind of 'in gentoo' already):
​http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/xpra/xpra-0.6.4.ebuild?revision=1.1&view=markup
and modified it to download the .tar.xz-archive and apply patches from a subdirectory in a local overlay. This was done by adding an "epatch ${FILESDIR}/somepatch.patch" in the ebuild, and adding "somepatch.patch" to the subdirectory "files" next to the ebuild.

After seeing your new archive now, I generated a modified ebuild which downloads the gentoo-specific tar.bz2 and builds it without further patching ;).
I will attach that one to this bug. It also contains the additional line
S="${WORKDIR}/${PF}"
over the ebuild from portage, so portage looks into to correct subdirectory including the "-r1".
I can also commit it to the gentoo-bugtracker as a bump request, so it shall be included in the portage tree for easy installation. The ebuild-maintainer on the gentoo-side appears to be Michael "xmw" Weber, who is also wrote the original version of the ebuild I modified.

[olifre]

Modified version of the ebuild from Gentoo Portage for new archive

[Antoine Martin]

merged in r1891 and available here: ​http://xpra.org/dists/gentoo/

Thanks!

[Michael Weber]

Hi, this is xmw from Gentoo.

I put some effort in an ebuild cleanup after the 0.6 to 0.7 changes.
The "fun" part about --no-compile is to disable .pyc creation, the not-compiling of the .so is an mishap. I added am similar patch to my version [1], but this is gone with 0.7.1 I just added to Gentoo.

Are there any discomfort in pointing Gentoo users to the regular (portage repo) ebuild [2]? I don't really see the point in maintaining 2 locations.

Obliviously I just stumbled over this bug after reading diff -ru of the 0.7.1 -> 0.7.2 source tree changes.

I'm open for input and would appreciate being included in such discussions.

Michael

[1]
​http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/xpra/files/xpra-0.7.0-ignore-gentoo-no-compile.patch?revision=1.1&view=markup
[2] ​http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/xpra/

[Antoine Martin]

The only concern about pointing users to another location is that by definition it will lag behind any releases we make, whereas the ebuilds found here will be up to date as soon as the release announcement is made.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/194