cross-posted from: https://feddit.org/post/23120439

Some people might look for alternatives to using AUR for common packages, for example because they don't have the competence to review PKDBUILD scripts for malicious code, or maybe because they simply do not have the time. The Guix package manager might be an alternative for these, as it now supports 31000 packages - significantly more than the Arch distribution. So, for popular packages, chances are good that your package is covered by Guix.

But what is Guix? Here, a summary of key features and decisions of Guix:

1. Guix includes a package manager that can run on top of Linux distributions like Debian or Arch (I use it successfully for both) or other POSIX systems, like cargo, pip, conda or Conan. In difference to the pip and cargo package managers, it is language-agnostic, supports many different build systems and languages.
2. Guix allows to define a fully reproducible system. This works by using a declarative language for immutable version-controlled package descriptions, and by deriving any software from package definitions and a fixed version (commit hash) of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code and build recipes - and all inputs to the system are open source and can be reviewed. This gives also some important protection against malware: An altered cached, binary package would not match the hash of the package's source code, its package definition, and the recursive hash of its dependencies.
3. Important for programming, this can also define isolated build and development environments, like Python's venv, but also Docker containers. This means that Guix can be used to develop, build, package, and deploy software, very much like Snap packages. And that's independent from the distribution you work in, very much like pip or cargo are independent from the system you work in. (And yes, it supports Rust!).
4. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free forks of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can't happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions as a complement to GNU Guix. Non-free packages for Guix do exist, in the same way as you can buy and run Steam Games software for Linux. Such non-free software just can't become part of the official Guix distribution, just like Amazon or Apple can't sell their non-free software via Debian or the Linux kernel project (or, for that matter, Apple has no obligation to market and distribute, say, Oracle products).
5. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson's "Trusting Trust" problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online -- certain companies don't seem to like it).
6. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
7. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software, but more importantly, whole user configuration, is written in Emacs Lisp.
8. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
9. Also worth noting is that the Guix project has superb online documentation. This is a practical advantage compared to Nix.

As example: you quickly want to try a recent version of a modern Scheme, say Guile 2 or Guile 3, or kawa (which runs on the JVM, like Clojure, see https://www.gnu.org/software/kawa/). Or of the interesting vis editor, a spin-off of Rob Pike's sam (https://github.com/martanne/vis). But you can't use the AUR packages, since AUR only supports Guile 1.8, and / or you don't have time to review the PKGBUILD and all its dependencies, and vis is simply not in AUR. Here, Guix helps out! Just type

guix install guile
guix install kawa
guix install vis

and bang you have it!

Disadvantages

• Guix generates packages from source. This means the package definition and a hash of the source code is hashed, and compared against cached packages. If it is available as a compiled package, it is retrieved. In other cases, Guix might need to compile the package and its dependencies. This is slower than using pacman. But if you only use it for the few packages you can't find in Arch, this should not bother you much. The advantage is that it is fully automated.
• Guix is not a good choice for installing proprietary binary drivers. This is due to its primary design choices. In this case, Nix might be a better alternative. (Or, you just get good Linux-compatible hardware, which can definitely avoid a lot of grief and head-scratching!)

How it works:

https://codeberg.org/guix/guix#headline-4

Manual:

https://guix.gnu.org/manual/en/html_node/Installation.html

For using Guix as a package manager under Arch, see:

https://wiki.archlinux.org/title/Guix

Ouch.

Just tried looking up an aur package via the Site and both Paru and the Site gave me an 500 Internal Server Error :(

Anyone know by Chance when AUR will be back up again? >.>
or are there AUR Archives by Chance i can get stuff from for now while its down? O.o

Thanks for the Help ^^

I've noticed that there are notifications now if a programme is taking too much ram and the kernel kills it.

Were they there before or it's an update from the DE or notification manager.

I having a hard time updating my arch-based computer because the downloads are so painfully slow. It takes hours and hours. Eventually some kind of error happens and Ive already left my computer to do something else so the task times out. Or download stalls to nothing and the process kills itself.

I have already adjusted the settings in yay to be more tolerant of slow connection, but can hardly ever manage to complete the upgrade. And the longer you wait, the more updates there are.

Does anyone else have this issue? I don't have a great connection but this is ridiculous. I do have a VPN running on router. This could be affecting it as github in particular seems to make downloads a slow trickle on certain VPN endpoints but lately I can't find any that satisfy it.

I start at least 1 upgrade task every day, sometimes multiple attempts but I have only had 1 successful full system upgrade in the past 2 or 3 weeks.

Edit: Solution was just switching to Proton 9.

This is a weird one involving many moving parts, so I'm looking for some pointers on where I can even start trouble-shooting:

• When I open My Summer Car (on Steam) in fullscreen mode, the keyboard doesn't work in game.
• When I start it in windowed mode, it works normally.
• When I then select full screen in the window menu, it works partially (some buttons in game don't react).
• Other games I tested have no issue.
• It works fine on Debian, but the issue is present on more bleeding edge distros (tested Arch, Endeavor and Bazzite)
• Flatpak or native Steam makes no difference
• Only tested KDE Plasma with Wayland

My best guess is that the issue is related to Wayland somehow, and that the game doesn't mesh with the newer Plasma version, but I'd love to know if there's a way to troubleshoot or work around this.
Thanks in advance!

Whatsapp web doesnt have critical feature like calls, is there any way to get whatsapp desktop on arch?

I'm not very bright so I'm feeling pumped :P grub wouldn't play nice with dual boot of other distros, realised I couldnt find a text editor to make the DE work, but we got there In the end and it turns out it's true what they say, you learn a lot.

“PacHub provides a GTK4/libadwaita GUI for pacman and AUR, so you can avoid the terminal. PacHub can install/uninstall packages, perform upgrades, and provide

Keeping up with security updates for your web browser is of increasing practical relevance. Under normal conditions this means important updates roughly every couple of weeks.

Mainline firefox or chromium packages are typically easy mode: For most people it's a matter of staying on top of regular pacman updates. torbrowser-launcher updates from inside the browser and is also usually painless to manage.

Running custom builds or forks from AUR requires more attention. Is the AUR package up to date? If it's a fork: Are security updates from Mozilla/Google downstreamed in a timely manner? Have you built it? Can you still build it? How long since you pulled and rebuilt that ungoogled-chromium binary and how many CVEs has it racked up by now?

Anyone running firefox-esr or any derivative like icecat, waterfox^1^, mullvad-browser or konform-browser from AUR should probably be paying attention to this right now:

Arch Linux repositories updated llvm and clang to v22 on 2026-03-07. This caused a regression for Firefox ESR packaging resulting in compilation failure when building.

Firefox ESR 14.9.0 was released on 2026-03-24.

This means that since then, users of the AUR packages for these browsers have not been able to build a new version with security fixes on up to date Arch Linux system. Some users may be prepared to handle this by maintaining separate build infra with internal registry where keeping system packages frozen on older version is acceptable but for everyone else, this is a conundrum.

Anyone browsing the web on firefox-esr or a derivative should make sure you get fixes for the issues addressed in 140.9.0 asap.

konform-browser AUR package has been patched with clang 22 toolchain fixes from mozilla and should now build succesfully. The other forks including firefox-esr will still need manual patching or downgrading clang toolchain packages to v21 to compile. The konform-browser patches for clang 22 are in the AUR repo and should be portable to the other browsers too. If others can share their results in testing (both X11 and Wayland) or reviewing the fix, this might help in sorting out the firefox-esr situation sooner than later, too.

^1^: Looking at git log it claims to build as of the wasi-compiler-rt21 makedepends but I have still not been able to make it compile when attempting. Please LMK if I'm holding it wrong and there is a way!

Announcement brought to you by Konform Browser

I have a basic firewall, but did not use App Armor, SELinux, or kernel blacklists. I definitely shut down port 22 just for now. It's just a laptop daily driver. Should I do more?

Also, I'm now addicted to Arch. I'm using Hyprland with it. This means I've got two bleeding edge wares and that gets rough sometimes when things break. I want Arch on my desktop gaming rig though. I tired other distros but I just love Arch. Has anyone tried using Ansible to manage multiple installations? I really can't maintain two so I was wondering if Ansible would make it easier, especially for updating.

cross-posted from: https://sh.itjust.works/post/56239562

Hello, I have been trying to get my drivers to play more nice with my hardware. When I originally installed Arch, it automatically installed the nouveau driver which mostly worked. However I was having issues with some windows rendering with big white boxes and a couple random crashes of the OS.

After looking into fixes I was recommended to swap to nvidia drivers, and I followed a guide to install the AUR nvidia-470xx-utils. But this completely broke my drivers. Luckily I was able to use TTY to revert these changes and got the nouveau drivers reinstalled.

With that background out of the way, I'm now dealing with some new issues. After logging in it now takes much longer to load the desktop and my whole system will randomly reboot. I'm hoping someone can point me in the right direction.

I am happy to post any more info or clarify points, I'm still very new to a lot of this.

Here is my gpu readout when I run lspci -v:

01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Device 00fc Flags: fast devsel, IRQ 16 Memory at c0000000 (32-bit, non-prefetchable) [size=16M] Memory at 90000000 (64-bit, prefetchable) [size=256M] Memory at a0000000 (64-bit, prefetchable) [size=32M] I/O ports at 2000 [size=128] Expansion ROM at c1000000 [disabled] [size=512K] Capabilities: Kernel modules: nouveau, nvidia_drm, nvidia

Why is nftables a dependency for docker? I thought docker used iptables for networking? Also I didn't think you were supposed to have nftables and iptables installed at the same time so should I now replace iptables with iptables-nftables?

Hey everyone,

So I did my usual weekly system update with paru -Syu this morning. The update went through normally. nothing major, no core packages, Nvidia, or Plasma updates from what I could tell when I glanced at the packages. I also checked the Arch news beforehand to see if anything required manual intervention and there was nothing.

I went ahead and rebooted and tried logging into a Wayland session from SDDM, and it froze on the desktop immediately. Couldn't even get into a TTY from there.

This issue is somewhat familiar and has happened to me before. Usually, it’s fixable by rebooting or unplugging and plugging back in an external monitor. So I did a forced reboot (holding power) and tried again same freeze. Tried once more, still the same.

Then I booted into X11, logged in, and initially it seemed fine. I resized the scaling to 125% (it was at 100%), logged out and tried logging back into x11 and it froze again.

I had no idea what broke. I ended up going into TTY from GRUB and restoring a Timeshift snapshot from a day ago. After that, I could log in normally again.

Has anyone else run into this issue?

PS: I wanted to check the journal and debug it, but I had to catch a bus for vacation, so my laptop is at home. Will try to investigate more later.

cross-posted from: https://programming.dev/post/45148310

Supac is a declarative package manager written in Rust fully scriptable in nushell. It's meant to make it easy to use the native package managers in existing distros without going through the associated headaches of using Nix, while maintaining the ergonomics of structured data in nushell.

Currently supported backends are:

• Archlinux and derivatives
• flatpak
• cargo/cargo-binstall
• uvx (packages only for now)
• rustup toolchains

I daily drive it, and it works well. Feel free to give it a try!