Build succeeds but AppImage won't run

[kiwih]

Hello,
I have been following the steps as laid out in https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Ubuntu,
i.e.

1. Clone the cura-build-environment repository.
2. Create a build subdirectory in that repository.
3. Open CMake and point its source directory to your cura-build-environment repository and the build directory to the build subdirectory.
4. Configure and generate. Use the GCC make files to compile these.
5. Open a terminal and run make in the build directory. If all goes well, this should build all dependencies.

6. Run make install to install the dependencies.
   

7. Clone the cura-build repository.
8. Create a build subdirectory in that repository.
9. Open CMake and point its source directory to your cura-build repository and the build directory to the build subdirectory.
10. Configure and generate. Use the GCC make files to compile these.
11. Open a terminal and run make in the build directory. If all goes well, this should build Cura's main components.
12. Find your source folders in the -prefix subdirectories of the build directory.

I am not using docker. I have followed those steps as directed on a clean Ubuntu 18.04 installation.

The build succeeds and generates a Ultimaker_Cura-0.0.0.AppImage file.
However, when I run this file, it crashes with the following error:

./Ultimaker_Cura-0.0.0.AppImage 
Traceback (most recent call last):
  File "/home/hammond/Documents/cura-build-dir/cura-build-environment/lib/python3.5/site-packages/cx_Freeze/initscripts/__startup__.py", line 12, in <module>
    __import__(name + "__init__")
  File "/home/hammond/Documents/cura-build-dir/cura-build-environment/lib/python3.5/site-packages/cx_Freeze/initscripts/Console.py", line 21, in <module>
    scriptModule = __import__(moduleName)
  File "/home/hammond/Documents/cura-build-dir/cura-build/build/inst/bin/cura", line 23, in <module>
    import Arcus  # @UnusedImport
ImportError: No module named 'sip'

I have checked in the build environment folder and there is a compiled sip file at /cura-build-environment/bin/sip, so it seems like sip is being built, but perhaps it isn't being included in the final binary?

Does anyone have any pointers to where something might be going wrong? I've tried rebuilding from clean a couple of times, but still I am having no luck.

[nallath]

What happens if you don't make an appimage? The image is only needed if you want to distribute Cura. For actual development, I would recommend not making the appimage.

[kiwih]

Hmm, I've tried the AppRun executable under the packaging directory and that crashes with the same error

hammond@hammond-FX505DD:~/Documents/cura-build-dir/cura-build/build/package$ ./AppRun 
Traceback (most recent call last):
  File "/home/hammond/Documents/cura-build-dir/cura-build-environment/lib/python3.5/site-packages/cx_Freeze/initscripts/__startup__.py", line 12, in <module>
    __import__(name + "__init__")
  File "/home/hammond/Documents/cura-build-dir/cura-build-environment/lib/python3.5/site-packages/cx_Freeze/initscripts/Console.py", line 21, in <module>
    scriptModule = __import__(moduleName)
  File "/home/hammond/Documents/cura-build-dir/cura-build/build/inst/bin/cura", line 23, in <module>
    import Arcus  # @UnusedImport
ImportError: No module named 'sip'

And I've tried the cura executable under the /inst/bin directory which crashes with a different but almost the same error

hammond@hammond-FX505DD:~/Documents/cura-build-dir/cura-build/build/inst/bin$ ./cura
Traceback (most recent call last):
  File "./cura", line 23, in <module>
    import Arcus  # @UnusedImport
ModuleNotFoundError: No module named 'Arcus'

(Again, there is an Arcus directory under the build-environment).

[nallath]

Have you also tried just running "python3 cura_app.py"?

That's what I use to run everything. I installed SIP in my python folder and ran the install script in LibArcus. (mkdir build && cd build && cmake .. && make && sudo make install)

[kiwih]

Same error -

Traceback (most recent call last):
  File "cura_app.py", line 23, in <module>
    import Arcus  # @UnusedImport
ModuleNotFoundError: No module named 'Arcus'

Maybe I am misunderstanding something, in the cura-build-environment it downloads and compiles Arcus. I point the cura-build script at the directory containing all of these built modules. Do I also need to install Arcus to my own machine? Can it not use the one it has already downloaded and built?

[nallath]

I don't know why the appimage isn't working for you. But unless you want a distributable package, there isn't a need to build appimages (hence me suggesting also installing libArcus from source).

You could use the one it has already downloaded and built, but it's probably more work to get that right than to just do it again ;)

[kiwih]

I'm not sure I understand - are you using a different build process than the one in cura-build? The cura-build always builds the appimage when I run make

[kiwih]

I have found that I can run the cura_app.py file using the python3.5 executable that cura-build-environment compiles, however that still crashes with a different error:

/home/hammond/Documents/cura-building/cura-build-environment/install/bin/python3.5 cura_app.py 
Traceback (most recent call last):
  File "cura_app.py", line 28, in <module>
    from UM.Platform import Platform
ImportError: No module named 'UM'

[kiwih]

I understand what you're saying now, I can actually just run the Cura repository by following the other steps in https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Ubuntu - I have tried this and it does work, and I've now got Cura running!

I'd still like to know why the build process is failing however

[Ghostkeeper]

We are using cura-build-environment on our build server to create the dependencies of Cura. This includes Sip and Arcus. We're then using cura-build to create the components of Cura itself which change more regularly (such as CuraEngine).

(The only step that's not automated or not public is the signing of the builds; for Linux and MacOS the private key / certificate is not public, and for Windows it's not public and not automated either.)

The No module named 'Arcus' and No module named 'UM' are simply cases where you need to adjust the PYTHONPATH environment variable to include the locations of these Python packages. My PYTHONPATH is this: /home/trin/Gedeeld/Projects/Uranium:/home/trin/inst/lib/python3/dist-packages; Uranium is separate and all of the other Python packages for Cura are installed to ~/inst.

The problem with sip is different though. It happens when the Python code import Arcus is executed, which is extra strange. One thing you could try is to run python3 manually and try import sip. SIP consists of a normal executable which is necessary to create the Arcus.so native Python package, as well as a Python package that needs to be installed on the Python environment in order to import it. Maybe you have the SIP executable but not the Python package? When you try this, be sure to use whichever Python interpreter is found by cura-build though. That may be your system's Python interpreter, but if you ran cura-build-environment to build CPython you may have chosen to use that one instead.

[Yosoy-Ed]

We are using cura-build-environment on our build server to create the dependencies of Cura. This includes Sip and Arcus. We're then using cura-build to create the components of Cura itself which change more regularly (such as CuraEngine).

(The only step that's not automated or not public is the signing of the builds; for Linux and MacOS the private key / certificate is not public, and for Windows it's not public and not automated either.)

The No module named 'Arcus' and No module named 'UM' are simply cases where you need to adjust the PYTHONPATH environment variable to include the locations of these Python packages. My PYTHONPATH is this: /home/trin/Gedeeld/Projects/Uranium:/home/trin/inst/lib/python3/dist-packages; Uranium is separate and all of the other Python packages for Cura are installed to ~/inst.

The problem with sip is different though. It happens when the Python code import Arcus is executed, which is extra strange. One thing you could try is to run python3 manually and try import sip. SIP consists of a normal executable which is necessary to create the Arcus.so native Python package, as well as a Python package that needs to be installed on the Python environment in order to import it. Maybe you have the SIP executable but not the Python package? When you try this, be sure to use whichever Python interpreter is found by cura-build though. That may be your system's Python interpreter, but if you ran cura-build-environment to build CPython you may have chosen to use that one instead.

I am having the same issue of compiling the appimage but it doesnt run. Tried running from source but still no luck.

How is the correct procedure using the docker image?

I use docker pull ultimaker/cura-build-environment and it download latest, inside container I clone cura-build and run the "build_in_docker" script but it says it cant find pyQT5, I do pip3 install but the same issue.

I try clonning cura-build outside docker and run the build scrip, I notice it download the docker image, however it is an old one edited 8 months ago, it compiles, but it doesnt work.

[Ghostkeeper]

The docker image for cura-build-environment is actively maintained since it's what our CI runs on (these tests). It was updated last week to include a tweak for our new libnest2d dependency.

The docker script for cura-build is not though. We have a server running the CMake script from a Jenkins client. We have plans to eventually(tm) transition to a new build server which would run from that docker image, but this project came to a standstill when our DevOps guy left the company and the rest didn't properly understand the system left behind. There was no strong incentive to continue the transition since the old servers are running fine so far, and better understood by the developers. So I can't guarantee that the docker script still works, if it ever did.
We do try to get it into a better state eventually. One of our test engineers has been trying to repair it recently. But he also doesn't really get the time for it. I'm a bit afraid that it'll rest until the Cura team gets a real DevOps engineer.

I would expect that you'd get decent results by opening up the cura-build-environment Docker image, going in a shell there and then try to run CMake manually, pointing CMake to all of the dependencies that it doesn't find automatically.

[Yosoy-Ed]

Thanks for the reply, I will try it. Would it be a hassle to offer nightly builds? I am just trying to test the latest changes you make to see if there is any improvement with the Cura issue #8321 about the slowdowns in circular perimeters. I have not tested the nightly provided there as I was trying just to get the newest.

[Ghostkeeper]

We've considered it several times and as far as I know most people here agree that would be useful, especially the programmers.

There are a couple of things that have prevented this so far though:

• People are afraid that buggy versions of Cura would tarnish the name of Ultimaker and Cura. Generally we can assume that people who are smart enough to build Cura will also be smart enough to know it's an unstable version. And not just know that but also to act like it, because people who build Cura are also the type of people who are interested in trying to fix the problems they encounter. So by forcing people to build Cura themselves, it acts like a sort of filter.
• This gets no priority in the planning, as there are no internal stakeholders in Ultimaker asking for it. Most are not really involved with the open source community and so they don't really see the need for it.
• We don't want to support those unstable versions. Of course it's easy to put 3 layers of disclaimers in the user's face when they try to download it and if they ask for support to tell them to use a stable version instead. But inevitably there will be hundreds of support questions where only after a dozen e-mails it's revealed that the problem stems from using a nightly.

Currently we can provide "nightly" builds if we want to, incidentally. We've done this most recently for a bug with the polygon decimation function. This covers the direct need for nightlies for us. However I do think providing nightlies would allow us to find some types of bugs earlier, particularly with the simplification algorithm we had in 4.7.

[Yosoy-Ed]

Well, that makes a lot of sense, I will test the nightly provided there and continue learning how to build from source.