Package Details: linux-lqx-docs 6.14.0.lqx1-1

Git Clone URL: https://aur.archlinux.org/linux-lqx.git (read-only, click to copy)
Package Base: linux-lqx
Description: Documentation for the Linux Liquorix kernel
Upstream URL: https://liquorix.net/
Keywords: bbr2 bfq futex pds proton zen
Licenses: GPL-2.0-only
Submitter: akurei
Maintainer: sir_lucjan (damentz)
Last Packager: damentz
Votes: 164
Popularity: 1.65
First Submitted: 2011-08-08 16:08 (UTC)
Last Updated: 2025-04-01 23:15 (UTC)

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 .. 112 113 114 115 116 117 118 119 120 121 122 Next › Last »

silvik commented on 2011-12-02 13:13 (UTC)

hey Mavirick / td123 / someone with sufficient skills and time, why don't you take ownership of this package or create linux-liquorix or something like this and maintain it properly? it's already 2 versions behind official arch kernel. the maintainer doesn't care anyway.

<deleted-account> commented on 2011-11-30 07:07 (UTC)

Thanks,Mavirick! Too bad the _new_ maintainer doesn't seem to care. It's been 3 days since lqx 3.1.3 is out and still no update.

<deleted-account> commented on 2011-11-30 06:47 (UTC)

I've created and tested a new pkgbuild for linux-lqx-3.1.3-1 it requires the new mkinitcpio 0.8 which moves mkinitcpio from /sbin/ to /usr/bin Here is the PKGBUILD: http://pastebin.com/TeySHHRs Here is the Modified linux-lqx.install: http://pastebin.com/bdiyFB51

shivik commented on 2011-11-23 07:13 (UTC)

td123, what I meant was that you can use a different name for your kernel for ex. linux-td123, linux-td, linux-lqxtd (and still base it on the -lqx)- you get my point. I believe in diversity so I welcome your unique approach, but still I don't think linux-lqx should be changed. That's why I suggested a new AUR package.

td123 commented on 2011-11-23 06:36 (UTC)

Ok, fine, I guess I wont take ownership of this package then.. I did manage to rebase against the [core] linux PKGBUILD. You can find the package at: http://ompldr.org/vYmV2Ng/linux-lqx-3.1.1-1.src.tar.gz fyi, this package is *a lot* cleaner and perhaps more bug free than the one provided on this page. Possibly easier to maintain. I haven't experienced any problems so far with my package.

akurei commented on 2011-11-22 22:31 (UTC)

I know, I am not maintining this anymore, and thus should not interfere, but please td123, leave the options for make xconfig and make menuconfig etc in. They're useful for everyone and don't harm anyone.

td123 commented on 2011-11-22 21:49 (UTC)

There is a good reason those patches do get applied to the arch kernel (fix freezes on certain hardware). The arch kernel does the compression also, so I think it's safe to say that this kernel should be using _compress_modules="yes" for all cases. I can't think of a reason why you wouldn't want this. The problem with creating another linux-lqx pkg in the aur is that it would be a duplicate. I guess for now, I will just try reworking the PKGBUILD and see what you guys think before posting it here...

shivik commented on 2011-11-22 19:15 (UTC)

I'm kind of against this. The main idea is to get the base kernel with the liquorix patchset applied only. As for the options - almost all of the other AUR kernels have those and they're kind of useful sometimes. Maybe _compress_modules is useless... A PKGBUILD cleanup would be nice though Your ideas are by no means bad,but I think this package should be left the way it is. Maybe you should create a new kernel based on the -lqx one and realize your ideas.

td123 commented on 2011-11-22 18:14 (UTC)

I'll try to rebase this kernel against the latest linux in [core]. My current thoughts are what to do about patches that get applied? Also, I'm planning on removing some if not all of the options provided at the top: _menu, _config, _compress_modules And general cleanup of the PKGBUILD so that future maintenance would be a lot easier. Does anyone have any opinions for or against this? If I can't update the PKGBUILD in about a week, I will just give up since that will probably mean I don't have enough time to figure all of this out.

« First ‹ Previous 1 .. 112 113 114 115 116 117 118 119 120 121 122 Next › Last »