Keep 3.11.y kernel for openSUSE 13.1 updates?

Post by Takashi Iwai
Hi,
Since 3.11.y maintenance was discontinued by Greg, Ubuntu took over
it. It made me wonder: are we willing to continue 3.11.y for openSUSE
13.1 updates, just relying on Ubuntu? Or, can we just move on 3.12.y?

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past? That aside,
personally I would feel much happier using an upstream maintained
kernel, so if that means moving to 3.12.y then so be it. I
unfortunately do not have any confidence in Ubuntu keeping the wider
community's interest at heart, they will just do what works for them.

Stephan Kulow

2013-12-05 13:17:12 UTC

That would also moving 12.2 to 3.4.72 and 12.3 to 3.10.22 - or are we
only worried about 13.1 maintenance?

Greetings, Stephan

Takashi Iwai

2013-12-05 14:21:21 UTC

At Thu, 05 Dec 2013 14:17:12 +0100,

That would also moving 12.2 to 3.4.72 and 12.3 to 3.10.22 - or are we
only worried about 13.1 maintenance?

I think we can concentrate only on 13.1 maintenance at this point.

The situation with 13.1 is somewhat new. Let's compare:

- 3.4 kernel on openSUSE 12.2 is a long-time support kernel, and Greg
still maintains it. We keep merging the upstream stable 3.4.y.

- 3.7 kernel on openSUSE 12.3 is a discontinued one and no one
actually maintains in the upstream. We (SUSE) eventually pick up
fixes occasionally. Thus the code flux is fairly low; i.e. very
little fixes have been done for 12.3 kernels.

- 3.11 kernel on openSUSE 13.1 is the one already discontinued by the
upstream, but Ubuntu continues to care and work on it. This makes a
dilemma.

Now, we have a few options:

A. Don't update any longer base kernel, just pick up a few critical
fixes. This is equivalent with what we did for openSUSE 12.3.

B. Take Ubuntu 3.11.y stable updates. We'll get stable backports
gratis, but hey, it's driven by them.

C. Move up on 3.12.y and later kernel maintained by the upstream.
This is basically a rolling update, and openSUSE 13.1 kernel will
catch up openSUSE 13.2 kernel at some point. (Or, it'll stay at
some long-time support kernel.)

For me, the option C sounds most attractive. But, maybe I'm biased
since I'm one of upstream kernel devs.

Takashi

Bruno Friedmann

2013-12-05 15:05:06 UTC

Post by Takashi Iwai
B. Take Ubuntu 3.11.y stable updates. We'll get stable backports
gratis, but hey, it's driven by them.

They will not keep it longer than April, I've a doubt they will use that one for LTS 14.04
We have to survive further than that, especially if we want to evergreen 13.1

--
Bruno Friedmann
Ioda-Net S�rl www.ioda-net.ch

openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot

Greg KH

2013-12-05 15:15:57 UTC

Post by Bruno Friedmann

Post by Takashi Iwai
B. Take Ubuntu 3.11.y stable updates. We'll get stable backports
gratis, but hey, it's driven by them.

They will not keep it longer than April, I've a doubt they will use that one for LTS 14.04

They have already publically stated that they will not use that one for
their next LTS kernel, for that they will be using 3.13.

Jeff Mahoney

2013-12-05 16:51:26 UTC

That would also moving 12.2 to 3.4.72 and 12.3 to 3.10.22 - or are we
only worried about 13.1 maintenance?

These are "standard" stable updates. They happen more or less
automatically already when Jiri Slaby has spare cycles.

-Jeff

--
Jeff Mahoney
SUSE Labs

Stephan Kulow

2013-12-06 09:11:36 UTC

Post by Takashi Iwai
Hi,
Since 3.11.y maintenance was discontinued by Greg, Ubuntu
took over it. It made me wonder: are we willing to continue
3.11.y for openSUSE 13.1 updates, just relying on Ubuntu?
Or, can we just move on 3.12.y?

That would also moving 12.2 to 3.4.72 and 12.3 to 3.10.22 - or
are we only worried about 13.1 maintenance?

These are "standard" stable updates. They happen more or less
automatically already when Jiri Slaby has spare cycles.

Updating from 3.7 to 3.10 in 12.3 in spare cycles? I don't think that
will be fair to our users.

Greetings, Stephan

Jeff Mahoney

2013-12-09 00:21:05 UTC

Post by Takashi Iwai
Hi,
Since 3.11.y maintenance was discontinued by Greg, Ubuntu
took over it. It made me wonder: are we willing to continue
3.11.y for openSUSE 13.1 updates, just relying on Ubuntu?
Or, can we just move on 3.12.y?

That would also moving 12.2 to 3.4.72 and 12.3 to 3.10.22 - or
are we only worried about 13.1 maintenance?

These are "standard" stable updates. They happen more or less
automatically already when Jiri Slaby has spare cycles.

Updating from 3.7 to 3.10 in 12.3 in spare cycles? I don't think that
will be fair to our users.

Ah, I misread and didn't parse the release-version mapping. No, we don't
have any plans to propose something like that. Just normal long-term
-stable updates.

-Jeff

--
Jeff Mahoney
SUSE Labs

Wolfgang Rosenauer

2013-12-05 13:18:09 UTC

I'm pretty sure that during the 2.4 and 2.6 kernel series there were
patch level updates. Since the versioning changed the minor number is
more what the patch level was in the past and those we had for sure at
some point.
I'm not a kernel expert and don't follow it well and the decision should
be on the kernel maintainers side taking into consideration the risks
and benefits. I would propose some testing beforehand though. Probably
after preparation of such an update let it long enough in the update
test queue for example and announce its availability to a broader
audience notice it and give it a try.

Wolfgang

Greg Freemyer

2013-12-05 15:24:51 UTC

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past?

You should check with the Evergreen team, but I believe they change
the kernel out to align with the next newer SLES kernel. So if you
consider evergreen as part of openSUSE, then yes openSUSE has done
kernel version changes in the past.

(I haven't fully kept up with this, the kernel upgrade may be an
optional feature of Evergreen and not all users are upgraded.)

Greg

Marcus Meissner

2013-12-05 15:33:15 UTC

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past?

You should check with the Evergreen team, but I believe they change
the kernel out to align with the next newer SLES kernel. So if you
consider evergreen as part of openSUSE, then yes openSUSE has done
kernel version changes in the past.
(I haven't fully kept up with this, the kernel upgrade may be an
optional feature of Evergreen and not all users are upgraded.)

Its a Evergreen Feature.

This of course could be considerd for 13.1, to align with the SLE12 kernel.

Ciao, Marcus

Greg Freemyer

2013-12-05 16:12:09 UTC

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past?

You should check with the Evergreen team, but I believe they change
the kernel out to align with the next newer SLES kernel. So if you
consider evergreen as part of openSUSE, then yes openSUSE has done
kernel version changes in the past.
(I haven't fully kept up with this, the kernel upgrade may be an
optional feature of Evergreen and not all users are upgraded.)

Its a Evergreen Feature.
This of course could be considerd for 13.1, to align with the SLE12 kernel.
Ciao, Marcus

My google-foo is failing me. When is SLE12 expected to release? And
with what kernel?

And since 13.1 is already designated as a Evergreen supported release,
one could argue that updating the kernel to match a SLES kernel is
being done to align with 13.1's Evergreen designation. It certainly
seems it would lighten the load on the evergreen team to have 13.1
already at the LTS kernel level they prefer.

Clearly, I vote for updating the 13.1 kernel to align with Evergreen's
needs at some point in the next 18 months.

Greg

Marcus Meissner

2013-12-05 16:40:50 UTC

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past?

You should check with the Evergreen team, but I believe they change
the kernel out to align with the next newer SLES kernel. So if you
consider evergreen as part of openSUSE, then yes openSUSE has done
kernel version changes in the past.
(I haven't fully kept up with this, the kernel upgrade may be an
optional feature of Evergreen and not all users are upgraded.)

Its a Evergreen Feature.
This of course could be considerd for 13.1, to align with the SLE12 kernel.
Ciao, Marcus

My google-foo is failing me. When is SLE12 expected to release? And
with what kernel?

Second half of 2014.

Not sure I am allowed to tell the kernel version yet. But it is similar
to the product version.

Post by Greg Freemyer
And since 13.1 is already designated as a Evergreen supported release,
one could argue that updating the kernel to match a SLES kernel is
being done to align with 13.1's Evergreen designation. It certainly
seems it would lighten the load on the evergreen team to have 13.1
already at the LTS kernel level they prefer.
Clearly, I vote for updating the 13.1 kernel to align with Evergreen's
needs at some point in the next 18 months.

In the end, it would currently be mostly the call for Maintenance and
the Kernel Team.

Ciao, Marcus

Greg Freemyer

2013-12-05 16:50:52 UTC

Post by Greg Freemyer
Clearly, I vote for updating the 13.1 kernel to align with Evergreen's
needs at some point in the next 18 months.

In the end, it would currently be mostly the call for Maintenance and
the Kernel Team.

Well my hope is that only one kernel version update occur for the full
3-year life of 13.1 (including the evergreen period). Having that
upgrade occur prior to the transition to the evergreen team providing
support would be a nice value add.

Greg

--
Greg Freemyer

Jeff Mahoney

2013-12-05 17:18:44 UTC

Has the precedence been set of changing version of the kernel after
release, I don't remember it happening in the past?

You should check with the Evergreen team, but I believe they change
the kernel out to align with the next newer SLES kernel. So if you
consider evergreen as part of openSUSE, then yes openSUSE has done
kernel version changes in the past.
(I haven't fully kept up with this, the kernel upgrade may be an
optional feature of Evergreen and not all users are upgraded.)

Its a Evergreen Feature.
This of course could be considerd for 13.1, to align with the SLE12 kernel.
Ciao, Marcus

My google-foo is failing me. When is SLE12 expected to release? And
with what kernel?

Second half of 2014.
Not sure I am allowed to tell the kernel version yet. But it is similar
to the product version.

Yeah, you are. :)

The branch is already public. It's based on 3.12.

Using the SLE12 branch directly may be tricky since there are different
architecture targets for openSUSE and SLES. Unfortunately, those are
details I can't get into just yet. I can share that we are not building
32-bit kernels for any architecture, so a SLE12 kernel used on openSUSE
will have zero i586 testing performed on it as part of the SLE testing
matrix. While I certainly wouldn't mind it happening, I don't know of
any openSUSE plans to drop i586 support just yet.

-Jeff

--
Jeff Mahoney
SUSE Labs

Greg Freemyer

2013-12-05 17:49:03 UTC

Post by Jeff Mahoney
The branch is already public. It's based on 3.12.
Using the SLE12 branch directly may be tricky since there are different
architecture targets for openSUSE and SLES. Unfortunately, those are
details I can't get into just yet. I can share that we are not building
32-bit kernels for any architecture, so a SLE12 kernel used on openSUSE
will have zero i586 testing performed on it as part of the SLE testing
matrix. While I certainly wouldn't mind it happening, I don't know of
any openSUSE plans to drop i586 support just yet.

I don't think Evergreen uses the SLES kernel, but it does use the same
version as SLES and then it pulls in patches from the SLES kernel set
of patches. I don't think it pulls all of them in, but that is a
separate discussion.

So switching oS 13.1 to the 3.12 kernel may involve some significant
32-bit testing, but it should eliminate the openSUSE team having to
search for patches and then having to backport them to the 3.11
kernel. Hopefully the end result is a better kernel with less work
expended.

Greg
--
Greg Freemyer

Michal Kubecek

2013-12-06 09:01:14 UTC

Post by Jeff Mahoney
Using the SLE12 branch directly may be tricky since there are different
architecture targets for openSUSE and SLES. Unfortunately, those are
details I can't get into just yet. I can share that we are not building
32-bit kernels for any architecture, so a SLE12 kernel used on openSUSE
will have zero i586 testing performed on it as part of the SLE testing
matrix. While I certainly wouldn't mind it happening, I don't know of
any openSUSE plans to drop i586 support just yet.

Even if there were such plans, I have a feeling it is a bit late to do
that in 13.1 :-)

Post by Greg Freemyer
I don't think Evergreen uses the SLES kernel, but it does use the same
version as SLES and then it pulls in patches from the SLES kernel set
of patches. I don't think it pulls all of them in, but that is a
separate discussion.

The Evergreen 11.4 kernel is based on SLE 11 SP2 kernel with only few
code changes (IIRC I only removed the tricks making ext4 read-only and
picked a bit more of the ceph backports as the way it is done in
SLE11-SP2 breaks the build in parts which are disabled in SLE11-SP2 but
enabled in openSUSE-11.4) but with different config(s) and some changes
in the packaging.

Post by Greg Freemyer
From the technical point of view, I created a new branch from SLE11-SP2

at some point, merged the config files to match openSUSE-11.4 ones as
closely as possible and did the ext4 related changes (ceph ones came
later). Since then I keep merging SLE11-SP2 branch into evergreen-11.4
from time to time - usually once a week - or when a SLE11-SP2 update is
submitted. Evergreen 11.4 kernel updates match SLE 11 SP2 updates. As
there are almost no code changes, the conflicts are only in config/
and, of course, kabi/ must be updated independently.

For 13.1, IMHO the same approach based on SLE12 branch (i.e. SLE 12 GA)
would be the best solution (or the least bad one). This time I want to
start as soon as possible and provide the kernel as an alternative in
OBS so that we can get more testing before 13.1 regular support
finishes. But all this is still open to discussion - actually there has
been no discussion about Evergreen 13.1 kernel yet (except this thread).

Michal Kubeček

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Larry Finger

2013-12-05 18:23:28 UTC

I hope that i586 support is not dropped by openSUSE as I have 3 32-bit systems
running openSUSE 12.3 or 13.1.

Larry

Jean Delvare

2013-12-06 14:48:17 UTC

Post by Larry Finger

I hope that i586 support is not dropped by openSUSE as I have 3 32-bit systems
running openSUSE 12.3 or 13.1.

Same here, I still have 2 32-bit x86 machines I use daily, and a few old
laptops I may revive for testing or special tasks. So I hope openSUSE
will keep the i386 kernels for several years. At least until 2016 or
even 2018, remember that 32-bit x86 machines have been sold until 2008!

We may not have to keep all the flavors though. I suppose some of them
like ec2 or xen can go away if they are no longer needed, and trace,
debug and vanilla are not mandatory either if the user base shrinks. And
then I suppose we can keep only one or two of desktop, default and pae.
As long as I have one kernel which can boot all my old machines with
decent performance, I'm happy.

--
Jean Delvare
Suse L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Cristian Rodríguez

2013-12-07 17:12:41 UTC

El 05/12/13 14:18, Jeff Mahoney escribió:

I can share that we are not building

Post by Jeff Mahoney
32-bit kernels for any architecture, so a SLE12 kernel used on openSUSE
will have zero i586 testing performed on it as part of the SLE testing
matrix. While I certainly wouldn't mind it happening, I don't know of
any openSUSE plans to drop i586 support just yet.

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Greg Freemyer

2013-12-07 18:00:00 UTC

On Sat, Dec 7, 2013 at 12:12 PM, Cristian Rodríguez

Post by Jeff Mahoney
I can share that we are not building

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

As far as I know, VMplayer (free) only supports 32-bit, so until that
changes, openSUSE needs to offer a 32-bit version.

Changing the default should probably happen now. 64-bit is already
more popular to choose.

Greg

Andrey Borzenkov

2013-12-07 18:06:40 UTC

В Sat, 7 Dec 2013 13:00:00 -0500

Post by Greg Freemyer
On Sat, Dec 7, 2013 at 12:12 PM, Cristian Rodríguez

Post by Jeff Mahoney
I can share that we are not building

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

As far as I know, VMplayer (free) only supports 32-bit, so until that
changes, openSUSE needs to offer a 32-bit version.

Player supports 64 bit on suitable hardware (you need hardware
virtualization support).

Post by Greg Freemyer
Changing the default should probably happen now. 64-bit is already
more popular to choose.
Greg

Greg Freemyer

2013-12-08 03:07:48 UTC

Post by Andrey Borzenkov
В Sat, 7 Dec 2013 13:00:00 -0500

Post by Greg Freemyer
On Sat, Dec 7, 2013 at 12:12 PM, Cristian Rodríguez

Post by Jeff Mahoney
I can share that we are not building

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

As far as I know, VMplayer (free) only supports 32-bit, so until that
changes, openSUSE needs to offer a 32-bit version.

Player supports 64 bit on suitable hardware (you need hardware
virtualization support).

That's a significant requirement that lots of current hardware doesn't meet.

32-bit looks like it will hang around for long time as far as I'm
concerned. I'm actually surprised SLES is able to ignore that user
group, but that is not relevant to this list.

Greg

Cristian Rodríguez

2013-12-08 04:40:26 UTC

El 08/12/13 00:07, Greg Freemyer escribió:

I'm actually surprised SLES is able to ignore that user

Post by Greg Freemyer
group, but that is not relevant to this list.

SLE is sold to be used with certified hardware.. I am pretty sure SUSE
would keep providing i586 support if there was enough demand to justify
the investment. Also note that we are talking about a product that will
hit the market in late 2014.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Jeff Mahoney

2013-12-08 18:45:15 UTC

Post by Andrey Borzenkov
В Sat, 7 Dec 2013 13:00:00 -0500

Post by Greg Freemyer
On Sat, Dec 7, 2013 at 12:12 PM, Cristian Rodríguez

Post by Jeff Mahoney
I can share that we are not building

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

As far as I know, VMplayer (free) only supports 32-bit, so until that
changes, openSUSE needs to offer a 32-bit version.

Player supports 64 bit on suitable hardware (you need hardware
virtualization support).

That's a significant requirement that lots of current hardware doesn't meet.
32-bit looks like it will hang around for long time as far as I'm
concerned. I'm actually surprised SLES is able to ignore that user
group, but that is not relevant to this list.

SLES users tend not to dig out old hardware to run a new version of the
OS on it. PAE was an architectural workaround and there's no excuse to
use it anymore now that we've had real 64-bit mode for a long time. The
4 GB limit is way too low for anything but the smallest server workloads
especially when you account for the fact that it basically locks you
into never adding more memory at full performance.

-Jeff

--
Jeff Mahoney
SUSE Labs
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Dave Howorth

2013-12-09 10:25:15 UTC

Post by Andrey Borzenkov
В Sat, 7 Dec 2013 13:00:00 -0500

Post by Greg Freemyer
On Sat, Dec 7, 2013 at 12:12 PM, Cristian Rodríguez

Post by Cristian RodrÃguez
Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

32-bit looks like it will hang around for long time as far as I'm
concerned. I'm actually surprised SLES is able to ignore that user
group, but that is not relevant to this list.

SLES users tend not to dig out old hardware to run a new version of the
OS on it.

But openSUSE users do want to be able to run new versions of the OS on
existing hardware. Not everybody is in a position to rush out and buy
the latest sparkly goodies, even at Xmas. And as has been pointed out,
there are ethical questions with encouraging trashing of otherwise good
machines.

So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Stephan Kulow

2013-12-09 10:47:34 UTC

Post by Dave Howorth
So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

I don't think openSUSE needs to please *everyone*. We can easily drop
i586 to the same status as e.g. arm has now: we still build for it,
but we don't give guarantees.

Not saying it will happen 2013, but it's a viable option for the future.
"nobody wants it" will never happen.

Greetings, Stephan

Dave Howorth

2013-12-09 11:39:10 UTC

Post by Dave Howorth
So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

I don't think openSUSE needs to please *everyone*. We can easily drop
i586 to the same status as e.g. arm has now: we still build for it,
but we don't give guarantees.
Not saying it will happen 2013, but it's a viable option for the future.
"nobody wants it" will never happen.
Greetings, Stephan

Yes, I did consider the potential problem of using normal English among
a literal-minded audience. So please substitute a suitably precise
phrase of your choice for the word nobody, compatible with the
explicatory 'make the decision based on user demand'.

Greg Freemyer

2013-12-09 13:22:10 UTC

Post by Dave Howorth
So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

I don't think openSUSE needs to please *everyone*. We can easily drop
i586 to the same status as e.g. arm has now: we still build for it,
but we don't give guarantees.
Not saying it will happen 2013, but it's a viable option for the future.
"nobody wants it" will never happen.
Greetings, Stephan

Is there some reason not to change the download pages default to 64 bit now? Does it need to wait for 13.2 for some reason?

Greg

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Stephan Kulow

2013-12-09 13:36:28 UTC

Post by Dave Howorth
So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

I don't think openSUSE needs to please *everyone*. We can easily drop
i586 to the same status as e.g. arm has now: we still build for it,
but we don't give guarantees.
Not saying it will happen 2013, but it's a viable option for the future.
"nobody wants it" will never happen.
Greetings, Stephan

Is there some reason not to change the download pages default to 64 bit now? Does it need to wait for 13.2 for some reason?

Send a pull request: https://github.com/openSUSE/software-o-o

Greetings, Stephan

Jeff Mahoney

2013-12-09 17:58:01 UTC

Post by Dave Howorth

Ð Sat, 7 Dec 2013 13:00:00 -0500

On Sat, Dec 7, 2013 at 12:12 PM, Cristian RodrÃguez

32-bit looks like it will hang around for long time as far as I'm
concerned. I'm actually surprised SLES is able to ignore that user
group, but that is not relevant to this list.

SLES users tend not to dig out old hardware to run a new version of the
OS on it.

But openSUSE users do want to be able to run new versions of the OS on
existing hardware. Not everybody is in a position to rush out and buy
the latest sparkly goodies, even at Xmas. And as has been pointed out,
there are ethical questions with encouraging trashing of otherwise good
machines.
So I suggest openSUSE forgets about stopping building 32-bit versions
until there is good evidence that nobody wants it. i.e. make the
decision based on user demand.

Absolutely. I'm just explaining the reasons for not supporting it any
longer with SLES. That's the decision made based on user demand. I'm not
proposing that the same demands exist in the openSUSE community. My
initial comment was more my personal opinion as someone who doesn't have
any 32-bit hardware left.

-Jeff

--
Jeff Mahoney
SUSE Labs

Felix Miata

2013-12-07 18:15:28 UTC

Post by Jeff Mahoney
I can share that we are not building

Wow, that's good news, for openSUSE we must start by changing the
download pages that default to 32 bit isos.. then slowly fade i586
away.. I propose 2 releases from now on.

I propose do no fade in foreseeable future, and beyond. I only started doing
any 64 bit installs on my own 64 bit capable systems less than a year ago,
and observe more cost than benefit except for video applications (and
virtualization, which I don't do). I have far more non-capable systems in use
than capable, and find whatever benefit 64 bit has over 32 to be outweighed
by the *nuisances* and worse that 64 brings:

1-Requires more installation space due to need for various 32 bit libs
2-More RAM used per app and by OS
3-Lack of various native 64 bit plugins and certain apps
4-Lack of apparent speed benefit in popular apps
5-Increasing RAM above 1G or 2G is not cheap when mobo has .5G, 1G or 2G
limit, requiring not only newer mobo, but most likely newer CPU and RAM and
burdening landfills with otherwise useful equipment
6-inefficient zypper https://features.opensuse.org/316759

Email, social media, banking, shopping & other common computing tasks do not
require fast multicore CPUs, 4G+ RAM and 8G+ broadband connectivity. Thus 64
bit for such use offers no material advantages, and comes with non-zero cost.
Dropping 32 bit while useful 32 bit systems remain plentiful and useful is
ecologically repugnant.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Stefan Seyfried

2013-12-07 20:56:18 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs
2-More RAM used per app and by OS

Those two are also important for virtual machines (appliances for example).

Post by Felix Miata
3-Lack of various native 64 bit plugins and certain apps
4-Lack of apparent speed benefit in popular apps

64bit is never faster. It just allows to address more memory, but unless
you need to address way more than a few GB, it does not bring any benefits.

So yeah, go ahead and drop support for i586. One more way to make
openSUSE less useful...

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw

Carlos E. R.

2013-12-07 21:06:00 UTC

Post by Stefan Seyfried
So yeah, go ahead and drop support for i586. One more way to make
openSUSE less useful...

There are many people using 32 machines out there, silently. My
workhorses are 64 bit, but I also have 32 bit machines, one of them
running 24/7. I can buy cheap old computers or laptops and use them
for simple tasks.

And then there are many people out there in less privileged countries
using older or simpler hardware. We would ban them, out of openSUSE
for ever.

- --
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)

Michal Kubecek

2013-12-07 22:21:00 UTC

Even if I got rid of my last 32-bit system on a physical machine more
than five years ago, I agree that we shouldn't drop i586 support in
OpenSuSE yet.

For example, for last few versions I've been seeding OpenSuSE images via
bittorent and 13.1 is the first where I have significantly bigger share
ratio for x86_64 image than for i586 one. So far, the ratio is about 2:1,
even for 12.3 the difference was only marginal. Personally, I consider
this quite sad but I think we can't ignore the fact that a lot of our
users keep using i586 for various reasons even if then don't need to.

That being said...

Post by Stefan Seyfried
64bit is never faster. It just allows to address more memory, but unless
you need to address way more than a few GB, it does not bring any benefits.

On the other hand, I really don't think we should use claims like this
to support keeping of i586 because everyone can simply check that this
is far from being true. For example, let's take the openssl binary from
our 12.3 package (x86_64 and i586) and run "openssl speed rsa1024" (on
the same system):

x86_64:
sign verify sign/s verify/s
rsa 1024 bits 0.000221s 0.000014s 4517.3 72704.6

i586:
sign verify sign/s verify/s
rsa 1024 bits 0.000890s 0.000044s 1123.2 22788.6

There _are_ benefits of x86_64 and x86_64 is sometimes faster than i586
- and sometimes it is _way_ faster than i586. And you don't need
applications using gigabytes of memory. On x86_64, we can process more
data in one instruction and we have more registers available - which is
also reflected in much more efficient ABI.

Michal Kubeček

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Cristian Rodríguez

2013-12-07 22:31:29 UTC

Post by Michal Kubecek
Even if I got rid of my last 32-bit system on a physical machine more
than five years ago, I agree that we shouldn't drop i586 support in
OpenSuSE yet.

That's why I proposed to first change the default offer in the download
page which currently defaults to i586 iso , then deprecate the arch and
then after a few more releases (2 at least) drop the build completely.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Greg Freemyer

2013-12-08 03:15:52 UTC

Post by Cristian RodrÃguez

On Sat, Dec 7, 2013 at 5:31 PM, Cristian Rodríguez

Post by Michal Kubecek
Even if I got rid of my last 32-bit system on a physical machine more
than five years ago, I agree that we shouldn't drop i586 support in
OpenSuSE yet.

I agree with changing the default. 64-bit is finally more popular
than 32-bit so the default should change.

But I'd be willing to bet openSUSE will still have x86 ISOs in 2016
(which seems to be the year of prediction for openSUSE).

Greg

Jeff Mahoney

2013-12-08 18:39:29 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs
2-More RAM used per app and by OS

Those two are also important for virtual machines (appliances for example).

Post by Felix Miata
3-Lack of various native 64 bit plugins and certain apps
4-Lack of apparent speed benefit in popular apps

64bit is never faster. It just allows to address more memory, but unless
you need to address way more than a few GB, it does not bring any benefits.
So yeah, go ahead and drop support for i586. One more way to make
openSUSE less useful...

64-bit mode has access to twice the general purpose registers, so it
/can/ actually be faster.

-Jeff

--
Jeff Mahoney
SUSE Labs

Jiri Kosina

2013-12-12 10:30:35 UTC

Post by Stefan Seyfried
64bit is never faster.

Where did you get this information from, please?

The code generated for x86_64 can be much faster in data operations,
because compiler can make use of wider range of CPU registers, and
register access is obviously faster than accessing memory.

--
Jiri Kosina
SUSE Labs

Stefan Seyfried

2013-12-12 11:03:34 UTC

Post by Jiri Kosina

Post by Stefan Seyfried
64bit is never faster.

Where did you get this information from, please?

yes, that was a bit bold :-)

Let's rephrase "64 bit is not necessarily faster".

Post by Jiri Kosina
The code generated for x86_64 can be much faster in data operations,
because compiler can make use of wider range of CPU registers, and
register access is obviously faster than accessing memory.

And cache is faster than memory, too, so 64 bit code with its higher
memory footprint might be slower :-)

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw

Alexander Graf

2013-12-12 11:10:13 UTC

Post by Jiri Kosina

Post by Stefan Seyfried
64bit is never faster.

Where did you get this information from, please?

yes, that was a bit bold :-)
Let's rephrase "64 bit is not necessarily faster".

And cache is faster than memory, too, so 64 bit code with its higher
memory footprint might be slower :-)

So according to that logic we should only have an x32 (x86_64 with 32-bit long/pointers) and a full x86_64 distribution right? No need for i386 :)

Alex

Jiri Kosina

2013-12-12 13:01:08 UTC

And cache is faster than memory, too, so 64 bit code with its higher
memory footprint might be slower :-)

Linux x32 ABI is trying to overcome at least the "data" portion of this
problem (of course instriction cache would still need to operate on 64
bits).

--
Jiri Kosina
SUSE Labs

Stefan Seyfried

2013-12-12 14:20:08 UTC

Post by Jiri Kosina
Linux x32 ABI is trying to overcome at least the "data" portion of this
problem (of course instriction cache would still need to operate on 64
bits).

Ok, but I don't think we are using this, yet. At least I can see clearly
much higher memory demand on x86_64 than on i586 (a desktop with just
1GB of RAM is totally unusable on x86_64, while it works well on an old
i686. Same config with XFCE, Thunderbird, Firefox).

But as I wrote further up in the thread, *I* don't mind if openSUSE
drops i586, because thanks to LF's yocto project, I don't mind just
building my own distribution. Might be less annoying in the long run
anyway :-)

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw

Jean Delvare

2013-12-08 17:42:19 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs

That's true, and I don't get it. On a freshly installed 13.1 x86_64
system, I have 63 32bit packages installed, for a total of over 41 MB.
I see I need glibc-32bit for master-boot-code (which surprisingly is
only built for i586), but the remaining ones I have no idea. If I ask
zypper to remove them all but glibc-32bit, it says it would be happy to
do so, so there are no dependencies.

So I am really curious why these are installed by default. What do I
get from having systemd-32bit, samba-32bit, pam-32bit etc. installed on
a 64-bit system?

--
Jean Delvare
Suse L3 Support

Cristian Rodríguez

2013-12-08 17:56:43 UTC

Post by Jean Delvare
So I am really curious why these are installed by default. What do I
get from having systemd-32bit, samba-32bit, pam-32bit etc. installed on
a 64-bit system?

Those are recommended packages, if you upgrade with --no-recommends they
are not installed.

I disagree with the addition of these 32bit "recommends" as well.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Stefan Seyfried

2013-12-08 18:49:37 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs

well, it is real mode x86 code, so it is probably not even 32bit, but
16bit code :-), but why the hell this needs glibc? It needs to fit into
432 bytes IIRC, so glibc is certainly not used by it...

Smells like a packaging bug.

Ok, i checked it. It is for "fixmbr", but I think this could easily be
built as 64bit program. Or shell/perl script...

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw

Hannes Reinecke

2013-12-09 07:10:06 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs

well, it is real mode x86 code, so it is probably not even 32bit, but
16bit code :-), but why the hell this needs glibc? It needs to fit into
432 bytes IIRC, so glibc is certainly not used by it...
Smells like a packaging bug.
Ok, i checked it. It is for "fixmbr", but I think this could easily be
built as 64bit program. Or shell/perl script...

And it's obsolete for EFI systems. Brilliant.

Already filed a bug?
If so, can you add me to Cc?

Cheers,

Hannes

--
Dr. Hannes Reinecke zSeries & Storage
hare-***@public.gmane.org +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Stefan Seyfried

2013-12-09 09:06:18 UTC

Post by Hannes Reinecke
Already filed a bug?

No, I have 32bit glibc installed anyway, so I don't really care ;-)

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw

Jean Delvare

2013-12-09 10:36:44 UTC

Hi Hannes, Stefan,

Post by Hannes Reinecke

Post by Stefan Seyfried
Smells like a packaging bug.
Ok, i checked it. It is for "fixmbr", but I think this could easily be
built as 64bit program. Or shell/perl script...

Yes, that's exactly the problem.

Post by Hannes Reinecke
And it's obsolete for EFI systems. Brilliant.

Not sure what problem you are pointing at exactly?

Post by Hannes Reinecke
Already filed a bug?
If so, can you add me to Cc?

Steffen Winterfeld did almost 4 years ago:
https://bugzilla.novell.com/show_bug.cgi?id=573445

--
Jean Delvare
Suse L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Jean Delvare

2013-12-09 11:48:59 UTC

Post by Hannes Reinecke
Already filed a bug?
If so, can you add me to Cc?

https://bugzilla.novell.com/show_bug.cgi?id=573445

Actually Roman Fietze reported it, Steffen is the bug assignee.

--
Jean "I can't read a bug report" Delvare
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Marcus Meissner

2013-12-09 10:29:19 UTC

Post by Felix Miata
1-Requires more installation space due to need for various 32 bit libs

That's true, and I don't get it. On a freshly installed 13.1 x86_64
system, I have 63 32bit packages installed, for a total of over 41 MB.
I see I need glibc-32bit for master-boot-code (which surprisingly is
only built for i586), but the remaining ones I have no idea. If I ask
zypper to remove them all but glibc-32bit, it says it would be happy to
do so, so there are no dependencies.
So I am really curious why these are installed by default. What do I
get from having systemd-32bit, samba-32bit, pam-32bit etc. installed on
a 64-bit system?

The PAM configuration is agnostic to biarch, it actually is for both.

Thats why all packags with PAM modules Recommend their -32bit equivalent.

Otherwise you might find missing PAM snippets if there is ever a 32bit
program trying to do PAM.

Ciao, marcus

Jean Delvare

2013-12-09 11:01:32 UTC

Hi Marcus,

Post by Jean Delvare
So I am really curious why these are installed by default. What do I
get from having systemd-32bit, samba-32bit, pam-32bit etc. installed on
a 64-bit system?

The PAM configuration is agnostic to biarch, it actually is for both.
Thats why all packags with PAM modules Recommend their -32bit equivalent.
Otherwise you might find missing PAM snippets if there is ever a 32bit
program trying to do PAM.

But wouldn't that program be responsible for requiring pam-32bit then?
Actually it seems to be the case, for example systemd-32bit does require
pam-32bit. So this explains why pam-32bit is installed.

What I really need to know is what systemd-32bit itself is good for.
Nothing requires it, and the package description doesn't say anything
about that sub-package specifically. Same for samba-32bit.

--
Jean Delvare
Suse L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Marcus Meissner

2013-12-09 11:03:13 UTC

Post by Jean Delvare
Hi Marcus,

Post by Jean Delvare
So I am really curious why these are installed by default. What do I
get from having systemd-32bit, samba-32bit, pam-32bit etc. installed on
a 64-bit system?

The PAM configuration is agnostic to biarch, it actually is for both.
Thats why all packags with PAM modules Recommend their -32bit equivalent.
Otherwise you might find missing PAM snippets if there is ever a 32bit
program trying to do PAM.

But wouldn't that program be responsible for requiring pam-32bit then?
Actually it seems to be the case, for example systemd-32bit does require
pam-32bit. So this explains why pam-32bit is installed.
What I really need to know is what systemd-32bit itself is good for.
Nothing requires it, and the package description doesn't say anything
about that sub-package specifically. Same for samba-32bit.

Well yes, but all the PAM modules are not required by main PAM package...

So main PAM does not know about the systemd pam module, or about the opie pam module
or the samba-winbinds pam module or the ecryptfs pam module.

Ciao, Marcus

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Felix Miata

2013-12-05 13:58:28 UTC

Post by Takashi Iwai
Since 3.11.y maintenance was discontinued by Greg, Ubuntu took over
it. It made me wonder: are we willing to continue 3.11.y for openSUSE
13.1 updates, just relying on Ubuntu? Or, can we just move on 3.12.y?

Fedora 17 Fedora 18 Fedora 19 Fedora 20
Release kernel 3.3.4 3.6.10 3.9.5 3.11.10
Updates latest 3.9.10 3.11.9 3.11.9 -------

Given kernel history for Fedora, I wonder about the apparent conservatism for
update kernels for openSUSE. I've never been able to observe a problem using
a kernel from Kernel:/stable/standard instead of an official kernel in any
openSUSE release. What's the risk in moving up officially?

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

Bruno Friedmann

2013-12-05 15:02:39 UTC

Fedora 17 Fedora 18 Fedora 19 Fedora 20
Release kernel 3.3.4 3.6.10 3.9.5 3.11.10
Updates latest 3.9.10 3.11.9 3.11.9 -------
Given kernel history for Fedora, I wonder about the apparent conservatism for
update kernels for openSUSE. I've never been able to observe a problem using
a kernel from Kernel:/stable/standard instead of an official kernel in any
openSUSE release. What's the risk in moving up officially?

Well there's always a risk, for example a working v.1x driver for a storage adapter suddendly bump to 2.x
and doesn't work anymore, or need firwmware update etc ...
(I face that one with still two kind of controler not being able to work since 3.2 kernel :-()

I'm not against but we have to put it in longer queue, and/or ask for more testing kernel-stable
to Be sure everybody knows.

--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot

Jean Delvare

2013-12-06 15:30:17 UTC

Fedora 17 Fedora 18 Fedora 19 Fedora 20
Release kernel 3.3.4 3.6.10 3.9.5 3.11.10
Updates latest 3.9.10 3.11.9 3.11.9 -------
Given kernel history for Fedora, I wonder about the apparent conservatism for
update kernels for openSUSE. I've never been able to observe a problem using
a kernel from Kernel:/stable/standard instead of an official kernel in any
openSUSE release. What's the risk in moving up officially?

Despite Linus's hopes, the kernel interface changes over time. Old
things get dropped, broken things get fixed with side effects. Plus
every kernel comes with its load of regressions. At one time upstream
was actually tracking them, see for example:
https://bugzilla.kernel.org/show_bug.cgi?id=16055
That's about 150 regression in a single kernel version.

The last available list is for kernel 3.7, but the last few lists only
had a few bug numbers. I doubt the kernels have suddenly become
regression-free, most likely nobody is tracking the regressions any
longer, but I suppose the amount of regressions is about the same - one
or two hundreds.

Thankfully most bugs end up getting fixed. But this means that, if we
really intend to switch to a more recent kernel tree, we better wait for
the new kernel branch to have matured. So it may make sense to stick to
3.11 as long as Ubuntu maintains it (and we can help them with that) and
jump to 3.12 later.

Also keep in mind that some other packages depend on the kernel package.
For example the nvidia binary driver. You may not like it (I don't...)
but people are using it, and it is known that there is lag between every
new kernel and its support by Nvidia. AFAIK 13.1 still doesn't have this
driver available. Some users are probably waiting for availability
before they switch to 13.1. When this happens, if the week after we
change the kernel version and that breaks their graphics driver again,
they will hate us.

So, I am not objecting to changing the kernel version in flight, but I'm
saying that great care should be taken if we decide to do it. All
dependencies must be carefully taken into account, and the timing must
be right too.

--
Jean Delvare
Suse L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Bruno Friedmann

2013-12-06 15:39:06 UTC

Post by Jean Delvare
Also keep in mind that some other packages depend on the kernel package.
For example the nvidia binary driver. You may not like it (I don't...)
but people are using it, and it is known that there is lag between every
new kernel and its support by Nvidia. AFAIK 13.1 still doesn't have this
driver available. Some users are probably waiting for availability
before they switch to 13.1. When this happens, if the week after we
change the kernel version and that breaks their graphics driver again,
they will hate us.

They already hate us, for not having them available. But on that specific subject the good news is
the 331.20 nvidia is compatible with 3.12x kernel.
The package prepared by sndhirsh build at least. and people have reported success of using this nvidia version
under 3.12 kernel branch.

--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot

nirsuse

2013-12-06 16:03:11 UTC

Fedora 17 Fedora 18 Fedora 19 Fedora 20
Release kernel 3.3.4 3.6.10 3.9.5 3.11.10
Updates latest 3.9.10 3.11.9 3.11.9 -------
Given kernel history for Fedora, I wonder about the apparent conservatism for
update kernels for openSUSE. I've never been able to observe a problem using
a kernel from Kernel:/stable/standard instead of an official kernel in any
openSUSE release. What's the risk in moving up officially?

Despite Linus's hopes, the kernel interface changes over time. Old
things get dropped, broken things get fixed with side effects. Plus
every kernel comes with its load of regressions. At one time upstream
https://bugzilla.kernel.org/show_bug.cgi?id=16055
That's about 150 regression in a single kernel version.
The last available list is for kernel 3.7, but the last few lists only
had a few bug numbers. I doubt the kernels have suddenly become
regression-free, most likely nobody is tracking the regressions any
longer, but I suppose the amount of regressions is about the same - one
or two hundreds.
Thankfully most bugs end up getting fixed. But this means that, if we
really intend to switch to a more recent kernel tree, we better wait for
the new kernel branch to have matured. So it may make sense to stick to
3.11 as long as Ubuntu maintains it (and we can help them with that) and
jump to 3.12 later.
Also keep in mind that some other packages depend on the kernel package.
For example the nvidia binary driver. You may not like it (I don't...)
but people are using it, and it is known that there is lag between every
new kernel and its support by Nvidia. AFAIK 13.1 still doesn't have this
driver available. Some users are probably waiting for availability
before they switch to 13.1. When this happens, if the week after we
change the kernel version and that breaks their graphics driver again,
they will hate us.
So, I am not objecting to changing the kernel version in flight, but I'm
saying that great care should be taken if we decide to do it. All
dependencies must be carefully taken into account, and the timing must
be right too.

I Don't think that we should depend on ubuntu team , i think that we
should move to kernel 3.12 when it be stable enough for our taste and
not as long ubuntu maintain kernel 3.11. and what ever you decide (if it
kernel 3.12) let test it and sooner the better

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Greg KH

2013-12-05 15:17:37 UTC

I'd recommend moving to 3.12.y for a number of reasons.

I've been using it in tumbleweed:testing for a while now with no
problems, if you want some expanded coverage at the moment, I'd be glad
to move it to Tumbleweed "proper" today.

Actually, I'll go do that anyway, can't hurt...

thanks,

greg k-h

Jiri Slaby

2013-12-08 07:57:45 UTC

Post by Greg KH

I'd recommend moving to 3.12.y for a number of reasons.

One of those is that 3.12 will be a longterm (handled by me) if
everything goes as planned...

--
js
suse labs

Jean Delvare

2014-06-06 09:50:17 UTC

Hi all,

Reviving an old discussion... It's been 6 months, and as far as I can
see no decision was made. We did not move to 3.12.y, but we also did not
move to Ubuntu's 3.11.10.z extended stable branch. While I am a little
disappointed by the return of 4-number versions, I still believe that
using Ubuntu's work as a base for openSUSE 13.1 would improve the
overall quality of our kernel.

As an example, we had a bug report yesterday about a firewire bug which
is already fixed in Ubuntu's 3.11.10.7 kernel, which was released 2
months ago.

I don't really care if we stick to 3.11 or move to 3.12, but any
solution based on an extended stable or longterm tree seems better to me
than what we have right now.

--
Jean Delvare
SUSE L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Greg KH

2014-06-06 15:48:24 UTC

Post by Jean Delvare
Hi all,

Reviving an old discussion... It's been 6 months, and as far as I can
see no decision was made. We did not move to 3.12.y, but we also did not
move to Ubuntu's 3.11.10.z extended stable branch. While I am a little
disappointed by the return of 4-number versions, I still believe that
using Ubuntu's work as a base for openSUSE 13.1 would improve the
overall quality of our kernel.
As an example, we had a bug report yesterday about a firewire bug which
is already fixed in Ubuntu's 3.11.10.7 kernel, which was released 2
months ago.
I don't really care if we stick to 3.11 or move to 3.12, but any
solution based on an extended stable or longterm tree seems better to me
than what we have right now.

I would recommend moving to 3.12, and take advantage of the work being
done there on that stable tree. But as I'm not an opensuse maintainer,
my vote doesn't really matter much :)

thanks,

greg k-h

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Giacomo Comes

2014-06-06 18:38:28 UTC

Post by Greg KH

Post by Jean Delvare
Hi all,

Reviving an old discussion... It's been 6 months, and as far as I can
see no decision was made. We did not move to 3.12.y, but we also did not
move to Ubuntu's 3.11.10.z extended stable branch. While I am a little
disappointed by the return of 4-number versions, I still believe that
using Ubuntu's work as a base for openSUSE 13.1 would improve the
overall quality of our kernel.
As an example, we had a bug report yesterday about a firewire bug which
is already fixed in Ubuntu's 3.11.10.7 kernel, which was released 2
months ago.
I don't really care if we stick to 3.11 or move to 3.12, but any
solution based on an extended stable or longterm tree seems better to me
than what we have right now.

I would recommend moving to 3.12, and take advantage of the work being
done there on that stable tree. But as I'm not an opensuse maintainer,
my vote doesn't really matter much :)

I have a laptop with a ValleyView graphic chipset and it has some
problems with 3.11 kernel (is shows a ghost vga monitor attached,
the display stays black after sleep, etc). Such problems are fixed
in 3.12 so I have a good reason to ask for moving to 3.12.

Giacomo

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Takashi Iwai

2014-06-08 09:55:01 UTC

At Fri, 6 Jun 2014 14:38:28 -0400,

Post by Giacomo Comes

Post by Greg KH

Post by Jean Delvare
Hi all,

Reviving an old discussion... It's been 6 months, and as far as I can
see no decision was made. We did not move to 3.12.y, but we also did not
move to Ubuntu's 3.11.10.z extended stable branch. While I am a little
disappointed by the return of 4-number versions, I still believe that
using Ubuntu's work as a base for openSUSE 13.1 would improve the
overall quality of our kernel.
As an example, we had a bug report yesterday about a firewire bug which
is already fixed in Ubuntu's 3.11.10.7 kernel, which was released 2
months ago.
I don't really care if we stick to 3.11 or move to 3.12, but any
solution based on an extended stable or longterm tree seems better to me
than what we have right now.

I would recommend moving to 3.12, and take advantage of the work being
done there on that stable tree. But as I'm not an opensuse maintainer,
my vote doesn't really matter much :)

IMO, moving to 3.12 is good for SUSE, too. It means more test
coverage. The openSUSE kernel may take different kernel configs, but
the kernel code base itself can be shared with SLE12.

Takashi

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Jiri Slaby

2014-06-11 08:09:55 UTC

Post by Takashi Iwai
IMO, moving to 3.12 is good for SUSE, too. It means more test
coverage. The openSUSE kernel may take different kernel configs, but
the kernel code base itself can be shared with SLE12.

Hi, I tend to agree (as a biased 3.12 maintainer and -stable "merger" to
our repos). However this discussion is recurring and the switch was
denied last time. The reasons are obvious, fear of regressions. But
provided the stable-3.12 branch receives much more
* fixes and
* testing
than the openSUSE branch, I now recommend the move to 3.12 too.

This should be re-evaluated at the proper posts like openSUSE PRJ
manager or whoever can decide now IMHO?

thanks,

--
js
suse labs

Gerald Pfeifer

2014-06-12 09:55:55 UTC

Post by Jiri Slaby

Post by Takashi Iwai
IMO, moving to 3.12 is good for SUSE, too. It means more test
coverage. The openSUSE kernel may take different kernel configs,
but the kernel code base itself can be shared with SLE12.

To me, this is a question that should be largely independent of
what SUSE does around SUSE Linux Enterprise 12 (though I'll admit
that can be another gentle nudge).

Post by Jiri Slaby
Hi, I tend to agree (as a biased 3.12 maintainer and -stable "merger"
to our repos). However this discussion is recurring and the switch
was denied last time. The reasons are obvious, fear of regressions.
But provided the stable-3.12 branch receives much more
* fixes and
* testing
than the openSUSE branch, I now recommend the move to 3.12 too.
From all I know, upstream is not keen to introduce regressions, or

at least let them live for long.

And my regular test usage of Fedora over the years has shown that
at least for everything I did that fear for regressions was pretty
unfounded.

My recommendation is to just go for it.

(If we want to be on the cautious side, how about providing a preview
of such an upgrade, asking a wider group of users to give it a try, and
wait three weeks, say, before releasing that as a regular update?)

Gerald

--
Dr. Gerald Pfeifer <gp-IBi9RG/***@public.gmane.org>
Sr. Director Product Management and Operations, SUSE

Jiri Slaby

2014-06-22 20:48:03 UTC

Post by Gerald Pfeifer

Post by Jiri Slaby

Post by Takashi Iwai
IMO, moving to 3.12 is good for SUSE, too. It means more test
coverage. The openSUSE kernel may take different kernel configs,
but the kernel code base itself can be shared with SLE12.

To me, this is a question that should be largely independent of
what SUSE does around SUSE Linux Enterprise 12 (though I'll admit
that can be another gentle nudge).

From all I know, upstream is not keen to introduce regressions, or
at least let them live for long.
And my regular test usage of Fedora over the years has shown that
at least for everything I did that fear for regressions was pretty
unfounded.
My recommendation is to just go for it.

Anyone wants to give it a try?

http://download.opensuse.org/repositories/home:/jirislaby:/os_13.1_3.12/standard/

--
js
suse labs

Felix Miata

2014-06-22 22:47:37 UTC

Post by Jiri Slaby
http://download.opensuse.org/repositories/home:/jirislaby:/os_13.1_3.12/standard/

After doing zypper up with kernel locked, I installed to 32 bit host gx270.
On first attempt to reboot it took several minutes to get to

SIGTERM
SIGKILL
Unmounting file systems.

and took several more minutes to get to umounting the 4 nfs mounts, which
took a _whole_ _lot_ more time to get through before plodding slowly through
the virtual filesystems, and then starting to umount the same 4 nfs mounts,
after which I pulled the plug. Selecting to boot the new kernel from the Grub
menu just returns the Grub menu. At least the previous kernel still works.

Andrey Borzenkov

2014-06-23 05:36:13 UTC

В Sun, 22 Jun 2014 18:47:37 -0400

Post by Jiri Slaby
http://download.opensuse.org/repositories/home:/jirislaby:/os_13.1_3.12/standard/

After doing zypper up with kernel locked, I installed to 32 bit host gx270.
On first attempt to reboot it took several minutes to get to
SIGTERM
SIGKILL
Unmounting file systems.

I'm afraid I do not understand - was it reboot after installation still
running old kernel, to activate new one, or was it reboot after you
booted with new kernel?

Post by Felix Miata
and took several more minutes to get to umounting the 4 nfs mounts, which
took a _whole_ _lot_ more time to get through before plodding slowly through
the virtual filesystems, and then starting to umount the same 4 nfs mounts,
after which I pulled the plug. Selecting to boot the new kernel from the Grub
menu just returns the Grub menu. At least the previous kernel still works.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-kernel+owner-***@public.gmane.org

Felix Miata

2014-06-23 06:34:31 UTC

Post by Andrey Borzenkov

Post by Felix Miata
After doing zypper up with kernel locked, I installed to 32 bit host gx270.
On first attempt to reboot it took several minutes to get to
SIGTERM
SIGKILL
Unmounting file systems.

I'm afraid I do not understand - was it reboot after installation still
running old kernel, to activate new one, or was it reboot after you
booted with new kernel?

I didn't proofread well enough. After the zypper dup with kernel locked I
unlocked kernel and repeated zypper dup to get Jiri's 3.12 installed.

Post by Andrey Borzenkov

3.12 never loaded before I posted. All that sloth was trying to reboot from
3.11.10-7 to make a first try on Jiri's 3.12. Booting with 3.11 since trying
to boot 3.12 allowed shutdown/reboot to proceed normally.

My master Grubs only refer to vmlinuz/initrd, vmlinuz-prv/initrd-prv,
vmlinuz-prv2/initrd-prv2, etc., so that installing new kernels requires no
edits to the primarily used master Grubs. The create process for the 3.12
initrd broke. 3.12 now boots, runs KDE4 & Firefox 17 esr, and shuts down
satisfactorily, so far at least.

I need more sleep than I've been getting.

Manfred Hollstein

2014-06-24 10:37:38 UTC

Hi Jiri,

Post by Jiri Slaby
[...]
Anyone wants to give it a try?
http://download.opensuse.org/repositories/home:/jirislaby:/os_13.1_3.12/standard/

Apart from one issue with kernel-syms requiring kernel-xen-devel which
doesn't exist, everything I tested works OK. Here's how I installed it:

# zypper in --no-recommends kernel-default-devel-3.12.22-1.1.g3f06f02 \
kernel-desktop-3.12.22-1.1.g3f06f02 \
kernel-desktop-devel-3.12.22-1.1.g3f06f02 \
kernel-devel-3.12.22-1.1.g3f06f02 \
kernel-source-3.12.22-1.1.g3f06f02 \
kernel-syms-3.12.22-1.1.g3f06f02
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides kernel-xen-devel = 3.12.22-1.g3f06f02 needed by kernel-syms-3.12.22-1.1.g3f06f02.x86_64
Solution 1: do not install kernel-syms-3.12.22-1.1.g3f06f02.x86_64
Solution 2: break kernel-syms-3.12.22-1.1.g3f06f02.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): 1
Resolving dependencies...
Resolving package dependencies...

The following 5 NEW packages are going to be installed:
kernel-default-devel-3.12.22-1.1.g3f06f02 kernel-desktop-3.12.22-1.1.g3f06f02
kernel-desktop-devel-3.12.22-1.1.g3f06f02 kernel-devel-3.12.22-1.1.g3f06f02
kernel-source-3.12.22-1.1.g3f06f02

5 new packages to install.
Overall download size: 128.1 MiB. After the operation, additional 668.0 MiB will be used.
Continue? [y/n/? shows all options] (y):
...

Some details about my system:

CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
Chipset: Intel Z77
RAM: 32 GiB
M/B: ASRock Z77 Pro4
Root-FS: ext4 on SDD
Data-FS: ext4 on md-RAID10 on 4 Seagate Barracuda 7200.14 (ST2000DM001)

This is what I've tested:

KVM virtualization
VMware virtualization
NFSv4 server and client
SMB server and client
Desktop usage (XFCE)

HTH, cheers.

l8er
manfred

Gerald Pfeifer

2014-07-07 20:34:49 UTC

Post by Jiri Slaby
Anyone wants to give it a try?
http://download.opensuse.org/repositories/home:/jirislaby:/os_13.1_3.12/standard/

I'm putting my data where my mouth is. Runs fine so far, including
suspend-to-disk, wireless (iwlwifi), 3G (cdc_ncm), graphics (i915),
audio,...

Gerald

--
Dr. Gerald Pfeifer <gp-IBi9RG/***@public.gmane.org>
Sr. Director Product Management and Operations, SUSE

t***@public.gmane.org

2014-07-08 21:18:07 UTC

I fully support the version increase. I have had some users particularly with
AMD systems that 3.11.x simply did not support. I had another broken system
due to lack of support with 3.11.x then lack of support with Broadcom Tainted
Crap closed source using the latest stable version of the Kernel. I had one
customer so far that I had to recommend waiting until the next release until
migrating which is frustrating.

I use the latest stable version of the kernel 3.15.x on my systems but I
purchase my hardware to work with it, Intel, Intel Graphics, Atheros Wireless
etc to keep the closed source tainted crap off my systems so I do not have
issues. This is what I recommend all people do.

3.12.x has been out for quite a while it is not exactly cutting edge, and has
had a number of maintenance patches applied to it so I see no real issue in
migrating openSUSE updates to it. I do not know any user that would be unhappy
about this.

I typically just add the OBS Kernel Stable repo to the system I install as
well as the OBS Xorg/X11 repo as well on the systems that I can. I have not
had a community user who was unhappy about this, unless they had hardware that
required proprietary drivers that could not work with that version in which
case they were relatively pissed they could not use the latest version and
irritated with NVDIA/ATI/Broadcom etc.

I also typically advise the people I do work for to replace hardware with
hardware that has more open source kernel support for the best Linux
experience.

Being stuck with an old Kernel and old X11/Mesa is crap as far as I am
concerned, It is like being stuck three versions behind with GNOME or KDE and
being irritated every time you see someone with the latest version.

All software has defects, regressions happen, keeping old software does not
really help in any way as far as I am concerned. Most regressions are found
and corrected quickly. Most users are happy when they get new features which
generates the best form of positive marketing. openSUSE is not an Enterprise
targeted distro, it is a community targeted distro sitting in the middle
between Enterprise and bleeding edge, it would be nice to push it a little
further toward bleeding edge and a little less toward enterprise and start
regularly bumping core components up after they have been released for general
consumption for 3-4 months.

The more the software versions age the more users/developers we loose! I am
all for only needing to do a full system upgrade about once a year but I still
want relatively new software and regular updates. If I wanted old software
with large amounts of new hardware headaches I would use SLED.

Since SUSE is supposedly breaking away form direct developer SUSE paid
employee support for openSUSE sadly we can also break away form openSUSE being
testing platform for SLED/SLES some as well and do some version jumps.

I do not know anyone that is really happy running 3.11.x when 3.15.x is out
for general consumption. I am personally fine with bumping to 3.14.x which
would make most users happy in my opinion, look how impatient most users are
when it comes to the latest major/maintenance releases of KDE, most openSUSE
users I talk to do not want to wait three weeks they want to jump right up and
a number typically do as soon as a repo is available even if it is just a
temporary one. Also most users I talk to are generally irritated by the lack
of kernel bumps through regular updates then slightly appeased when they
discover OBS Kernel Stable.

If OBS did not exist I personally would not use openSUSE. It provides me with
the software versions I want on a distro that I like using.

Firefox and LibreOffice should be bumped as soon as a new public release is
released. I hate having old versions of these products.

Bruno Friedmann

2014-07-09 05:33:58 UTC

Post by t***@public.gmane.org
If OBS did not exist I personally would not use openSUSE. It provides me with
the software versions I want on a distro that I like using.

That's why it was invented and used by numerous people to get what they want.

Post by t***@public.gmane.org
Firefox and LibreOffice should be bumped as soon as a new public release is
released. I hate having old versions of these products.

It seems you've never been hit by abrupt changes and major breakage that happen.
Firefox & LibreOffice are perfect example of this kind of trouble.
And believe me, if you have 100 person who depend on a previous feature that now
is a bug. You don't want new version.

About the kernel: I've bought one month ago a perfect laptop (Macbook pro)
The thunderbold link with the external screen was working with 3.12,3.13.3.14
The day of my hollidays return 3.15 appear and then no more working screen & ethernet.
Guess what 3.16-rc not at all either.

I'm confident on the fact this will get fixed, but in the meantime "the update" broke my working system.
You can't imagine how many different systems and way to use them there's outside.
It's just not that simple as osc sr et voilà.

Global question :
Should we announce the fact to opensuse-ml & opensuse-project (+news, +meeting) to have feedback.
(and yes managing the flow)
Or we're enough confident to make the bump.

--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board
GPG KEY : D5C9B751C4653227
irc: tigerfoot

~~~Don't take Life too serious. Nobody gets out alive anyway!~~~

Michal Kubecek

2014-07-09 07:08:58 UTC

Post by t***@public.gmane.org
3.12.x has been out for quite a while it is not exactly cutting edge,
and has had a number of maintenance patches applied to it so I see no
real issue in migrating openSUSE updates to it. I do not know any
user that would be unhappy about this.

...

Post by t***@public.gmane.org
All software has defects, regressions happen, keeping old software
does not really help in any way as far as I am concerned. Most
regressions are found and corrected quickly. Most users are happy
when they get new features which generates the best form of positive
marketing.

No, they are not. For most users, it's more like in this strip:

https://www.eviscerati.org/comics/comic/kp/2005/05/cold-hard-truth

If the distribution doesn't work on some hardware from the start or if
the user is missing some new feature, it makes sense for him/her to try
newer version from OBS or try Tumbleweed or even Factory.

Most users, however, have already installed and working systems and
would be very annoyed if they just updated the system and it stopped
working. And be sure that if we just throwed in a 3.14 or 3.15 kernel,
this would happen and people would be very unhappy. When we moved from
2.6.37 to SLE-based 3.0 kernel in Evergreen 11.4 for very good reasons,
there were people who complained because things stopped working for them
(and not all of them because of missing NVidia/fglrx drivers).

Post by t***@public.gmane.org
From the maintainability point of view, it makes sense to move to kernel

based either on Canonical's 3.11.10.z or on stable 3.12.y or on SLE12.
All these have their pros and cons and I would welcome a discussion
about which of these three would be the most suitable (taking Evergreen
into account). But I don't see much advantage in moving to 3.14.y
instead; while it would help some new installation, it would also
unnecessarily heighten the risk of regressions and breaking existing
systems.

Post by t***@public.gmane.org
openSUSE is not an Enterprise targeted distro, it is a
community targeted distro sitting in the middle between Enterprise
and bleeding edge, it would be nice to push it a little further
toward bleeding edge and a little less toward enterprise and start
regularly bumping core components up after they have been released
for general consumption for 3-4 months.
The more the software versions age the more users/developers we loose!
I am all for only needing to do a full system upgrade about once a
year but I still want relatively new software and regular updates. If
I wanted old software with large amounts of new hardware headaches I
would use SLED.
Since SUSE is supposedly breaking away form direct developer SUSE paid
employee support for openSUSE sadly we can also break away form
openSUSE being testing platform for SLED/SLES some as well and do
some version jumps.
I do not know anyone that is really happy running 3.11.x when 3.15.x
is out for general consumption.

For example, I'm running few systems with OpenSuSE 13.1 and only on one
of them I installed a newer kernel (because of driver for a sound card
I'm experimenting with). As a result, suspend to disk seems completely
broken. I see no point in upgrading a kernel on those that work, why
should I? Where I want/need new kernel, I have sources to get it; but
I'm glad noone is forcing it on me in a regular update.

Michal Kubeček

Gerald Pfeifer

2014-09-12 09:52:43 UTC

Seeing that Jiri's repo has not seen a source code updates since
originally posted three months ago, I guess this is an abandoned
experiment?

Gerald

Greg Freemyer

2014-09-12 11:36:57 UTC

Post by Gerald Pfeifer

user

Post by t***@public.gmane.org
that would be unhappy about this.

Seeing that Jiri's repo has not seen a source code updates since
originally posted three months ago, I guess this is an abandoned
experiment?
Gerald

Fyi:

There was discussion that Evergreen would leverage opensuse 13.1 switching to kernel 3.12, but at least for now the main evergreen Kernel maintainer is contemplating basing his effort on the SLES kernel.

http://lists.rosenauer.org/pipermail/evergreen/2014-September/001421.html

Greg

Marcus Meissner

2014-09-12 12:03:56 UTC

Post by Gerald Pfeifer

user

Post by t***@public.gmane.org
that would be unhappy about this.

Seeing that Jiri's repo has not seen a source code updates since
originally posted three months ago, I guess this is an abandoned
experiment?
Gerald

There was discussion that Evergreen would leverage opensuse 13.1 switching to kernel 3.12, but at least for now the main evergreen Kernel maintainer is contemplating basing his effort on the SLES kernel.
http://lists.rosenauer.org/pipermail/evergreen/2014-September/001421.html

... which is based on 3.12.

Ciao, Marcus

Felix Miata

2014-09-12 13:20:31 UTC

Post by Gerald Pfeifer
Seeing that Jiri's repo has not seen a source code updates since
originally posted three months ago, I guess this is an abandoned
experiment?

I was using Jiri's 3.12 until Michal's 3.12 came along:
http://download.opensuse.org/repositories/home:/mkubecek:/evergreen-13.1/openSUSE_13.1/

Michal Kubecek

2014-06-08 20:31:11 UTC