December 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1047218] New: trackerbug: packages do not build reproducibly from including build time
by bugzilla_noreply＠novell.com 07 Apr '23

07 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1047218 Bug ID: 1047218 Summary: trackerbug: packages do not build reproducibly from including build time Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: SUSE Other Status: CONFIRMED Severity: Normal Priority: P5 - None Component: Development Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- See also https://reproducible-builds.org/ and https://reproducible-builds.org/specs/source-date-epoch/ When packages include the current time of build it results in binaries that differ on every build and thus trigger rebuilds of depending packages and are published to mirrors and users when actually nothing really changed. -- You are receiving this mail because: You are on the CC list for the bug.

2 30

[Bug 1088738] New: xhost setting fails to have affect in /etc/gdm/Xsession --- "no protocol specified"
by bugzilla_noreply＠novell.com 31 Mar '23

31 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1088738 Bug ID: 1088738 Summary: xhost setting fails to have affect in /etc/gdm/Xsession --- "no protocol specified" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: noah(a)chromakey.io QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- line 154 xhost+ si:localuser ... needs to be in /etc/X11/xinit/xinitrc.d/what-ever.sh ... ... or maybe somewhere else all I know is that in Xsession it fails to have any affect ... effectively breaking the X11 gnome access for remote logins/ssh/etc. I'd expect a lot of bug reports of people angry, confused .. and complaining about "no protocol specified" errors. Thanks! -noah -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1051881] New: clang can't find libc.so with -m32
by bugzilla_noreply＠novell.com 28 Mar '23

28 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1051881 Bug ID: 1051881 Summary: clang can't find libc.so with -m32 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: --- Running: $ clang --version clang version 4.0.1 (tags/RELEASE_401/final 305264) $ cat a.c int main() {} $ clang -m32 a.c /usr/bin/ld: skipping incompatible /usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../libc.so when searching for -lc /lib/libc.so.6: error adding symbols: File format not recognized clang-4.0.1: error: linker command failed with exit code 1 (use -v to see invocation) I've noticed we have openSUSE specific patches: https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/clang-r… https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/assume-… But it does not work properly with -m32. Note the code in DetectDistro.cpp checks for /etc/SuSE-release, which is legacy. One should use /etc/os-release. I can fix that after we resolve this issue. Thanks, Martin -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1117095] New: vc4: Failed to allocate from CMA, graphics freezes
by bugzilla_noreply＠novell.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1117095 Bug ID: 1117095 Summary: vc4: Failed to allocate from CMA, graphics freezes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: jimc(a)math.ucla.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On a Raspberry Pi 3B (not plus) with OpenSuSE Tumbleweed openSUSE-release-20181101-934.1.aarch64 and kernel-default-4.18.15-1.2.aarch64. Kernel command line (/proc/cmdline): BOOT_IMAGE=/boot/Image-4.18.15-1-default root=UUID=38fbf451-5579-43d1-bdd2-84cfd886ad00 loglevel=3 splash=silent plymouth.enable=0 swiotlb=512 cma=300M console=ttyS1,115200n8 console=tty resume=/dev/mmcblk0p3 /boot/efi/config.txt (minus comments): kernel=u-boot.bin gpu_mem=32 force_turbo=0 initial_turbo=30 over_voltage=0 enable_uart=1 avoid_warnings=1 dtoverlay=upstream +upstream-mmc +upstreame-aux-interrupt include ubootconfig.txt arm_control=0x200 include extraconfig.txt dtparam=audio=on dtoverlay=vc4-kms-v3d (similar symptom with vc4-fkms-v3d) /etc/X11/xorg.conf.d/20-kms.conf says: Section "Device" Identifier "kms gfx" Driver "modesetting" #Option "AccelMethod" "none" [Commented out] EndSection /var/log/Xorg.0.log says: modeset(0): [DRI2] DRI driver: vc4 AIGLX: Loaded and initialized vc4 GLX: Initialized DRI2 GL provider for screen 0 In this configuration, glmark2-0.0+git.20180608-1.1.aarch64 runs without freezing or crashing and gets an overall score of 74, whereas with software rendering the score is 17, so GPU acceleration is really happening. >From the LightDM greeter I log in and start the default XFCE desktop. I start various programs and eventually get the symptom complained about; in the simplest case I start one xterm, one xload -update 2 (secs), and xscreensaver-5.37-4.3.aarch64 is active, blanking the screen only, DPMS off after 20 min. I let it incubate overnight. At the start, CmaTotal (from /proc/meminfo) is 307200kB and CmaFree is 206856 kB; CmaFree went up gradually to 241684 kB by the time the screensaver shut off video (DPMS). After 5 hours CmaFree was static at 234252 kB. With no change in CmaFree this message appeared in syslog: Nov 22 01:15:25 orion kernel: [34890.524661] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: Nov 22 01:15:25 orion kernel: [34890.524683] [drm] kernel: 8100kb BOs (1) Nov 22 01:15:25 orion kernel: [34890.524691] [drm] V3D: 26904kb BOs (121) Nov 22 01:15:25 orion kernel: [34890.524699] [drm] V3D shader: 272kb BOs (65) Nov 22 01:15:25 orion kernel: [34890.524706] [drm] dumb: 48kb BOs (3) Nov 22 01:15:25 orion kernel: [34890.524713] [drm] binner: 16384kb BOs (1) Nov 22 01:15:25 orion kernel: [34890.524721] [drm] total purged BO: 8kb BOs (2) Nov 22 01:15:25 orion kernel: [34890.524741] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory. In other tests this message appears at the same time that graphics freezes. When I woke up the screensaver, video came on, but the screen was black, except the cursor was visible, confined within the screensaver's authentication box. In other tests the screen content at the time of freezing remains unchanging, but the cursor changes shape according to what it's over, including not changing shape if the program (e.g. xterm) owning the window was killed. Keystrokes directed to an xterm are received and executed (with no visible effect on the screen), e.g. "echo Test File > /tmp/testfile", and the file appears. I can do "DISPLAY=:0 XAUTHORITY=/run/lightdm/root/:0 xwd -root > image.xwd" and the image will be complete and will show the current windows, not those at the time of freezing. The same symptoms can be elicited quicker if I run Firefox or Chromium. Heavy work in the browser did not seem to make the failure happen earlier; the 2 tests (one after the other) were to scroll quickly through 1.16Mb of text/html (no Javascript nor images), then 221 JPEG images in simple HTML pages. The freeze typically happens when I am doing nothing on the RPi, writing up notes on another machine. With either web browser, but not in the simple test case, CmaFree declined in non-reproducible patterns until the freeze occurred, and continued to decline to near zero (like 3000kB). I believe that this "death spiral" behavior is consequential damage from something freezing up, not the actual cause of the freeze. This is a known bug, though the exact symptoms seem to change with small variations in the test conditions, and with one or another kernel commit being excluded. https://github.com/raspberrypi/linux/issues/2680 (2018-09-12, OP cbxbiker61) He reports it began for him with approx. kernel 4.14.62 and someone else reports that it's still there in 4.18.11. Jimc sees it in 4.18.15 . Other forum and bug posters in various distros (Arch, Red Hat) report various similar-sounding problems, starting around 2018-09-xx. Could the SuSE distro managers please identify a combination of commits that gives the best results in the OpenSuSE context and push out that kernel, and keep an eye on progress in finding and killing the actual bug that is causing these freezeups? Thank you. I'm going to try to do the same thing, and I'll report back if I succeed, not a sure thing given my limited skills with git. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1089823] New: YaST can silently fail to run snapper during installation
by bugzilla_noreply＠novell.com 24 Mar '23

24 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1089823 Bug ID: 1089823 Summary: YaST can silently fail to run snapper during installation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 767377 --> http://bugzilla.suse.com/attachment.cgi?id=767377&action=edit y2logs Installation with the live media and snapshots enabled fails: https://openqa.opensuse.org/tests/657353#step/await_install/21 This is because snapper is not installed in the installation system, so the snapper installation-helper is missing. So YaST needs to add a hard dependency there. The bigger issue is that YaST didn't care that the binary is not present though (found in y2log-3): [libstorage] ActiongraphImpl.cc:584 Commit Action "Mounting /dev/vda2 at /" [sid:59, first] [libstorage] SystemCmd.cc:67 constructor SystemCmd("/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'") [libstorage] SystemCmd.cc:186 SystemCmd Executing:"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:187 timestamp [295.985073], 2018-04-17 02:15:45 GMT, 2018-04-16 22:15:45 EDT [libstorage] SystemCmd.cc:660 Adding Line 1 "/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory" [libstorage] SystemCmd.cc:626 pid:4219 added lines:1 stderr:true [libstorage] SystemCmd.cc:492 THROW: Command not found: "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:416 stopwatch 0.010977s for "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:436 system() Returns:127 [libstorage] SystemCmd.cc:678 stderr:/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory [libstorage] SystemCmd.cc:67 constructor SystemCmd("/sbin/udevadm settle --timeout=20") As can be seen, YaST notices the error but ignores it. Similar output for step 2. -- You are receiving this mail because: You are on the CC list for the bug.

2 19

[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 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