Package Details: linux-ck 6.11.8-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.26
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2024-11-15 22:31 (UTC)

Dependencies (14)

Required by (6)

Sources (6)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 .. 307 Next › Last »

graysky commented on 2022-12-04 21:17 (UTC)

What you're proposing is too non-standard for most other users IMO. If you can tweak your build script that would be preferable for your edge use case.

For my build script, the strategy is to first make the set of PKGBUILD files needed for the 4 subarches then copy them into a working dir to build. You might try something like that.

makework() {
  TODO="$des/TODO"
  if [[ ! -d "$TODO" ]]; then
    mkdir -p "$TODO" || exit 1
  fi

  cp "$pkg_source/PKGBUILD" "$TODO" || exit 1

  for i in "${buildem[@]}"; do
    if [[ "$i" = "generic" ]]; then
      # generic setup where 36 is the default
      num=36
      # this hit both instances of 'make oldconfig' for they are in an if statement so doesnt matter
      sed -e s/"#groups=('ck-generic')"/"groups=('ck-generic')"/ \
        -e "s/_subarch=/_subarch=36/" <"$TODO/PKGBUILD" >"$TODO/PKGBUILD.$i"
        #-e "s/make oldconfig/yes $num | make oldconfig/g" <"$TODO/PKGBUILD" >"$TODO/PKGBUILD.$i"
            else
              # not generic so everything else
              # num refers to the number added by my gcc patch assuming x86_64's list
              case $i in
                generic-v2)
                  num=37
                  ;;
                generic-v3)
                  num=38
                  ;;
                generic-v4)
                  num=39
                  ;;
                *) exit 0
                  ;;
              esac

              sed -e s"/#groups=('ck-generic')"/"groups=('ck-generic')"/ \
                -e "/^pkgbase=/ s,linux-ck,linux-ck-$i," \
                -e "/depends=('linux-ck'/ s,ck,ck-$i," \
                -e "s/groups=('ck-generic')"/"groups=('ck-$i')"/ \
                -e "s/_subarch=/_subarch=$num/" \
                <"$TODO/PKGBUILD" >"$TODO/PKGBUILD.$i"
    fi
  done

  # only work with PKGBUILD.xxx
  rm -f "$TODO/PKGBUILD"
}

brunomiguel commented on 2022-12-04 20:53 (UTC)

Editing the file makes it harder for automated builds, and it's trivial to add those entries as environment variables on the PKGBUILD. I understand you are not obligated to do so; you have it this way, and anyone who wants it differently can fork it, just like with any other FOSS project.

To make it easy for automated builds, would you be willing to use environment variables on the PKGBUILD to choose the sub-architecture and the compiler?

Thank you for creating the PKGBUILD for this kernel 🤝

artafinde commented on 2022-12-04 09:49 (UTC)

graysky: after the change for resolve_btfids issue below can you build the generic in a clean chroot?

graysky commented on 2022-12-04 09:38 (UTC)

Works fine as-is for me. Edit the PKGBUILD defining a valid number for _subarch= and build

brunomiguel commented on 2022-12-03 18:23 (UTC) (edited on 2022-12-03 19:26 (UTC) by brunomiguel)

Could you enable passing the _subarch variable with a value to the build process? I've been trying to pass it, either exporting it beforehand or using the env command, but it always requires user input. This prevents me from automating the build process for this kernel.

A way to fix it is changing _subarch= to "${_subarch:=""}" when first declaring it.

graysky commented on 2022-12-01 08:01 (UTC)

Fixed in -3

VGrol commented on 2022-12-01 02:42 (UTC) (edited on 2022-12-01 06:33 (UTC) by VGrol)

I'm also having the same issues as Air-G4P, with Nvidia-DKMS failing after having successfully built and installed linux-ck, linux-ck-headers, both via AUR helper and manually with makepkg.

Identical error of resolve_btfids

After some research, I found a solution, posted by Logs, on the Linux-CK thread on the BBS forums. It can be resolved by uncommenting the following line in the PKGBUILD.

air-g4p commented on 2022-10-09 14:41 (UTC)

@graysky - Thank you for your suggestion.

If I understood you correctly, I did copy my modprobed.db to my build directory containing the 6.0-1 PKGBUILD, added that file to the source array, appended the 256sum and modified the make line to the statement you referenced below.

The PKGBUILD I used is here: http://ix.io/4cFF

The only relevant modifications I made were on lines: 97, 111 and 194.

The build did succeed, without any reported error. However I still suspect time makechrootpkg -c -r $CHROOT is silently ignoring the reading/use of the 'modprobed.db' file as my build time still exceeded 5.5+ hours and my ~/chroot/user folder is (again) 20 GiB.

If you had another build process idea in mind, please let me know.

Cheers

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 .. 307 Next › Last »