Repository navigation
Conversation
…le and ppc64 3.7.0 reverts the embedded shell of 3.6.0 and ships the same patched dash as a `dash` file inside sharun+helper-libs-<arch>.tar. sharun runs AppRun.sh with it when it sits next to sharun, and falls back to the host shells otherwise. That removes the reason the embedded design could not work under qemu user emulation: the embedded dash was a foreign-arch ELF in a memfd, so binfmt_misc had to run it and the kernel refuses to hand a close-on-exec fd to an interpreter. All six per-arch tarballs and checksums are updated. _get_sharun now extracts both sharun and dash into the AppDir root, and _add_helper_libs removes dash from the preload dir along with sharun, so it does not end up in lib/sharun-preload where nothing looks for it. A new build-additional-cpu-arches matrix builds the gtk3, gtk4, sdl and vkcube+glxgears demos for riscv64, loongarch64, ppc64le and ppc64 through qemu user emulation, and runs them: with the shipped dash they start, which they could not do before. The binfmt handlers are registered before the container starts, with the script of anylinux-setup-action, because docker/setup-qemu-action ships no ppc64 (BE) handler. The release job now also waits for that matrix, using the same !cancelled() guard as the template so a disabled matrix does not block a release. There are no vulkan drivers on those arches, neither in the distro repos nor in archlinux-pkgs-debloated, so the vkcube demo makes glxgears its main binary there and skips the vulkan-swrast install that only matters when vkcube is what gets launched. The sdl demo uses sdl2-compat on riscv64 and loongarch64, where the sdl2 package is gone and sdl2-compat provides it.
sharun 3.7.0 ships the patched dash inside sharun+helper-libs-<arch>.tar instead of embedding it, and runs AppRun.sh with <sharun dir>/dash when that file is executable. quick-sharun only extracted sharun, so the dash never reached the AppDir and the shell was silently looked up on the host again. _get_sharun now extracts both into the AppDir root and chmods them, so the AppImage keeps working on systems with no /bin/sh. dash is extracted separately from sharun: it is not in tarballs older than 3.7.0, and asking tar for a member that is not there fails the whole extraction. The early return also checks dash now. With only sharun present it used to skip the download entirely, so an AppDir built by an older quick-sharun would never get a dash. _add_helper_libs keeps deleting dash from the preload dir, since it belongs next to sharun and not in lib/sharun-preload.
pacman resolves the sdl2 package name to sdl2-compat on riscv64 and loongarch64, since sdl2-compat provides sdl2, so the explicit case was not needed. ppc64le, loongarch64 and riscv64 do have vulkan drivers in their repos, we just do not bundle them, so vkcube works there and only BE ppc64 predates vulkan. vulkan-swrast is packaged for powerpc64 too, so it is installed unconditionally again.
Open a PR to anylinux-sharun doing this. |
3.7.1 adds the BSD-3-Clause notice to the tarball as dash-COPYING, so quick-sharun deploys it next to dash in the AppDir root and drops it from the preload dir along with sharun and dash. It is extracted with its own tar call and failure ignored, since tarballs older than 3.7.1 do not have it and asking tar for a missing member fails the whole extraction.
ppc64le, loongarch64 and riscv64 do have vulkan drivers in their repos, we just do not bundle them, so vkcube works there and only BE ppc64 predates vulkan. vulkan-swrast is packaged for powerpc64 as well, so it is installed unconditionally again and only ppc64 changes MAIN_BIN to glxgears. On the four emulated arches the debloated mesa still ships the files that upstream now splits into vulkan-mesa-implicit-layers, which vulkan-swrast depends on, so the transaction dies with a file conflict against its own mesa. Those two paths are passed to --overwrite; x86_64 and aarch64 do not need it and are unaffected.
The BSD-3-Clause notice that ships with dash belongs with the other license files, not in the AppDir root next to the binary, so it goes to APPDIR/share/licenses/dash-COPYING. The directory is only created when the tarball actually has the notice, so tarballs older than 3.7.1 do not leave an empty share/licenses behind.
|
Both fixed, plus two things the changes surfaced.
Two things came out of running it:
Both versions are updated: 3.7.0 → 3.7.1, all six checksums verified against the release's own Verified with a full matrix run on my fork: all five |
Nemo-010
changed the title
|
Superseded by #969, which is rebased on current |
Greetings from Port Edwards. Updates
quick-sharunto sharun 3.7.1 and turns on the emulated arches for four demos.sharun 3.7.1
3.7.0 reverted the embedded shell of 3.6.0 and ships the same patched dash as a
dashfile insidesharun+helper-libs-<arch>.tar. sharun runsAppRun.shwith<sharun dir>/dashwhen it is executable, and falls back to the host shells otherwise. 3.7.1 adds the BSD-3-Clause notice for dash to the tarball asdash-COPYING. All six tarball checksums are updated, and each was checked against the release's own.sha256files.That matters for the second half of this PR: the embedded dash of 3.6.0 was a foreign-arch ELF in a memfd, so under qemu user emulation
binfmt_mischad to run it, and the kernel refuses to hand a close-on-exec fd to an interpreter. Every emulated AppImage died inAppRun.shbefore the app started. With the dash shipped as a plain file next to sharun, that path is gone.quick-sharunnow deploysdash. It only extractedsharun, so without this the dash never reached the AppDir and the shell was silently looked up on the host again, which is the/bin/shdependency the dash exists to remove:_get_sharunextractsdashinto the AppDir root next tosharunand chmods both.dashis extracted separately fromsharun. It is not in tarballs older than 3.7.0, and askingtarfor a member that is not there fails the whole extraction. If it is missing the build warns and continues instead of dying.dashtoo. With onlysharunpresent it used to skip the download entirely, so an AppDir built by an older quick-sharun would never get a dash._add_helper_libskeeps deletingdashfrom the preload dir, since it belongs next to sharun, not inlib/sharun-preload.dash-COPYINGgoes toAPPDIR/share/licenses/, not the AppDir root. The directory is only created when the tarball has the notice, so tarballs older than 3.7.1 do not leave an emptyshare/licensesbehind.Checked each of those against the real 3.7.1 tarball:
sharunanddashland in the AppDir root executable, the notice lands inshare/licenses, a 3.5.1 tarball warns and keeps the workingsharunwithout leaving an empty directory, an AppDir with onlysharungets itsdash, andlib/sharun-preloadends up with only the helper libs.Emulated arches
A new
build-additional-cpu-archesmatrix builds the gtk3, gtk4, sdl and vkcube+glxgears demos for riscv64, loongarch64, ppc64le and ppc64 through qemu user emulation, and runs them. The binfmt handlers are registered before the container starts, with the script ofanylinux-setup-action, becausedocker/setup-qemu-actionships no ppc64 (BE) handler. The release job now waits for that matrix too, using the same!cancelled()guard as the template so a disabled matrix does not block a release.ppc64le,loongarch64andriscv64do have vulkan drivers in their repos, we just do not bundle them, sovkcubeworks there; only BEppc64predates vulkan and makesglxgearsits main binary.vulkan-swrastis installed for the test on every arch, it is packaged forpowerpc64too.On the four emulated arches the debloated mesa still ships the files that upstream now splits into
vulkan-mesa-implicit-layers, whichvulkan-swrastdepends on, so installing it dies with a file conflict against its own mesa. Those two paths are passed to--overwrite; x86_64 and aarch64 do not carry them in the debloated mesa.The sdl demo keeps plain
sdl2:sdl2-compatprovidessdl2on riscv64 and loongarch64, so pacman resolves it.Tested with a full matrix run on my fork: all five
vkcubejobs green, includingppc64withvulkan-swrastinstalled, and the emulated--teststep runs again now that the shell is a real file next to sharun. The remaining failures were a transient mirror reset on loongarch64 andgtk3-demo (ppc64le)exiting with code 0 inside the test window, which it did before these changes too.The notice was added to the tarball by pkgforge-dev/Anylinux-sharun#42, which shipped as 3.7.1.
We aim to provide the software that shapes the world of tomorrow.
Requested by Samueru via errand.
Conversation: https://discord.com/channels/1313385177703256064/1561764843965649021