[mfelipe]

✍️ Description

Removes the Alpine install option for OpenViking. It cannot work, and no release of the application makes it work: not one of the 61 openviking versions on PyPI has a musllinux wheel. Every release publishes the same five files:

openviking-0.5.2-cp310-abi3-manylinux_2_31_x86_64.whl
openviking-0.5.2-cp310-abi3-manylinux_2_31_aarch64.whl
openviking-0.5.2-cp310-abi3-macosx_*.whl   (x86_64, arm64)
openviking-0.5.2-cp310-abi3-win_amd64.whl
openviking-0.5.2.tar.gz                     67 MB

tree-sitter-language-pack, which openviking pins, is the same: only the pre-1.0 0.13.0 ever shipped musllinux, every 1.x is manylinux/macOS/Windows/sdist. So on musl uv compiles two Rust projects from source — openviking is a ~645-crate workspace with lto = true, plus the tree-sitter grammar crates.

Measured on an Alpine 3.24 container (1 vCPU, this host):

step	result
uv pip install openviking	15m52s total, 13m58s of it inside cargo
disk	8 GB default → No space left on device (os error 28) while linking aws-sdk crates
RAM	3 GB (1 GB and 2 GB both die during the LTO link)
extra system packages	build-base, rustup, perl (vendored OpenSSL Configure), patchelf (maturin bundling), cmake, linux-headers

And after all of that the container still does not start. openviking's setup.py extracts only ragfs_python.abi3.so from the maturin wheel and discards the accompanying ragfs_python.libs/ directory, so the auditwheel-rewritten DT_NEEDED (libgcc_s-<hash>.so.1) has nothing to resolve against:

ImportError: ragfs_python native library is not available: Rust binding not available
uvicorn.error - ERROR - Application startup failed. Exiting.

On manylinux none of this exists — glibc's libgcc_s is whitelisted, so auditwheel neither bundles nor renames it — which is why the Debian path installs from wheels in about two minutes and works.

Changes:

• ct/openviking.sh — no OS menu, var_os="${var_os:-debian}", Debian resource defaults, update path folded into update_script() the way every other single-OS script does it (update_deb_based / update_alpine / run_os_update removed).
• install/openviking-install.sh — setup_alpine() removed; the Debian steps are top-level again (setup_deb_based / run_os_setup dropped) to match the repo layout. Health check goes from 30×2 s to 60×2 s: 60 seconds is tight for a 314-package venv to answer its first request on a small container.
• json/openviking.json — the alpine install method is removed; only the default Debian 13 entry remains.

Nothing changes for Debian users: same packages, same systemd unit, same config, same update flow.

If upstream ever publishes musllinux wheels (maturin --compatibility musllinux_1_2) and stops discarding ragfs_python.libs/ from the wheel, the Alpine option can come back in a few lines — the working patch exists, it just is not worth 15+ minutes, 3 GB and 20 GB per install.

🔗 Related PR / Issue

Link: #

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🖥️ Tested on (X in brackets)

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus – Created on an Incus host and the app works.

Application containers run on both; tick what you actually tested. VMs and host tools are Proxmox only.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose – The application is installed bare-metal; Docker is not used.
• No git pull – Updates use fetch_and_deploy_gh_release, fetch_and_deploy_codeberg_release, fetch_and_deploy_gl_release, or fetch_and_deploy_from_url instead of git pull.

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

Please describe to which degree, if any, an LLM was used in creating this pull request. Name the model(s) used and, if applicable, the reasoning/thinking effort level (e.g. "Claude Sonnet 4.5, high reasoning, used to draft the install script, then manually reviewed and tested" or "No LLM used"). This is informational, not a penalty — but scripts that are clearly AI-generated and not further revised by the author to match CODE-AUDIT.md / CONTRIBUTING.md may be closed without review.

Hermes Agent, model deepseek-flash (provider deepseek), standard reasoning level. Used to trace the Alpine failures end to end (maturin/puccinialin bootstrap, vendored OpenSSL needing perl, disk exhaustion, patchelf, missing ragfs_python.libs), to measure the source build, and to restructure the script to the single-OS layout. Manually reviewed, and the resulting Debian install was run end to end on Proxmox VE (see Additional Information).

---

📋 Additional Information (optional)

Verified after the change — Proxmox VE 9.2.21, Debian 13.1, unprivileged CT, 2 vCPU / 2048 MB / 8 GB:

✔️  Updated Container OS
✔️  Installed Dependencies
✔️  Python 3.12 installed   (uv, cpython-3.12.15-linux-x86_64-gnu)
✔️  Setup uv 0.13.5
✔️  Installed OpenViking    (Resolved 314 packages in 1.32s, Prepared in 2.54s, Installed in 340ms — wheels only, no cargo)
✔️  Configured OpenViking
✔️  Created Service         (health endpoint answering on 127.0.0.1:1933 after ~14s)
✔️  Completed Successfully!

The Doctor line reports warnings because embedding and vlm still carry the REPLACE_WITH_YOUR_*_API_KEY placeholders — that is the documented post-install step, not an install failure.

The Alpine figures above come from the same host: Alpine 3.24 container, openviking 0.5.2, 1 vCPU / 3 GB / 20 GB. To confirm the "no musllinux wheel" claim yourself:

python3 - <<'PY'
import json, urllib.request
d = json.load(urllib.request.urlopen("https://pypi.org/pypi/openviking/json"))
for ver, files in sorted(d["releases"].items()):
    if files:
        print(ver, sorted({f["filename"].split("-")[-1] for f in files}))
PY

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• Application: https://github.com/volcengine/OpenViking
• Wheels per release (no musllinux): https://pypi.org/project/openviking/0.5.2/#files
• tree-sitter-language-pack files: https://pypi.org/project/tree-sitter-language-pack/1.13.3/#files
• Upstream wheel assembly that drops ragfs_python.libs/: setup.py → build_ragfs_python_artifact()
• Alpine rustup package (no rust/cargo in v3.23/v3.24): https://pkgs.alpinelinux.org/packages?name=rustup&branch=v3.24

[github-actions]

✅ Requirements check passed. Thanks for fixing the description — the stale mark has been removed.

[github-actions]

Try this script

ct/openviking.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/mfelipe/ProxmoxVED/fix/drop-alpine-support \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/mfelipe/ProxmoxVED/fix/drop-alpine-support/ct/openviking.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.