Arch Linux User Repository

GCC13.1 is mainlined in arch, so this means znver4 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver4 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver3 based hardware, please use linux-amd-znver3
If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

GCC11.1 is mainlined in arch, so this means znver3 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver3 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

@eggz do you remember when we spoke about Asus thresholds? If you can I would need you to recompile one of those kernels but with another patch. This patch have to containe the same as the before patch . Change batt or bat0 to bat1 or add another option to the patch . May be something like: / The WMI method does not provide a way to specific a battery, so we * just assume it is the first battery. + * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first + * battery is named BATT. / - if (strcmp(battery->desc->name, "BAT0") != 0) + if (strcmp(battery->desc->name, "BAT0") != 0 && + strcmp(battery->desc->name, "BATT") != 0 && + if (strcmp(battery->desc->name, "BAT1") != 0 ) return -ENODEV;

if (device_create_file(&battery->dev,

Still no structleak fix. The kernelconfig gets overridden during the build where structleak is disabled. Since this exact problem does not occur in my upstream 5.7 builds, I'm pretty sure this is not really intended. but I'm afraid for mainline they will just wait till it hits 5.7, So I guess until then, no structleak.

I fixed basic stackprotection, but extra kernel hardening like structleak does not seem functional on 5.6 kernels. I will wait for upstream for that one.

I temporarily disabled stack canaries and used an upstream supression patch to get the gcc-10.1 builds going. I will re enable them as soon everything catches up. Have fun.

I managed to enable gcc-10 on every kernel by disabling stack canaries like CONFIG_STACKPROTECTOR (otherwise it doesn't even boot), but on this kernel, it doesn't even get there. the build fails on gcc-10. Ill keep looking... something to do with unprintable errors in the modules.order ... what the hell ...

Hi Folks, I know some of you are yearning to use the first gcc10.1 build (as any true ZEN user should), but the build on 5.6 looks anything but stable. I'm working as fast as I can to implement the right fixes to get gcc-10 built kernels in our hands, but I cant promise anything!!

If you HAVE to check it out and can't wait, the 'linux-next' and 'linux-new' (mainline) did build succesfully, you can take a look at them on our repo with those exact package names -- It appears that there are gcc10 fixed present upstream. Let's go hunting.

You can keep a local copy of the git and copy it to the pkgbuild dir before the makepkg so that the source matches the copied git. With that, you only need to git pull on your local linux git, which only downloads the updates.

Thats how I do it at home. I just download the updates. But I also use other tools that rely on a git source, to implement other patches, to watch for updates, config commit comparing, and other automated stuff that escapes me for the moment.

And most people download from my repo so there is not much git hammering going on there :)

If you really are anti git, you could also edit the pkgbuild source to get the tar instead and unpack it there. But youll have to find your own links then..

Above all, that git is meant to be hammered and if its not .. Ill host it myself ;)

For the moment I wont maintain the tar way since everything is running pretty smooth and automated right now, and I dont have the time right now to deal with suprises (believe it or not, during this pandemic I have more work than ever..) I might look into it when I'm feeling more adventurous..

Again, if speed is important to you and you really want to leave the git alone, the repo doesnt bite ;)

Thank you for using my kernel and appreciating our work!

Wouldn't it be a very small change to the PKGBUILD though? You can keep your local pipeline and only change it for here. Or does your local pipeline involve downloading this package? I'm grateful for your work on this package, so don't worry if this is something you cannot do, I'm just wondering. This wouldn't be so bad if we could set "--depth 1" for git cloning for AUR packages, this just hammers the git servers for no reason at all.

Sorry, I use a local git at home so I can streamline the AUR and my repo builds, it's much easier that way (mostly because of the stuff already in place) ..

If you are looking for speed you can always use my repo..

If I really wanted to push your change I have to change my entire pipeline of kernel autobuilds (with autodetection of changes and other small and bigger tools that expects a git repo present) from local to aur to repo... It would take me a terribly long time for almost the same result...

Sorry, I hope you understand..

Can you modify your PKGBUILD to download the tarball from kernel.org instead of cloning the whole linux repository? On some connections it takes longer to download than it does to compile.