May 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1224402] New: /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-procfs.o: warning: objtool: nv_register_procfs() falls through to next function nv_unregister_procfs()
by bugzilla_noreply＠suse.com 02 Apr '25

02 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1224402 Bug ID: 1224402 Summary: /usr/src/kernel-modules/nvidia-390.157-default/nvidia/ nv-procfs.o: warning: objtool: nv_register_procfs() falls through to next function nv_unregister_procfs() Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Is this a bug in objtool? How would you even go about writing such function? -- You are receiving this mail because: You are on the CC list for the bug.

1 28

[Bug 1217749] New: No bass in built-in speakers on Lenovo Slim 7 16" AMD
by bugzilla_noreply＠suse.com 01 Apr '25

01 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1217749 Bug ID: 1217749 Summary: No bass in built-in speakers on Lenovo Slim 7 16" AMD Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: variable_valuables761(a)simplelogin.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 871116 --> https://bugzilla.suse.com/attachment.cgi?id=871116&action=edit Output of "hwinfo --sound" for Lenovo 16ARH7 It seems the bass speakers do not work in the latest Tumbleweed KDE snapshot on the Lenovo Slim 7 16" AMD, 16ARH7, 82UX0001US (and this same model is called Yoga outside the United States). This issue appears to be similar to that of the wide range of recently released laptops that have the CS35L41 and TAS2781 amps, however I cannot find that hardware listed in any of my logs or online spec sheets for this laptop. The closest I can find is that is has a Realtek ALC3287 codec. Attached is the output of "hwinfo --sound" Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1221378] New: Unable to create KIO worker (KDE X11)
by bugzilla_noreply＠suse.com 31 Mar '25

31 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1221378 Bug ID: 1221378 Summary: Unable to create KIO worker (KDE X11) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: wl(a)gnu.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After running `zypper up` a few minutes ago and doing a reboot the desktop greets me with ``` Unable to create KIO worker. Can not create a socket for launching a KIO worker for protokol 'desktop'. ``` and no icons are displayed. I have no idea what is causing this... The following updates were installed: ``` kernel-default 5.14.21-150500.55.52.1 libmaxminddb0 1.4.3-150000.1.8.1 libmetalink3 0.1.3-150000.3.2.1 libqrencode4 4.1.1-150000.3.3.1 libuv1 1.44.2-150500.3.2.1 x86_64 python3-bind 9.16.48-150500.8.18.1 kernel-default-extra 5.14.21-150500.55.52.1 wget 1.20.3-150000.3.17.1 x86_64 bind-utils 9.16.48-150500.8.18.1 kernel-default-optional 5.14.21-150500.55.52.1 wget-lang 1.20.3-150000.3.17.1 glibc 2.31-150300.68.1 glibc-extra 2.31-150300.68.1 glibc-info 2.31-150300.68.1 yast2-logs 4.5.26-150500.3.3.2 sudo 1.9.12p1-150500.7.10.1 sudo-plugin-python 1.9.12p1-150500.7.10.1 nscd 2.31-150300.68.1 glibc-locale-base 2.31-150300.68.1 glibc-lang 2.31-150300.68.1 glibc-devel 2.31-150300.68.1 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1214364] New: net-snmp: new release 5.9.4
by bugzilla_noreply＠suse.com 31 Mar '25

31 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1214364 Bug ID: 1214364 Summary: net-snmp: new release 5.9.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: abergmann(a)suse.com Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- https://github.com/net-snmp/net-snmp/blob/v5.9.4/CHANGES *5.9.4*: IMPORTANT: SNMP over TLS and/or DTLS are not functioning properly in this release with various versions of OpenSSL and will be fixed in a future release. libsnmp: - Remove the SNMP_SWIPE_MEM() macro Remove this macro since it is not used in the Net-SNMP code base. - DISPLAY-HINT fixes - Miscellanious improvements to the transports - Handle multiple oldEngineID configuration lines - fixes for DNS names longer than 63 characters agent: - Added a ignoremount configuration option for the HOST-MIB - disallow SETs with a NULL varbind - fix the --enable-minimalist build apps: - snmpset: allow SET with NULL varbind for testing - snmptrapd: improved MySQL logging code general: - configure: Remove -Wno-deprecated as it is no longer needed - miscellanious ther bug fixes, build fixes and cleanups -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1219011] New: cannot specify which multibuild package flavors to use for build in package metadata
by bugzilla_noreply＠suse.com 26 Mar '25

26 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1219011 Bug ID: 1219011 Summary: cannot specify which multibuild package flavors to use for build in package metadata Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: backend Assignee: mls(a)suse.com Reporter: msuchanek(a)suse.com QA Contact: adrian.schroeter(a)suse.com CC: adrian.schroeter(a)suse.com, mls(a)suse.com Depends on: 1219005 Blocks: 1211226, 1218184 Target Milestone: --- Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1219005 +++ For some packages a number of different builds uses the same source. For consistency and efficiency it is required to upload the sources only once, and run multiple builds against the same sources. Historically this has been done by package links: The sources would be uploaded with a number of spec files, and a number of package links created. Because OBS selects the spec file to build based on container name the different package links would build different spec files. In other ways these package links appear as any other build containers. In particular, it's possible to select in what repositories (if any) the individual spec files should be used for build in the package container metadata. There is a push to convert these packages to use multibuild instead. With multibuild a _multibuild file is created that lists the spec files to build but only one package container is created in which all these spec files are built. That results in only one container metadata, and inability to specify which packages to use for build. https://github.com/openSUSE/open-build-service/issues/3574 This is important functionality for development of core packages. The kernel is used for building the kernel, binutils are used for building binutils, etc. When a broken version of such core package is uploaded into a develproject the develproject breaks, and will no longer produce any binaries. The answer is 'You can wipe binaries', and that's clearly the case. The kernel is uploaded using a custom script, and it does wipe the binaries as part of the upload. In this particular case it's also not particularly disruptive because the package that can break the build is also fast to rebuild. That is not the case with all packages. Wiping the binaries can be forgotten if done by hand, and then it will. Wiping the binaries always might be disruptive for some packages. The other option is to use some sort of bootstrap project setup. The release projects do use the various ring projects, and some toolchains bootstrap in quite elaborate ways because that's required for those particular packages. What these bootstrap setups have in common is that they are each one of a kind, very hard to understand for people who are not experts on OBS, and very fiddly. For some packages the 'use for build' flag was enough for setting up a project that can continuously build binaries as the developers upload changes, without breaking when a broken version is uploaded, without using special tools. Given that people working on toolchain or kernel are experts in that area and not necessarily on OBS project setup this feature is valuable for streamlining development of these core packages. Given that these core packages also typically use multiple spec files with one source file the 'use for build' is not longer available with multibuild, nor is any replacement. Clearly, having streamlined, standardized, and well-documented bootstrap project setup would also help, and solve the problem even for the cases where 'use for build' is not sufficient. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1219107] New: Migrate away from update-alternatives (phase 1)
by bugzilla_noreply＠suse.com 26 Mar '25

26 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1219107 Bug ID: 1219107 Summary: Migrate away from update-alternatives (phase 1) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: martin.schreiner(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Following the mailing list thread: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… And the summarised view of the discussion, as presented on the Wiki: https://en.opensuse.org/openSUSE:Update-alternatives_migration We'd like to keep pushing for libalternatives to be adopted, replacing update-alternatives where feasible, leaving the door open for certain packages to use Conflicts and/or systemd units where applicable. This will have to be considered on a case-by-case basis, but for the majority of packages, libalternatives should work just fine, as it supports setting default binaries and manpages tied to a particular alternative choice. I therefore propose the following: Phase 1) We identify common packaging patterns regarding the update-alternatives -> libalternatives migration. For instance, some packages are fairly straightforward, and do not require regular files to be changed based on an alternative setting. They may not even provide different manpages. Some packages do provide different manpages based on a given alternative. And some packages provide different arbitrary files based on alternative. We'll document and provide examples on OBS/IBS as to how these should be handled. Phase 2) We communicate. Word needs to get out. Everyone doing packaging should be aware that update-alternatives is being slowly phased out. Labs Conference may be a good place to spread the word. We also need to let our users know what's going on. The Tumbleweed announcement blog, the mailing list, even Reddit, all of these could play a role. We'll explain our rationale and try to prevent any backlash from the community. If anyone provides valuable feedback, we'll approach carefully, openly, always keeping the project's best interest at heart. Phase 3) We make ourselves available. Should anyone need help, or any particularly tricky migration require our help, we can be counted on. When I say "we", I mean any developer who's interested in this migration and is willing to help our efforts. Of course the Pack team plays a special role, but anyone interested is more than welcome to be a part of this. This is a sizable change. We need to stick together. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1219005] New: cannot specify which multibuild package flavors to build in package metadata
by bugzilla_noreply＠suse.com 25 Mar '25

25 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1219005 Bug ID: 1219005 Summary: cannot specify which multibuild package flavors to build in package metadata Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: backend Assignee: mls(a)suse.com Reporter: msuchanek(a)suse.com QA Contact: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- For some packages a number of different builds uses the same source. For consistency and efficiency it is required to upload the sources only once, and run multiple builds against the same sources. Historically this has been done by package links: The sources would be uploaded with a number of spec files, and a number of package links created. Because OBS selects the spec file to build based on container name the different package links would build different spec files. In other ways these package links appear as any other build containers. In particular, it's possible to select in what repositories (if any) the individual spec files should be built in the package container metadata. There is a push to convert these packages to use multibuild instead. With multibuild a _multibuild file is created that lists the spec files to build but only one package container is created in which all these spec files are built. That results in only one container metadata, and inability to specify which spec file to build in which repository. https://github.com/openSUSE/open-build-service/issues/3574 This is important functionality for package development. The kernel uses this functionality to set up multiple repositories in the development project and select which spec file to build in which repository. That makes it possible to test kernel builds without breaking the project when the kernel fails to boot on the OBS builder. For both kernel and other packages that build a number of configurations this is important for people that want to branch the package and only build/change a specific configuration. Currently kernel and u-boot use different hacks to workaround this deficiency in OBS multibuild support, some packages completely give up on controlling which individual configurations to build. That means users that branch these multibuild packages have to read the package sources to find out how to select which configuration to build if the option is provided at all. There is no standardized and documented way to do it. Some workarounds have been proposed. The obvious one is to change the _multibuild file but that results in changing the package sources, it becomes a different package then. All already built configurations are rebuilt after the change. The source change is likely to cause package breaks because OBS is very bad at resolving updates to modified packages. Another option are build flags in project config. onlybuild/excludebuild flags can be used to (de)select some configurations. However, the project config is inherited, and so are these flags. Building against a project that already (de)selected some configuration (de)selects same configurations for the branched package, and this cannot be changed. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1218998] New: cannot abort build/restart build/wipe binaries for multibuild packages
by bugzilla_noreply＠suse.com 25 Mar '25

25 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1218998 Bug ID: 1218998 Summary: cannot abort build/restart build/wipe binaries for multibuild packages Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: webui Assignee: hvogel(a)suse.com Reporter: msuchanek(a)suse.com QA Contact: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- The Abort build/Restart build/wipe binaries buttons don't work in the web UI https://github.com/openSUSE/open-build-service/issues/12913 https://github.com/openSUSE/open-build-service/issues/7866 https://github.com/openSUSE/open-build-service/issues/7156 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1216083] New: cockpit-ws: theme QA
by bugzilla_noreply＠suse.com 25 Mar '25

25 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1216083 Bug ID: 1216083 Summary: cockpit-ws: theme QA Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: Cockpit-bugs(a)suse.de Reporter: amajer(a)suse.com QA Contact: qa-bugs(a)suse.de CC: Cockpit-bugs(a)suse.de, qa-bugs(a)suse.de Depends on: 1216082 Target Milestone: --- Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1216082 +++ We should add openQA test for basic theme and login -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1217424] New: node-gyp 21 errors out with SyntaxError
by bugzilla_noreply＠suse.com 21 Mar '25

21 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1217424 Bug ID: 1217424 Summary: node-gyp 21 errors out with SyntaxError Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: brunopitrus(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After Tumbleweed upgraded to node 21.2.0, the vscode RPM started failing to build with the following error: [ 258s] Traceback (most recent call last): [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/gyp_main.py", line 45, in <module> [ 258s] sys.exit(gyp.script_main()) [ 258s] ^^^^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 688, in script_main [ 258s] return main(sys.argv[1:]) [ 258s] ^^^^^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 680, in main [ 258s] return gyp_main(args) [ 258s] ^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 647, in gyp_main [ 258s] [generator, flat_list, targets, data] = Load( [ 258s] ^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 157, in Load [ 258s] result = gyp.input.Load( [ 258s] ^^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/input.py", line 2987, in Load [ 258s] LoadTargetBuildFile( [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/input.py", line 400, in LoadTargetBuildFile [ 258s] build_file_data = LoadOneBuildFile( [ 258s] ^^^^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/pylib/gyp/input.py", line 237, in LoadOneBuildFile [ 258s] build_file_data = eval(build_file_contents, {"__builtins__": {}}, None) [ 258s] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 258s] File "/usr/lib64/node_modules/npm21/node_modules/node-gyp/gyp/gyp_main.py", line 7 [ 258s] import os [ 258s] ^^^^^^ [ 258s] SyntaxError: invalid syntax see full build log at https://build.opensuse.org/package/live_build_log/devel:tools:ide:vscode/co… This is a regression from nodejs 21.1.0. -- You are receiving this mail because: You are on the CC list for the bug.

1 3