June 2026 - Arch-general - lists.archlinux.org

Linux 7.1.1 released
by Олег Бобок 20 Jun '26

20 Jun '26

Sorry, I'm newbie to arch linux ecosystem, so definitely not sure if I'm writing this right place. It seems that linux (kernel) package was flagged too early, before the stable 7.1.1 released. Now it is, but, as far as I can see, the linux package maintainers are not aware. There may be other reasons why the package hasn't been accepted for work yet, but I don't know where to read about them. So, the main purpose of this – to re-flag linux package. Sorry for bothering if I had done it wrong

2 1

Higher idle load averages
by SET 20 Jun '26

20 Jun '26

Hello, I am seeing higher idle load averages for kernels above 6.17. This is seen on multiple machines, with both x86_64 and aarch64 CPUs. These machines are really sitting idle and observed for many days. As an example, on a same x86_64 host: $ uname -a Linux localhost.localdomain 6.17.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 23 Oct 2025 18:49:03 +0000 x86_64 GNU/Linux $ uptime 20:25:39 up 2:26, 10 users, load average: 0.02, 0.02, 0.00 $ uname -a Linux localhost.localdomain 7.0.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000 x86_64 GNU/Linux $ uptime 20:39:45 up 10 min, 10 users, load average: 0.08, 0.13, 0.09 It's hard to know if it pertains to the upstream kernel itself, or to Arch's kernel. Of course it's not huge in absolute values, yet higher that what I been seeing for years. I am drawing your attention to this in the hope of a confirmation and perhaps later an improvement. Thanks for considering and regards.

1 0

Re: The certificate for signing /iso/2026.06.01/arch/boot/x86_64/* has expired
by Kusoneko 19 Jun '26

19 Jun '26

Hi, 1) I'd start by actually sending it to Pierre's email address instead of just saying "To pierre(a)archlinux.de" in the message. 2) probably the arch-general list instead of the aur-general list? cc'd both in this reply. Kusoneko. Jun 19, 2026 17:14:58 lao(a)snv0.com: > Hello! > > 1) > To:pierre@archlinux.de[To%3Apierre@archlinux.de] > > The certificate codesigning_pierre_archlinux.pem, used to sign the files `/iso/2026.06.01/arch/boot/x86_64/*` (used for Netboot, https://archlinux.org/releng/netboot/) expired on May 30, 2026, at 16:41:56 UTC. > > Steps to reproduce: > > [user@linuxbox ~]$ wget -q https://geo.mirror.pkgbuild.com/iso/2026.06.01/arch/boot/x86_64/vmlinuz-lin… > [user@linuxbox ~]$ openssl cms -in vmlinuz-linux.ipxe.sig -inform DER -cmsout -print | grep -E 'notAfter:|subject:' > notAfter: May 30 16:41:56 2026 GMT > subject: C=DE, CN=Pierre Schmitz, emailAddress%3Dpierre(a)archlinux.de > [user@linuxbox ~]$ > > 2) > Where should I write instead of Arch-releng (Arch Linux Release Engineering) mail list?

1 0

Proposal for a simplier reporting experience
by Ruby 17 Jun '26

17 Jun '26

In the recent Arch News post, the following was said: […] please reach out to Arch staff via the aur-general mailing list with more information. This is a weird one for me personally. Sure, email probably prevents some spam, and the target userbase is Linux users, so I bet there’s more experienced people, but I really don’t like mailing lists. For something like reporting malicious content, especially for the AUR, where content can be freely submitted by most people, I wish packages just had some form of a “Report as Malicious” button. Trying to send this email, my first one to any of the Arch lists, it took me at least 20 minutes to figure out how. I had to find the link to the mailing list website, I tried the anon subscription, I sent the confirmation email, nothing happened. Tried sending this and got rejected. Then, I tried again. Created an account, got the confirmation email, clicked it, it errored. Refreshed, finally got confirmed. Then it told me that I “have a subscription request pending”. Meaning I have to wait, possibly multiple days, potentially for quite a long while, to even report a package. At this point, I feel like 90% of users would have given up trying to report the malicious content. Which is a big issue - time is key when it comes to fighting bad actors. So yeah, again, I wish packages just had some form of a “Report as Malicious” button. This could either go to an internal list or, if it’s easier to implement, keeping the workflow of moderators, just have it send an automated email from some automatic-reporting(a)aur.archlinux.org or whatever to the existing mailing list. This might require a captcha (like is required for SSO account creation), maybe sign-in, or both, but I do really think a (practically) one-click reporting solution would benefit everyone. People not as familiar or not wanting to interact with mailing lists can report packages, and moderators get quicker reports about malicious packages solely because there’s a greater user base that can report. While I do think the lower barrier of entry also causes some issues, like spam, something like a rate limit and/or verification (such as through login or similar means) should lower this, especially given people could, if malicious, also just spam the mailing list somewhat easily.

3 2

AUR And What Can Be Done Next
by Amal Krishna 17 Jun '26

17 Jun '26

Hi all, Following recent supply chain incidents involving the AUR, I’d like to open a discussion regarding the current "open" submission model. To better defend against supply chain attacks and reduce the maintenance burden caused by low-quality submissions, I am proposing a transition to a batch-based submission system. Instead of the current continuous influx, we could implement a scheduled intake: *Submission Windows:* New packages are submitted throughout the month but held in a pending state. *Designated Review Cycles:* Verification occurs on a fixed schedule (e.g., the first Sunday of each month). *Quality Filtering:* Packages are audited for security and adherence to AUR standards. Non-compliant packages are rejected with feedback, allowing maintainers to iterate and resubmit during the next window. The goal is to create a mandatory "cool-down" and verification period that makes it significantly harder for malicious code to be distributed. While this would be a significant shift in workflow, it seems like a necessary step to address the current security landscape. I am interested in hearing perspectives from the TUs and current maintainers on the feasibility of this approach and whether it aligns with our current infrastructure capabilities. Best regards, Amal Krishna

2 1

Evolution had become unbearably slow
by Ralf Mardorf 16 Jun '26

16 Jun '26

Hi, Evolution has become slower to start up. It takes a very long time to open. Once it's open, it takes a long time for the preview to work. When I try to compose a new email, it takes a very long time for a new email window to open for editing. I started Evolution from the command line, and there was a segfault related to a gst-plugin-lib, with instructions to remove it or on how to debug it. But when I start Evolution now, I no longer get those instructions. Therefore, I am unable to provide any further details on this matter. $ pacman -Q evolution evolution-data-server webkit2gtk-4.1 evolution 3.60.2-1 evolution-data-server 3.60.2-2 webkit2gtk-4.1 2.52.4-1 $ pacman -Q gst-libav gst-plugin-gtk4 gst-plugin-pipewire gst-plugins- bad gst-plugins-bad-libs gst-plugins-base gst-plugins-base-libs gst- plugins-good gst-plugins-ugly gstreamer qt-gstreamer lsp-plugins-gst gambas3-gb-media gst-libav 1.28.4-1 gst-plugin-gtk4 0.15.2-2 gst-plugin-pipewire 1:1.6.6-1 gst-plugins-bad 1.28.4-1 gst-plugins-bad-libs 1.28.4-1 gst-plugins-base 1.28.4-1 gst-plugins-base-libs 1.28.4-1 gst-plugins-good 1.28.4-1 gst-plugins-ugly 1.28.4-1 gstreamer 1.28.4-1 qt-gstreamer 1.2.0-4 lsp-plugins-gst 1.2.29-1 gambas3-gb-media 3.21.6-1 I couldn't find a corresponding bug report on gitlab.archlinux.org or gitlab.gnome.org, hence I’m going to make an exception and cross-post this. Regards, Ralf

5 13

Question about sagemath
by Philippe Delavalade 15 Jun '26

15 Jun '26

Hello. As root, I installed sagemath ; now, the script 'sage' is in /usr/sbin/ ; so when I'm user 'math', I can't access it. Shall I remove package (being root) and reinstalled it as user 'math' or is there a method by, for instance, creating a symlink from /home/math/bin to /usr/sbin/ ? I'm still a newbie for archlinux :-) Regards. -- Philippe

2 2

Questions about archived packages and arch linux malware
by fc26wuqa＠studserv.uni-leipzig.de 15 Jun '26

15 Jun '26

Hello, what is the process in deciding in archiving a package? And what are the reasons? And are there any channels where I can get notified if a package is getting archived? I noticed that the package `vim-airline` and `vim-airline-themes` got archived - I think just recently. Can someone tell me, why that happened? Do packages get archived, because they got malicious? Best, Lucienne

3 3

400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers
by Turritopsis Dohrnii Teo En Ming 15 Jun '26

15 Jun '26

Subject: 400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers Good day from Singapore, Here is an article which I would like to share. Article: 400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers Link: https://cybersecuritynews.com/arch-linux-aur-packages-compromised/ Date of article: 12 Jun 2026 Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Extremely Democratic People's Republic of Singapore 15 Jun 2026 Monday 3.41 pm Singapore Time

1 0

Malware reduction measures ideas
by nathan sasser 14 Jun '26

14 Jun '26

Will note that I'm not familiar with mailing lists. (I'm gen Z and have never touched this before) But looking through this, I have a few ideas, some for the AUR's side, others for the AUR helper's side, and some others that I'm not sure which side would need to contribute to implement it. I'll number these (1),(2),(3) in the order I said them for which side would probably need to work on. (1) 1: My first thought was that for packages that are orphaned and are also EOL or otherwise dropped by upstream i.e. not the AUR publisher, but the developers. The PKGBUILDs should be made read only and unadoptable without confirmation of a fork or the upstream devs picking it back up. Seems extreme I know, but it seems a good amount of the packages that are orphaned there (that aren't git packages) are for packages that are EOL by the original devs or were for stuff that was since merged into mainline versions. (3) 2: as an addendum to idea 1, there needs to be an ability to redirect updates to the mainline package if a fork's features are added to the mainline packages. (2) 3: for the AUR helper's side, some malware analysis pre-step is needed. This could be as basic as a hook for utils like traur or some way to run yara/yara-X scripts on it (yes, I'm aware I or someone else could do that very quickly these days, but testing it might be iffy unless the all clear is given on the AUR's side when it comes to the malware stuff, that and there's no known steps on spinning up a custom AUR like repo it seems, but I'd imagine it's very basic.)

5 4