flatpak build-export validates exported icons in a bwrap sandbox that
fails in an unprivileged CI container. The previous workaround stripped
build-dir/export/share/icons entirely, but flatpak exports the host icon
from that tree at install time, so the host menu and the window/alt-tab
icon were left generic on every machine - even ones where validation
would have passed.
Use 'flatpak build-export --disable-sandbox', which runs the same icon
validation in-process (no bwrap/userns) and keeps the icon in the export,
so it reaches the host.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the <owner> stub and stale gitea.pc-heini.de host with the
real git.pc-heini.de/pc-heini URL in the README install snippet and
o3de.flatpakrepo. Retitle the caveats section now that the items are
confirmed rather than pending verification.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- push to main triggers a rebuild of the current version so build changes get
tested; scoped to main so the job's pages/tag pushes can't loop it, and
docs-only paths are ignored to avoid wasteful full rebuilds.
- the decide step treats a push (like a manual force) as build=true even when
the version tag already exists.
- cron still handles new upstream binary releases as before.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Captures the why behind the build: the read-only /app core tension, the
packaging architecture (no flatpak-builder/bwrap, Sdk-not-Platform, OSTree on
pages), the full read-only-/app saga (X11, Python sdist hook, wrapper venv
bootstrap, SNAP/SNAP_BUILD engine path, the unrelocatable user folder, the
icon), the CI flow, and a maintenance/debugging guide for future O3DE releases.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The non-editable install requires SNAP/SNAP_BUILD for engine-path resolution
(now in the wrapper). The engine-level user folder (cache/metrics/UserSettings)
still resolves under read-only /app for the projectless Project Manager; tested
that the SourceProjectUserPath regset is overwritten by O3DE's bootstrap and
does not help. These writes are non-fatal - documenting rather than chasing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With the non-editable o3de install, the package lives in the per-user venv,
so manifest.get_this_engine_path() (which walks up from the package __file__)
resolved into the venv and engine.json wasn't found -> "Failed to get engine
info" / "Failed to initialize". O3DE has a built-in override for this
immutable-install case: when SNAP and SNAP_BUILD are set, get_this_engine_path
returns "$SNAP/$SNAP_BUILD". The wrapper now sets them to the engine root.
Verified by launching with these vars set: the Project Manager opens with no
engine.json errors.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Project Manager GUI does not set up O3DE's Python venv itself; it only
errors ("Missing python venv file .../pyvenv.cfg") when it's absent, which
cascades into "Failed to get engine info" / "Failed to initialize". Nothing
was running get_python.sh on launch.
The wrapper now runs python/get_python.sh when python.sh reports the venv is
missing/stale. get_python.sh downloads Python, creates the venv under the
writable ~/.o3de, and installs the o3de CLI from the prebuilt sdist. It is
idempotent and self-heals a half-built venv (venv creation uses --clear).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Force-rebuilding an already-published version made the final tag push fail
("tag already exists"), turning an otherwise successful run red. Skip
tagging when the tag already exists on the remote.
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>
get_python.sh runs on the host shell and shells out to cmake to fetch the
engine's Python runtime, but the bare ubuntu container had neither cmake
nor python3. Add them (and tar) to the dependency install.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
flatpak-builder sandboxes each build command in bubblewrap, which needs
user namespaces / a privileged job container that Gitea act_runner does
not grant by default (bwrap: Creating new namespace failed).
Replace it with scripts/make-flatpak.sh, which uses flatpak
build-init/build-finish/build-export plus plain-shell extraction and the
get_python.sh bake. None of these use bwrap, so an unprivileged container
works. The flatpak-builder manifest stays as a documented alternative.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The bare ubuntu:24.04 container has no Node.js, so the JS-based
actions/checkout@v4 fails with exit 127. Clone via plain git 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