Package Base Details: linux-git

Git Clone URL: https://aur.archlinux.org/linux-git.git (read-only, click to copy)
Keywords: kernel linux
Submitter: jonathanio
Maintainer: jonathanio
Last Packager: jonathanio
Votes: 7
Popularity: 0.015714
First Submitted: 2019-12-22 10:10
Last Updated: 2020-11-04 21:11

Pinned Comments

jonathanio commented on 2019-12-22 10:14

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

mxfm commented on 2020-08-29 18:57

@gardotd426 I knew the kernel is not broken for the reasons outlined by you. My suspect was that something is changed in kernel build process which required changes in PKGBUILD, so this would affect only Arch.

Regarding dracut. I can assure, that dracut is fully fine in my setup, which is quite complicated (full disk encryption). I even have created custom scripts to facilitate my minor needs. I would recommend to any advanced Arch user to use dracut because it is at least as flexible as mkinitcpio.

Regarding the problem. It turns out, that depmod and modinfo (which were called by dracut) were complaining on garbage '/usr/lib/modules' previous kernel version installation which no longer existed (trashed by power failure). After clearing this not tracked by pacman gargabe I was able to compile package. Thanks for quick response!

gardotd426 commented on 2020-08-29 14:29

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

mxfm commented on 2020-08-29 11:01

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?

Harvey commented on 2020-08-19 09:56

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 ;)

sandy8925 commented on 2020-08-18 16:14

@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"

Harvey commented on 2020-08-18 14:16

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.

gardotd426 commented on 2020-08-18 14:04

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 commented on 2020-08-18 14:04

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

sandy8925 commented on 2020-08-18 13:56

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

gardotd426 commented on 2020-08-18 13:48

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