July 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1210186] python-zope.schema:test fails to build in Leap 15.5
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1210186 https://bugzilla.suse.com/show_bug.cgi?id=1210186#c5 --- Comment #5 from Daniel Garcia <daniel.garcia(a)suse.com> --- (In reply to Daniel Garcia from comment #4) > Okay, I've created a request backporting the patch that fixes the failing > tests. https://github.com/zopefoundation/zope.schema/commit/d7126a481e5c92e9e2b35b… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1210186] python-zope.schema:test fails to build in Leap 15.5
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1210186 https://bugzilla.suse.com/show_bug.cgi?id=1210186#c4 --- Comment #4 from Daniel Garcia <daniel.garcia(a)suse.com> --- Okay, I've created a request backporting the patch that fixes the failing tests. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212474] Nautilus: Segmentation fault (core dumped) with libpython3_11-1_0-x86-64-v3 (works with non-v3 optimized library)
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212474 Daniel Garcia <daniel.garcia(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.garcia(a)suse.com Assignee|python-maintainers(a)suse.com |daniel.garcia(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1210186] python-zope.schema:test fails to build in Leap 15.5
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1210186 Daniel Garcia <daniel.garcia(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 953693] VLC opens video in a second window
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=953693 https://bugzilla.suse.com/show_bug.cgi?id=953693#c33 --- Comment #33 from Stakanov Schufter <stakanov(a)disroot.org> --- Created attachment 867929 --> https://bugzilla.suse.com/attachment.cgi?id=867929&action=edit vlc opens independent window in wayland this is in a Wayland session but does not happen in a X11 session. The bug is therefore valid only for Plasma Wayland. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212932] sddm 0.20 puts $XAUTHORITY in /tmp instead of $XDG_RUNTIME_DIR
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212932 https://bugzilla.suse.com/show_bug.cgi?id=1212932#c1 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar(a)gmail.com, | |fvogt(a)suse.com Flags| |needinfo?(arvidjaar(a)gmail.c | |om) --- Comment #1 from Fabian Vogt <fvogt(a)suse.com> --- That's intentional and was part of the libXau PR already. It was in /run/user/... initially but that proved to be problematic: - On FreeBSD, $XDG_RUNTIME_DIR is an afterthought and only created/set as part of the graphical session itself - If $XDG_RUNTIME_DIR is not available, a fallback is needed anyway - Cleanup needs to be performed after session exit but still as unprivileged user, which is currently not easily possible with sddm-helper's design Is there any particular issue with having the file in /tmp instead? That commit touches the code for the greeter cookie only and doesn't actually change the location either: - m_authPath = QStringLiteral("%1/%2").arg(m_authDir).arg(QUuid::createUuid().toString(QUuid::WithoutBraces)); - qDebug() << "Xauthority path:" << m_authPath; + m_authFile.setFileTemplate(m_authDir + QStringLiteral("/xauth_XXXXXX")); It's inside m_authDir in both cases. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212919] kdesu does not launch kate
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212919 https://bugzilla.suse.com/show_bug.cgi?id=1212919#c5 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fkrueger@mailbox. | |org) CC| |fvogt(a)suse.com --- Comment #5 from Fabian Vogt <fvogt(a)suse.com> --- The xauth output looks good. What's $DISPLAY? Does xterm show any better error message? (In reply to Frank Krüger from comment #4) > Might this issue actually be a feature? Cf. > https://build.opensuse.org/package/view_file/openSUSE:Factory/kate/0001- > Defuse-root-block.patch?expand=1 No, it would clearly indicate that. In this case it fails to connect to the X server. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212929] Subvolume layout should not depend on whether snapshots are enabled during installation
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212929 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212775] go1.16 fails to build with new update kernel-sources 6.4
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212775 https://bugzilla.suse.com/show_bug.cgi?id=1212775#c9 --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jeff Kowalczyk from comment #8) > Do newer Go versions build with 6.4? Only both go1.16 and go1.17 were failing. > Currently go1.x bootstraps with an earlier go1.x toolchain, but gccgo is an > option for bootstrapping. This change is already under consideration > primarily to shorten the bootstrap chain. > > go1.16 and go1.17 are EOL for upstream updates: > https://github.com/golang/go/wiki/Go-Release-Cycle The supported versions > today are go1.19 and go1.20, and in August 2023 the supported versions shift > to go1.20 and go1.21 (go1.21rc2 is in Factory). > > TBD if 6.4 compatibility fixes for recent Go versions backport to go1.16 and > go1.17. go1.17 in particular is a designated bootstrap version: > https://github.com/golang/go/issues/44505 It looks like a bug in these old versions. So the kernel doesn't seem to be at fault this time. So could you somehow eliminate these old unsupported versions of go? (I actually quite don't understand why they designated an unsupported version for bootstrapping?) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212929] New: Subvolume layout should not depend on whether snapshots are enabled during installation
by bugzilla_noreply＠suse.com 03 Jul '23

03 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212929 Bug ID: 1212929 Summary: Subvolume layout should not depend on whether snapshots are enabled during installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: arvidjaar(a)gmail.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Currently if snapshots were disabled during installation, installer puts root on /@ subvolume. Users can enable snapshots later and it will appear to work as usual until user attempts rollback. At which point content of /@ subvolume becomes completely hidden, it is not visible in snapper output and for a user it looks like mysteriously lost space. Because /@ subvolume contains all other system subvolumes it is also impossible to simply delete it, user must mount and manually clean it up which is rather error prone. The latest user experience on this: https://forums.opensuse.org/t/one-small-snapshot-takes-a-lot-of-disk-space-… I do not see any reason for this artificial difference in subvolume layouts. There is absolutely no harm in having root always on /.snapshot/1/subvolume after installation. This will provide consistent layout and make it easy to enable snapshots later. It will also simplify installer :) Ideally, installer should also create snapper metadata for the initial snapshot unconditionally (but may be this is better done by snapper when snapshots are enabled). -- You are receiving this mail because: You are on the CC list for the bug.

1 0