GNU bug report logs - #76850
tests/pack.scm failure (AppImage)

Previous Next

Full log

View this message in rfc822 format

From: Noé Lopez <noe <at> xn--no-cja.eu>
To: Ludovic Courtès <ludo <at> gnu.org>, Reepca Russelstein <reepca <at> russelstein.xyz>
Cc: 76850 <at> debbugs.gnu.org
Subject: bug#76850: tests/pack.scm failure (AppImage)
Date: Sun, 06 Apr 2025 00:29:17 +0200

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello,
>
> Thanks for the bug report, Reepca.
>
> Noé, could you take a look?
>
> Thanks,
> Ludo’.
>

Hi Reepca and Ludo,

Thanks for sending this to me Ludo.

This bug report is very well detailed, thank you.

> Reepca Russelstein <reepca <at> russelstein.xyz> skribis:
>
>> Or perhaps it would be more accurate to say that it is nondeterministic.
>> This is because it currently succeeds more or less by accident: the
>> AppRun symlink points to ./gnu/store/...-profile/bin/hello, which points
>> to /gnu/store/...-hello-2.12.1/bin/hello (note: absolute path!).  There
>> shouldn't be any reason for that to exist inside the chroot, except that
>> the daemon's reference scanner has noticed that some of the inputs to
>> the appimage-building derivation *may* have their hashes visible in the
>> built appimage.  I say "may" because the appimage is compressed with
>> squashfs, so it's a matter of luck whether a hash is actually directly
>> visible.  Currently, in the master branch, it happens to be visible, but
>> in my local repository it isn't, and so it fails for me.

So you’re saying that the daemon is scanning through the files to find
references to add?  As we see here that is unreliable, do you know what
is the reasoning for this?

Indeed, there are no reasons for that absolute path to exist, since we
have not yet entered the AppImage’s chroot/usermount.  This is a
weakness in our current AppImage design, the contents are always
designed to be ran with a store in /gnu/store but this is handled only
by the AppImage runtime (without --appimage-extract).
--appimage-extract bypasses this and we then rely on the --relocatable
binaries, but ideally there would be no need for relocatable.

This is where our issue lies: in our tests we use #:relocatable? on the
self-contained-appimage function but the profile we give it has not
been made relocatably.

>>
>> To demonstrate this without relying on the fickle compression, find the
>> store path of the appimage built during the tests/pack.scm "appimage"
>> test case after running "make check TESTS=tests/pack.scm" (the
>> "check-appimage" derivation is printed into tests/pack.log, from there
>> you can find the appimage derivation and its output path), and call it
>> $IMAGE.  Then:
>>
>> $ IMAGE=/gnu/store/2c8m9in2pkgkf8p9qgv17dqz19jfxmmm-hello-appimage.AppImage
>> $ mkdir test-root
>> $ mkdir test-root/proc
>> $ mkdir test-root/tmp
>> $ cp "$IMAGE" test-root/test-image
>> $ unshare --user --mount --map-root-user
>>
>> then, in the subshell spawned by unshare:
>>
>> $ mount --bind /proc test-root/proc
>> $ chroot ./test-root /test-image --appimage-extract-and-run
>>
>> you should see "Failed to run
>> /tmp/appimage_extracted_e331827d4eb2f579cccf6fb79143c261/AppRun: No such
>> file or directory" or something like it.
>>
>> - reepca

I’m sending a patch with the updated tests.  Sorry for the long wait!

Have a nice day,
Noé

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.