On the run in which steamcmd replaces itself, the app_update that follows fails
with 'Missing configuration', and the same command succeeds once it runs again.
A login-only run first takes that self-update out of the install and update.
The noavx2 requirements pin numpy 1.23.5 and onnx 1.14.1, neither of which ships
a cp312 wheel, so on 3.12 uv built them from source: numpy fails without
distutils and onnx without cmake. Every noavx2 pin has a 3.11 wheel.
@lobehub/ui 5.50.0 dropped NeuralNetworkLoading, and LobeHub 2.2.18 still imports
it through a ^5.47.0 range with lockfile: false, so every fresh build now fails.
Upstream moved off it on main; the pin only applies while package.json still asks
for a 5.4x range, so it stops on its own with the next stable release.
The repo also publishes web-clipper-v* releases, and whenever upstream marked one
of those as latest the update offered to replace the server with the browser
extension. A v prefix makes core pick the newest stable server release itself
instead of trusting that marking.
2.16.0 ships production.conf only as a template that its s6 prepare step renders,
so installs outside Docker never listened on 81; render it on install, on update
while keeping a custom admin port, and on update for containers already stuck on
2.16.0. Certbot's upgrade died on a dist-info without RECORD, which pip's own
--ignore-installed hint does not clear, so drop such records before upgrading.
Upstream renamed OBSIDIAN_VERSION in its Dockerfile to IGNIS_OBSIDIAN_PIN, so the
grep matched nothing - and under pipefail the assignment itself aborts, which is why
the fallback on the next line never ran. The tag already carries the pairing
(0.8.13+obsidian.1.13.7), so read it there and keep both Dockerfile keys as a
fallback.
* Docker-LXC: remove Portainer installation from install
Removed Portainer installation prompts and related code.
* Remove Portainer installation instructions from docker.sh
Removed instructions for installing Portainer as an addon.
* scanopy: use prebuilt server binary, relax release profile for generate-fixtures
* scanopy: drop unneeded rust build, use committed UI fixtures
* scanopy: restore generate-fixtures build, ui/src/lib/data is gitignored and incomplete
* scanopy: serve the UI from the binary, drop the source build
Upstream confirmed in scanopy/scanopy#698 that scanopy-server-linux-*
has carried the built UI since v0.17.13, fixtures and service logos
included, served on the same port as the API. The release notes never
said so, which is why we kept building it.
That removes the source tarball, the Rust toolchain and
generate-fixtures, Node with npm ci and npm run build, and
SCANOPY_WEB_EXTERNAL_PATH. With the variable set to a directory that no
longer has an index.html, v0.17.14 and earlier refuse to start, so the
update deletes the line rather than leaving it. build-essential,
libssl-dev and pkg-config go too: the release binary is static-pie with
no INTERP segment, so it has no runtime library dependencies.
/opt/scanopy stays, now only for .env and oidc.toml, and the unit's
WorkingDirectory follows it out of the removed backend directory. Since
nothing wipes that directory any more, the config survives an update on
its own, which is the report upstream passed on of an update coming
back without SCANOPY_WEB_EXTERNAL_PATH and the server starting API-only.
The update keeps the running binary until the new one answers
/api/health and puts it back if it does not, so a bad release leaves a
working server instead of a stopped one.
check_for_gh_release now keys on scanopy-server, matching the version
file the binary deploy writes; the Scanopy key belonged to the tarball
that is gone. Existing containers run one extra update, then agree.
* Refactor scanopy-install.sh for server setup
Updated installation script to configure Scanopy server and removed daemon configuration section.
* Update service names from 'scanopy-server' to 'Scanopy'
* Fix case sensitivity in fetch_and_deploy_gh_release
* scanopy: make the rollback restore the whole old setup
The health check put the previous binary back but nothing else, and the
source tree it needs was already gone by then: the update deleted
/opt/scanopy/ui before starting the new server, and removed
SCANOPY_WEB_EXTERNAL_PATH from the env at the same time. A failed
health check therefore left the old binary running without the UI it
serves from disk, so the rollback produced an API-only server.
Back up the env file and the unit alongside the binary, restore all
three when the check fails, and delete the source tree only once the
new server has answered. Nothing the old version needs is removed
before the new one has proven itself.
* scanopy: name the deployed binary what the unit starts
singlefile mode writes the asset to <target>/<app name>:
local target_file="$app"
[[ "${USE_ORIGINAL_FILENAME:-false}" == "true" ]] && target_file="$filename"
so with the app renamed to Scanopy the binary lands at /usr/bin/Scanopy
while the unit starts /usr/bin/scanopy-server, and the service never
comes up on a fresh install. Rename it after the deploy, the same way
the daemon block already renames "Scanopy Daemon".
Keeping the app name is what matters here: it is also the version file
(~/.scanopy), and changing it would make every existing container
report an update it does not need.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
* Let uv see the project before syncing it
uv refuses to run when a project pins a required-version it does not
match, in either direction: RomM pins ==0.12.13, which fails against
both the 0.10.3 a container was built with and the 0.12.17 latest
installs.
UV_PROJECT_DIR points setup_uv at the project so it reads that pin. It
is a prefix like PYTHON_VERSION and UV_VERSION, and the call sits
directly under fetch_and_deploy: the project is on disk by then, and
the deploy has closed its message block, which setup_uv needs since it
opens one of its own. That is also the only call needed - nothing
between the old early call and the deploy uses uv or Python, so the two
collapse into one.
Two things found along the way:
UV_PYTHON was set as a command prefix on setup_uv in 14 places. setup_uv
reads PYTHON_VERSION, never UV_PYTHON, and a prefix assignment does not
outlive the call, so those pins did nothing. They now use
PYTHON_VERSION, which installs the interpreter they were asking for.
Five update scripts had no setup_uv at all while their install
counterpart pinned a Python version. They now carry the same pin.
immich is left out: it runs uv through sudo -u inside a retry loop.
* yubal: drop the uv 0.7.19 pin
The pin came in with the script and was never explained. uv 0.7.19 is
from 2025-07-02; yubal's uv.lock has carried revision 3 since at least
2025-12-27, and older uv refuses a newer lockfile revision. The script
runs uv sync --frozen, so there is no fallback.
yubal declares no required-version of its own, so latest is what it
gets - and if it ever pins one, that pin is now honoured.
generate-app-headers.sh read APP with a plain grep -oP, so a script that
sets APP twice yielded both lines and the filename became
"almalinux
almalinux${var_version}vm". Three of those are in the tree
and they make main impossible to check out on Windows.
Nothing reads vm/headers: get_header fetches banners from the core
repo, which already carries clean almalinux, debian and ubuntu.
* Ubuntu-VM: AIO | new core | performance | remove old wrappers
This script automates the creation of an Ubuntu virtual machine with configurable options such as version selection, cloud-init usage, and advanced settings.
* Delete vm/ubuntu2204-vm.sh
* Delete vm/ubuntu2404-vm.sh
* Delete vm/ubuntu2504-vm.sh
The default path set USE_CLOUD_INIT itself, so the username and
password dialogs were skipped; only the advanced path asked. The cloud
image sets no password, so the question is which credentials, not
whether. Same fix as almalinux-vm and fedora-vm.
* suggestarr: keep the data where the app actually reads it
The env file sets CONFIG_DIR=/opt/suggestarr_data and the service passes
it through, but SuggestArr never reads that variable. Its database
manager builds the path from the application directory:
DB_PATH = os.path.join(BASE_DIR, 'config', 'config_files', 'requests.db')
so config.yaml, requests.db and secret.key live under /opt/suggestarr,
which the update wipes with CLEAN_INSTALL. Every update came back as a
fresh install.
Make config/config_files a symlink to /opt/suggestarr_data and lay it
down again after each deploy, since the deploy replaces it with a real
directory. Existing installs have their files copied across first, with
cp -an so anything already in the data directory wins.
CONFIG_DIR stays in the env file: it is inert today and costs nothing if
upstream starts reading it.
* suggestarr: let a failed migration stop the update
The || true was wrong and the review caught it. CLEAN_INSTALL wipes
/opt/suggestarr right after this copy, so swallowing a failure here
means the source is deleted with nothing carried across.
The guard was not even doing anything: cp -an exits 0 when it skips a
file that already exists in the target, which is the only case that
looked like it needed one. It only returns non-zero on a real failure,
which is exactly when the update has to stop - and it now stops before
the deploy, with the original data still in place.
cp -an, target file exists -> exit 0, continues
cp -an, source missing -> exit 1, ERR trap, aborts before deploy
2>/dev/null goes as well, so the reason is visible.
* refactor: streamline OxiCloud installation process by using prebuilt binaries
* oxicloud: take the prebuilt binary in the update too
Upstream now attaches musl tarballs to every release (AtalayaLabs/
OxiCloud#533), so the update no longer has to install a Rust toolchain
and Node and compile for up to 35 minutes. That compile is also what
broke #16216: a release whose source did not build left users with a
failed install and no way forward.
The tarball carries one top-level directory, which the deploy helper
strips, so the binary lands at /opt/oxicloud/oxicloud. The frontend is
baked into it, so the SPA build and OXICLOUD_STATIC_PATH both go; the
variable is commented out rather than removed, since a stale ./static
path would otherwise point at a directory that no longer exists.
migrate-nfc-filenames is gone as a separate binary - it is now a
subcommand, oxicloud migrate nfc-filenames - so the update removes the
old one. ffmpeg replaces build-essential: the server forks it for video
thumbnails and it is the one runtime dependency the musl build still
needs from the system.
Defaults drop to 2 CPU and 2048 MB, which were sized for the compile.
* oxicloud: install ffmpeg on update as well
The install gained it, the update did not, so a container created before
this change would never get it. The musl binary forks ffmpeg for video
thumbnails; without it that one feature stays silently unavailable.
* immichframe: set the admin password the new admin UI requires
immichFrame/ImmichFrame#698 added an admin UI that refuses to open
/admin unless IMMICHFRAME_ADMIN_PASSWORD is set, leaving users to edit
the unit by hand after an install or an upgrade from an older version.
Generate one, put it in the unit next to the other Environment lines,
and record it in ~/immichframe.creds the way the other scripts record
credentials. The update adds the line only when it is missing, so a
password already set by hand survives.
* immichframe: write the creds file the way the other scripts do
Sixty install scripts use cat <<EOF for their .creds file and exactly
one used an echo block, which was this one. Match the rest.
The install writes the file, the update appends: on an existing
container the file may already be there from the original install, and
the password line is only added when the unit has none.
Upstream derives everything from one setting:
ROMM_BASE_PATH = _get_env("ROMM_BASE_PATH", "/romm")
LIBRARY_BASE_PATH = f"{ROMM_BASE_PATH}/library"
There is no separate library setting; config.yml's roms_folder is only
a folder name inside the library. So ROMM_BASE_PATH in /opt/romm/.env
is the single lever, and everything that names a path has to follow it.
Two places did not. The watcher unit had /var/lib/romm/library written
into ExecStart, so a moved library was still watched at the default and
rescans never fired. It now uses ${ROMM_BASE_PATH}/library, which
systemd expands from the EnvironmentFile the unit already loads.
The Angie alias was derived from the env file, but only while the
install or an update ran. Editing ROMM_BASE_PATH afterwards left the
internal /library/ location pointing at the old path, and since the
backend serves content through X-Accel-Redirect, every download and
every play returned 404 while scanning and metadata kept working.
Re-sync it from an ExecStartPre on angie, so a restart is enough.
Update installs both for existing containers and rewrites the watcher
unit in place.
Reported in #17263. The suggested fix there was to template the alias,
which the scripts already did; the gap was that nothing re-applied it.
* sparkyfitness: run the Better Auth migration during the update
1.7.1 ships a Better Auth version whose schema has columns 1.6.5 never
created, and nothing in the update adds them. The backend starts, then
refuses every sign-in:
Database schema mismatch
Missing columns session.impersonated_by two_factor.verified ...
Run `npx auth migrate` to add the missing tables and columns.
Run exactly that after the backend dependencies are in place, with the
config Better Auth looks for, SparkyFitnessServer/auth.ts, and the
database credentials from /etc/sparkyfitness/.env. Users who hit this
were left running the server by hand to get the columns created.
A failure warns instead of aborting: the rest of the update has already
succeeded at that point, and the message names the remaining step.
* sparkyfitness: start the server through the entrypoint that migrates
The Better Auth CLI added in the previous commit is the wrong tool. It
generates sso_provider.user_id as text and cannot reference this
schema's uuid user.id:
foreign key constraint "sso_provider_user_id_fkey" cannot be
implemented [...] incompatible types: text and uuid
The real cause is one line up in the unit. It ran
tsx SparkyFitnessServer.js
which imports the application module directly and never applies the
schema migrations. Upstream starts through index.ts - nodemon.json has
exec: tsx index.ts - and that file runs applyMigrations() and
applyRlsPolicies() before importing anything, with a comment naming this
exact failure:
Better Auth validates the database schema eagerly, the moment
betterAuth() is constructed at auth.ts module scope [...] When
migrations ran later (from inside SparkyFitnessServer.ts) that check
read the pre-migration schema on the first boot after an upgrade, so
every /api/auth request failed until the container was restarted.
Point both the install and the update at index.ts and drop the CLI call.
index.ts exits non-zero when a migration fails, so systemd surfaces that
instead of serving a broken login.
6.87.0 moved init.sh from the repository root to docker/init.sh, so the
update stopped at
chmod: cannot access '/opt/poznote/init.sh': No such file or directory
The file itself is byte for byte the same and uses absolute paths only,
so running it from the new location changes nothing. Prefer docker/ and
fall back to the old path, since a container pinned to an older release
still has it there.
* pocketbase-bot: accept the var_ names and two missing fields
cpu, ram, hdd, os and version were already reachable, but only under
the PocketBase names. People type what the ct scripts call them, so
"/pocketbase <slug> var_ram=4096" was rejected as an unknown field
while "ram=4096" worked. The bot already carried the mapping as
RESOURCE_TO_CT_VAR, for display only.
Normalise the keys in parseKVPairs, so both the field=value path and
the method path accept them, along with disk and memory as the other
two names people reach for. Matching is case-insensitive.
pin_reason and last_update_commit exist on the record and are worth
editing, but were not in ALLOWED_FIELDS. slug, script_created and
script_updated stay out: the first is the key the command looks the
record up by, the other two belong to the timestamp workflow. notes and
install_methods keep their own subcommands.
* pocketbase-bot: write the sync PR against the PR template
The sync PR body had its own Summary and Source headings, so the
autolabeler found none of the template checkboxes it looks for and the
PR came out with nothing but "needs triage". It also never referenced
the issue the command came from.
Write the body the way the template expects, with the Website update
box ticked, which is what a PocketBase sync is. Tested thoroughly stays
unticked and Tested on says not tested, because nothing here was run;
close-invalid-pr-template skips bot authors, so that costs nothing.
Reference the triggering number as Fixes when the command came from an
issue and as a plain mention when it came from a PR comment, where
Fixes would point the PR at itself. issue_comment carries both under
github.event.issue, so the new IS_PR_COMMENT tells them apart.
* ci: stop the .app header PR being closed as a new script
allowedBots carried "community-scripts-pr-app" but not the
"[bot]"-suffixed name GitHub actually reports, and the check is an exact
match, so the exemption never applied to it. push-app-to-main is listed
both ways; this one was not. PR #17304 was closed as an untested new
script submission because of it.
generate-app-headers.sh empties ct/headers, tools/headers and
vm/headers and writes them again, so every run reports those files as
added. That is what the autolabeler's new-script rule looks for, and
the vm rule matched vm/headers too. Exclude the header directories from
both, and skip them in the close workflow's own added-file fallback, so
the label cannot come back by another route.
Checked against minimatch with the shipped config: header files get
neither label, ct/*.sh, install/*.sh and vm/*.sh still get theirs.
* pocketbase-bot: label the sync PR as a bugfix
The sync corrects CT defaults that no longer match the PocketBase
record, so bugfix describes it better than website update, which is
meant for metadata changes on the site itself.
* frigate: move to 0.18.0
Bump the pinned release and follow the four build changes that matter
outside of Docker.
ffmpeg: 0.18 ships 8.0 as the default and keeps 7.0 and 5.0 alongside
it, so /etc/frigate.env has to name all three or the s6 run script
resolves a version that install_deps.sh never downloaded.
go2rtc: pin to v1.9.14, the version the Dockerfile fetches. "latest"
happened to work but shipped whatever AlexxIT had tagged that day
rather than the build Frigate was tested against.
OpenVINO: requirements-ov.txt dropped tensorflow and openvino-dev, and
build_ov_model.py no longer uses the Model Optimizer. omz_tools is
therefore gone, which left the first two branches of the labelmap
lookup dead; download coco_91cl_bkgr.txt the way the Dockerfile does.
Intel media driver: 0.18 builds intel-media-va-driver-non-free from
source for Battlemage, because the prebuilt noble/trixie packages need
a glibc that bookworm does not have. Run it before install_deps.sh, as
the deps-rootfs stage does, and drop the jammy repo the build adds so
the later trixie pull for libva2 is not resolved against it.
The remaining build scripts and requirement files changed too, but
those come from the checked-out tree and follow the version bump on
their own.
* frigate: stop the detector config from replacing the base config
The install wrote a config with mqtt, cameras, auth and detect, then the
detector branch wrote the file again instead of adding to it. Both
branches used a single redirect, so everything above them was discarded
and the result had neither mqtt nor cameras. frigate/config/config.py
declares both as Field() without a default, in 0.17.2 as well as in
0.18.0, so Frigate rejected the file and came up in safe mode:
mqtt - Field required
cameras - Field required
Move hwaccel_args into the base block, since both branches set it, and
append the detector and model sections instead of overwriting.
Checked by generating both branches and parsing the result: the OpenVINO
path yields auth, cameras, detect, detectors, ffmpeg, model, mqtt, the
CPU path the same without detectors, and the test camera survives in
both.
* frigate: write the config in one place
Only the detector and model section depends on the CPU check, but the
file was assembled in three heredocs writing to the same path. That
shape is what produced the safe-mode config: both branches used a plain
redirect and discarded everything above them.
Pick the variable part into DETECTOR_CONFIG first and write the file
once, so the layout is visible in one block and no branch can replace
what came before it.
Output is unchanged, verified by generating both branches from the
previous commit and from this one and diffing: byte-identical.
* Update default RAM and disk values in frigate.sh
Navidrome 0.61.x created cache, artwork and plugins under the data
folder whenever any navidrome command ran, including the ones the deb
postinstall runs as root. 0.62 stopped creating them that way but never
corrected the owner, so a container that passed through 0.61.x carries a
root-owned artwork directory. 0.64.0 is the first release to write into
it and fails with
writing image store: mkdir /var/lib/navidrome/artwork/hashed:
permission denied
which breaks newly resolved album covers and every playlist cover, since
those are composites.
Repair the three directories the same way navidrome/navidrome#6143 does:
the entries themselves only, since they were created empty, real
directories owned by root only, and chown -h, because the navidrome user
owns the data folder and could otherwise plant a symlink.
The trailing || true is not in the upstream copy and is needed here.
Their postinstall runs without set -e, while update_script runs under
catch_errors, which sets -Ee with an ERR trap. find exits 1 as soon as
one starting point is missing, so on a container without a plugins
directory the update would abort.
Fixes the report in #17247, confirmed there by the reporter's stat and
dpkg log: artwork is root-owned and dated to their 0.60.3 -> 0.61.1
upgrade.
* HomeAssistant-OS (VM): Refactor for improved readability
Refactor script to improve readability and maintainability. Updated function calls and variable assignments for better clarity.
* Modify author line in haos-vm.sh
Updated author information in the script header.
* Refactor Home Assistant OS version selection and caching
Refactor advanced settings dialog for Home Assistant OS version selection and simplify image caching logic.
* tor-snowflake: read the Go version from the module root
Snowflake is a single Go module with go.mod at the repository root, not
under proxy/. The install read /opt/tor-snowflake/proxy/go.mod, which
has never existed, so grep failed and the version came out empty. Go
was then fetched from
https://go.dev/dl/go.linux-amd64.tar.gz
with no version in the name, and the install aborted at that download.
Read the directive with a single awk instead of grep piped into awk.
The pipeline tripped catch_errors, which sets -Ee with pipefail and an
ERR trap, the moment the file was missing; that is the "exit code 2
while executing command awk" line that preceded the download failure.
Fall back to latest when the file cannot be read, so a future upstream
move of go.mod costs a Go version that is newer than the one pinned
rather than a failed build. setup_go already resolves latest, and also
resolves a bare major.minor to its newest patch, so a go directive
without a patch level stays fine.
Verified against v2.14.1: go.mod sits at the root and declares go
1.24.0, and the awk yields 1.24.0 from it and latest from a missing
file without tripping the ERR trap.
* Refactor GO_VERSION extraction in tor-snowflake.sh
Updated the method of extracting GO_VERSION from go.mod and set a default value if not found.
* Refactor: TrueNAS VM (core / improve functions / performance)
* Boot TrueNAS from sata0, the disk it actually installs to
The boot order named scsi0, which never exists: the system disk is
sata0, and imported passthrough disks start at scsi1 because SCSI_NR is
pre-incremented. So the order always fell through to ide2 and the
installer came back up after every reboot.
* Fix URL in truenas-vm.sh script
Docmost pins its package manager, so running pnpm goes through corepack,
which asks before fetching the pinned version:
Corepack is about to download .../pnpm-11.25.0.tgz
? Do you want to continue? [Y/n]
The pnpm calls run under $STD, so with verbose off the question is
never shown and the update sits on "Configuring Docmost" waiting for an
answer nobody can see. With verbose on the same update completes,
because the prompt is visible and gets answered, which is exactly what
the reporter observed.
Set COREPACK_ENABLE_DOWNLOAD_PROMPT=0 before the pnpm calls in both the
install and the update, the way fifteen other ct scripts and ten
install scripts already do.
One checklist now lists containers and VMs side by side, each tagged with its
type, with separate ALL CT / ALL VM entries. VMs stop via qm stop and are
removed with qm destroy --purge --destroy-unreferenced-disks.
Two fixes fall out of the rework: the destroy exit status is read from the
background job rather than from the spinner, so failures actually surface, and
a guest is only stopped once its deletion is confirmed.
bullseye left security.debian.org when its LTS ended, so the hardcoded
libssl1.1_1.1.1w-0+deb11u8 filename now 404s. Scan the security, the
security-archive and the archive pools and take the newest build on offer
for the host architecture.
Closes#17104
A container keeps the slug it was built with, so a renamed ct/ script leaves
the updater looking for a name that no longer exists.
Reported for pbs, renamed to proxmox-backup-server in 0e5f663df. The Alpine
merge on 2026-08-18 retired 29 more names the same way, so every container
installed from an alpine-* script before that date hits this too.
Candidates are only accepted when the target script really exists, so an
unknown slug still errors rather than running some other app's updater.
Fixes#16989
* FileFlows Node: Stop Spinner before read -rp
* fileflows: update install path for Node->Agent rename, detect service unit dynamically
* fileflows: tolerate no pre-existing fileflows units when checking for the new Agent unit
Replaces the misc/build.func bootstrap with the two-root core loader.
No other change: the engine contract (var_*, update_script, start,
build_container, description) is identical on both engines.
versitygw.sh additionally gains a trailing newline; it lacked one.
With this batch every ct/ script is on the core engine.
Replaces the misc/build.func bootstrap with the two-root core loader.
No other change: the engine contract (var_*, update_script, start,
build_container, description) is identical on both engines.
Replaces the misc/build.func bootstrap with the two-root core loader.
No other change: the engine contract (var_*, update_script, start,
build_container, description) is identical on both engines.
The 25 most-installed ct scripts still on misc/build.func, by install
count: homarr, influxdb, sonarr, radarr, networkoptimizer, authentik,
stirling-pdf, seerr, prowlarr, searxng, wordpress, zabbix, omada,
homeassistant, pegaprox, crafty-controller, iventoy, homelable,
flaresolverr, metube, netbird, casaos, obsidian-livesync, npmplus,
wazuh. ProxmoxVE goes from 115 migrated to 140.
Same three checks as #16749, since "migrate" has meant more than a line
swap before:
- None of the 25 has an alpine-* variant, so there is no merge to do.
- None references misc/ outside its bootstrap line.
- Two functions exist only in misc/ (_gl_asset_urls,
_send_abort_telemetry) and none of the 25 calls either.
So it is one line per script. Every head is byte-identical to the ones
migrated earlier, each diff is exactly 3+/1-, and all 25 parse.
Worth watching: scanopy is not in this set but sits at 32.9% success,
and casaos at 49.4% and networkoptimizer at 48.6% are in it. If those
two move, the engine is one changed variable among others.
vars.APP_ID named two different apps: 1065612 (community-scripts-pr-app)
here, 1108144 (app-header-generator) in ProxmoxVED. Folding both into
one GHAPP_HEADERS_ID would have pointed this repo at the wrong app, so
the PR app gets its own name.
CanbiZ (MickLesk)
