[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 <a.abfalterer gmail.com>] * ) mod_ssl: Fix memory leak in stapling code. PR63687. [Stefan Eissing] * ) mod_http2: Fixed regression that no longer set H2_STREAM_ID and H2_STREAM_TAG. PR64330 [Stefan Eissing] * ) mod_http2: Fixed regression that caused connections to close when mod_reqtimeout was configured with a handshake timeout. Fixes gitub issue #196. [Stefan Eissing] * ) mod_proxy_http2: the "ping" proxy parameter (see <https://httpd.apache.org/docs/2.4/mod/mod_proxy.html>) is now used when checking the liveliness of a new or reused h2 connection to the backend. With short durations, this makes load-balancing more responsive. The module will hold back requests until ping conditions are met, using features of the HTTP/2 protocol alone. [Ruediger Pluem, Stefan Eissing] * ) core: httpd is no longer linked against -lsystemd if mod_systemd is enabled (and built as a DSO). [Rainer Jung] * ) mod_proxy_http2: respect ProxyTimeout settings on backend connections while waiting on incoming data. [Ruediger Pluem, Stefan Eissing] - modified patches % apache2-mod_proxy_uwsgi-fix-crash.patch (refreshed) - modified sources % apache2.keyring ==== emacs ==== Version update (26.3 -> 27.1) Subpackages: emacs-info emacs-nox emacs-x11 etags - Provide for all three emacs layouts, that are emacs-nox, emacs-x11, and emacs-gtk their own pdumper file (boo#1175233) - Update to GNU Emacs version 27.1 * Emacs is now compliant with the latest version 13.0 of the Unicode Standard. * Emacs can now use the XDG convention for init files. The 'XDG_CONFIG_HOME' environment variable (which defaults to "~/.config") specifies the XDG configuration parent directory. Emacs checks for "init.el" and other configuration files inside the "emacs" subdirectory of 'XDG_CONFIG_HOME', i.e. "$XDG_CONFIG_HOME/emacs/init.el" However, Emacs will still initially look for init files in their traditional locations if "~/.emacs.d" or "~/.emacs" exist, even if "$XDG_CONFIG_HOME/emacs" also exists. This means that you must delete or rename any existing "~/.emacs.d" and "~/.emacs" to enable use of the XDG directory. * The varius changes can be read in detail at /usr/share/emacs/27.1/etc/NEWS - Port and rename patch emacs-26.2.dif to emacs-27.1.dif - Modify/port patches * emacs-24.1-ps-mule.patch * emacs-24.3-asian-print.patch * emacs-24.3-iconic.patch * emacs-24.3-x11r7.patch * emacs-24.4-flyspell.patch * emacs-24.4-glibc.patch * emacs-24.4-nonvoid.patch * emacs-24.4-ps-bdf.patch * emacs-24.4-xim.patch * emacs-25.1-custom-fonts.patch * emacs-25.2-ImageMagick7.patch * emacs-26.1-xft4x11.patch - Remove patches now upstream solved * xwidget.patch * emacs-libX11-boo1175028.patch - Add patch emacs-27.1-pdftex.patch to generate pdf files - Add emacs-27.1-pdf.tar.xz as result of this to use texlive only once - Use emacs.keyring to verify source tar ball ==== iputils ==== Subpackages: rarpd - Remove 2 old patches (iputils-sec-ping-unblock.diff, iputils-ping-interrupt.diff) Although not documented, they both belong to bsc#674304. Fix from 2011 was resolved upstream in commit 810dd7f ("ping,ping6: Unmask signals on start-up.") [1], released in s20121112. - Use %autosetup -p1 ==== publicsuffix ==== Version update (20200715 -> 20200810) - Update to version 20200810: * Add algorithmia.com (#1071) * Added Mythic Beasts (#1075) * gTLD autopull: 2020-08-07 (#1085) * add rdv.to domains for pcarrier.ca Software Inc. (#1039) * thingdust AG: added in-house domains of internal services (#1031) * Add mcdir.ru and vps.mcdir.ru (#1051) * Add na4u.ru to list (#998) * gTLD autopull: 2020-07-29 (#1079) * gTLD autopull: 2020-07-28 (#1077) * add impertrix.com and impertrixcdn.com (#1060) * gTLD autopull: 2020-07-18 (#1069) * Add 12 sub zones to .br [20200714 update] (#1068)
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: #<font-spec nil nil Source\ Code\ Pro nil nil bold italic nil 14.0 nil nil nil nil> Anyone else having such issues? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Peter Suetterlin <pit@astro.su.se> writes:
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: #<font-spec nil nil Source\ Code\ Pro nil nil bold italic nil 14.0 nil nil nil nil>
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 <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
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