body:
--1596977732.065BE0.9287
Date: Sun, 9 Aug 2020 12:55:32 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175039

            Bug ID: 1175039
           Summary: pkgconf does not search /usr/local
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Development
          Assignee: screening-team-bugs-at-suse.de
          Reporter: andreas_nordal_4-at-hotmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

In order to not break everything that relies on pkg-config for finding locally
built libraries, pkgconf can not be used as a pkg-config replacement until it
can find .pc files in the normal installation path for locally built libraries
(such as /usr/local/lib64/pkgconfig/ on x64).

More info: https://access.redhat.com/discussions/4734691

I'm testing with pkgconf version 1.7.3.

Testcase:
Here is a Meson project that will install a .pc file only. This way, we are
consulting Meson for the installation path:

    project('null-lib', 'c')

    version = '1.0.0'
    nullib = library('null-lib', version : version)

    pkg_mod = import('pkgconfig')
    pkg_mod.generate(
        libraries : nullib,
        version : version,
        name : 'null-lib',
        filebase : 'null-lib',
        description : 'Null library.'
    )

After letting it install to wherever it wants, this shall succeed:

    pkg-config --exists null-lib

summary: pkgconf does not search /usr/local


--1597044327.8AC67CE0.11868
Date: Mon, 10 Aug 2020 07:25:27 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175044

            Bug ID: 1175044
           Summary: Recent chromium upgrade broke headless mode
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: tchvatal-at-suse.com
          Reporter: michal.vyskocil-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

One of the recent chromium upgrades broke headless mode. I have
chromium-84.0.4147.89-1.1.x86_64 and the headless mode crashes. Normal mode
works well.

BTW: I've checked Google Chrome and it crashes as well, but this is unrelated
bug and can be mitigated by --disable-gpu switch.

/usr/bin/chromium --headless
[0810/091855.149698:FATAL:platform_selection.cc(45)] Invalid ozone platform:
headless
#0 0x557e3997ec49 base::debug::CollectStackTrace()
#1 0x557e398c7a96 base::debug::StackTrace::StackTrace()
#2 0x557e398d882c logging::LogMessage::~LogMessage()
#3 0x557e36ad0439 ui::GetOzonePlatformId()
#4 0x557e36ad0ac2 ui::PlatformObject<>::Create()
#5 0x557e36ad088c ui::(anonymous namespace)::EnsureInstance()
#6 0x557e36ad09fe ui::OzonePlatform::InitializeForUI()
#7 0x557e3aa58198 aura::Env::Init()
#8 0x557e3aa58253 aura::Env::CreateInstance()
#9 0x557e3748f4c0 content::BrowserMainLoop::InitializeToolkit()
#10 0x557e37490f21 content::BrowserMainRunnerImpl::Initialize()
#11 0x557e3d5bc361 headless::HeadlessContentMainDelegate::RunProcess()
#12 0x557e39331475 content::RunBrowserProcessMain()
#13 0x557e39331603 content::ContentMainRunnerImpl::RunServiceManager()
#14 0x557e3933292f content::ContentMainRunnerImpl::Run()
#15 0x557e3935c60a service_manager::Main()
#16 0x557e39330d2b content::ContentMain()
#17 0x557e39359ccf headless::(anonymous namespace)::RunContentMain()
#18 0x557e3935aaba headless::HeadlessShellMain()
#19 0x557e3645dc0c ChromeMain
#20 0x7f1f8dd1ecca __libc_start_main
#21 0x557e3645da8a _start

Received signal 6
#0 0x557e3997ec49 base::debug::CollectStackTrace()
#1 0x557e398c7a96 base::debug::StackTrace::StackTrace()
#2 0x557e3997e689 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f1f91e13260 (/lib64/libpthread-2.31.so+0x1425f)
#4 0x7f1f8dd344b1 __GI_raise
#5 0x7f1f8dd1d539 __GI_abort
#6 0x557e3997e135 base::debug::BreakDebugger()
#7 0x557e398d8af5 logging::LogMessage::~LogMessage()
#8 0x557e36ad0439 ui::GetOzonePlatformId()
#9 0x557e36ad0ac2 ui::PlatformObject<>::Create()
#10 0x557e36ad088c ui::(anonymous namespace)::EnsureInstance()
#11 0x557e36ad09fe ui::OzonePlatform::InitializeForUI()
#12 0x557e3aa58198 aura::Env::Init()
#13 0x557e3aa58253 aura::Env::CreateInstance()
#14 0x557e3748f4c0 content::BrowserMainLoop::InitializeToolkit()
#15 0x557e37490f21 content::BrowserMainRunnerImpl::Initialize()
#16 0x557e3d5bc361 headless::HeadlessContentMainDelegate::RunProcess()
#17 0x557e39331475 content::RunBrowserProcessMain()
#18 0x557e39331603 content::ContentMainRunnerImpl::RunServiceManager()
#19 0x557e3933292f content::ContentMainRunnerImpl::Run()
#20 0x557e3935c60a service_manager::Main()
#21 0x557e39330d2b content::ContentMain()
#22 0x557e39359ccf headless::(anonymous namespace)::RunContentMain()
#23 0x557e3935aaba headless::HeadlessShellMain()
#24 0x557e3645dc0c ChromeMain
#25 0x7f1f8dd1ecca __libc_start_main
#26 0x557e3645da8a _start
  r8: 0000000000000000  r9: 00007ffc0b519a20 r10: 0000000000000008 r11:
0000000000000246
 r12: 00007ffc0b519d00 r13: 00007ffc0b51a4d0 r14: 0000000000000055 r15:
00007ffc0b519cf0
  di: 0000000000000002  si: 00007ffc0b519a20  bp: 00007ffc0b519c70  bx:
00007f1f8943e1c0
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f1f8dd344b1  sp:
00007ffc0b519a20
  ip: 00007f1f8dd344b1 efl: 0000000000000246 cgf: 002b000000000033 erf:
0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.


--1597095296.bE1e0.4483
Date: Mon, 10 Aug 2020 21:34:56 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175085

            Bug ID: 1175085
           Summary: VUL-0: chromium: multiple security issues fixed in 84.0.4147.125
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: tchvatal-at-suse.com
          Reporter: Andreas.Stieger-at-gmx.de
        QA Contact: qa-bugs-at-suse.de
                CC: security-team-at-suse.de
          Found By: ---
           Blocker: ---

https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop.html

Fixed in Chromium 84.0.4147.125

CVE-2020-6542: Use after free in ANGLE
CVE-2020-6543: Use after free in task scheduling
CVE-2020-6544: Use after free in media
CVE-2020-6545: Use after free in audio
CVE-2020-6546: Inappropriate implementation in installer. CVE-2020-6547:
Incorrect security UI in mediaCVE-2020-6548: Heap buffer overflow in Skia
CVE-2020-6549: Use after free in media
CVE-2020-6550: Use after free in IndexedDB
CVE-2020-6551: Use after free in WebXR
CVE-2020-6552: Use after free in Blink
CVE-2020-6553: Use after free in offline mode
CVE-2020-6554: Use after free in extensions
CVE-2020-6555: Out of bounds read in WebGL
Various fixes from internal audits, fuzzing and other initiatives


--1597135026.3Cc6110.27969
Date: Tue, 11 Aug 2020 08:37:06 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175099

            Bug ID: 1175099
           Summary: Tensorflow Lite devel is missing header files
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: marco.varlese-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

The tensorflow-lite devel package does not provide any header files needed for
development.


body:
--1597199545.ea6Cc51.6448
Date: Wed, 12 Aug 2020 02:32:25 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175132

            Bug ID: 1175132
           Summary: go1.15 release tracking
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Development
          Assignee: screening-team-bugs-at-suse.de
          Reporter: jkowalczyk-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

go1.15 (released 2020-08-11) is a major release of Go.
Minor releases of go1.15.x will be provided through August 2021.
This issue tracks go1.15.x releases packaged and submitted initially
to openSUSE:Factory and can be referenced in submissions to
additional repositories.

Go Release Cycle
https://github.com/golang/go/wiki/Go-Release-Cycle

Go Release history
https://golang.org/doc/devel/release.html

summary: go1.15 release tracking


body:
--1597222778.Cf5B1.4760
Date: Wed, 12 Aug 2020 08:59:38 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175140

            Bug ID: 1175140
           Summary: X11:Solus: budgie-desktop not included in Leap 15.2
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Maintenance
          Assignee: maintenance-at-opensuse.org
          Reporter: callumjfarmer13-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

budgie-desktop has been requested to be included in Leap 15.2 on Reddit.
https://www.reddit.com/r/openSUSE/comments/i5t0dn/will_there_be_official_budgie_desktop_packages/?utm_source=share&utm_medium=web2x

pkgs: budgie-desktop budgie-screensaver


--1597232981.16ea4.16944
Date: Wed, 12 Aug 2020 11:49:41 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175154

            Bug ID: 1175154
           Summary: Add Control-flow Enforcement Technology (CET) to openSUSE
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: lpechacek-at-suse.com
        QA Contact: qa-bugs-at-suse.de
                CC: aginies-at-suse.com, jcheung-at-suse.com,
                    lubos.kocman-at-suse.com, matz-at-suse.com
          Found By: ---
           Blocker: ---

Control-flow Enforcement Technology (CET) looks like a promising mitigation of
Return Oriented Programming group of attacks. CET requires support in the CPU
(starting with Intel Tiger Lake, if I'm not mistaken), kernel support, and
support in the libraries and the application code itself.

According to the technology partner, this capability needs enabling:
*    Kernel
*    KVM
*    QEMU
*    Tool Chain GCC v8.1
*    GDB Support – TBD
*    GNU Binutils v2.31
*    GLIBC v2.28


--1597239792.bfbf4ca0.20927
Date: Wed, 12 Aug 2020 13:43:12 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175168

            Bug ID: 1175168
           Summary: cc fails during compilation: lto1: internal compiler error: Segmentation fault
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: matz-at-suse.com
          Reporter: rfrohl-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840550
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840550&action=edit
osc rbl

I tried to update radare2 and ran into an error during compilation on x86_64.
Relevant part from the attached log is this one (I think):

> [  156s] cc -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -MD   -fPIC -g -Wall -D__UNIX__=1 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -MD   -fPIC -g -Wall -D__UNIX__=1 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr/../shlr/zip/
 include -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -MD   -fPIC -g -Wall -D__UNIX__=1 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr/../shlr/zip/include -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/include -MD   -fPIC -g -Wall -D__UNIX__=1 -DR2_PLUGIN_INCORE -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr/..//shlr -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr/../shlr/zip/include -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr -I/home/abuild/rpmbuild/BUILD/radare2-4.5.0/libr/include -fvisibility=hidden -I../../shlr/sdb/src//src -DHAVE_FORK=1 -DUSE_R2=1 -I../..
 /shlr -std=gnu99 -D_XOPEN_SOURCE=700 -D_POSIX_C_SOURCE=200809L  -Wall -Wsign-compare -g -Wall -O0 -MMD -fPIC -g -flto=auto -flto=auto -flto=auto -flto=auto -flto=auto -flto=auto -flto=auto -flto=auto -lm -lssl -lcrypto -lpthread -ldl -lm -fvisibility=hidden -o sdb main.o cdb.o buffer.o cdb_make.o ls.o sdbht.o ht_uu.o sdb.o num.o base64.o match.o json.o ns.o lock.o util.o disk.o query.o array.o fmt.o journal.o dict.o ht_pp.o ht_up.o set.o diff.o
> [  156s] during IPA pass: cp
> [  156s] lto1: internal compiler error: Segmentation fault

build log from 'osc rbl home:rfrohl:branches:devel:tools radare2
openSUSE_Tumbleweed  x86_64'.

Please let me know if you need anything else from me :)


body:
--1597258675.eF4E60.10918
Date: Wed, 12 Aug 2020 18:57:55 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175201

            Bug ID: 1175201
           Summary: VirtualBox fails with kernel 5.8
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Factory
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Virtualization:Tools
          Assignee: virt-bugs-at-suse.de
          Reporter: Larry.Finger-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840578
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840578&action=edit
Changes needed for kernel 5.8 for patch to module_memory to work

First some background: For several cycles, the kernel developers have been
restricting the allocation of executable memory for out-of-kernel modules. With
5.8, the method used by VirtualBox is no longer accessible. The resulting error
is as follows:

Failed to open a session for the virtual machine <VM Name>

"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)."

I tried to find workarounds for this problem, but the only one I found requires
modifying the kernel, which the openSUSE developers would not make part of the
distribution [1][2]. I expect that Oracle will likely find a solution using
libvirt, but a rewrite of that magnitude is beyond my capabilities.

The current solutions are as follows:

1. Remain with kernel 5.7.

2. Convert from VirtualBox to KVM.[3] The quoted web page covers the issue, and
I will not discuss it further.

3. It is reported that the test builds at [4] work. Be sure to get the latest
6.1.X test build for 64-bit Linux and the Extensions. Before installing that
package, use YaST to remove all the regular VB packages. When Oracle's release
runs with kernel 5.8, you will need to rerun their '.run' file with the
uninstall option. This option may or may not work. I had trouble with it.

4. Use a modified kernel and modify the vboxdrv kernel module. If you do not
already generate a custom kernel, use YaST to install the kernel-source
package. Then cd to the kernel source directory. For those of you who used YaST
to get the kernel, then that is /usr/src/linux-5.8.X-Y. X and Y will depend on
the version you just installed. You will also need the corresponding config
file from /boot - use 'cp /boot/config-$(uname -r) ." Everyone should download
the file temp_kernel.patch into the current directory. Then run the following
commands:

patch -p1 < temp_kernel_patch
make
sudo make modules_install install

If you get a permissions error from the first command, you will need to use
sudo for all 3 commands. Once these commands finish, reboot into the new
kernel.

After you reboot, use 'sudo zypper install virtualbox-host-source package' to
verify that the source is installed. Then
cd /usr/src/kernel-modules/virtualbox/src
Download the attachment fix_vboxdrv_for_5.8.patch and run the following:
sudo patch -p1 < fix_vboxdrv_for_5.8.patch
sudo make
sudo make install

Then reboot. VirtualBox should now work.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1172897
[2] https://lists.opensuse.org/opensuse-kernel/2020-06/msg00002.html
[3]
https://joseph.zikusooka.com/?p=981#:~:text=To%20convert%20from%20VirtualBox%20to%20KVM%2C%20look%20for%20your%20VDI%20images.&text=You%20can%20now%20import%20the,'Storage%20format'%20to%20qcow2.
[4]https://www.virtualbox.org/wiki/Testbuilds

summary: VirtualBox fails with kernel 5.8


--1597266168.61d42320.15710
Date: Wed, 12 Aug 2020 21:02:48 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175205

            Bug ID: 1175205
           Summary: Audacity 2.4.2-2.2 issues loading some wav files
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: SUSE Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: dommason-at-yahoo.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840580
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840580&action=edit
WAV file that will not load into Audacity 2.4.2 on Tumbleweed

When trying to load a wav file copied from a Zoom R16 multitrack, I get the
following message:

"Audacity did not recognise the type of file 'MONO-000.WAV'.
Try installing FFmpeg. For uncompressed files, also try File > Import > Raw
Data."

These particular wav files are identified as:

file MONO-000.WAV
MONO-000.WAV: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit,
mono 44100 Hz

Files from this device did (and do) load in earlier releases of Audacity

eg I have a VirtualBox VM with LinuxMint running Audacity 2.1.2 which loads the
file with no problem

If I use FFmpeg to convert the file to a wav file

 ffmpeg -i MONO-000.WAV converted.wav

then "converted.wav" file loads into Audacity

Audacity on my system is:

Information for package audacity:
---------------------------------
Repository     : openSUSE-Tumbleweed-Oss
Name           : audacity
Version        : 2.4.2-2.2
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 17.0 MiB
Installed      : Yes
Status         : up-to-date
Source package : audacity-2.4.2-2.2.src

ffmpeg-4 is:

Information for package ffmpeg-4:
---------------------------------
Repository     : packman
Name           : ffmpeg-4
Version        : 4.3.1-6.2
Arch           : x86_64
Vendor         : http://packman.links2linux.de
Installed Size : 2.2 MiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : ffmpeg-4-4.3.1-6.2.src


--1597328886.b75dA0.12578
Date: Thu, 13 Aug 2020 14:28:06 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175233

            Bug ID: 1175233
           Summary: editors/emacs: Bug dump file load failed in Emacs 27.1
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Hardware: x86-64
                OS: openSUSE Factory
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: 3rd party software
          Assignee: werner-at-suse.com
          Reporter: open-at-brsvh.org
        QA Contact: screening-team-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Description of problem:

After I install emacs(27.1-331.1) and try to run it. I get some pdump file load
error.

```
desired fingerprint: xxx
found fingerprint: xxx
emacs: could not load dump file
"/usr/lib/emacs/27.1/x86_64-suse-linux/emacs.pdmp": not built for this Emacs
executable
```

Reproduce:

Install the emacs package of editors/emacs and run it.


body:
--1597394516.516D2d0.28502
Date: Fri, 14 Aug 2020 08:41:56 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175266

            Bug ID: 1175266
           Summary: [glibc2.32] ceph build failure
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: martin.liska-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Fails with new release of glibc here:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:C/ceph/standard/x86_64

with:

[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.cc:
In function 'void install_sighandler(int, signal_handler_t, int)':
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
error: 'sys_siglist' was not declared in this scope
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
note: in definition of macro 'sig_str'
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.cc:
In function 'void handle_fatal_signal(int)':
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
error: 'sys_siglist' was not declared in this scope
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
note: in definition of macro 'sig_str'
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.cc:
In member function 'virtual void* SignalHandler::entry()':
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
error: 'sys_siglist' was not declared in this scope
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~
[  158s]
/home/abuild/rpmbuild/BUILD/ceph-15.2.4-89-g583fe198f6/src/global/signal_handler.h:24:26:
note: in definition of macro 'sig_str'
[  158s]    24 | # define sig_str(signum) sys_siglist[signum]
[  158s]       |                          ^~~~~~~~~~~

summary: [glibc2.32] ceph build failure


body:
--1597394886.620eD0.23472
Date: Fri, 14 Aug 2020 08:48:06 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175268

            Bug ID: 1175268
           Summary: [glibc2.32] kbuild build failure
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: martin.liska-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Fails due to a new glibc release here:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:C/kbuild/standard/x86_64

with:
[  177s]
/home/abuild/rpmbuild/BUILD/kbuild-0.1.9998svn3110/src/kash/jobs.c:399:21:
error: 'sys_siglist' undeclared (first use in this function)
[  177s]   399 |    if (st < NSIG && sys_siglist[st])
[  177s]       |                     ^~~~~~~~~~~

summary: [glibc2.32] kbuild build failure


--1597403211.CA03d0.7524
Date: Fri, 14 Aug 2020 11:06:51 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175274

            Bug ID: 1175274
           Summary: New GNU Emacs does not provide (process-kill-without-query) anymore
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: All
                OS: openSUSE Factory
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: werner-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

this leads top error messages like:
```
  Symbol?s function definition is void: process-kill-without-query
```
therefore all packages using the lisp function call
(process-kill-without-query) should been update to latest version or on behalf
of the maintainers of

  anthy
  gnuserv
  psgml
  uim

the function call

  (process-kill-without-query process)

has to be replaced with

  (set-process-query-on-exit-flag process nil)

...

From documentation:

 set-process-query-on-exit-flag is a built-in function in ?C source code?.

 (set-process-query-on-exit-flag PROCESS FLAG)

   Probably introduced at or before Emacs version 22.1.

 Specify if query is needed for PROCESS when Emacs is exited.
 If the second argument FLAG is non-nil, Emacs will query the user before
 exiting or killing a buffer if PROCESS is running.  This function
 returns FLAG.


--1597404816.DbCf50.9115
Date: Fri, 14 Aug 2020 11:33:36 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175278

            Bug ID: 1175278
           Summary: [glibc2.32] kdelibs4support build failure
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: martin.liska-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Fails in a staging with new glibc:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:C/kdelibs4support/standard/x86_64

due to:
[  221s] make[2]: *** [src/CMakeFiles/kf5deprecatedwidgets.dir/build.make:81:
src/kdedeprecatedwidgets.cpp] Segmentation fault

TERM=xterm osc chroot
abuild@marxinbox:~> cd /home/abuild/rpmbuild/BUILD/kdelibs4support-5.73.0/build
abuild@marxinbox:~/rpmbuild/BUILD/kdelibs4support-5.73.0/build> valgrind
/usr/bin/kgendesignerplugin -o
/home/abuild/rpmbuild/BUILD/kdelibs4support-5.73.0/build/src/kdedeprecatedwidgets.cpp
/home/abuild/rpmbuild/BUILD/kdelibs4support-5.73.0/src/kdedeprecated.widgets
==9637== Memcheck, a memory error detector
==9637== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9637== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==9637== Command: /usr/bin/kgendesignerplugin -o
/home/abuild/rpmbuild/BUILD/kdelibs4support-5.73.0/build/src/kdedeprecatedwidgets.cpp
/home/abuild/rpmbuild/BUILD/kdelibs4support-5.73.0/src/kdedeprecated.widgets
==9637==
==9637== Invalid read of size 8
==9637==    at 0x4C18480: QObject::thread() const (in
/usr/lib64/libQt5Core.so.5.15.0)
==9637==    by 0x10CE2A: ??? (in /usr/bin/kgendesignerplugin)
==9637==    by 0x4BF4F46: QCoreApplicationPrivate::init() (in
/usr/lib64/libQt5Core.so.5.15.0)
==9637==    by 0x4BF576B: QCoreApplication::QCoreApplication(int&, char**, int)
(in /usr/lib64/libQt5Core.so.5.15.0)
==9637==    by 0x10B6B6: ??? (in /usr/bin/kgendesignerplugin)
==9637==    by 0x50DBE09: (below main) (in /lib64/libc-2.32.so)
==9637==  Address 0x8 is not stack'd, malloc'd or (recently) free'd


body:
--1597409147.B4348faA0.13603
Date: Fri, 14 Aug 2020 12:45:47 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175286

            Bug ID: 1175286
           Summary: Keepass crash on startup
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: x86-64
                OS: SUSE Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: mv.jordan-at-gmx.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840646
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840646&action=edit
error

Overview:

    On a newly started/woken system, start the application. Sometimes, it
crashes.

Steps to Reproduce:

    1) Boot and log in to openSUSE.

    2.1) In a terminal:
$ keepass
    2.2) From an application menu, click "Keepass"

Actual Results:
    When successfully started, from a terminal the following additional output
is generated:

Locale not supported by C library. Using the fallback 'C' locale.

Whenever the application crashes, an error log is written to $HOME.

Expected Results:
    Start the application without crashes.

Build Date & Hardware:
According to
https://build.opensuse.org/public/build/openSUSE:Leap:15.2/standard/x86_64/keepass/_log
:

    Build 2020-06-09 on openSUSE Leap 15.2

Additional Builds and Platforms:
unknown

Additional Information:
$ keepass --version

KeePass 2.38 (Dev. 200609)

$ cat /etc/os-release | grep PRE
PRETTY_NAME="openSUSE Leap 15.2"

$ uname -rm
5.3.18-lp152.33-default x86_64

Crash not easily reproducible, but when it occurs, the application cannot be
started before a suspend/reboot. I have attached one error log, cannot seem to
attach multiple files.

summary: Keepass crash on startup


body:
--1597411691.1A6C81.14769
Date: Fri, 14 Aug 2020 13:28:11 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175289

            Bug ID: 1175289
           Summary: azure-cli initial "help" behavior oddity
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: Cloud:Tools
          Assignee: public-cloud-maintainers-at-suse.de
          Reporter: bryan.gartner-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Very minor oddity, just curious about this output:

On my up-to-date Tumbleweed system ... just installed azure-cli for the first
time.

zypper info azure-cli
Loading repository data...
Reading installed packages...

Information for package azure-cli:
----------------------------------
Repository     : Cloud:Tools
Name           : azure-cli
Version        : 2.9.1-46.1
Arch           : noarch
Vendor         : obs://build.opensuse.org/Cloud
Installed Size : 13.4 MiB
Installed      : Yes
Status         : up-to-date
Source package : azure-cli-2.9.1-46.1.src
Summary        : Microsoft Azure CLI 2.0
Description    :
    Microsoft Azure CLI 2.0 Command Line Utilities

Then noticed the following (inital) output from "az help"

Error loading command module 'aro': No module named
'azure.mgmt.redhatopenshift'

... normal help output, then

For more specific examples, use: az find "az "

You have 2 updates available. Consider updating your CLI installation with 'pip
install --upgrade azure-cli' or 'curl -L https://aka.ms/InstallAzureCli | bash'
if you used our script for installation. Detailed instructions can be found at
https://aka.ms/doc/UpdateAzureCliLinux

Please let us know how we are doing: https://aka.ms/azureclihats
and let us know if you're interested in trying out our newest features:
https://aka.ms/CLIUXstudy

Yet, re-doing that "help" command again, did not show the "You have 2 updates
.." paragraph content. Likewise, zypper rm azure-cli ; zypper in azure-cli ; az
help did not show the "update" content either.

So
- did the client update itself (or it's dependencies)
- was the update output in some way errant in some way (and maybe just
correlated to this package version ... first time I've tried this on TW)
- does the packaged version need to be updated

pkgs: azure-cli azure-cli-core


--1597422433.f28F4630.28026
Date: Fri, 14 Aug 2020 16:27:13 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175296

            Bug ID: 1175296
           Summary: network regression with a Realtek RTL8111E network chip
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Kernel
          Assignee: kernel-bugs-at-opensuse.org
          Reporter: ralf.koelmel-at-kit.edu
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840655
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840655&action=edit
lscpi of the realtek ethernet controller

a watchdog stops the network function (a bridge with one ethernet interface is
configured) on a Gigabyte Z68XP-UD3 motherboard with a Realtek RTL8111E network
chip (driver r8169). This is reproducible after a little network usage after
boot (e.g. working on a ssh session or doing some ansible commands over ssh)
and until the watchdog is stopping the network, the ssh session is reacting
very slow on the input. Then the bridge, the interface and the routes are still
present and up, but the network is not working.
There are no significant signs in the system log and on the higher network
level before the problem is occuring.
I have 2 such identical systems, which are showing the problem and were running
stable on Leap 15.1. I have only tried the kernel 5.3.18-lp152.33-default.
The Leap 15.2 was installed from a image, which is running stable on other
systems (with other network cards and motherboards).


body:
--1597492840.ACB30.10027
Date: Sat, 15 Aug 2020 12:00:40 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175303

            Bug ID: 1175303
           Summary: python3-afdko is missing dependency
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: cornelis-at-solcon.nl
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

The command "makeotf -h" gives the following error message:

Traceback (most recent call last):
  File "/usr/bin/makeotf", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3252,
in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3235,
in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3264,
in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583,
in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900,
in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786,
in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'brotli>=1.0.1' distribution was not
found and is required by fontTools

Installing python3-Brotli solves this error. This package (or another one, I
don't know if this is the right one) should be required.

This is on an up-to-date TW system.

summary: python3-afdko is missing dependency


--1597589144.CBfD83F30.31214
Date: Sun, 16 Aug 2020 14:45:44 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175314

            Bug ID: 1175314
           Summary: cacti: HTTP server does not start because of error in /etc/apache2/conf.d/cacti.conf
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: x86-64
                OS: openSUSE Leap 15.2
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: erwinl-at-dds.nl
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

I installed cacti version 1.2.14 (release lp152.127.1) from the Server -
Monitoring repository, but now the apache HTTP server refuses to start and
issues the following error message:

httpd-prefork: Syntax error on line 210 of /etc/apache2/httpd.conf: Syntax
error on line 119 of /etc/apache2/default-server.conf: Syntax error on line 15
of /etc/apache2/conf.d/cacti.conf: Expected </DirectoryMatch> but saw
</Directory>


--1597589184.D3Ed0.32029
Date: Sun, 16 Aug 2020 14:46:24 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175315

            Bug ID: 1175315
           Summary: GRUB2 update removes Windows 10 from menu on a dual-boot system
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Bootloader
          Assignee: screening-team-bugs-at-suse.de
          Reporter: alexander.shchadilov-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Today a GRUB2 update made Windows 10 disappear from boot menu, I was able to
fix it with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

I see that "Probe Foreign OS" option is active in "Yast"/"Boot
Loader"/"Bootloader Options". I think it was active before an update because I
did not remove it willingly. This is a new 15.2 installation that was made a
few days ago; Windows was already in place before that.

Zypper log in /var/log/zypp/history ends with:

2020-08-16 16:14:14|patch
|openSUSE-2020-913|1|noarch|repo-update|important|security|not-needed|applied|
2020-08-16 16:14:14|patch
|openSUSE-2020-1108|1|noarch|repo-update|important|security|not-needed|applied|
2020-08-16 16:14:14|patch
|openSUSE-2020-1158|1|noarch|repo-update|low|recommended|not-needed|applied|
2020-08-16 16:19:16|command|root@dhcppc6|'/usr/lib/packagekitd'|
2020-08-16
16:19:17|install|grub2|2.04-lp152.7.6.1|x86_64||repo-update|ceab3d243b2e8e6d1ce1cdf69cc1f5410c712af2121f999465194abb1b8cc8b8|
2020-08-16
16:19:18|install|grub2-i386-pc|2.04-lp152.7.6.1|noarch||repo-update|f6cb9bf5a13b6e4b227802a6f8f7c4fd593b9f230213cc18f2f07467dbb52aff|
2020-08-16
16:19:18|install|grub2-x86_64-efi|2.04-lp152.7.6.1|noarch||repo-update|b983725f1d10d8bed206144fa96cd51c8497e47982bc48000c33475e01365763|
2020-08-16
16:19:18|install|grub2-systemd-sleep-plugin|2.04-lp152.7.6.1|noarch||repo-update|02522fb63f6068297f194341deea5dcc61606b8b3c9bf8728929cf4e0cd78fa9|
2020-08-16
16:19:18|install|grub2-snapper-plugin|2.04-lp152.7.6.1|noarch||repo-update|eb74eb5f789605da38423500db4c32c2f82602cb10647bfefce548eeda7a2f05|
2020-08-16 16:19:21|patch
|openSUSE-2020-1221|1|noarch|repo-update|important|recommended|needed|applied|


body:
--1597610106.8d06E7ce0.8569
Date: Sun, 16 Aug 2020 20:35:06 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175320

            Bug ID: 1175320
           Summary: QXL and USB Redirect stopped working
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Virtualization:Other
          Assignee: virt-bugs-at-suse.de
          Reporter: piotr-at-orzechowski.tech
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

`virt-manager` reports `libvirt.libvirtError: unsupported configuration: domain
configuration does not support 'video model' value 'qxl'` and
`libvirt.libvirtError: unsupported configuration: USB redirection is not
supported by this version of QEMU` when I try to run my VMs.

This definitely happend after updating my Tumbleweed to version `20200814` from
previous one. I have installed `qemu-hw-display-qxl` and
`qemu-hw-usb-redirect`, but the problem still persists.

summary: QXL and USB Redirect stopped working


--1597655234.3E8a0e0.23530
Date: Mon, 17 Aug 2020 09:07:14 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175339

            Bug ID: 1175339
           Summary: VUL-1: CVE-2020-24342: lua,lua51,lua53: a stack redzone cross in luaO_pushvfstring because a protection mechanism wrongly calls luaD_callnoyield twice in a row
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.3
          Hardware: Other
               URL: https://smash.suse.de/issue/265279/
                OS: Other
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: Security
          Assignee: mcepl-at-suse.com
          Reporter: rfrohl-at-suse.com
        QA Contact: security-team-at-suse.de
          Found By: Security Response Team
           Blocker: ---

CVE-2020-24342

Lua through 5.4.0 allows a stack redzone cross in luaO_pushvfstring because a
protection mechanism wrongly calls luaD_callnoyield twice in a row.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-24342
http://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-24342.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24342
https://github.com/lua/lua/commit/34affe7a63fc5d842580a9f23616d057e17dfe27
http://lua-users.org/lists/lua-l/2020-07/msg00052.html


--1597655267.47A7DE00.23575
Date: Mon, 17 Aug 2020 09:07:47 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175340

            Bug ID: 1175340
           Summary: update-ca-certificates: relative vs. absolute symlinks
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: kukuk-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

build scripts make a relative symlink out of /etc/ssl/certs, while
update-ca-certificates expects an absolute symlink. So you always get:

Output of ca-certificates-mozilla.rpm %posttrans script:
Warning: /etc/ssl/certs needs to be a link to /var/lib/ca-certificates/pem,
fixing


--1597674515.e3B8e1BA0.26503
Date: Mon, 17 Aug 2020 14:28:35 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175367

            Bug ID: 1175367
           Summary: Memory leak in firmware loader at freeing pages
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Kernel
          Assignee: kernel-bugs-at-opensuse.org
          Reporter: tiwai-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

A bug was reported about the memory leak in the kernel firmware loader when the
buffer is managed with SG-pages.

https://lore.kernel.org/lkml/1597258819-14080-1-git-send-email-prsood-at-codeaurora.org/

Since we use the compressed firmware files and those require the SG-pages, TW
kernels (and possibly SLE/Leap 15.2 with the latest kernel-firmware-*
subpackages) are affected.


body:
--1597681600.1F2cDc70.4587
Date: Mon, 17 Aug 2020 16:26:40 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175372

            Bug ID: 1175372
           Summary: Emacs.FontBackend should not be set
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Leap 15.1
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: X11 Applications
          Assignee: screening-team-bugs-at-suse.de
          Reporter: pmlists-at-free.fr
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Further information is here:
https://lists.gnu.org/archive/html/help-gnu-emacs/2020-08/msg00073.html

I use this package:
https://download.opensuse.org/repositories/editors/openSUSE_Leap_15.1/x86_64/emacs-x11-27.1-lp151.334.1.x86_64.rpm

Kind regards, Peter

summary: Emacs.FontBackend should not be set


--1597693574.3f8bdd1.15375
Date: Mon, 17 Aug 2020 19:46:14 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175379

            Bug ID: 1175379
           Summary: microos-tools as of request 826035 renders MicroOs instances with /tmp not tmpfs unusable
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: All
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: MicroOS
          Assignee: kubic-bugs-at-opensuse.org
          Reporter: chris-at-intrbiz.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

microos-tools recently added a systemd drop-in
(/usr/lib/systemd/system/tmp.mount.d/selinux.conf) which will override the
Options configuration for the tmp.mount unit.

For MicroOs instances which have /tmp as Btrfs subvolume, this drop-in
overrides the subvol= flag.  This then effectively mounts /tmp as a read only
copy of /.

Once /tmp is readonly Wicked will fail to start network interfaces:

wickedd[1121]: __ni_objectmodel_write_message: unable to create tempfile for
script arguments

This then renders the instance unusable over the network, with the only
recourse being connecting to the VM console and booting into the previous
snapshot.

My instances had been installed back in March from the MicroOs ISO.  The YaST
install logs indicate that the installer back then setup /tmp as a Btrfs
subvolume.

Work Around:
Boot to the previous snapshot, remove /tmp from /etc/fstab, run
transactional-update and reboot.


--1597770884.EECB3230.6170
Date: Tue, 18 Aug 2020 17:14:44 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175463

            Bug ID: 1175463
           Summary: virt-manager creating pool error: unable to control COW flag
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Virtualization:Tools
          Assignee: virt-bugs-at-suse.de
          Reporter: wayne.patton-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

When trying to create a new storage pool using a directory, type set to dir,
target path being /home/wayne/test or any other target dir results in the
following error:

Error creating pool: Could not build storage pool: unable to control COW flag
on '/home/wayne/test', not btrfs: Function not implemented

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createpool.py", line 378, in
_async_pool_create
    poolobj = pool.install(create=True, meter=meter, build=build)

I am able to create and start a storage pool just fine using the following
virsh command:

virsh pool-create-as --name test-dir --type dir --target /home/wayne/test


--1597795372.DBea7C4f0.30201
Date: Wed, 19 Aug 2020 00:02:52 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175465

            Bug ID: 1175465
           Summary: libvirtd can't start VM, can't get devmapper targets for its disc
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Virtualization:Tools
          Assignee: virt-bugs-at-suse.de
          Reporter: jimc-at-jfcarter.net
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840786
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840786&action=edit
virt-manager --debug output, shows host and guest configuration etc.

Versions:
libvirt-daemon-6.6.0-1.1.x86_64
libvirt-daemon-driver-qemu-6.6.0-1.1.x86_64
qemu-5.1.0-1.1.x86_64
qemu-kvm-5.1.0-1.1.x86_64
qemu-x86-5.1.0-1.1.x86_64
All installed today, 2020-08-18, provoking the problem.

Error message:
... libvirtd[1724]: internal error: Failed to autostart VM 'claude':
internal error: Process exited prior to exec: libvirt:
QEMU Driver error : Unable to get devmapper targets for
/s1/kvm/claude/claude-disc1.raw: Success
(Multiple attempts to start VMs on multiple hosts gave a similar
message.)

For libvirt bugs, exec virt-manager --debug and post the output.
The GUI opens and a bunch of stuff, including the host and guest
configuration, come out on stdout/stderr.  Just for laughs I selected
Claude and hit the "power on" triangle.  On stderr and also a pop-up,
it showed the above message and a traceback, probably useless
because the problem isn't in virt-manager.  I've attached the output.

Here's a related bug report:
https://www.spinics.net/linux/fedora/libvir/msg206635.html
OP Andrea Bolognani (Red Hat), 2020-08-04
Referring to a patch involving CVE-2020-14339 made by
Michal Privoznik, 2020-07-27
Jimc's summary: On a system with only plain partitions, no LVM
(like mine), /proc/devices lacks an entry for dev-mapper which
virdevmapper needs.  Without AppArmor the error message above is
seen; with AppArmor the message is about deleting a busy directory.

Workarounds mentioned: Set namespaces=[] in qemu.conf, but he implies
that this may have baleful security issues maybe relating to the
leaked file descriptor mentioned in CVE-2020-14339.  To populate
/proc/devices you could run (as root) dmsetup info (says no devices
found, which we already knew) and the startup will work.  (jimc
confirms this; it's block device 254 at the end.)

See the bug report for Andrea's offer of help in getting this fixed.


--1597826225.AE41B00.23904
Date: Wed, 19 Aug 2020 08:37:05 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175475

            Bug ID: 1175475
           Summary: VUL-0: CVE-2020-14352: librepo: missing path validation in repomd.xml may lead to directory traversal
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.1
          Hardware: Other
               URL: https://smash.suse.de/issue/265258/
                OS: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Security
          Assignee: christian.voegl-at-suse.com
          Reporter: rfrohl-at-suse.com
        QA Contact: security-team-at-suse.de
                CC: pth-at-suse.com
          Found By: Security Response Team
           Blocker: ---

rh#1866498

Librepo fails to sanitize paths in the 'repomd.xml' configuration file.
Malformed or malicious repository metadata could allow a remote attacker to
copy files outside of the destination directory via path traversal. Considering
that DNF runs as root, this flaw could potentially result in system compromise
via arbitrary file overwriting of critical system files.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1866498
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14352
https://access.redhat.com/security/cve/CVE-2020-14352


--1597840712.6e1C80.20654
Date: Wed, 19 Aug 2020 12:38:32 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175487

            Bug ID: 1175487
           Summary: Emacs 27.1: package downloads & compilation yields "end of file during parsing" error
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: X11 Applications
          Assignee: screening-team-bugs-at-suse.de
          Reporter: philipp.reichmuth-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

DESCRIPTION
Emacs 27.1 has a bug related to HTTP(S) downloads and/or package compilation
that causes downloads and compilation of ELPA packages using Quelpa
(https://github.com/quelpa/quelpa) to fail. Compilation of downloaded files
gives an error: "error in process sentinel: End of file during parsing".

Being a bit of a novice, it is hard for me to pinpoint the error, but it's
reproducible when installing the Spacemacs Emacs distribution
(https://github.com/syl20bnr/spacemacs/). This is because Spacemacs, upon
installation, downloads and installs lots of packages. This will yield dozens
of "end of file during parsing" messages.

This error is usually indicative of missed parentheses, but it seems to be
related to the download operation, because (a) it is not reproducible (it
concerns different files every time), and (b) the files in question are
downloaded from their master repositories and are unlikely to contain missing
parentheses.

HOW TO REPRODUCE

Installation of Spacemacs according to the recommended procedure:
- Delete ./emacs.d
- Delete .spacemacs
- Download spacemacs using `git clone --branch develop
https://github.com/syl20bnr/spacemacs ~/.emacs.d`
- Start Emacs 27.1.

EXPECTED BEHAVIOUR

Clean installation of Spacemacs.

OBSERVED BEHAVIOUR

Spacemacs begins downloading and compiling packages from ELPA. A significant,
but not reproducible number of these fail to compile and give the following
error message:

error in process sentinel: async-handle-result: End of file during parsing
error in process sentinel: End of file during parsing

This happens regardless of whether I use the "develop" (0.300) or the stable
"master" (0.200) branch of Spacemacs, and regardless of whether I use HTTPS or
HTTP (with `emacs --insecure`).

Different packages are concerned every time.

Two examples of messages from this installation are here:
https://pastebin.com/AzPJ0FZr and https://pastebin.com/VQzD6zgY


--1597854833.317e3F0.9814
Date: Wed, 19 Aug 2020 16:33:53 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175502

            Bug ID: 1175502
           Summary: onefetch ppc64le build "error: the listed checksum ... has changed"
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: normand-at-linux.vnet.ibm.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Created attachment 840822
  --> http://bugzilla.opensuse.org/attachment.cgi?id=840822&action=edit
onefetch_standard_ppc64le_202008191619.log

onefetch ppc64le build "error: the listed checksum ... has changed"
as reported in
https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/onefetch

If I compare the log extracts for ppc64le(1) that failed and ppc64(2) that
passed; there is a bunch of lines in failing case that modified the input
config.guess
This is the reason of next reported checksum failure.

I do not identified from what macro are comming those lines.

(1) extract of attached log:
=== ppc64le:
[   65s] + /usr/bin/mkdir
/home/abuild/rpmbuild/BUILDROOT/onefetch-2.3.0-1.1.ppc64le
[   65s] + cd onefetch-2.3.0
[   65s] + ref=/usr/lib/rpm
[   65s] ++ uname -m
[   65s] + testarch=ppc64le
[   65s] + for s in guess sub
[   65s] ++ find -maxdepth 8 -name config.guess
[   65s] + for c in $(find -maxdepth 8 -name "config.$s")
[   65s] + grep -q config-patches@
./vendor/backtrace-sys/src/libbacktrace/config.guess
[   65s] + grep -q 'ppc64le[-:]'
./vendor/backtrace-sys/src/libbacktrace/config.guess
[   65s] + install -m 755 /usr/lib/rpm/config.guess
./vendor/backtrace-sys/src/libbacktrace/config.guess
[   65s] + for s in guess sub
[   65s] ++ find -maxdepth 8 -name config.sub
[   65s] + for c in $(find -maxdepth 8 -name "config.$s")
[   65s] + grep -q config-patches@
./vendor/backtrace-sys/src/libbacktrace/config.sub
[   65s] + grep -q 'ppc64le[-:]'
./vendor/backtrace-sys/src/libbacktrace/config.sub
[   65s] + cargo build --release -j4
[   65s] error: the listed checksum of
`/home/abuild/rpmbuild/BUILD/onefetch-2.3.0/vendor/backtrace-sys/src/libbacktrace/config.guess`
has changed:
[   65s] expected:
9be3de218833c076786b919dc34aab691611f4cd73316e7705f2673e2c41921b
[   65s] actual:
beb948be88d1f06d21c53d1b739a89216dc0bf6a1861403a0c221936d0a5498e
===

Comparing with ppc64 (BE) log that passed
(2):
=== ppc64:
[   32s] + /usr/bin/mkdir
/home/abuild/rpmbuild/BUILDROOT/onefetch-2.3.0-1.1.ppc64
[   32s] + cd onefetch-2.3.0
[   32s] + cargo build --release -j8
===


--1597864372.E226e0.18969
Date: Wed, 19 Aug 2020 19:12:52 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175505

            Bug ID: 1175505
           Summary: VUL-0: chromium: update to 84.0.4147.135
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.1
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: tchvatal-at-suse.com
          Reporter: wolfgang.frisch-at-suse.com
        QA Contact: security-team-at-suse.de
                CC: Andreas.Stieger-at-gmx.de
          Found By: ---
           Blocker: ---

The Chromium stable channel has been updated to 84.0.4147.135 for Windows, Mac,
and Linux.

Security issue fixed:

- CVE-2020-6556: Heap buffer overflow in SwiftShader.


--1597937566.1dB85.27456
Date: Thu, 20 Aug 2020 15:32:46 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175559

            Bug ID: 1175559
           Summary: mutter shouldn't rely on libGLESv2.so at runtime
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: GNOME
          Assignee: gnome-bugs-at-suse.de
          Reporter: fcrozat-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

On hardware using libGLESv2 (old netbook using Pineview M), mutter incorrectly
tries to load libGLESv2.so instead of libGLESv2.so.2.

This is already fixed upstream
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1298

This is a backport for openSUSE Leap 15.2 / SLE15 SP2 and openSUSE Tumbleweed


body:
--1597964951.6Bf7184D0.20200
Date: Thu, 20 Aug 2020 23:09:11 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175574

            Bug ID: 1175574
           Summary: libvirt-6.0.0-lp152.8.1 fails to build
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Development
          Assignee: screening-team-bugs-at-suse.de
          Reporter: rbsmith-at-sandia.gov
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

The following build process fails on an X86_64 box running OS Leap 15.2:
# zypper si libvirt
# cd /usr/src/packages/SPECS
# rpmbuild -ba libvirt.spec

The failure occurs in the following Makefile target:
/usr/src/packages/BUILD/libvirt-6.0.0/x86_64-suse-linux/src # make check-local

This patch enables the build to complete successfully:

diff -Naur libvirt-6.0.0.orig/src/libxl/test_libvirtd_libxl.aug.in
libvirt-6.0.0/src/libxl/test_libvirtd_libxl.aug.in
-

summary: libvirt-6.0.0-lp152.8.1 fails to build


body:
Build Identifier:

Hello everyone!

I just installed Leap 15.2, with everything working ... And after the first
update I had no keyboard.

The usb keyboard works.

I had to determine by yast, the boot from the previous kernel, but I would like
to try to fix this, and use the most current kernel.

My machine is an Acer E5-511 laptop - 4gib ram - Intel Celeron N2940 - Bay
Trail.

Reproducible: Always

I don't know if what I did is right, but it worked ...

I went to /etc/x11/xorg.conf.d

I deleted all files except touchpad ...

I rebooted with the current kernel, and it worked ...

summary: I installed Leap 15.2 and after upgrading I had no keyboard


body:
--1598040134.DbBd2780.5142
Date: Fri, 21 Aug 2020 20:02:14 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175626

            Bug ID: 1175626
           Summary: Recent update run on August 21, 2020 kills bootloader
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: x86-64
                OS: openSUSE Leap 15.2
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: Bootloader
          Assignee: screening-team-bugs-at-suse.de
          Reporter: zhonb-at-yahoo.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Most recent update killed EFI bootloader, results in the following error
immediately upon powering on system:

Failed to open \EFI\BOOT\MokManager.efi - Not Found
Failed to load image \EFI\BOOT\MokManager.efi: Not Found
Failed to start MokManager: Not Found
Something has gone seriously wrong: import_mok_state() failed : Not found

See also
https://forums.opensuse.org/showthread.php/543433-update-killed-bootloader

and https://lists.opensuse.org/opensuse-factory/2020-08/msg00169.html

pkgs: shim shim-leap


body:
--1598101344.d26Bb0.28261
Date: Sat, 22 Aug 2020 13:02:24 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175633

            Bug ID: 1175633
           Summary: AUDIT-0: kdenetwork-filesharing (polkit-unauthorized-privilege, polkit-untracked-privilege, suse-dbus-unauthorized-service)
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: security-team-at-suse.de
          Reporter: lbeltrame-at-kde.org
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Hello,

the next version of kdenetwork-filesharing, which will be released in a few
months, adds a new KAuth helper to perform privileged operations (creation of
Samba users).

Therefore, I'd like to request an audit in advance. A package is already
available in KDE:Unstable:Applications. The files pointed out by rpmlint are:

- /usr/share/dbus-1/system-services/org.kde.filesharing.samba.service
-  /usr/share/dbus-1/system.d/org.kde.filesharing.samba.conf

And the privileges required are:

- org.kde.filesharing.samba.createuser (??:auth_admin:auth_admin)
- org.kde.filesharing.samba.isuserknown (??:yes:yes)

There are two informational messages related to this pointed out by rpmlint:

kdenetwork-filesharing.x86_64: I: polkit-cant-acquire-privilege
org.kde.filesharing.samba.createuser (??:auth_admin:auth_admin)

kdenetwork-filesharing.x86_64: I: polkit-cant-acquire-privilege
org.kde.filesharing.samba.isuserknown (??:yes:yes)

Usability can be improved by allowing users to acquire privileges         via
authentication. Use e.g. 'auth_admin' instead of 'no' and make         sure to
define 'allow_any'. This is an issue only if the privilege         is not
listed in /etc/polkit-default-privs.*

The code which is used from the helper is:

-
https://invent.kde.org/network/kdenetwork-filesharing/-/blob/master/samba/filepropertiesplugin/authhelper.cpp
-
https://invent.kde.org/network/kdenetwork-filesharing/-/blob/master/samba/filepropertiesplugin/authhelper.h
-
https://invent.kde.org/network/kdenetwork-filesharing/-/blob/master/samba/filepropertiesplugin/org.kde.filesharing.samba.actions

pkgs: polkit-default-privs rpmlint


--1598356288.3A4FD30.5818
Date: Tue, 25 Aug 2020 11:51:27 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175720

            Bug ID: 1175720
           Summary: New packager physlock requires suid bit root otherwise it does not work
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: All
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: security-team-at-suse.de
          Reporter: werner-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

This is what I see

[    7s] physlock.x86_64: W: permissions-file-setuid-bit /usr/bin/physlock is
packaged with setuid/setgid bits (04755)
[    7s] If the package is     intended for inclusion in any SUSE product
please open a
[    7s] bug report to request     review of the package by the security team.
Please
[    7s] refer to
[    7s]
https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for
[    7s] more     information.

to be able to submit this package to Factory I'd like to ask for a review by
the security team.

For more information about physlock, see https://github.com/muennich/physlock
as well
as the manual page of the current package physlock below security repostitory.


--1598424946.aEB50.341
Date: Wed, 26 Aug 2020 06:55:46 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175760

            Bug ID: 1175760
           Summary: VUL-0: CVE-2020-24614: fossil: remote authenticated users to execute arbitrary code
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.1
          Hardware: Other
               URL: https://smash.suse.de/issue/265912/
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: max-at-suse.com
          Reporter: atoptsoglou-at-suse.com
        QA Contact: security-team-at-suse.de
          Found By: Security Response Team
           Blocker: ---

CVE-2020-24614

"Researcher Max Justicz discovered a potential RCE and other
vulnerabilities in the Fossil distributed version control system.
(https://fossil-scm.org/)  Patches to address these issues are now
available for download.  Package maintainers who bundle Fossil are
encouraged to update their packages without unnecessary delay.

All vulnerabilities require a pre-existing trust relationship between
the victim and the attacker.  In other words, the attacker must be
either a site administrator, or someone with check-in privileges on
the project.  There are no known vulnerabilities to servers from web
users entering tickets or forum messages or wiki or doing other
on-line operations.  The attacks require the ability to push, at
least, and the most serious RCE problem requires the ability to
configure a server in malicious ways.  If you are unable to upgrade to
one of the patched versions of Fossil, then you are encouraged at
least to know well the people from whom you clone or pull.

Precompiled binaries and source tarballs for the patched versions of
Fossil are available on the Fossil download page
(http://fossil-scm.org/fossil/uv/download.html).  However, the dozens
of check-ins that went into generating these patches, and the tickets
that describe the specifics of the vulnerabilities, will be embargoed
for a few days.

See the thread on the Fossil Forum
(https://fossil-scm.org/forum/info/a05ae3ce7760daf6) for follow up
information or to communicate directly with the Fossil developers."

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1870789
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-24614
http://seclists.org/oss-sec/2020/q3/134
https://www.openwall.com/lists/oss-security/2020/08/20/1
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24614
https://fossil-scm.org/forum/info/a05ae3ce7760daf6


--1598438102.1F3D0560.13735
Date: Wed, 26 Aug 2020 10:35:02 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175779

            Bug ID: 1175779
           Summary: Symlink /etc/systemd/system/tmp.mount cripples system
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: suseacc-at-johnzone.org
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

After the dist-upgrade to 20200823, my system did not log in to the graphical
environment (plasma). After reboot, it was worse.
The root fs was mounted read only and some services did not start because of
this.
After some poking, I decided to roll back. The system came up and I
dist-upgraded again. As Robert Munteanu hinted, there was a symlink from
/etc/systemd/system/tmp.mount to /usr/share/systemd/tmp.mount which I deleted.
The system rebooted normally this time.
I checked the snapshots and did not find this symlink in the rw snapshot after
the rollback, but in all previous until the one after the first upgrade to
20200823.
I did comment out the /tmp entry in /etc/fstab as described in the wiki to
migrate /tmp to tmpfs (https://en.opensuse.org/openSUSE:Tmp_on_tmpfs) and i
wrote a service to create a symlink from /tmp/dumps to /dev/null to prevent
steam from dumping gigabytes of logfiles there, effectively filling /tmp.


--1598446909.f6b0f6D0.25919
Date: Wed, 26 Aug 2020 13:01:49 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175789

            Bug ID: 1175789
           Summary: Missing & wrong location for header files in tensorflow*-devel package
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: marco.varlese-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

First, the location used to install C header files for Tensorflow is wrong. It
currently installs the headers to /usr/lib/python3.8/site-packages/...
whilst they should belong to the standard /usr/include location.

That said, there are missing header files which prevent a C program to use the
tensorflow library.

rpm -ql tensorflow2-devel |grep \.h |grep "c_api"

returns nothing.


--1598512520.Af42f70.2032
Date: Thu, 27 Aug 2020 07:15:20 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175813

            Bug ID: 1175813
           Summary: [libexecdir[[20200825] man wrapper has hardcoded /usr/lib/man-db
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
               URL: https://openqa.opensuse.org/tests/1373823/modules/podm
                    an/steps/106
                OS: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: dimstar-at-opensuse.org
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

## Observation

openQA test in scenario
opensuse-Tumbleweed-DVD-x86_64-extra_tests_textmode_containers@64bit fails in
[podman](https://openqa.opensuse.org/tests/1373823/modules/podman/steps/106)

With Snapshot 0825, the definition of %{_libexecdir} changed to be
/usr/libexec, as was discussed and announced in July 2019.

This change is now part of Factory and in the complete openQA test suite (more
exhausting than what we test in Staging) it turned out that 'man' can't be
started anymore.

The openQA test does:
man -P cat podman build

which in turn results in:
  execve: No such file or directory

Inspecting the built man package, we see this file system layout:

/usr/libexec
/usr/libexec/man-db
/usr/libexec/man-db/do_mandb
/usr/libexec/man-db/globbing
/usr/libexec/man-db/man

but wrapper.c (in the source package) contains:

  { "man",      "/usr/lib/man-db/man",          "man"   },
  { "mandb",    "/usr/lib/man-db/mandb",        "man"   },

This issue is currently blocking Factory from passing openQA - hence:
major/blocker

## Test suite description
Maintainer: dheidler. Extra tests about CLI software in container module

## Reproducible

Fails since (at least) Build
[20200825](https://openqa.opensuse.org/tests/1373563)

## Expected result

Last good: [20200824](https://openqa.opensuse.org/tests/1371875) (or more
recent)

## Further details

Always latest result in this scenario:
[latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=extra_tests_textmode_containers&version=Tumbleweed)


body:
--1598529840.831c580.29208
Date: Thu, 27 Aug 2020 12:04:00 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175825

            Bug ID: 1175825
           Summary: VUL-0: brotli: decoder: integer overflow when input chunk is larger than 2GiB
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: jengelh-at-inai.de
          Reporter: Andreas.Stieger-at-gmx.de
        QA Contact: qa-bugs-at-suse.de
                CC: security-team-at-suse.de
          Found By: ---
           Blocker: ---

From https://github.com/google/brotli/releases/tag/v1.0.8

> SECURITY: decoder: fix integer overflow when input chunk is larger than 2GiB

References:
https://github.com/google/brotli/pull/826/commits/4c08c515f3c45abde832ce7421794ae6fc14cd21
https://build.opensuse.org/request/show/829811

pkgs: brotli python-Brotli


--1598538549.FF6c1.9246
Date: Thu, 27 Aug 2020 14:29:09 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175841

            Bug ID: 1175841
           Summary: MicroOS Desktop installer says it needs 'lvm2' and 'nvme-cli' packages. Not present by default.
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: MicroOS
          Assignee: kubic-bugs-at-opensuse.org
          Reporter: mike-at-flingtoad.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

If you try to install MicroOS Desktop (KDE Plasma) (ALPHA), then change the
"Partitioning" settings using "Guided Setup" to enable LVM, the installer will
display the error:

These packages need to be selected to install: lvm2
Please manually select the needed items to install

This error is displayed (in red) during the "Installation Settings" screen
under the "Software" heading.

As far as I can tell, lvm2 is not included in the openSUSE-MicroOS-20200804-0
repo on the install DVD.

The SAME thing occurs on a different system, but that system also reports that
it needs 'nvme-cli', even if the installation is to the non-nvme disk.

As suggested by 'fvogt' in IRC, I added
'addon=http://download.opensuse.org/tumbleweed/repo/oss' to the kernel boot
parameters for the installer. This allows the installer to find the 'lvm2'
package (and the 'nvme-cli' package, if necessary), but it requires manually
resolving a conflict between:

product:openSUSE-20200824-0.x86_64 conflicts with distribution-release provided
by product:MicroOS-20200824-0.x86_64
product:openSUSE-20200824-0.x86_64 requires product(openSUSE) = 20200824.0, but
this requirement cannot be provided.

For both conflicts, I chose "do no install product:openSUSE-20200824-0.x86_64"
and that seems to work. The installation is running now.

While this seems to solve the initial problem, I also see that bug #1137460
said that tumbleweed is not or should not be an addon for kubic. If that is
still the case, the proper resolution seems to be adding 'lvm2' and 'nvme-cli'
to the install image for MicroOS.


--1598596249.47bc1D1.23243
Date: Fri, 28 Aug 2020 06:30:49 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175867

            Bug ID: 1175867
           Summary: Security Review requested of using  Xorg.wrap to start X server by default
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: security-team-at-suse.de
          Reporter: xiaoguang.wang-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Some time the X server need root rights to function properly, like the issue we
meet in https://bugzilla.suse.com/show_bug.cgi?id=1075805.

By default Xorg.wrap will auto detect if root rights are necessary, and if not
it will drop its elevated rights before starting the real X server.

On Fedora and Ubuntu distro they use Xorg.wrap to start X server.

We hope security team can review the Xorg.wrap and we want to know whether
openSUSE distro can use Xorg.wrap to start X server.


body:
--1598604824.2EdD62.2929
Date: Fri, 28 Aug 2020 08:53:44 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175882

            Bug ID: 1175882
           Summary: pesign-obs-integration doesn't respect _binary_payload from the original .spec
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: glin-at-suse.com
          Reporter: jslaby-at-suse.com
        QA Contact: qa-bugs-at-suse.de
                CC: manfred.h-at-gmx.net, mkubecek-at-suse.com, mliska-at-suse.cz
          Found By: ---
           Blocker: ---

Kernel specs define _binary_payload to w9.bzdio:
# Force bzip2 instead of lzma compression to
# 1) allow install on older dist versions, and
# 2) decrease build times (bug 962356)
%define _binary_payload w9.bzdio

So that the kernel can be used on older distros:
$ rpm -qp before-repack.rpm --qf '%{PAYLOADCOMPRESSOR}\n'
bzip2

But after repackage:
$ rpm -qp after-repack.rpm --qf '%{PAYLOADCOMPRESSOR}\n'
zstd

That is problematic after the factory switch to zstd (SR#819007). The kernels
from the Kernel: project cannot be installed on older distros (but they
should):
  error: Failed dependendies:
    Nothing provides rpmlib(PayloadIsZstd) <= 5.4.18-1

pkgs: kernel-source pesign-obs-integration


--1598634417.3d5Ba85.16004
Date: Fri, 28 Aug 2020 17:06:57 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175899

            Bug ID: 1175899
           Summary: xdg-document-portal does not work properly without fusermount
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: GNOME
          Assignee: gnome-bugs-at-suse.de
          Reporter: dfaggioli-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

xdg-desktop-portal does not have an explicit runtime dependency from the
fusermount binary. But in case the program is really not present in the system,
things don't work.

In fact, I can see a file open/save/etc dialog being open, and I can select a
file or a directory, as a location, but then nothing works. A typical example
is trying to save an attachment of an email, from the Evolution flatpak. In
fact, one is able to choose where to save the file, but then when checking the
filesystem, it is not there.

Launching the flatpak from a terminal showed an error related to the absence of
the fusermount binary in the system (which unfortunately I can't paste as I
didn't stashed it anywhere, and now I've got fusermount installed).


body:
--1598673925.AC7a24C0.22035
Date: Sat, 29 Aug 2020 04:05:25 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175910

            Bug ID: 1175910
           Summary: [trackerbug] lxd 4.5 update
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Containers
          Assignee: containers-bugowner-at-suse.de
          Reporter: asarai-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

- Update to LXD 4.5. The full upstream changelog is available from:
  https://discuss.linuxcontainers.org/t/lxd-4-5-has-been-released/8824

  + Initial support for OVN virtual networks
  + Initial bpf syscall interception
  * Support for native terminal device allocation
  * VGA console now working on Windows
  * Improved handling of remote storage pools
  * forkdns and forkproxy now running under AppArmor confinement
  + lxc move now let’s you select a cluster target too

summary: [trackerbug] lxd 4.5 update


--1598689524.45deC40.32400
Date: Sat, 29 Aug 2020 08:25:24 +0000
MIME-Version: 1.0
Content-Type: text/plain

https://bugzilla.suse.com/show_bug.cgi?id=1175913

            Bug ID: 1175913
           Summary: sysstat causing suspend and resume delays
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: pmonrealgonzalez-at-suse.com
          Reporter: jslaby-at-suse.com
        QA Contact: qa-bugs-at-suse.de
                CC: aj-at-suse.com, dmueller-at-suse.com
          Found By: ---
           Blocker: ---

After update to sysstat 12.4, suspend and resume take looong time.

> 2020-08-24T08:05:07.789068+02:00 anemoi2 [RPM][22146]: erase sysstat-12.3.3-1.2.x86_64: success
> 2020-08-24T08:05:07.789440+02:00 anemoi2 [RPM][22146]: install sysstat-12.4.0-1.1.x86_64: success
> 2020-08-24T22:23:43.855599+02:00 anemoi2 [9481]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-24T22:27:20.196024+02:00 anemoi2 [11735]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-25T07:18:40.097626+02:00 anemoi2 logwatch[11957]:     sysstat 12.4.0-1.1
> 2020-08-25T07:19:31.082739+02:00 anemoi2 [11963]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-25T20:06:39.824253+02:00 anemoi2 [11875]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-25T20:28:18.010184+02:00 anemoi2 [12076]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-25T20:50:23.692493+02:00 anemoi2 [15417]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-26T06:55:15.784394+02:00 anemoi2 [15640]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-27T07:39:08.955768+02:00 anemoi2 [14793]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-28T21:42:41.052114+02:00 anemoi2 [16056]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.
> 2020-08-28T21:44:51.523729+02:00 anemoi2 [16970]: /usr/lib/systemd/system-sleep/sysstat.sleep failed with exit status 73.

It looks like the lock file at
  /var/run/sysstat/sadc.LOCK
is not removed sometimes (it looks like every time), so
$ /usr/lib64/sa/sa1 --sleep
run from the above script has to time out.

If I remove the lock file, the command returns immediately, of course.


body:
--1598702789.AA8E5b20.3325
Date: Sat, 29 Aug 2020 12:06:29 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175914

            Bug ID: 1175914
           Summary: updating libvirt-daemon hangs
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Virtualization:Tools
          Assignee: virt-bugs-at-suse.de
          Reporter: michael-at-stroeder.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

During zypper dup update hangs for package  libvirt-daemon.

After killing these two processes update proceeds:

/usr/bin/systemd-inhibit --what=sleep:shutdown:idle --who=zypp --mode=block
--why=Zypp commit running. /usr/bin/cat

/usr/bin/systemctl try-restart libvirtd.service libvirtd.socket
libvirtd-ro.socket libvirtd-admin.socket libvirtd-tcp.socket

summary: updating libvirt-daemon hangs


--1598721644.F1DB0.15421
Date: Sat, 29 Aug 2020 17:20:44 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175919

            Bug ID: 1175919
           Summary: For man and associated programs update-alternatives still has symlinks pointing to /usr/lib/man-db instead of /usr/libexec/man-db after dup to TW 20200826
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: screening-team-bugs-at-suse.de
          Reporter: m4ng4n-at-gmx.de
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

This is on openSUSE Tumbleweed 20200826.�
The problem is what the Summary says.

If you call man and associate programs (e.g. whatis) from cli you get a "man
not found".

ls -l /etc/alternatives | grep "\man ->" results in
lrwxrwxrwx 1 root root 23 Jul 25 22:38 man -> /usr/lib/man-db/wrapper

Two workarounds that I tried can help until this is fixed.

1. call man with the full absolute path: /usr/libexec/man-db/man.
2. use update-alternatives from cli or Yast to change the links.


body:
--1598789537.cf703E0.22666
Date: Sun, 30 Aug 2020 12:12:17 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175925

            Bug ID: 1175925
           Summary: screen, utempter: libexec fallout
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
          Assignee: meissner-at-suse.com
          Reporter: jengelh-at-inai.de
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Using /usr/bin/screen since the libexec update to Tumbleweed, no utmp entries
are generated anymore. The permissions on the helper program are correct.
strace reveals the library has not been told the new path.

� strace -fe execve -o exec.log screen
20677 execve("/usr/lib/utempter/utempter", ["/usr/lib/utempter/utempter",
"add", ":pts/0:S.0"], 0x7ffef1c7de18 /* 78 vars */) = -1 ENOEN>

libutempter0-1.2.0-1.16.x86_64

summary: screen, utempter: libexec fallout


--1598820042.bfB5cBF0.21215
Date: Sun, 30 Aug 2020 20:40:42 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175933

            Bug ID: 1175933
           Summary: Peazip, please add soft dependencies for supported formats.
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: x86-64
                OS: openSUSE Tumbleweed
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: jodr666-at-live.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Recently i've been testing different compressing/archiving formats i am using
peazip becuase it has wider support than Ark does in KDE.

I noticed opening and compressing files using zpaq, arc, zstd, brotli doesn't
work.
With zpaq i get traps :
traps: zpaq[8229] trap invalid opcode ip:55c6b0354bf4 sp:7ffc8fdcfe90 error:0
in zpaq[55c6b0345000+4b000]

The peazip package seems to ship its own executalbes for some these (zpaq, arc)
while not for others (zstd, brotli).

These "plugins" are found in "/usr/lib64/peazip/res/" i made a directory named
as the plugin containing a symbolic link of the system's executable as a
workaround, this being the same the package does for 7z.

Common formats like bz2 and gz work OK.


--1598939335.e147dEaC1.11729
Date: Tue, 1 Sep 2020 05:48:55 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175983

            Bug ID: 1175983
           Summary: zypper dup problem: clang-devel-9.0.1-lp152.1.1.x86_64 requires clang9-devel = 9.0.1, but this requirement cannot be provided
    Classification: openSUSE
           Product: openSUSE Distribution
           Version: Leap 15.2
          Hardware: x86-64
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Upgrade Problems
          Assignee: screening-team-bugs-at-suse.de
          Reporter: Ulrich.Windl-at-rz.uni-regensburg.de
        QA Contact: jsrain-at-suse.com
          Found By: ---
           Blocker: ---

Running "zypper dup" like this:
# sudo zypper --releasever 15.2 ref
# sudo zypper --releasever 15.2 dup
Results in:
Computing distribution upgrade...
3 Problems:
Problem: clang-devel-9.0.1-lp152.1.1.x86_64 requires clang9-devel = 9.0.1, but
this requirement cannot be provided
Problem: llvm-devel-9.0.1-lp152.1.1.x86_64 requires llvm9-devel = 9.0.1, but
this requirement cannot be provided
Problem: llvm-gold-9.0.1-lp152.1.1.x86_64 requires llvm9-gold = 9.0.1, but this
requirement cannot be provided

This looks like a packaging problem to me.


body:
--1598950984.Ff550.20446
Date: Tue, 1 Sep 2020 09:03:04 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1175991

            Bug ID: 1175991
           Summary: SSH no longer uses ksshaskpass
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
          Assignee: screening-team-bugs-at-suse.de
          Reporter: linus.kardell-at-gmail.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

SSH no longer uses ksshaskpass, unless I set the SSH_ASKPASS variable. So it
asks for a password on the command line, rather than using the one stored in
kwallet.

summary: SSH no longer uses ksshaskpass


--1598970815.78C1e0.24487
Date: Tue, 1 Sep 2020 14:33:35 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1176016

            Bug ID: 1176016
           Summary: X11:Solus/budgie-desktop: system tray patches to fix icon corruption
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: 3rd party software
          Assignee: matthias-at-mailaender.name
          Reporter: sb56637-at-gmail.com
        QA Contact: screening-team-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Hi there, great work on packaging Budgie for openSUSE thus far! It's working
just as well as on Solus, which is to say that it also inherited a fairly ugly
bug that they've had for years in Solus ;-)
https://github.com/solus-project/budgie-desktop/issues/1249#issuecomment-625989059

They claim that it's recently been fixed, but the packager would have to search
through the git transactions and cherry-pick a few commits to fix it...
https://github.com/solus-project/budgie-desktop/issues/1249#issuecomment-683763373

For now I'm using this hack/workaround, which is ugly but reliable:
https://discuss.getsol.us/d/3229-system-tray-applet-glitch-in-budgie/8


--1598987840.e61231.18347
Date: Tue, 1 Sep 2020 19:17:20 +0000
MIME-Version: 1.0
Content-Type: text/plain

http://bugzilla.opensuse.org/show_bug.cgi?id=1176031

            Bug ID: 1176031
           Summary: (CVE-2020-24553) VUL-0: CVE-2020-24553: go net/http/cgi,net/http/fcgi: Cross-Site Scripting (XSS) when Content-Type is not specified
    Classification: openSUSE
           Product: openSUSE Tumbleweed
           Version: Current
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Security
          Assignee: security-team-at-suse.de
          Reporter: jkowalczyk-at-suse.com
        QA Contact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Go 1.15.1 and Go 1.14.8 address a recently reported security issue:

When a Handler does not explicitly set the Content-Type header, the
net/http/cgi and net/http/fcgi packages would default to “text/html”, which
could cause a Cross-Site Scripting vulnerability if an attacker can control any
part of the contents of a response.

The Content-Type header is now set based on the contents of the first Write
using http.DetectContentType, which is consistent with the behavior of the
net/http package.

Although this protects some applications that validate the contents of uploaded
files, not setting the Content-Type header explicitly on any
attacker-controlled file is unsafe and should be avoided.

This issue is CVE-2020-24553 and Go issue
https://github.com/golang/go/issues/40928