[bong-water-water-bong]

Weekly releases, every Sunday (docs/releases.md). The engine pins every upstream, and Lemonade ships on Fridays, so on Sunday Strix Halo rebuilds everything at that week's pins and publishes v<ISO year>.<ISO week>.

• scripts/weekly.sh <workdir> [stage...]:
  • bumps: verifies each open bump-* PR merged onto main (full build, ctest with serve end to end, plus the check that bump needs), then updates it, waits for CI and merges it. PRs that fail stay open and are listed as held back.
  • build, test, package, release: builds main, runs ctest, packages it and publishes the release.
  • WEEKLY_DRY_RUN=1 merges and publishes nothing.
  • Heavy steps wait for free memory and retry after mem-guard kills them, because the box is shared.
• scripts/package-linux.sh: a relocatable tarball of 1bit and every backend. Libraries loaded from the build tree go beside the programs that load them ($ORIGIN), and XRT goes in xrt/lib. RUNPATHs into TheRock stay.
• app/built_path.h: 1bit's backends are compiled in by build-tree path. When that path is gone, 1bit looks for the same relative path beside itself.
• tools/weekly_changes.py: for each moved pin, the upstream commits (authors, PRs) and releases since the last release. Its output becomes changes.json and the release notes. Discord's #announcements post is written from changes.json by a local bot.
• scripts/build-lemonade.sh: copies resources/ beside lemond, which refuses to start without it.

Verified on Strix Halo (build 21 min, packages 6 min):

• ctest: 11/11, including serve_e2e on vulkan, hrx, vulkan with hrx prefill, and zinc.
• The Linux tarball, unpacked in /tmp with the build tree moved away, passes serve_e2e on vulkan, hrx, zinc and --prefill-device hrx. DwarfStar, ONNX and lean have no missing libraries.
• lemond from the Lemonade package starts and lists the onebit models.
• Package sizes: Linux 117 MB, Lemonade 5 MB, 1bit OS 101 MB img.zst + 107 MB efi. The Windows zip now holds only the exe/dll files.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit 4809549

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 4809549)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Path Resolution Logic The built_path function attempts to resolve backend paths relative to the build directory when the original path does not exist. However, it only checks for the existence of the path in the build directory on Linux (__linux__ defined). On other platforms, it will always return the original path, which may lead to incorrect behavior if the backend is not found at the expected location. This could cause runtime errors or unexpected behavior when running the engine in environments where the build directory is not accessible or when using non-Linux systems. inline std::string built_path(const char* compiled) { namespace fs = std::filesystem; std::error_code ec; if (fs::exists(compiled, ec)) return compiled; #if defined(ONEBIT_BUILD_DIR) && defined(__linux__) const fs::path rel = fs::path(compiled).lexically_relative(ONEBIT_BUILD_DIR); if (!rel.empty() && *rel.begin() != "..") { const fs::path here = fs::read_symlink("/proc/self/exe", ec).parent_path(); if (!ec && fs::exists(here / rel, ec)) return (here / rel).string(); } #endif return compiled; } RPATH Handling The script modifies RPATH entries for ELF binaries to ensure they find their libraries beside themselves. However, it does not check for or handle cases where the build directory path might be embedded in the binary's RPATH in a way that could conflict with the intended runtime behavior. This could lead to issues if binaries are expected to load libraries from specific locations that are not properly handled by the script's RPATH manipulation. fix() { # fix <staged file> <file in the build> local f=$1 orig=$2 keep="" e dep while read -r dep; do case "$dep" in "$build"/*) [ -e "$(dirname "$f")/$(basename "$dep")" ] || { cp -L "$dep" "$(dirname "$f")/"; queue+=("$(dirname "$f")/$(basename "$dep")|$dep"); } ;; esac done < <(ldd "$orig" 2>/dev/null | awk '$2 == "=>" && $3 ~ /^\// {print $3}') for e in $(readelf -d "$orig" | sed -n 's/.*R\(UN\)\{0,1\}PATH.*\[\(.*\)\]/\2/p' | tr ':' ' '); do case "$e" in '$ORIGIN'*|"$build"*|"$HOME"*|'') ;; *) keep="$keep:$e" ;; esac done patchelf --set-rpath "\$ORIGIN$keep" "$f" } queue=() while IFS= read -r -d '' f; do is_elf "$f" && queue+=("$f|$build/${f#"$stage"/}") done < <(find "$stage" -mindepth 2 -type f -print0) while [ ${#queue[@]} -gt 0 ]; do item=${queue[0]}; queue=("${queue[@]:1}") fix "${item%%|*}" "${item#*|}" done if [ -n "$xrt" ] && readelf -d "$stage/1bit" | grep -q libxrt; then mkdir -p "$stage/xrt/lib" cp -a "$xrt"/lib/libxrt_coreutil.so* "$xrt"/lib/libxrt_core.so* "$stage/xrt/lib/" 2>/dev/null || true cp -a "$xrt"/lib/libxrt_driver_xdna.so* "$stage/xrt/lib/" 2>/dev/null || true while IFS= read -r -d '' f; do is_elf "$f" && patchelf --set-rpath '$ORIGIN' "$f"; done \ < <(find "$stage/xrt/lib" -type f -print0) patchelf --set-rpath '$ORIGIN/xrt/lib' "$stage/1bit" echo " xrt/lib: $(ls "$stage/xrt/lib" | wc -l) files" else patchelf --remove-rpath "$stage/1bit" fi Memory Guard Retry Logic The guard function retries execution of commands up to 10 times if memory guard stops them. However, if a command fails consistently due to resource constraints, it could lead to a long-running process or even a hang, as the retries do not include exponential backoff or a timeout mechanism. This could cause the weekly release process to stall indefinitely if the system remains under heavy load. guard() { local try for try in $(seq 10); do room || return 1 "$SRC/scripts/mem-guard.sh" 4 "$@" && return 0 say "memory guard stopped it (try $try): $*" done return 1 }

[github-actions]

Persistent review updated to latest commit 4809549