September 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 987114] New: Bluetooth headset connected but not showing under 'Sound Settings'
by bugzilla_noreply＠novell.com 16 Nov '22

16 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=987114 Bug ID: 987114 Summary: Bluetooth headset connected but not showing under 'Sound Settings' Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: damien.lloyd21(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build Identifier: On openSUSE Tumbleweed, my bluetooth headset pairs and connects successfully through GNOME's bluetooth interface, but after going to the 'Sound Settings' my bluetooth headset doesn't show up, even though it is paired up. Because I can't see my bluetooth headset under 'Sound Settings' it's not possible to re-route sound through it, which means I can't use my bluetooth headset. Reproducible: Always Steps to Reproduce: 1. Make bluetooth headset discoverable; 2. Open up GNOME's bluetooth interface and select bluetooth headset; 3. Connect to bluetooth headset; 4. Once paired, access 'Sound Settings': bluetooth headset doesn't show up. Actual Results: The bluetooth headset doesn't show up under 'Sound Settings' even though it is connected and paired. Expected Results: The bluetooth headset should appear under 'Sound Settings' so that sound can be re-routed through it. My headset is a UE MEGABOOM and it worked under Ubuntu 14.04/16.04 extremely well. It doesn't work under openSUSE Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1180037] New: X11:Utilities/WoeUSB: Version upgrade
by bugzilla_noreply＠suse.com 15 Nov '22

15 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180037 Bug ID: 1180037 Summary: X11:Utilities/WoeUSB: Version upgrade Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: 3rd party software Assignee: screening-team-bugs(a)suse.de Reporter: nopeinomicon(a)posteo.net QA Contact: screening-team-bugs(a)suse.de Found By: --- Blocker: --- This software is reasonably outdated as of now. The version packaged is the last version from the project's old git repo, but development has progressed much further. This would be an easy issue to take care of to resubmit the newer package, but the problem is the GUI component is no longer maintained, only the CLI tool. This should be resolved in some way, either by stripping the GUI entirely, or packaging the newer version separately, or some other way at the discretion of the maintainer of course. At the following link is the old Git repo, the readme explains the current state of development, including the depreciation of the GUI found in the package here: https://github.com/slacka/WoeUSB -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1203252] New: virt-manager regression - cannot add second virtio-scsi controller
by bugzilla_noreply＠suse.com 15 Nov '22

15 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203252 Bug ID: 1203252 Summary: virt-manager regression - cannot add second virtio-scsi controller Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Tools Assignee: virt-bugs(a)suse.de Reporter: jirib79(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- virt-manager regression - cannot add second virtio-scsi controller, it used to work fine. ver: virt-manager-4.1.0-1.1.noarch / TW steps to reproduce: 1. create new vm flow 2. select 'Customize configuration before install' 3. 'Add Hardware' -> Controller - use virtio-scsi controller 4. try to add another virtio-scsi controller as the first one issue: - after clicking 'Apply' for the 2nd virtio-scsi controller following error appers: ---%>--- Error building device XML: unsupported operand type(s) for +: 'NoneType' and 'int' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/addhardware.py", line 1359, in _build_device dev = self._build_device_page(page_num) File "/usr/share/virt-manager/virtManager/addhardware.py", line 1375, in _build_device_page dev = self._build_controller() File "/usr/share/virt-manager/virtManager/addhardware.py", line 1571, in _build_controller index_new = max([x.index for x in controller_num]) + 1 TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' ---%<--- notes: - setup of the 1st virtio-scsi controller is: ---%>--- <controller type="scsi" model="virtio-scsi"/> ---%<--- So is it because of the 1st controller still does not have index and other generated lines of the definition? workaround: - edit 1st virtio-scsi controller (see above) and add "index='0'", then adding 2nd controller works fine -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1110245] New: Connection to online repositories should be HTTPS
by bugzilla_noreply＠novell.com 15 Nov '22

15 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1110245 Bug ID: 1110245 Summary: Connection to online repositories should be HTTPS Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: All OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: digitalmon(a)rambler.ru QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Although the online repository servers support HTTPS connection, downloading of packets still occurs via the HTTP protocol. This compromises the security of users. If their connection to the Internet is intercepted, if they work through any proxy server, the attackers can modify the packages on the fly during the download. To install malware and spyware into target system. At the moment, you can only manually change the URLs of the repositories to https so that the packets are downloaded over a secure channel. I want that by default in the operating system the connection to the online-repositories, the downloading of packets, should be with HTTPS connection. This will make users' safety a step higher. I'm sure there will be less glitches, bugs in user systems. But Https is not a panacea. She is also vulnerable to the attack of MITM. The private surveilance service known to me, generates its own RSA-keys to encrypt the HTTPS, brute-force for them a digital signature so that the browser of user does not suspect forgery. The attacker's computer connects to the remote server by https, downloads packages, replaces executable files, infects them with a virus, and the user gives https traffic with his encryption key and a digital signature. But such an attack is not for everyone. To make it more difficult, you need to use long encryption keys and digital signatures on the repository servers. RSA4096 at least. I know that even LTE-connection to the Internet can be intercepted with using of special technical means and OpenLTE, so I do not trust to LTE. LTE-connection can work without encryption, and 3G connection seems to be always encrypted. A wired connection to the Internet, to intercept - generally easy. As PPPoe, as DHCP (DHCP is without authorization and verification of provider access point). The 3G modem with a good antenna has the same speed as the LTE. -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1198626] New: bluez-obex not available by default
by bugzilla_noreply＠suse.com 15 Nov '22

15 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198626 Bug ID: 1198626 Summary: bluez-obex not available by default Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: beppe85(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- It was noticed [1] that transferring files via Bluetooth stopped working. This feature can be reinstated with: $ sudo zypper in bluez-obex $ systemctl --user start obex This report is to ask to add the obex package at least as a recommends, and globally enable the service for users, automatically. [1] https://forums.opensuse.org/showthread.php/566965-bluetooth-no-file-transfer -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1195676] New: Ability to specify mkfs.btrfs options
by bugzilla_noreply＠suse.com 15 Nov '22

15 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1195676 Bug ID: 1195676 Summary: Ability to specify mkfs.btrfs options Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: lmb(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I wanted to specify mkfs.btrfs options (specifically, '--csum xxhash') because that can't be changed later at runtime. The installer did not offer the opportunity to specify custom options or modify the command. (My apologies if it does and I missed this. I did see the fstab options, but that isn't what I need here.) (Looks like this is possible in autoyast2, but not the interactive installer?) -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1200899] New: VUL-1: CVE-2022-34299: Heap-based buffer over-read in libdwarf 0.4.0
by bugzilla_noreply＠suse.com 14 Nov '22

14 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1200899 Bug ID: 1200899 Summary: VUL-1: CVE-2022-34299: Heap-based buffer over-read in libdwarf 0.4.0 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://smash.suse.de/issue/335354/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: dmueller(a)suse.com Reporter: cathy.hu(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2022-34299 There is a heap-based buffer over-read in libdwarf 0.4.0. This issue is related to dwarf_global_formref_b. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-34299 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34299 https://github.com/davea42/libdwarf-code/issues/119 https://github.com/davea42/libdwarf-code/commit/7ef09e1fc9ba07653dd078edb24… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1198869] New: [Tumbleweed][postfix][Build_20220423] Postfix relay failed to send when sending mail from vm3 to vm2 via a relay server(vm1)
by bugzilla_noreply＠suse.com 14 Nov '22

14 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1198869 Bug ID: 1198869 Summary: [Tumbleweed][postfix][Build_20220423] Postfix relay failed to send when sending mail from vm3 to vm2 via a relay server(vm1) 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(a)suse.de Reporter: weixuan.hao(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Summary Postfix working as a relay server failed to relay mail to recipient server, while sending/receiving mail directly works fine for both server. ## Observation Setting up 3 vms, vm1 works as mail server and relay server, vm2 works as mail server and vm3 is the client. Mails sent directly from vm3 to vm1 and vm2 are successful while mails sent from vm3 to vm2 with vm1 as the relay server failed. Similar issue also observed in sle15-sp4 under fips mode. I'm not sure if this is a misconfiguration issue or some other reason caused this. ## Environment # uname -m x86_64 # cat /etc/*release NAME="openSUSE Tumbleweed" # VERSION="20220423" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20220423" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20220423" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed" LOGO="distributor-logo-Tumbleweed" ## Reproducible Basically follow all steps in: https://bugzilla.suse.com/tr_show_case.cgi?case_id=1769966 Note that: 1. 'hash' is not supported in postfix configurations in main.cf now, default replacement is using 'lmdb' 2. Additional dependencies are required, for sle15sp4 cyrus-sasl-saslauthd need to be installed along with metamail installed via package hub; for tumbleweed cyrus-sasl-saslauthd and cyrus-sasl-plain need to be installed Other detailed configurations: VM01: # postconf -n alias_maps = lmdb:/etc/aliases biff = no canonical_maps = lmdb:/etc/postfix/canonical command_directory = /usr/sbin compatibility_level = 3.6 content_filter = daemon_directory = /usr/lib/postfix/bin/ data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 defer_transports = delay_warning_time = 1h disable_dns_lookups = yes disable_mime_output_conversion = no disable_vrfy_command = yes html_directory = /usr/share/doc/packages/postfix-doc/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 0 message_strip_characters = \0 mydestination = $myhostname, localhost mydomain = example1.com myhostname = mail.example1.com mynetworks_style = subnet newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES relay_clientcerts = relay_domains = $mydestination, lmdb:/etc/postfix/relay relay_recipient_maps = lmdb:/etc/postfix/relay_recipients relayhost = relocated_maps = lmdb:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix-doc/samples sender_canonical_maps = lmdb:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_enforce_tls = yes smtp_sasl_auth_enable = no smtp_sasl_password_maps = smtp_sasl_security_options = smtp_tls_CAfile = /etc/ssl/ca-bundle.pem smtp_tls_CApath = smtp_tls_cert_file = smtp_tls_key_file = smtp_tls_loglevel = 2 smtp_tls_session_cache_database = smtp_use_tls = yes smtpd_banner = $myhostname ESMTP smtpd_client_restrictions = smtpd_delay_reject = yes smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = smtpd smtpd_sasl_type = cyrus smtpd_sender_restrictions = lmdb:/etc/postfix/access smtpd_tls_CAfile = smtpd_tls_CApath = smtpd_tls_ask_ccert = no smtpd_tls_cert_file = /etc/postfix/ssl/server1_crt.pem smtpd_tls_exclude_ciphers = RC4 smtpd_tls_key_file = /etc/postfix/ssl/server1_key.pem smtpd_tls_loglevel = 2 smtpd_tls_received_header = yes smtpd_use_tls = yes strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = lmdb:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = lmdb:/etc/postfix/virtual VM02: # postconf -n alias_maps = lmdb:/etc/aliases biff = no canonical_maps = lmdb:/etc/postfix/canonical command_directory = /usr/sbin compatibility_level = 3.6 content_filter = daemon_directory = /usr/lib/postfix/bin/ data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 defer_transports = delay_warning_time = 1h disable_dns_lookups = yes disable_mime_output_conversion = no disable_vrfy_command = yes html_directory = /usr/share/doc/packages/postfix-doc/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 0 message_strip_characters = \0 mydestination = $myhostname, localhost mydomain = example2.com myhostname = mail.example2.com mynetworks_style = subnet newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES relay_clientcerts = relay_domains = $mydestination lmdb:/etc/postfix/relay relay_recipient_maps = lmdb:/etc/postfix/relay_recipients relayhost = relocated_maps = lmdb:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix-doc/samples sender_canonical_maps = lmdb:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_enforce_tls = no smtp_sasl_auth_enable = no smtp_sasl_password_maps = smtp_sasl_security_options = smtp_tls_CAfile = smtp_tls_CApath = smtp_tls_cert_file = smtp_tls_key_file = smtp_tls_session_cache_database = smtp_use_tls = no smtpd_banner = $myhostname ESMTP smtpd_client_restrictions = smtpd_delay_reject = yes smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = smtpd smtpd_sasl_type = cyrus smtpd_sender_restrictions = lmdb:/etc/postfix/access smtpd_tls_CAfile = smtpd_tls_CApath = smtpd_tls_ask_ccert = no smtpd_tls_cert_file = /etc/postfix/ssl/server2_crt.pem smtpd_tls_exclude_ciphers = RC4 smtpd_tls_key_file = /etc/postfix/ssl/server2_key.pem smtpd_tls_loglevel = 2 smtpd_tls_received_header = yes smtpd_use_tls = yes strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = lmdb:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = lmdb:/etc/postfix/virtual ## Error result Log from vm01: # journactl -u postfix.service Apr 26 15:15:56 vm01 postfix/smtp[14526]: certificate verification failed for mail.example2.com[]:25: self-signed certificate Apr 26 15:15:56 vm01 postfix/smtp[14526]: mail.example2.com[]:25: subject_CN=Shawn, issuer_CN=Shawn, fingerprint=, pkey_fingerpr> Apr 26 15:15:56 vm01 postfix/smtp[14526]: Untrusted TLS connection established to mail.example2.com[]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) se> Apr 26 15:15:56 vm01 postfix/smtp[14526]: CB7AE32CB: to=<root(a)example2.com>, relay=mail.example2.com[]:25, delay=0.11, delays=0.07/0.02/0.02/0, dsn=4.7.5, status=deferred (Server certificate not verified) ## Expected result mail should be sent to vm02 successfully -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1170409] New: update-test-trivial: TW test maintenance updates do not work
by bugzilla_noreply＠novell.com 14 Nov '22

14 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1170409 Bug ID: 1170409 Summary: update-test-trivial: TW test maintenance updates do not work Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Maintenance Assignee: screening-team-bugs(a)suse.de Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The test maintenance update is broken in openSUSE:Factory:Update. Installing update-test-trivial from the TW OSS repository does make the zypper maintenance update available/needed, despite it being in the repository. This indicates that the maintenance update stack is not being tested in Tumbleweed. Same for (at least) update-test-security. Install the non-updated package: $ zypper in --from tw-oss update-test-trivial $ zypper search -s -t package update-test-trivial.x86_64 S | Name | Type | Version | Arch | Repository ---+---------------------+---------+---------+--------+----------- v | update-test-trivial | package | 5-5.1 | x86_64 | tw-update i+ | update-test-trivial | package | 5-4.11 | x86_64 | tw-oss v | update-test-trivial | package | 5-4.1 | x86_64 | tw-update Update is not available: $ zypper lp No updates found. But a newer packages is available: $ zypper lu S | Repository | Name | Current Version | Available Version | Arch --+------------+---------------------+-----------------+-------------------+------- v | tw-update | update-test-trivial | 5-4.11 | 5-5.1 | x86_64 The patch seems to refer a previous package $ zypper info -t patch update-test-trivial Information for patch update-test-trivial: ------------------------------------------ Repository : tw-update Name : update-test-trivial Version : 1 Arch : noarch Vendor : BenniBrunner Status : applied Category : recommended Severity : low Created On : Thu Mar 1 11:28:21 2018 Interactive : --- Summary : Test-update for openSUSE Tumbleweed Description : This is a trivial test-update for openSUSE Tumbleweed. Provides : patch:update-test-trivial = 1 Conflicts : [4] update-test-trivial.src < 5-4.1 update-test-trivial.noarch < 5-4.1 update-test-trivial.x86_64 < 5-4.1 update-test-trivial.i586 < 5-4.1 -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1189003] New: Yast is unable to handle encrypted disk
by bugzilla_noreply＠suse.com 14 Nov '22

14 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1189003 Bug ID: 1189003 Summary: Yast is unable to handle encrypted disk Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs(a)suse.de Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 851486 --> http://bugzilla.opensuse.org/attachment.cgi?id=851486&action=edit Screenshot showing problem and details When trying an update or installation, Yast detects an encrypted disk, asks for the password, and unlocks it, but then is unable to continue (see attachment). The device /dev/mapper/cr-auto-1 is there when Yast claims it is not. -- You are receiving this mail because: You are on the CC list for the bug.

1 13