April 2016 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 960739] New: OpenStack nova ends with traceback when connecting to server with custom SUSE certificate
by bugzilla_noreply＠novell.com 19 Mar '20

19 Mar '20

http://bugzilla.suse.com/show_bug.cgi?id=960739 Bug ID: 960739 Summary: OpenStack nova ends with traceback when connecting to server with custom SUSE certificate Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mnowak(a)suse.com QA Contact: qa-bugs(a)suse.de CC: mkravec(a)suse.com, pgonin(a)suse.com Found By: --- Blocker: --- I try to connect to cloud.suse.de on Tumbleweed but I end up with traceback: $ nova --debug image-list DEBUG (session:198) REQ: curl -g -i -X GET https://dashboardp2.cloud.suse.de:5000/v2.0/ -H "Accept: application/json" -H "User-Agent: python-keystoneclient" INFO (connectionpool:756) Starting new HTTPS connection (1): dashboardp2.cloud.suse.de WARNING (base:143) Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. DEBUG (v2:86) Making authentication request to https://dashboardp2.cloud.suse.de:5000/v2.0/tokens INFO (connectionpool:756) Starting new HTTPS connection (2): dashboardp2.cloud.suse.de DEBUG (shell:905) SSL exception connecting to https://dashboardp2.cloud.suse.de:5000/v2.0/tokens: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 903, in main OpenStackComputeShell().main(argv) File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 737, in main api_version = api_versions.discover_version(self.cs, api_version) File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 253, in discover_version client) File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 235, in _get_server_version_range version = client.versions.get_current() File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 62, in get_current return self._get_current() File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 43, in _get_current url = self.api.client.get_endpoint().rsplit("/", 1)[0] File "/usr/lib/python2.7/site-packages/keystoneclient/adapter.py", line 129, in get_endpoint return self.session.get_endpoint(auth or self.auth, **kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 660, in get_endpoint return auth.get_endpoint(self, **kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 315, in get_endpoint service_catalog = self.get_access(session).service_catalog File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 240, in get_access self.auth_ref = self.get_auth_ref(session) File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/generic/base.py", line 186, in get_auth_ref return self._plugin.get_auth_ref(session, **kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py", line 88, in get_auth_ref authenticated=False, log=False) File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 501, in post return self.request(url, 'POST', **kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/utils.py", line 337, in inner return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 386, in request resp = send(**kwargs) File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 424, in _send_request raise exceptions.SSLError(msg) SSLError: SSL exception connecting to https://dashboardp2.cloud.suse.de:5000/v2.0/tokens: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) ERROR (SSLError): SSL exception connecting to https://dashboardp2.cloud.suse.de:5000/v2.0/tokens: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) Packages: python-openstackclient-1.7.1-1.1.noarch python-novaclient-2.30.1-1.1.noarch python-neutronclient-3.1.0-1.1.noarch python-glanceclient-1.1.0-1.1.noarch python-cinderclient-1.4.0-1.1.noarch python-troveclient-1.3.0-1.1.noarch python-keystoneclient-1.7.2-1.1.noarch python-swiftclient-2.6.0-1.1.noarch python-heatclient-0.8.0-1.1.noarch python-ceilometerclient-1.5.0-1.1.noarch python-saharaclient-0.11.1-1.1.noarch ca-certificates-suse-1.0-5.1.noarch *-openrc.sh file is properly sourced in the terminal. `nova --insecure image-list` works but prints a lot of InsecureRequestWarning warnings. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 927743] New: Loading screen not displaying correctly
by bugzilla_noreply＠novell.com 17 Mar '20

17 Mar '20

http://bugzilla.opensuse.org/show_bug.cgi?id=927743 Bug ID: 927743 Summary: Loading screen not displaying correctly Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: x86-64 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gerharddeclercq(a)outlook.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am on Tumbleweed and the loading screen (three green blocks) are not displaying correctly on my machine (Thinkpad Yoga S1). They displayed correctly on 13.2. They are now just blocks of strange green characters that I do not recognize. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 969142] New: games:tools/springlobby: Bug
by bugzilla_noreply＠novell.com 14 Mar '20

14 Mar '20

http://bugzilla.opensuse.org/show_bug.cgi?id=969142 Bug ID: 969142 Summary: games:tools/springlobby: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: matthias(a)mailaender.name Reporter: smithjd15(a)gmail.com QA Contact: opensuse-communityscreening(a)forge.provo.novell.com CC: opensuse(a)dstoecker.de Found By: --- Blocker: --- Hard runtime dependencies for springlobby that aren't pulled in: libwx_baseu_net-suse1 libwx_gtk2u_qa-suse1 libwx_gtk2u_adv-suse1 libwx_gtk2u_aui-suse1 springlobby also complains about libdumb, but still runs. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 915483] New: a2ps:/etc/a2ps.cfg:220: invalid option `variable:'
by bugzilla_noreply＠novell.com 10 Mar '20

10 Mar '20

http://bugzilla.suse.com/show_bug.cgi?id=915483 Bug ID: 915483 Summary: a2ps:/etc/a2ps.cfg:220: invalid option `variable:' Classification: openSUSE Product: openSUSE Factory Version: 201501* Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 621418 --> http://bugzilla.suse.com/attachment.cgi?id=621418&action=edit Patch that fixes the configuration file Using a2ps on a simple text file, with a2ps-4.14-1.1.x86_64 I get % a2ps -o x.ps x a2ps:/etc/a2ps.cfg:220: invalid option `variable:' % ll /etc/a2ps.cfg -rw-r--r-- 1 root root 15964 Dez 16 17:42 /etc/a2ps.cfg `rpm -V a2ps` indicates I have the vanilla version of that file, and indeed I never changed anything. This seems to be due to a spelling of "variable" (lowercase) vs "Variable", and can be fixed as follows (see attached patch): -variable: ghostview a2ps-open +Variable: ghostview a2ps-open -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 917728] New: Obsolete/deprecated config option still enabled
by bugzilla_noreply＠novell.com 23 Feb '20

23 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=917728 Bug ID: 917728 Summary: Obsolete/deprecated config option still enabled Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: zaitor(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi Kernel people. Just installed the spiffy new 3.19 kernel from Kernel:stable, and when going through journald logs to see if there was something new and exciting I came over these warnings that I've seen for ages, but never cared for since it seem to do no harm. linux-ial4:~ # uname -r 3.19.0-1.g8a7d5f9-desktop linux-ial4:~ # journalctl -b | grep CONFIG_ACPI_PROCFS_POWER feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared linux-ial4:~ # ---- But today I took the time to google it, and found this bug from Arch https://bugs.archlinux.org/task/25845 Snip from bug ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared This was scheduled for removal in 2.6.39, but is still there. I suggest trying to disable it for 3.1, if for nothing else than to discover what problems this might cause so the appropriate bug reports can be filed. >From Documentation/feature-removal-schedule.txt: What: CONFIG_ACPI_PROCFS_POWER When: 2.6.39 Why: sysfs I/F for ACPI power devices, including AC and Battery, has been working in upstream kernel since 2.6.24, Sep 2007. In 2.6.37, we make the sysfs I/F always built in and this option disabled by default. Remove this option and the ACPI power procfs interface in 2.6.39. Who: Zhang Rui <rui.zhang(a)intel.com> ---- Short story this was disabled on Arch back in 2011 Could we do this for openSUSE too? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 966255] New: System does not boot
by bugzilla_noreply＠novell.com 09 Feb '20

09 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=966255 Bug ID: 966255 Summary: System does not boot Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: rjschwei(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- kernel 4.4.0.3 Has encrypted user partition. Hangs at Ignoring BGRT: Invalid version 0 (expected 1) This appears to happen right before the point where I would expect to enter my passphrase. -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 790151] New: When I open nickle-2.70-1.src.rpm,YaST2 finds nothing to install.
by bugzilla_noreply＠novell.com 02 Jan '20

02 Jan '20

https://bugzilla.novell.com/show_bug.cgi?id=790151 https://bugzilla.novell.com/show_bug.cgi?id=790151#c0 Summary: When I open nickle-2.70-1.src.rpm,YaST2 finds nothing to install. Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 URL: http://nickle.org/release/nickle-2.70-1.src.rpm OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: giecrilj(a)stegny.2a.pl QAContact: jsrain(a)suse.com CC: hrvoje.senjan(a)gmail.com Depends on: 684610 Found By: Community User Blocker: No +++ This bug was initially created as a clone of Bug #684610 +++ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.0) Gecko/20100101 Firefox/4.0 When I open nickle-2.70-1.src.rpm, YaST2 does not install anything. Reproducible: Always Steps to Reproduce: 1. Tell Dolphin to open nickle-2.70-1.src.rpm [1]. Actual Results: 1. YaST2 finds nothing to be installed. Expected Results: 1. Let YaST2 install the source package. ___ [1] <URL: http://nickle.org/release/nickle-2.70-1.src.rpm > -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

[Bug 712025] New: openssh helpers wrongly uses %_libdir
by bugzilla_noreply＠novell.com 26 Dec '19

26 Dec '19

https://bugzilla.novell.com/show_bug.cgi?id=712025 https://bugzilla.novell.com/show_bug.cgi?id=712025#c0 Summary: openssh helpers wrongly uses %_libdir Classification: openSUSE Product: openSUSE 12.1 Version: Factory Platform: x86-64 OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: qa(a)suse.de Found By: Beta-Customer Blocker: --- I had a openSUSE 11.4 i586 installation on one machine, and as I was upgrading its hardware to a 64-bit CPU, I did a x86_64 reinstall, and copied over the configs from the previous install. Among that was /etc/ssh/sshd_config. After this, sftp was no longer usable ("Connection closed by host"), hinting towards the helper not being executable. sshd_config, having been inherited from a i586 environment, contained: Subsystem sftp /usr/lib/ssh/sftp-server However, the sftp helper was installed in /usr/lib64/ssh (%_libdir/ssh), which I consider the wrong place, because the helper is bitness-independent and thus should go to %_libexecdir/ssh instead. The problem persists by looking at the current /network/openssh/openssh.spec. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

[Bug 536564] New: Packages creating user accounts do not select UID
by bugzilla_noreply＠novell.com 26 Dec '19

26 Dec '19

http://bugzilla.novell.com/show_bug.cgi?id=536564 Summary: Packages creating user accounts do not select UID Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: All OS/Version: Linux Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: qa(a)suse.de Found By: Beta-Customer Some packages, such as openssh, do explicitly specify a UID/GID when creating its users/groups: /usr/sbin/groupadd -g 65 -o -r sshd 2>/dev/null || :; On the other hand, the hal package does not: /usr/sbin/groupadd -r haldaemon 2>/dev/null || : So, which is correct? Should not hal also use a fixed ID? There are many packages belonging to the latter category. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 518238] New: openSSH chroot security settings faulty
by bugzilla_noreply＠novell.com 26 Dec '19

26 Dec '19

http://bugzilla.novell.com/show_bug.cgi?id=518238 Summary: openSSH chroot security settings faulty Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: marcus(a)swedcore.net QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060200 SUSE/3.0.11-0.1.1 Firefox/3.0.11 Whenever i tried to setup a chroot environment with OpenSSH the security settings for the user folder must be root or OpenSSH doesn't work, the only solution for now is to either create subfolders in the users chroot folder where the user can have write permissions or land them one step up in the hierarchy and thus making them see other chroot folder which is not good. I followed this Wiki page to the letter: http://en.opensuse.org/Openssh#SFTP_chroot_with_ChrootDirectory I have Swedish community users trying to set this up to with same result as me. This thread takes up the same issue: http://marc.info/?l=openssh-unix-dev&m=122640731518850&w=2 But the solution mentioned there is not acceptable because as it stats on the Wiki you make one folder the chroot folder and then mapping the users home folder relative to the chroot folder, in this scenario the users should get write permissions to his own folder, but that is not possible, thus breaking the functionality intended. So the question is, is this a bug or is it designed to act like this? Reproducible: Always Steps to Reproduce: Done accordingly to this wiki entry: http://en.opensuse.org/OpenSSH Actual Results: Gets a read only home folder root Expected Results: Getting a writable home folder, where they can create on folder and upload files directly to the root of their home folder. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6