July 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1135030] New: LTO: ceph build fails
by bugzilla_noreply＠novell.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1135030 Bug ID: 1135030 Summary: LTO: ceph 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: --- Fails here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… due to: [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_aio_create_completion' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create_with_context' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_version' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create2' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_nobjects_list_next' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_env' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_set' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_ioctx_create2' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_argv' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_read_file' -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 952198] New: django-admin does not work, django-admin.py does
by bugzilla_noreply＠novell.com 20 Mar '23

20 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=952198 Bug ID: 952198 Summary: django-admin does not work, django-admin.py does Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 RC1 1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: o.kurz(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- observation: The django tutorial https://docs.djangoproject.com/en/1.8/intro/tutorial01/ suggests to use the tool "django-admin" with django >= v1.7 which is also available in Leap but does not work. "django-admin.py" also exists and works ok. steps to reproduce: - "zypper in python-Django python-sqlite" # confirm uninstallation of blocker package - "django-admin startproject mysite" - observe error with python traceback problem: unknown so far. Is ist maybe related that python-Django (still) uses python2? workaround: - Use django-admin.py which works flawlessly, e.g. example project can be configured and run: "django-admin.py startproject mysite && python manage.py migrate && python manage.py runserver", connect with webbrowser to http://localhost:8000. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1129471] New: kernel 5.0.1-1-default: Problem loading X.509 certificate -65
by bugzilla_noreply＠novell.com 20 Mar '23

20 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1129471 Bug ID: 1129471 Summary: kernel 5.0.1-1-default: Problem loading X.509 certificate -65 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: hendrikw(a)arcor.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Sins Tumbleweed 20190314, with kernel 5.0.1-1-default (x86_64) I get the following message during boot: integrity: Problem loading X.509 certificate -65 Log snippet: [ 2.985576] sched_clock: Marking stable (2989021511, -3468039)->(2994215803, -8662331) [ 2.986009] registered taskstats version 1 [ 2.986012] Loading compiled-in X.509 certificates [ 2.986062] Loaded X.509 cert 'openSUSE Secure Boot Signkey: 0332fa9cbf0d88bf21924b0de82a09a54d5defc8' [ 2.986093] zswap: loaded using pool lzo/zbud [ 2.998908] Key type big_key registered [ 3.005600] Key type encrypted registered [ 3.005606] AppArmor: AppArmor sha1 policy hashing enabled [ 3.008353] integrity: Loading X.509 certificate: UEFI:db [ 3.008414] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' [ 3.008415] integrity: Loading X.509 certificate: UEFI:db [ 3.008452] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' [ 3.008453] integrity: Loading X.509 certificate: UEFI:db [ 3.008476] integrity: Loaded X.509 cert 'Acer Database: 84f00f5841571abd2cc11a8c26d5c9c8d2b6b0b5' [ 3.008477] integrity: Loading X.509 certificate: UEFI:db [ 3.008482] integrity: Problem loading X.509 certificate -65 [ 3.008494] fbcon: Taking over console [ 3.008496] Error adding keys to platform keyring UEFI:db [ 3.008497] integrity: Loading X.509 certificate: UEFI:db [ 3.008501] integrity: Problem loading X.509 certificate -65 [ 3.008505] Error adding keys to platform keyring UEFI:db [ 3.008596] Console: switching to colour frame buffer device 240x67 [ 3.009680] integrity: Loading X.509 certificate: UEFI:MokListRT [ 3.009739] integrity: Loaded X.509 cert 'openSUSE Secure Boot Signkey: 0332fa9cbf0d88bf21924b0de82a09a54d5defc8' [ 3.009740] integrity: Loading X.509 certificate: UEFI:MokListRT [ 3.012608] integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762' [ 3.014923] ima: Allocated hash algorithm: sha256 [ 3.052885] evm: Initialising EVM extended attributes: hardware: Laptop Acer Aspire A517-51-5832, one year old -- You are receiving this mail because: You are on the CC list for the bug.

2 20

[Bug 1140614] New: Error loading Applications menu extension in SLE-Classic
by bugzilla_noreply＠novell.com 20 Mar '23

20 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1140614 Bug ID: 1140614 Summary: Error loading Applications menu extension in SLE-Classic Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: qkzhu(a)suse.com Reporter: qkzhu(a)suse.com QA Contact: qa-bugs(a)suse.de CC: gwang(a)suse.com, xiaoguang.wang(a)suse.com, yfjiang(a)suse.com, zcjia(a)suse.com Found By: --- Blocker: --- apps-menu disappeared in TW-20190704, and journalctl shows: > gnome-shell[2369]: Extension "apps-menu(a)gnome-shell-extensions.gcampax.github.com" had error: Error: Requiring GMenu, version none: Typelib file for namespace 'GMenu' (any version) not found -- You are receiving this mail because: You are on the CC list for the bug.

2 15

[Bug 1100677] New: trackerbug: packages do not build reproducibly from compile-time CPU-detection
by bugzilla_noreply＠novell.com 18 Mar '23

18 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1100677 Bug ID: 1100677 Summary: trackerbug: packages do not build reproducibly from compile-time CPU-detection Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Depends on: 1100520 Blocks: 1081754 Found By: Development Blocker: --- e.g. bug 1100520 compiler options -march=native and -mtune=native make the resulting machine code depend on the build system's CPU which breaks reproducible builds. affects at least: glucat form python-annoy legion trigger-rally This is already fixed in: clpeak higan kyotocabinet one common approach seems to do sed -i "s|-march=native||g" $FILE -- You are receiving this mail because: You are on the CC list for the bug.

2 19

[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

[Bug 980292] New: Yast shouldn't allow running two instances of module at once
by bugzilla_noreply＠novell.com 08 Mar '23

08 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=980292 Bug ID: 980292 Summary: Yast shouldn't allow running two instances of module at once 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: hguo(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- It's very easy to mistakenly double click on a module icon in Yast2, causing two instances of the module to be started, and there's absolutely no point in using more than one instance of any yast module. Please disallow double click on yast2, and prevent more than one instance of module to be started. -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 1114673] New: New UI for firewalld: interface not assigned to the right zone when changed to public in first run
by bugzilla_noreply＠novell.com 07 Mar '23

07 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1114673 Bug ID: 1114673 Summary: New UI for firewalld: interface not assigned to the right zone when changed to public in first run 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: jeriveramoya(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Interface is not assigned to the right zone after following steps: - Open new UI for firewalld: yast2 firewall - Assign interface to different zone (for example public) - In Zones, set different zone (for example trusted) as default. - Accept - Check with firewall-cmd interface assignation: firewall-cmd --list-interfaces --zone=public | grep ens4 (is not there) but firewall-cmd --list-interfaces --zone=trusted | grep ens4 (it succeeds and it is pointing to the default zone not the one that was assigned) (same result also after trying a firewall-cmd --reload) Assignation works in general, but in this combination and just when the user enters first to this screen and set previous steps, does not work (perhaps some wrong initialization). Expected result: Point to the interface that is assigned in the UI (in the example, to public) -- You are receiving this mail because: You are on the CC list for the bug.

2 33