April 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 989284] New: KIWI images broken due to e2fsprogs update for U-Boot based boot, uses "64bit" feature
by bugzilla_noreply＠novell.com 12 Oct '21

12 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=989284 Bug ID: 989284 Summary: KIWI images broken due to e2fsprogs update for U-Boot based boot, uses "64bit" feature Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: stefan.bruens(a)rwth-aachen.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- e2fsprogs-1.43 adds the "64bit" feature for ext4 filesystems. KIWI uses the default features from /etc/mke2fs.conf U-Boot does not support ext4 with enabled 64bit feature. Thus this affects any system using U-Boot which stores kernel and initrd on the root filesystem. (e.g. rpi3 uses a seperate ext3 /boot partition, Pine64 uses the ext4 / root filesystem) The issue can be worked around by e.g.: "tune2fs -O ^64bit /dev/sdc2; e2fsck -y /dev/sdc2; resize2fs -s /dev/sdc2" assuming sdc2 is the root filesystem partition on the SD card. Affected image: e.g. http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Pin… -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1086757] New: Images for Raspberry Pi 1/2/3 does not boot - only Splash Screen Rainbow
by bugzilla_noreply＠novell.com 12 Oct '21

12 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1086757 Bug ID: 1086757 Summary: Images for Raspberry Pi 1/2/3 does not boot - only Splash Screen Rainbow Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: kasimir_(a)outlook.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have tried the current images [1] of the Raspberry Pi 1/2/3 and get only the Splash Screen Rainbow. No messages are output through the serial console. [1] RPi1: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2018.03.25-Build1.1.raw.xz RPi2: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2018.03.25-Build1.1.raw.xz RPi3: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.03.25-Build1.1.raw.xz -- You are receiving this mail because: You are on the CC list for the bug.

2 10

[Bug 1073820] New: meson fails to build projects when run under the fish shell
by bugzilla_noreply＠novell.com 11 Oct '21

11 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1073820 Bug ID: 1073820 Summary: meson fails to build projects when run under the fish shell Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: sor.alexei(a)meowr.ru Reporter: simonf.lees(a)suse.com QA Contact: opensuse-communityscreening(a)forge.provo.novell.com CC: pth(a)suse.com, sbrabec(a)suse.com Found By: --- Blocker: --- I have my shell set to /usr/bin/fish and meson fails to detect gcc properly, if I switch to bash then the project builds fine, i've seen this on multiple projects when building under tumbleweed. simon@tek-top ~/src/build/wireless ➤ meson build The Meson build system Version: 0.43.0 Source dir: /home/simon/src/build/wireless Build dir: /home/simon/src/build/wireless/build Build type: native build Project name: wireless Meson encountered an error in file meson.build, line 1, column 0: Unable to detect GNU compiler type: cc: error trying to exec 'cc1': execvp: No such file or directory A full log can be found at /home/simon/src/build/wireless/build/meson-logs/meson-log.txt -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 930505] New: every package available in standard or optional repos is not discoverable via https://software.opensuse.org/search
by bugzilla_noreply＠novell.com 06 Oct '21

06 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=930505 Bug ID: 930505 Summary: every package available in standard or optional repos is not discoverable via https://software.opensuse.org/search Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Infrastructure Assignee: mrueckert(a)suse.com Reporter: mrmazda(a)earthlink.net QA Contact: lrupp(a)suse.com Found By: --- Blocker: --- mc is the package name and binary executable for the best available file manager in openSUSE repos. Latest Midnight Commander (mc) not discoverable via https://software.opensuse.org/search . Until recently, current mc for 13.1 could be found on http://download.opensuse.org/repositories/Base:/System/openSUSE_13.2/ but this repo has been retired. Searching https://software.opensuse.org/search for search term commander produces no hits for Midnight Commander or mc. Search term mc is not acceptable to https://software.opensuse.org/search, as it rejects two character search strings, first by announcement, then when proceeding anyway, searching for mc only as a substring, listing many packages containing string mc but not mc itself. I tried searching for latest mc on https://build.opensuse.org/search but as I am not a builder I found it too difficult to use to locate latest (mc-4.8.14) even with help from irc://freenode/opensuse-factory. Something needs to be done so that every package that exists in standard or BS repos can be discovered via https://software.opensuse.org/search without the degree of difficulty searching for Midnight Commander presents. -- You are receiving this mail because: You are on the CC list for the bug.

2 11

[Bug 1090355] New: GCC 8: qemu build fails
by bugzilla_noreply＠novell.com 04 Oct '21

04 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1090355 Bug ID: 1090355 Summary: GCC 8: qemu build fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- [ 1107s] In function 'process_section', [ 1107s] inlined from 'elf2pe.isra.4' at util/elf2efi.c:909:25: [ 1107s] util/elf2efi.c:494:2: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation] [ 1107s] strncpy ( ( char * ) new->hdr.Name, name, sizeof ( new->hdr.Name ) ); [ 1107s] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Seen here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1003226] New: Slow loading/page construction
by bugzilla_noreply＠novell.com 03 Oct '21

03 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1003226 Bug ID: 1003226 Summary: Slow loading/page construction Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: matthias(a)mailaender.name QA Contact: adrian(a)suse.com Found By: --- Blocker: --- I already reported my dashboard loading extremely slow https://github.com/openSUSE/open-build-service/issues/2086 which seems to be strengthened by my activity as I have 3 pages full of open requests submitted to Factory or devel project awaiting peer review from maintainers. How since a few weeks the whole website became super slow. Viewing regular package pages or repository enable/disable sites, which I usually quickly click to avoid redundant rebuilds. See also https://github.com/openSUSE/open-build-service/issues/586 I usually only branch or create packages via the web interface and use osc with local builds and only commit stuff that works. But with the current response time it is far too tedious. Pages take several minutes to load for me. Tested on multiple V-DSL connections at various day times. It seems to be a fundamental problem that has gotten worse lately. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 952288] New: Find a way to set Adwaita as systemwide icon theme when installing GNOME DE
by bugzilla_noreply＠novell.com 28 Sep '21

28 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=952288 Bug ID: 952288 Summary: Find a way to set Adwaita as systemwide icon theme when installing GNOME DE Classification: openSUSE Product: openSUSE Factory Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: zaitor(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- As of today, any user installing GNOME as DE will still end up with DMZ set as system cursor instead of Adwaita. (do a grep X_MOUSE_CURSOR /etc/sysconfig/windowmanager on your boxes). Now this is only noticed when users open up yast (and possibly odd 3'rd party apps) It's rather visually unpleasing, and something we should look into fixing. The easiest thing to do would probably be to add it to one of our branding packages, or even create a new one if needed. Ideally we should offer a "system option" in tweak tool, but that will probably be a lot of work. Patches/fixes welcome everyone. -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 970624] New: Package Request: RetroFE
by bugzilla_noreply＠novell.com 28 Sep '21

28 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=970624 Bug ID: 970624 Summary: Package Request: RetroFE Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: zombie_ryushu(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I request that RetroFE be Packaged for SUSE. Sources can be found here. http://www.retrofe.com/download.php -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1069468] New: Packages should no longer use /var/adm/fillup-templates
by bugzilla_noreply＠novell.com 27 Sep '21

27 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1069468 Bug ID: 1069468 Summary: Packages should no longer use /var/adm/fillup-templates Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: CONFIRMED Severity: Major Priority: P5 - None Component: Other Assignee: rbrown(a)suse.com Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 749776 --> http://bugzilla.opensuse.org/attachment.cgi?id=749776&action=edit fillup-templates list As discussed on the opensuse-packaging list there are significant problems with fillup-templates being located in /var/adm https://lists.opensuse.org/opensuse-packaging/2017-11/msg00017.html At time of writing, rpm in Tumbleweed now has support for a new rpm macro (%_fillupdir) which should be used instead to relocate the fillup templates to the new location of /usr/share/fillup-templates https://en.opensuse.org/index.php?title=openSUSE:Packaging_Conventions_RPM_… Any unchanged packages should be okay, as the rpm package's other macros that consume fillup-templates support both the old and new path. However to enable us to tidy up the /var subvolumes in all *SUSE distributions we to change all the packages to use the new path There are over 200 packages in Factory that currently use the old convention (List attached) I am working initially on the packages needed by CaaSP/Kubic, with my intention being to either do the rest soon after or ask the community to help with the rest. This bug is therefore a reference for all of these efforts -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1063638] New: btrfs balance renders system unresponsive and eventually even kills WiFi when quota is enabled - review I/O scheduling parameters of btrfsmaintenance
by bugzilla_noreply＠novell.com 23 Sep '21

23 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1063638 Bug ID: 1063638 Summary: btrfs balance renders system unresponsive and eventually even kills WiFi when quota is enabled - review I/O scheduling parameters of btrfsmaintenance Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de CC: Antoine.Saroufim(a)gmail.com, aschnell(a)suse.com, auxsvr(a)gmail.com, dmitry(a)roshchin.org, dsterba(a)suse.com, ecsos(a)schirra.net, enadolski(a)suse.com, fcrozat(a)suse.com, fliu(a)suse.com, friedhelm.stappert(a)web.de, guenther(a)mpanrw.de, gweberbh(a)gmail.com, hannsj_uhl(a)de.ibm.com, harald.achitz(a)gmail.com, ingo.goeppert+suse(a)mailbox.org, jeffm(a)suse.com, kdejaeger(a)gmail.com, lnussel(a)suse.com, lpechacek(a)suse.com, ndcunliffe(a)gmail.com, okurz(a)suse.com, ortsacs(a)yahoo.es, rgoldwyn(a)suse.com, richard(a)nod.at, ronisbr(a)gmail.com, slindomansilla(a)suse.com, suse(a)bugs.jan.ritzerfeld.org, sven.heithecker(a)web.de, t.rother(a)netzwissen.de, tneo(a)gmx.com, ulrich.hobelmann+suse(a)gmail.com Depends on: 1017461 Found By: --- Blocker: --- ## Observation +++ This bug was initially created as a clone of Bug #1017461 +++ The first part of fixes have been done in bug 1017461 but it seems the btrfs maintenance tasks can still have a significant impact on system responsiveness. Running the btrfs maintenance jobs, e.g. * /etc/cron.monthly/btrfs-scrub * /etc/cron.weekly/btrfs-balance * /etc/cron.weekly/btrfs-trim can make the clock with seconds displayed stop for some seconds or the mouse cursor to get stuck for seconds ## Reproducible * Somehow cause lot of "dirty" data that needs balancing/scrubbing * Run the cron jobs * Observe the system responsiveness is hindered ## Expected result Interactive use of a machine should not be impacted ## Suggestion It looks like /usr/share/btrfsmaintenance/btrfs-scrub.sh checks for the variable "$BTRFS_SCRUB_PRIORITY" equalling "normal" from /etc/sysconfig/btrfsmaintenance but this is set to "idle" for me in the config file which causes that no I/O scheduling parameters are forwarded to the call of scrub at all which does not seem to make sense to me. Should it set `-c 3` for idle or `-c 2 -n 7` for best-effort prio 7 instead? -- You are receiving this mail because: You are on the CC list for the bug.

2 109