Compiz fails to build ~ looks like finding python ver. doesn't work properly (Archlinux)

[triplesqaurednine]

I can't build compiz on Arch, right now. it looks like you guys have changed around how compiz uses python. i used to just specify in CMakelists.txt to use python2 instead of python (3) ... anyway, it currently doesn't pick up on python, and then fails a few lines later.

(relevant) output;

-- checking for modules 'x11;libxml-2.0;libxslt;protobuf'
-- found x11, version 1.4.99.901
-- found libxml-2.0, version 2.7.8
-- found libxslt, version 1.1.26
-- found protobuf, version 2.4.1
  File "<string>", line 1
    import sys; print str (sys.version_info.major) + '.' + str (sys.version_info.minor)
                        ^
SyntaxError: invalid syntax
CMake Error at compizconfig/compizconfig-python/CMakeLists.txt:24 (string):
  string sub-command REPLACE requires at least four arguments.

-- Adding test test_profile
-- Adding test test_setting
-- Adding test test_plugin
-- Adding test test_backend
  File "<string>", line 1
    import sys; print str (sys.version_info.major) + '.' + str (sys.version_info.minor)
                        ^
SyntaxError: invalid syntax
CMake Error at compizconfig/ccsm/CMakeLists.txt:24 (string):
  string sub-command REPLACE requires at least four arguments.

-- checking for module 'glib-2.0'
-- found glib-2.0, version 2.32.3
-- checking for module 'gconf-2.0'

So being as line 20 fails due to a syntax error, when it is supposed to pass on those arguments to be used in line 24, it obviously fails because nothing is passed.

I think this build error actually cropped up a day or two ago, but i had thought it was a Clang-bug, as i was going to see if compiz would compile with it (ie: i saw Sam's branch - ' the whole thing goes clang). when it failed i didn't investigate, and hadn't tried to compile compiz until today after seeing the latest revisions and decided to upgrade (using GCC, as i normally would).

cheerz

[triplesqaurednine (triplesquarednine)]

Nevermind, you can disregard this.

I just had to change some stuff in my build scripts, compiz is compiling fine now. :)

sorry for the noise

[Sam Spilsbury (smspillaz)]

Does arch use python3 ?

My python-foo isn't great, so I'm not sure if str (whatever) is invalid in 3

[triplesqaurednine (triplesquarednine)]

@ Sam

On Arch, /usr/bin/python is python3 while /usr/bin/python2 is (obviously) python2.

I believe Arch was the first distro to make Python3 the default.

Most PKGBUILDs (which are like ebuilds in Gentoo, ie: build scripts for packages), will use a 'sed' command to replace python with python2.

I ended up changing my own build script, so that the CMakelists.txt for both CCSM and compizconfig-python both will read COMMAND python2 instead of COMMAND python ...

as for it being invalid in python3, that is the impression that i get. but i am no expert ;)

[Daniel van Vugt (vanvugt)]

Python 3 will eventually become default everywhere so we need to sort this out, if anything does need fixing.

[yellowhat (yellowhat46)]

I have the same problem with 0.9.8.0, I am using gentoo ~x86.
Can you post a workaround or a patch?

[yellowhat (yellowhat46)]

Same error with revision 3374

[triplesqaurednine (triplesquarednine)]

@yellowhat

It's not a bug.

I am not sure how Gentoo does python2/3 but in Archlinux /usr/bin/python is python3 ... while /usr/bin/python2 (is obviously python2). Ubuntu has /usr/bin/python as python2 - so this causes confusion.

anyway, it is very easy to fix - you need to change a couple of spots in the sources to read 'python2' instead of just 'python'. Edit these two files, and change 'COMMAND python' to 'COMMAND python2' where they appear (search and replace, in a text editor) should work fine;

~/compiz/compizconfig/ccsm/CMakeLists.txt

~/compiz/compizconfig/compizconfig-python/CMakeLists.txt

then save both files and then try compiling again, it should work for you.

I've heard Ubuntu 12.10 is going to have python3 as the default (as /usr/bin/python - (?) hopefully) so maybe this will eventually be changed upstream when Ubuntu has migrated - but since i don't use Ubuntu, i don't really know for sure.

[yellowhat (yellowhat46)]

OK Thanks for reply.

[triplesqaurednine (triplesquarednine)]

@yellowhat

if you could, please post the results - ie: if everything was successful or not.

cheerz

[simon (sausageandeggs)]

I've just tried this and it then gives this error

CMake Error: File /media/arch/projects/builds/compiz-core-dev/src/compiz-0.9.8.2/compizconfig/compizconfig-python/compizconfig-python2.pc.in does not exist.
CMake Error at compizconfig/compizconfig-python/CMakeLists.txt:36 (configure_file):
  configure_file Problem configuring file

[simon (sausageandeggs)]

Just realised that thats my fault, getting a bit sed happy! Sorry for the noise

[triplesqaurednine (triplesquarednine)]

@Daniel/Sam

Has Ubuntu switched to Python 3 yet? if so, how did the distro do the migration?

I am curious, because it would be nice if the build-system could check to see if /usr/bin/python2 exists, in which case instead of executing COMMAND python ... it could substitute in COMMAND python2 where it is needed so that compiz builds on distros that are using /usr/bin/python as python3 not python2... anyway, i mention this because recently another file in the sources need to be modified in order to succesfully install.

so we are at a total of 3 files in the sources that need to be modified;

/compiz/compizconfig/ccsm/CMakeLists.txt
/compiz/compizconfig/compizconfig-python/CMakeLists.txt
/compiz/compizconfig/cmake/exec_setup_py_with_destdir.cmake

I thought when Ubuntu migrated to python3, they would have done like most of the distros that first adopted python3 - which is to make /usr/bin/python (python3), while for python2 their using /usr/bin/python2..

anyway, some sort of detection of /usr/bin/python2 would be a good thing.

cheerz

[Iven Hsu (ivenvd)]

For those who need a sed:

    find -type f \( -name 'CMakeLists.txt' -or -name '*.cmake' \) -exec sed -e 's/COMMAND python/COMMAND python2/g' -i {} \;
    find compizconfig/ccsm -type f -exec sed -e 's|^#!.*python|#!/usr/bin/env python2|g' -i {} \;

For a patch see the attachment.

Tested in Arch Linux. Should also work for Ubuntu(not tested).

[Iven Hsu (ivenvd)]

I suggest using FindPythonInterp.cmake instead of the raw `python` command in CMakeFiles.txt. So in Arch Linux, we can define `Python_ADDITIONAL_VERSIONS` variable to specify the python version.

It seems Ubuntu already supports `/usr/bin/python2` and `/usr/bin/env python2` for several releases, why not just use them instead of `/usr/bin/env python` in the Python scripts?

[triplesqaurednine (triplesquarednine)]

@Iven

You should probably look at the revisions. The introduction of 'python_ADDITIONAL_VERSIONS' is much never than this bug report - the same goes for Ubuntu migrating to python 3.

[Iven Hsu (ivenvd)]

@triplesquarednine

Sorry for my poor English. Do you mean it's not related with this bug? Aren't we discussing how to make Compiz more compatible with python3-default systems?

As you said in #13, the FindPythonInterp.cmake could detect /usr/bin/python2, especially when we manually specified 'python_ADDITIONAL_VERSIONS' when compiling or packaging, so `COMMAND python` will not be necessary.

[MC Return (mc-return)]

Is this fixed ?

[Iven Hsu (ivenvd)]

@mc-return

Arch users still have to use patches/workarounds to let compiz build system to find python 2.

See: https://aur.archlinux.org/packages/co/compiz-bzr/PKGBUILD

[MC Return (mc-return)]

@ivenvd:
Thanx 4 the info.
I've set importance to "High". Hopefully somebody can take this on soon.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "compiz-python2.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Barry Warsaw (barry)]

Hi. I've landed here because of LP: #1310794. In order to drop Python 2 from the Ubuntu touch image, we need to port all autopilot tests to Python 3. One of the current blockers is unity7, which uses the python-compizconfig package to access the Python level `compizconfig.Context` object.

This is problematic because the compiz Python bindings are provided by a pyrex module, compizconfig.pyx. Pyrex itself is essentially dead upstream, the last release happening in 2011 afaict. It also doesn't support Python 3 afaict. So porting python-compizconfig to Python 3 is going to be a major PITA. I don't even know if it's worth it, if say unity7 is deprecated in 'U'.

Let's say it *is* worth it, there are a few options. The Python bindings could be hand-coded, or we could use ctypes, but in both those cases, the entire module would have to be ported. Are there enough tests so that we know when we're done and have a high quality port?

The other option is to try to port just what's needed for unity7's autopilot tests. That may be just as big a task though, depending on how much of the compizconfig API the tests require.

As for Python 2/3 on Ubuntu, we would like Python 3 to be "the default" in the sense that all system scripts and services written in Python should be Python 3. However, we'll never change /usr/bin/python like Arch did. As inherited from Debian, /usr/bin/python will *always* be Python 2 (unless and until PEP 394 changes that recommendation, but don't hold your breath). /usr/bin/python3 is what you need to use, but as is pointed out, most distros will heed PEP 394 and provide a /usr/bin/python2 symlink too. Ubuntu and Debian do.

Any guidance you can provide on helping us get enough of compizconfig exposed to Python 3 would be very helpful.

[Barry Warsaw (barry)]

Sorry, Pyrex was last released upstream in *2010*

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.13.1+19.04.20190103-0ubuntu1

---------------
compiz (1:0.9.13.1+19.04.20190103-0ubuntu1) disco; urgency=medium

  [ Alberts Muktupāvels ]
  * Port CCSM to Python 3. (LP: #1004592, #1310794)

 -- Dmitry Shachnev <email address hidden> Thu, 03 Jan 2019 18:56:40 +0000