dev-util/openchamber-bin
OpenChamber, a cockpit for running parallel opencode sessions
ChangeLog
commit 276587f9a273699ef5ded6db4f458edce9f45bc9
Author: lucascouts <lucascs@protonmail.com>
Date: Thu Sep 10 23:10:30 2026 -0300
add(dev-util/openchamber-bin-1.23.0), add(metadata/md5-cache/dev-util/openchamber-bin-1.23.0), mod(.autoupdate/packages.toml)
OpenChamber is a desktop cockpit for driving several opencode sessions at
once, which pairs with the dev-util/opencode-bin added earlier.
AppImage is the only Linux artefact upstream publishes, and unpacker.eclass
cannot read the format. src_unpack peels the squashfs off by hand: an AppImage
is an ELF launcher with a filesystem appended, starting at
e_shoff + e_shentsize * e_shnum, which is precisely what the AppImage
runtime's own --appimage-offset would report -- obtained here without
executing the downloaded file and without needing FUSE. readelf runs under
LC_ALL=C because it translates its field labels and the awk patterns match the
English ones.
Two upstream properties are repaired, and both fixes assert their own result
so a future bump fails loudly instead of regressing in silence:
The AppImage bundles copies of system libraries so it can run on hosts that
lack them -- libXss, libXtst, libnotify, libappindicator, libgconf,
libindicator. Checking rather than assuming: none appear in the binary's
NEEDED list, and only libnotify is referenced at all, through dlopen. They are
removed and RDEPEND names the real packages. That is not cosmetic:
libappindicator and libindicator do not exist in ::gentoo, so keeping them
would have meant shipping vendored copies of libraries the distribution has
deliberately dropped.
Upstream's desktop entry runs "AppRun --no-sandbox". An AppImage has no choice
there -- it cannot ship a setuid helper, so Chromium's sandbox must be off.
An installed package can, so chrome-sandbox is installed 4755 and the sandbox
stays ENABLED. Shipping a browser engine with its sandbox disabled because the
upstream launcher happened to say so would be a real security regression.
Verified, not assumed: pkgcheck reports 0 findings; the package completed
`ebuild ... clean install` without root; and the image was inspected --
no bundled usr/lib, no AppRun, chrome-sandbox mode 4755 (-rwsr-xr-x),
/usr/bin/openchamber resolving into /opt, Exec= rewritten, X-AppImage-Version
gone, and desktop-file-validate exiting 0 with no warnings.
Not verified: the application was never launched. It is an Electron GUI and
this session has no display, so only its installed image was checked. No merge
onto the live system either, so ownership is untested.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: lucascouts <lucascs@protonmail.com>
Date: Thu Sep 10 23:10:30 2026 -0300
add(dev-util/openchamber-bin-1.23.0), add(metadata/md5-cache/dev-util/openchamber-bin-1.23.0), mod(.autoupdate/packages.toml)
OpenChamber is a desktop cockpit for driving several opencode sessions at
once, which pairs with the dev-util/opencode-bin added earlier.
AppImage is the only Linux artefact upstream publishes, and unpacker.eclass
cannot read the format. src_unpack peels the squashfs off by hand: an AppImage
is an ELF launcher with a filesystem appended, starting at
e_shoff + e_shentsize * e_shnum, which is precisely what the AppImage
runtime's own --appimage-offset would report -- obtained here without
executing the downloaded file and without needing FUSE. readelf runs under
LC_ALL=C because it translates its field labels and the awk patterns match the
English ones.
Two upstream properties are repaired, and both fixes assert their own result
so a future bump fails loudly instead of regressing in silence:
The AppImage bundles copies of system libraries so it can run on hosts that
lack them -- libXss, libXtst, libnotify, libappindicator, libgconf,
libindicator. Checking rather than assuming: none appear in the binary's
NEEDED list, and only libnotify is referenced at all, through dlopen. They are
removed and RDEPEND names the real packages. That is not cosmetic:
libappindicator and libindicator do not exist in ::gentoo, so keeping them
would have meant shipping vendored copies of libraries the distribution has
deliberately dropped.
Upstream's desktop entry runs "AppRun --no-sandbox". An AppImage has no choice
there -- it cannot ship a setuid helper, so Chromium's sandbox must be off.
An installed package can, so chrome-sandbox is installed 4755 and the sandbox
stays ENABLED. Shipping a browser engine with its sandbox disabled because the
upstream launcher happened to say so would be a real security regression.
Verified, not assumed: pkgcheck reports 0 findings; the package completed
`ebuild ... clean install` without root; and the image was inspected --
no bundled usr/lib, no AppRun, chrome-sandbox mode 4755 (-rwsr-xr-x),
/usr/bin/openchamber resolving into /opt, Exec= rewritten, X-AppImage-Version
gone, and desktop-file-validate exiting 0 with no warnings.
Not verified: the application was never launched. It is an Electron GUI and
this session has no display, so only its installed image was checked. No merge
onto the live system either, so ownership is untested.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>


View
Download
Browse