[aur-general] LTS kernel moved to 3.10.x - module rebuilds
I've updated LTS kernel to 3.10.x branch into testing repo. Please rebuild all community modules. I'll do the module rebuilds for extra repo packages. -Andy
Hi, please consider adding this patch for a bug in the 3.10.x / 3.11.x series. https://bbs.archlinux.org/viewtopic.php?id=167257 It was reported 2 month ago and has been finally fixed. Unfortunately, it hasn't been yet included in 3.10.12 resp. 3.11.1 The patch itself is really simple - avoiding a divide error on 0 counters --- a/drivers/media/common/siano/ smsdvb-main.c 2013-07-01 00:13:29.000000000 +0200 +++ b/drivers/media/common/siano/smsdvb-main.c 2013-09-13 00:17:58.765980686 +0200 @@ -275,7 +275,8 @@ /* Legacy PER/BER */ tmp = p->ets_packets * 65535; - do_div(tmp, p->ts_packets + p->ets_packets); + if (p->ts_packets + p->ets_packets) + do_div(tmp, p->ts_packets + p->ets_packets); client->legacy_per = tmp; } --- On Mon, Sep 16, 2013 at 10:14 PM, Andreas Radke <andyrtr@archlinux.org> wrote:
I've updated LTS kernel to 3.10.x branch into testing repo. Please rebuild all community modules. I'll do the module rebuilds for extra repo packages.
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas, On Mon, 16 Sep 2013, Andreas Radke wrote:
I've updated LTS kernel to 3.10.x branch into testing repo. Please rebuild all community modules. I'll do the module rebuilds for extra repo packages.
What required the move al the way to 3.10.x instead of, say, the longer supported 3.2.x? - --brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFSN6QbMYOP2up1d2URAoIXAJ9E1HE/hsjCeMVNqAduoQMFm0PMAwCg9ncM 6As54wy2ElxttzgGslVVslM= =87Go -----END PGP SIGNATURE-----
On 09/16/2013 05:36 PM, Brian F. G. Bidulock wrote:
Andreas,
On Mon, 16 Sep 2013, Andreas Radke wrote:
I've updated LTS kernel to 3.10.x branch into testing repo. Please rebuild all community modules. I'll do the module rebuilds for extra repo packages.
What required the move al the way to 3.10.x instead of, say, the longer supported 3.2.x?
--brian It was picked for long term support. I think that is why it was the one chosen. http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/
Don, On Mon, 16 Sep 2013, Don deJuan wrote:
It was picked for long term support. I think that is why it was the one chosen. http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/
If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.) When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build? --brian
On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.)
When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build?
Off the top of my head, the discussion in arch-dev-public went about two main points: 1:) Arch is a distribution that prides itself in being on the bleeding edge of technology. If there is a new LTS kernel since now and September 2015, be sure it will replace the present version unless there are apocalyptic reasons not to do it. 2.) The 3.10 kernel has much better hardware support and gives access to a lot of newer technology that LTS users might want to use. On my side, I can see a very important and beneficial side effect of using 3.10 as LTS kernel: It is very well integrated with systemd. In fact it has already part of the work that supports the new hirearchical cgroups world, therefore it will be more compatible with future systemd versions. Furthermore, the technological advance in file-systems, virtualization and graphics support from 3.2 to 3.10 is not something to ignore. Perhaps I ought to point out that a kernel.org LTS is a bug-fix only affair unless there is an obvious need to correct a glaring mistake, new features are not added lightly. That's not the case with vendor kernels. They choose to add the support and backport the features they want, that is: those kernels are Frankenstein monsters. A RHEL 5 2.6.17 kernel is really made out of the corpses of all kernels up to 3.8 at this time ---taking an educated guess--- and that is without taking into consideration all the out-of-tree additions that are not either in Torvald's nor linux-next trees. -- http://about.me/palopezv
Hi On Tue, Sep 17, 2013 at 5:26 AM, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.)
When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build?
Off the top of my head, the discussion in arch-dev-public went about two main points: 1:) Arch is a distribution that prides itself in being on the bleeding edge of technology. If there is a new LTS kernel since now and September 2015, be sure it will replace the present version unless there are apocalyptic reasons not to do it. 2.) The 3.10 kernel has much better hardware support and gives access to a lot of newer technology that LTS users might want to use.
On my side, I can see a very important and beneficial side effect of using 3.10 as LTS kernel: It is very well integrated with systemd. In fact it has already part of the work that supports the new hirearchical cgroups world, therefore it will be more compatible with future systemd versions. Furthermore, the technological advance in file-systems, virtualization and graphics support from 3.2 to 3.10 is not something to ignore.
Perhaps I ought to point out that a kernel.org LTS is a bug-fix only affair unless there is an obvious need to correct a glaring mistake, new features are not added lightly. That's not the case with vendor kernels. They choose to add the support and backport the features they want, that is: those kernels are Frankenstein monsters. A RHEL 5 2.6.17 kernel is really made out of the corpses of all kernels up to 3.8 at this time ---taking an educated guess--- and that is without taking into consideration all the out-of-tree additions that are not either in Torvald's nor linux-next trees.
I would suggest to rename linux-lts to linux-lts-3.2 and keep it in the repo for a while. This is the way how Arch can keep old version of the package. So people who does not want to rush with kernel upgrade can use that package. Later (in ~12 months) this package can be removed or moved to AUR.
El mar, 17-09-2013 a las 06:09 -0700, Anatol Pomozov escribió:
I would suggest to rename linux-lts to linux-lts-3.2 and keep it in the repo for a while. This is the way how Arch can keep old version of the package.
This sounds reasonable, but see below.
So people who does not want to rush with kernel upgrade can use that package. Later (in ~12 months) this package can be removed or moved to AUR.
Considering the maintenance burden on the devs (they are not many and we all are volunteers here), this lts-3.2 could go directly into the AUR. Not that I'm volunteering myself to do it.
On Tue, 17 Sep 2013 09:36:44 -0500 Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
El mar, 17-09-2013 a las 06:09 -0700, Anatol Pomozov escribió:
I would suggest to rename linux-lts to linux-lts-3.2 and keep it in the repo for a while. This is the way how Arch can keep old version of the package.
This sounds reasonable, but see below.
So people who does not want to rush with kernel upgrade can use that package. Later (in ~12 months) this package can be removed or moved to AUR.
Considering the maintenance burden on the devs (they are not many and we all are volunteers here), this lts-3.2 could go directly into the AUR. Not that I'm volunteering myself to do it.
In that case don't forget the companion nvidia-lts-3.2, etc packages too... -- Joakim
participants (7)
-
Anatol Pomozov
-
Andreas Radke
-
Brian F. G. Bidulock
-
Don deJuan
-
Joakim Hernberg
-
Pedro Alejandro López-Valencia
-
Rob Til Freedmen