The real first-launch installer is python/get_python.sh, not LYPython.cmake.
It does `pip install -e scripts/o3de`, whose egg_info write hits read-only
/app and fails ([Errno 30]). get_python.sh has a built-in immutable-install
hook: if scripts/o3de/dist/o3de-1.0.0.tar.gz exists it installs that
(non-editable) instead. Pre-build that tarball at Flatpak build time
(python3 setup.py sdist) so the runtime CLI lands in the writable ~/.o3de
venv. Verified end-to-end: tarball install -> `import o3de` resolves from
site-packages.
Also patch every LYPython.cmake copy (not just the first) for the separate
project-build CMake-configure path, and add python3/python3-setuptools to CI.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The previous patch matched a development-branch variable that does not
exist in release 2605.0, so the warning fired and the editable install was
not patched. In 2605.0 the -e is hardcoded in the pip command
("pip install -e ${package_folder_path}"); strip the -e there instead.
Also, flatpak build-export validates exported app icons in a bwrap sandbox,
which fails in an unprivileged container. Keep the icon inside the app (for
the running window/taskbar) but remove it from build-dir/export so export
skips validation. Host menu icon stays generic; build needs no privileges.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
On first launch O3DE pip-installs its 'o3de' CLI with 'pip install -e'
(editable), which writes an egg-info next to the source under read-only
/app and fails ([Errno 30] Read-only file system), leaving the venv broken
("unable to install O3DE's built-in Python").
- Patch cmake/LYPython.cmake at build time to force a normal (non-editable)
install, which builds in a temp dir and lands in the writable ~/.o3de venv.
- Drop the build-time get_python "bake": the venv is per-user (keyed to
$HOME), so it can only be created at runtime; baking under a throwaway
build HOME did nothing. Speeds up CI; removes cmake/python3 build deps and
the network build-arg.
- Add a real launcher icon (org.o3de.O3DE.png).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
O3DE's bundled Qt only ships the xcb platform plugin, so it needs X11/
XWayland. Using --socket=fallback-x11 alongside --socket=wayland meant X11
was not shared on Wayland sessions, leaving DISPLAY empty and Qt unable to
connect. Share --socket=x11 unconditionally instead.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Inspecting o3de_2605_0.deb (control.tar md5sums) showed:
- everything installs under /opt/O3DE/<ver>/; no /usr glue, no app icon
- ~270 .so files sit beside the o3de launcher (LD_LIBRARY_PATH is required)
- the package depends on a build toolchain (clang/ninja/cmake/pkg-config)
- no Python runtime is bundled; O3DE fetches it into its install tree on
first use, which is read-only in a Flatpak
Changes:
- run against org.freedesktop.Sdk so the build toolchain is present at runtime
- bake O3DE's Python in at build time via get_python.sh (network build-arg)
- drop the icon auto-grab (it would have installed a random asset SVG)
- document the remaining open risk: runtime writes into the read-only /app
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Repackage the official O3DE Linux .deb as a Flatpak and publish it as a
static OSTree repo on the 'pages' branch for install via flatpak remote.
- org.o3de.O3DE.yaml: flatpak-builder manifest (extracts the .deb into /app)
- o3de-wrapper.sh: launcher that locates the versioned o3de binary at runtime
- desktop + AppStream metadata under the app-id
- scripts/: live version resolver and local build helper
- .gitea/workflows/build-flatpak.yml: daily check -> build -> publish -> tag
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pc-heini