Package Details: linux-mainline-headers 6.12-1

Git Clone URL: https://aur.archlinux.org/linux-mainline.git (read-only, click to copy)
Package Base: linux-mainline
Description: Headers and scripts for building modules for the Linux Mainline kernel
Upstream URL: https://kernel.org/
Licenses: GPL-2.0-only
Submitter: miffe
Maintainer: miffe
Last Packager: miffe
Votes: 278
Popularity: 2.51
First Submitted: 2011-07-22 06:50 (UTC)
Last Updated: 2024-11-18 03:24 (UTC)

Required by (0)

Sources (2)

Pinned Comments

miffe commented on 2020-01-30 21:44 (UTC)

Repository here

Latest Comments

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 76 Next › Last »

Det commented on 2017-04-15 10:02 (UTC) (edited on 2017-05-01 05:39 (UTC) by Det)

PKGBUILD still has pkgrel=1: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-mainline. .SRCINFO is this file: https://aur.archlinux.org/cgit/aur.git/tree/.SRCINFO?h=linux-mainline, which you run on the PKGBUILD only to get the information you see here on this page (also what yaourt and friends get). You can go rename /var/lib/pacman/local/linux-mainline-4.11rc6-1/ to *-2 and do the same for the %VERSION% in /var/lib/pacman/local/linux-mainline-4.11rc6-2/desc, which is quicker than rebuilding with pkgrel=2.

lesto commented on 2017-04-15 09:28 (UTC)

the revision 2 has a bug, yaourt thinks this is still revision 1 and try to install it over and over. Not 100% sure but could be cause by pkgrel=1??

smirky commented on 2017-04-13 21:52 (UTC) (edited on 2017-04-13 21:54 (UTC) by smirky)

https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-mainline&id=ae054cccecbba92d2fce801e82bffb433b9e6759 This commit breaks the kernel's hook. We get an empty file here because of that: /usr/share/libalpm/hooks/90-linux-mainline.hook To fix it, we just need to rename the 99-linux.hook to 90-linux.hook, otherwise, we do sed on a non-existing file, forcing us to workaround it with mkinitcpio -p linux-mainline (manually).

kgizdov commented on 2017-04-13 11:04 (UTC)

@WozMzy, sorry, I misunderstood how the config was handled. I thought it was just taken plainly from core, who has already applied olddefconfig. That is fine then.

WorMzy commented on 2017-04-12 23:32 (UTC)

@kgizdov: As miffe said, the core package's config is used as a base and is updated with olddefconfig which sets all new config options to their recommended/default values. If you are unhappy with the upstream defaults, complain there. Alternatively, roll your own config as Det suggested.

kgizdov commented on 2017-04-12 22:10 (UTC)

@miffe, as I said, regardless of the flag I mentioned, you are saying you are using a config from a different version of Linux. That is not how Linux works. This is a problem. You can run the built-in conf routine in the Linux source yourself and then diff against the one from another version. You will find that they have huge differences. Please try to mitigate this.

miffe commented on 2017-04-10 11:38 (UTC)

@kgizdov: The core config is updated with make olddefconfig before building. It hasn't caused a problem yet. And core can add that flag when they update to 4.11 and then i'll merge it back here.

Det commented on 2017-04-10 09:55 (UTC)

I don't suppose it matters either too much, since it's just a module, but also on that, isn't it easy enough to just enable nconfig to go through your own changes?

kgizdov commented on 2017-04-10 09:49 (UTC)

@miffe, a lot of the times you need a different config with newer versions of the kernel. How do you justify using the "old" config from the core package? I don't necessarily mean you to add my flag in particular, but core cannot and will not add it because it doesn't exist for linux 4.10, but it does for linux 4.11. It's bad practice not to update the config to match the version of linux.

basica commented on 2017-04-10 08:59 (UTC)

@miffe, thanks. I will wait till it becomes a stable kernel, and if not included in the default config log a request with the arch devs.

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 76 Next › Last »