Hello, Thanks for the bug report, Reepca.
Noé, could you take a look? Thanks, Ludo’. Reepca Russelstein <ree...@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. > > 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
