October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1159231] New: tesseract-ocr builds with march=native
by bugzilla_noreply＠novell.com 18 Mar '23

18 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1159231 Bug ID: 1159231 Summary: tesseract-ocr builds with march=native Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Factory Status: NEW Severity: Major Priority: P5 - None Component: Development Assignee: idonmez(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de CC: hiwatari.seiji(a)gmail.com Found By: Development Blocker: --- While working on reproducible builds for openSUSE, I found that the tesseract-ocr package binary varies depending on build machine CPU. This is a bug that can cause crashes on machines older that the random build machine. -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1184786] New: Deduplicate directory ownership with filesystem package
by bugzilla_noreply＠suse.com 17 Mar '23

17 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1184786 Bug ID: 1184786 Summary: Deduplicate directory ownership with filesystem package Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, checksec pointed out that various directories in our /usr are 0755 while they're 0555 on Fedora and Red Hat. For more hardened environments this might make a difference, as it prevents a user "root" that doesn't have DAC_OVERRIDE permission to no longer write/create files there. In order to achieve that, only one package need to own the permissions of that directory. currently we have various packages co-owning it, which means actual permission would depend on installation order, and we'd get installation conflicts. This can be prevented by de-duplicating directory ownership. this is a tracker bug that tracks the work related to it. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1191381] New: gnu-compilers-hpc: Move rpm macros to %_rpmmacrodir
by bugzilla_noreply＠suse.com 16 Mar '23

16 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1191381 Bug ID: 1191381 Summary: gnu-compilers-hpc: Move rpm macros to %_rpmmacrodir Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: eich(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1191379 Found By: --- Blocker: --- rpm macros aren't config files for the administrator, as such they should be installed into %_rpmmacrodir (ie /usr/lib/rpm/macros.d) instead of /etc/rpm. Please consider adjusting gnu-compilers-hpc -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1175587] New: windows:mingw:win{32|64}/mingw{32|64}-filesystem: Deprecated external dependency generator is used
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1175587 Bug ID: 1175587 Summary: windows:mingw:win{32|64}/mingw{32|64}-filesystem: Deprecated external dependency generator is used Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: fstrba(a)suse.com Reporter: ralf.habacker(a)freenet.de QA Contact: screening-team-bugs(a)suse.de CC: fridrich.strba(a)bluewin.ch, hib(a)hiberis.nl, idonmez(a)suse.com, mkbosmans(a)gmail.com Found By: --- Blocker: --- On building packages there is always a message printed that a 'Deprecated external dependency generator is used'. The reason for this message is located in macros.mingw32 (https://build.opensuse.org/package/view_file/windows:mingw:win32/mingw32-fi…) %_mingw32_package_header \ %global __strip %{_mingw32_strip} \ %global __objdump %{_mingw32_objdump} \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{_mingw32_findrequires} \ %global __find_provides %{_mingw32_findprovides} \ %global __os_install_post %{_mingw32_install_post} by specifing '_use_internal_dependency_generator 0' and overriding the __find_requires and __find_provides. Recent obs dependency support uses *.attr file as shown below: cat /usr/lib/rpm/fileattrs/cmake.attr %__cmake_provides %{_rpmconfigdir}/cmake.prov %__cmake_path ^/usr/lib(64)?/cmake/.*/.*(Config\.cmake|-config\.cmake) where the mentioned file cmake.prov does the work of generating a list of packages that are provided by cmake configuration files. Similar files exists for debuginfo cat /usr/lib/rpm/fileattrs/debuginfo.attr %__debuginfo_provides %{_rpmconfigdir}/debuginfo.prov %__debuginfo_path ^/usr/lib/debug/ for pkgconfig files cat /usr/lib/rpm/fileattrs/pkgconfig.attr %__pkgconfig_provides %{_rpmconfigdir}/pkgconfigdeps.sh --provides %__pkgconfig_requires %{_rpmconfigdir}/pkgconfigdeps.sh --requires %__pkgconfig_path ^((%{_libdir}|%{_datadir})/pkgconfig/.*\.pc|%{_bindir}/pkg-config)$ for executables cat /usr/lib/rpm/fileattrs/elf.attr %__elf_provides %{_rpmconfigdir}/elfdeps --provides %{?__filter_GLIBC_PRIVATE:--filter-private} %__elf_requires %{_rpmconfigdir}/elfdeps --requires %{?__filter_GLIBC_PRIVATE:--filter-private} %__elf_magic ^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*executable %__elf_flags exeonly %__elf_exclude_path ^/usr/lib/debug/ for shared libraries cat /usr/lib/rpm/fileattrs/elflib.attr %__elflib_provides %{_rpmconfigdir}/elfdeps --assume-exec --provides %{?__filter_GLIBC_PRIVATE:--filter-private} %__elflib_requires %{_rpmconfigdir}/elfdeps --assume-exec --requires %{?__filter_GLIBC_PRIVATE:--filter-private} %__elflib_magic ^(setuid )?(setgid )?(sticky )?ELF (32|64)-bit.*shared object %__elflib_exclude_path ^/usr/lib/debug/ and others. To take advantage of this type of support, the currently used files mingw32-find-provides.sh and mingw32-find-requres.sh must be split into implementations that handle a single category of corresponding files. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1166537] New: osc rq accept - forwarding request causes backtrace
by bugzilla_noreply＠novell.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1166537 Bug ID: 1166537 Summary: osc rq accept - forwarding request causes backtrace Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: marco.strigl(a)suse.com Reporter: suse-beta(a)cboltz.de QA Contact: qa-bugs(a)suse.de CC: suse-tux(a)gmx.de Found By: --- Blocker: --- When accepting a SR to a devel project, osc asks if I want to forward the SR to Factory. I answered "y", but got this nice backtrace instead of a SR to Factory: # osc rq accept 784420 Result of change request state: ok openSUSE:Factory Forward this submit to it? ([y]/n)y Traceback (most recent call last): File "/usr/bin/osc", line 41, in <module> r = babysitter.run(osccli) File "/usr/lib/python3.8/site-packages/osc/babysitter.py", line 64, in run return prg.main(argv) File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 344, in main return self.cmd(args) File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 367, in cmd retval = self.onecmd(argv) File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 501, in onecmd return self._dispatch_cmd(handler, argv) File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 1232, in _dispatch_cmd return handler(argv[0], opts, *args) File "/usr/lib/python3.8/site-packages/osc/commandline.py", line 2652, in do_request project, package, html.escape(msg, quote=False)) NameError: name 'html' is not defined Wild guess: missing "import html"? Note: commandline.py has an "import html" in do_submitrequest(), but this import isn't visible to do_request(). Also note that there are more functions in this file that call html.escape() without importing html before and will probably break in a similar way. Doing the "import html" in the file header instead of inside the functions might be a good idea. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1176566] New: Installing ignition leads to unbootable system
by bugzilla_noreply＠suse.com 13 Mar '23

13 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1176566 Bug ID: 1176566 Summary: Installing ignition leads to unbootable system Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: rombert(a)apache.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've installed ignition locally on Tumbleweed, to be able to validate ignition files locally. After a reboot I was presented with an emergency shell, leading down a wild goose chase for disabling ignition permanently. It all went away after setting up a chroot and removing all traces of ignition, but it would be much much better if installing it would not lead to a broken system by default. I saw some errors related to the ignition generator, and the systemd unit file was broken, but could not save any logs unfortunately. But it should be easy enough to reproduce if anyone cares: # zypper in ignition # reboot (Might be related to #1172592) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1189826] New: Severe screen flickering with kernel 5.13.12-1-default and i915
by bugzilla_noreply＠suse.com 12 Mar '23

12 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1189826 Bug ID: 1189826 Summary: Severe screen flickering with kernel 5.13.12-1-default and i915 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: javier(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My laptop's screen flickers so much with 5.13.12 that it renders my laptop unusable. One workaround is to close and open the lid. After resuming, it works fine - there is no flickering. Booting up from the KDE Live image works fine. I have used the same Tumbleweed version (20210820) as the one I have installed on my laptop. The only difference is that I have an encrypted /home partition on my laptop's SSD. Tested kernels: 5.10.16-1.3: OK 5.11.4-1.3: NON-OK 5.12.12-1: NON-OK 5.13.12-1: NON-OK KDE Plasma 5.22.4 KDE Frameworks 5.85.0 Qt 5.15.2 See the attachments for more details. -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1084017] New: YaST in Leap 15 fails to set boot flags correctly
by bugzilla_noreply＠novell.com 10 Mar '23

10 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1084017 Bug ID: 1084017 Summary: YaST in Leap 15 fails to set boot flags correctly Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: Larry.Finger(a)lwfinger.net QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 762755 --> http://bugzilla.suse.com/attachment.cgi?id=762755&action=edit Compressed YaST2 logs My system has a GPT partitioning scheme and does not use EFI. I also put the boot block at the start of the active partition, and have generic boot code in the MBR. The active partition is indicated with the legacy_boot flag. A partial df for the system is: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 60213124 9954072 47170668 18% / /dev/sda6 53826316 32795236 20576144 62% /var/tmp /dev/sda7 51255784 20631016 28050216 43% /TW /dev/sda4 60344404 22760752 36522788 39% /Leap42.3 /dev/sda5 711705020 393141448 282387980 59% /home tmpfs 809360 20 809340 1% /run/user/1000 Looking at the partitions with parted: GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA Samsung SSD 850 (scsi) Disk /dev/sda: 1024GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 1049kB 9437kB 8389kB bios_grub 2 9437kB 16.8GB 16.8GB linux-swap(v1) swap 3 16.8GB 79.7GB 62.9GB ext4 4 79.7GB 143GB 62.9GB ext4 msftdata 5 143GB 883GB 741GB ext4 msftdata 6 883GB 939GB 56.1GB ext4 msftdata 8 939GB 971GB 31.5GB ext4 7 971GB 1024GB 53.5GB ext4 legacy_boot, msftdata (parted) quit In this case, partition number 7 will be booted. Running YaST => System => Boot Loader changes nothing. If I want the automatic boot to choose Leap 15.0, I need to manually toggle the legacy_boot flag on partitions 7 and 3. Attached is a compressed copy of the /var/log/YaST2/ directory. -- You are receiving this mail because: You are on the CC list for the bug.

2 15

[Bug 1027519] New: Xen: Missing upstream bug fixes
by bugzilla_noreply＠novell.com 09 Mar '23

09 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1027519 Bug ID: 1027519 Summary: Xen: Missing upstream bug fixes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xen Assignee: xen-bugs(a)suse.de Reporter: carnold(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There are upstream patches fixing bugs needed for this version of Xen. -- You are receiving this mail because: You are on the CC list for the bug.

2 293

[Bug 1048337] New: yast2-slide-show need to adjust the install path for new product builder
by bugzilla_noreply＠novell.com 08 Mar '23

08 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1048337 Bug ID: 1048337 Summary: yast2-slide-show need to adjust the install path for new product builder Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: mlin(a)suse.com QA Contact: jsrain(a)suse.com CC: adrian(a)suse.com Found By: --- Blocker: --- I've tested this in the staging project, I hot-patched yast2-slide-show then all files are located at /usr/lib/skelcd/CD1 for new product builder, since DATADIR is obsoleted already then new product builder doesn't have process those files. you can find testdvd build log at https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… so the main question: is product builder still support slideshow? if so where is the right path it should be? -- You are receiving this mail because: You are on the CC list for the bug.

2 8