Oh hi Mark!
> I think we should not add linux-libre-4.15, because that version of
> Linux-libre is no longer supported upstream, and therefore will have
> well-known security flaws.
Ahhh... Good point! I've attached a patch at the end of the message (I think the
commit message might need tweaking).
> Also, this removes the definition of 'linux-libre', which I, for one,
> reference from my OS config and maybe others do as well. Sometimes it's useful
> to break compatibility, but in this case I see no reason for it.
I believe that the definition of 'linux-libre' was kept on line 527:
> (define-public linux-libre linux-libre-5.1)
Let me know if there are other things I can help fix up!
Cheers,
Carl Dong
accou...@carldong.me
"I fight for the users"
>From 327211937d5c243c796eb74b746680702b52b347 Mon Sep 17 00:00:00 2001
From: Carl Dong <cont...@carldong.me>
Date: Wed, 29 May 2019 21:47:06 -0400
Subject: [PATCH 2/2] gnu: linux: Remove unsupported kernel versions.
* gnu/package/linux.scm (%linux-libre-4.15-version,
%linux-libre-4.15-hash, linux-libre-4.15, linux-libre-headers-4.15):
Remove variables.
[comments] Add comment regarding what linux-libre versions to support.
---
gnu/packages/linux.scm | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 18e091a95a..95c76d3c90 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -428,6 +428,10 @@ for ARCH and optionally VARIANT, or #f if there is no such
configuration."
It has been modified to remove all non-free binary blobs.")
(license license:gpl2)))
+;; It is preferable to add kernels with upstream support. A list of longterm
+;; release kernels that receive backport fixes can be found here:
+;; https://www.kernel.org/category/releases.html
+
(define %linux-libre-version "5.1.4")
(define %linux-libre-hash
"02pzad29w2apcqsk4r4fq93539z3by8kvk1f59lb8xnl0gvhdi5v")
@@ -464,19 +468,6 @@ It has been modified to remove all non-free binary blobs.")
(make-linux-libre-headers %linux-libre-4.19-version
%linux-libre-4.19-hash))
-(define %linux-libre-4.15-version "4.15.18")
-(define %linux-libre-4.15-hash
"0f0s4drx888ydlwjcm9qcxqian4850yiv2vamyw9bbjf83frwxyw")
-
-(define-public linux-libre-4.15
- (make-linux-libre %linux-libre-4.15-version
- %linux-libre-4.15-hash
- '("x86_64-linux" "i686-linux" "armhf-linux")
- #:configuration-file kernel-config))
-
-(define-public linux-libre-headers-4.15
- (make-linux-libre-headers %linux-libre-4.15-version
- %linux-libre-4.15-hash))
-
(define %linux-libre-4.14-version "4.14.121")
(define %linux-libre-4.14-hash
"1g7gyjmp056pasf9m34dqs8pa15my6hqasdd551jw8mgkbhsfnxg")
--
2.21.0
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 29, 2019 9:31 PM, Mark H Weaver <m...@netris.org> wrote:
> Hi Danny and Carl,
>
> guix-comm...@gnu.org writes:
>
> > dannym pushed a commit to branch master
> > in repository guix.
> > commit a15cee50cebddc665a16b455f44e22dcfb87d57f
> > Author: Carl Dong accou...@carldong.me
> > Date: Wed May 29 18:04:43 2019 +0200
> >
> > gnu: Use make-linux-libre-headers.
> >
> > * gnu/packages/linux.scm (make-linux-libre-headers): New variable.
> > (linux-libre): Rename to...
> > (linux-libre-5.1): ...this.
> > (linux-libre-headers): Rename to...
> > (linux-libre-headers-4.14.67): ...this.
> > (linux-libre-5.1, linux-libre-headers-4.14.67): Use
> > make-linux-libre-headers.
> > (linux-libre-5.1, linux-libre-headers-5.1, linux-libre-headers-4.19,
> > %linux-libre-4.15-version, %linux-libre-4.15-hash, linux-libre-4.15,
> > linux-libre-headers-4.15, linux-libre-headers-4.14): New variables.
> >
> > Signed-off-by: Danny Milosavljevic <dan...@scratchpost.org>
> >
>
> I think we should not add linux-libre-4.15, because that version of
> Linux-libre is no longer supported upstream, and therefore will have
> well-known security flaws.
>
> Also, this removes the definition of 'linux-libre', which I, for one,
> reference from my OS config and maybe others do as well. Sometimes it's
> useful to break compatibility, but in this case I see no reason for it.
>
> Finally, given I've been the de-facto maintainer of our kernel packages
> since the early days of Guix, I would have appreciated a heads-up on
> these proposed changes and an opportunity to comment before they were
> pushed to master.
>
> Regards,
> Mark
