August 2024 - openSUSE Bugs - openSUSE Mailing Lists

[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

[Bug 1220571] New: [META] Packages failing because GCC 14+ treats some warnings as errors
by bugzilla_noreply＠suse.com 21 Mar '25

21 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1220571 Bug ID: 1220571 Summary: [META] Packages failing because GCC 14+ treats some warnings as errors Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: mjambor(a)suse.com Reporter: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- GCC 14 treats the following situations, which were only warnings before, as errors: -Werror=implicit-int -Werror=implicit-function-declaration -Werror=declaration-missing-parameter-type -Werror=return-mismatch -Werror=int-conversion -Werror=incompatible-pointer-types More details about all of these cases together with the most common ways of addressing them and some associated pitfalls is available at https://gcc.gnu.org/gcc-14/porting_to.html For the record, clang has taken a similar step since clang 16, see for example https://www.redhat.com/en/blog/new-warnings-and-errors-clang-16 The preferred method of dealing with these issues is of course fixing the code. Other distributions have shared patches from their porting efforts on relevant upstream mailing lists and bug trackers, Gentoo and RedHat are perhaps most active in this regard, so you can have a look at what they did for their packages at: - https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=0 - https://gitlab.com/fweimer-rh/fedora-modernc/ In case there is for some reason not possible to fix the code, or at least to fix it in time for adoption of GCC 14, it is possible to turn these back to warnings by adding to the compiler options one of the following: -std=gnu89, -std=c89, or -fpermissive. (Especially if you use -fpermissive as a temporary workaround with intention to fix the underlying issues later, I'd suggest leaving the particular bug opened until it is done so.) -- You are receiving this mail because: You are on the CC list for the bug.

1 116

[Bug 1228342] New: Package texlive does not build with gcc 14 on i586 because of use of incompatible pointer types
by bugzilla_noreply＠suse.com 21 Mar '25

21 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1228342 Bug ID: 1228342 Summary: Package texlive does not build with gcc 14 on i586 because of use of incompatible pointer types 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: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de CC: werner(a)suse.com Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- Package texlive fails to build with GCC 14 on i586 (and probably othr 32bit architectures too) because of various C99 violations which previously just generated warning s but which cause errors with GCC 14 by default (see meta bug#1220571). The (first) problem stopping the build is: pdftexini.c: In function 'loadfmtfile': pdftexini.c:4016:25: error: assignment to 'boolean *' {aka 'int *'} from incompatible pointer type 'internalfontnumber ' {aka 'long int *'} [-Wincompatible-pointer-types] 4016 | pdffonthasspacechar = xmallocarray ( internalfontnumber , fontmax ) ; | ^ pdftexini.c: In function 'mainbody': pdftexini.c:5569:27: error: assignment to 'boolean *' {aka 'int *'} from incompatible pointer type 'internalfontnumber ' {aka 'long int *'} [-Wincompatible-pointer-types] 5569 | pdffonthasspacechar = xmallocarray ( internalfontnumber , fontmax ) ; | ^ so IIUC double the necessary size is allocated rater than just half but it looks like a genuine type issue. We can work-around the issue by building with -Wno-error=incompatible-pointer-types (on 32 bit architectures) but it is always better to fix these issues. I admit that so far I am super puzzled where the file texk/web2c/pdftexini.c comes from (or rather how it is generated?) so I'd be grateful if someone who knows the package better looked at this. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1225965] New: Improve KDE Discover bug reporting button
by bugzilla_noreply＠suse.com 20 Mar '25

20 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1225965 Bug ID: 1225965 Summary: Improve KDE Discover bug reporting button Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: shundhammer(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Whenever we have a generic package issues that affects multiple users like (bug 1225174), we get a whole to of bug reports and duplicates. All that users seem to be doing is copy the text "<html>Dependency resolution failed:<br/><br/>[...] </html>", report a bug in a random component. Bonus: If the component is YaST, Huha gets angry like in bug 1225949. We do not see the bugs that were not reported due to bugzilla pointing out the possible duplicate, but in the example above we got 14 reports. These users may or may not have read through the duplicated bug, or read the recommendation there. https://github.com/KDE/discover/blob/d644b2a1000c04f084d39a4ef8a3402abf6417… Let's improve user experience here. Some ideas: 0. Direct the user to zypper/YaST for self-service resolution of the conflict. 1. Direct the user to a landing page with instructions for #0. 2. Direct the user to bugzilla search first 3. Take the message - extract package names only, strip arch/installed version, sort, and make a hash from it. Use that as the bug alias for automatic reduplication. 4. or even a fuzzy hash 5. Use a bugzilla whiteboard field with self-service fix instructions -- You are receiving this mail because: You are on the CC list for the bug.

1 33

[Bug 1226194] New: Make JeOS images work with u-boot BOOTSTD
by bugzilla_noreply＠suse.com 20 Mar '25

20 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 10

[Bug 1229450] New: libbpf: failed to find '.BTF' ELF section in vmlinux
by bugzilla_noreply＠suse.com 19 Mar '25

19 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1229450 Bug ID: 1229450 Summary: libbpf: failed to find '.BTF' ELF section in vmlinux Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876820 --> https://bugzilla.suse.com/attachment.cgi?id=876820&action=edit Devel:Kernel:master/kernel-source:kernel-vanilla/LEGACYX86/i586 build log The kernel builds result in random build failures while creating BTF. For example https://build.opensuse.org/package/live_build_log/Kernel:vanilla/kernel-sou…: > libbpf: failed to find '.BTF' ELF section in vmlinux > FAILED: load BTF from vmlinux: No data available > make[2]: *** [../scripts/Makefile.vmlinux:34: vmlinux] Error 255 > make[2]: *** Deleting file 'vmlinux' > make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-vanilla-6.11~rc3.338.gc3f2d783a459/linux-6.11-rc3-338-gc3f2d783a459/Makefile:1158: vmlinux] Error 2 > make: *** [../Makefile:224: __sub-make] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.olf5Nu (%build) arm seems to fail reliably. But for example in ibs://Devel:Kernel:master/kernel-source:kernel-vanilla/LEGACYX86/i586, it looks like it is sort of random. kernel-debug and kernel-vanilla fails for i586, but -default and -pae are built currently. See the job history for kernel-vanilla in there (the failed boot log is attached): > time package reason code build time worker > 2024-07-15 07:41:48 kernel-source:kernel-vanilla source change succeeded 47m 53s h01-ch5a:3 > 2024-07-15 23:56:48 kernel-source:kernel-vanilla source change succeeded 47m 57s h01-ch5b:5 > 2024-07-18 11:12:40 kernel-source:kernel-vanilla source change succeeded 48m 46s h01-ch5b:2 > 2024-07-26 20:01:29 kernel-source:kernel-vanilla source change succeeded 52m 40s h01-ch4b:2 > 2024-07-29 09:07:35 kernel-source:kernel-vanilla source change succeeded 52m 53s h01-ch4a:6 > 2024-08-03 11:38:55 kernel-source:kernel-vanilla source change failed 25m 16s h01-ch4b:8 > 2024-08-04 23:48:15 kernel-source:kernel-vanilla source change failed 25m 14s h01-ch4b:7 > 2024-08-06 16:37:35 kernel-source:kernel-vanilla source change succeeded 53m 25s h01-ch4b:4 > 2024-08-09 19:44:44 kernel-source:kernel-vanilla source change failed 26m 4s h01-ch5a:2 > 2024-08-11 22:48:56 kernel-source:kernel-vanilla source change failed 0m 38s h01-ch4b:6 > 2024-08-12 16:44:52 kernel-source:kernel-vanilla source change succeeded 54m 0s h01-ch5b:5 > 2024-08-15 21:49:11 kernel-source:kernel-vanilla source change failed 25m 25s h01-ch4b:1 > 2024-08-19 01:53:01 kernel-source:kernel-vanilla source change succeeded 50m 9s h01-ch4a:5 > 2024-08-19 11:33:50 kernel-source:kernel-vanilla source change succeeded 55m 9s h01-ch5b:1 > 2024-08-19 17:23:59 kernel-source:kernel-vanilla source change failed 25m 16s h01-ch5a:3 -- You are receiving this mail because: You are on the CC list for the bug.

1 38

[Bug 1222192] New: Package description for cadvisor shows trivy
by bugzilla_noreply＠suse.com 17 Mar '25

17 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222192 Bug ID: 1222192 Summary: Package description for cadvisor shows trivy Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: holdenrf2021(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Also shows on https://software.opensuse.org/package/cadvisor $ sudo zypper if trivy cadvisor [sudo] password for root: Loading repository data... Reading installed packages... Information for package trivy: ------------------------------ Repository : Main Repository (OSS) Name : trivy Version : 0.49.1-1.2 Arch : x86_64 Vendor : openSUSE Installed Size : 274.2 MiB Installed : No Status : not installed Source package : trivy-0.49.1-1.2.src Upstream URL : https://github.com/aquasecurity/trivy Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. Information for package cadvisor: --------------------------------- Repository : Main Repository (OSS) Name : cadvisor Version : 0.46.0-1.8 Arch : x86_64 Vendor : openSUSE Installed Size : 29.9 MiB Installed : No Status : not installed Source package : cadvisor-0.46.0-1.8.src Upstream URL : https://github.com/google/cadvisor Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1226207] New: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226207 Bug ID: 1226207 Summary: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light 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: w01dnick(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- kf6-breeze-icons generate identical icons for both breeze & breeze-dark. While this is not an issue for KF6 apps, that use run-time recoloring, in KF5 apps, like Krusader, when dark color theme is used and icons are breeze-dark symbolic icons are dark on dark background and almost invisible. The reason is this build option: `-DWITH_ICON_GENERATION:BOOL=FALSE` I've tried to make my custom build [1] switching it to TRUE and breeze-dark icons are fine with Krusader now. But I don't know the reasoning behind switching it to FALSE. There is comment: ``` saves ~30MB and installs dangling symlinks ``` Less size is true, though IMHO it's not a good solution to break KF5 apps to save some space. But I can't see any dangling symlinks: ``` find /usr/share/icons/breeze{,-dark} -xtype l ``` doesn't find anything. Any other reason or should I cleanup [1] and make a submit request? [1] https://build.opensuse.org/package/show/home:NickLion:branches:KDE:Framewor… -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1229338] New: ffmpeg fails to build on 32bit arm
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1229338 Bug ID: 1229338 Summary: ffmpeg fails to build on 32bit arm Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/4414868/modules/star t_install/steps/3 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ffmpeg-6 and ffmpeg-7 fail to build on armv6hl as well as armv7hl, turning desktops uninstallable. This patch should fix it: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=654bd47716c4f36719fb0f3f7f… ## Observation openQA test in scenario opensuse-Tumbleweed-NET-arm-install_only@aarch32 fails in [start_install](https://openqa.opensuse.org/tests/4414868/modules/start_inst… ## Test suite description set HDDSIZE=40 as required for ppc64le (failed w/o it on https://openqa.opensuse.org/tests/390330#step/install_and_reboot/21 ## Reproducible Fails since (at least) Build [20240524](https://openqa.opensuse.org/tests/4222103) ## Expected result Last good: [20240523](https://openqa.opensuse.org/tests/4218706) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=arm&distri=opensuse&f… -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1215945] New: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed)
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1215945 Bug ID: 1215945 Summary: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Keywords: build Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: burnus(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: jengelh(a)inai.de Target Milestone: --- Found By: --- Blocker: --- GNU Binutils 2.41 now reveals a bug in the 'asm' code used in ffmpeg-4: ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' While Binutils is pending for opensuse:factory, the new version has already landed in 15.4 and 15.5 such that ffmpeg-4 fails there: https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 ffmpeg-5/6 seemingly got the fix as I do see no fails for 15.4/15.5 for the build of the 4h old package. Upstream FIX: "Fixes assembling with binutil as >= 2.41" at https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/effadce6c756247ea8bae32… See also https://trac.ffmpeg.org/ticket/10405 or (where I found it): The pending Binutils update for openSUSE:factory update is: https://build.opensuse.org/request/show/1113885 -- You are receiving this mail because: You are on the CC list for the bug.

1 3