The only people complaining about the codes of conduct are those who want to be shitty to others.

(from omarchy's doctrine)

Omarchy is bringing that ethos back, and dropping the Code-of-Conduct struggle sessions and identity-overload nonsense that has plagued open source for far too long. We're done with all of it. Just be nice and sincere.

be nice to whom?

Thanks to the Arch team for not accepting this racist's money.

direct link to their resignation letter ☞ https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/2AX2BCJ3EQX7G3YXSDX73BR4NCAWXXBZ/

🤦

It's that time again!

Firefox ESR 140.10.0

Firefox RR 150.0

Relevant for AUR users this time, there is a regression with rustc 1.95^1^ affecting both releases. So those building from source will need to either:

• Ensure they compile with compatible rust version (1.94)
• Apply fix for Bug 2033279
• Use PKGBUILD that sorts it out. firefox and konform-browser have upstream patch ported for RR and ESR, respectively.

Removing ac_add_options --enable-rust-simd from mozconfig might also be a workaround but have not tested that.

^1^: Which is what Arch currently ships.

Why guess? Either use the aforementioned package search or use the internet search engine of your choice and type "arch $name_of_the_software". The matching site for the arch or AUR package is always among the first results.

Well, package search is a thing.

s Would you prefer an electron app instead? /s

I’m all-in for some great GUI for that, by the way. But I think having it as an actual website (so, just redesigning the link) is a great thing to have.

I’d do it sudo pacman -Syu firefox in terminal, and you cannot beat that.

While you're not wrong, and while Arch isn't a particularly forgiving distro for newbies, I'm forever hitting up against trying to guess the name of a package that I want to install via a terminal. Firefox is straightforward, but so many bits of software have names that make sense, but that you couldn't necessarily guess.

I second this, thanks for taking time formulating it. I have never used Cachy, but I assume that’s something you recommend to others as an Arch-like system. I’m not sure it’s worth it for an average Joe, I’d still recommend Fedora. I really like Gnome, I think it’s the best right now, but it needs some more polish, as not everything is newcomer friendly. Yet, those are mostly nitpicks, in general it’s good, I’d say.

for distros like CachyOS this would make sense. But then again Cachy already uses Octopi. Now if this is EASIER to use than octopi and is put at the forefront of CachyOS I can see it being of value. Its' been a few months since I've used CachyOS so I don't know if they now have their own package manager.

Now for someone who has managed to install Arch on it's own then yeah I don't see the benefit of having a GUI Package Manager for Arch. If you've installed Arch it's safe to assume you're already very comfortable in the terminal so why slide backwards and use a GUI? unless you're completely dependent on the mouse...I don't know.

All that being said I can see the benefit of it if you just want to browse for stuff. Sometimes it's just nice to browse in a graphical interface for new and interesting things. I'm not a huge GNOME fan but I do like their GNOME Software package manager and I do use that on Debian based distros like PikaOS.

But the GTK 4 UI is the attraction here, especially for Arch Linux newcomers who want to get things done quickly.

That alone reads as the author of the text wrote the text they wrote just to generate something on the topic. In other words, that article was mostly useless to me, if not for a few screenshots in it.

Quickly is not the appropriate word here. If I’d like to install something, I’d do it sudo pacman -Syu firefox in terminal, and you cannot beat that. Even for a newcomer, especially if they are comfortable with CLI. (As a macOS refugee, I was pretty at home with Linux terminal.) Even when they are not, I personally know non-computer people I guided to open terminal and paste the command, then press enter. Nothing is quicker than that.

What it potentially gives us is the GUI for people who want to do something on their own, without learning even the tiniest bits of new things, like why the fuck Ctrl + C does something weird, and Ctrl + V is not a key for pasting that word they coped with the chat with me.

My take, that would be just another abandonware. Won’t be surprised the whole thing is heavily vibe coded, as much as the 9to5 article. Normally, I don’t even read or comment that. It’s that I think both Gnome and KDE Software App Stores front ends could do better, UX wise. So I was curious about this solution to the problem. Another Synaptic I’ve been trying with Ubuntu like 20 years ago, not really understanding what it does and why. I see no difference here. Not saying nobody needs it, but I don’t see much of an improvement from the first glance. And not much motivation to explore that further. If the author reflects on whys and hows somewhere, I might explore though.

Good. Now when will it default to the eBPF backend?

Discovered it was because I had just updated on system, and

uname -a

was showing a different than version than the following showing my Linux version installed

pacman -Q linux

So I simply had to reboot.

I'm not sure what changed this morning. Maybe a simple reboot fixed it, or another update.

Running the following zcat /proc/config.gz | grep OVERLAY_FS

Shows the following, which I read means the module is available but not loaded.

CONFIG_OVERLAY_FS=m

Even after everything was working, I went to ahead to install linux-headers sudo pacman -Su linux-headers anyways.

I'm able to run the following now without errors from the command sudo modprobe overlay

However I still see CONFIG_OVERLAY_FS=m

When you say rebuild, do you mean rebuild the Podman containers?

This is usually because the overlay module isn't built as a loadable module in your kernel — it's either built-in or not compiled at all.

Check with:

grep OVERLAY /boot/config-$(uname -r)

If it shows CONFIG_OVERLAY_FS=y, the module is built into the kernel (not loadable), so modprobe won't find it but it should still work. Podman just checks incorrectly.

If it's not there at all, you might need to install linux-headers and rebuild, or use a different storage driver like vfs (slower but works everywhere):

# In containers.conf or storage.conf
[storage]
driver = "vfs"

🎉

Yeah, I am using Octopi. I found out Kdenlive needed it, so I couldn't uninstall it. I uninstalled kddockwidgets-qt6 and Kdenlive, installed the other one and all good. Thanks for the help.

Are you using an AUR helper?

Looks like it's trying to update spdlock to version 1.17.0-1, but kddockwidgets-qt6, which seems to be installed from the AUR, requires version 1.16-64. A quick look on the package details page of kddockwidgets tells you that it's actually available from the official repositories since last november (look at the pinned comment). That version is also newer and probably doesn't require an old version of spdlog.

So i'd suppose uninstalling kddockwidgets-qt, installing kddockwidgets from the official repository, and then trying to update again should fix your issue.

Update: Pre-built packages for Debian/Ubuntu (.deb), Fedora/SUSE (.rpm) and others (tarball) are now built and published by Codeberg CI for each release:

https://codeberg.org/konform-browser/source/releases

In one way I think so, yes.

Many people obviously offload trust to the community to some extent, (probably much more than we should, reflected in popularity of helpers like the one you asked for), which involves the AUR discussions and votes, and the Arch wiki.

Sometimes a flatpak or container image, or straight up compiling from instructions, is the easier answer.

Have fun and be careful but curious out there! How obscure AUR packages you will be able deal with safely depends on your level of ambition.

So it's a safety measure for people like me? That implies that I am capable of recognising malicious software. It seems like I've got even more reading to do.

Thank you for the explanation.

Ah thanks, I'll look into that.

Read https://wiki.archlinux.org/title/Arch_User_Repository

"Installing from the AUR" usually means:

• Cloning the AUR repo
• Installing build dependencies
  • If any of those are AUR packages, recursively repeat
• Download source files from arbitrary online location
• Run arbitrary commands to build
• Pack it all into a tarball
• pacman -U the tarball

Anyone can easily register and upload AUR packages in seconds or minutes.

This makes it a high-risk vector for malware and there is indeed malware uploaded to the AUR all the time. Looking at the NPM malware development, the increased popularity of Linux, and the already ongoing cyberattacks on AUR itself, this will only get worse.

The idea is that you are expected to manually inspect and vet the PKGBUILD yourself by doing these steps before you run makepkg itself. With great power comes great responsibility. Developers realize that it is not responsible to make a tool specifically designed to make dangerous behavior and explicitly bypassing safeguards, stopgaps and best-practice protocols more convenient than the alternative, when it will be targeted to uneducated users.

As wltr mentioned, there are helpers, but you really should pick one that involves that manual inspection (like aurutils), and after becoming comfortable enough with git+makepkg+pacman to make it routine.

TLDR: If you can't or won't vet PKGBUILDs of AUR packages you shouldn't be blindly installing them.

Because it’s not really safe to install random unverified software. You’re supposed to review the make file before running it.

However, there are helpers, look for paru or yay, then it’s as simple as installing with pacman.