[Issue report] Problem with starting up from command line (Linux)

[openBrain]

Can't reproduce with a 0.19 AppImage (FreeCAD_0.19-24291-Linux-Conda_glibc2.12-x86_64) on an up-to-date Kubuntu 21.04.

[adrianinsaval]

The "get version" instruction (with the "About FreeCAD" menu) won't work if FreeCAD does not start the GUI

Does it not work when you don't try to use the system's python? That freecad info normally also mentions the Desktop Environment (DE) so it might be useful here.
The first issue about xcb might be an actual bug, I don't know, but the python stuff seems unrelated. From were did you try to launch freecad? xterm or similar or a virtual console? what happens if you try to launch with double click? How did you know to use that command to make it work?

[mcgiwer]

Does it not work when you don't try to use the system's python?

no because in the FreeCAD, python's variable 'sys.path' is forcing to search only for python 3.8, either as an folder or a zip file (even if the python is currently distributed in other format's)

The first issue about xcb might be an actual bug, I don't know, but the python stuff seems unrelated.

The XCB bug seem to apply not only FreeCAD, but also other software as well, so I think it need to be reported to the XCB dev team...

From were did you try to launch freecad? xterm or similar or a virtual console?

The terminal thu with it doesn't has a matter because thru any it woulndn't been run, the result would be the same...

I had made two different attempts:

• first: running the AppImage
• second: after extracting the Appimage and "flatten up" the catalog structure (listed at the end of this message)

what happens if you try to launch with double click?

it would not run, but I'm not sure if then a message would even display

How did you know to use that command to make it work?

First, before answering this question, I present the slight changes of the structure of the extred AppImage (only first level):

Code: Select all

[Root dir]
|- [bin]
|- [Ext]
|- [lib]
|- [libexec] (content moved to lib, directory has been replaced with a link)
|- [Macro]
|- [Mod] (content moved to share/Mod, directory replaced with a link)
|- [plugins]
|- [resources]
|- [sbin] (content moved to bin, directory replaced with a link)
|- [share]
|- [ssl]
|- [translations]
|
|- FreeCAD.conf
|- LICENSE
|- run (renamed and changed FreeCAD startup script, content bellow)
|- system.cfg
|- user.cfg

Content of the changed startup script (Note: all patches have been made relative to the root folder):

Code: Select all

#!/bin/bash

## Fix for the XCB issue ##

sudo xhost +si:localuser:$USER
export DISPLAY=:0

## End of the fix ##

# Get the root folder

$root=$(readlink -f $0)

# Create the link to the user home dir

if [ ! -d ${HOME}/.FreeCAD ]; then ln -s ${root} ${HOME}/.FreeCAD; fi

##  TODO: ##
#
# Automatical discovery of the avaliable Python version
#
## End of TODO ##

export PYTHONHOME=.

# Font path

#export FONTCONFIG_PATH=fonts
#export FONTCONFIG_FILE=${FONTCONFIG_PATH}/fonts.conf

#export LD_LIBRARY_PATH=lib

# Qt

# export QT_XKB_CONFIG_ROOT=${LD_LIBRARY_PATH}
# export QT_QPA_PLATFORM_PLUGIN_PATH=plugins
# export QTWEBENGINEPROCESS_PATH=libexec/QtWebEngineProcess


# SSL

export SSL_ROOT=ssl
export SSL_CERT_FILE=${SSL_ROOT}/cacert.pem
export GIT_SSL_CAINFO=${SSL_ROOT}/cacert.pem

# Support for launching other applications from /usr/bin ( https://github.com/FreeCAD/FreeCAD-AppImage/issues/30)

if [ ! -z "$1" ] && [ -e "$HERE/usr/bin/$1" ] ; then
    MAIN="bin/$1" ; shift
else
    MAIN="bin/freecad"
fi

# Reduce the priority of FreeCAD and make it run in background to prevent that
# system becomes not responsive because of FreeCAD

nice -n19 ${MAIN} "$@" &

[mcgiwer]

Does it not work when you don't try to use the system's python?

no because in the FreeCAD, python's variable 'sys.path' is forcing to search only for python 3.8, either as an folder or a zip file (even if the python is currently distributed in other format's)

The first issue about xcb might be an actual bug, I don't know, but the python stuff seems unrelated.

The XCB bug seem to apply not only FreeCAD, but also other software as well, so I think it need to be reported to the XCB dev team...

From were did you try to launch freecad? xterm or similar or a virtual console?

The terminal thu with it doesn't has a matter because thru any it woulndn't been run, the result would be the same...

I had made two different attempts:

• first: running the AppImage
• second: after extracting the Appimage and "flatten up" the catalog structure (listed at the end of this message)

what happens if you try to launch with double click?

it would not run, but I'm not sure if then a message would even display

How did you know to use that command to make it work?

First, before answering this question, I present the slight changes of the structure of the extracted AppImage (only first level):

Code: Select all

[Root dir]
|- [bin]
|- [Ext]
|- [lib]
|- [libexec] (content moved to lib, directory has been replaced with a link)
|- [Macro]
|- [Mod] (content moved to share/Mod, directory replaced with a link)
|- [plugins]
|- [resources]
|- [sbin] (content moved to bin, directory replaced with a link)
|- [share]
|- [ssl]
|- [translations]
|
|- FreeCAD.conf
|- LICENSE
|- run (renamed and changed FreeCAD startup script, content bellow)
|- system.cfg
|- user.cfg

Content of the changed startup script (Note: all patches have been made relative to the root folder):

Code: Select all

#!/bin/bash

## Fix for the XCB issue ##

sudo xhost +si:localuser:$USER
export DISPLAY=:0

## End of the fix ##

# Get the root folder

$root=$(readlink -f $0)

# Create the link to the user home dir

if [ ! -d ${HOME}/.FreeCAD ]; then ln -s ${root} ${HOME}/.FreeCAD; fi

##  TODO: ##
#
# Automatical discovery of the avaliable Python version
#
## End of TODO ##

export PYTHONHOME=.

# Font path

# export FONTCONFIG_PATH=fonts
# export FONTCONFIG_FILE=${FONTCONFIG_PATH}/fonts.conf

# export LD_LIBRARY_PATH=lib

# Qt

# export QT_XKB_CONFIG_ROOT=${LD_LIBRARY_PATH}
# export QT_QPA_PLATFORM_PLUGIN_PATH=plugins
# export QTWEBENGINEPROCESS_PATH=libexec/QtWebEngineProcess


# SSL

export SSL_ROOT=ssl
export SSL_CERT_FILE=${SSL_ROOT}/cacert.pem
export GIT_SSL_CAINFO=${SSL_ROOT}/cacert.pem

# Support for launching other applications from /usr/bin ( https://github.com/FreeCAD/FreeCAD-AppImage/issues/30)

if [ ! -z "$1" ] && [ -e "bin/$1" ] ; then
    MAIN="bin/$1" ; shift
else
    MAIN="bin/freecad"
fi

# Reduce the priority of FreeCAD and make it run in background to prevent that
# system becomes not responsive because of FreeCAD

nice -n19 ${MAIN} "$@" &

[adrianinsaval]

no because in the FreeCAD, python's variable 'sys.path' is forcing to search only for python 3.8, either as an folder or a zip file (even if the python is currently distributed in other format's)

I meant to run the appimage without any modification or env variable besides the xcb fix, the appimage is not meant to be run with a different python.

Unsetting the PYTHONHOME the appimage sets is probably not a good idea, it's there for a reason, if I'm not mistaken it doesn't set the path for the python executable to be used but the path were python would search for other executables. By unsetting it you are probably breaking a ton of stuff. For your python issues if you don't mind you could use the dev version which I believe uses python 3.9.

To take into account next time: bug reporting guidelines ask you to try if you have the same issue in the latest dev version before reporting.

If the xcb issue is a bug in your system then there's no reason to report it as a FreeCAD bug and the python issues you have are not a bug either.

[mcgiwer]

I meant to run the appimage without any modification or env variable besides the xcb fix, the appimage is not meant to be run with a different python.

As I had mentioned earlier, when running the unmodiffied version of FreeCAD, it complains that in the included Python 3.8 some libraries with are needed to run the extensions are older then the version with the extensions are requiring. It's like the extensions were updated (with includes their Python libs requirments), but in the same time making that they won't work because FreeCAD itself is stuck in a Python 3.8 version with old libs.

Unsetting the PYTHONHOME the appimage sets is probably not a good idea, it's there for a reason, if I'm not mistaken it doesn't set the path for the python executable to be used but the path were python would search for other executables. By unsetting it you are probably breaking a ton of stuff. For your python issues if you don't mind you could use the dev version which I believe uses python 3.9.

Either it's set or not it still need a workaround. The best thing were if FreeCAD would self search for the latest version of Python and set the PYTHONHOME variable itself to the propper path of the newest version of it.

To take into account next time: bug reporting guidelines ask you to try if you have the same issue in the latest dev version before reporting.

I had used the latest stable version because on the current system I don't have enough disk space for the dev version and the build enviroment

If the xcb issue is a bug in your system then there's no reason to report it as a FreeCAD bug and the python issues you have are not a bug either.

The XCB bug was mentioned because it does apply to FreeCAD as well, so I had created a workaround for it with would help to solve it. It would be nice if this would be implemented to the FreeCAD, that from the next releases it wouldn't occur.

[adrianinsaval]

As I had mentioned earlier, when running the unmodiffied version of FreeCAD, it complains that in the included Python 3.8 some libraries with are needed to run the extensions are older then the version with the extensions are requiring. It's like the extensions were updated (with includes their Python libs requirments), but in the same time making that they won't work because FreeCAD itself is stuck in a Python 3.8 version with old libs.

My point was that you could run the freecad gui normally in order to provide the full freecad info but chose not to. Can you be more specific about these complaints? maybe we can help you with that rather than your (non) bug report.

Either it's set or not it still need a workaround. The best thing were if FreeCAD would self search for the latest version of Python and set the PYTHONHOME variable itself to the propper path of the newest version of it.

As I said before the purpose of PYTHONHOME is not to point to the used python executable. The appimage will not search for the latest python because that IS NOT it's purpose, is meant to have it's dependencies included and use them. And I don't think this will change any time soon.
Are you running debian testing/unstable? I think you are since python 3.9 is not in stable, if you are you could install freecad from the repos instead of the appimage, seems to be a few revisions behind though but it's not a big deal.

I had used the latest stable version because on the current system I don't have enough disk space for the dev version and the build enviroment

There's precompiled appimages for the dev version too if you want: https://github.com/FreeCAD/FreeCAD-Bund ... kly-builds and it uses python 3.9.

The XCB bug was mentioned because it does apply to FreeCAD as well, so I had created a workaround for it with would help to solve it. It would be nice if this would be implemented to the FreeCAD, that from the next releases it wouldn't occur.

I have not seen anyone else with this issue, do you have any idea of what is causing it? In my opinion it's not a FreeCAD bug since it only happens in your system and you have that problem with other apps, by the way does it only happen with appimages?

[wieszak17]

Could you provide error which you get for XCB before applying 'fix' ?
Do you run terminal as same user as your desktop?
Is terminal run remotely or on text console?