Arch Linux User Repository

The last version of the linux-git package was disowned and deleted. I've restored it taken ownership, as I do make use of this package.

This package will automatically update it's version

Note: This is a -git package and the version will automatically update to the latest mainline commit when it is run, having pulled down the branch from the repository. It will normally only be updated between major versions in order to include any updated configuration for new modules and features or settings changes.

@mxfm um, the "git repo" is literally the actual main Linux kernel repo. There's nothing wrong with it, if there were, the whole world would know. It would also mean that no other 5.9-rc1 kernels could be built using that source, which isn't true (I'm running one right now).

It's very likely a Dracut issue. Dracut on Arch is nowhere near ready for prime time on Arch Linux. An Arch dev reported not being able to use their keyboard and mouse when testing Dracut, etc.

But it's definitely not the git repo. If it's not the PKGBUILD, then it's your setup or dracut.

Approximately since 5.9.1.rc1 I cannot build correct package of linux-git. I use config file from mainline 'linux' package from core repo (I only modified two kernel options related to default localhost name and version config). After building the package, I cannot build initramfs image with dracut - it fails to include kernel modules with message like 'depmod: ERROR: failed to load symbols from /var/tmp/dracut.nBQFd0/initramfs/lib/modules/5.9.0-rc1-1-git/kernel/drivers/pinctrl/cirrus/pi nctrl-lochnagar.ko.xz: Exec format error'

Can someone confirm that he can build package from this script? Perhaps something has been broken in git repo?

I just did a complete rebuild for testing purposes with -j12 enabled. The build time came down from ~2 hours to 20 minutes while the laptop is still responsive. Wow! Thank you for this suggestion. This is more than I ever expected. I'll stick with this setting definitely ;)

@gardotd426 - Well in my case the build files stay near the source code, and are present even after reboots and /tmp is cleared.

And if you use "makepkg -e" it does perform an incremental build (assuming config was already done on the previous build).

@Harey - You should definitely go with a higher count, atleast "make -j8" if not "make -j12"

Wow, thank you for the fast and elaborate answers. I think I'll go with MAKEFLAGS -j4 (should be safe on a Ryzen 4800U) and maybe have a look at ccache.

Well I mean even if they're not using an AUR helper, /etc/makepkg.conf will have /tmp/makepkg set as the BUILDDIR so unless you set another BUILDDIR at compile time it'll still go to /tmp. But yeah, otherwise. It's definitely not impossible to make sure the files stick around, they just usually don't by default (but even if they do stick around, I'm not sure about "only rebuilding what's changed," I know that's a thing when manually compiling from source, but I don't know how well it works with PKGBUILDs, so I defer to you or someone else that knows on that part. I just use ccache).

Well I mean even if they're not using an AUR helper, /etc/makepkg.conf will have /tmp/makepkg set as the BUILDDIR so unless you set another BUILDDIR at compile time it'll still go to /tmp. But yeah, otherwise. It's definitely not impossible to make sure the files stick around, they just usually don't by default (but even if they do stick around, I'm not sure about "only rebuilding what's changed," I know that's a thing when manually compiling from source, but I don't know how well it works with PKGBUILDs, so I defer to you or someone else that knows on that part. I just use ccache).

@gardotd426 - That's assuming they're using an AUR helper. Which OK they probably are.

Since I'm doing some Linux kernel development, I just cloned the AUR repo into one of my partitions, and I build and develop from there. Hence why the build files are still around (until I clean them).

In that specific situation, my advice applies, otherwise you're right.

@sandy8925 there should be no way the original build files are still around, if they're using the default /tmp directory to build in....

Whenever you compile a kernel, you completely recompile. Using something like ccache would be the only way I know of to speed that up, but as far as I know with a kernel PKGBUILD there's no real way to only rebuild what's changed. But yeah if there were a way, it would absolutely require the original source files.

@Harey - I think the PKGBUILD itself will always attempt a clean rebuild, but if you want it to just recompile the changed files, you could always update the source manually, skip the prepare step by doing "makepkg -e" which should then do an incremental compile (assuming the previous intermediate build files are still around). Note that the version number may be wrong, and you'll have to make sure that any required patches are applied as well.

Also, if you want to save time in recompiling, you should setup ccache which can help to some extent.