On Wed, Dec 30, 2020 at 04:18:40PM -0500, Raghav Gururajan wrote:
> From 24fc8ba6ea11a0d45ea8b240292bd56dc865ae52 Mon Sep 17 00:00:00 2001
> From: Raghav Gururajan
> Date: Wed, 30 Dec 2020 16:15:26 -0500
> Subject: [PATCH 11/11] gnu: Revise comment for Linux-Libre-LTS.
>
&
Guix right now are current LTS
> > > kernels. Do you mean "Always points to the newest released LTS version?"
> >
> > Yours makes it more clear. So,
> >
> > linux-libre => Always points to the latest released version.
> >
> > linux-l
e clear. So,
linux-libre => Always points to the latest released version.
linux-libre-lts => Always points to the newest released LTS version.
I have attached a patch to update the comment in linux.scm. Could any of
you push it please?
Regards,
RG.
>From 24fc8ba6ea11a0d45ea8b240292bd56
e clear. So,
linux-libre => Always points to the latest released version.
linux-libre-lts => Always points to the newest released LTS version.
Regards,
RG.
On 29.10.20 04:32, Raghav Gururajan wrote:
[...]
Thoughts?
A problem with the approach pushed is that it's not easy to spot
`linux-libre-lts`. As its only a variable and not a package: `guix show`
and `guix package -A` wont find it.
gt; Always points to the latest released version.
>
> linux-libre-lts => Always points to the currently released LTS version.
This guideline, and the code comment in 'gnu/packages/linux.scm', don't
make sense to me.
All of the kernel packages offered by Guix right now are cu
Hi Mark!
>
> I have one concern.
>
> It seems to me that the main reason to specify an LTS kernel is to avoid
> the unscheduled breakage that can occur when updating to a new kernel
> release series (i.e. to a new major+minor version). Using
> "linux-libre-lts&
age that can occur when updating to a new kernel
> >> release series (i.e. to a new major+minor version). Using
> >> "linux-libre-lts" would fail to avoid these unscheduled updates; it
> >> would merely reduce their frequency.
> >>
> >>
On Thu, Dec 24, 2020 at 09:24:17PM -0500, Mark H Weaver wrote:
> What do you think?
I understand your concerns about the ambiguous meaning of an "LTS"
kernel in the context of Guix.
In order to make it more concrete, we could attempt to stay on the same
long-term support kernel series between Gui
On Wed, Dec 23, 2020 at 10:54:30PM -0500, Raghav Gururajan wrote:
> Hello Efraim!
>
> > I was waiting for the kernel code reorganization before adding it as a
> > variable. The trick is to add also linux-libre-lts-source and all the
> > others, and in a useful location.
updating to a new kernel
>> release series (i.e. to a new major+minor version). Using
>> "linux-libre-lts" would fail to avoid these unscheduled updates; it
>> would merely reduce their frequency.
>>
>> The only way to reliably avoid unscheduled major+mino
On 24.12.20 11:15, Mark H Weaver wrote:
Thoughts?
I have one concern.
It seems to me that the main reason to specify an LTS kernel is to avoid
the unscheduled breakage that can occur when updating to a new kernel
release series (i.e. to a new major+minor version). Using
"linux-libr
Hi Raghav,
Raghav Gururajan writes:
> I think it is good to have a package-variable "linux-libre-lts", as
> mentioned in the table at https://jxself.org/linux-libre/
>
> This way, users don't have to remember and change the version numbers in
> their operating-s
Hello Efraim!
> I was waiting for the kernel code reorganization before adding it as a
> variable. The trick is to add also linux-libre-lts-source and all the
> others, and in a useful location. Now it's just taking the time to add
> it in somewhere.
>
> Do you want to tak
Hi Raghav,
Raghav Gururajan 写道：
Where? It's neither here[0] nor there[1]. I found it on
blogs.
The name isn't that important; just don't change it for fun,
and
‘longterm’ is what I'm used to hearing upstream.
Here, https://jxself.org/linux-libre/
That's the blog I was talking about.
Kin
Hey Tobias!
Where? It's neither here[0] nor there[1]. I found it on blogs.
The name isn't that important; just don't change it for fun, and
‘longterm’ is what I'm used to hearing upstream.
Here, https://jxself.org/linux-libre/
There is a table at the bottom of the page. The same naming co
Hi Raghav,
Raghav Gururajan 写道：
Sure! Yeah, making it default was the next thing in my mind.
Honestly no idea where I stand on that but I can bring the
popcorn.
We should use upstream[0] release names, though, not roll our
own
(+less clear) ones. So ‘-longterm’ instead of ‘-lts’.
By up
Hello Tobias!
It is! Would you like to try your hand at a patch? It should be easy
if unexciting work. (If you want excitment you can suggest making it
the default.)
Sure! Yeah, making it default was the next thing in my mind.
We should use upstream[0] release names, though, not roll our
Hi Efraim!
I was waiting for the kernel code reorganization before adding it as a
variable. The trick is to add also linux-libre-lts-source and all the
others, and in a useful location. Now it's just taking the time to add
it in somewhere.
Do you want to take a stab at it? I'm not
On Thu, Oct 29, 2020 at 09:24:08AM +0100, Tobias Geerinckx-Rice wrote:
> Raghav!
>
> Raghav Gururajan 写道：
> > I think it is good to have a package-variable "linux-libre-lts", as
> > mentioned in the table at https://jxself.org/linux-libre/
>
> It is! Would
Raghav!
Raghav Gururajan 写道：
I think it is good to have a package-variable "linux-libre-lts",
as
mentioned in the table at https://jxself.org/linux-libre/
It is! Would you like to try your hand at a patch? It should be
easy if unexciting work. (If you want excitment you c
On Wed, Oct 28, 2020 at 11:32:08PM -0400, Raghav Gururajan wrote:
> Hello Guix!
>
> I think it is good to have a package-variable "linux-libre-lts", as
> mentioned in the table at https://jxself.org/linux-libre/
>
> This way, users don't have to remember and chan
Hello Guix!
I think it is good to have a package-variable "linux-libre-lts", as
mentioned in the table at https://jxself.org/linux-libre/
This way, users don't have to remember and change the version numbers in
their operating-system-configuration or package-manifest, wheneve
23 matches
Mail list logo
