mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-19 17:25:19 +03:00
8246aa5538
Get this thing going..
<!-- greptile_comment -->
<!-- greptile_summary -->
<h2><a
href="https://app.greptile.com/api/retrigger?id=63134761"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/RetriggerDark.svg?v=1"><source
media="(prefers-color-scheme: light)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/Retrigger.svg?v=1"><img
alt="Retrigger"
src="https://greptile-static-assets.s3.amazonaws.com/badges/Retrigger.svg?v=1"
align="right"></picture></a>Confidence Score: 5/5</h2>
The PR appears safe to merge; all previous findings are resolved and the
latest readiness change introduces no established actionable regression.
<h3>Summary</h3>
- Establishes required guest filesystems, runtime directories, device
permissions, and service processes.
- Reports initialization and service deaths over the lifecycle channel.
- Supports launch, restart, and shutdown commands for a resident guest.
- Separates service and workload identities and configures per-launch
runtime environments.
- Removes the currently inactive nescope screenshot option and makes
capture-chain verification fail explicitly when compositor readback is
unavailable.
- Reworks the guest image around `nesinit` as PID 1 without a
distribution service manager.
<h3>Diagram</h3>
```mermaid
sequenceDiagram
participant Host
participant Init as nesinit
participant FS as Guest filesystems
participant Services as Service stack
participant Workload
Init->>Host: Ready(protocol version)
Host->>Init: Boot(mount descriptors)
Init->>FS: Establish and mount shares
Init->>Services: Spawn services in order
Services-->>Init: Required sockets ready
Init->>Host: Initialized(service names)
Host->>Init: Launch(id, exec, on_exit)
Init->>Workload: Spawn with isolated UID/runtime
Init->>Host: Started(id)
Workload-->>Init: Exit status
Init->>Host: WorkloadExited(id, status)
Host->>Init: Launch / Restart / Shutdown
```
<sub>Reviews (4) · Last reviewed commit: ["fix(nesinit): readiness is a
socket
that..."](731d34df9d)</sub>
<!-- /greptile_comment -->
---------
Co-authored-by: DatCaptainHorse <DatCaptainHorse@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
58 lines
2.5 KiB
Bash
Executable File
58 lines
2.5 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Fetches proton-cachyos' source and its bundled runtimes. Container-only.
|
|
#
|
|
# Deliberately its own script, and its own layer: the submodule checkout runs
|
|
# well past ten minutes, and it must not be redone every time a build flag or a
|
|
# missing dependency changes. Keep everything that can fail *fast* in
|
|
# proton-build.sh instead.
|
|
set -euo pipefail
|
|
|
|
: "${PROTON_GIT:?}"
|
|
: "${PROTON_TAG:?}"
|
|
: "${GECKO_VER:?}"
|
|
: "${MONO_VER:?}"
|
|
: "${XALIA_VER:?}"
|
|
|
|
SRC_DIR="/build/proton-cachyos"
|
|
|
|
git clone --branch "${PROTON_TAG}" --depth=1 "${PROTON_GIT}" "${SRC_DIR}"
|
|
cd "${SRC_DIR}"
|
|
# Relative submodule paths resolve against origin, so it has to be the real URL
|
|
# even though we cloned by tag.
|
|
git remote set-url origin "${PROTON_GIT}"
|
|
# No --depth here: submodules are pinned to commits that are often not a branch
|
|
# tip. --filter=tree:0 keeps the download down instead.
|
|
git submodule update --init --filter=tree:0 --recursive
|
|
|
|
# Still needed with wow64: these are PE-side, and a 32-bit Windows program wants
|
|
# the 32-bit gecko and mono regardless of how wine is built.
|
|
mkdir -p contrib
|
|
for url in \
|
|
"https://dl.winehq.org/wine/wine-gecko/${GECKO_VER}/wine-gecko-${GECKO_VER}-x86.tar.xz" \
|
|
"https://dl.winehq.org/wine/wine-gecko/${GECKO_VER}/wine-gecko-${GECKO_VER}-x86_64.tar.xz" \
|
|
"https://github.com/madewokherd/wine-mono/releases/download/wine-mono-${MONO_VER}/wine-mono-${MONO_VER}-x86.tar.xz" \
|
|
"https://github.com/madewokherd/xalia/releases/download/xalia-${XALIA_VER}/xalia-${XALIA_VER}-net48-mono.zip" \
|
|
; do
|
|
curl -fL --retry 3 -o "contrib/$(basename "$url")" "$url"
|
|
done
|
|
|
|
# Proton's cargo rule runs `cargo build --locked --offline`, so every crate has
|
|
# to be in CARGO_HOME before the build starts — including the git dependencies,
|
|
# which is what the "you are in the offline mode" failure is really saying. The
|
|
# error names a URL that is perfectly reachable; the build simply refuses to go
|
|
# out and get it.
|
|
#
|
|
# gst-plugins-rs is the only cargo component in the tree. Both targets are
|
|
# fetched: wow64 should mean nothing builds the i386 unix side, but a fetch is
|
|
# metadata only and costs almost nothing next to being wrong about that.
|
|
#
|
|
# CARGO_HOME is left at its default so it lands in this layer and the build
|
|
# layer inherits it.
|
|
export CARGO_NET_GIT_FETCH_WITH_CLI=true
|
|
export RUSTUP_TOOLCHAIN=stable
|
|
cd "${SRC_DIR}/gst-plugins-rs"
|
|
cargo fetch --locked --target x86_64-unknown-linux-gnu
|
|
cargo fetch --locked --target i686-unknown-linux-gnu
|
|
|
|
echo "proton: source at ${SRC_DIR}"
|