Package Details: thorium-browser-bin 130.0.6723.174-1

Git Clone URL: https://aur.archlinux.org/thorium-browser-bin.git (read-only, click to copy)
Package Base: thorium-browser-bin
Description: Chromium fork focused on high performance and security
Upstream URL: https://github.com/Alex313031/Thorium
Licenses: BSD-3-Clause
Conflicts: thorium-browser
Provides: thorium-browser
Submitter: StarterX4
Maintainer: xiota
Last Packager: xiota
Votes: 54
Popularity: 1.12
First Submitted: 2022-08-03 14:39 (UTC)
Last Updated: 2025-02-09 23:57 (UTC)

Pinned Comments

xiota commented on 2024-09-29 22:55 (UTC) (edited on 2024-10-01 10:49 (UTC) by xiota)

This package has been revised to use the variant corresponding to architecture set in some config files. This may cause problems with other packages, so users choosing to do this are (mostly) on their own.

  • makepkg.confCARCH="x86_64_v3" (or v2)
  • pacman.confArchitecture = auto x86_64 x86_64_v2 x86_64_v3
  • /usr/share/devtools/setarch-aliases.d/x86_64_v3 — Contents: x86_64

The default variant is SSE3. This version is the closest available to baseline x86_64, which is currently the only architecture supported by Arch Linux. Other variants have shown no significant performance benefit, while crashing on some users' computers. The default will not be changed unless upstream offerings change or there is no other way to prevent a significant bug. Please refrain from arguing to change default for any other reason.

Alternate PKGBUILDs are available (i386, sse3, sse4, avx, avx2). They may be used by running makepkg -Cp <file>. This is the recommended way to build alternate versions to avoid interfering with other packages.

xiota commented on 2023-10-10 04:01 (UTC) (edited on 2025-02-09 23:58 (UTC) by xiota)

  • This package no longer attempts to autoupdate.

  • Avoid flagging and commenting at the same time for the same issue.

    • Flag for common issues with standard solutions (new version, typos, hash mismatch, etc).
    • Comment for issues requiring explanation or debugging.
    • Use a pastebin for blocks of text more than a few lines.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 10 Next › Last »

xiota commented on 2024-10-01 10:55 (UTC)

Package should work with aura now.

Pinned comments have been updated, including more info about changing architecture. However, doing so not recommended because it prevents other packages from being built

==> ERROR: _____ is not available for the 'x86_64_v3' architecture.

Workaround: makepkg --ignorearch.

RubenKelevra commented on 2024-09-30 05:34 (UTC)

With the default x86_64 CARCH building the package with Aura also fails now:

Aura:

aura -A thorium-browser-bin
aura :: Determining dependencies...
aura :: AUR packages:
 thorium-browser-bin
aura :: Proceed? [Y/n] 
aura :: Preparing build directories...
aura :: Building thorium-browser-bin...
/home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD: line 22: /home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD.base: No such file or directory
==> ERROR: Failed to source /home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD
aura :: Package failed to build, citing:

  makepkg failed.

aura :: Action cancelled.

RubenKelevra commented on 2024-09-30 05:29 (UTC)

I've changed my CARCH to "x86_64_v3" but it doesn't build with paru or aura:

Paru:

fetching devel info...
==> Making package: thorium-browser-avx2-bin 126.0.6478.231-4 (Mon 30 Sep 2024 07:24:44 AM CEST)
==> Retrieving sources...
  -> Downloading thorium-browser_126.0.6478.231_AVX2.deb...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  139M  100  139M    0     0  2188k      0  0:01:05  0:01:05 --:--:-- 2574k
==> Validating source files with sha256sums...
    thorium-browser_126.0.6478.231_AVX2.deb ... Skipped
==> Making package: thorium-browser-avx2-bin 126.0.6478.231-4 (Mon 30 Sep 2024 07:25:50 AM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found thorium-browser_126.0.6478.231_AVX2.deb
==> Validating source files with sha256sums...
    thorium-browser_126.0.6478.231_AVX2.deb ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
==> Starting prepare()...
'/dev/stdin' -> 'thorium-browser-avx2.sh'
==> Sources are ready.
thorium-browser-bin-126.0.6478.231-4: parsing pkg list...
error: package list does not match srcinfo
error: packages failed to build: thorium-browser-bin-126.0.6478.231-4

Aura:

aura -A thorium-browser-bin
aura :: Determining dependencies...
aura :: AUR packages:
 thorium-browser-bin
aura :: Proceed? [Y/n] y
aura :: Preparing build directories...
aura :: Building thorium-browser-bin...
/home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD: line 28: /home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD.avx2: No such file or directory
==> ERROR: Failed to source /home/ruben/.cache/aura/builds/thorium-browser-bin/PKGBUILD
aura :: Package failed to build, citing:

  makepkg failed.

aura :: Action cancelled.

RubenKelevra commented on 2024-09-30 05:19 (UTC) (edited on 2024-09-30 05:21 (UTC) by RubenKelevra)

@xiota Sorry if my question seemed off. I was genuinely asking why you aren’t providing separate packages if you’re already maintaining multiple build instructions. You mentioned it "wasn't worth the effort," but upstream creates distinct versions, and you’re still handling multiple builds. It’s confusing since this approach affects usability for users with modern CPUs. I’m not against supporting older CPUs, just wondering why not split them for better user experience.

If you don't have the time to maintain multiple packages, I'm happy to take over the non SSE3 builds.

xiota commented on 2024-09-29 22:55 (UTC) (edited on 2024-10-01 10:49 (UTC) by xiota)

This package has been revised to use the variant corresponding to architecture set in some config files. This may cause problems with other packages, so users choosing to do this are (mostly) on their own.

  • makepkg.confCARCH="x86_64_v3" (or v2)
  • pacman.confArchitecture = auto x86_64 x86_64_v2 x86_64_v3
  • /usr/share/devtools/setarch-aliases.d/x86_64_v3 — Contents: x86_64

The default variant is SSE3. This version is the closest available to baseline x86_64, which is currently the only architecture supported by Arch Linux. Other variants have shown no significant performance benefit, while crashing on some users' computers. The default will not be changed unless upstream offerings change or there is no other way to prevent a significant bug. Please refrain from arguing to change default for any other reason.

Alternate PKGBUILDs are available (i386, sse3, sse4, avx, avx2). They may be used by running makepkg -Cp <file>. This is the recommended way to build alternate versions to avoid interfering with other packages.

xiota commented on 2024-09-29 22:23 (UTC) (edited on 2024-09-29 22:25 (UTC) by xiota)

I was pointing out that continuing this was not helpful.

@FFY00 That is why I shut the discussion down by telling the instigating user to stop commenting, with explicit exception for legitimate packaging issues. In the future, I will refer cases directly to you. Here are some users who have likely violated Arch CoC.

  • rekman at python-tokenizers. Continues demanding changes that are not applicable to package. Cussed at me.
  • toropisco. Has multi-year history of insulting users ("you really are an idiot", "child") and refusing to fix legitimate packaging issues. (One split package has components that conflicts with each other, triggering uninstall/reinstall loops.)

FFY00 commented on 2024-09-24 10:25 (UTC)

xiota, the discussion progressed from a technical discussion to personal attacks, with multiple people involved. I was pointing out that continuing this was not helpful.

Regarding the SIMD usage, yes, a lot of software, including browsers, leverages SSE and AVX instructions, though this is often done using runtime instruction set detection. This means that the software will indeed include SSE or AVX instructions in the binary, but will only run those code branches if the CPU supports them. See [1] for a simple implementation example.

Regarding the package, I think I may have misunderstood the comments, sorry. Considering this is a -bin package, if there are no upstream builds without SIMD instructions, the most commonly supported build should probably be chosen, which may be SSE3. Support for newer instruction sets could be provided via the x86_64-v3 architecture, if desired.

[1] https://lwn.net/Articles/691932/