appimage.github.io Create Rice

changed AppRun path to use usr/bin/python3.8. This should fix the namespace error as it wasn't finding PyGObject. First time doing this sort of stuff, sorry about my pitiful efforts.

Jun 17 '23 10:06 Narmis-E

It runs now but I'm not sure why It cant see the window... Other tests I've seen have also failed the test and still proceeded. Is there a way to bypass the screenshotting like others appear to do? (I'm assuming that's what it is for)

Edit: just spotted the GLIBC error...

Jun 17 '23 10:06 Narmis-E

I'll try rebuilding on an Ubuntu VM to your spec which might hopefully alleviate the glibc incompatibility.

Jun 17 '23 22:06 Narmis-E

Ok, spun up an Ubuntu 18.04 VM (Same as test version hopefully).

On my vm:

ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1.5) 2.27

I successfully ran Rice Manager on this ubuntu vm with no issues. Uploaded the Appimage to my releases so here's hoping. I'll make another commit and I really hope this works.

Jun 18 '23 05:06 Narmis-E

Another Failure... Ill keep developing my app and work more on this when I have the time. I am using https://github.com/niess/linuxdeploy-plugin-python which you are a contributor of @probonopd. For context I am building my appimage with this sh script:

#!/bin/bash
export PIP_REQUIREMENTS=PyGObject
./linuxdeploy-plugin-python-x86_64.AppImage --appdir ./rice-manager
ARCH=x86_64 ./linuxdeploy-x86_64.AppImage --appdir rice-manager/ --output appimage --desktop-file rice-manager/rice-manager.desktop --icon-file rice-manager/myapp.png
ARCH=x86_64 ./appimagetool-x86_64.AppImage rice-manager/

It is nobodies job but mine to comb through logs but for reference here is the log for building (after already built, all the python compilation worked)

Apologies for being bad at this stuff :/

Jun 18 '23 06:06 Narmis-E

ImportError: libffi.so.6: cannot open shared object file: No such file or directory

This (and possibly other) libraries need to be bundled inside the AppImage.

Jun 18 '23 08:06 probonopd

Thanks,

I assume you mean by using the -l argument and passing in the path /usr/lib/x86_64-linux-gnu/libffi.so.6 from here

Jun 18 '23 08:06 Narmis-E

...or by using something like patchelf to modify the rpath to get it loaded.

But before you do manual workarounds, maybe check with @niess whether something about the missing library can be done directly in https://github.com/niess/linuxdeploy-plugin-python. That way all users would benefit. Thanks!

Jun 18 '23 09:06 probonopd

Hello,

sorry, I haven't much developed linuxdeploy-plugin-python lately. I actually switched to another strategy, python-appimage, where Python installs are directly relocated from the Manylinux Docker images into an AppImage. This ensures binary compatibility with packages available from PyPI (i.e., following the PSF).

Maybe you could use python-appimage instead, for your project? The AppImages are available under Python AppImage releases. Python is actually located under APPDIR/opt (following the Manylinux Docker images layout). Note that there is also a utility (python-appimage, available from PyPI) for generating simple Python based apps, where all deps would be available as binary wheels from PyPI.

Jun 19 '23 09:06 niess

Hey,

Thanks, I've had a look through the readthedocs and this looks really cool! So I need to start by submitting my app to PyPI first and then going through the build procedure (python-appimage build {my pip package} -p {version} /path/to/recipe/folder)? Thanks for responding.

Jun 19 '23 11:06 Narmis-E

Hey @Narmis-E ,

that would be the way to go indeed with python-appimage.

The point is that building a Python binary wheel or an AppImage using {Python + packages} faces very similar issues. Thus, if you can build a Python binary wheel for your application, then it is "straightforward" to package it as an AppImage.

Now it really depends on your actual application and its dependencies. In particular, note that all dependencies should be available as binary wheels, for this to work. Which does not seem to be your use case.

Indeed, I understand that your application uses PyGObject, which does not ship a binary wheel (only a source distribution according to PyPI). Then, unfortunately, you could not use the python-appimage executable.

But, if that's useful, you could download an existing Python AppImage as a starting base for your own AppImage (see e.g. Advanced installation), etc. At least, you would already have a functional Python runtime.

The problem is that PyGObject likely depends on system libraries that need to be packaged in the AppImage as well. If those are not already packaged in a Python binary wheel, then python-appimage won't help with this.

Jun 19 '23 12:06 niess

@Narmis-E , you might be interested in the Advanced packaging section of the python-appimage documentation, as well.

Jun 19 '23 12:06 niess

Create Rice_Manager