[opensuse-factory] New Tumbleweed snapshot 20200816 released!
Please note that this mail was generated by a script.
The described changes are computed based on the x86_64 DVD.
The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading:
https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version=Tumbleweed&build=20200816
Please do not reply to this email to report issues, rather file a bug
on bugzilla.opensuse.org. For more information on filing bugs please
see https://en.opensuse.org/openSUSE:Submitting_bug_reports
Packages changed:
apache2 (2.4.43 -> 2.4.46)
emacs (26.3 -> 27.1)
iputils
publicsuffix (20200715 -> 20200810)
=== Details ===
==== apache2 ====
Version update (2.4.43 -> 2.4.46)
Subpackages: apache2-doc apache2-example-pages apache2-prefork apache2-utils
- version update to 2.4.46
Changes with Apache 2.4.46
* ) mod_proxy_fcgi: Fix build warnings for Windows platform
[Eric Covener, Christophe Jaillet]
Changes with Apache 2.4.45
* ) mod_http2: remove support for abandoned http-wg draft
https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/.
[Stefan Eissing]
Changes with Apache 2.4.44
* ) mod_proxy_uwsgi: Error out on HTTP header larger than 16K (hard
protocol limit). [Yann Ylavic]
* ) mod_http2:
Fixes https://github.com/icing/mod_h2/issues/200:
"LimitRequestFields 0" now disables the limit, as documented.
Fixes https://github.com/icing/mod_h2/issues/201:
Do not count repeated headers with same name against the field
count limit. The are merged internally, as if sent in a single HTTP/1 line.
[Stefan Eissing]
* ) mod_http2: Avoid segfaults in case of handling certain responses for
already aborted connections. [Stefan Eissing, Ruediger Pluem]
* ) mod_http2: The module now handles master/secondary connections and has marked
methods according to use. [Stefan Eissing]
* ) core: Drop an invalid Last-Modified header value coming
from a FCGI/CGI script instead of replacing it with Unix epoch.
[Yann Ylavic, Luca Toscano]
* ) Add support for strict content-length parsing through addition of
ap_parse_strict_length() [Yann Ylavic]
* ) mod_proxy_fcgi: ProxyFCGISetEnvIf unsets variables when expression
evaluates to false. PR64365. [Michael König <mail ikoenig.net>]
* ) mod_proxy_http: flush spooled request body in one go to avoid
leaking (or long lived) temporary file. PR 64452. [Yann Ylavic]
* ) mod_ssl: Fix a race condition and possible crash when using a proxy client
certificate (SSLProxyMachineCertificateFile).
[Armin Abfalterer
Hi! Virtualbox crashes with kernel 5.8 on openSUSE Do you know it ??? I don't have "hardrock errors" like rebooting, but Virtualbox just refuses to start: ---------------------------- Für die virtuelle Maschine winni7 konnte keine neue Sitzung eröffnet werden. Failed to load R0 module /usr/lib/virtualbox/VMMR0.r0: SUP_IOCTL_LDR_OPEN failed (VERR_NO_EXEC_MEMORY). Failed to load VMMR0.r0 (VERR_NO_EXEC_MEMORY). Fehlercode: NS_ERROR_FAILURE (0x80004005) Komponente: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed} ------------------------------------- Discussion about it is here: https://forums.virtualbox.org/viewtopic.php?f=7&t=99310 Winni -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-08-18 at 13:10 +0200, Winfried Bartnick wrote:
Hi!
Virtualbox crashes with kernel 5.8 on openSUSE
Do you know it ???
https://bugzilla.opensuse.org/show_bug.cgi?id=1175201 Cheers, Dominique
Hi similarily, vmware player 15.5.6 does not work on kernel 5.8 as well, so I need to refrain from upgrading to latest Tumbleweed now... needing vmware player working. BR Christian Am 18.08.20 um 13:33 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-08-18 at 13:10 +0200, Winfried Bartnick wrote:
Hi!
Virtualbox crashes with kernel 5.8 on openSUSE
Do you know it ??? https://bugzilla.opensuse.org/show_bug.cgi?id=1175201
Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi! This happened with VirtualBox 6.11.2-1.3 and the Suse Tumbleweed from last night 17-18.August (CEDT). Winni Am 18.08.20 um 13:54 schrieb Christian Mahr:
Hi
similarily, vmware player 15.5.6 does not work on kernel 5.8 as well, so I need to refrain from upgrading to latest Tumbleweed now... needing vmware player working.
BR Christian
Am 18.08.20 um 13:33 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-08-18 at 13:10 +0200, Winfried Bartnick wrote:
Hi!
Virtualbox crashes with kernel 5.8 on openSUSE
Do you know it ??? https://bugzilla.opensuse.org/show_bug.cgi?id=1175201
Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Aug 18, 2020 at 01:54:55PM +0200, Christian Mahr wrote:
similarily, vmware player 15.5.6 does not work on kernel 5.8 as well, so I need to refrain from upgrading to latest Tumbleweed now... needing vmware player working.
It's a known problem (actually the same as with virtualbox, except with VMware it results in a triple fault) and only VMware can fix it. Apparently they plan to address the issue in upcoming Workstation 16 and it's unclear what to expect for 15.5.x: https://communities.vmware.com/thread/638457 Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi there, On Tue, 18 Aug 2020, 13:33:03 +0200, Dominique Leuenberger / DimStar wrote:
On Tue, 2020-08-18 at 13:10 +0200, Winfried Bartnick wrote:
Hi!
Virtualbox crashes with kernel 5.8 on openSUSE
Do you know it ???
to be honest, this is a perfect example where Oracle failed to keep track with recent kernel development! As we had seen it before, probably just not as extreme as we see it now, I thought it might be time to migrate all my virtual machines from VB to KVM... Guess what, I did not have trouble with any of them, which include Win 7 32bit, Win 10 64bit and various Linux VMs. One thing which really surprised me was, how well usage of USB devices works these days. I could even use a webcam inside a KVM VM which only very barely worked in VB. FWIW, I may have been lucky, but I certainly don't need VB anymore! PLEASE, this is not intended to start a flame war!
Cheers, Dominique
Cheers. l8er manfred
On 8/18/20 7:17 AM, Manfred Hollstein wrote:
to be honest, this is a perfect example where Oracle failed to keep track with recent kernel development! As we had seen it before, probably just not as extreme as we see it now, I thought it might be time to migrate all my virtual machines from VB to KVM...
Guess what, I did not have trouble with any of them, which include Win 7 32bit, Win 10 64bit and various Linux VMs. One thing which really surprised me was, how well usage of USB devices works these days. I could even use a webcam inside a KVM VM which only very barely worked in VB. FWIW, I may have been lucky, but I certainly don't need VB anymore!
If you look at https://bugzilla.opensuse.org/show_bug.cgi?id=1175201, you will note that conversion to KVM is my second suggested work around, right after staying with kernel 5.7. The fundamental reason for this situation is that the kernel developers in charge of memory management have the goal of restricting the acquisition of memory that can can execute code. When code external to the kernel can acquire this feature, a huge security hole exists. Through the past 4 or 5 kernel releases such memory acquisition has been tightened and VirtualBox has undergone several changes to adapt; however, with kernel 5.8, there is no adapting. Please note that I proposed a 2-line patch to our kernel developers to handle our situation until Oracle found a proper solution, but that request was denied. Oracle was also given advance notice. Apparently Oracle does have a solution, but it has not worked for me. Perhaps it will in work with VB 6.1.14, but I expect such a solution to be a temporary fix as it still requires the security hole. The real solution will be to incorporate libvirt the way that QEMU/KVM does, but that implementation is beyond my abilities. This issue has been a full-time sink for me for nearly 2 months. Unfortunately, I was not able to supply a seamless solution! Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Larry, On Tue, 18 Aug 2020, 18:28:16 +0200, Larry Finger wrote:
On 8/18/20 7:17 AM, Manfred Hollstein wrote:
to be honest, this is a perfect example where Oracle failed to keep track with recent kernel development! As we had seen it before, probably just not as extreme as we see it now, I thought it might be time to migrate all my virtual machines from VB to KVM...
Guess what, I did not have trouble with any of them, which include Win 7 32bit, Win 10 64bit and various Linux VMs. One thing which really surprised me was, how well usage of USB devices works these days. I could even use a webcam inside a KVM VM which only very barely worked in VB. FWIW, I may have been lucky, but I certainly don't need VB anymore!
If you look at https://bugzilla.opensuse.org/show_bug.cgi?id=1175201, you will note that conversion to KVM is my second suggested work around, right after staying with kernel 5.7.
yes, absolutely! I always appreciated your work (and applied your patches to my local systems), but...
The fundamental reason for this situation is that the kernel developers in charge of memory management have the goal of restricting the acquisition of memory that can can execute code. When code external to the kernel can acquire this feature, a huge security hole exists. Through the past 4 or 5 kernel releases such memory acquisition has been tightened and VirtualBox has undergone several changes to adapt; however, with kernel 5.8, there is no adapting.
... here's the point. I cannot see why/how Oracle/VB developers got involved to find a solution for this issue - and, I completely agree with the kernel developers in this respect and how they decided!
Please note that I proposed a 2-line patch to our kernel developers to handle our situation until Oracle found a proper solution, but that request was denied. Oracle was also given advance notice.
...
Apparently Oracle does have a solution, but it has not worked for me. Perhaps it will in work with VB 6.1.14, but I expect such a solution to be a temporary fix as it still requires the security hole.
Exactly. FWIW, I find it unacceptable to a wait for such a long period, assuming VM users will wait that long, even knowing it's not a *real* fix!
The real solution will be to incorporate libvirt the way that QEMU/KVM does, but that implementation is beyond my abilities.
And again, yes, this is the way forward from my point of view, and it's absolutely not against your work - it's just a good chance now to decide if Oracle is a real good open source citizen, or not.
This issue has been a full-time sink for me for nearly 2 months. Unfortunately, I was not able to supply a seamless solution!
Larry
Again, thanks a lot for your work! Cheers. l8er manfred
On Tue, 18 Aug 2020, 20:14:19 +0200, Manfred Hollstein wrote:
Hi Larry,
On Tue, 18 Aug 2020, 18:28:16 +0200, Larry Finger wrote:
On 8/18/20 7:17 AM, Manfred Hollstein wrote:
to be honest, this is a perfect example where Oracle failed to keep track with recent kernel development! As we had seen it before, probably just not as extreme as we see it now, I thought it might be time to migrate all my virtual machines from VB to KVM...
Guess what, I did not have trouble with any of them, which include Win 7 32bit, Win 10 64bit and various Linux VMs. One thing which really surprised me was, how well usage of USB devices works these days. I could even use a webcam inside a KVM VM which only very barely worked in VB. FWIW, I may have been lucky, but I certainly don't need VB anymore!
If you look at https://bugzilla.opensuse.org/show_bug.cgi?id=1175201, you will note that conversion to KVM is my second suggested work around, right after staying with kernel 5.7.
yes, absolutely! I always appreciated your work (and applied your patches to my local systems), but...
The fundamental reason for this situation is that the kernel developers in charge of memory management have the goal of restricting the acquisition of memory that can can execute code. When code external to the kernel can acquire this feature, a huge security hole exists. Through the past 4 or 5 kernel releases such memory acquisition has been tightened and VirtualBox has undergone several changes to adapt; however, with kernel 5.8, there is no adapting.
... here's the point. I cannot see why/how Oracle/VB developers got involved to find a solution for this issue - and, I completely agree
correction: I cannot see how they got involved or responded at all! This was my main intention to bring over...
with the kernel developers in this respect and how they decided!
Please note that I proposed a 2-line patch to our kernel developers to handle our situation until Oracle found a proper solution, but that request was denied. Oracle was also given advance notice.
...
Apparently Oracle does have a solution, but it has not worked for me. Perhaps it will in work with VB 6.1.14, but I expect such a solution to be a temporary fix as it still requires the security hole.
Exactly. FWIW, I find it unacceptable to a wait for such a long period, assuming VM users will wait that long, even knowing it's not a *real* fix!
The real solution will be to incorporate libvirt the way that QEMU/KVM does, but that implementation is beyond my abilities.
And again, yes, this is the way forward from my point of view, and it's absolutely not against your work - it's just a good chance now to decide if Oracle is a real good open source citizen, or not.
This issue has been a full-time sink for me for nearly 2 months. Unfortunately, I was not able to supply a seamless solution!
Larry
Again, thanks a lot for your work!
Cheers.
l8er manfred
On 8/18/20 1:16 PM, Manfred Hollstein wrote:
... here's the point. I cannot see why/how Oracle/VB developers got involved to find a solution for this issue - and, I completely agree correction: I cannot see how they got involved or responded at all! This was my main intention to bring over...
The Oracle/VB developers are the ones that have made the decision to keep their modules outside the kernel. I presume that they are doing this to keep the Linux version of VB as compatible as possible with that for Windows or OS X. Why would they not be responsible to fix the issue? It is not as if openSUSE has written VB. Our involvement is to keep the packages building and running on the various openSUSE releases. For some time, I have been providing patches for new kernels to Oracle. In this case, the fix was beyond my abilities. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Larry, On Tue, 18 Aug 2020, 20:24:52 +0200, Larry Finger wrote:
On 8/18/20 1:16 PM, Manfred Hollstein wrote:
... here's the point. I cannot see why/how Oracle/VB developers got involved to find a solution for this issue - and, I completely agree correction: I cannot see how they got involved or responded at all! This was my main intention to bring over...
The Oracle/VB developers are the ones that have made the decision to keep their modules outside the kernel. I presume that they are doing this to keep the Linux version of VB as compatible as possible with that for Windows or OS X.
Why would they not be responsible to fix the issue? It is not as if openSUSE has written VB.
Exactly, and this is why I believe the fault is at their side! Every Linux distribution running a 5.8 kernel will simply not work with VB, full stop!
Our involvement is to keep the packages building and running on the various openSUSE releases. For some time, I have been providing patches for new kernels to Oracle. In this case, the fix was beyond my abilities.
Fully agreed! This is, why I decided it's time to change...
Larry
Cheers. l8er manfred
On 8/18/20 2:38 PM, Manfred Hollstein wrote:
Exactly, and this is why I believe the fault is at their side! Every Linux distribution running a 5.8 kernel will simply not work with VB, full stop!
No, not quite true. Virtualbox 6.1.3 (testbuild, build=139989, sdkbuild=139990) with virtualbox-ext-oracle (build=139990), builds and works with Linux 5.8.1. There is no "released" version of virtualbox for that yet, but slowly and surely it is coming. 5.2 branch is unsupported at this time and will not have updates for Linux 5.8. -- David C. Rankin, J.D.,P.E.
Hi! Now I got the workaround to get the VirtualBox started with kernel 5.17: a) Edit the file /etc/zypp/zypp.conf b) Set multiversion = provides:multiversion(kernel) This is the default with TumbleWeed c) Enhance the multiversion.kernels: multiversion.kernels = latest,latest-1,running,5.7.11-1-default Done. Now select 5.7.11-1-default at grub and VirtualBox works again. Winni -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 20. August 2020, 14:15:43 CEST schrieb Winfried Bartnick:
multiversion.kernels = latest,latest-1,running,5.7.11-1-default
Done.
Now select 5.7.11-1-default at grub and VirtualBox works again.
Why not to pin kernel 5.7.11 (and other 5.7.11 related stuff) until VBox works with Kernel 5.8? This worked fine for me. But it leads me to a question: Is there some way how I can pin just the major version (5.7) and not the specific 5.7.11? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 20, 2020 at 02:34:59PM +0200, Axel Braun wrote:
Am Donnerstag, 20. August 2020, 14:15:43 CEST schrieb Winfried Bartnick:
multiversion.kernels = latest,latest-1,running,5.7.11-1-default
Done.
Now select 5.7.11-1-default at grub and VirtualBox works again.
Why not to pin kernel 5.7.11 (and other 5.7.11 related stuff) until VBox works with Kernel 5.8? This worked fine for me.
But it leads me to a question: Is there some way how I can pin just the major version (5.7) and not the specific 5.7.11?
You could e.g. build a fake empty package which would conflict with kernel-default >= 5.8. But there is little point, there won't be any further 5.7.x kernel update in the repository once the kernel branch updated to 5.8. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello Michal, Am Donnerstag, 20. August 2020, 16:14:35 CEST schrieb Michal Kubecek:
On Thu, Aug 20, 2020 at 02:34:59PM +0200, Axel Braun wrote:
But it leads me to a question: Is there some way how I can pin just the major version (5.7) and not the specific 5.7.11?
You could e.g. build a fake empty package which would conflict with kernel-default >= 5.8.
Good idea, but this may case problems in other areas. Zypper obviously does not offer this
But there is little point, there won't be any further 5.7.x kernel update in the repository once the kernel branch updated to 5.8.
Sure, see the question more in general (it could be any package with a major version) Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger wrote:
Packages changed: emacs (26.3 -> 27.1)
Just updated my system, which also included this.
Now the font system seems foobar. Emacs comes up with a different size and
font, and when I try to change the font via Options->Set Default Font I can
select whatever I want in the dialog that pops up, I will always get an error
message that the font could not be found, e.g.,
set-face-attribute: Font not available: #
Peter Suetterlin
Dominique Leuenberger wrote:
Packages changed: emacs (26.3 -> 27.1)
Just updated my system, which also included this.
Now the font system seems foobar. Emacs comes up with a different size and font, and when I try to change the font via Options->Set Default Font I can select whatever I want in the dialog that pops up, I will always get an error message that the font could not be found, e.g.,
set-face-attribute: Font not available: #
Anyone else having such issues?
Yes, I've had these. tl;dr; change the setting "Emacs.FontBackend" to
"ftcrhb,x" in either your .Xresources or in
/usr/share/X11/app-defaults/Emacs
A fix for this should be coming to Tumbleweed very soon as well.
Cheers,
Dan
--
Dan Čermák
Dan Čermák wrote:
Yes, I've had these. tl;dr; change the setting "Emacs.FontBackend" to "ftcrhb,x" in either your .Xresources or in /usr/share/X11/app-defaults/Emacs
A fix for this should be coming to Tumbleweed very soon as well.
Thanks! That indeed cured it :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Axel Braun -
Christian Mahr -
Dan Čermák -
David C. Rankin -
Dominique Leuenberger -
Dominique Leuenberger / DimStar -
Larry Finger -
Manfred Hollstein -
Michal Kubecek -
Peter Suetterlin -
Winfried Bartnick