Am 10.06.2016 um 23:06 schrieb Greg Freemyer:

Given your statement, Is it appropriate to say the main benefit of a standalone Kernel:LTS repo is that users don't have to worry about pulling in non-kernel related packages like they would if they were to add the full Leap:42.2 repo?

Are you maybe looking for this project? https://build.opensuse.org/project/show/Kernel:openSUSE-42.2 It won't give you an automatic update to a 2017 LTS kernel but shouldn't pull in any Leap packages today either. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 10 Jun 2016 23:06:17 +0200, Greg Freemyer wrote:

On Fri, Jun 10, 2016 at 1:50 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

Am 10.06.2016 um 16:46 schrieb Greg Freemyer:

...

I've got the Leap 42.2 Kernel in a Kernel:LTS tracking project. It should get all the SLE 12 SP2 kernel patches/updates automatically. I'm building for Tumbleweed, Leap 42.1, 13,2, and 13.1.

There is no need for building the kernel multiple times for different distributions. Just building against Factory or Tumbleweed will do.

See Kernel:HEAD, Kernel:stable or Kernel:vanilla for setup hints.

With you setup you are wasting lots of buildservice power.

Best regards,

Stefan -- Stefan Seyfried

Got it.

Given your statement, Is it appropriate to say the main benefit of a standalone Kernel:LTS repo is that users don't have to worry about pulling in non-kernel related packages like they would if they were to add the full Leap:42.2 repo?

Also, in can be built against by any kernel modules maintainers that would like to test their modules without requiring a full Leap 42.2 install?

Or am I just wasting my cycles trying to promote this?

The kernel package that is built even with a newer gcc can be deployed to older distros in general. Also, building a KMP with an older gcc for a kernel with a newer gcc usually works. In that sense, building the same kernel package for multiple distro versions is a waste of resources, yes. One possible problem for deploying a new kernel to an old distro would be the difference of mkinitrd stuff or module-init-tools. But it should be no problem if the distro is 13.1 or later. That being said, there is no much merit to rebuilding the whole again, as long as the code is same as 42.2 kernel. Of course, if you're willing to maintain the next LTS kernel (4.10 or whatever), it's a different question. In general, tracking the upstream stable kernel is really easy. It's a monkey work. However, there are a few more difficult tasks: * kABI compatibility For keeping KMPs working, you'd need to keep the kABI compatible. And this is the most difficult task while maintaining the kernel package. If you don't keep kABI compatibility, it means a rolling release like TW, i.e. all KMPs have to be rebuilt against the new kernel at each time. If we define such a policy, it's fine. But then you'll have a project linking every KMP into the same kernel project. * kconfig adjustment The kernel config has to be updated properly after the kernel upgrade. Though, this can be done by following TW kernel development. But you'll need to check the compatibility from the previous LTS Kernel as wel. * Bug report handling As a maintainer, you'll need to deal with each bug report against your LTS kernel. * Taking and maintaining own patches Taking own fix patches that aren't in stable tree depend on the maintainer. Leap 42.1 kernel have a significant number of own patches, for example. * Security fixes Sometimes you'll need to handle security fixes before handled in stable tree. Hopefully this will get you a more concrete idea how to maintain your kernel project. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

I just now set the repositories to match Kernel:stable. Greg -- Greg Freemyer www.IntelligentAvatar.net On Sat, Jun 11, 2016 at 5:02 AM, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:

Where are other architectures?

10.06.2016 17:46, Greg Freemyer пишет:

...

All,

As you know the 4.4 kernel is the current kernel.org LTS kernel and it is going to be the Leap 42.2 kernel and SLE 12 SP2 kernel.

Since Leap 42.x is likely to use LTS kernels going forward I thought it would be good to have a Kernel:LTS project that people can use to test out that kernel. And then update that project when the 2017 LTS kernel is released by kernel.org.

For testing purposes I thought both Tumbleweed and older Leap / 13.x releases should have 4.4 kernel packages available.

All that to say:

I've got the Leap 42.2 Kernel in a Kernel:LTS tracking project. It should get all the SLE 12 SP2 kernel patches/updates automatically. I'm building for Tumbleweed, Leap 42.1, 13,2, and 13.1.

http://download.opensuse.org/repositories/home:/gregfreemyer:/Kernel:/LTS/

I'm planning to leave that there until the kernel team makes an official Kernel:LTS project. (I don't have the OBS permissions to do that, or I would have).

If anyone wants to test the Leap 42.2 kernel in advance without doing a full Leap 42.2 install, please do. That's why I created the project.

Also if people want to build kernel modules against it, they can. My desire is that this repo can allow non Leap 42.2 testers to contribute to testing out the Leap 42.2 kernel over the next 5 months or so.

I suspect having the project promoted a Kernel:LTS project would increase the likelyhood of kernel modules etc. being built against it.

Thanks Greg -- Greg Freemyer www.IntelligentAvatar.net

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

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