November 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1192157] New: libzypp caching strategy
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1192157 Bug ID: 1192157 Summary: libzypp caching strategy Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: jdelvare(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I would like to understand libzypp's strategy for caching packages (under /var/cache/zypp/packages). My practical issue is with wine-staging packages which I get from the Emulators:Wine repository. Once in a while, a wine-staging update breaks my game and I would like to get back to the previous, known-working version. My expectation is that this package should be in the cache, as it was installed not long ago. However, looking in /var/cache/zypp/packages/Emulators_Wine/x86_64, I see old versions of wine-staging (from 6.3 to 6.12) but *not* the recent versions (latest is 6.20, so I would be looking for 6.19). What is the logic of libzypp to decide whether or not a package file should be kept in the cache by default? I would expect the cache to be handled in a first in, first out style, that is, delete older files first to make room for newer files. Newer packages have a much higher chance to be needed again. For now I am forced to manually download rpm packages and store them in my own cache. But as everything manual, I eventually forget and only remember the next time a wine-staging update breaks my game - at which point it is too late as the package I need is no longer available in the online repository. Now I see that repository files have a keeppackages option, which could help here. However, I haven't set it on any repository so far, still my /var/cache/zypp contains 1.7 GB of caches packages, so there's definitely caching going on even without this option. Makes me wonder what the option is really doing (I'm going to give it a try now). Shouldn't /var/cache/zypp/packages be empty when all repositories are configured with keeppackages=0? This brings another question of how much data libzypp is going to keep in the cache. The keeppackages flag is binary, if implemented the way it is documented, it would keep no files at all (if set to 0), or all files forever (if set to 1). I would expect a limit to exist so as to not fill out the storage space completely, however I couldn't find any such option in /etc/zypp/zypp.conf. Did I miss the option? Is there are hard-coded limit? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1191402] New: [Snapshots 20210929 and 20211001] [KDE Plasma Wayland] GTK Applications (Firefox, Inkscape etc) adopt broken adwaita theme, cursors do not follow Breeze default
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1191402 Bug ID: 1191402 Summary: [Snapshots 20210929 and 20211001] [KDE Plasma Wayland] GTK Applications (Firefox, Inkscape etc) adopt broken adwaita theme, cursors do not follow Breeze default 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: mrcuve0(a)posteo.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0 Build Identifier: After updating Tumbleweed from 20210927 to 20210929 (and 20211001) GTK applications like Firefox and Inkscape adopt an "old-looking" Adwaita theme, with non antialiased fonts and Adwait cursor. For instance, on Firefox, moving the mouse in and out the window makes the mouse cursor change to (what I believe is) Adwaita's default one, hence not following the default Breeze dark cursor. Reproducible: Always Steps to Reproduce: 1. Update from 20210927 to 20210929 (which I believe is the snapshot causing the issue) 2. Open Inkscape, the splashscreen has non-antialiased fonts, the cursor when inside the window does not respect system's default one (Breeze Dark in my case) 3. Open Firefox, a similar behavior happens: the cursor, when inside the window, changes from Breeze to Adwaita's one. It reverts back to the default one when placing the cursor outside the window. Actual Results: GTK applications stop following the GTK theme set by the user and revert back to Adwaita, with non-antialised fonts and general old looking theme. Setting back a custom GTK theme normally used by the user has no effect, even after logouts or reboots. Expected Results: Both GTK applications shall resort to the GTK theme adopted by the user, not Adwaita's one. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1191517] emacs-gtk crashes on mouse selection due to XLIB_SKIP_ARGB_VISUALS=1 in /usr/bin/emacs
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191517 https://bugzilla.suse.com/show_bug.cgi?id=1191517#c41 Martin Wilck <martin.wilck(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maurizio.galli(a)suse.com --- Comment #41 from Martin Wilck <martin.wilck(a)suse.com> --- Problem A): emacs crashes with XLIB_SKIP_ARGB_VISUALS=1 Problem B): emacs crashes without XLIB_SKIP_ARGB_VISUALS=1 A new occurence of A) was just reported in bug 1186341. It appears that the occurence of A) is increasing. The only person reporting B) was Maurizio Galli (comment 1186341, comment 20 ff.). Admittedly, there was only a short time window in which XLIB_SKIP_ARGB_VISUALS= wasn't set by default, so perhaps there would have been more reporters of B) if the change hadn't been reverted quickly. Still, "Necessary to keep Flash from crashing" (comment 19) seems to be a very weak rationale for having emacs crash. So perhaps we should vote for changing the default once more... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1186341] New: emacs-gtk crashes when hitting Ctrl-<space>
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1186341 Bug ID: 1186341 Summary: emacs-gtk crashes when hitting Ctrl-<space> Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When hitting ctrl-space (set-mark-command), emacs reproducibly crashes. #0 XVisualIDFromVisual (visual=0x0) at Misc.c:60 #1 0x00007f8ef5a4e2de in gdk_x11_window_foreign_new_for_display (display=0x22220e0 [GdkX11Display], window=90177538) at x11/gdkwindow-x11.c:1270 #2 0x00007f8ef5a39478 in gdk_x11_display_translate_event (translator=<optimized out>, display=0x22220e0 [GdkX11Display], event=0x2238be0, xevent=0xa7e3b0 <old_fcntl_owner+1168>) at x11/gdkdisplay-x11.c:1116 #3 0x00007f8ef5a3acc1 in _gdk_x11_event_translator_translate (translator=0x22220e0, display=0x22220e0 [GdkX11Display], xevent=xevent@entry=0xa7e3b0 <old_fcntl_owner+1168>) at x11/gdkeventtranslator.c:51 #4 0x00007f8ef5a3e800 in gdk_event_source_translate_event (xevent=0xa7e3b0 <old_fcntl_owner+1168>, event_source=0x2239a30) at x11/gdkeventsource.c:243 #5 _gdk_x11_display_queue_events (display=0x22220e0 [GdkX11Display]) at x11/gdkeventsource.c:341 #6 0x00007f8ef5a056a9 in gdk_display_get_event (display=0x22220e0 [GdkX11Display]) at gdkdisplay.c:442 #7 0x00007f8ef5a3ea22 in gdk_event_source_dispatch (source=source@entry=0x2239a30, callback=<optimized out>, user_data=<optimized out>) at x11/gdkeventsource.c:363 #8 0x00007f8ef54288b7 in g_main_dispatch (context=0x2239b20) at ../glib/gmain.c:3337 #9 g_main_context_dispatch (context=0x2239b20) at ../glib/gmain.c:4055 #10 0x00007f8ef5428c38 in g_main_context_iterate (context=context@entry=0x2239b20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131 #11 0x00007f8ef5428cef in g_main_context_iteration (context=0x2239b20, context@entry=0x0, may_block=may_block@entry=1) at ../glib/gmain.c:4196 #12 0x00007f8ef5d19385 in gtk_main_iteration () at gtkmain.c:1433 #13 0x00000000004ed0c3 in XTread_socket (terminal=<optimized out>, hold_quit=0xa7e620 <old_fcntl_owner+1792>) at xterm.c:9396 #14 0x0000000000514312 in gobble_input () at keyboard.c:6892 #15 0x00000000005865a5 in handle_async_input () at keyboard.c:7129 #16 process_pending_signals () at keyboard.c:7143 -- You are receiving this mail because: You are on the CC list for the bug.

1 26

[Bug 1192194] irq 40: nobody cared (try booting with the "irqpoll" option)
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192194 https://bugzilla.suse.com/show_bug.cgi?id=1192194#c2 --- Comment #2 from Takashi Iwai <tiwai(a)suse.com> --- Also, how often is this reproduced? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192194] irq 40: nobody cared (try booting with the "irqpoll" option)
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192194 https://bugzilla.suse.com/show_bug.cgi?id=1192194#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jshand2013(a)gmail.com, | |tiwai(a)suse.com Flags| |needinfo?(jshand2013@gmail. | |com) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Hm, this might be a stray irq after de-registering the HD-audio controller irq handler. Could you check what takes irq 40? Please check the contents of /proc/interrupts during playing some tone from the onboard audio. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192181] brightness keys mute mic instead (HP Elitebook 840 G6)
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192181 https://bugzilla.suse.com/show_bug.cgi?id=1192181#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Which input device handles the brightness keys? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192183] YaST2 internal error in forwardable.rb:227 'connected?' during "saving network configuration" step
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192183 Jos� Iv�n L�pez Gonz�lez <jlopez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED URL| |https://trello.com/c/JFzpno | |zm Assignee|yast2-maintainers(a)suse.de |yast-internal(a)suse.de -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192183] YaST2 internal error in forwardable.rb:227 'connected?' during "saving network configuration" step
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192183 https://bugzilla.suse.com/show_bug.cgi?id=1192183#c3 Jos� Iv�n L�pez Gonz�lez <jlopez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mfilka(a)suse.com), | |needinfo?(kanderssen(a)suse.c | |om) | --- Comment #3 from Jos� Iv�n L�pez Gonz�lez <jlopez(a)suse.com> --- Knut has confirmed the issue. Creating a trello card for it. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1188922] AUDIT-TRACKER: barrier: security report for Barrier networking logic
by bugzilla_noreply＠suse.com 02 Nov '21

02 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1188922 https://bugzilla.suse.com/show_bug.cgi?id=1188922#c13 --- Comment #13 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- I published the final report on oss-sec: https://www.openwall.com/lists/oss-security/2021/11/02/4 -- You are receiving this mail because: You are on the CC list for the bug.

1 0