AUR (en) - linux-amd

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: linux-amd-headers 6.10.5-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/linux-amd.git (read-only, click to copy)
Package Base:	linux-amd
Description:	Headers and scripts for building modules for the linux-amd package
Upstream URL:	https://www.kernel.org/
Licenses:	GPL-2.0-only
Submitter:	None
Maintainer:	archdevlab
Last Packager:	archdevlab
Votes:	33
Popularity:	0.21
First Submitted:	2019-11-10 15:20 (UTC)
Last Updated:	2024-08-21 00:22 (UTC)

Dependencies (28)

linux-amd^AUR
pahole (pahole-git^AUR)
bc (bc-gh^AUR) (make)
binutils (make)
bison (byacc-bison^AUR, bison-git^AUR) (make)
cpio (cpio-git^AUR) (make)
flex (flex-git^AUR) (make)
gcc (gcc-git^AUR, gccrs-git^AUR, gcc11^AUR, gcc-snapshot^AUR) (make)
gcc-libs (gcc-libs-git^AUR, gccrs-libs-git^AUR, gcc11-libs^AUR, gcc-libs-snapshot^AUR) (make)
gettext (gettext-git^AUR) (make)
git (git-git^AUR, git-gl^AUR) (make)
glibc (glibc-git^AUR, glibc-linux4^AUR, glibc-eac^AUR, glibc-eac-bin^AUR, glibc-eac-roco^AUR) (make)
graphviz (make)
imagemagick (imagemagick-git^AUR, imagemagick-full-git^AUR, imagemagick-full^AUR) (make)
kmod (busybox-coreutils^AUR, kmod-git^AUR) (make)
libelf (elfutils-git^AUR) (make)
make (make-git^AUR) (make)
pahole (pahole-git^AUR) (make)
patch (patch-git^AUR) (make)
perl (perl-git^AUR) (make)
python (python37^AUR, python311^AUR, python310^AUR) (make)
python-sphinx (python-sphinx-git^AUR) (make)
python-yaml (python-yaml-git^AUR) (make)
tar (tar-git^AUR, busybox-coreutils^AUR) (make)
texlive-latexextra (texlive-installer^AUR, texlive-full^AUR, texlive-dummy^AUR) (make)
xmlto (xmlto-git^AUR) (make)
xz (xz-git^AUR) (make)
zstd (zstd-git^AUR, zstd-static^AUR) (make)

Required by (0)

Sources (21)

Pinned Comments

archdevlab commented on 2024-08-15 03:38 (UTC)

I have adopted this package and have updated it!

Thanks!

<deleted-account> commented on 2023-05-04 16:38 (UTC)

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

<deleted-account> commented on 2020-10-26 18:15 (UTC)

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

<deleted-account> commented on 2019-11-10 15:23 (UTC)

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

Latest Comments

« First ‹ Previous 1 .. 28 29 30 31 32 33 34 35 36 37 Next › Last »

<deleted-account> commented on 2020-05-14 14:55 (UTC)

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.

<deleted-account> commented on 2020-05-03 17:07 (UTC)

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!

anaconda commented on 2020-05-03 13:48 (UTC)

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.

<deleted-account> commented on 2020-05-03 10:58 (UTC)

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..

anaconda commented on 2020-05-03 10:50 (UTC)

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.

<deleted-account> commented on 2020-04-21 08:25 (UTC)

Seems that the upstream code finally caught up, amdgpu fix no longer needed.

bedson commented on 2020-04-20 17:14 (UTC)

@eggz thank you! New build working like a charm :-)

<deleted-account> commented on 2020-04-19 21:29 (UTC)

@bedson yes, I have got the same patch implemented on my linux-amd-raven kernel suggested by markuschaaf. ( Wait, you were first! )

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.7&id=b2a7e9735ab2864330be9d00d7f38c961c28de5d

Going to implement it here aswell. Hang on. Thank you for your attention!

bedson commented on 2020-04-19 10:31 (UTC) (edited on 2020-04-19 14:37 (UTC) by bedson)

Thanks @eggz The shutdown process runs correctly, however, when the motherboard should poweroff, the process hangs (black screen). It wasn't there before. If you need something to diagnose the problem, write and I'll do it.

I downloaded logs from the entire last session - complete journalctl -b: https://pastebin.com/YBAM4rvv

Edit: Downgrade did not help. Some other package had to mess up something - systemd? I keep searching.. Maybe? https://gitlab.manjaro.org/packages/core/linux56/-/issues/3

Cheers.

<deleted-account> commented on 2020-04-19 09:34 (UTC)

Hi there Bedson,

Since I haven't seen your issue anywhere on any system on the new kernel, I'm going to need more info :), where exactly does systemd hang during the shutdown proces?