Package Details: linux-ck 6.11-1

Git Clone URL: https://aur.archlinux.org/linux-ck.git (read-only, click to copy)
Package Base: linux-ck
Description: The Linux kernel and modules with ck's hrtimer patches
Upstream URL: https://wiki.archlinux.org/index.php/Linux-ck
Licenses: GPL-2.0-only
Provides: KSMBD-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Replaces: virtualbox-guest-modules-arch, wireguard-arch
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 459
Popularity: 0.92
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2024-09-19 13:04 (UTC)

Dependencies (14)

Required by (6)

Sources (6)

Latest Comments

« First ‹ Previous 1 .. 56 57 58 59 60 61 62 63 64 65 66 .. 307 Next › Last »

graysky commented on 2017-12-18 20:10 (UTC)

@air-g4p - You need to assign a value to the _subarch variable (line 38) before you try building.

air-g4p commented on 2017-12-18 15:55 (UTC)

oops: my missing (below) linux-ck 4.14.7-1 build failure link is here:

https://bpaste.net/show/d4da2db9822e

air-g4p commented on 2017-12-18 15:52 (UTC)

Hi grayslake,

I am sorry to have to inform you that using: extra-x86_64-build

fails with either linux-ck 4.14.6-3 or with linux-ck 4.14.7-1.

I have pasted the complete failed build runs at:

linux-ck 4.14.6-3 (per your suggestion) lives here: https://bpaste.net/show/cad411ec029a

and also with: linux-ck 4.14.7-1, here:

Despite the 'advice' generated just prior to build failure:

Console input/output is redirected. Run 'make oldconfig' to update configuration.

$ make oldconfig make: *** No rule to make target 'oldconfig'. Stop.

and ofc, this also:

$ sudo make oldconfig [sudo] password for <userid>: make: *** No rule to make target 'oldconfig'. Stop.</userid>

Those 'make oldconfig' failures occur irrespective of whether a user is in their correct build directory, or in their chroot directory = /var/lib/archbuild/extra-x86_64/<userid>/build</userid>

Also, carefully note, the build process never stopped, prior to failure, to ask me, which CPU I wanted to build support for. The current linux-ck AURs I have tested above both only auto-select '> 23. Generic-x86-64 (GENERIC_CPU)', then immediately fail.

grayslake - I do appreciate your ongoing support, but I would like to get to the bottom of this issue, sometime 'soon'. If you have specific commands you want me to test, let me know.

All the best,

air|g4p

graysky commented on 2017-12-18 12:22 (UTC)

@artafinde - good idea.

sir_lucjan commented on 2017-12-18 11:29 (UTC) (edited on 2017-12-18 11:30 (UTC) by sir_lucjan)

@foi

RTFM

https://wiki.archlinux.org/index.php/GnuPG#Import_a_public_key

artafinde commented on 2017-12-18 07:58 (UTC)

@graysky I suggest for now to delete the 24 option (line #38) on the PKGBUILD. If a user wants native detection let him go through makepkg.

foi commented on 2017-12-18 06:16 (UTC)

Hi!

Failed in install (distro: manjaro gnome):

==> Verifying source file signatures with gpg... linux-4.14.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.14.7 ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-ck.

air-g4p commented on 2017-12-18 05:41 (UTC)

Hi graysky,

Thank you very much for attention and extremely quick correction of this issue. Highly impressive, indeed!

When I get a chance, I'll try a re-build with the current release, and let you how things went.

All the best,

air|g4p

graysky commented on 2017-12-17 23:33 (UTC) (edited on 2017-12-17 23:34 (UTC) by graysky)

@artafinde - Short of applying this patch and shipping the corresponding config (which makes building for repo-ck more difficult), I don't know how to cover that use-case.

It might be a bit of a hassle for you, but if you just run makepkg -s outside of the chroot, setup the config to your liking, you can replace the shipped config with config.last and update the checksums before you build in the chroot.

artafinde commented on 2017-12-17 23:23 (UTC)

@graysky: if you choose 24 (native) then you are asked again for P6_NOPS which fails to auto-configure with "yes" Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW)