Package Base Details: linux-ck

Git Clone URL: (read-only)
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 390
Popularity: 2.215335
First Submitted: 2011-07-22 14:51
Last Updated: 2018-10-13 18:43

Packages (2)

karabaja4 commented on 2011-08-23 10:59

Has BFQ been ported to kernel 3.0? Because I'm unable to see it anywhere, yet linux-pf 3.0 seems to have it included somehow...

graysky commented on 2011-08-22 23:31

Guess this is my 15 min...

Det commented on 2011-08-22 19:58

@graysky, did you see my post?

E: btw, and that *is* correct. Even Googling reveals that the only 2 hits for "KCCPFLAGS" in the whole internets are both here :).

Det commented on 2011-08-22 19:56

@graysky, did you see my post?

graysky commented on 2011-08-22 19:20

@feilen - perhaps a typeo on my part in the comment. In the PKGUBILD, I use the following:


I believe these are correct. Is this not the case?

feilen commented on 2011-08-22 18:11

@graysky That is still not what I'm talking about. Here, maybe this will make it more clear:
One of those two is the correct variable to use, but in one post you said KCCPFLAGS, while in the PKGBUILD it was KCPPFLAGS.

Det commented on 2011-08-21 20:30

@graysky, hehe, seems like makepkg.conf flags don't affect the size image of my kernel image after all. My stupid ego is having problems dealing with this (or at least was having).

Well, moving on. The '-O2' flag messes up "CONFIG_CC_OPTIMIZE_FOR_SIZE=y" (-Os) (funnily even resulted in a 96 bytes bigger kernel for me - 300 KiB smaller after removing '-O2') so at least that should be removed as it's default anyway. In addition as told in FS#11864, "-fstack-protector" has been enabled already in the kernel for a long time: I even tested both of these just to make sure.

The KC(PP)FLAGS aren't needed in the package() function either since there's no compiling done there anyways. That line only installs the already built modules into the correct place:

$\O/> make help|grep modules_i
modules_install - Install all modules to INSTALL_MOD_PATH (default: /)

Anyway, thanks for telling about these KC(PP)FLAGS. I honestly always thought that makepkg.conf flags would always be used by default.

Anonymous comment on 2011-08-21 17:08

@Det and gravsyk: Thank you very much for your help! Det was right. My makepkg.conf is exactly like the one from you (gravsky), so it was upgraded the right way. Thank you very much for your help!

graysky commented on 2011-08-21 12:27

@Det - The main reason why I bumped it to -4 is that I need to rebuild all of the repo packages, and to make that a meaningful exercise, the pkgver needs to increase or else pacman won't pick up that something changed and trigger an update. I want to keep the AUR and repo packages "in sync" so bumping to force a rebuild is required.

To comment on your 2nd point about the long string for KCFLAGS/KCPPFLAGS: Since the KCFLAGS and KCPPFLAGS are as I understand it defined by the Makefile (or similar) included with the linux source. As I understand it, unless a user implicatively defines them at the make step, the generic defaults are used. Please correct me if I'm mistaken. Also, I do not believe that march=native provides the ARCH defaults of "-fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" but also please correct me if I'm mistaken.

@Loth - My bad for pointing you to the pre-files. See an example of /etc/makepkg.conf here (adjust for your $arch):

Det commented on 2011-08-21 11:15

@Lothium, it seems like you just fetched makepkg.conf from the [pacman] sources, through ABS or from here:

Either way, a simple "fix" would be to just remove your makepkg.conf and let pacman install the right one with:

# pacman -Syy pacman

E: wait, no, forget about that. It was just me not paying attention. The "@CARCH"and "@CHOST" stuff are just there to be changed in build time based on whether you are on i686 or x86_64. Nothing to worry there and definitely don't just copy+paste that file to your makepkg.conf

But if you don't have a makepkg.conf.pacnew file in /etc - that's perfectly fine. The confs are prefixed like that only when the previous file had changed since the previous update (meaning _you_ changed it).

So when you haven't changed the file in any way it can simply be replaced with the new one.