maxjivi05andzooluis 7309e2f63d fix(epic): install the Epic Games Launcher from its Linux .deb ...

Epic no longer serves the Linux AppImage: the installer URL answers 404
errors.com.epicgames.launcher.app_direct_url_not_found (30003), so Install
failed for everyone. Epic now ships EpicGamesLauncher-x86_64.deb
(0.113.0+g2164614).

- The installer downloads the .deb, checks its ar magic and the CDN ETag,
  and droiddeck-epic unpacks its data.tar.* member straight from the
  archive.
- The .deb links WebKitGTK 4.1, JavaScriptCoreGTK 4.1 and GTK 3, which the
  Steam Runtime 4 image does not ship. 32 Debian 13 amd64 packages, pinned
  by SHA-256 and size (60.2 MB download, 201 MB unpacked), are unpacked
  into the launcher's desktop/ folder (shared libraries only) and put on
  its LD_LIBRARY_PATH. Debian 13 matches the runtime's own base, so only
  sonames the runtime lacks are added. Each package falls back to
  snapshot.debian.org when the deb.debian.org pool has moved on.
- WebKit starts its helper processes from its built-in
  /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1 path, so each launch links that
  folder in the runtime to the layer's copy.
- An installed AppImage launcher keeps starting through its AppRun; the
  next update check moves it to the .deb.

Closure checked offline: every ELF in the .deb and the layer resolves with
the runtime's own ld-linux-x86-64.so.2 inside a sandbox holding only the
runtime, the layer and libGLESv2 (0 missing, 0 version or undefined
symbol errors with LD_BIND_NOW).

Based on zooluis's research in #2268.

Co-authored-by: zooluis <150430329+zooluis@users.noreply.github.com>

2026-11-08 10:26:31 -05:00

..

src

fix(epic): install the Epic Games Launcher from its Linux .deb

2026-11-08 10:26:31 -05:00

build.gradle

chore: bump version to 0.7.0 (18) (#2278)

2026-11-08 09:36:10 -05:00