Package Details: firefox-vaapi 134.0-1

Git Clone URL: https://aur.archlinux.org/firefox-vaapi.git (read-only, click to copy)
Package Base: firefox-vaapi
Description: Fast, Private & Safe Web Browser (with VA-API patches)
Upstream URL: https://www.mozilla.org/firefox/
Keywords: firefox libva va-api vaapi video
Licenses: MPL-2.0
Conflicts: firefox
Provides: firefox
Submitter: ewout
Maintainer: dcelasun
Last Packager: dcelasun
Votes: 12
Popularity: 0.55
First Submitted: 2023-02-24 13:48 (UTC)
Last Updated: 2025-01-08 09:11 (UTC)

Required by (171)

Sources (7)

Latest Comments

1 2 3 4 5 6 .. 8 Next › Last »

dcelasun commented on 2025-01-08 09:13 (UTC)

Updated to 134.0 which builds fine for me with Python 3.13.1 from the repos.

tendie commented on 2025-01-01 19:33 (UTC) (edited on 2025-01-01 19:41 (UTC) by tendie)

Currently, building fails at:

Installing collected packages: zstandard
Successfully installed zstandard-0.23.0
Traceback (most recent call last):
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/./mach", line 155, in main
    mach = check_and_get_mach(os.path.dirname(os.path.realpath(__file__)), args)
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/./mach", line 39, in check_and_get_mach
    return load_mach(dir_path, mach_path, args)
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/./mach", line 25, in load_mach
    return mach_initialize.initialize(dir_path, args)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/build/mach_initialize.py", line 344, in initialize
    command_site_manager.activate()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 602, in activate
    self.ensure()
    ~~~~~~~~~~~^^
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 563, in ensure
    result = self._up_to_date()
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 800, in _up_to_date
    pthfile_lines = self._pthfile_lines()
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 782, in _pthfile_lines
    PythonVirtualenv(self._mach_virtualenv_root).site_packages_dirs()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 853, in site_packages_dirs
    platlib = self.resolve_sysconfig_packages_path("platlib")
  File "/home/admin/.cache/yay/firefox-vaapi/src/firefox-133.0/python/mach/mach/site.py", line 843, in resolve_sysconfig_packages_path
    relative_path = path.relative_to(data_path)
  File "/usr/lib/python3.13/pathlib/_local.py", line 385, in relative_to
    raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
ValueError: '/usr/lib/python3.13/site-packages' is not in the subpath of '/home/admin/.cache/yay/firefox-vaapi/src/mozbuild/srcdirs/firefox-133.0-f725f8cfd913/_virtualenvs/mach'

---

Note that you are running Mach with Python 3.13.1, which is higher
than the highest known working version of Python for Mach. Consider
running Mach with Python 3.11 or lower.

Running the following command may solve your issue:

    python3.11 ./mach build --priority normal

==> ERROR: A failure occurred in build().
    Aborting...

The message may slightly vary as I installed python311 after my first failed build; without it, the message stating to run mach on python311 doesn't show up.

I can confirm that going into the source directory and building/calling mach with python311 does in fact work and the build process finishes successfully, however I don't know what the steps are to force the PKGBUILD to use python311 as opposed to 3.13 (my guesses are: python311 needs to be a dependency/build dependency and run mach with that version)

I tried by adding an env variable to the PKGBUILD under build() "export PYTHON=/usr/bin/python3.11" but the build process failed with the same error. (In addition to having to delete the built package as yay would fail because src/mozbuild already existed, therefore not reaching the build stage).

I'm guessing I should've changed the actual line where mach is called to explicitly use python311, but since it took quite a while to build and I need to get back to work I can't provide a satisfactory solution to this issue at this time. I will update if I go through with it again and successfully finish the entire install process.

EDITS: redaction/clarity, formatting, punctuation

deemon commented on 2024-12-30 23:16 (UTC)

I was wondering, why there is no HEVC support enabled in about:support? I only see HW decoding enabled for H264, VP9 and AV1; and SW for everything except also HEVC. Although my vainfo seems to show, that I have totally HEVC HW thing supported to some degree?

Trying display: wayland
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 24.3.2-arch1.1 for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.54, 6.6.65-1-MANJARO)
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

deemon commented on 2024-12-28 13:22 (UTC) (edited on 2024-12-30 23:25 (UTC) by deemon)

I noticed a lot of those in the journal: firefox[12302]: Failed to create /home for shader cache (Permission denied)---disabling. Apparently others on "normal" firefox are having the same issue... https://bugzilla.mozilla.org/show_bug.cgi?id=1921742 -- fixed as workaround by putting into /etc/environment MESA_SHADER_CACHE_DIR=$HOME/.cache/mesa_shader_cache. no more spam in logs. :-)

xzntest commented on 2024-12-05 01:19 (UTC)

Need slightly older version of rust, one that uses LLVM 18 instead of 19. Rust 1.81 should work.

Zexal commented on 2024-12-03 09:10 (UTC) (edited on 2024-12-05 17:53 (UTC) by Zexal)

133.0-1 doesn't compile. Any thoughts?

12:20.17 ld.lld: error: ../../../../../x86_64-unknown-linux-gnu/release/libbuiltins_static.a(builtins_static-9340740c376201f4.builtins_static.d4eca79a53e7550b-cgu.0.rcgu.o): Invalid attribute group entry (Producer: 'LLVM19.1.1-rust-1.83.0-stable' Reader: 'LLVM 18.1.8')

EDIT: Thanks to xzntest, realized the issue. Never use rust so I had not idea how rust toolchains are supposed to work. Uninstalled stable and installed last release with LLVM 18 (1.81.1). If its using LLVM from the rust toolchain why doesn't it just use the same LLVM at the final step? Hmm..

Anyways, copy & paste if anyone else is having the same issue (if same arch):

rustup toolchain install 1.81.0
rustup default 1.81.0-x86_64-unknown-linux-gnu
rustup toolchain uninstall stable-x86_64-unknown-linux-gnu
rustc --version --verbose

kikislater commented on 2024-11-25 04:09 (UTC)

@deemon : just comment these lines => 

161 # System libraries
162 ac_add_options --with-system-nspr
163 ac_add_options --with-system-nss

deemon commented on 2024-11-24 10:16 (UTC) (edited on 2024-11-24 10:24 (UTC) by deemon)

For me the build failed on Manjaro, because it complained that my nss is not >=3.105 or something (Manjaro has still 3.104) -- np, will wait until manjaro gets the correct version also sometime later. But it's not even listed as dependency and started building regardless and failed later, when the build process itself didn't have correct version.

kikislater commented on 2024-11-23 05:30 (UTC)

Thank you broller, this is what we need !

broller commented on 2024-11-23 04:45 (UTC)

@dcelasun Oh okay, I understand. Thank you for explaining, appreciate the clarifications a lot!

1 2 3 4 5 6 .. 8 Next › Last »