Jiri Slaby writes:

On 07. 02. 20, 8:12, Hans-Peter Jansen wrote:

...

can we have a late 5.4 kernel for TW before going to 5.5, *please*.

Hi,

no, why would we? Unless there is a serious bug or problem, of course...

...

The virtualbox woes with 5.5 will keep that move more painful than ever.

You have to complain to virtualbox authors. It's apparently their fault not to upstream the modules in the past decade. It cannot stop new kernels to roll in openSUSE.

The other option is to politely ask our vbox maintainer to keep vbox up with 5.5. What's the problem, actually?

As the maintainer of Vagrant, that was designed to primarily use VirtualBox (not on openSUSE though), I'd like to know too.

...

While at it, is KVM fully tested with 5.5 on both sides?

Provided openQA runs on KVM -- and trust me, the kernel is massaged there -- I believe the answer is: as much as possible.

Well, we have openQA tests for Vagrant that will probably break in case there are issues with Virtualbox, so we should be covered here to catch breakage. Cheers, Dan -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

Am Freitag, 7. Februar 2020, 08:27:29 CET schrieb Jiri Slaby:

On 07. 02. 20, 8:12, Hans-Peter Jansen wrote:

...

can we have a late 5.4 kernel for TW before going to 5.5, *please*.

Hi,

no, why would we? Unless there is a serious bug or problem, of course...

Well, obviously, that happened already. I didn't checked that: https://build.opensuse.org/package/revisions/openSUSE:Factory/kernel-source

...

The virtualbox woes with 5.5 will keep that move more painful than ever.

You have to complain to virtualbox authors. It's apparently their fault not to upstream the modules in the past decade. It cannot stop new kernels to roll in openSUSE.

I didn't ask you to stop, Jiri. This was meant as a polite request to arrange the timing a bit, and to fill the gap with another revision of 5.4 in order to avoid the trap, that we were captured in transition of 5.3 to 5.4 on TW, where we bobbed up and down with 5.3.12, while Leap got up to 5.3.16 at the same time. https://lists.opensuse.org/opensuse-factory/2019-12/msg00205.html

The other option is to politely ask our vbox maintainer to keep vbox up with 5.5. What's the problem, actually?

https://www.virtualbox.org/ticket/19145 Larry knows about this already, but given the convoluted code in question, even the code owners seems to struggle with this.. :-( Fun fact, the evil bits from nvidia suffered from the same issue, but it took a couple of hours to get fixed. This is a fine example, how code quality pays off in the long run.

...

While at it, is KVM fully tested with 5.5 on both sides?

Provided openQA runs on KVM -- and trust me, the kernel is massaged there -- I believe the answer is: as much as possible.

Sorry, Jiri, it wasn't my intention to patronize you or your colleges, just to make you aware of some issues, that affects quite a few users, and which can lead to bad timing effects from the users POV (in the *best* case, that is). Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07. 02. 20, 11:09, Dominique Leuenberger / DimStar wrote:

On Fri, 2020-02-07 at 10:57 +0100, Hans-Peter Jansen wrote:

...

Am Freitag, 7. Februar 2020, 08:27:29 CET schrieb Jiri Slaby:

...

On 07. 02. 20, 8:12, Hans-Peter Jansen wrote:

...

can we have a late 5.4 kernel for TW before going to 5.5, *please*.

Hi,

no, why would we? Unless there is a serious bug or problem, of course...

Well, obviously, that happened already. I didn't checked that:

https://build.opensuse.org/package/revisions/openSUSE:Factory/kernel-source

I currently have kernel 5.5.1 in staging and virtualbox builds against that:

https://build.opensuse.org/package/binaries/openSUSE:Factory:Staging:E/virtu...

The support was actually added here: https://build.opensuse.org/request/show/758050 2 months ago! So: what is actually the problem? thanks, -- js suse labs

On 07. 02. 20, 10:57, Hans-Peter Jansen wrote:

...

The other option is to politely ask our vbox maintainer to keep vbox up with 5.5. What's the problem, actually?

https://www.virtualbox.org/ticket/19145

Hmm, "Opened 2 months ago"

Larry knows about this already, but given the convoluted code in question, even the code owners seems to struggle with this.. :-(

The problem is how long would you want to wait given they are unable to fix it in 2 months?

Fun fact, the evil bits from nvidia suffered from the same issue, but it took a couple of hours to get fixed. This is a fine example, how code quality pays off in the long run.

I like you mention nvidia and code quality in the same paragraph :). All in all, the only way forward I see is to merge the drivers, really. What prevents them to do so? They wouldn't need to lose time like this with every single kernel version. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 7. Februar 2020, 17:13:02 CET schrieb Larry Finger:

On 2/7/20 4:17 AM, Jiri Slaby wrote:

...

On 07. 02. 20, 10:57, Hans-Peter Jansen wrote:

...

...

The other option is to politely ask our vbox maintainer to keep vbox up with 5.5. What's the problem, actually?

https://www.virtualbox.org/ticket/19145

Hmm, "Opened 2 months ago"

...

Larry knows about this already, but given the convoluted code in question, even the code owners seems to struggle with this.. :-(

The problem is how long would you want to wait given they are unable to fix it in 2 months?

...

Fun fact, the evil bits from nvidia suffered from the same issue, but it took a couple of hours to get fixed. This is a fine example, how code quality pays off in the long run.

I like you mention nvidia and code quality in the same paragraph :).

All in all, the only way forward I see is to merge the drivers, really. What prevents them to do so? They wouldn't need to lose time like this with every single kernel version.

Soon, most of the guest modules for VB will be included in the standard kernel; however, I am not aware of anyone starting to convert the host drivers. Even so, as I say below, this should not cause any lost time.

As the VirtualBox maintainer, my workflow is to test VB against the latest mainline kernel HEAD. When a kernel API changes, I prepare a patch so that the openSUSE version builds against the new version. About the time Kernel_HEAD_standard switches to a new kernel (v5.6.0-rc1 in the latest case), I push a new version with that patch included. I also post that patch on the VB developers newsgroup. It is hardly my fault if they fail to apply those changes.

Since the openSUSE versions of the VB kernel modules normally build against all kernels. including the current one that is transitional between V5.5 and v5.6, why is the failure of Oracle's version to build on a given kernel of issue here? If our users are going to download Oracle's RPM, rather than out packages, perhaps we should just drop our VB packages! It would free up a lot of OBS time, and my personal time. Yes, I am retired and have a lot of time, but there is a limit.

Larry, as mentioned already, you're doing a fantastic job on VB, and the package is in a really nice shape. It's not your fault, if upstream is not dealing well with their own creation and ignoring your work at the same time. It was my fault to believe, that we would be affected. Please beg my pardon everybody and especially you! It's a pleasure to work with you, and I'm happily awaiting the 5.5 kernel condensing in our favorite OS. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org