So recently Arch bumped the Linux LTS kernel from 6.12.x to 6.18.x. Good news. But I wanted to stick around with 6.12.x. Irrationally have grown fond of it. So went down the AUR route tried to install the LTS Kernel 6.12.x. The command that I gave to install LTS 6.12.x was yay -S linux-lts612
On the way I did some tweaking of the file $XDG_CONFIG_HOME/pacman/makepkg.conf. The two main changes that were to put in are, -march=native -mtune=generic in CFLAGS and also enable lto in the OPTIONS flag. lto is for link time optimization. Wanted to have the Kernel built for my specific host and tuned for my specific host too.
Oh boy oh boy, did I not realize what I was getting into. It took freaking 10 hours to compile, while I was doing something else on the computer, used up whole RAM and then failed because the filesystem got full. The whole RAM was consumed, with only 312KB left as free.
Why oh why did the Arch team not build and keep the 6.12 LTS kernel in the extra repository as the linux-lts612 package? Is it too much to ask by mere mortals?
And more importantly how do I get it to compile under say 1-2 hours. Otherwise any AUR update and bamn I am stuck with LinuxLTS kernel getting compiled for over 10 hours.
You should probably remove -mtune=generic, as that tunes it generically, not specifically to your CPU. You have -march=native which tunes it to your specific CPU already, and that’s the one you want to keep.
The real game changer for compile times is parallel compilation. Make sure your MAKEFLAGS in /etc/makepkg.conf are set as this, to fully utilise all processors :
MAKEFLAGS="-j$(nproc)"
See more details on optimisations here (although we’ve covered most of the relevant ones):
The reason that I gave -mtune=generic was because I read on StackExchange or one of the blogs that in Gentoo Forums there was a claim that giving -mtune=generic along with -march=native helps in creating binaries and libraries which are a few percentages more faster and optimized.
Will have a look at it. But does that mean, I will not be able to multi task while this is happening, since compilation will take up all the CPU cores? Also the build failed after 10 hours when I tried it.
I would strongly recommend setting up Chaotic AUR. It’s got tons of pre-compiled behemoths, like kernels and web browsers. The 6.12 kernel was just added today.
I guess you can specify an amount that’ll leave you a core or two for other tasks? I haven’t tried it, but presumably this would reserve 2 processors for you?:
I will try first with MAKEFLAGS="-j$(nproc)" and then MAKEFLAGS="-j$(nproc - 2)". Maybe I will have to keep my updates limited to weekend nights then. I wanna bring the compilation down to a few hours, 2-3 hrs max. Not 10 hrs and counting.
And to think I was thinking to take up Kernel compilation for tweaking, so that I only compile in the kernel the drives for the filesystems, CPU, GPU that I use. For example I do not have nvidia stuff so I would keep it out along with other unnecessary items.
It may be an interesting adventure, but I’m not sure you’d find all that much real-world performance benefit from it, particularly given the time and power involved in needing to compile it yourself.
Maybe if it was for a super lean system? But then, a super lean system is probably going to struggle to compile it natively
Mainly for kernels. Here’s my /etc/pacman.conf with the repos:
[endeavouros]
SigLevel = PackageRequired
Include = /etc/pacman.d/endeavouros-mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
[chaotic-aur]
Include = /etc/pacman.d/chaotic-mirrorlist
Since regular AUR packages are always installed last, the order-of-preference should be fine. Sometimes you’ll show packages that are installed from multiple repos, like this example with downgrade:
$ yay -Ss downgrade
aur/downgrade 12.0.1-1 (+876 9.79) (Installed)
Bash script for downgrading one or more packages to a version in your cache or the A.L.A.
chaotic-aur/downgrade 12.0.1-1 (30.0 KiB 83.6 KiB) (Installed)
Bash script for downgrading one or more packages to a version in your cache or the A.L.A.
endeavouros/downgrade 12.0.1-1 (38.6 KiB 83.6 KiB) (Installed)
Bash script for downgrading one or more packages to a version in your cache or the A.L.A.
endeavouros/eos-downgrade 0.26-1 (16.7 KiB 6.8 KiB)
Downgrade EndeavourOS packages (currently beta quality).
But a simple check with yay -Qii downgrade shows that the installed package came from EOS:
Name : downgrade
Version : 12.0.1-1
Description : Bash script for downgrading one or more packages to a version in your cache or the
A.L.A.
Architecture : any
URL : https://github.com/archlinux-downgrade/downgrade
Licenses : GPL
Groups : None
Provides : None
Depends On : pacman-contrib fzf
Optional Deps : sudo: for installation via sudo [installed]
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 83.56 KiB
Packager : manuel <manuel@endeavouros.com>
Build Date : Wed 04 Mar 2026 08:09:48 AM PST
Install Date : Thu 05 Mar 2026 10:25:14 AM PST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
Backup Files : /etc/xdg/downgrade/downgrade.conf [unmodified]
Extended Data : pkgtype=pkg
It’s a bit confusing, but you’ll quickly get used to it.
It can lead to issues on occasion when updating, yes. Many of your AUR packages will also start coming from chaotic instead of AUR and you will lose the ability to easily inspect the diffs on updates.
Is there no way to tell AUR utilities or PacMan utilities that so and so package comes from Arch. X y and z comes from EOS while only some of the linux kernels comes from Chaotic AUR?
Does the URL determine the repo from which the package has been pulled? It seems that labels like [endeavouros], [core], [extra] are not used by the command yay -Qii downgrade
Not in this case, no. If you do yay -Sii downgrade, you’ll get results from the EOS and Chaotic AUR repos, both using the same source URL. Even running yay -Sii endeavouros/downgrade returns this:
Repository : endeavouros
Name : downgrade
Version : 12.0.1-1
Description : Bash script for downgrading one or more packages to a version in your cache or the
A.L.A.
Architecture : any
URL : https://github.com/archlinux-downgrade/downgrade
Licenses : GPL
Groups : None
Provides : None
Depends On : pacman-contrib fzf
Optional Deps : sudo: for installation via sudo
Required By : None
Optional For : eos-downgrade pacui
Conflicts With : None
Replaces : None
Download Size : 38.65 KiB
Installed Size : 83.56 KiB
Packager : manuel <manuel@endeavouros.com>
Build Date : Wed 04 Mar 2026 08:09:48 AM PST
MD5 Sum : None
SHA-256 Sum : 6e915eb4549a03aa14d1cef59a8ec4ef24512020bf6302fd411ec3999e219e1b
Signatures : A367FB01AE54040E
Extended Data : None
So is there any other pacman utility like paru or something else which can show this information? i.e. which repository and what label was used to download the package? It is surprising yay does not have the ability to link the label, the repository url with the package. It should be there. Maybe this is a bug in pacman/yay?
This can get messy fast. If we have linux-lts and linux-lts612 packages and both are available in Arch Repor/AUR as well as Chaotic AUR then an update will massively screw up everything.
It’s really not a problem. As I mentioned above, repos in /etc/pacman.conf always take priority over the AUR. The only potential issue - it’s really more of an inconvenience than anything else - it when you upgrade an AUR package before Chaotic-AUR has built the new binary.
In your example above, the (2) LTS packages are completely different, and can actually be installed at the same time.
It isn’t a bug, it is how pacman works. Arch doesn’t expect you to use 3rd party repositories that conflict in this way. If you choose to, this will always be a problem. Pacman does not track where software was installed from.
It won’t massively screw things up but it will cause most of your AUR packages to updated from chaotic-aur instead. There may also occassionally be library conflicts caused by chaotic-aur depending on which packages you install.