Arch Linux User Repository

Hello all,

Kindly note: this packaging tracks the stable branch of helium-linux. Before marking this package out of date, please check the latest version here: https://github.com/imputnet/helium-linux/releases/latest. There can be anywhere from 10 minutes, up to a week (happened once) before upstream marks a release as "Latest."

If you wish to track the beta/pre-releases branch, you can use the helium-browser-beta-bin package.

Cheers,

Sam

Installing Helium's PGP key

==> Verifying source file signatures with gpg...
    helium-0.7.7.2-x86_64_linux.tar.xz ... FAILED (unknown public key 351601AD01D6378E)
==> ERROR: One or more PGP signatures could not be verified!

Since Helium 0.7.7.2 you will need Helium's PGP signature to verify the tarballs on install. This is a once off/once per system process.

• tl;dr: jump to step 3. Steps one and two exist simply to prove the key added to the PKGBUILD is legitimate (i.e., Helium's/Imputnet's), and how to manually import their key without a keyserver.

1. Get the key and signature. (Optional)

Obtain Helium's signing key from https://github.com/imputnet/helium-linux#signature and save the key to a file.

2. Verify the signature (Optional)

Run gpg --show-key /PATH/TO/helium_pub.asc. What returns should match the first comment of Helium's PGP key block, and the validpgpkeys entry in the PKGBUILD.

> gpg --show-key helium_pub.asc 
pub   ed25519 2025-10-11 [SC] [expires: 2028-10-10]
      BE677C1989D35EAB2C5F26C9351601AD01D6378E
uid                      Helium signing key (https://helium.computer/) <helium@imput.net>
sub   cv25519 2025-10-11 [E] [expires: 2028-10-10]

3. Install the key

• Option 1: source the key from upstream per step 1 and 2, and run:

gpg --import /path/to/helium_pub.asc

• Option 2: install from a public server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys BE677C1989D35EAB2C5F26C9351601AD01D6378E

4. Verify the key install

> gpg --fingerprint BE677C1989D35EAB2C5F26C9351601AD01D6378E
pub   ed25519 2025-10-11 [SC] [expires: 2028-10-10]
      BE67 7C19 89D3 5EAB 2C5F  26C9 3516 01AD 01D6 378E
uid           [ unknown] Helium signing key (https://helium.computer/) <helium@imput.net>
sub   cv25519 2025-10-11 [E] [expires: 2028-10-10]

5. Install helium as normal

Hello everyone,

v0.12.4.1 includes an amendment to align patch 0002 with upstream changes to the .desktop file, which no longer includes the StartupWMClass value.

Ref: https://github.com/imputnet/helium-linux/pull/296

Cheers,

Sam

Knotrocket,

Do you know which version is used by Helium when set to "Use QT" and why there are two .so libraries?

I can confirm that Helium only requires qt5-base after reviewing strace outputs. Testing with 'Use QT' enabled and disabled, version six is not called even when installed on my system. I believe the namcap results flagging version six was due to my system having the package installed. Also checking upstream, builds only include the qt5base-dev package (on Debian) 1.

So I think it's safe to say that we don't need version six, but version five should be included as an optional dependency for these and previously mentioned reasons. I will bump packaging to version two with this amendment shortly.

This issue and strace outputs has been documented here: https://github.com/s6muel/helium-browser-bin/issues/47

Please accept apologies for any inconvenience caused, and for the delay in responding.

Cheers,

Sam

Hey, I noticed that the url variable isn't really used in the source reference in the PKGBUILD, I think using the variable there is probably convenient, that way you only define it once and use it in the other places. Thanks!

Before making changes, might I propose that we move the qt{5,6}-base to optdepends, while inviting any suggestions and discussion.

Sounds good to me! I commented here because in my case qt5-base was not already installed when updating helium.

Do you know which version is used by Helium when set to "Use QT" and why there are two .so libraries?

Knotrocket,

After review, I think adding qt{5,6}-base was an unnecessary addition on my part in strictly adhering to namcap results. As you pointed out, this seems like a dependency for those that are using themes and at minimum should move to optdepends, but there's justification for their removal all together. Removal would align packaging with google-chrome which we might consider as the baseline standard for Chromium packaging. A namcap audit of the latest google-chrome packaging yields similar results to Helium.

However, my interpretation of the PKGBUILD guidelines [1] would suggest that we keep these as optional dependencies, since they 'provide additional features.' Additionally, namcap identifies these packages as optional dependencies and running find-deps against the latest Helium packaging would suggest the same.

Before making changes, might I propose that we move the qt{5,6}-base to optdepends, while inviting any suggestions and discussion.

Thanks for bringing this up!

Cheers,

Sam

[1] https://wiki.archlinux.org/title/PKGBUILD#optdepends

add qt5-base, qt6-base

Is this necessary for those who stick with the default appearance settings or only change the colours?

arc-d3v,

Yes absolutely. I will update the dependencies in 0.11.4.1 per an audit with namcap. In short, this will involve the following changes to depends and optdepends:

• replace systemd with udev
• add qt5-base, qt6-base
• remove desktop-file-utils, libffi, libgcrypt, pciutils, gtk4

The namcap audits along with a diff and further details can be found here: https://github.com/s6muel/helium-browser-bin/issues/46

Local testing found no issues; if anyone would like to test and provide feedback please feel free.

Cheers,

Sam

EDIT: These changes have been included in 0.11.5.1, if there are any issues please let me know.

Is it possible to put udev as a dependency instead of explicit systemd?

This is wrongly flagged out-of-date, 0.9.4.1 is marked as "latest" at the moment, 0.10.1.1 is still "pre-release".