On 14.10.2012 17:57, Akemi Yagi wrote:
OK, I blame the whole mess on Nux! who started this damn thing. ;-)
I deny everything!
We will adopt the kernel-ml/kernel-lt naming for the
mainline/longterm
kernels.
No objections allowed at this point !
Akemi the Despot
Wow, thank you very much, A
On Fri, Oct 12, 2012 at 12:17 PM, Phil Perry wrote:
> The decision to change is driven purely by user requests/expectations that
> yum can/will update within the current 3.0.y "longterm" branch rather than
> update from that to the latest mainline branch as it does now. Either of the
> proposed m
On 12/10/12 17:44, Dag Wieers wrote:
On Fri, 12 Oct 2012, Akemi Yagi wrote:
Having understood the subdirectory method, I now say I'd prefer the
kernel-ml / kernel-lt option for 2 reasons.
One is that, as Phil said, having to update the elrepo-release package
because of kernel addition does not
On Fri, 12 Oct 2012, Akemi Yagi wrote:
Having understood the subdirectory method, I now say I'd prefer the
kernel-ml / kernel-lt option for 2 reasons.
One is that, as Phil said, having to update the elrepo-release package
because of kernel addition does not sound right. We want to keep it as
st
On Fri, Oct 12, 2012 at 8:20 AM, Phil Perry wrote:
> On 12/10/12 16:01, Dag Wieers wrote:
>>
>> On Thu, 11 Oct 2012, Akemi Yagi wrote:
>>> I am trying to understand this concept of "sub-repositories". Using
>>> the above example, Elrepo will be offering new repositories named
>>> "kernel-ml-3.0"
On 12/10/12 16:01, Dag Wieers wrote:
On Thu, 11 Oct 2012, Akemi Yagi wrote:
On Thu, Oct 11, 2012 at 2:23 PM, Dag Wieers wrote:
I am not in favor of renaming the packages to kernel-lts (or anything
but
kernel-ml). For all practical purposes, sticking to one name, but
offering
(sub)repositorie
On Thu, 11 Oct 2012, Akemi Yagi wrote:
On Thu, Oct 11, 2012 at 2:23 PM, Dag Wieers wrote:
I am not in favor of renaming the packages to kernel-lts (or anything but
kernel-ml). For all practical purposes, sticking to one name, but offering
(sub)repositories for the different versions offers ev
On Thu, Oct 11, 2012 at 2:23 PM, Dag Wieers wrote:
> I am not in favor of renaming the packages to kernel-lts (or anything but
> kernel-ml). For all practical purposes, sticking to one name, but offering
> (sub)repositories for the different versions offers everything.
>
> So I would propose this
On 10/12/2012 01:44 AM, Dag Wieers wrote:
Ok, this boils down to having potentially 3 kernels installed
'kernel', 'kernel-lt' and 'kernel-ml'.
You are perfectly correct here, potentially, yes, all three variants
could be installed in the same time. But OTOH the kernel-lt is intended
for peopl
On Fri, 12 Oct 2012, Manuel Wolfshant wrote:
On 10/12/2012 12:44 AM, Alan Bartlett wrote:
On 11 October 2012 22:23, Dag Wieers wrote:
> On Thu, 11 Oct 2012, Phil Perry wrote:
>
> > On 10/10/12 23:30, Trevor Hemsley wrote:
> >
> > >I'd suggest kernel30 rather than kernel-lt since the l
On Thu, 11 Oct 2012, Alan Bartlett wrote:
On 11 October 2012 22:23, Dag Wieers wrote:
On Thu, 11 Oct 2012, Phil Perry wrote:
On 10/10/12 23:30, Trevor Hemsley wrote:
I'd suggest kernel30 rather than kernel-lt since the long term in this
case is not that long and soon we'll be trying to w
On 10/12/2012 12:44 AM, Alan Bartlett wrote:
On 11 October 2012 22:23, Dag Wieers wrote:
On Thu, 11 Oct 2012, Phil Perry wrote:
On 10/10/12 23:30, Trevor Hemsley wrote:
I'd suggest kernel30 rather than kernel-lt since the long term in this
case is not that long and soon we'll be trying
On 11 October 2012 22:23, Dag Wieers wrote:
> On Thu, 11 Oct 2012, Phil Perry wrote:
>
>> On 10/10/12 23:30, Trevor Hemsley wrote:
>>
>>> I'd suggest kernel30 rather than kernel-lt since the long term in this
>>> case is not that long and soon we'll be trying to work out how to change
>>> kerne
On Thu, 11 Oct 2012, Phil Perry wrote:
On 10/10/12 23:30, Trevor Hemsley wrote:
I'd suggest kernel30 rather than kernel-lt since the long term in this
case is not that long and soon we'll be trying to work out how to change
kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel
Thank you, all.
I propose, therefore, to implement this change upon release of the
linux-3.0.46 tarball, upstream.
Alan.
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
On 10/11/2012 11:48 PM, Akemi Yagi wrote:
On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett wrote:
I have considered everyone's comments, including that from Trevor.
On the whole, I am agreeable with making the split into kernel-ml
(currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6.
How w
On 11.10.2012 21:34, Alan Bartlett wrote:
I have considered everyone's comments, including that from Trevor.
On the whole, I am agreeable with making the split into kernel-ml
(currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6.
Thank you!
--
Sent from the Delta quadrant using Borg techn
On 11.10.2012 21:48, Akemi Yagi wrote:
On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett
wrote:
I have considered everyone's comments, including that from Trevor.
On the whole, I am agreeable with making the split into kernel-ml
(currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6.
How woul
On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett wrote:
> I have considered everyone's comments, including that from Trevor.
>
> On the whole, I am agreeable with making the split into kernel-ml
> (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6.
>
> How would people like this to be impleme
I have considered everyone's comments, including that from Trevor.
On the whole, I am agreeable with making the split into kernel-ml
(currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6.
How would people like this to be implemented?
Alan.
___
elre
On 11.10.2012 00:17, Phil Perry wrote:
On 10/10/12 23:30, Trevor Hemsley wrote:
I'd suggest kernel30 rather than kernel-lt since the long term in
this
case is not that long and soon we'll be trying to work out how to
change
kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel
h
On 10/10/12 23:30, Trevor Hemsley wrote:
I'd suggest kernel30 rather than kernel-lt since the long term in this
case is not that long and soon we'll be trying to work out how to change
kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel
happens to be.
Unless the desired action
On 10/10/12 23:23, Manuel Wolfshant wrote:
On 10/11/2012 12:57 AM, Alan Bartlett wrote:
So let's try to move this on. As it is currently "my move", I shall
confirm that I am prepared to "smile" at the suggestion of kernel-lt
and kernel-ml. To begin with, I would need to perform a small
operation
On 10/10/12 23:23, Manuel Wolfshant wrote:
> On 10/11/2012 12:57 AM, Alan Bartlett wrote:
>> So let's try to move this on. As it is currently "my move", I shall
>> confirm that I am prepared to "smile" at the suggestion of kernel-lt
>> and kernel-ml. To begin with, I would need to perform a small
>
On 10/11/2012 12:57 AM, Alan Bartlett wrote:
So let's try to move this on. As it is currently "my move", I shall
confirm that I am prepared to "smile" at the suggestion of kernel-lt
and kernel-ml. To begin with, I would need to perform a small
operation upon a copy of the kernel-ml specification
On 10 October 2012 22:24, Phil Perry wrote:
> On 10/10/12 19:29, Alan Bartlett wrote:
>>
>> I'm going to advertise my ignorance -- for what does the 'LTS'
>> abbreviation stand, please?
>
> LTS = Long Term Service (although this is more of an Ubuntuism than a tern
> used by kernel.org who prefer s
On 10/10/12 19:29, Alan Bartlett wrote:
Yawn! Who woke me up by mentioning my name? Hmm . . .
I'm going to advertise my ignorance -- for what does the 'LTS'
abbreviation stand, please?
LTS = Long Term Service (although this is more of an Ubuntuism than a
tern used by kernel.org who prefer si
Yawn! Who woke me up by mentioning my name? Hmm . . .
I'm going to advertise my ignorance -- for what does the 'LTS'
abbreviation stand, please?
I've just been over to kernel.org and this is what I've seen --
[quote]
Latest Stable Kernel:3.6.1
stable: 3.6.1
mainline: 3.6
stabl
On 10.10.2012 11:28, Phil Perry wrote:
How about kernel-ml and kernel-lts for mainline and lts kernels,
respectively. But even that gets complicated as it looks like Alan is
currently maintaining 3.0, 3.5 and 3.6 branches.
Still, renaming the 3.0.x packages to kernel-lts would at least
differen
On 10/10/12 11:18, Nicolas Thierry-Mieg wrote:
Phil Perry wrote:
On 10/10/12 09:30, Manuel Wolfshant wrote:
On 10/10/2012 11:21 AM, Nux! wrote:
On 10.10.2012 09:12, Manuel Wolfshant wrote:
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their
On 10/10/2012 01:18 PM, Nicolas Thierry-Mieg wrote:
Phil Perry wrote:
On 10/10/12 09:30, Manuel Wolfshant wrote:
Oh well. +1 for separating LTS. "kernel-ml" is too broad now, covering
3-4 different versions.
Great suggestion. I agree, it makes sense to separate versions so yum is
able to in
On 10.10.2012 11:18, Nicolas Thierry-Mieg wrote:
perhaps you could rename the packages kernel-ml-lts and keep them in
the same repo, not sure if it's better than a separate repo but I
don't see other options.
Yes, I was going to suggest this as well. So it's either this or a
different repo.
Phil Perry wrote:
On 10/10/12 09:30, Manuel Wolfshant wrote:
On 10/10/2012 11:21 AM, Nux! wrote:
On 10.10.2012 09:12, Manuel Wolfshant wrote:
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their own
repo or would it be just spreading too thin?
On 10/10/12 09:30, Manuel Wolfshant wrote:
On 10/10/2012 11:21 AM, Nux! wrote:
On 10.10.2012 09:12, Manuel Wolfshant wrote:
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their own
repo or would it be just spreading too thin? Maybe some hardlin
On 10/10/2012 11:21 AM, Nux! wrote:
On 10.10.2012 09:12, Manuel Wolfshant wrote:
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their own
repo or would it be just spreading too thin? Maybe some hardlinks as
to not waste space.. I'm not using t
On 10.10.2012 09:12, Manuel Wolfshant wrote:
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their own
repo or would it be just spreading too thin? Maybe some hardlinks as
to not waste space.. I'm not using the lts kernel but I'm thinking
many
On 10/10/2012 11:09 AM, Nux! wrote:
Hi,
Guys, is there a possibility to have the TLS kernels in their own repo
or would it be just spreading too thin? Maybe some hardlinks as to not
waste space.. I'm not using the lts kernel but I'm thinking many do
and they don't want to have the lts kernel
37 matches
Mail list logo
