This guide is deprecated as of May 11th, 2019. Liquorix is now built for Debian Stable and Debian Testing. Check the home page for a new one-liner for Debian that correctly sets up /etc/apt/sources.list.d/liquorix.list with the correct Debian code name (stretch, buster, sid, etc).

The latest Liquorix headers require gcc-7, not available except in Debian development or Ubuntu 17.10+. These versions are rebuilt to use the default gcc version for each release.

You can get to the automatically generated instruction page here:

software.opensuse.org/download.html?project=home%3Astevenpusser%3Acodelite&package=liquorix

The Ubuntu directions use sudo, the Debian ones say to use root. Debian sudo users can become root with "sudo -i".

Simplifying the Debian Stretch directions:

Add the repo as root:


Download the key as a standard user:


Add the key to your key store and update the package database as root:


Jessie users can just replace the "9.0" in the instructions with "8.0". Ubuntu user's instruction
with sudo are simpler to follow, just copy and paste into the terminal the instructions from that link for your release.

Ignore the command about "apt-get install liquorix", that's a dummy package I had to add.

64-bit users can then install the kernel and header metapackages:



32-bit users can choose between the standard or the PAE versions:



or



Jessie users of proprietary drivers and ndiswrapper may need to update to patched or backported versions from this repo to get them to build on the newer kernels.
Back to top

Hmmm--what happens if I replace the versioned version of gcc in debian/config/defines with just "gcc"? Would that then build using the default gcc for each distro release, so I wouldn't have to maintain separate gcc-4.8, 4.9, 5, and 6 versions?
Back to top

Yes, I would suspect that's true. The reason I specify the GCC version is to prevent a newer version of GCC in Debian Unstable / Testing from being used mid-packaging of a kernel. That and I like to watch the latest Ubuntu releases, and once a new stable version of Ubuntu comes out with the newer GCC in the repo, I update the next major version of Liquorix with that.

But yes, there's no harm in just setting the GCC version to "gcc" and building that on an older distribution. In fact, for automated builds among many old distributions (16.04, 16.10, 17.04, 17.10, etc), you'll want to do that anyway and not specify any version in particular.
Back to top

Cool...but should I keep building with -O2 instead of -O3 optimization for gcc < 5? That will still mean two different versions, which is better than the four I'm doing now.
Back to top

Hmm, that's a good question. I actually suspect -O3 is much more stable than you might think and is simply less tested only because maintainers are afraid of supporting it. I've been using O3 for quite some time (since 2016-05-16 per the atom feed: liquorix.net/atom)

So, I think that's up to you. The newer the version, major or minor, the less likely O3 will have unwanted side effects.

On the other hand, I'm now building official packages for Ubuntu on the PPA here: launchpad.net/~damentz/+archive/ubuntu/liquorix

If you check the liquorix-package git repository, I'll now be running a new build script as part of my local build process that sends Ubuntu source packages to launchpad: github.com/damentz/liquorix-package/blob/master/scripts/make-ppa-spins.sh

Just a heads up, once this is all stabilized, I'll advertise it on the main website and we probably won't need your backports (except for maybe Debian stable).
Back to top

I"m not sure about that, I see you built for beta, current, and the two previous releases, which means, the pools go back about 1, 1.5 years. This doesn't seem to relate to supporting LTR or Debian Stable releases, which can easily be 2 to 3 to more times older.

It looks to me like the liquorix ppa's will be good for people running the recent releases, but the stuff being done by stevenpusser is focused on the stable stuff that can be older.
Back to top

At least I can cut out the builds that are duplicated in the official PPA now. Looks like I can switch to just one source version now that uses just "gcc" in the defines. I'll try leaving -O3 in there, too.
Back to top

The 4.19 kernels won't build on Jessie or Ubuntu 14.04; the error message is that the OBS isn't providing a retpoline-enabled compiler, though that patched default gcc is available in the security updates for each distro...apparently the OBS isn't getting those, though the Stretch compiler, which also added retpoline in a security update, works just fine there.

They build fine on my own machine in Jessie/Trusty pbuilders, though.
Back to top

I've quit updating the kernels in the repo now. I do know that the broadcom-sta-dkms driver currently in any version of Debian won't build on a 5.1 kernel, but I have a patch from ParrotOS that fixes the build, and will put that in the repo...unless Liquorix feels like adding it?
Back to top

I think that's up to the user and the distribution. By choosing a stable distribution that is careful on pulling from upstream, you run the risk of getting a mismatched configuration where your dkms modules are too out-of-date to build with the running kernel. That and certain userspace like xorg and drm packages may hit an edge case where the kernel requires updated userspace to render, set display modes, and accelerate graphics correctly.

However, I am interested in automating backports of key packages (out-of-tree driver dkms, firmware), from Debian Unstable / latest Ubuntus. The key is to automate it and make the packages available to stable users in Debian / Ubuntu. I'll look into it and see how hard that would be to do and support.

EDIT: And thanks for supporting Debian packages for so long. Part of my reason to spin up packages for stable / testing is the popularity of MX Linux. I think they're doing it right by backporting important software for distribution, which makes it a serious option for users that want a stable system that'll last a long time, but need software to not be ancient for their use-case.

I was also not aware of ParrotOS, looks interesting. I'll check it out when I get some free time.
Back to top