Package Base Details: linux-lqx

Git Clone URL: (read-only, click to copy)
Submitter: akurei
Maintainer: sir_lucjan (damentz)
Last Packager: damentz
Votes: 128
Popularity: 1.56
First Submitted: 2011-08-08 16:08
Last Updated: 2020-04-02 15:28

Latest Comments

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

sir_lucjan commented on 2019-06-23 22:46


Sure. We could drop pkgver() if you want.

damentz commented on 2019-06-23 22:44

@sir_lucjan, I separated the commit to change pkgver() from the update to the version updates, so we're still tracking the latest version of Liquorix despite your revert.

According to the wiki, if you define a pkgver() function, it'll be used to automatically update pkgver on execution of makepkg with the code you define. How about we just delete the function entirely then? I don't use that code myself, so all it does is interfere with the value I put into pkgver.

sir_lucjan commented on 2019-06-23 22:25


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

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


I've reverted

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


Please check your mailbox.

Freso commented on 2019-06-23 20:32

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

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


We don't support yay and aur-helpers.

Please use a makepkg.

Arzte commented on 2019-06-13 21:01

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)

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

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.