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

Pacman and NPM conflict
by Sudarshan Srivatsan 28 Apr '26

28 Apr '26

Hello everyone, I had installed extra/zed recently, and it depends on npm and Node.js. Every time npm is updated in the repositories, there are always file conflicts. For now, I have been appending '--overwrite="*"', but I know that is not best practice. I also know that Zed pulls other packages directly via npm. Is there any way to prevent this, or is Zed/npm the issue, and nothing can be done except a request upstream? Sudarshan

2 1

Re: (optional) AUR helper in archinstall
by Óscar García Amor 25 Apr '26

25 Apr '26

Please forgive me for playing devil's advocate here, but I see that many of you are strongly opposed to adding an AUR helper to archinstall because “AUR packages shouldn't be in official repositories,” and yet we have aurpublish [1] in the extra repository. In my opinion, having some AUR helpers maintained as extra packages (such as paru or yay, which are the most widely used) is just like any other package maintained in the extra repository, and having them there would certainly make life easier for many users, since they wouldn’t face the chicken-and-egg problem when they start using AUR. I think a simple notice stating that this is no longer supported and that you use it at your own risk is sufficient. Ultimately, it’s about making life easier for the user. Greetings. [1]: https://archlinux.org/packages/extra/any/aurpublish/ -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

15 32

python-dbus-deviation failure to build
by Pocket 25 Apr '26

25 Apr '26

I am trying to build python-dbus-deviation It fails and this is from the build log, and it appers to have not gotten to the check() function * Getting build dependencies for wheel... <string>:59: SetuptoolsDeprecationWarning: The test command is disabled and references to it are deprecated. !! ******************************************************************************** Please remove any references to `setuptools.command.test` in all supported versions of the affected package. This deprecation is overdue, please update your project and remove deprecated calls to avoid build errors in the future. ******************************************************************************** !! ERROR Missing dependencies: sphinx roman-numerals>=1.0.0 ==> ERROR: A failure occurred in build(). Aborting... ERROR Missing dependencies: sphinx I am building in a clean chroot as per the wiki on that subject I am using the PKGBUILD file from the git packaging repos all the depends and makedepends are installed into the chroot Can someone help me debug this and get to the bottom of this? -- Hindi madali ang maging ako

4 10

Re: (optional) AUR helper in archinstall
by Sudarshan Srivatsan 24 Apr '26

24 Apr '26

I feel the only justification for including an AUR helper in Archinstall would be for legacy drivers. But even then, there are other ways to accomplish this. Sudarshan

1 0

Re: (optional) AUR helper in archinstall
by Jonathan Isom 24 Apr '26

24 Apr '26

On Fri, Apr 24, 2026 at 5:00 AM Andrei Korshikov < andrej.s.korshikov(a)gmail.com> wrote: > "No" (for non-technical reason): > For me it looks like an encouragement or even invitation to use AUR > directly, which -- in an ideal world -- should be avoided (see > kpcyrd's letter above). > > "Yes" (for non-technical reason): > Newcomers will use AUR anyway, so it's a good opportunity to educate them > a bit. > > > users not aware of the risks, should be clearly informed of the "dangers" > > For me "cleary informed" means not just using general non-informative > waringns "not officially supported" and "use at your own risk", but > some explanations like in the mentioned kpcyrd's letter. I.e. users > should be aware of all that .so dependency business and Python > troubles, and understand that they do not use Arch Linux anymore, but > some kind of their own "Arch Linux downstream" distribution. > > Importance of paru's "localrepo" and "chroot" features (and similar > features in other helpers if/when they will be added to archinstall) > should be explained too. > > "I don't care": > I customize ISO (because I need ZFS kernel modules up and running), so > I already have AUR helper on it just in case:) And it is not really > needed anyway, because I use local repository (at least, for packages > which are important for me) to avoid troubles with dependencies. > > --- > Andrei > Regarding the staff discussion of “(optional) AUR helper in archinstall” For the NOs, would the aurutils scripts package be more of a yes? It only does fetching, searching and a few other tasks. The user would still have to fetch a package, makepkg it and install it. I have a wifi card that currently isn’t upstream in the kernel, but hopefully will in kernel 7.1 or 7.2. This would save quite a bit of searching and typing to install drivers that may still be not upstreamed, but available and still have an increased difficulty level compared to something like yay or paru. This could be a patched version that has a notice at the end of all actions that says something to the extent of “Arch User Repository is unsupported ArchLinux and its use can result in broken updates and systems. It is only included for the use of drivers that are not upstreamed yet. Use at ones own risk”. Maybe in red. Thanks J

1 0

Request: move AUR package "ruffle-nightly-bin" to official "extra" repository
by EpicTux123 24 Apr '26

24 Apr '26

The package https://aur.archlinux.org/packages/ruffle-nightly-bin seems to be officially maintained ("ruffle" account), and it has also been in a good shape since many months now. Ruffle is an Adobe Flash Player emulator. Since the death of Adobe Flash Player, it has been the best way to run old Shockwave Flash (SWF) files. Website: https://ruffle.rs/ Repository: https://github.com/ruffle-rs/ruffle Build instructions: https://github.com/ruffle-rs/ruffle#building-from-source I'd like to ask for this package to become an official package on Arch Linux, because it is cool. :) I've also CC'd the maintainers of the AUR package in this e-mail. Thanks. -EpicTux123

1 0

Issues booting after kernel upgrades
by Lucie Scarlet 23 Apr '26

23 Apr '26

Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. Does anyone have tips for how to potentially fix this? /Lucie

11 18

FSF librelocal meetup in London
by Polarian 21 Apr '26

21 Apr '26

Good afternoon, Not really sure where the best place to put this would have been, however I felt it would be useful to share this with the community because arch is a FOSS project. See [1] for the information on the meetup, and if you are outside of the UK, there are other local meetups [2] which you might be able to attend. I only know the info about the UK one as I live here. Enjoy! Disclaimer: I am not the organiser. Take care, -- Polarian Jabber/XMPP: polarian(a)icebound.dev [1] https://mailman.lug.org.uk/pipermail/gllug/2026-April/083787.html [2] https://libreplanet.org/wiki/Group:Librelocal/2026

1 0

I have successfully compiled and installed the latest Linux Kernel 7.0.0-1-mainline in Arch Linux 2026.04.01
by Turritopsis Dohrnii Teo En Ming 21 Apr '26

21 Apr '26

Subject: I have successfully compiled and installed the latest Linux Kernel 7.0.0-1-mainline in Arch Linux 2026.04.01 Good day from Singapore, I had started performing a fresh new installation of Arch Linux 2026.04.01 on 17 Apr 2026 Friday at 6.08 pm Singapore Time. But I have not installed a GUI environment yet. I shall do that later. My main objective is to install the latest Linux Kernel 7.0.0-1-mainline first. At 7.47 PM on 17 Apr 2026 Friday, I had started compiling Linux Kernel 7.0.0-1-mainline from source code using yay. At 3.18 AM on 18 Apr 2026 Saturday, I have successfully compiled and installed Linux Kernel 7.0.0-1-mainline. The entire Linux Kernel compilation process took 7 hours and 31 minutes. Although my Arch Linux 2026.04.01 virtual machine has 4 CPU cores and 8 GB RAM, I made the mistake of forgetting to configure the Linux Kernel building process to use 4 CPU cores. I am using VMware Workstation Pro 25H2 version 25.0.0.24995812. To make the building process use 4 CPU cores, you need to edit the makepkg.conf file. This file controls how yay and makepkg handle compilation. $ sudo nano /etc/makepkg.conf Find the line that says MAKEFLAGS. It is usually commented out with a # at the beginning. Change it to look exactly like this: MAKEFLAGS="-j4" Note: Make sure to remove the # from the start of the line so the setting becomes active. The -j4 flag tells the compiler to run 4 parallel jobs at once. Since my previous build took over 7 hours on 1 core, this setting should cut that time down to roughly 1.5 to 2 hours for future updates. Note: Ensure you have assigned at least 8GB of RAM to your VM before using 4 cores, as each build job requires its own memory. As I have grossly forgotten to make the above changes, in the end my Linux Kernel 7.0.0-1-mainline building process took 7 hours and 31 minutes on only 1 CPU core. You may like to watch my YouTube videos on how I have successfully compiled and installed the latest Linux Kernel 7.0.0-1-mainline in Arch Linux 2026.04.01. [01] YouTube video: Compiling Linux Kernel 7.0 on Arch Linux 2026.04.01 Link: https://www.youtube.com/watch?v=qW2s468y6hs [02] YouTube video: Successfully compiled and installed Linux Kernel 7.0.0-1-mainline in Arch Linux 2026.04.01 Link: https://www.youtube.com/watch?v=LrtQTcC4rQo I will be testing the latest Linux Kernel 7.0.0-1-mainline for stability and for any bugs. I will also be installing a GUI environment in Arch Linux 2026.04.01 soon. Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Extremely Democratic People's Republic of Singapore 18 Apr 2026 Saturday 9.51 am Singapore Time

3 2

Bring ARM into the fold?
by Christer Solskogen 20 Apr '26

20 Apr '26

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

14 27