Package Details: linux-lqx 6.11.10.lqx1-1

Git Clone URL: https://aur.archlinux.org/linux-lqx.git (read-only, click to copy)
Package Base: linux-lqx
Description: The Linux Liquorix kernel and modules
Upstream URL: https://liquorix.net/
Keywords: bbr2 bfq futex pds proton zen
Licenses: GPL-2.0-only
Provides: UKSMD-BUILTIN, VHBA-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Submitter: akurei
Maintainer: sir_lucjan (damentz)
Last Packager: damentz
Votes: 161
Popularity: 1.84
First Submitted: 2011-08-08 16:08 (UTC)
Last Updated: 2024-11-22 16:37 (UTC)

Dependencies (19)

Required by (11)

Sources (3)

Pinned Comments

damentz commented on 2020-08-31 15:22 (UTC) (edited on 2021-12-21 18:25 (UTC) by damentz)

Official binaries of linux-lqx, linux-lqx-headers, and linux-lqx-docs are now available: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#liquorix

Signing key import instructions: sudo pacman-key --keyserver hkps://keyserver.ubuntu.com --recv-keys 9AE4078033F8024D && sudo pacman-key --lsign-key 9AE4078033F8024D

Latest Comments

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

sir_lucjan commented on 2019-06-23 22:25 (UTC)

@Freso

Currently pkgver() generates the correct version number because regardless of the position in PKGBUILD it starts anyway after the prepare() function where these values are declared. If prepare() was following pkgver() then you would be absolutely right. pkgver() is before prepare() in PKGBUILD only for cosmetic reasons and it doesn't matter for the operation; anyway it is after prepare() and before build().

Freso commented on 2019-06-23 21:57 (UTC)

I don’t think $_minor and $_patchrel get carried over from prepare() to other functions (such as pkgver()). You may need to define them again inside pkgver().

sir_lucjan commented on 2019-06-23 20:46 (UTC)

@Freso

I've reverted https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-lqx&id=962414a35862.

pkgver() dosen't work properly; I've downgrade lqxpatchset (-13 --> -11) and pkgver() doesn't set a proper pkgver.

@damentz

Please check your mailbox.

Freso commented on 2019-06-23 20:32 (UTC)

If all pkgver() does is return $pkgver, why not just remove the pkgver() function entirely? The pkgver() is a helper function to set $pkgver, so it makes no sense to have it set $pkgver to $pkgver

Arzte commented on 2019-06-13 21:41 (UTC)

Sure! Using makepkg, if you do your build in a separate command, it'll build using the wrong version. As an example, makepkg --cleanbuild --nobuild followed by makepkg --clean --force --noextract --noprepare will cause the second command to use the wrong version (because it "updates" it to 5.1._-1 from 5.1.9_4-1)

sir_lucjan commented on 2019-06-13 21:04 (UTC)

@Arzte

We don't support yay and aur-helpers.

Please use a makepkg.

Arzte commented on 2019-06-13 21:01 (UTC) (edited on 2019-06-13 21:05 (UTC) by Arzte)

Heya this package is currently broken when using the AUR helper yay. Yay runs functions separately (Eg prepare separate from build) and so any variable set in say prepare aren't kept for later on. This means that when this is building because _minor and _patchrel are set in prepare, this package can't currently be installed using yay, as it builds under a weird version.

An example of this would be with version 5.1.9_4-1 of this package, yay will error out when trying to install it, because makepkg would've built it under 5.1._-1, instead of 5.1.9_4-1.

(The yay issue discussing this is here) https://github.com/Jguer/yay/issues/893

To clarify this is because the variables are in separate functions, so they don't carry on when the PKGBUILD functions are executed separately with makepkg.

Democrab commented on 2019-06-04 13:24 (UTC)

I've been building/using this kernel for a few months on Manjaro, using an AUR Helper with zero problems in that entire timeframe. Any problems that @megapro17 is having are related to his specific system.

Thank you for maintaining this.

damentz commented on 2019-05-14 02:01 (UTC)

@Agafron, thanks for the feedback.