http://bugzilla.opensuse.org/show_bug.cgi?id=1196707
Bug ID: 1196707
Summary: lxqt-config-appearance fails to open due to missing
liblxqt-config-cursor.so
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: LXQt
Assignee: mvetter(a)suse.com
Reporter: slemke(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
slemke@notebook:~> zypper info lxqt-config
Loading repository data...
Reading installed packages...
Information for package lxqt-config:
------------------------------------
Repository : Main Repository
Name : lxqt-config
Version : 1.0.0-bp154.1.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 1.3 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : lxqt-config-1.0.0-bp154.1.1.src
Upstream URL : http://www.lxqt.org
Summary : LXQt Control Center
Description :
System Configuration and Control Center for LXQt
slemke@notebook:~>
slemke@notebook:~> lxqt-config-appearance
lxqt-config-appearance: error while loading shared libraries:
liblxqt-config-cursor.so: cannot open shared object file: No such file or
directory
slemke@notebook:~>
Some maybe useful outputs:
slemke@notebook:~> rpm -qa |grep -i lxqt |grep -c 1.0.0
25
slemke@notebook:~> rpm -qa |grep -ic lxqt
35
slemke@notebook:~> rpm -qa |grep -i lxqt |grep -v 1.0.0
patterns-lxqt-lxqt-20170319-lp154.1.2.x86_64
lxqt-theme-openSUSE-default-0.1-bp154.1.2.noarch
lxqt-globalkeys-1.0.1-bp154.1.1.x86_64
lxqt-theme-openSUSE-leaper-0.1-bp154.1.2.noarch
lxqt-globalkeys-lang-1.0.1-bp154.1.1.noarch
lxqt-archiver-0.5.0-bp154.1.1.x86_64
lxqt-archiver-lang-0.5.0-bp154.1.1.noarch
liblxqt-globalkeys-ui1-1.0.1-bp154.1.1.x86_64
liblxqt-globalkeys1-1.0.1-bp154.1.1.x86_64
lxqt-theme-openSUSE-light-0.1-bp154.1.2.noarch
slemke@notebook:~>
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1200182
Bug ID: 1200182
Summary: systemd-resolved cannot bind port 53
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: MicroOS
Assignee: kubic-bugs(a)opensuse.org
Reporter: paul(a)pbarker.dev
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
On a fresh installation of OpenSUSE MicroOS, I have attempted to switch to
systemd-networkd and systemd-resolved to manage my network connections
following the instructions in
https://en.opensuse.org/Network_Management_With_Systemd. However, when trying
to enable systemd-resolved I hit an error:
alpha:~ # systemctl enable --now systemd-resolved
Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service ���
/usr/lib/systemd/system/systemd-resolved.service.
Created symlink
/etc/systemd/system/multi-user.target.wants/systemd-resolved.service ���
/usr/lib/systemd/system/systemd-resolved.service.
Job for systemd-resolved.service failed because the control process exited with
error code.
See "systemctl status systemd-resolved.service" and "journalctl -xeu
systemd-resolved.service" for details.
alpha:~ # journalctl -xeu systemd-resolved.service
������ Subject: Automatic restarting of a unit has been scheduled
������ Defined-By: systemd
������ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
������
������ Automatic restarting of the unit systemd-resolved.service has been
scheduled, as the result for
������ the configured Restart= setting for the unit.
Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Stopped Network Name Resolution.
������ Subject: A stop job for unit systemd-resolved.service has finished
������ Defined-By: systemd
������ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
������
������ A stop job for unit systemd-resolved.service has finished.
������
������ The job identifier is 1376 and the job result is done.
Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Starting Network Name Resolution...
������ Subject: A start job for unit systemd-resolved.service has begun execution
������ Defined-By: systemd
������ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
������
������ A start job for unit systemd-resolved.service has begun execution.
������
������ The job identifier is 1376.
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Positive Trust Anchors:
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: . IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Negative trust anchors:
home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa
18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa
22.172.in-addr.arpa 23.172.in-addr.arpa 24.>
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Using system hostname
'alpha.cephei.uk'.
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL
link message: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL
link message: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL
link message: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv6(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to listen on UDP
socket 127.0.0.53:53: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to start
manager: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv6(UDP): Failed
to bind socket: Permission denied
Jun 02 21:51:19 alpha.cephei.uk systemd[1]: systemd-resolved.service: Main
process exited, code=exited, status=1/FAILURE
������ Subject: Unit process exited
������ Defined-By: systemd
������ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
������
������ An ExecStart= process belonging to unit systemd-resolved.service has exited.
������
������ The process' exit code is 'exited' and its exit status is 1.
Jun 02 21:51:19 alpha.cephei.uk systemd[1]: systemd-resolved.service: Failed
with result 'exit-code'.
������ Subject: Unit failed
������ Defined-By: systemd
������ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
������
������ The unit systemd-resolved.service has entered the 'failed' state with result
'exit-code'.
Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Failed to start Network Name
Resolution.
It appears that the permission denied errors when systemd-resolved tried to
bind port 53 are caused by SELinux. I confirmed that this is the case by
disabling SELinux and retrying the command - this resulted in systemd-resolved
successfully starting.
Therefore I think there is an error in the SELinux policy here -
systemd-resolved should be able to bind port 53 on localhost to offer DNS
resolution services.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1175219
Bug ID: 1175219
Summary: OpenVPN fails with certificates on smart cards on Leap
15.2 and TW
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.2
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Security
Assignee: security-team(a)suse.de
Reporter: bjoernv(a)arcor.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
After upgrading from Leap 15.1 to Leap 15.2 working OpenVPN setups with PKCS11
certificates on Yubikeys are failing. The same applies to openSUSE Tumbleweed.
Also other smart card devices may be affected.
OpenVPN does not show many details, even with highest logging level.
# openvpn --cd /etc/openvpn --config openvpn-yubikey-test.ovpn
[...]
Thu Aug 13 10:21:21 2020 VERIFY OK: depth=1, CN=Test CA
Thu Aug 13 10:21:21 2020 VERIFY KU OK
Thu Aug 13 10:21:21 2020 Validating certificate extended key usage
Thu Aug 13 10:21:21 2020 ++ Certificate has EKU (str) TLS Web Server
Authentication, expects TLS Web Server Authentication
Thu Aug 13 10:21:21 2020 VERIFY EKU OK
Thu Aug 13 10:21:21 2020 VERIFY OK: depth=0, CN=host1.example.com
Thu Aug 13 10:21:21 2020 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib
Thu Aug 13 10:21:21 2020 TLS_ERROR: BIO read tls_read_plaintext error
Thu Aug 13 10:21:21 2020 TLS Error: TLS object -> incoming plaintext read error
Thu Aug 13 10:21:21 2020 TLS Error: TLS handshake failed
Thu Aug 13 10:21:21 2020 Fatal TLS error (check_tls_errors_co), restarting
Thu Aug 13 10:21:21 2020 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 13 10:21:21 2020 Restart pause, 5 second(s)
The bug can be resolved by upgrading the pkcs11-helper packages from
pkcs11-helper-1.25.1 to pkcs11-helper-devel-1.26.0.
# openvpn --cd /etc/openvpn --config openvpn-yubikey-test.ovpn
[...]
Thu Aug 13 10:32:36 2020 VERIFY OK: depth=1, CN=Test CA
Thu Aug 13 10:32:36 2020 VERIFY KU OK
Thu Aug 13 10:32:36 2020 Validating certificate extended key usage
Thu Aug 13 10:32:36 2020 ++ Certificate has EKU (str) TLS Web Server
Authentication, expects TLS Web Server Authentication
Thu Aug 13 10:32:36 2020 VERIFY EKU OK
Thu Aug 13 10:32:36 2020 VERIFY OK: depth=0, CN=host1.example.com
Enter user1 token Password: (press TAB for no echo)
There is a problem with inconsistent padding between OpenSSL 1.1.1 and
pkcs11-helper-1.25.1. The details are described here:
http://openssl.6102.n7.nabble.com/Issue-with-smartcard-authentication-for-o…
The pkcs11-helper-devel-1.26.0 Changelog contains this line:
- openssl: support RSA_NO_PADDING padding, thanks to Selva Nair
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1196225
Bug ID: 1196225
Summary: webcamoid wants to download binaries from the internet
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: KDE Applications
Assignee: aloisio(a)gmx.com
Reporter: lnussel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
in settings->video->outputs the install button wants to download and run
https://github.com/webcamoid/akvcam/releases/download/1.2.2/akvcam-linux-1.…
That's not ok in openSUSE. Would it be possible to redirect the call to
packagekit instead to make it install a distro package for the software in
question?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1157881
Bug ID: 1157881
Summary: mount.nfs improve error reporting: "Connection
*WHERE*TO* timed out"
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: Other
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: 7eggert(a)gmx.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When one of the nfs mounts times out, it gets reported as "Connection timed
out".
This is semi-helpful and thus semi-qualifies as a bug as well as a feature
request. Please forward this to upstream.
(Also not being able to mount triggers a bug in systemd to unmount unrelated
mounts. One of my nfs servers is currently unresponsive but the other servers
do work, yet systemd unmounts several other mounts. mount.nfs not reporting the
cause didn't help me to find the cause.)
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1127591
Bug ID: 1127591
Summary: zypper option "ssl_capath" not working for mirror URLs
from metalink file
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: x86-64
OS: SUSE Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: libzypp
Assignee: zypp-maintainers(a)forge.provo.novell.com
Reporter: cunix(a)bitmessage.ch
QA Contact: qa-bugs(a)suse.de
CC: security-team(a)suse.de
Found By: ---
Blocker: ---
Using zypper (version: 1.14.12) for the update repository of openSUSE Leap
15.0 with the option
baseurl=https://download.opensuse.org/update/leap/15.0/oss/?proxy=127.0.0.1…
does not use the here configured trusted root certificates for mirror URLs,
probably retrieved from a metalink file.
The configured path is used for the initial connection to download.opensuse.org
but following requests to mirrors seem to fallback to the system trusted certs
from /etc/ssl/certs.
If the mirrors' root CA is trusted in
"ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in
/etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the
TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http
(without transport layer encryption).
Question for cc'ed security-team to answer:
If using clear text is considered a security flaw where zypper is configured to
use (https-)encryption, this might have security implications.
Some Scenarios:
Assume download.opensuse.org is signed by CA A
and the mirror by CA B
Assume further,
ssl_capath=/path/to/directory/with/c_rehash/rootCAs
is directory C
and directory D is
/etc/ssl/certs
1.
If C includes A and B and in D at least B is not available, I would expect
zypper to encrypt both connection, but the request to the mirror is not.
2.
If A is not in C, no data (meta link file) is retrieved and therefore no mirror
is connected - Good!
No fallback of looking for A in D occurs.
3.
If A is in C and B in D, both connections are encrypted.
4.
If A is in C and B not in C and not in D, the mirror is contacted unencrypted -
here I'm unsure if using plain text in this scenario is correct or if it should
fail.
So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper
option to configure, if clear text fallback should be allowed.
Another question is, if /etc/ssl/certs should actually be consulted when the
option "ssl_capath" is used and pointing to a different directory.
https://bugzilla.opensuse.org/show_bug.cgi?id=933839
might be related (similar setup).
Problem and solution might be similar, too.
By the way, is there a debugging option to dump the traffic from inside the
encrypted connection?
Especially being able to read the metalink file with the listed mirrors is of
interest.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1051881
Bug ID: 1051881
Summary: clang can't find libc.so with -m32
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Running:
$ clang --version
clang version 4.0.1 (tags/RELEASE_401/final 305264)
$ cat a.c
int main() {}
$ clang -m32 a.c
/usr/bin/ld: skipping incompatible
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../libc.so when searching for
-lc
/lib/libc.so.6: error adding symbols: File format not recognized
clang-4.0.1: error: linker command failed with exit code 1 (use -v to see
invocation)
I've noticed we have openSUSE specific patches:
https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/clang-r…https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/assume-…
But it does not work properly with -m32. Note the code in DetectDistro.cpp
checks for /etc/SuSE-release, which is legacy. One should use /etc/os-release.
I can fix that after we resolve this issue.
Thanks,
Martin
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133084
Bug ID: 1133084
Summary: [META] GCC + LTO package failures
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Meta issue that will track all packages that fail with enabled Link Time
Optimization (LTO). For more detail description, please see:
https://en.opensuse.org/openSUSE:LTO
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1136670
Bug ID: 1136670
Summary: LTO: libkate build fails on i586
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails here:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:…
due to:
[ 38s] Checking Kate namespace
[ 38s] /usr/bin/nm: '../lib/.libs/*.a': No such file
[ 38s] 00000022 W kate.c.1d9f1982
--
You are receiving this mail because:
You are on the CC list for the bug.