-
Notifications
You must be signed in to change notification settings - Fork 16
Native openSUSE package does not run appimaged #40
Comments
Looking at https://build.opensuse.org/package/show/home:MargueriteSu/appimagekit it seems like you are not merely re-packaging the prebuilt AppImages, but are really compiling everything from source. Congratulations, great work. If you are doing this, then you might as well want to install the tools natively into the system, i.e., not as an AppImage, and use the openSUSE mechanism for launching a per-user daemon (using systemd?) to start appimaged. That way the user would not have to deal with Packaging Please let me know if the above is not clear, then I will try to explain in more detail. Again, thank you for your great work, well done @marguerite. |
Hi, @probonopd At first I did want to package appimagetool and appimaged directly into the system, but as I know little about the inside information, I don't know which files are actually needed. eg AppRun? And I don't know what appimaged-X86_64.AppImage --install will do. Actually I just finished packaging, didn't research on the details in real life packaging yet. But as you can see, I created two AppImages in my build, which indicates my build works. In my build, I statically compiled openssl, xz and inotify-tools because most of the times such static compiled libraries will not be provided by a distribution, and patched some CFLAGS/LDFLAGS to use them. If you agree, I can tweak the patch to upstream... |
Hi @marguerite. Sorry my response took a bit longer due to Christmas holidays. There are different ways to distribute software (among others): 1. As an AppImage. This is intended for users who do not want or cannot use a package manger, and does not install things to
2. As native distribution packages. For example, a deb or RPM. This usually means installing software to a
Note that no The challenge here is how to get
But how do we enable this for all users in the RPM package's
In any case, the result should be that one 3. As a mixture of both. For example, an AppImage being packaged inside a deb or RPM. I do not recommend it. So @marguerite I would recommend to use 2. for your packages. Please let me know if this explanation is not clear, I will try to do my best to make it as understandable as possible. |
Thanks for the explanation. I'll play with my specfile tonight. will see what we can get. |
and this is just the beginning at archlinux with appimages ... its also one of my favorite linux distris |
@probonopd You said the following: # Enable per-user launchd unit for all users in a way that users can disable it
systemctl --global enable appimaged # I can't seem to get it to work on Ubuntu
# Enable per-user launchd unit for all users # I can't seem to get it to work on Ubuntu
mkdir -p /usr/lib/systemd/user/graphical.target.wants/
( cd /usr/lib/systemd/user/graphical.target.wants/ ; ln -s ../appimaged.service . ) I wrote a workaround to enable the appimaged service for each user on the post install script as found here that may give you an alternative idea on how to accomplish it: I found a segmentation fault issue on the appimaged binary, it seems that it is having issues with recursing on all the directories that it uses to search for appimage files: appimaged -v
Unrecognized file '/opt/firebird/bin/fbguard'
get_thumbnail_path: /home/myuser/.cache/thumbnails/normal/d2a8d51ab6c8b0a9716975d2c7e562bd.png
get_thumbnail_path: /home/myuser/.cache/thumbnails/normal/9f854c9e292d1a7fd3664ae96911865a.png
opendir error
[1] 14923 segmentation fault (core dumped) appimaged -v when running it with valgrind the most important part of the errors is this:
Maybe I should open a new issue for this, let me know. |
so I decided to take a look at the appimaged.c source file and discovered the issue is because opendir is failing on a directory with no read permission and this isn't handled. |
Hi, I am still confused about whether we should package AppRun or not. For the appimaged/appimagetool itself, it is not needed since AppRun is the entry point for AppImage format, we don't need it if we don't distribute appimaged/appimagetool via AppImage format. But, appinagetool is an application that creates AppImage from AppImage Dir. AppImage Dir is not a normal directory, it will be squashfs that needs "boot codes", that is, AppRun. So I think if we want appimagekit to be "out of the box" for the end users, we will need a helper that creates a skeleton AppImage Dir. If we don't distribute AppRun, will appimagetool insert such thing into a normal directory automatically? Apparently not, as I see, there's no such "initialize" feature in appimagetool right now. If we don't distribute AppRun, I think there's no way for the end users to get it from other places because it is built here. If end users have to build appimagetool anyway to get something, our packaging actually fails to achieve the goal. So I am thinking that I should write a bash script to make it happen... and you said AppRun is not needed...so I am confused... |
Hi @marguerite Generating that AppDir (=the ingredients that go into an AppImage) is currently outside the scope of With "AppRun is not needed" I was referring to the fact that in order to run |
Thanks @jgmdev Have you seen something like https://aur.archlinux.org/cgit/aur.git/tree/appimage-git.install?h=appimage-git to be used for other packages as well? Do you think this is the way we are supposed to do enable per-user systemd services in package postinstall/prerm scripts? How are recent GNOME versions packaged, which apparently also use per-user systemd services? |
Thanks, now I clearly know what I should do to modify my specfile |
This issue can be closed now. see https://build.opensuse.org/package/show/devel:tools:building/appimagekit |
@probonopd I have been inspecting the /usr/lib/systemd/user/ directory and I see some services are marked as static and they are of type dbus, which I guess dbus takes care of launching them, but im not sure how this works, would need to research if the dbus scenario applies to appimaged case. |
openSUSE defined some amazing RPM macros for systemd:https://build.opensuse.org/package/view_file/Base:System/systemd-rpm-macros/macros.systemd?expand=1 hope it can help. see systemd_user_post systemd_user_preun |
Thanks @marguerite! What I don't understand is why those macros are using --global in combination with --user. Maybe there is something I'm missing from the systemctl documentation. |
Great progress, thank you, will test very soon @marguerite. |
Using http://download.opensuse.org/repositories/devel:/tools:/building/openSUSE_Factory/x86_64/appimaged-7~git20161206.0720f5f-3.1.x86_64.rpm on openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso, I got errors in YaST regarding an invalid signature but installed nonetheless. Then I logged out of my session and logged in again. I expected that appimaged would be running by now, but it was not.
I can start it manually:
Now, when I download https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage using the browser, it is automatically registered with the system and can be launched via the GNOME Shell. So, |
Now, http://download.opensuse.org/repositories/devel:/tools:/building/openSUSE_Factory/x86_64/appimagetool-7~git20161206.0720f5f-3.1.x86_64.rpm on openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso:
Works! So, The only thing I wonder, the tiny runtime executable that gets injected into each generated AppImage, could we compile this on a very old system and use that? If we don't, then the AppImages generated e.g., on a Tumbleweed system might not run on (much) older systems due to dependencies on recent symbols. (For this reason we compile AppImageKit on CentOS 6.) |
I think openSUSE intends not to start the service automatically...you see I used the official macro...sometimes users install things just for later use, eg I installed mysql but I didn't want it to take my resources until I finished writing my blog service. It should be their choice to enable some daemon or it sounds like spyware. for system default enabled services, there is a central place/package if I remember correctly. there is surely something we can do, we can just 'systemctl --user enable' it in post and stop & disable it in preun. or we just make it included in that central package. about AppRun, I understand your concern. Then it is not good by distributing apprun.c or AppRun because they are all compiled on the developers' systems eg openSUSE TW or Archlinux. The only right thing is to compile it on an outdated system eg rhel4/sles10... |
@marguerite as I understand it, Gnome these days also runs (and enables by default) per-user systemd services, maybe you can find out how it is done there, and use the same for appimaged? Good point about AppRun, too. |
@probonopd can you please tell me which upstream package includes such service? then I can find openSUSE one. Yesterday I tried but didn't find such examples. |
@marguerite I think http://software.opensuse.org/package/gvfs-backends contains some, since it has service files that get installed to However I can't seem to find anything in the postinstall script that activates them:
|
openSUSE installed the user service but did nothing. I think it is not enabled at all. I also checked Debian, it didn't install the user service at all. So from the distribution point of view either they want users to do it, or they didn't find a way of doing it yet :-( |
Could it be that it gets activated on demand using dbus or something like that? |
@marguerite do you see any way the postinstall script could enable the service? So that the user does not have to do it by hand? Then we could close this issue. Thanks! What do you think about the solution proposed by @jgmdev |
Thanks for finding this out. Please do open a separate issue and/or PR. Thanks! |
@probonopd the Arch way is doable, but not perfect. It will enable the service for all local users that have /home/xxx directories, even if he doesn't login at all. I think start/stop the service for LOGUSER is enough, if a user logout will stop all user services (which I don't know). Anyway starting service for an inactive user sounds like redundancy or security risk. And why daemon-reload when appimaged is still running? I think daemon-reload should be the last step for stop. and starting the service doesn't require a reload at all |
If I understand it correctly, "enable" only means that it will launch once the user logs in. If the user does not log in, it doesn't get started. Perhaps I am wrong though. |
Just discovered that this spec file by @adrianschroeter also produces a package for |
Maye related: systemd/systemd#2690 |
To clarify: The intended behavior is that when the user logs in, then
manually. |
JFYI, the official openSUSE distribution place for the package is here now: https://build.opensuse.org/package/show/system:packagemanager/appimaged trying to get it into Factory/Tumbleweed atm. It is based on @marguerite work though. |
Please move to the appimaged repo. |
This currently depends on https://build.opensuse.org/request/show/817517 I tried updating the package nonetheless however you can't just download new source code during the build. Any distribution that takes security serious will forbid it. See AppImage/AppImageKit#1057 for a patch that is also used on https://github.com/nbacquey/custom-nixpkgs/blob/f5063820e75ccb7c0d630a5bc8e2d0cfa500195c/pkgs/tools/package-management/appimagekit/nix.patch There are several bugs in the build system
The build also fails. I don't know how to fix this:
"squashfuse_dlopen.h" is also not found if one removes the nonstd.h reference, so I gave up. My progress is stored at https://build.opensuse.org/package/show/home:Mailaender:branches:system:packagemanager/appimaged |
Thanks for looking into this @Mailaender. Can OBS handle Go projects well? The new (still experimental) code is at https://github.com/probonopd/go-appimage/tree/master/src/appimaged. |
There is support for https://en.opensuse.org/openSUSE:Packaging_Go |
The native openSUSE package by @marguerite currently installs
/usr/bin/appimaged-x86_64.AppImage
andappimagetool-x86_64.AppImage
.To get
appimaged
to work, one has toBy handling installation and/or packaging this a bit differently, this could be made automatic. I will write more about this when I have time to think about this. I need to provide additional information.
The text was updated successfully, but these errors were encountered: