January 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1133423] New: AutoYaST: repository priority not working in add-on section
by bugzilla_noreply＠novell.com 04 Jan '23

04 Jan '23

http://bugzilla.suse.com/show_bug.cgi?id=1133423 Bug ID: 1133423 Summary: AutoYaST: repository priority not working in add-on section Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: apoulat(a)vitechnology.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 803606 --> http://bugzilla.suse.com/attachment.cgi?id=803606&action=edit add-on.xml Hi, I've just seen that, for example with attached add-on.xml given to AutoYaST, with, as you can see one repository with priority 20 and another with priority 10, they both, after install, have a (default) 99 priority (checked with "zypper -lr -p" command). See documentation about that here: https://doc.opensuse.org/projects/autoyast/#idm139966593990112 Note: I'm not sure on how <product> and <product_dir> tags are relevant then I tried without them and there is still the same issue. Thanks -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1206758] xhci_hcd periodically not ready on resume
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206758 https://bugzilla.suse.com/show_bug.cgi?id=1206758#c13 --- Comment #13 from Pablo Sanchez <pablo(a)blueoakdb.com> --- Created attachment 863840 --> https://bugzilla.suse.com/attachment.cgi?id=863840&action=edit pcie_aspm=off test > dmesg output > Could you check with pcie_aspm=off boot option? Hi, Unfortunately this test didn't pan out. Previously, the phone would work on the first boot. With the test, it failed at first-boot. I'm attaching the output of dmesg. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197298] QEMU downstream patches break persistent binfmt registration by default
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1197298 https://bugzilla.suse.com/show_bug.cgi?id=1197298#c64 Dirk Mueller <dmueller(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #64 from Dirk Mueller <dmueller(a)suse.com> --- This has entered factory now, closing this one and filed https://bugzilla.suse.com/show_bug.cgi?id=1206838 for the followup issue caused by this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205768] New: Plasma Lockscreen and pam_u2f: Unlock needed for each monitor?
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1205768 Bug ID: 1205768 Summary: Plasma Lockscreen and pam_u2f: Unlock needed for each monitor? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: opensuse_buildservice(a)ojkastl.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, current openSUSE Tumbleweed on a X86_64 Laptop KDE Plasma (X11, not wayland) pam_u2f-1.2.1-1.2.x86_64 I am using pam_u2f to unlock my Plasma/KDE lock screen using a U2F device (the predecessor of FIDO). PAM configuration for sudo and sudo-i: ``` # etc/pam.d/sudo #%PAM-1.0 auth sufficient pam_u2f.so authfile=/etc/Yubico/u2f_keys cue [...] ``` PAM configuration for KDE unlocking (with openasuser, so it checks for the user that is logged in) ``` # /etc/pam.d/kde #%PAM-1.0 auth sufficient pam_u2f.so openasuser [...] ``` Works like a charm with sudo. Enter "sudo ls", the device starts blinking, I confirm and the command is executed. Works like a charm with the lockscreen, if the laptop is NOT connected to an external monitor. - plasma is locked - I move the mouse - the U2F device starts blinking - I touch the U2F device and confirm - the blinking stops - I get a "Entsperren" (Unlock) button instead of the password prompt on the lock screen - I press that button or hit ENTER - the screen is unlocked Works with two external monitors connected, but it seems I need to go through the "press U2F device and click the 'unlock' button" process for each monitor. In my case, three times. Sometimes it seems to be enough to just have 2 of each, however: Once should be enough. - plasma is locked - I move the mouse - the U2F device starts blinking - I touch the U2F device and confirm - the blinking stops - I get a "Entsperren" (Unlock) button instead of the password prompt on the lock screen - I press that button or hit ENTER - **the lock screen stays, the device starts blinking again** - I touch the U2F device and confirm - the blinking stops - I get a "Entsperren" (Unlock) button instead of the password prompt on the lock screen - I press that button or hit ENTER - **the lock screen stays, the device starts blinking again** - I touch the U2F device and confirm - the blinking stops - I get a "Entsperren" (Unlock) button instead of the password prompt on the lock screen - I press that button or hit ENTER - the screen is unlocked Not sure if there are any logs that I can provide? In case of questions, please reach out. Kind Regards, Johannes -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1185613] groff: .Os macro uses BSD as default
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1185613 https://bugzilla.suse.com/show_bug.cgi?id=1185613#c9 --- Comment #9 from Petr Gajdos <pgajdos(a)suse.com> --- s:Even:Even if: -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1185613] groff: .Os macro uses BSD as default
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1185613 https://bugzilla.suse.com/show_bug.cgi?id=1185613#c8 --- Comment #8 from Petr Gajdos <pgajdos(a)suse.com> --- (In reply to Petr Gajdos from comment #7) > (In reply to Ludwig Nussel from comment #5) > > Binary packages of an OBS project are reused in different products. So > > what's correct to display really depends on what we want. Code stream or > > actually installed product? Evaluating os-release at run time, ie implement > > in C code would show the actually installed product. > > Or even hard code it harder to s/BSD/SUSE/. Of course there can pop up Took this way and submitted: https://build.opensuse.org/request/show/1055783 > someone else with greater motivation to have $PRETTY_NAME in header/tailer > of few manual pages. Even this sounds ideal, yes, but in the course of almost two years none who would like to implement this feature appeared. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206774] dvb driver fails
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206774 https://bugzilla.suse.com/show_bug.cgi?id=1206774#c8 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #8 from Jiri Slaby <jslaby(a)suse.com> --- The TODO says: +The saa7146-based drivers are one of the few drivers still not using +the vb2 framework, so these drivers are now deprecated with the intent of +removing them altogether by the beginning of 2023. + +In order to keep these drivers they have to be converted to vb2. +If someone is interested in doing this work, then contact the +linux-media mailinglist (https://linuxtv.org/lists.php) So if there are no volunteers, the driver is going away. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206774] dvb driver fails
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206774 https://bugzilla.suse.com/show_bug.cgi?id=1206774#c7 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby(a)suse.com Flags|needinfo?(Gerhard@Dr-Lorbee | |r.de) | --- Comment #7 from Jiri Slaby <jslaby(a)suse.com> --- The driver was moved to staging and marked as deprecated by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206674] No network (wicked) after 23-12-2022 updates
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206674 https://bugzilla.suse.com/show_bug.cgi?id=1206674#c3 Andrei Borzenkov <arvidjaar(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar(a)gmail.com --- Comment #3 from Andrei Borzenkov <arvidjaar(a)gmail.com> --- (In reply to Alessandro Sturniolo from comment #0) > > Today (23-12-2022) I have updated my system, and after reboot (there was a > new kernel version), network no longer worked. > You updated from what snapshot exactly? What was the previous version of wicked? What packages were updated? I suspect the problem is not wicked (at least, directly) but missing event or notification. So the reason could be kernel or udev/systemd. It would be extremely helpful if you could identify what package exactly caused this regression. Get the list of packages that were updated; revert to previous snapshot; update each package individually and check whether you observe this problem. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206758] xhci_hcd periodically not ready on resume
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206758 https://bugzilla.suse.com/show_bug.cgi?id=1206758#c12 Oliver Neukum <oneukum(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #12 from Oliver Neukum <oneukum(a)suse.com> --- (In reply to Pablo Sanchez from comment #10) > (In reply to Oliver Neukum from comment #8) > > The failure you are seeing is on the PCI level. From your logs it is unclear > > whether the HC that fails to resume is hosting other busses. It is possible > > that it is just not resumed without a device. > > Hi, > > My work-around is to resume, *then* connect the device. Sorry, this probably needs a long explanation. From usbcore's viewpoint your roothub on the XHCI without any device connected to it will be in the state (suspended w. remote wakeup) after your system resumes that is the desired state of the root hub, too. So without devices if your system is suspended, no PM transitions will be done on the roothub. If, however, your system is connected to your phone, the roothub and the phone need to be in (active) before and after the system sleeps. So PM transitions are certainly done. My theory was that your system is generally incapable of a PM transition on the PCI level at that time. If that theory were true, your system should crash with any device that is in (active) attached and it should also crash if you artificially force the roothub into a PM transition on resume, which was my second suggestion. > > > Do you have other devices to test to make sure it is not specific to your > > phone? > > What an excellent idea. As my phone is a Samsung S21, non-root, I hadn't > thought it might be an issue. > > Using another phone (OnePlus Nord), it works. Please attach the output of "lsusb -v" in the working state with that second phone connected. > > Alternatively, if not, it would be necessary to set the "control" > > attribute for your root hub to "on". > > I think you're saying a work-around is for me to create a udev rule. No, that was for testing purposes only. Something is failing on the PCI level. You cannot fix that with a udev rule. So please test whether the fault is related to ASPM by doing Takashi's test. From your log: [26232.379255] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold to D0, device inaccessible [26232.457787] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold to D0, device inaccessible These must not happen. If they do, everything after that is as expected, though not as desired. Unfortunately everything before them is as it should be. Hence tests to determine the cause of this issue are needed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0