July 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1187704] New: [Staging] runc1.0.0 breaks podman
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187704 Bug ID: 1187704 Summary: [Staging] runc1.0.0 breaks podman Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1805410/modules/podm an/steps/70 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: asarai(a)suse.com Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Staging:E-Staging-DVD-x86_64-container-host-microos@64bit-2G-HD40G fails in [podman](https://openqa.opensuse.org/tests/1805410/modules/podman/steps/70) ## Test suite description Test tries to run a simple podman run hello-world container: podman container run --name test_1 18.156.2.117:5000/library/hello-world | grep 'Hello from Docker!'; echo qn7p5-$?- Results in an OCI permission error: Error: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: process_linux.go:508: setting cgroup config for procHooks process caused: cannot fetch program from id: get program by id: permission denied: OCI permission denied qn7p5-1- Also happens on unrelated, undependant but similar podman_image tests when trying to start containers: https://openqa.opensuse.org/tests/1805410#step/podman_image/22 We cannot accept runc 1.0.0 until this issue is resolved. ## Reproducible Fails since (at least) Build [E.514.1](https://openqa.opensuse.org/tests/1804171) ## Expected result Last good: [E.513.1](https://openqa.opensuse.org/tests/1797455) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1175754] New: (EE) Failed to load /usr/lib/xorg/modules/drivers/mga_drv.so: /usr/lib/xorg/modules/drivers/mga_drv.so: undefined symbol: shadowUpdatePacked
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1175754 Bug ID: 1175754 Summary: (EE) Failed to load /usr/lib/xorg/modules/drivers/mga_drv.so: /usr/lib/xorg/modules/drivers/mga_drv.so: undefined symbol: shadowUpdatePacked Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i586 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: mrmazda(a)earthlink.net QA Contact: gfx-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 841042 --> http://bugzilla.opensuse.org/attachment.cgi?id=841042&action=edit Xorg.0.log from TW20200824 P4 host gx27c Xorg.0.log highlights: (EE) Failed to load /usr/lib/xorg/modules/drivers/mga_drv.so: /usr/lib/xorg/modules/drivers/mga_drv.so: undefined symbol: shadowUpdatePacked EE) Failed to load module "mga" (loader failed, 0) (EE) Failed to load module "fbdev" (module does not exist, 0) (EE) Failed to load module "vesa" (module does not exist, 0) (EE) open /dev/dri/card0: No such file or directory (EE) open /dev/dri/card0: No such file or directory (EE) Screen 0 deleted because of no matching config section. (EE) Device(s) detected, but none match those in the config file. Matrox G400 102b:0525, has been like this for over a year. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1187864] Semantic interposition inhibits optimization of shared libraries
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187864 http://bugzilla.opensuse.org/show_bug.cgi?id=1187864#c5 --- Comment #5 from Aaron Puchert <aaronpuchert(a)alice-dsl.net> --- (In reply to Richard Biener from comment #2) > For C there's no ODR so things are more complicated. What about C11 6.9.5? An external definition is an external declaration that is also a definition of a function (other than an inline definition) or an object. If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one. (In reply to Michael Matz from comment #3) > I'm quite heavily opposed to disabling interposition wholesale. In my view this is more about explicitly annotating interposable functions as weak instead of allowing interposition for any function. ELF default visibility has always implied interposability, but I think that's mostly seen as historical artifact by now. Visibility and interposability are pretty much orthogonal. Just because a library is "exporting" functions doesn't mean it's inviting others to replace them. With a few exceptions that makes absolutely no sense, and it wouldn't hurt to mark these exceptions as "weak". > Also note that protected visiblity is going to be fixed on x86-64 (to not be > worse than default visibility and break with copy relocations, i.e. it will > work again like before 2014/15) over the next months. What are the ideas for that? Not doing copy relocations at all, or giving protected visibility a different meaning for variables? > At that point packages choosing so can simply use that. It's going to quite a bit of time for packages to migrate to this. I get your point, default visibility has never been a good default, and it's probably hopeless to save it. Protected visibility is more or less defined as non-interposable export, so that and hidden visibility should satisfy nearly all uses. Default visibility could still be used for the rare case where a function should actually be interposable. But I think that's what library writers have (in almost all cases) always wanted, but didn't use it because it didn't work and was recommended against. (GCC's man page says "protected and internal are pretty useless in real-world usage so the only other commonly used option is hidden." Drepper writes: "Only the first two [default and hidden] should ever be used.") Still, protected visibility just doesn't interpose, it doesn't error out if there is a function with the same name. So while library writers can use it to opt out of interposition (which they probably didn't want in the first place), those who'd want to interpose just get a silent failure just as if we were making -fno-semantic-interposition the default. If library writers know about their users and whether someone might interpose their functions that could be helpful, but I don't know how often that's the case. In any event, if library writers want to actively allow interposition, an explicit "weak" attribute would communicate that intent clearly. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187788] New: audacity is searching for jack via cmake files
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187788 Bug ID: 1187788 Summary: audacity is searching for jack via cmake files Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ``` [ 37s] By not providing "Findjack.cmake" in CMAKE_MODULE_PATH this project has [ 37s] asked CMake to find a package configuration file provided by "jack", but [ 37s] CMake did not find one. [ 37s] [ 37s] Could not find a package configuration file provided by "jack" with any of [ 37s] the following names: [ 37s] [ 37s] jackConfig.cmake [ 37s] jack-config.cmake [ 37s] [ 37s] Add the installation prefix of "jack" to CMAKE_PREFIX_PATH or set [ 37s] "jack_DIR" to a directory containing one of the above files. If "jack" [ 37s] provides a separate development package or SDK, be sure it has been [ 37s] installed. ``` I think this leads to audacity not being built with jack. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1137569] [Build 20190605] openQA test fails in vino_screensharing_available
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

https://bugzilla.suse.com/show_bug.cgi?id=1137569 https://bugzilla.suse.com/show_bug.cgi?id=1137569#c18 --- Comment #18 from openQA Review <openqa-review(a)suse.de> --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: extra_tests_on_gnome https://openqa.opensuse.org/tests/1755944 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The label in the openQA scenario is removed -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1188056] New: Upgrade fetchmail to latest version as TLS v1.0 is deprecated.
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188056 Bug ID: 1188056 Summary: Upgrade fetchmail to latest version as TLS v1.0 is deprecated. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: erwinl(a)dds.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The version of fetchmail (v 6.3.26) in the distribution was released in 2013 and does not support TLS beyond version 1.0. TLS version 1.0 is deprecated. The current version of fetchmail was no longer able to negotiate a secure TLS connection with the IMAP server of my mail provider because the IMAP server was upgraded to use TLS v1.2 Please, update fetchmail in the distribution to at least version 6.4.19. This version supports TLS v1.2 and 1.3. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1116658] Crash of Writer opening any document having "invalid" python file in home directory
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

https://bugzilla.suse.com/show_bug.cgi?id=1116658 https://bugzilla.suse.com/show_bug.cgi?id=1116658#c43 --- Comment #43 from Mark�ta Machov� <mmachova(a)suse.com> --- (In reply to Ednilson Miura from comment #41) > Yes, yes, sorry, I properly used abc.py to reproduce the issue. > However, SLE12SP5 does not seem to have $PYTHONPATH set, so it wont > reproduce the issue as is. > May I consider it as "not reproduceable" (i.e not an issue), since it > requires the variable to be set manually? Yes, please :) consider this issue fixed. Fiddling with PYTHONPATH could get you into trouble in many ways. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1185893] opensuse-welcome: typo in German translation "siech"
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1185893 http://bugzilla.opensuse.org/show_bug.cgi?id=1185893#c7 Andreas Stieger <Andreas.Stieger(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suttorp(a)pt.lu --- Comment #7 from Andreas Stieger <Andreas.Stieger(a)gmx.de> --- *** Bug 1188053 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1188053] New: Typo in "welcome" window
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188053 Bug ID: 1188053 Summary: Typo in "welcome" window Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Translations Assignee: ke(a)suse.com Reporter: suttorp(a)pt.lu QA Contact: ke(a)suse.com Found By: --- Blocker: --- Typo in the German translation in the welcoming window that pops up at the first login after the installation of the OS. "Falls dies Ihr erstes mal mit openSUSE ist, w�nschen wir uns dass Sie [siech] direkt auf Ihrer neuen Reise wohl f�hlen." "siech" instead of "sich" -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1137203] [Build 20190602] openQA test fails in tk
by bugzilla_noreply＠suse.com 06 Jul '21

06 Jul '21

https://bugzilla.suse.com/show_bug.cgi?id=1137203 https://bugzilla.suse.com/show_bug.cgi?id=1137203#c27 --- Comment #27 from Oliver Kurz <okurz(a)suse.com> --- (In reply to Reinhard Max from comment #26) > (In reply to Oliver Kurz from comment #21) > > e.g. see the latest result > > https://openqa.opensuse.org/tests/1755968#step/tk/10 where a TK window shows > > up but no font is rendered, hence reopening. > > I finally managed to boot the images from this run in qemu on x86_64 using > the hints and scripts from comment 8 with a few changes that should not > affect the results: > [��] > What do I need to change to run this image under conditions that are closer > to what happens in openQA when the bug shows up? Did you try to reproduce on x86_64? Because the tests do not reproduce it there but now only aarch64. -- You are receiving this mail because: You are on the CC list for the bug.

1 0