Package Details: linux-pf-headers 6.11.pf4-1

Git Clone URL: https://aur.archlinux.org/linux-pf.git (read-only, click to copy)
Package Base: linux-pf
Description: Headers and scripts for building modules for the pf-kernel
Upstream URL: https://pfkernel.natalenko.name
Keywords: bbr bbr3 kernel ksm linux linux-pf pf-kernel uksm uksmd v4l2loopback zstd
Licenses: GPL-2.0-only
Provides: linux-pf-headers
Submitter: nous
Maintainer: post-factum
Last Packager: post-factum
Votes: 210
Popularity: 0.30
First Submitted: 2011-07-24 12:01 (UTC)
Last Updated: 2024-11-06 15:49 (UTC)

Dependencies (10)

Required by (0)

Sources (2)

Pinned Comments

post-factum commented on 2023-09-25 20:30 (UTC) (edited on 2024-10-08 14:21 (UTC) by post-factum)

Official binary builds for various x86_64 ISA levels are available here.

Latest Comments

« First ‹ Previous 1 .. 47 48 49 50 51 52 53 54 55 56 57 .. 106 Next › Last »

<deleted-account> commented on 2012-12-17 16:08 (UTC)

@jnbek Thanks, it worked.

jnbek commented on 2012-12-16 19:00 (UTC)

@nous: w00t!!! thanks :) @Decepteiskon, remove it, and it's corresponding md5sum (4th line from the bottom iirc, starts with d) from the PKGBUILD, this patch never actually applied, well at least for quite a while. The maintainer has stated that this will be removed when the 3.7 build is released.

<deleted-account> commented on 2012-12-16 18:39 (UTC)

Can't compile, error: curl: (22) The requested URL returned error: 404 Not Found ...given when downloading interactive-governor.tar.gz

nous commented on 2012-12-15 18:03 (UTC)

Ok then, the customer is always right! I'll give the 2/3-digit kernel version option in 3.7-pf.

jnbek commented on 2012-12-14 20:31 (UTC)

When I did it last night, using yaourt it removed the old 3.6-pf and installed the 3.6.11-pf just fine. And there's no 3.6-pf dir in /lib/modules seems fine.

nous commented on 2012-12-14 19:14 (UTC)

@jnbek: A simple versioning preference option and an "if-fi" around the SUBLEVEL sed would be enough for that, but I don't know what happens if one compiles a 3-digit linux-pf and at the next update one forgets to select again a 3-digit version: does pacman remove the old modulesdir from /usr/lib/modules or it ends up accomodating both 3.7.1-pf and 3.7-pf? In the pacman manpage it says -U is "remove-then-add", so I'm guessing we're OK but what happens with 2-digit kernver packages downloaded from the repo and installed with -S over a previous 3-digit version?

jnbek commented on 2012-12-14 18:49 (UTC)

@ nous, I totally understand the rationale, I guess I came across a little on teh smartass side of the discussion initially. Perhaps, a possible solution would be a -fullversion package for those that don't mind the nvidia/vbox compilings, and then this one keeping the 2 digit versioning for the folks who don't wish to compile. I mean, it is just a one line difference in the PKGBUILD, that way you could do some A/B testing, if you will, to see which of the two get's the most attention, then y'all can at that point decide which of the two seems best. Just a thought.

nous commented on 2012-12-14 18:07 (UTC)

Incidentally, I've been having this discussion with post-factum (the patchset author) a couple of days now. Here's an excerpt from my rationale on why we should stick to 2-digit versioning: "[...] if we want to show the patchlevel and increment it with every release, then I'm OK with that, but there is an unbeatable advantage in leaving the patchlevel out of the kernel version: binary modules don't need rebuilding with every update and that was the way of linux-ARCH a few months back, until Tobias decided he didn't mind rebuilding nvidia and virtualbox with every kernel update." Most of the boxes I own or run sport an nvidia card and I hate it when I update the kernel and Xorg won't start at the next reboot due to a simple bump from 3.6.1 to 3.6.2. It's just unproductive.

J4913 commented on 2012-12-14 18:06 (UTC)

Yeah, I was aware of that. I only have PHC (which seems to be working with '3.6.11-pf' without a recompile, somehow) and VirtualBox (which is taken care of by the DKMS service). Either way, I needed to do it to test something in CrashPlan - it seems to fail to use inotify if the kernel version is only <major>.<minor>, for some crazy reason.

jnbek commented on 2012-12-14 17:51 (UTC)

@ J4913 just keep in mind, nous and the AUR maintainers have set it that way to prevent external module problems, so, you will likely need to rebuild any RAID, nVidia/ATI, Wireless, etc modules to accommodate the 3 level kernel value. I personally don't use any of that stuff so it's not an issue for me, I prefer a proper smelling uname -r as well, but if you find yourself having to spend 937 years rebuilding modules, you may want to relent as run it as offered.

« First ‹ Previous 1 .. 47 48 49 50 51 52 53 54 55 56 57 .. 106 Next › Last »