[opensuse-kernel] Kernel updates on Tumbleweed have been coming out pretty slowly lately...
The kernel releases for Tumbleweed have been coming out pretty slowly lately. When I started using Tumbleweed in November of 2017, it was not at all uncommon for Tumbleweed to get a new kernel release before Arch got the same kernel release. Now, it seems like we get new kernel releases a week after they are released upstream at best. I personally have been using kernel:stable because of this, but due to the kmp setup and not using dkms, not everyone can do this. Is there a reason for this? I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Freitag, 19. Juli 2019, 05:38:03 CEST schrieb simonizor:
The kernel releases for Tumbleweed have been coming out pretty slowly lately. When I started using Tumbleweed in November of 2017, it was not at all uncommon for Tumbleweed to get a new kernel release before Arch got the same kernel release. Now, it seems like we get new kernel releases a week after they are released upstream at best. I personally have been using kernel:stable because of this, but due to the kmp setup and not using dkms, not everyone can do this.
Is there a reason for this? I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue.
While I guess, the basic reason is about human resources, or better the lack thereof, I second a slightly more conservative kernel release management, as it is practiced today. I used to live on the edge side of kernel:stable for a long time (building them on a local OBS, even for /ancient/ userspace), but since moved to factory, things run smoother in general here. What does it buy you to live one or two weeks ahead, especially in the major kernel release version gap, other than dealing with yet another NVidia fallout, Virtualbox hassles, ... Check the change logs for reverts. They're done for a reason. I don't want to be my systems *that* reason. After all, kernel:stable is there to be used from the more adventurous ones. All the kernel guys are doing a fantastic job, but we're living in a complicated world nowadays. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 19. 07. 19, 10:09, Hans-Peter Jansen wrote:
Am Freitag, 19. Juli 2019, 05:38:03 CEST schrieb simonizor:
The kernel releases for Tumbleweed have been coming out pretty slowly lately. When I started using Tumbleweed in November of 2017, it was not at all uncommon for Tumbleweed to get a new kernel release before Arch got the same kernel release. Now, it seems like we get new kernel releases a week after they are released upstream at best. I personally have been using kernel:stable because of this, but due to the kmp setup and not using dkms, not everyone can do this.
Is there a reason for this? I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue.
While I guess, the basic reason is about human resources, or better the lack thereof, I second a slightly more conservative kernel release management, as it is practiced today.
There is at least one caveat. If something breaks in that many (even stable) releases, it's quite harder to find the culprit in thousands patches instead of a hundred.
What does it buy you to live one or two weeks ahead, especially in the major kernel release version gap, other than dealing with yet another NVidia fallout, Virtualbox hassles, ... Check the change logs for reverts. They're done for a reason. I don't want to be my systems *that* reason.
There are people not using nvidia, vbox or other out-of-tree thing at all. Anyway, those are usually problem only on major version updates.
After all, kernel:stable is there to be used from the more adventurous ones. All the kernel guys are doing a fantastic job, but we're living in a complicated world nowadays.
Sure, kernel is 30 millions line of code... Even if every 1'000th line had a bug, we would have 3000 bugs (there are likely many more). thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote:
What does it buy you to live one or two weeks ahead, especially in the major kernel release version gap, other than dealing with yet another NVidia fallout, Virtualbox hassles, ... Check the change logs for reverts. They're done for a reason. I don't want to be my systems *that* reason.
All of this would not even be an issue if we didn't use KMP and used dkms as most distributions do. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote:
What does it buy you to live one or two weeks ahead, especially in the major kernel release version gap, other than dealing with yet another NVidia fallout, Virtualbox hassles, ... Check the change logs for reverts. They're done for a reason. I don't want to be my systems *that* reason.
All of this would not even be an issue if we didn't use KMP and used dkms as most distributions do.
It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...
It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.
Takashi
Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...
It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.
Takashi
Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel.
It's pretty much irrelevant from DKMS vs KMP argument. Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote: ...
It's pretty much irrelevant from DKMS vs KMP argument.
Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla.
Takashi
With dkms, you wouldn't have to provide separate things at all. One package works for all kernels. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:
On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote: ...
It's pretty much irrelevant from DKMS vs KMP argument.
Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla.
Takashi
With dkms, you wouldn't have to provide separate things at all. One package works for all kernels.
Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project). Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 9:14:14 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:
On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote: ...
Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project).
Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either.
Takashi
Yes, but the user needs to know how to do all of these things. With DKMS, it's a pretty much "just works" solution. KMP is not at all user friendly for anyone who doesn't want to use the default kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, 19 July 2019 16:15 simonizor wrote:
On Friday, July 19, 2019 9:14:14 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:
On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote: ...
Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project).
Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either.
Yes, but the user needs to know how to do all of these things. With DKMS, it's a pretty much "just works" solution. KMP is not at all user friendly for anyone who doesn't want to use the default kernel.
No, it's far from "just works". It means less work in some scenarios, more in others. The cold hard truth is: if you are using out-of-tree modules with rolling distribution like Tumbleweed, you are asking for trouble (unless you are prepared to handle the problems yourself). If you are using closed source modules with such distribution, you are asking for a lot of trouble and often you can do nothing with it, just wait. Michal Kubecek -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 16:15:33 +0200, simonizor wrote:
On Friday, July 19, 2019 9:14:14 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:
On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote: ...
Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project).
Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either.
Takashi
Yes, but the user needs to know how to do all of these things. With DKMS, it's a pretty much "just works" solution. KMP is not at all user friendly for anyone who doesn't want to use the default kernel.
DKMS is "just works" only because you know about DKMS, too. I suppose that DKMS is often easier to manage, too, but my point is that DKMS is no solution for the problems of Nvidia or VirtualBox breakages that have been suggested in this thread. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 7/19/19 7:25 AM, Takashi Iwai wrote:
that DKMS is no solution for the problems of Nvidia or VirtualBox breakages that have been suggested in this thread.
this is certainly a YMMV kindof issue, isn't it? here, for production, I use stable core + current kernel -- namely, KernelStable on Leap15.1 builds. KernelStable builds @opensuse are, IME, very reliably maintained & production ready. in order to unwind some of the staging deps mentioned above -- and, more importantly for making local tweaking simple -- I build a _link'd instance of KernelStable. nvidia is widely in use here. nvidia's proprietary drivers continue to be a preferable solution here to nouveau. following kernel:stable versions, building nvidia's upstream on OBS, and fussing with KMPs, was more trouble than it's worth -- -- and, frankly, I clearly wasn't very 'good' at it. i can build with no errors, but had all sorts of weird runtime artifacts here. yes, most likely 'some' problem with my builds -- simply not worth it. installing dkms & enabling nvidia's dkms support has cured that problem. it works, & it's easy to deploy & maintain. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
PGNet Dev composed on 2019-07-19 08:08 (UTC-0700):
nvidia's proprietary drivers continue to be a preferable solution here to nouveau.
You write as if the competent choices are two, when in fact, there are three. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 7/19/19 10:05 AM, Felix Miata wrote:
You write as if the competent choices are two, when in fact, there are three.
No idea what that's supposed to mean. I've simply stated the choice I've made from the 2 options I consider. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
PGNet Dev composed on 2019-07-19 10:40 (UTC-0700):
Felix Miata wrote:
You write as if the competent choices are two, when in fact, there are three.
No idea what that's supposed to mean.
I've simply stated the choice I've made from the 2 options I consider.
What stops you from considering the upstream default option? It doesn't scare you asking you to acknowledge its limitations when you install or upgrade. # inxi -Gxx Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:107d Fermi based Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia compositor: kwin_x11 resolution: 2560x1440~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 19.0.5 compat-v: 3.1 direct render: Yes -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
What stops you from considering the upstream default option? It doesn't scare you asking you to acknowledge its limitations when you install or upgrade.
sry, can't help you. i have no idea what you're talking about, or what point you're attempting to make. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
PGNet Dev composed on 2019-07-19 10:59 (UTC-0700):
i have no idea what you're talking about, or what point you're attempting to make.
How can you know which driver suits you best if you haven't even tried the (upstream default) DDX, aka /modesetting/, provided by xorg-x11-server rpm? # rpm -qa | egrep -i 'xf86-video|nvidia|modeset' xf86-video-fbdev-0.5.0-1.7.x86_64 xf86-video-vesa-2.4.0-1.7.x86_64 # xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 2560 x 2640, maximum 16384 x 16384 DP-2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm DP-1 connected primary 2560x1440+0+1200 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 1920x1200 59.95*+ # xdpyinfo | grep dimen dimensions: 2560x2640 pixels (541x558 millimeters) # inxi -GxxS System: Host: p5bse Kernel: 5.1.16-1-default x86_64 bits: 64 compiler: gcc v: 9.1.1 Desktop: KDE Plasma 5.16.2 tk: Qt 5.13.0 wm: kwin_x11 dm: startx Distro: openSUSE Tumbleweed 20190717 Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:107d Display: tty server: X.Org 1.20.5 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia compositor: kwin_x11 resolution: 2560x1440~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 8.0 128 bits) v: 3.3 Mesa 19.1.2 compat-v: 3.1 direct render: Yes # egrep -i 't\(0\)|modeset|connect' /var/log/Xorg.0.log | grep -v 'not conn' | head -n6 [ 679.616] (==) Matched modesetting as autoconfigured driver 3 [ 679.617] (II) LoadModule: "modesetting" [ 679.617] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 679.617] (II) Module modesetting: vendor="X.Org Foundation" [ 679.617] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 679.617] (II) modeset(0): using drv /dev/dri/card0 # grep -i unload /var/log/Xorg.0.log [ 681.372] (II) UnloadModule: "fbdev" [ 681.372] (II) Unloading fbdev [ 681.372] (II) UnloadSubModule: "fbdevhw" [ 681.372] (II) Unloading fbdevhw [ 681.372] (II) UnloadModule: "vesa" [ 681.372] (II) Unloading vesa -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
19.07.2019 20:53, Felix Miata пишет:
PGNet Dev composed on 2019-07-19 10:40 (UTC-0700):
Felix Miata wrote:
You write as if the competent choices are two, when in fact, there are three.
No idea what that's supposed to mean.
I've simply stated the choice I've made from the 2 options I consider.
What stops you from considering the upstream default option?
That's option 2. What is the third option you were talking about? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Andrei Borzenkov composed on 2019-07-20 07:19 (UTC+0300):
Felix Miata composed:
PGNet Dev composed on 2019-07-19 10:40 (UTC-0700):
Felix Miata wrote:
You write as if the competent choices are two, when in fact, there are three.
No idea what that's supposed to mean.
I've simply stated the choice I've made from the 2 options I consider.
What stops you from considering the upstream default option?
That's option 2. What is the third option you were talking about?
Option 1, apparently most popular: non-FOSS (proprietary) NVidia Option 2, openSUSE default: FOSS nouveau DDX, provided by (upstream optional) rpm xf86-video-nouveau Option 3, upstream default: FOSS modesetting DDX, provided by xorg-x11-server rpm -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
20.07.2019 9:04, Felix Miata пишет:
Option 2, openSUSE default: FOSS nouveau DDX, provided by (upstream optional) rpm xf86-video-nouveau
Option 3, upstream default: FOSS modesetting DDX, provided by xorg-x11-server rpm
This is opensuse-kernel, not opensuse-xorg list. There are two kernel drivers - nouveau or nvidia. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Andrei Borzenkov composed on 2019-07-20 09:16 (UTC+0300):
Felix Miata composed:
Option 2, openSUSE default: FOSS nouveau DDX, provided by (upstream optional) rpm xf86-video-nouveau
Option 3, upstream default: FOSS modesetting DDX, provided by xorg-x11-server rpm
This is opensuse-kernel, not opensuse-xorg list. There are two kernel drivers - nouveau or nvidia.
The language initially replied to was: nvidia's proprietary drivers Yes, NVidia's drivers are of two types, kernel, and X. However, just because a post is on a kernel list doesn't necessarily mean only the former type can be inferred as the subject matter. For X there are (the) three types I listed. Thus the post replied to was unclear and my intent was in no small part to elicit clarification on the subject of video "drivers" generally. Of the X type it seems few have any idea there are more than two to choose from, much less a need to be specific whether the kernel or X type, or both, is the subject matter. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 9:25:32 AM CDT, Takashi Iwai wrote:
DKMS is "just works" only because you know about DKMS, too.
Actually, I know next to nothing about it other than it allows me to use drivers such as NVIDIA with pretty much any kernel version without having to worry. I used Ubuntu's nvidia-dkms driver package for quite some time on many different kernel versions without ever having to do anything myself. This is not ever the case for KMP. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 19:21:25 +0200, simonizor wrote:
On Friday, July 19, 2019 9:25:32 AM CDT, Takashi Iwai wrote:
DKMS is "just works" only because you know about DKMS, too.
Actually, I know next to nothing about it other than it allows me to use drivers such as NVIDIA with pretty much any kernel version without having to worry. I used Ubuntu's nvidia-dkms driver package for quite some time on many different kernel versions without ever having to do anything myself. This is not ever the case for KMP.
Well, that's the difference by how to look at the whole process. You've got positive results, but it's just merely because someone already worked on it to make things working before you try. That's not DKMS that fixes the build issues by the kernel API changes automagically. You haven't seen the people behind the scene, hence you'd believe it being DKMS as an exposed result. That said, pushing DKMS into Tumbleweed or Kernel:stable *alone* won't help much as advertised. Someone still needs to step in and resolve the issues quickly. It's irrelevant whether DKMS or KMP. Unfortunately, on openSUSE, a fix for Nvidia or such is often behind Ubuntu simply because fewer developers are interested in it. And, if the problem is about pure packaging, it should be reported as quickly as possible to Bugzilla, and we're going to address it in timely manner. Switching to DKMS should be discussed only after it's confirmed that this kind of feedback cycle doesn't work well. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 1:05:44 PM CDT, Takashi Iwai wrote:
Well, that's the difference by how to look at the whole process.
You've got positive results, but it's just merely because someone already worked on it to make things working before you try. That's not DKMS that fixes the build issues by the kernel API changes automagically. You haven't seen the people behind the scene, hence you'd believe it being DKMS as an exposed result.
That said, pushing DKMS into Tumbleweed or Kernel:stable *alone* won't help much as advertised. Someone still needs to step in and resolve the issues quickly. It's irrelevant whether DKMS or KMP. Unfortunately, on openSUSE, a fix for Nvidia or such is often behind Ubuntu simply because fewer developers are interested in it.
And, if the problem is about pure packaging, it should be reported as quickly as possible to Bugzilla, and we're going to address it in timely manner. Switching to DKMS should be discussed only after it's confirmed that this kind of feedback cycle doesn't work well.
Takashi
Not sure if you're aware, but we have a dkms-nvidia package available in the Bumblebee repos that hasn't had to change anything with their dkms setup for quite some time. It is very much "just works". Just take a look at this. It has had ***one*** revision since creation in what seems like 2011 (it's updated by a service), and it has been working that entire time. https://build.opensuse.org/package/view_file/home:Bumblebee-Project:nVidia:l... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 16:06:16 +0200, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...
It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.
Takashi
Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel.
It's pretty much irrelevant from DKMS vs KMP argument.
Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla.
... and to be more noted: the difference between vanilla and default on TW is fairly minimalistic, hence there won't be much benefit to provide extra resources for building a vanilla-kmp. Maybe Leap is a different story; but I'm not going further to that direction, as it'll be a discussion about how to manage Leap kernels in general :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 9:10:32 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 16:06:16 +0200, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote: ...
... and to be more noted: the difference between vanilla and default on TW is fairly minimalistic, hence there won't be much benefit to provide extra resources for building a vanilla-kmp.
Maybe Leap is a different story; but I'm not going further to that direction, as it'll be a discussion about how to manage Leap kernels in general :)
Takashi
I don't think you get my point... with the KMP setup, someone who has modules that use KMP cannot even use kernel-vanilla. With dkms, they can use whatever kernel they want. Someone on Ubuntu isn't limited to the default kernel in their repos; they can use the latest kernel without doing anything to something like their NVIDIA packages. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 16:14:03 +0200, simonizor wrote:
On Friday, July 19, 2019 9:10:32 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 16:06:16 +0200, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote: ...
... and to be more noted: the difference between vanilla and default on TW is fairly minimalistic, hence there won't be much benefit to provide extra resources for building a vanilla-kmp.
Maybe Leap is a different story; but I'm not going further to that direction, as it'll be a discussion about how to manage Leap kernels in general :)
Takashi
I don't think you get my point... with the KMP setup, someone who has modules that use KMP cannot even use kernel-vanilla. With dkms, they can use whatever kernel they want. Someone on Ubuntu isn't limited to the default kernel in their repos; they can use the latest kernel without doing anything to something like their NVIDIA packages.
Of course, it's a drawback of KMP. The build is done in outside. But this is also an advantage. You don't need any toolchain for installing a KMP in general. (Nvidia package is an exception in this regard because it is Nvidia, who always needs avoid GPL-thingies :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, 19 July 2019 15:58 simonizor wrote:
On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 15:03:46 +0200,
simonizor wrote:
On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...
It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.
Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel.
KMPs are built for a particular flavor. You just need foo-kmp-vanilla instead of foo-kmp-default if you want to switch to kernel-vanilla. Michal Kubecek -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 9:12:41 AM CDT, Michal Kubecek wrote:
KMPs are built for a particular flavor. You just need foo-kmp-vanilla instead of foo-kmp-default if you want to switch to kernel-vanilla.
Michal Kubecek
Are you sure that's even a thing? I know broadcom-wl has no broadcom-wl-kmp-vanilla, and 'zypper se kmp-vanilla' gives 'No matching items found.'... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 19:11:56 +0200, simonizor wrote:
On Friday, July 19, 2019 9:12:41 AM CDT, Michal Kubecek wrote:
KMPs are built for a particular flavor. You just need foo-kmp-vanilla instead of foo-kmp-default if you want to switch to kernel-vanilla.
Michal Kubecek
Are you sure that's even a thing? I know broadcom-wl has no broadcom-wl-kmp-vanilla, and 'zypper se kmp-vanilla' gives 'No matching items found.'...
Usually it's not built for vanilla. A part of reasons is thatit'd be a bit trickier to build from two different source trees (vanilla and default have different sources in the end). And, as already mentioned, it makes little sense to build a vanilla KMP for TW, as the difference between vanilla and default is pretty small, so no one ever tried toward that direction. But technically seen, there is nothing to stop building vanilla KMP by yourself if you inevitably need it. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Friday, July 19, 2019 2:26:33 PM CDT, Takashi Iwai wrote:
On Fri, 19 Jul 2019 19:11:56 +0200, simonizor wrote:
On Friday, July 19, 2019 9:12:41 AM CDT, Michal Kubecek wrote: ...
Usually it's not built for vanilla. A part of reasons is thatit'd be a bit trickier to build from two different source trees (vanilla and default have different sources in the end). And, as already mentioned, it makes little sense to build a vanilla KMP for TW, as the difference between vanilla and default is pretty small, so no one ever tried toward that direction. But technically seen, there is nothing to stop building vanilla KMP by yourself if you inevitably need it.
Takashi
I have no interest in touching KMP lol... I would just use dkms like everyone else does. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 19. 07. 19, 5:38, simonizor wrote:
The kernel releases for Tumbleweed have been coming out pretty slowly lately. When I started using Tumbleweed in November of 2017, it was not at all uncommon for Tumbleweed to get a new kernel release before Arch got the same kernel release. Now, it seems like we get new kernel releases a week after they are released upstream at best. I personally have been using kernel:stable because of this, but due to the kmp setup and not using dkms, not everyone can do this.
Is there a reason for this? I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue.
I, as a maintainer of that kernel, can only say, that the process from my side hasn't changed. The submit requests are still as quick as they used to be. I guess the culprit is the change in staging process performed few weeks ago. Kernel used to be a single package in a staging project before that. Now, 5.2.1 (superseding earlier 5.2 submission) is sitting in Staging:C with gcc9, linux-glibc-devel, libreoffice and dozen of other packages since 07/08. Some of the mentioned broke the staging, so they were removed (like linux-glibc-devel breaking firefox). And that triggered a full rebuild. Actually a full double-rebuild as kernel usually triggers a second full rebuild on its own. libreoffice was still broken in the staging this morning (even though it was removed from the staging 3 days ago). Libuv was removed this morning, perhaps to fix that, and given cmake depends on libuv, almost full rebuild was triggered by that again. And so on :). Now, we will see in a day or so, if the staging is working or not... Note that this is pretty usual and normal with stagings and changes in core packages like the above, I am not accusing anybody. I would only not put gcc9, linux-glibc-devel, and kernel together in a single staging ;). I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :). (*) Note that packman also have a Factory repo which builds against Kernel:stable. regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 10:10:52 +0200, Jiri Slaby wrote:
I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :).
There is Tumbleweed:Update for a faster update path, IIRC, so if the fix is urgently requested, we can push to there, too. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 19 Jul 2019 at 10:43, Jiri Slaby <jslaby@suse.cz> wrote:
I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :).
Yup, that seems suboptimal. I would imagine the staging managers had no idea there was anything special about this kernel submission. Did anyone notify the staging managers regarding the CVE sensitivity of the submission? I've found that a note in an SR, an email or a ping in IRC to any of the staging managers is universally met with my request being handled in the way I wish. I would be shocked if they couldn't have shoved the kernel in its own staging and got it through quickly. I'm having to do that right now given I've got half a dozen submissions that absolutely need the opposite treatment - they need to be clumped together and care taken to ensure we only merge them as one unified blob :) Hope this helps Richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Jul 19, 2019 at 10:50:17AM +0200, Richard Brown wrote:
On Fri, 19 Jul 2019 at 10:43, Jiri Slaby <jslaby@suse.cz> wrote:
I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :).
Yup, that seems suboptimal. I would imagine the staging managers had no idea there was anything special about this kernel submission.
Did anyone notify the staging managers regarding the CVE sensitivity of the submission?
I've found that a note in an SR, an email or a ping in IRC to any of the staging managers is universally met with my request being handled in the way I wish. I would be shocked if they couldn't have shoved the kernel in its own staging and got it through quickly.
I'm having to do that right now given I've got half a dozen submissions that absolutely need the opposite treatment - they need to be clumped together and care taken to ensure we only merge them as one unified blob :)
We occasionaly ping dimstar on critical security issues. AFAIR for SACK fixes these also had problems with overlayfs at the same time, where openqa used overlayfs incorrectly. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 19. 07. 19, 10:52, Marcus Meissner wrote:
AFAIR for SACK fixes these also had problems with overlayfs at the same time, where openqa used overlayfs incorrectly.
tcp fixes were one release earlier than that (revision 492 in factory). ofs was problematic later -- when submitting what was later revision 493. This contained "only" the fix for the above TCP fixes. Here, it took 7 days to fix the ofs issue as the notification e-mail was kept on the o365 account unnoticed. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
hi, Am 19.07.19 um 10:10 schrieb Jiri Slaby:
On 19. 07. 19, 5:38, simonizor wrote:
Is there a reason for this? I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue. I, as a maintainer of that kernel, can only say, that the process from
THANK YOU for that. i use it since years now! -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (11)
-
Andrei Borzenkov -
Felix Miata -
Hans-Peter Jansen -
Jiri Slaby -
Marcus Meissner -
Michal Kubecek -
PGNet Dev -
Rainer Klier -
Richard Brown -
simonizor -
Takashi Iwai