August 2024 - openSUSE Bugs - openSUSE Mailing Lists

[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 1226194] New: Make JeOS images work with u-boot BOOTSTD
by bugzilla_noreply＠suse.com 27 Mar '25

27 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226194 Bug ID: 1226194 Summary: Make JeOS images work with u-boot BOOTSTD Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: mbrugger(a)suse.com Reporter: schwab(a)suse.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- U-Boot configurations that use CONFIG_BOOTSTD_DEFAULTS or CONFIG_BOOTSTD_FULL no longer find the device tree file on the disk (they pass on the builtin device tree instead). Either the patch 0001-XXX-openSUSE-XXX-Prepend-partition-.patch needs to be ported to BOOTSTD or the boot setup needs to be changed. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[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 1226525] New: Cockpit confusing behavior with performance profiles
by bugzilla_noreply＠suse.com 25 Mar '25

25 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226525 Bug ID: 1226525 Summary: Cockpit confusing behavior with performance profiles Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Cockpit Assignee: Cockpit-bugs(a)suse.de Reporter: robert.simai(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Fresh boot, log into Cockpit as regular user, see Overview, Configuration, "Performance profile: none". Mouse over "none" shows "Tuned is not running". All correct so far. Switch to administrative access, still it shows "Performance profile none" but isn't grayed out anymore. Click on that gives an error -->-- Change performance profile Danger alert:Server has closed the connection. -<-- which makes sense, as tuned is not running. But after clicking the error away the performance profile ("virtual-guest" in my installation) shows correctly and can be changed. Tuned is still disabled but now running, Cockpit magically started it. Changing the profile finally changes tuned to be enabled for system boot, again magically and without telling the admin. This is confusing. I suggest to change the error to something understandable, maybe along with adding something meaningful to the docs. -- 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 1226094] New: broken doc link to slemicro
by bugzilla_noreply＠suse.com 25 Mar '25

25 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226094 Bug ID: 1226094 Summary: broken doc link to slemicro Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Cockpit Assignee: Cockpit-bugs(a)suse.de Reporter: robert.simai(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- In current Cockpit (309) "Help", "Configure system settings" links to https://documentation.suse.com/smart/systems-management/html/cockpit-slemic… The link is broken (Sorry We could not find this page) and it overall isn't consistent to refer to SUSE product documentation from Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 1