Skip to main content ↑ ↓
Topic: Issues with AUR updates and pamac (Read 1157 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Issues with AUR updates and pamac

I'm not sure if AUR related stuff is fine to post in the software/application support part of the forum. On one hand, it's Software/Application related, on the other hand, Artix doesn't personally curate the AUR packages...

Lately, I've noticed that pamac isn't updating with all of the available updates for packages. I also see errors when updating my AUR packages saying it couldn't lock or update the database...I usually update everything through the terminal, but I like being able to glance at all the packages that need to be update without putting in my password.

Today I was trying to update Librewolf and it took up the entirety of my processor's resources and caused my computer to freeze. Looks like gkrust (lib) is related to the issue. I waited for almost an hour for nothing to happen.

Code: [Select]
24:22.60 error: could not compile `gkrust` (lib)
24:22.89 Caused by:
24:22.89   process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust toolkit/library/rust/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type staticlib --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -Clto --cfg 'feature="mozilla-central-workspace-hack"' -C metadata=2d52629e4486950c -C extra-filename=-2d52629e4486950c --out-dir /home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/build/cargo-linker -L dependency=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/release/deps --extern gkrust_shared=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-b942d6dec88e437b.rlib --extern lmdb_sys=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/liblmdb_sys-32649512d6ee599f.rlib --extern mozglue_static=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libmozglue_static-9cbe01fe3768dd68.rlib --extern mozilla_central_workspace_hack=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-ac742912eada0b74.rlib --extern swgl=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libswgl-45ab1c052a6e3176.rlib -C debuginfo=2 --cap-lints warn -Cembed-bitcode=yes -C profile-generate=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu -C codegen-units=1 -L native=/usr/lib -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/build/audioipc2-f84b40266bbbb5c8/out -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/dist/bin -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/nss/nss_nss3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/ssl/ssl_ssl3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/config/external/nspr/pr -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/build/lmdb-rkv-sys-4a4d0988f9e39642/out -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/build/mozglue-static-08e4c02c0a134cb5/out -L native=/usr/lib -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/dist/bin -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/nss/nss_nss3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/ssl/ssl_ssl3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/config/external/nspr/pr -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/dist/bin -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/nss/nss_nss3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/security/nss/lib/ssl/ssl_ssl3 -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/config/external/nspr/pr -L native=/home/yousername/source-code/librewolf/src/librewolf-117.0-1/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/build/swgl-fc09d8933086a11b/out` (signal: 9, SIGKILL: kill)
24:26.14 make[4]: *** [/home/yousername/source-code/librewolf/src/librewolf-117.0-1/config/makefiles/rust.mk:442: force-cargo-library-build] Error 101
24:26.73 make[3]: *** [/home/yousername/source-code/librewolf/src/librewolf-117.0-1/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
24:26.73 make[3]: *** Waiting for unfinished jobs....
25:27.76 make[2]: *** [/home/yousername/source-code/librewolf/src/librewolf-117.0-1/config/recurse.mk:34: compile] Error 2
25:27.76 make[1]: *** [/home/yousername/source-code/librewolf/src/librewolf-117.0-1/config/rules.mk:361: default] Error 2
25:27.84 make: *** [client.mk:60: build] Error 2
25:27.86 W 19 compiler warnings present.
==> ERROR: A failure occurred in build().
    Aborting...

quakespasm is having an issue as well where it wanted to downgrade a bunch of packages to update itself including Ungoogled Chromium for some reason?... I was trying to update it like when I had an issue with dsda-doom where I needed to clone the repository again and build it that way, but it was doing this for both AUR packages. I also was getting "unable to lock or update database" errors

I had written some more stuff but somehow undo decided to hear me loud and clear and revert to my first draft... So, I hope I covered everything I wanted to ask about.

Re: Issues with AUR updates and pamac

Reply #1 –
Quote from: TuxPenguino – on
I'm not sure if ...

Obviously you want to have problems on a regular basis, otherwise I can't explain why you and all the other questioners constantly make lazy compromises.
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Issues with AUR updates and pamac

Reply #2 –
The Package Management board has an AUR packages sub board. Have you tried rebuilding Pamac, it could have been affected by something else that it depends on getting upgraded? There is a librewolf-bin package in the AUR, unless you have some reason to build it from source that's going to be the best option as it's prebuilt.
I tried to build librewolf here and disabled the PGO builds to save time, but it failed like your attempt - error: could not compile 'style' (lib) process didn't exit sucessfully: 'usr/bin/rustc ...blahblah ...'  warning: build failed, waiting for other jobs to finish - and the other threads hung at 100% CPU so I hit ctrl C. A rust problem? Don't know.
This also changed in the librewolf PKGBUILD when 116 was introduced:
-ac_add_options --enable-lto=cross
+ac_add_options --enable-lto=cross,full
https://aur.archlinux.org/cgit/aur.git/commit/?h=librewolf&id=3a2f93dbb9f8628b651edb2665690cd5918405fa
I think the build is currently failing before linking though.

Re: Issues with AUR updates and pamac

Reply #3 –
gkrust is the most memory intensive part of any firefox build. It's entirely possible that you're just running out of memory because it's garbage like that. I think this was the problem Artist was having with later librewolf versions.

Re: Issues with AUR updates and pamac

Reply #4 –
I found a mistake in my fstab, swap wasn't enabled and I hadn't noticed before, which was probably why it failed, due to lack of memory, as you said. With PGO = false,  and reverting to --enable-lto=cross, 8GB RAM and a 16GB swap partition on the NVME drive actually enabled this time it built OK, peak RAM usage was a bit over 16GB during the gkrust bit, with 4 cores hence 4 threads, although top -c was showing most of the RAM usage was by rustc with 3 other clang threads not using that much in comparison.
I don't know if it would use more memory with --enable-lto=cross,full having enabled swap, but it took so long on my hw I'll settle for having found one working build config  ;D
(This was building librewolf 117.0-1 from the AUR librewolf PKGBUILD, in case that was not clear.)

Re: Issues with AUR updates and pamac

Reply #5 –
Lucky you, with my 16ram, zram and another 16 of swap the memory gets awfullly utilized still. :-) Although i use all 16 threads, i should retry with just 4 someday when i'll try to refork the mozilla forks myself.

Re: Issues with AUR updates and pamac

Reply #6 –
The first time I tried it went to the gkrust part without issue, then failed. Next time it almost froze before it got that far, I could see at that point there were 2 rustc processes, one compiling style, another webrender. Memory usage was nearly 8GB and I saw kswapd at the top of top, keeping things going even without swap, but slowing things down, so then I did swapon which rescued the build. You could see the rustc things gradually using more and more memory until they moved on to the next part, so if several of those were running at the same time it might use more, and there could be an element of chance what coincides.  Using half the available threads only extends build times by 30% or so due to dark silicon where I have tried that. The Pale Moon devs recommended not using swap for building Pale Moon in various discussions, they said it could potentially cause bugs in the resulting browser due to the complex build procedure and the proper solution was get more RAM if needed instead.

Re: Issues with AUR updates and pamac

Reply #7 –
Quote from: Dudemanguy – on
gkrust is the most memory intensive part of any firefox build. It's entirely possible that you're just running out of memory because it's garbage like that. I think this was the problem Artist was having with later librewolf versions.

I see. That makes sense. This system is pretty old. I'm not sure how I managed to install Librewolf before this update was available. I know it is something I hadn't run into before.

Quote from: Hitman – on
Lucky you, with my 16ram, zram and another 16 of swap the memory gets awfullly utilized still. :-) Although i use all 16 threads, i should retry with just 4 someday when i'll try to refork the mozilla forks myself.

I'm working on building a new high end PC and I'm considering just maxing out the ram to 128 GB. I was having issue on another system with Swap so I didn't put a swap partition for this current machine.

Quote from: ####### – on
The Package Management board has an AUR packages sub board. Have you tried rebuilding Pamac, it could have been affected by something else that it depends on getting upgraded? There is a librewolf-bin package in the AUR, unless you have some reason to build it from source that's going to be the best option as it's prebuilt.
I tried to build librewolf here and disabled the PGO builds to save time, but it failed like your attempt - error: could not compile 'style' (lib) process didn't exit sucessfully: 'usr/bin/rustc ...blahblah ...'  warning: build failed, waiting for other jobs to finish - and the other threads hung at 100% CPU so I hit ctrl C. A rust problem? Don't know.
This also changed in the librewolf PKGBUILD when 116 was introduced:
-ac_add_options --enable-lto=cross
+ac_add_options --enable-lto=cross,full
https://aur.archlinux.org/cgit/aur.git/commit/?h=librewolf&id=3a2f93dbb9f8628b651edb2665690cd5918405fa
I think the build is currently failing before linking though.

The first time I tried it went to the gkrust part without issue, then failed. Next time it almost froze before it got that far, I could see at that point there were 2 rustc processes, one compiling style, another webrender. Memory usage was nearly 8GB and I saw kswapd at the top of top, keeping things going even without swap, but slowing things down, so then I did swapon which rescued the build. You could see the rustc things gradually using more and more memory until they moved on to the next part, so if several of those were running at the same time it might use more, and there could be an element of chance what coincides.  Using half the available threads only extends build times by 30% or so due to dark silicon where I have tried that. The Pale Moon devs recommended not using swap for building Pale Moon in various discussions, they said it could potentially cause bugs in the resulting browser due to the complex build procedure and the proper solution was get more RAM if needed instead.

I found a mistake in my fstab, swap wasn't enabled and I hadn't noticed before, which was probably why it failed, due to lack of memory, as you said. With PGO = false,  and reverting to --enable-lto=cross, 8GB RAM and a 16GB swap partition on the NVME drive actually enabled this time it built OK, peak RAM usage was a bit over 16GB during the gkrust bit, with 4 cores hence 4 threads, although top -c was showing most of the RAM usage was by rustc with 3 other clang threads not using that much in comparison.
I don't know if it would use more memory with --enable-lto=cross,full having enabled swap, but it took so long on my hw I'll settle for having found one working build config  ;D
(This was building librewolf 117.0-1 from the AUR librewolf PKGBUILD, in case that was not clear.)

Okay, thank you for the reply! I realize now there's a subsection of the forum for AUR packages. I apologize for the mistake. That makes sense, I learned a lot from your post. If that is the case, I'm not sure why I had the source version rather than the bin version.

Speaking of swap, I was having an issue with another system where if it went to sleep and woke up later, the swap usage would be maxed out despite the system having plenty of physical RAM that wasn't being used. So, on my system I'm currently using I don't have a swap partition. This set up was not really meant to be used for longer than a few months, I'm just waiting for the parts for my new system at this point.

Re: Issues with AUR updates and pamac

Reply #8 –
@TuxPenguino Good idea to put lots of memory in the pc as long as it's cheap enough, maybe try 64 first if it's more affordable.
I'd still recommend using virtual zram/zswap as it's compression will help with leaked memory that would otherwise be wasted. Keep swappiness down of course like 20 instead of the default 60, maybe will help you now too.