Arch Linux User Repository

Version 5.2.3-2 works for me too. Thanks!

@lynix: Excellent! I'm glad I could help. The new release builds and runs just fine. It sounds like the debug flag was disabled by default previously, which would explain why it hadn't had to be disabled explicitly in the package, or was it always enabled by default and your machine-local overrides are for other reasons?

@bossi: Excellent, thanks for your work identifying the issue!

Yes, 'debug' is now default in /etc/makepkg.conf. I've got it disabled on all my machines, which explains why I'm not seeing the issue.

I will push a -2 with '!debug' in the PKGBUILD shortly.

I've tracked down what's stripping the binary still, even though !strip is specified as an option in PKGBUILD and it turns out it still is the strip script (/usr/share/makepkg/tidy/strip.sh), which strips the binary down to debug symbols if only !strip is specified, it seems. Also setting !debug fixes the issue (options=(!strip !debug)).

It looks like pacman has had some work done on its debug option recently (https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/commits/main), maybe that's where a possible regression was introduced since I'm puzzled it assumes the debug option as a default here.

A brief look into what might be going on shows that build() and package() seem to return good results (the .AppImage doesn't get truncated - or whatever's going on). That leads me to believe that something is possibly stripping it (?) in the subsequent actions that makepkg is taking.

==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Copying source files needed for debug symbols...
  -> Compressing man and info pages...
[...]

Not sure how to debug them but, like I said above, the output of package() looks good to me.

P.S.: To clarify, the results of package() look good when run manually. Looking at the pkg folder that makepkg produces, however, show a tampered result of package() - the .AppImage is stripped to ~100KiB; I'm assuming that it must be a result of whatever makepkg is doing to $pkgdir contents post build.

To contribute a sample: Same AppImage error here.

An observation - note the file size:

$ cd ~/.cache/pikaur/pkg/
$ ll
-rw-r--r-- 1 user group 103M Mar 13 10:55 linphone-desktop-appimage-5.2.2-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 user group 100K Apr  1 03:04 linphone-desktop-appimage-5.2.3-1-x86_64.pkg.tar.zst

I can confirm @Flupp's error message. I get the same error message ("This doesn't look like a squashfs image."), linphone does not start. Same with re-install and stable version.

Flupp: I'm sorry, cannot reproduce your issue. Used 'yay' as well to do a fresh build, runs as expected.

Since the update to 5.2.1-3 (from 5.2.0-2), I get the following error. I use yay for installation. Cleanbuilding did not help.

% linphone 
This doesn't look like a squashfs image.

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory
return value 127

@jsimon0: Out of interest: Is another bump of both .PKGBUILD's and .SRCINFO's pkgrel to 3 strictly necessary or would it suffice to only bring PKGBUILD's pkgrel up to 2 to be in sync with .SRCINFO? No client should have 3.2.1-2 installed, so the only (hypothetical) reason I can think of is that a(nother) bump of .SRCINFO would be required if that's what is necessary for the package managers to pull master again (which I'd tend to doubt - I'd guess that AUR repos always get pulled before the build but that's a guess).