Arch Linux User Repository

Hi. Since the package became an orphan, I adopted it to continue what I actively maintain on https://aur.archlinux.org/pkgbase/linux-mainline-git, now on this AUR package.

The build script and config file will be up-to-date with Arch's official Linux package unless an update is required to be functional.

But I intentionally removed the documentation package because it consumes too much building time.

This package supports certain customization if compiled by the user. Check for the README file inside the package repo, or the .INSTALL message after package installation to learn how.

For some reason building fails for me. Any idea why?

  CC [M]  fs/xfs/scrub/agheader_repair.o
  CC [M]  fs/xfs/scrub/repair.o
  LD [M]  fs/xfs/xfs.o
make: *** [Makefile:2026: .] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: linux-git-exit status 4

This is corresponding to the following line in the makefile:

2024 | PHONY += $(build-dir)
2025 | $(build-dir): prepare
2026 |   $(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1 $(single-goals)

Also happening on linux-mainline.

yurikoles

Thanks for your feedback, I appreciate it.

About the custom remote/config/patches: I know people many times use tools to build/install aur packages and that may bypass the customization, but that's fine. The behavior they will get is the current mainline kernel will be build/installed which is exactly what is expected. But your suggestion to use .install file to advertise the customization is pretty good. I'll add it. Also, using SKIP to user-modifiable files actually makes sense. I'll make this change.

Regarding to the doc package, the stock arch linux package maintainers were kind enough to make it easy to identify anything related to the doc package, even the build dependencies. If if becomes difficult to track their changes in future, I'll consider re-adding the doc package.

osimarr

Although me too consider doc package a waste of CPU time and disk space, but as a maintainer of other kernel packages on AUR, I suggest you to keep it in order to minimize diff against stock linux package , this will minimize a maintenance burden.

I really like your approach with a custom remotes and configs, but I’m afraid that you will face a 80/20 rule, since most archers are lazy and blindly install packages via helpers and [chaotic-aur]

I would suggest you a few points to consider:
1. 'SKIP' checksums for the custom end-user-modifiable files.
2. Inform users about package’s customization capabilities via message from .install file. Given some people install prebuilt packages from likes of [chaotic-aur], a message from install file will be shown even for these binary-only installs.

Hi. Since the package became an orphan, I adopted it to continue what I actively maintain on https://aur.archlinux.org/pkgbase/linux-mainline-git, now on this AUR package.

The build script and config file will be up-to-date with Arch's official Linux package unless an update is required to be functional.

But I intentionally removed the documentation package because it consumes too much building time.

This package supports certain customization if compiled by the user. Check for the README file inside the package repo, or the .INSTALL message after package installation to learn how.

@yurikoles

Here is a fork of this package which updates on a regular basis - https://aur.archlinux.org/packages/linux-mainline-git

Doesn't build.

==> Starting prepare()...
Setting version...
Usage: scripts/setlocalversion [srctree]
==> ERROR: A failure occurred in prepare().
    Aborting...

we now have flags for the repo cloning which saves quite some bandwith, e.g.:

GITFLAGS="--depth=1" makepkg
GITFLAGS="--depth=1" paru -S linux-mainline

in case the repo supports partial clones, --filter=tree:0 would be an option as well. this then even updates the repo correctly as soon as this is merged: https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/53

i'd be glad if you could try out your use case and maybe put a comment into the merge request?

https://github.com/archlinux/svntogit-packages/blob/41e9b62450ed0e7f520fa49be7117399da2d53f8/trunk/PKGBUILD#L112 needs to be added or dkms can fail spectacularly.

I personally use this a lot to build arbitrary kernels but it needs a cleanup;

Tons of Steam Deck users are gonna be playing around so wanna add 'any', and GKH is maintaining 5.10.y and a whole bunch of other kernels due to popular demand.

@osimarr should I delete this or convert it into just a generic x.x.y PKGBUILD?

5.15    Greg Kroah-Hartman & Sasha Levin    2021-10-31  Oct, 2023
5.10    Greg Kroah-Hartman & Sasha Levin    2020-12-13  Dec, 2026
5.4     Greg Kroah-Hartman & Sasha Levin    2019-11-24  Dec, 2025
4.19    Greg Kroah-Hartman & Sasha Levin    2018-10-22  Dec, 2024
4.14    Greg Kroah-Hartman & Sasha Levin    2017-11-12  Jan, 2024
4.9     Greg Kroah-Hartman & Sasha Levin    2016-12-11  Jan, 2023

via kernel.org

Ok created a public working copy here with history: https://github.com/sickcodes/linux-git

Just submitting a PR, with the way I use it; would love to see how everyone else uses this

@osimarr, see https://github.com/sickcodes/linux-git/invitations

Perhaps merge and you take charge?

I changed it to 'any' and used zcat config.gz