Debian12, won't launch: "undefined symbol: g_assertion_message_cmpint"

[tbone2k-git]

Hello! o)

I'm using Debian12 and was about to try your Bottles app image, but for some reason it won't launch and gives this error. Maybe you or somebody else has an idea what's going wrong? Thank you in advance! o)

Traceback (most recent call last): File "/tmp/.mount_bottlefafpFK/usr/bin/bottles", line 39, in from gi.repository import Gio File "/tmp/.mount_bottlefafpFK/usr/lib/python3.11/site-packages/gi/init.py", line 40, in from . import _gi ImportError: /tmp/.mount_bottlefafpFK/usr/lib/python3.11/site-packages/gi/_gi.cpython-311-x86_64-linux-gnu.so: undefined symbol: g_assertion_message_cmpint

I had a look around for the error "undefined symbol: g_assertion_message_cmpint" and there seem to be some related issues recently, but I can't make out exactly what would fix this. I also read that you relied on an AUR package for this app image, maybe the error is already there somewhere?

I think the appimage experience is the way to go and much preferred over the other "solutions". Thank you for your efforts and pushing appimages in general! o)

[ivan-hc]

I had a look around for the error "undefined symbol: g_assertion_message_cmpint" and there seem to be some related issues recently, but I can't make out exactly what would fix this. I also read that you relied on an AUR package for this app image, maybe the error is already there somewhere?

I'm quite sure that its because this. Sadly the AUR package is the only one available other than the Flatpak's one, so I had no other alternatives to build it as an AppImage.

And right now I can't do much, since the Python version in Arch Linux is changed.

To work, Bottles require python, and being this an AUR package for Arch Linux, the python version available right now is the v12, since one/two months ago it ws the v11, the same as Debian 12. So I can't rebuild the AppImage. If you take a look at the release, it is still the same since March 21.

Since versions of python in Debian Stable and Arch Linux are now different, I can't do much. Sorry.

[ivan-hc]

The ideal solution would be to use a single, possibly old, version of Python that is common with Debian and Arch Linux.

I saw that older versions of Python on the AUR are referred to as python39, python310, python311.

If it were possible to compile Bottles on Arch Linux using Python 3.9 (package "python39") I could base Bottles on oldstable Debian and render the AppImage on even older systems.

However, I don't know how feasible this is.

EDIT: also, consider that Bottles uses "pycurl" to connect the internet and download dependences, and the latter must be compiled on the same version of python and curl in use by the system... and the latter would be different from the one in use on Debian oldstable.

[tbone2k-git]

As someone who is relatively new to the Linux world, it seems quite odd that the OS you install right now, can already be outdated in the moment you finish the installation. o) I had several situations where CLIB or GLIB or whatever was not recent enough to run a specific application on current Debian stable. So this seems like another case of that phenomenon, thanks! o)

Would it be possible somehow to build the appimage on an older version of the AUR bottles-appimage / bottles packages? As far as I can see, it's all git repositories? So checking out an older version and use that might be possible? It's just a guess. I'm not advanced enough to run Arch and compile a bunch of packages on my own. Compiling myself does not work out most of the time. Missing or too old dependencies come up here as well quite often. It's really a pain in the rear. o)

No offense, just learning and trying to understand. Most appimages still work fine on Debian12, so it is still a useful concept. I looked into creating appimages myself, since I miss a lot of smaller tools and generally dislike reinstalling and reconfiguring applications with each new PC build, but I quickly realized, it's not really easy to do. There are multiple approaches, some are outdated and it's kind of hard to even get an overview of what is the current process to follow for most success, sigh! o)

I probably won't install Arch now because of this (which would still require recompiling a lot of python packages, if I look into the AUR package comments). I also won't use any Bottle Flatpak, since this seems to me the same as installing from the Windows App Store - something I never used on Windows either. Nonetheless, I used my Windows installations for about 10 years each without problems like this. I am really not eager to ditch the Debian installs after a handful of months, that's not the point of an OS I guess, hu? o)

It seems the "Bottles" people are very fond of their Flatpak package, there is no way to get it installed differently, that's kinda weird, but ok, no Bottles for me. You can't have everything I guess?!

Thank you for taking the time, really appreciated!

I learned something new. Unfortunately I can't help to resolve this, I would like to, but for now I am limited to file reports on problems, until I get the hang of more Linux concepts and "dev work on Linux" routine.

Have a nice day and thank you again! o)

[ivan-hc]

Debian Stable is a distribution designed for Servers, other derivatives, such as Linux Mint and SparkyLinux, are instead user-oriented. But in any case, they offer system stability by ensuring the use of software tested over and over again, at the expense of innovation. For the innovation, Rolling Release distributions are involved, not only Arch Linux, but derivatives such as Manjaro, EndeavourOS or Garuda, offering you an official or (thanks to the AUR) third-party software park, (almost) always updated to the latest version.

As far as I know, the choice of the Bottles developers to support only their version in Flaptak format is driven by the inefficiency of one format compared to another, on multiple different platforms, which slowed down the development and improvement of the software itself.

You need to understand that there is a difference between developer and packager. The first develops the software, the other distributes it in various formats. My AppImage is based on the AUR package, so my work as a packager depends on the work of another packager.

The complaint is that on the Bottles website they don't provide details on how to compile it from sources, there is only the guide on how to build the Flatpak. This is what moved me to build and invent new ways to assemble AppImage packages. Flatpak is based on "ostree", it has nothing to do with the normal functioning of a program installed via package manager. It relies on the LSB (Linux Standard Base) standard by installing everything in /var (as I do in /opt, with my "AM"), but copies the filesystem structure. It is a subsystem, so to speak, with its /usr, /bin, /etc... and instead of the kernel a runtime is used, like on Android. This is why they are so widely compatible with all distributions (and at the same time are so bloated and take up so much space).

That said, I want to work on creating Bottles in a way that makes it compatible with older distributions as well. I will try to do as much as possible.

[ivan-hc]

I'm trying to re-base the package on Ubuntu Focal + Python PPA (for version 3.12). This is the first draft:

Click here to see the script

``` #!/usr/bin/env bash APP=bottles # CREATE A TEMPORARY DIRECTORY mkdir -p tmp cd tmp function _archimage(){ DEPENDENCES="fvs python-gobject" BASICSTUFF="binutils debugedit gzip" COMPILERS="meson ninja blueprint-compiler" if ! test -f ./appimagetool; then wget -q "$(wget -q https://api.github.com/repos/probonopd/go-appimage/releases -O - | sed 's/"/ /g; s/ /\n/g' | grep -o 'https.*continuous.*tool.*86_64.*mage$')" -O appimagetool chmod a+x appimagetool fi mkdir archlinux-junest cd archlinux-junest # SET APPDIR AS A TEMPORARY $HOME DIRECTORY, THIS WILL DO ALL WORK INTO THE APPDIR HOME="$(dirname "$(readlink -f $0)")" # DOWNLOAD AND INSTALL JUNEST (DON'T TOUCH THIS) git clone https://github.com/fsquillace/junest.git ~/.local/share/junest wget -q --show-progress https://github.com/ivan-hc/junest/releases/download/continuous/junest-x86_64.tar.gz ./.local/share/junest/bin/junest setup -i junest-x86_64.tar.gz rm -f junest-x86_64.tar.gz # ENABLE MULTILIB (optional) echo -e "\n[multilib]\nInclude = /etc/pacman.d/mirrorlist" >> ./.junest/etc/pacman.conf # CUSTOM MIRRORLIST rm -R ./.junest/etc/pacman.d/mirrorlist wget -q https://archlinux.org/mirrorlist/all/ -O - | awk NR==2 RS= | sed 's/#Server/Server/g' >> ./.junest/etc/pacman.d/mirrorlist # ENABLES WORLDWIDE MIRRORS # BYPASS SIGNATURE CHECK LEVEL sed -i 's/#SigLevel/SigLevel/g' ./.junest/etc/pacman.conf sed -i 's/Required DatabaseOptional/Never/g' ./.junest/etc/pacman.conf # UPDATE ARCH LINUX IN JUNEST ./.local/share/junest/bin/junest -- sudo pacman -Syy ./.local/share/junest/bin/junest -- sudo pacman --noconfirm -Syu # INSTALL THE PROGRAM USING YAY ./.local/share/junest/bin/junest -- yay -Syy ./.local/share/junest/bin/junest -- gpg --keyserver keyserver.ubuntu.com --recv-key C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF # UNCOMMENT IF YOU USE THE AUR ./.local/share/junest/bin/junest -- yay --noconfirm -S $(echo "$BASICSTUFF") ./.local/share/junest/bin/junest -- yay --noconfirm -S gnu-free-fonts $(echo "$BASICSTUFF $COMPILERS $DEPENDENCES $APP") echo y | ./.local/share/junest/bin/junest -- yay --answerclean All --answerdiff All --noconfirm -Sa $APP patool ./.local/share/junest/bin/junest -- yay --noconfirm -S python-pathvalidate cd .. } if ! test -d ./archlinux-junest; then _archimage fi # DOWNLOADING THE DEPENDENCIES if test -f ./appimagetool; then echo " appimagetool already exists" 1> /dev/null else echo " Downloading appimagetool..." wget -q https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage -O appimagetool fi if test -f ./pkg2appimage; then echo " pkg2appimage already exists" 1> /dev/null else echo " Downloading pkg2appimage..." wget -q https://raw.githubusercontent.com/ivan-hc/AM-application-manager/main/tools/pkg2appimage fi chmod a+x ./appimagetool ./pkg2appimage rm -f ./recipe.yml PYTHONVERSION=$(ls ./archlinux-junest/.junest/usr/lib/ | sort | grep python | grep -v lib) #LIBCURL=$(wget -q https://packages.debian.org/stable-backports/amd64/libcurl4/download -O - | grep Download | head -1 | grep -o -P '(?<=Selection -- ).*(?=> recipe.yml # DOWNLOAD ALL THE NEEDED PACKAGES AND COMPILE THE APPDIR ./pkg2appimage ./recipe.yml # PATCH THE APPDIR WITH YAY PACKAGES tar xf ./archlinux-junest/.cache/yay/bottles/*tar.zst -C ./$APP/$APP.AppDir/ VERSION=$(cat ./$APP/$APP.AppDir/.PKGINFO | grep pkgver | cut -c 10- | sed 's@.*:@@') tar xf ./archlinux-junest/.cache/yay/fvs/*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.cache/yay/patool/*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.cache/yay/python-steamgriddb/*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.cache/yay/vkbasalt-cli/*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.junest/var/cache/pacman/pkg/python-gobject-*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.junest/var/cache/pacman/pkg/python-orjson-*tar.zst -C ./$APP/$APP.AppDir/ tar xf ./archlinux-junest/.junest/var/cache/pacman/pkg/python-pycurl-*tar.zst -C ./$APP/$APP.AppDir/ rsync -av ./archlinux-junest/.junest/usr/share/glib-2.0/* ./$APP/$APP.AppDir/usr/share/glib-2.0/ rsync -av ./archlinux-junest/.junest/usr/lib/$PYTHONVERSION/site-packages/setuptools ./$APP/$APP.AppDir/usr/lib/$PYTHONVERSION/site-packages/ rsync -av ./archlinux-junest/.junest/usr/lib/$PYTHONVERSION/lib-dynload/_socket* ./$APP/$APP.AppDir/usr/lib/$PYTHONVERSION/lib-dynload/ # SYMLINK PYTHON3 cd ./$APP/$APP.AppDir/usr/bin PYTHONBIN=$(ls . | sort | grep "$PYTHONVERSION" | head -1) ln -s ./$PYTHONBIN ./python3 cd - # SYMLINK LIBCURL cd ./$APP/$APP.AppDir/usr/lib/x86_64-linux-gnu LIBCURL=$(ls . | sort | grep "libcurl.so" | head -1) ln -s ./$LIBCURL ./libcurl.so cd - # SYMLINK MAIN DIRECTORIES cd ./$APP/$APP.AppDir ln -s /home ./home ln -s /media ./media ln -s /mnt ./mnt cd - # LIBUNIONPRELOAD wget https://github.com/project-portable/libunionpreload/releases/download/amd64/libunionpreload.so chmod a+x libunionpreload.so mv ./libunionpreload.so ./$APP/$APP.AppDir/ # COMPILE SCHEMAS glib-compile-schemas ./$APP/$APP.AppDir/usr/share/glib-2.0/schemas/ || echo "No ./usr/share/glib-2.0/schemas/" # CUSTOMIZE THE APPRUN rm -R -f ./$APP/$APP.AppDir/AppRun cat >> ./$APP/$APP.AppDir/AppRun << 'EOF' #!/bin/sh HERE="$(dirname "$(readlink -f "${0}")")" export UNION_PRELOAD="${HERE}" export LD_PRELOAD="${HERE}"/libunionpreload.so:"${HERE}"/usr/lib/x86_64-linux-gnu/libcurl.so export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${LD_LIBRARY_PATH}" export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}" export PYTHONPATH="${HERE}"/usr/lib/PYTHONVERSION/site-packages/:"${HERE}"/usr/lib/PYTHONVERSION/lib-dynload/:"${PYTHONPATH}" export PYTHONHOME="${HERE}"/usr/ export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}" export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}" export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}" EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g') case "$1" in '') $HERE/usr/bin/${EXEC};; *) $HERE/usr/bin/bottles-cli "$@";; esac EOF sed -i "s/PYTHONVERSION/$PYTHONVERSION/g" ./$APP/$APP.AppDir/AppRun # MADE THE APPRUN EXECUTABLE chmod a+x ./$APP/$APP.AppDir/AppRun # END OF THE PART RELATED TO THE APPRUN, NOW WE WELL SEE IF EVERYTHING WORKS ---------------------------------------------------------------------- # IMPORT THE LAUNCHER AND THE ICON TO THE APPDIR IF THEY NOT EXIST if test -f ./$APP/$APP.AppDir/*.desktop; then echo "The desktop file exists" else echo "Trying to get the .desktop file" cp ./$APP/$APP.AppDir/usr/share/applications/*$(ls . | grep -i $APP | cut -c -4)*desktop ./$APP/$APP.AppDir/ 2>/dev/null fi ICONNAME=$(cat ./$APP/$APP.AppDir/*desktop | grep "Icon=" | head -1 | cut -c 6-) cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/22x22/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/24x24/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/32x32/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/48x48/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/64x64/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/128x128/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/256x256/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/512x512/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/icons/hicolor/scalable/apps/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null cp ./$APP/$APP.AppDir/usr/share/applications/*$ICONNAME* ./$APP/$APP.AppDir/ 2>/dev/null # DEBLOAT PACKAGE rm -R -f ./$APP/$APP.AppDir/usr/lib/gcc rm -R -f ./$APP/$APP.AppDir/.* # EXPORT THE APP TO AN APPIMAGE ARCH=x86_64 VERSION=$(./appimagetool -v | grep -o '[[:digit:]]*') ./appimagetool -s ./$APP/$APP.AppDir cd .. mv ./tmp/*.AppImage ./Bottles-"$VERSION"-Type3-x86_64.AppImage chmod a+x *.AppImage ```

its still a work in progress. For now I'm getting the following message with a final error:

Python path configuration:
  PYTHONHOME = '/tmp/.mount_BottleMdClBM/usr/'
  PYTHONPATH = '/tmp/.mount_BottleMdClBM/usr/lib/python3.12/site-packages/:/tmp/.mount_BottleMdClBM/usr/lib/python3.12/lib-dynload/:'
  program name = '/usr/bin/python3'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/tmp/.mount_BottleMdClBM/usr/lib/python3.11'
  sys._base_executable = '/usr/bin/python3'
  sys.base_prefix = '/tmp/.mount_BottleMdClBM/usr/'
  sys.base_exec_prefix = '/tmp/.mount_BottleMdClBM/usr/'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/python3'
  sys.prefix = '/tmp/.mount_BottleMdClBM/usr/'
  sys.exec_prefix = '/tmp/.mount_BottleMdClBM/usr/'
  sys.path = [
    '/tmp/.mount_BottleMdClBM/usr/lib/python3.12/site-packages',
    '/tmp/.mount_BottleMdClBM/usr/lib/python3.12/lib-dynload',
    '/home/ivan/Scrivania',
    '/tmp/.mount_BottleMdClBM/usr/lib/python311.zip',
    '/tmp/.mount_BottleMdClBM/usr/lib/python3.11',
    '/tmp/.mount_BottleMdClBM/usr/lib/python3.11/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007fe0c7379940 (most recent call first):
  <no Python frame>

it seems to be an issue between the recognized python version used in the main repositories of Ubuntu 20.04 "Focal".

Or maybe something has not been changed yet in thwe AUR package, I see that it still shows some lines related to python3.11.

---

EDIT: yes, the old AUR package still relies on the old python3.11 modules, I've done a symlink to the python3.12 directory

# SYMLINK THE PYTHON DIRECTORY
cd ./$APP/$APP.AppDir/usr/lib
ln -s ./$PYTHONVERSION ./python3.11
cd -

and now the mesage is changed

Traceback (most recent call last):
  File "/tmp/.mount_BottleaKDOMD/usr/bin/bottles", line 23, in <module>
    import gettext
  File "/tmp/.mount_BottleaKDOMD/usr/lib/python3.11/gettext.py", line 51, in <module>
    import re
  File "/tmp/.mount_BottleaKDOMD/usr/lib/python3.11/re/__init__.py", line 125, in <module>
    from . import _compiler, _parser
  File "/tmp/.mount_BottleaKDOMD/usr/lib/python3.11/re/_compiler.py", line 18, in <module>
    assert _sre.MAGIC == MAGIC, "SRE module mismatch"
           ^^^^^^^^^^^^^^^^^^^
AssertionError: SRE module mismatch

however, I don't think that this step has much relevance

[tbone2k-git]

"SRE module mismatch" could be related to python interpreter not matching python modules / version? I had a quick online search, I am really not an expert with python, it's virtual environment and things. I recently did some Qt6 and python tests, not sure how many wild attempts at using pip, pip3 and a trillion other commands I needed, until the PySide6 package was eventually to be found by my test application, so I can feel you! o)

I still appreciate you post the result of your experiment! o) I would be happy to help more, at what stage do you encounter this error, is it while creating the appimage with your updated script, which seems to create the recipe or when running the appimage it created?

[ivan-hc]

I still appreciate you post the result of your experiment! o) I would be happy to help more, at what stage do you encounter this error, is it while creating the appimage with your updated script, which seems to create the recipe or when running the appimage it created?

when I run the AppImage.

Right now we are stuck because the AUR package is not updated, it still relies on python3.11 while the Arch Linux version is python3.12. Just read the comments under the package at https://aur.archlinux.org/packages/bottles

[ivan-hc]

Also if I successfully puilt python3.11 from AUR, there ase stil some modules that are instead compiled for python3.12, for example "fvs". It also come from the AUR and its outdated... but while it is compiled, it relies on the system python version officially supported, the v3.12.

There is no way to solve this :disappointed:

[ivan-hc]

even if I were to use "pip", the modules and libraries would be unique to the system they were compiled on... that's why I mix the Debian and Arch ones. It's a portability issue.

[tbone2k-git]

Right now we are stuck because the AUR package is not updated, it still relies on python3.11 while the Arch Linux version is python3.12. Just read the comments under the package at https://aur.archlinux.org/packages/bottles

So, the solution could be to just wait until all the AUR people have updated their things? Sorry for not coming back earlier, I got distracted by a lot of other things not working on this Linux thing! o)

[ivan-hc]

So, the solution could be to just wait until all the AUR people have updated their things?

yes, I've already contacted the developer of Bottles in private on May 9 (16 days ago), and no answer yet

[tbone2k-git]

Maybe he has some dependencies to resolve as well?.. o) Thank you! If he does not respond anytime soon, let me try as well! o)

I tried around with a regular Wine appimage(s) these days with very mixed results. This Wine thing is a complex beast, I did not get behind all the variations out there yet. Wineprefixes, Winetricks, Lutris, Proton, GloriousEggrole and ever changing tricks and parameters to pass, when running Windows binaries. I was hoping Bottles would make things easier, but I don't know yet. o)

[ivan-hc]

Maybe he has some dependencies to resolve as well?.. o)

or they simply don't care about the AUR version, it being "unofficial"

Thank you! If he does not respond anytime soon, let me try as well! o)

thanks to you instead

I tried around with a regular Wine appimage(s) these days with very mixed results. This Wine thing is a complex beast, I did not get behind all the variations out there yet. Wineprefixes, Winetricks, Lutris, Proton, GloriousEggrole and ever changing tricks and parameters to pass, when running Windows binaries. I was hoping Bottles would make things easier, but I don't know yet. o)

For me, version 9.x doesn't work for the games I use, all 32bit (Diablo 2 and FIFA 2004), so I use the appimage of version 8.x... but apart from that, there's no Windows program I need, on GNU/Linux I have everything I need.

[ivan-hc]

I still have had no answer, and none is updating the AUR package... also python311 seems to be broken, so I can't try to use the latest working python version for Arch Linux, I get a python311 - exit status 4 error when the PKGBUILD is running

[ivan-hc]

Hi, I've finally found a workaround to use the last compatible Arch Linux snapshot to build it https://github.com/ivan-hc/Bottles-appimage/commit/2750749625667f50c8ecd8a2df6b9fec646811fc

The problem is that to work, my AppImage needs to see the system libraries. This is the content of the AppRun:

#!/bin/sh
HERE="$(dirname "$(readlink -f "${0}")")"
export UNION_PRELOAD="${HERE}"
export LD_PRELOAD="${HERE}"/libunionpreload.so:"${HERE}"/usr/lib/x86_64-linux-gnu/libcurl.so
export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${LD_LIBRARY_PATH}"
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export PYTHONPATH="${HERE}"/usr/lib/PYTHONVERSION/site-packages/:"${HERE}"/usr/lib/PYTHONVERSION/lib-dynload/:"${PYTHONPATH}"
export PYTHONHOME="${HERE}"/usr/
export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"
export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}"
EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')
case "$1" in
    '') $HERE/usr/bin/${EXEC};;
    *) $HERE/usr/bin/bottles-cli "$@";;
esac

and this is the affected line:

export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${LD_LIBRARY_PATH}"

Without it I am not able to start the Appimage.

On my system (Debian Testing) I've your same message, but if I change it like this:

export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${LD_LIBRARY_PATH}"

the above "should be" the correct way to bundle an AppImage, but I've no luck here, in particular with Python-based programs.

Another problem is library compatibility.

In practice, during construction, the AppImage uses the Debian Stable base and the "Bottles" package compiled by AUR on the Arch Linux (JuNest) container. The result is that this module is not recognized, because Bottles was compiled with a different one, with a different edition of Python, even if at the same version.

What you need to do is compile Bottles from source using the same destination base, be it Debian or Arch Linux, but also Alpine, CentOS... it doesn't matter, as long as it is one.

The choice to mix the libraries is given by the fact that Debian allows compatibility with Nvidia drivers, as it does not depend on a container. On the contrary, my basic packaging method that uses Arch Linux is called "Archimage" which has the only problem with the lack of support for hardware acceleration, which can also work for a writing program or a video/audio player.. . but not for a WINE frontend to play 3D games.

In short, the problem here is just to compile Bottles with the same libraries, and play only those. Furthermore, the AppImage must be completely autonomous, and on this last point I admit, I failed.

If I had a Bottles .deb package, it would have been simpler, using a single compilation method. But bottles only exists as a Flatpak, while the AUR is not officially supported.

Anyone that can convert the PKGBUILD to a shell script and that can manually build Bottles from source would be able to reach this result.

[ivan-hc]

You can both run the script on your PC or download and extract (with the option --appimage-extract) the AppImage and then edit/run the AppRun script to find the correct way to launch Bottles in a complete standalone way

[tbone2k-git]

Hi ivan-hc, interesting! I succesfully used an "export LD_LIBRARY_PATH=.." statement in a wrapping shell script successfully with other AppImages to make them run (set the LD_LIBRARY_PATH env variable before launching the specifc AppImage).

1) So you added "/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:" in the front, do you think it is really necessary to --appimage-extract the AppImage, edit the AppRun and repack the AppImage? Or could setting the LD_LIBRARY_PATH variable, simply before running the AppImage could work here as well? I don't know if the AppImage mechanics always just extend on an existing LD_LIBRARY_PATH, if that is always the case, then setting it externally should work as well? Like this, just before the launch?

export LD_LIBRARY_PATH="/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"

I guess I also have to try some more, but..

2) I'm not sure I understood you correctly. For your LD_LIBRARY_PATH change to work, I also would have to compile the Bottles package on my current system and also create the AppImage, so it contains matching versions. Is this correct? Compiling this seems to be a lot of hassle, especially on Debian stable. I have a lot of issues trying to compile things from the wild, I end up downloading and compiling half the internet and packages to meet version level in all the dependencies. I'm not a long term Linux die hard user and no C/C++ developer, there are a lot of issues and errors popping up when trying to compile, half of them I can't fix, so I often fail when trying to compile things on my own.. o(

Thank you! o)

[ivan-hc]

Its not a priority ro rebuild it again, all you need is just to extract it into a directory and run the "AppRun", the core shell script, and do attempts by playing with environment variables. The AppImage already includes all it needs.

About trying to rebuild it, this is not a common build bethod, this is a mix of two of my projects:

1. the first part acts like this "Archimage" (in the example, Firefox) https://github.com/ivan-hc/ArchImage/assets/88724353/d7ecb9e5-1db7-4d5c-ae6b-374b6c32e87c

2. the second part looks like this "AppImaGen" (in the example, Abiword, built on the fly for "AM" package manager) https://github.com/ivan-hc/AM/assets/88724353/6ae38787-e0e5-4b63-b020-c89c1e975ddd

I can't fit 10 MB fideo on github, so I share it here these two parts.

To build Bottles on my PC takes about 3-4 minutes.

All you need are imagemagick and glib-compile-schemas installed on your system, I think you already have chmod, mv, rsync, wget, sed, mkdir... among your paric commands.

[ivan-hc]

I'll try to share a full video here and on the readme, just in case. It's not difficult.

[ivan-hc]

I've a 70+ MB video, I had to split it in multiple parts, sorry for this

1.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/6f24a769-ef6e-48da-902e-3992dd24d3c4

2.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/e1707ba8-8a29-440d-8bb1-cd01431701f7

3.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/0e33a82b-f657-47b4-8560-b017228af0b6

4.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/306705c0-0d5e-4583-9df3-8440e38b0e1c

5.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/a3a37034-78d3-4504-b274-78d5388f1a03

6.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/9f6b0da5-977b-40bf-a065-858ddcf32929

7.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/65bf1bf9-64a3-43e3-9d35-59c24ee2b850

8.

https://github.com/ivan-hc/Bottles-appimage/assets/88724353/db8b393c-d599-49c4-8595-c18b90edb3fc

[ivan-hc]

Just testing using an alternative AppRun, and disabling LD_LIBRARY_PATH seems to work

#!/bin/sh
HERE="$(dirname "$(readlink -f "${0}")")"
export UNION_PRELOAD="${HERE}"
export LD_PRELOAD="${HERE}"/libunionpreload.so
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export PYTHONPATH="${HERE}"/usr/lib/python3.11/site-packages/:"${HERE}"/usr/lib/python3.11/lib-dynload/:"${PYTHONPATH}"
export PYTHONHOME="${HERE}"/usr/
export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"
export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}"
EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')

# DOWNLOAD THE RUNTIME OF BOTTLES
if ! [ -d $HOME/.local/share/bottles/runtimes ]; then
    mkdir -p $HOME/.local/share/bottles/runtimes
    bottlesruntimedlurl=$(curl -Ls https://api.github.com/repos/bottlesdevs/runtime/releases | sed 's/[()",{} ]/\n/g' | grep -oi "http.*runtime-.*" | cut -d '"' -f 4)
    wget -q $bottlesruntimedlurl -O Bottles-runtime.tar.gz
    tar xf ./Bottles-runtime.tar.gz -C $HOME/.local/share/bottles/runtimes/ 2> /dev/null
    rm -R -f ./Bottles-runtime.tar.gz
fi

case "$1" in
    '') $HERE/usr/bin/${EXEC};;
    *) $HERE/usr/bin/bottles-cli "$@";;
esac

however I've issues in launc an exe file

[ivan-hc]

I keep getting this error

wine: could not open working directory L"unix\\home\\ivan\\Scaricati\\", starting in the Windows directory.

AppRun in use

#!/bin/sh
HERE="$(dirname "$(readlink -f "${0}")")"
export UNION_PRELOAD="${HERE}"
export LD_PRELOAD="${HERE}"/libunionpreload.so
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export PYTHONPATH="${HERE}"/usr/lib/python3.11/site-packages/:"${HERE}"/usr/lib/python3.11/lib-dynload/:"${PYTHONPATH}"
export PYTHONHOME="${HERE}"/usr/
export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"
export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}"

# DOWNLOAD THE RUNTIME OF BOTTLES
if ! [ -d $HOME/.local/share/bottles/runtimes ]; then
    mkdir -p $HOME/.local/share/bottles/runtimes
    bottlesruntimedlurl=$(curl -Ls https://api.github.com/repos/bottlesdevs/runtime/releases | sed 's/[()",{} ]/\n/g' | grep -oi "http.*runtime-.*" | cut -d '"' -f 4)
    wget -q $bottlesruntimedlurl -O Bottles-runtime.tar.gz
    tar xf ./Bottles-runtime.tar.gz -C $HOME/.local/share/bottles/runtimes/ 2> /dev/null
    rm -R -f ./Bottles-runtime.tar.gz
fi

EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')
case "$1" in
    '') $HERE/usr/bin/${EXEC};;
    *) $HERE/usr/bin/bottles-cli "$@";;
esac

[magpie514]

EDIT: Please look into #10

[ivan-hc]

@magpie514 thanks, your search was helpful

Are you able to run programs? I get this when trying to install an external .exe file

[magpie514]

Let me try with MEGAsync, seems to be the smallest pre-cooked package.

[ivan-hc]

I'm testing with supertuxkart for windows (the only exe I know)

[magpie514]

Hmm does not seem to work. I'm not sure if

wine: could not open working directory L"unix\\home\\magpie\\.local\\share\\bottles\\bottles\\test\\", starting in the Windows directory.

is the culprit or not. The symlinks in dosdevices and the paths in winecfg seem fine, Z should be the DOS-style drive to go with, yet it's using "unix" as prefix and that's weird. Let me see if I can set it up to use WINEDEBUG env var.

[ivan-hc]

thanks, I'm not an expert of Bottles or either WINE, and today I've tested also the previous AppImage I uploaded in March, and also it gave me the same error

[tbone2k-git]

The error [wine: could not open working directory L"unix\home\.."] can be related to using NTFS partition or bad / missing path mappings in winecfg or missing permissions or fuse-fs, at least according to these threads I found about it, maybe this is of help?!

https://www.reddit.com/r/winehq/comments/rvp879/wine_could_not_open_working_directory_lunix/ https://www.reddit.com/r/archlinux/comments/moh9kf/wine_not_working/ https://www.reddit.com/r/winehq/comments/lj2ehm/i_tried_to_create_a_wine_prefix_on_an_ntfs/ https://forum.winehq.org/viewtopic.php?t=34719

[ivan-hc]

hi @tbone2k-git , I've just updated the AppImage to fix the issue https://github.com/ivan-hc/Bottles-appimage/issues/10

https://github.com/ivan-hc/Bottles-appimage/releases/tag/continuous

if this solves your title problem, I would at least rename the issue to investigate the causes of WINE's failure

[magpie514]

Yeah seems it refuses to run anything I throw at it. I wonder if it's related to the LD_PRELOAD errors

ERROR: ld.so: object '/home/magpie/Downloads/squashfs-root/libunionpreload.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

But those only seemed to pop out when installing the prefix. Checking the outputs of WINEDEBUG=warn+all I seem to get file not found errors:

00d4:warn:file:NtQueryAttributesFile L"\\??\\C:\\users\\steamuser\\AppData\\Local\\MEGAsync\\MEGAsync.exe" not found (c000003a)
00d4:warn:file:NtCreateFile L"\\??\\C:\\users\\steamuser\\AppData\\Local\\MEGAsync\\" not found (c0000034)
00d4:warn:file:NtCreateFile L"\\??\\C:\\users\\steamuser\\AppData\\Local\\MEGAsync\\MEGAsync.exe" not found (c000003a)
00d4:warn:file:CreateFileW Unable to create file L"C:\\\\users\\steamuser\\AppData\\Local\\MEGAsync\\MEGAsync.exe" (status c000003a)
00d4:fixme:exec:SHELL_execute flags ignored: 0x00000100
00d4:warn:file:NtQueryAttributesFile L"\\??\\C:\\users\\steamuser\\AppData\\Local\\MEGAsync\\MEGAsync.exe" not found (c000003a)

Repeated to infinity. Something is off with the paths, but I can't seem to find any obvious culprit.

[tbone2k-git]

Mhh, unfortunately no. Your upload some minutes ago seems to give the very same error message as in the opening post.

op@debian:/media/op/datx/bin/emu/bottlesv51.11#2$ ./bottles_v51.11.api Setting $HOME to /media/op/datx/bin/emu/bottlesv51.11#2/bottles_v51.11.api.home Setting $XDG_CONFIG_HOME to /media/op/datx/bin/emu/bottlesv51.11#2/bottles_v51.11.api.config Downloading the runtime of Bottles... Traceback (most recent call last): File "/tmp/.mount_bottleNGKano/usr/bin/bottles", line 39, in from gi.repository import Gio File "/tmp/.mount_bottleNGKano/usr/lib/python3.11/site-packages/gi/init.py", line 40, in from . import _gi ImportError: /tmp/.mount_bottleNGKano/usr/lib/python3.11/site-packages/gi/_gi.cpython-311-x86_64-linux-gnu.so: undefined symbol: g_assertion_message_cmpint

I made sure I have package "python3-chardet" installed as mentioned in https://github.com/ivan-hc/Bottles-appimage/issues/10. The python3 on my system is:

python3 --version Python 3.11.2

[ivan-hc]

if I try to start the program from "file explorer" I get this instead

/lib/ld-linux.so.2: could not open

[ivan-hc]

if I disable LD_PRELOAD this is the message

Traceback (most recent call last):
  File "/tmp/.mount_BottleehamcE/usr/bin/bottles", line 41, in <module>
    resource = Gio.Resource.load(gresource_path)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gi.repository.GLib.GError: g-file-error-quark: Failed to open file “/usr/share/bottles/bottles.gresource”: open() failed: No such file or directory (4)

[magpie514]

Hmm, I wonder what would happen if you use the older appImage implementation with the libfuse2 dependency?

[ivan-hc]

@magpie514 I'm trying right now

PS: are you sure that we can keep LD_LIBRARY_PATH like this?

[ivan-hc]

same issue, also with the old Type2 AppImage

[ivan-hc]

I think that this is related to the new soda9/wine9 behaviour with the experimental wow64 implementation

on my side, wine 9 does not work al all with 32bit games.

[ivan-hc]

i'll try with the vanilla runner 8.6

[magpie514]

RE: Wine 9.0's WOW64 implementation: Yeah that was exactly why I was trying to use Bottles (ended up getting a separate installation of wine and launching it with a wrapper, instead). Seems a bug with the rc2 shipped with Ubuntu 24.04 caused issues, it was a pain to fix, was easier to install a separate package that lives in /opt.

RE: LD_LIBRARY_PATH: No, LD_LIBRARY_PATH should be fine. I'm thinking there's some sort of hardcoded path somewhere breaking things though.

@tbone2k-git Seems the only difference is that you are using Python 3.11. I might be off-track though. There's a way to find out though, could you try putting this as "AppRun2" in there and showing what comes out? (AppRun2 is just so we aren't overwriting stuff, the env should be the same).

#!/bin/sh
env python3.11 --version
HERE="$(dirname "$(readlink -f "${0}")")"
export UNION_PRELOAD="${HERE}"
export LD_PRELOAD="${HERE}"/libunionpreload.so:"${HERE}"/usr/lib/x86_64-linux-gnu/libcurl.so
export LD_LIBRARY_PATH=/lib/:/lib64/:/lib/x86_64-linux-gnu/:/usr/lib/:"${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${LD_LIBRARY_PATH}"
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export PYTHONPATH="${HERE}"/usr/lib/python3.11/site-packages/:"${HERE}"/usr/lib/python3.11/lib-dynload/:"${PYTHONPATH}"
export PYTHONHOME="${HERE}"/usr/
export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"
export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}"

EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')

which python3.11
env python3.11 --version

[ivan-hc]

@magpie514

ivan@debian:~/Scrivania$ ./Bottles-51.11-2-Type3-x86_64.AppImage 
Python 3.11.9
/tmp/.mount_BottlePFJAke/usr/bin//python3.11
Python 3.11.2

[ivan-hc]

RE: Wine 9.0's WOW64 implementation: Yeah that was exactly why I was trying to use Bottles

normally if I need to install wine I use this appimage https://github.com/mmtrt/WINE_AppImage

you can install it using my package manager AM, using the command am -i wine and then select the release

I use it near Bottles in my tests normally, but this time I want to test the runners

[tbone2k-git]

@magpie514

Like so?!

op@debian:/media/op/datx/bin/emu/bottlesv51.11#2/squashfs-root$ ./AppRun2 Python 3.11.2 /media/op/datx/bin/emu/bottlesv51.11#2/squashfs-root/usr/bin//python3.11 Python 3.11.2

[magpie514]

@ivan-hc Whoa there's a WINE appImage? Why didn't I even consider that possibility. Interesting, thanks for letting me know.

Hmm, seems the switch to the appimage version of python should succeed. For reference I get

env: ‘python3.11’: No such file or directory
/home/magpie/Downloads/squashfs-root/usr/bin//python3.11
Python 3.11.2

Which is what one should expect. EDIT: huh, thanks tbone2k. How...curious. Same version, but it's indeed using the proper binary. I don't know why it's doing that, but at least it doesn't seem to be using the wrong python install. I don't quite know what to look for.

[ivan-hc]

How...curious. Same version

because are both Debian Stable :laughing:

[magpie514]

Still the second line indicates it's using the right python. I'm at a loss here, it should work.

[ivan-hc]

By talking with the Bottles developer, it seems that all errors with WINE that is unable to write in the $HOME are due to different settings between the Flatpak environment and the normal one.

Him pointed me to this https://github.com/bottlesdevs/Bottles/blob/eb6399eb55cbf57a53291e7d9c21042cea10d48b/bottles/backend/managers/manager.py#L1311

and told me to add FLATPAK_ID=1 trying to disable the Flatpak environment.

I had no success in this, but @magpie514 I see that you know more how Python works in these cases.

Mirko said that we need to set our own environment in the AppImage.

What do you think?

[magpie514]

Hmm, strange, but this problem doesn't seem related to the ability to write, but to properly set up the paths. The code in there seems to be acting on it, but seems it's not quite enough. I tried adding it to AppRun with no distinguishable effect.

Still I'd advise @tbone2k-git to give it a try (export FLATPAK_ID=1 in AppRun) since this particular issue affects them the most (we can at least get the UI running and everything works except running WINE applications itself).

---

On that matter, I was able to "run" Balatro of all things with your appImage, but it was quite interesting, since it launched the LÖVE runtime fine, but then it was unable to find the resources (producing a "no game" screen). All of this points to some error with generating the paths, but I can't quite point out exactly where the issue is because at a glance it seems fine (dosdevices, wincfg, etc seem to point at the right places)

[ivan-hc]

Hi folks, I'm still working on a solution and I think I've found it:

https://github.com/Kron4ek/Conty

This is an amazing Arch Linux container able to install Nvidia drivers on-the-fly, to made apps working out of the box as if they are native.

I started forking this project to bundle only Bottles, and this is what I reached:

https://github.com/ivan-hc/Conty/releases

to test bottles is enough to run the command ./conty.sh bottles

I have still to test a way to reduce sizes, since it is a bundled filesystem itself.

Once ready, it can bundled into an AppImage, and used as an AppImage, with all advantages it takes (at least by using my package manager "AM", for example, to sandbox installed AppImages).

But now its late, I'll start working on this new solution tomorrow.

Stay tuned.

https://github.com/user-attachments/assets/3276a424-5d0d-4554-82cb-218da3d091a6

[ivan-hc]

Just uploaded a script that creates Bottles using my build of Conty

https://github.com/ivan-hc/Bottles-appimage/blob/main/bottles-conty-builder.sh

I need to update it, since I'll dedicate a branch to Bottles in my fork of Conty.

However, I still need to reduce size of the AppImage, and this is related to the size of Conty build, 1,1 GB.

It contains WINE and drivers, and builds missing drivers on the fly, as I've shown in the previous post.

In total, the AppImage (1,1 GB) and the downloaded driver (700 MB) are 1,8 GB... so without including the built of each bottle/wine profile that reaches 3+ GB without apps installed into them, but this is a data you are aware of.

My goal is to reduce Conty, the file is 1,1 GB, and AppImage compression is not enough to sovle this.

Conty is a compressed filesystem itself. No way for now to reduce sizes, even if compressed again in the AppImage.

I think the solution is in one of these scripts:

• https://github.com/ivan-hc/Conty/blob/master/create-arch-bootstrap.sh
• https://github.com/ivan-hc/Conty/blob/master/create-conty.sh

the ones required to build Conty.