Bug#1069869: flash-kernel fails for kernel vmlinux-*
Please, review merge request https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/59
Bug#1069869: flash-kernel fails for kernel vmlinux-*
Package: flash-kernel Version: 3.107+b1 Severity: normal Package linux-image-6.7.9-riscv64 installs file /boot/vmlinux-6.7.9-riscv64. Flash-kernel fails with: sudo flash-kernel $(uname -r) Can't find /boot/vmlinuz-6.7.9-riscv64 (see /tmp/flash-kernel-no-kernel-error.log) Please, change flash-kernel to accept vmlinux*. In /usr/share/flash-kernel/functions we find kfile="/boot/vmlinuz-$kvers" if [ ! -e $kfile ]; then Changing this to kfile="/boot/vmlinuz-$kvers" if [ ! -e $kfile ]; then kfile="/boot/vmlinux-$kvers" fi if [ ! -e $kfile ]; then would be sufficient to resolve the issue. Best regards Heinrich
Bug#1064059: U-Boot: secure boot support
On 3/26/24 22:47, Vagrant Cascadian wrote: On 2024-02-16, Heinrich Schuchardt wrote: debian/patches/qemu/efi-secure-boot.patch is not a good approach to enabling secure boot with U-Boot. Variables entered via the command line containing the security database will be stored on file but will not be loaded into U-Boot on the next boot. If you want a version of U-Boot that supports secure boot properly, use CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security database which will be built into U-Boot. tools/efivar.py can be used to build that file. Separate U-Boot binaries for secure and non-secure would have to be provided. Are you saying that individuals needing this support should build their own custom u-boot binaries to eanble secure boot ... or that we should provide separate packages in Debian with secure boot enabled? I would not see the benefit of providing U-Boot in a way that looks like secure boot but does not provide security. Secure boot requires chain of trust. It starts at the root of trust. On embedded devices this root of trust is typically based on a public key burnt by the ODM into the SoC. U-Boot needs to be signed with a private key. The prior boot stage will check the signature. If Debian wanted to supply signed U-Boot binaries, Debian would have send the binaries with the built in EFI security data base to the ODM for signing similar to what is done for signed shim. The only use case for an unsigned U-Boot with secure-boot enabled would be for launching virtual machines. But there we can already use the edk2 package. Best regards Heinrich Existing EDK II packages provide secure boot. Hence I suggest to simply drop patch debian/patches/qemu/efi-secure-boot.patch. Any thoughts on this, Luca, as the provider of the original merge request: https://salsa.debian.org/debian/u-boot/-/merge_requests/24 Thanks! live well, vagrant
Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B
Upstream patch create: [PATCH 1/1] serial: move sbi_dbcn_available to .data section https://lists.denx.de/pipermail/u-boot/2024-February/546790.html
Bug#1060682: __wrpll_calc_filter_range: post-divider reference freq out of range
the
__wrpll_calc_filter_range: post-divider reference freq out of range
issue is caused by corruption of the in memory device-tree.
The appended patch solves the issue.
Best regards
HeinrichSubject: move sbi_dbcn_available to .data section
From: Heinrich Schuchardt
When U-Boot SPL loads the device-tree it does not consider the BSS section.
The RISC-V SBI Debug UART is enable before relocations. With
sbi_dbcn_available in the .bss section the device-tree is corrupted.
Move the variable to the .data section.
For a final solution the handling of the BSS section will have to be
improved in upstream U-Boot.
Forwarded: no
Last-Update: 2024-02-21
--- a/drivers/serial/serial_sbi.c
+++ b/drivers/serial/serial_sbi.c
@@ -17,7 +17,7 @@
#else
-static int sbi_dbcn_available;
+static int sbi_dbcn_available __section(".data");
static inline void _debug_uart_init(void)
{
Bug#1064281: ghdl: Building ghdl fails if LLVM and Clang versions are not provided explicitly
Package: ghdl Version: 3.0.0+dfsg2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, the 3.0.0+dfsg2 packaging requires that LLVM < 17 should be installed. As this is already the LLVM default we must explicitely install the LLVM 16 and Clang 16 packages for building. * Explicitely use llvm-16, clang-16 (LP: #2047298) Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.0-14-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru ghdl-3.0.0+dfsg2/debian/control ghdl-3.0.0+dfsg2/debian/control --- ghdl-3.0.0+dfsg2/debian/control 2023-10-01 01:16:46.0 +0200 +++ ghdl-3.0.0+dfsg2/debian/control 2024-02-19 12:49:34.0 +0100 @@ -12,8 +12,8 @@ libmpfr-dev (>= 3.0.0-9~) , libgmp-dev (>= 2:5.0.1~) , texinfo , - llvm-dev (<< 1:17~) , - clang (>= 1:3.5) , + llvm-16-dev , + clang-16 , zlib1g-dev Standards-Version: 4.6.2 Homepage: https://github.com/ghdl/ghdl diff -Nru ghdl-3.0.0+dfsg2/debian/rules ghdl-3.0.0+dfsg2/debian/rules --- ghdl-3.0.0+dfsg2/debian/rules 2023-10-01 01:16:46.0 +0200 +++ ghdl-3.0.0+dfsg2/debian/rules 2024-02-19 12:49:34.0 +0100 @@ -4,6 +4,8 @@ # for Ada code anyway export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format +export PATH:=$(PATH):/usr/lib/llvm-16/bin + #export DH_VERBOSE = 1 include /usr/share/dpkg/default.mk
Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B
Related Launchpad bug: HiFive Unmatched: __wrpll_calc_filter_range: post-divider reference freq out of range: 4294967295 https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2054091
Bug#1064059: U-Boot: secure boot support
Package: u-boot-qemu Version: 2024.01+dfsg-1 Severity: normal debian/patches/qemu/efi-secure-boot.patch is not a good approach to enabling secure boot with U-Boot. Variables entered via the command line containing the security database will be stored on file but will not be loaded into U-Boot on the next boot. If you want a version of U-Boot that supports secure boot properly, use CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security database which will be built into U-Boot. tools/efivar.py can be used to build that file. Separate U-Boot binaries for secure and non-secure would have to be provided. Existing EDK II packages provide secure boot. Hence I suggest to simply drop patch debian/patches/qemu/efi-secure-boot.patch. Best regards Heinrich
Bug#1062664: u-boot-starfive: crash with USB stick plugged in
Package: u-boot-starfive
Version: 2024.01+dfsg-1
Severity: normal
As reported in Launchpad bug 2052141 booting the StarFive VisionFive 2
board with a USB stick plugged in results in a crash.
The crash occurs when calling free() implemented in common/dlmalloc.c
The following two patches applied on top of upstream v2024.01 resolve
the issue:
0351b659dd02 ("efi_loader: create common function to free struct
efi_disk_obj")
f674a2f9a9f9 ("efi_loader: avoid pointer access after calling
efi_delete_handle")
Best regards
Heinrich
Bug#1053359: rsyslog-mysql: Data too long for column 'FromHost'
Package: rsyslog-mysql
Version: 8.2312.0-3
Severity: normal
In Launchpad autopkgtests fail with Data too long for column 'FromHost'
on a system with a hostname of 63 characters.
I hope to resolve this with merge request
https://github.com/rsyslog/rsyslog/issues/5309
testing is still ongoing.
These are the relevant syslog messages:
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: ommysql: db
error (1406): Data too long for column 'FromHost' at row 1 [v8.2312.0]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: The error
statement was: insert into SystemEvents (Message, Facility, FromHost,
Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values
(' rsyslogd: action \'action-7-ommysql\' (module \'ommysql\') message
lost, could not be processed. Check for additional error messages before
this one. [v8.2312.0 try https://www.rsyslog.com/e/2218 ]', 3,
'adt-noble-amd64-rsyslog-20240115-160328-juju-7f2275-prod-propos', 6,
'20240115174920', '20240115174920', 1, 'rsyslogd[2317]:') [v8.2312.0 try
https://www.rsyslog.com/e/2218 ]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: action
'action-7-ommysql' (module 'ommysql') message lost, could not be
processed. Check for additional error messages before this one.
[v8.2312.0 try https://www.rsyslog.com/e/2218 ]
Best regards
Heinrich
Bug#1060868: rsyslog-mysql: Data too long for column 'FromHost'
Package: rsyslog-mysql
Version: 8.2312.0-3
Severity: normal
In Launchpad autopkgtests fail with Data too long for column 'FromHost'
on a system with a hostname of 63 characters.
I hope to resolve this with merge request
https://github.com/rsyslog/rsyslog/issues/5310
testing is still ongoing.
These are the relevant syslog messages:
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: ommysql: db
error (1406): Data too long for column 'FromHost' at row 1 [v8.2312.0]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: The error
statement was: insert into SystemEvents (Message, Facility, FromHost,
Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values
(' rsyslogd: action \'action-7-ommysql\' (module \'ommysql\') message
lost, could not be processed. Check for additional error messages before
this one. [v8.2312.0 try https://www.rsyslog.com/e/2218 ]', 3,
'adt-noble-amd64-rsyslog-20240115-160328-juju-7f2275-prod-propos', 6,
'20240115174920', '20240115174920', 1, 'rsyslogd[2317]:') [v8.2312.0 try
https://www.rsyslog.com/e/2218 ]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: action
'action-7-ommysql' (module 'ommysql') message lost, could not be
processed. Check for additional error messages before this one.
[v8.2312.0 try https://www.rsyslog.com/e/2218 ]
Best regards
Heinrich
Bug#1060292: Flash-kernel add Sipeed Lichee Pi 4A - merge request
Merge request: https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/54
Bug#1060292: Flash-kernel add Sipeed Lichee Pi 4A
Package: flash-kernel Version: 3.107 Severity: wishlist Please, add the Sipeed Lichee Pi 4A to the database: Machine: Sipeed Lichee Pi 4A Kernel-Flavors: any Boot-Script-Path: /boot/boot.scr DTB-Id: thead/th1520-lichee-pi-4a.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools Best regards Heinrich
Bug#1060248: tang: Timeouts when testing on armhf
Package: tang
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
in Launchpad timeouts occured in the adv-socat tests.
* Increase timeout for the adv-socat test (LP: #2048479)
d/p/ubuntu/adv_socat_test_timeout.patch
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers noble
APT policy: (500, 'noble')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.0-14-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tang-14/debian/patches/series tang-14/debian/patches/series
--- tang-14/debian/patches/series 2023-07-04 20:26:54.0 +0200
+++ tang-14/debian/patches/series 2024-01-08 00:41:03.0 +0100
@@ -10,3 +10,6 @@
debian/2021-09-30.use-var-lib.patch
debian/2021-09-30.xinetd-support.patch
debian/2023-07-04.test-timeout.patch
+
+# patches for Ubuntu
+ubuntu/adv_socat_test_timeout.patch
diff -Nru tang-14/debian/patches/ubuntu/adv_socat_test_timeout.patch
tang-14/debian/patches/ubuntu/adv_socat_test_timeout.patch
--- tang-14/debian/patches/ubuntu/adv_socat_test_timeout.patch 1970-01-01
01:00:00.0 +0100
+++ tang-14/debian/patches/ubuntu/adv_socat_test_timeout.patch 2024-01-08
01:26:38.0 +0100
@@ -0,0 +1,18 @@
+Subject: Increase timeout for the adv-socat test
+Author: Heinrich Schuchardt
+Date: 2024-01-08
+Forwarded: yes
+
+The adv-socat test tends to often fail on armhf due to timeouts.
+
+--- a/tests/meson.build
b/tests/meson.build
+@@ -41,7 +41,7 @@
+ endif
+
+ test('adv-standalone', find_program('adv-standalone'), env: env, timeout:
1200)
+-test('adv-socat', find_program('adv-socat'), env: env, timeout: 60)
++test('adv-socat', find_program('adv-socat'), env: env, timeout: 1200)
+ test('rec-standalone', find_program('rec-standalone'), env: env, timeout: 60)
+ test('rec-socat', find_program('rec-socat'), env: env)
+ test('test-keys', test_keys, env: env, timeout: 60)
Bug#1053359: U-Boot debian/2024.01-rcX: u-boot-starfve
On 1/7/24 01:39, Vagrant Cascadian wrote: It may be preferable to upgrade the dependency OpenSBI to v1.4 before the new U-Boot release. I debated weather to bump the dependency, as OpenSBI is now v1.4 in unstable, so it should default to that version going forward... The VisionFive 2 board needs at least OpenSBI 1.3. This should be reflected in debian/control. Best regards Heinrich
Bug#1053359: U-Boot debian/2024.01-rcX: u-boot-starfve
Hello Vagrant, I have built U-Boot from https://salsa.debian.org/debian/u-boot/-/commit/e182a8eb13eb6d1990a3d79740b71b0cc52f9f5a Merge branch 'debian/2024.01-rcX' into debian/latest and deployed it to these boards: StarFive VisionFive 2 v1.3B, 4 GiB StarFive VisionFive 2 v1.3B, 8 GiB StarFive VisionFive 2 v1.2A, 4 GiB They boot fine via UEFI into Ubuntu. Thanks a lot for integrating this. It may be preferable to upgrade the dependency OpenSBI to v1.4 before the new U-Boot release. Best regards Heinrich
Bug#1060110: FTBFS: buffer overflow in test
Package: socat
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
A buffer overrun in msg2() was observed when executing the HOSTNAMEOVFL
test:
https://launchpadlibrarian.net/704617807/buildlog_ubuntu-noble-ppc64el.socat_1.8.0.0-3_BUILDING.txt.gz
* Fix memory overflow (LP: #2048408)
d/p/error.c-buffer-overflow-in-msg2.patch
Thanks for considering the patch.
Best regards
Heinrich
diff -Nru socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch
socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch
--- socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch
1970-01-01 01:00:00.0 +0100
+++ socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch
2024-01-06 00:03:50.0 +0100
@@ -0,0 +1,35 @@
+From: Heinrich Schuchardt
+Date: Fri, 5 Jan 2024 21:20:26 +
+Subject: [PATCH 1/1] error.c: buffer overflow in msg2()
+
+A buffer overrun in msg2() was observed when executing the HOSTNAMEOVFL
+test.
+
+If strncpy() truncates a string it does not append a terminating NUL
+character. Insert a NUL character after the destination area.
+This ensures that strchr() will stop at the end of the string.
+
+Fixes: 9be423ceea3c ("Improved handling of very long host or program names, or
no strftime")
+Signed-off-by: Heinrich Schuchardt
+
+Forwarded: yes
+Last-Update: 2024-01-05
+---
+ error.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/error.c b/error.c
+index d0a2a9e..3435046 100644
+--- a/error.c
b/error.c
+@@ -404,6 +404,7 @@ void msg2(
+if (bufp < buff+MSGLEN)
+ *bufp++ = ' ';
+strncpy(bufp, text, MSGLEN-(bufp-buff));
++ bufp[MSGLEN-(bufp-buff)] = 0;
+bufp = strchr(bufp, '\0');
+strcpy(bufp, "\n");
+_msg(level, buff, syslp);
+--
+2.43.0
+
diff -Nru socat-1.8.0.0/debian/patches/series
socat-1.8.0.0/debian/patches/series
--- socat-1.8.0.0/debian/patches/series 2023-12-21 13:58:31.0 +0100
+++ socat-1.8.0.0/debian/patches/series 2024-01-06 00:04:02.0 +0100
@@ -5,3 +5,4 @@
07-compat-define-PATH_MAX.patch
08-test.sh-fixes.patch
09-xioinitialize.c.patch
+error.c-buffer-overflow-in-msg2.patch
Bug#1058905: QEMU: why not use package opensbi as dependency?
On 12/18/23 07:41, Michael Tokarev wrote: Yes, we can do that. I don't see much benefit here though. For one, I dislike dangling symlinks in package, and don't want to add yet another directory to firmware search directories. OpenSBI is security critical as it runs in the highest privilege mode at Linux runtime. There have been potentially security relevant code errors detected in the past like buffer overruns. I am concerned that security errors fixed in the OpenSBI package might not be fixed in qemu-system-data at the same time. For the security team it would be much more evident what to fix if there were only one package building OpenSBI. Best regards Heinrich
Bug#1058905: QEMU: why not use package opensbi as dependency?
Package: qemu-system-data Version: 1:8.2.0~rc2+ds-1 Severity: wishlist Hello Michael, Debian provides package opensbi. In the qemu package's debian/rules we build another OpenSBI. Wouldn't it be preferable to reuse the existing opensbi package? This would imply that if we update OpenSBI also QEMU will use that new version. These are the duplicate files: opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.elf qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.elf opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin Best regards Heinrich
Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10
On 11/18/23 00:30, Vagrant Cascadian wrote:
On 2023-10-02, Heinrich Schuchardt wrote:
U-Boot v2023.10 has been released. It provides sufficient support for
the StarFive Visionfive 2 board.
Thanks!
I would suggest to package it as u-boot-starfive.
I will probably wait until u-boot 2023.10 lands in Debian before
uploading a new binary package that requires NEW review, but probably
not long after.
64fd30d367a1 ("tools: mkimage: Add StarFive SPL image support")
90602e779d3a ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
ad4b1bc39eef ("configs: NVMe/USB target boot devices on VisionFive 2")
98d17450cd4b ("starfive: visionfive2: add mmc0 and nvme boot targets")
I presume the above commits have now landed in upstream u-boot git?
Above commit hashes are present in upstream origin/master.
[PATCH v2] i2c: designware_i2c: adjust timing calculation
https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/
Did this land upstream yet?
35e8007ef382 ("i2c: designware_i2c: adjust timing calculation")
in origin/master.
Anything else needed?
To my knowledge this is all that is needed on top of v2023.10.
Best regards
Heinrich
Bug#1054651: qemu-efi-riscv64: Missing README.Debian file explaining the usage
Package: qemu-efi-riscv64 Version: 2023.08-1 Priority: wishlist Hello Dann, thanks for packaging qemu-efi-riscv64 in experimental. For first users it would be helpful to add a README.Debian explaining how to use the EDK II firmware with QEMU by giving an example, e.g. Package qemu-efi-riscv64 provides a RISC-V EDK II binary RISCV_VIRT_VARS.fd and an empty variables data base RISCV_VIRT_VARS.fd. Below you can find an example how to invoke QEMU to boot from a disk image (disk.img). The variables data base is copied so that it can be written to. By default the EDK II virt machine provides ACPI tables and no device-tree. The parameter acpi=off is used to provide a device-tree instead. cp /usr/share/qemu-efi-riscv64/ . qemu-system-riscv64 \ -M virt,acpi=off -m 4096 -smp 4 \ -serial mon:stdio \ -device virtio-gpu-pci \ -device qemu-xhci \ -device usb-kbd \ -device usb-mouse \ -drive \ if=pflash,format=raw,unit=0,file=/usr/share/qemu-efi-riscv64/RISCV_VIRT_CODE.fd,readonly=on \ -drive if=pflash,format=raw,unit=1,file=RISCV_VIRT_VARS.fd \ -drive file=disk.img,format=raw,if=virtio \ -device virtio-net-device,netdev=net0 \ -device virtio-rng-pci \ -netdev user,id=net0 If you only need a serial console, you could use qemu-system-riscv64 \ -M virt,acpi=off -m 4096 -smp 4 \ -nographic \ -drive \ if=pflash,format=raw,unit=0,file=/usr/share/qemu-efi-riscv64/RISCV_VIRT_CODE.fd,readonly=on \ -drive if=pflash,format=raw,unit=1,file=RISCV_VIRT_VARS.fd \ -drive file=disk.img,format=raw,if=virtio \ -device virtio-net-device,netdev=net0 \ -device virtio-rng-pci \ -netdev user,id=net0 On the serial console press the ESC key twice to reach the EDK II menu during the count down. Should package qemu-system-misc be marked as suggested? Best regards Heinrich
Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10
U-Boot v2023.01 introduced SPL code to detect the memory size on the different VisionFive 2 boards and adjust the device-tree accordingly. This relies on reading the EEPROM. Unfortunately the Designware I2C driver has an issue. So the following patch is needed: [PATCH v2] i2c: designware_i2c: adjust timing calculation https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/ Best regards Heinrich
Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10
To allow booting from NVMe, USB eMMC on the VisionFive 2 board the
following patches would be needed.
ad4b1bc39eef ("configs: NVMe/USB target boot devices on VisionFive 2")
98d17450cd4b ("starfive: visionfive2: add mmc0 and nvme boot targets")
Best regards
Heinrich
Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10
Package: u-boot
Version: 2023.07+dfsg-1
Severity: wishlist
U-Boot v2023.10 has been released. It provides sufficient support for
the StarFive Visionfive 2 board.
I would suggest to package it as u-boot-starfive.
The generated spl/u-boot-spl.bin cannot be used directly for
installation. But the U-Boot origin/next branch has two patches which
will result in a further binary with the necessary header prepended to
spl/u-boot-spl.bin:
64fd30d367a1 ("tools: mkimage: Add StarFive SPL image support")
90602e779d3a ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
Best regards
Heinrich
Bug#1052315: FTBFS: missing libzstd-dev build dependency
Package: spades Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch Dear Maintainer, The package failed to build from source on Launchpad. dh_auto_configure fails: dh_auto_configure: error: cd obj-x86_64-linux-gnu && \ DEB_PYTHON_INSTALL_LAYOUT=deb cmake \ -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None \ -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var \ -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF \ -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON \ -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run \ -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" \ -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu \ -DBoost_NO_BOOST_CMAKE=TRUE ../assembler/src returned exit code 1 make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 2 In Ubuntu, the attached patch was applied to achieve the following: * Add missing libzstd-dev build-dependency (LP: #2036726) Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers mantic APT policy: (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru spades-3.15.5+dfsg/debian/control spades-3.15.5+dfsg/debian/control --- spades-3.15.5+dfsg/debian/control 2023-08-09 12:45:04.0 +0200 +++ spades-3.15.5+dfsg/debian/control 2023-09-20 11:35:02.0 +0200 @@ -23,6 +23,7 @@ libnlopt-dev, libnlopt-cxx-dev, libssw-dev, + libzstd-dev, llvm-dev, python3-yaml, python3-joblib,
Bug#1052313: debug-me 1.20221231-1 FTBFS on ppc64el due to internal ld.gold error
Package: debug-me
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer,
building on ppc64el with LTO fails in Launchpad.
Cf.
https://launchpadlibrarian.net/684538812/buildlog_ubuntu-mantic-ppc64el.debug-me_1.20221231-1_BUILDING.txt.gz
Linking dist/build/debug-me/debug-me ...
/usr/bin/ld.gold: internal error in set_xindex, at ../../gold/object.h:1050
collect2: error: ld returned 1 exit status
`powerpc64le-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
In Ubuntu, the attached patch was applied to achieve the following:
* Disable LTO on the ppc64el architecture (LP: #2033639)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic
APT policy: (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-5-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru debug-me-1.20221231/debian/rules debug-me-1.20221231/debian/rules
--- debug-me-1.20221231/debian/rules2023-07-04 17:38:00.0 +0200
+++ debug-me-1.20221231/debian/rules2023-09-18 15:51:21.0 +0200
@@ -1,9 +1,18 @@
#!/usr/bin/make -f
+DPKG_EXPORT_BUILDFLAGS := 1
+include /usr/share/dpkg/architecture.mk
+
# Debian's ghc cannot compile anything with -fPIC at present, so we
# have to disable PIE hardening to avoid build failures on archs like
# amd64. See discussion on debian-hask...@lists.debian.org
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+
+# Building with LTO failed on ppc64el (LP: #2033639)
+ifeq ("$(DEB_BUILD_ARCH)", "ppc64el")
+ DEB_BUILD_MAINT_OPTIONS += optimize=-lto
+endif
+export DEB_BUILD_MAINT_OPTIONS
# cabal likes to write to $HOME, so use Setup.hs directly
export BUILDER = ./Setup
Bug#1036001: aespipe: FTBFS: building 2.4d-1.1 with LTO fails on arm64, ppc64el, s390x
Dear Maintainer, I have updated the appended patch to disable LTO only on the concerned architectures (arm64, ppc64el, s390x) and not on all. Best regards Heinrichdiff -Nru aespipe-2.4d/debian/changelog aespipe-2.4d/debian/changelog --- aespipe-2.4d/debian/changelog 2022-12-08 18:14:21.0 +0100 +++ aespipe-2.4d/debian/changelog 2023-05-12 15:21:16.0 +0200 @@ -1,3 +1,10 @@ +aespipe (2.4d-1.1ubuntu1) mantic; urgency=medium + + * Disable LTO to avoid failing tests on arm64, ppc64el, s390x +(LP: #2019319) + + -- Heinrich Schuchardt Fri, 12 May 2023 15:21:16 +0200 + aespipe (2.4d-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru aespipe-2.4d/debian/control aespipe-2.4d/debian/control --- aespipe-2.4d/debian/control 2016-11-11 00:22:01.0 +0100 +++ aespipe-2.4d/debian/control 2023-05-12 15:21:16.0 +0200 @@ -1,7 +1,8 @@ Source: aespipe Section: utils Priority: optional -Maintainer: Max Vozeler +Maintainer: Ubuntu Developers +XSBC-Original-Maintainer: Max Vozeler Build-Depends: debhelper (>= 7), gnupg, autotools-dev Standards-Version: 3.9.8 diff -Nru aespipe-2.4d/debian/rules aespipe-2.4d/debian/rules --- aespipe-2.4d/debian/rules 2022-12-08 18:14:21.0 +0100 +++ aespipe-2.4d/debian/rules 2023-05-12 15:21:16.0 +0200 @@ -1,15 +1,21 @@ #!/usr/bin/make -f #export DH_VERBOSE=1 -export DEB_BUILD_MAINT_OPTIONS=hardening=-pie reproducible=-fixfilepath,+fixdebugpath - -DPKG_EXPORT_BUILDFLAGS = 1 -include /usr/share/dpkg/buildflags.mk - DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_BUILD_MAINT_OPTIONS=hardening=-pie reproducible=-fixfilepath,+fixdebugpath + +# Test failures occured with LTO on these architectures +ifneq ($(findstring $(DEB_HOST_ARCH), arm64 ppc64el s390x),) + DEB_BUILD_MAINT_OPTIONS += optimize=-lto +endif +export DEB_BUILD_MAINT_OPTIONS + +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk + ifeq ($(DEB_HOST_ARCH),amd64) DEBIAN_OPTIMIZE := amd64 endif
Bug#1036001: aespipe: FTFBS on arm64, ppc64el, s390x with LTO enabled
Package: aespipe Version: 2.4d-1.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch Dear Maintainer, * Disable LTO to avoid failing tests on arm64, ppc64el, s390x (LP: #2019319) Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers mantic APT policy: (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.0-21-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru aespipe-2.4d/debian/rules aespipe-2.4d/debian/rules --- aespipe-2.4d/debian/rules 2022-12-08 18:14:21.0 +0100 +++ aespipe-2.4d/debian/rules 2023-05-12 15:21:16.0 +0200 @@ -1,7 +1,7 @@ #!/usr/bin/make -f #export DH_VERBOSE=1 -export DEB_BUILD_MAINT_OPTIONS=hardening=-pie reproducible=-fixfilepath,+fixdebugpath +export DEB_BUILD_MAINT_OPTIONS=optimize=-lto hardening=-pie reproducible=-fixfilepath,+fixdebugpath DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk
Bug#1035919: umockdev: Autopkgtest failure
Package: umockdev
Version: Autopkgtest failure
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
d/p/test-Allow-missing-.X11-unix-X5-file.patch
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers mantic
APT policy: (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.2.0-21-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru umockdev-0.17.17/debian/patches/series
umockdev-0.17.17/debian/patches/series
--- umockdev-0.17.17/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ umockdev-0.17.17/debian/patches/series 2023-05-11 09:20:46.0
+0200
@@ -0,0 +1 @@
+test-Allow-missing-.X11-unix-X5-file.patch
diff -Nru
umockdev-0.17.17/debian/patches/test-Allow-missing-.X11-unix-X5-file.patch
umockdev-0.17.17/debian/patches/test-Allow-missing-.X11-unix-X5-file.patch
--- umockdev-0.17.17/debian/patches/test-Allow-missing-.X11-unix-X5-file.patch
1970-01-01 01:00:00.0 +0100
+++ umockdev-0.17.17/debian/patches/test-Allow-missing-.X11-unix-X5-file.patch
2023-05-11 09:21:19.0 +0200
@@ -0,0 +1,36 @@
+From: Heinrich Schuchardt
+Date: Wed, 10 May 2023 18:22:12 +0200
+Subject: [PATCH 1/1] test: Allow missing .X11-unix/X5 file
+
+Testing fails with
+
+cannot remove /tmp/.X11-unix/X5: No such file or directory
+
+Fixes: 0f686e11540c ("Check FileUtils.{remove,unlink}() return code")
+
+Fixes #208
+https://launchpad.net/bugs/2019122
+
+Signed-off-by: Heinrich Schuchardt
+Origin:
https://github.com/martinpitt/umockdev/commit/e3a0383ebd15391e08549ceb8be9053315e15fc1
+---
+ tests/test-umockdev-run.vala | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tests/test-umockdev-run.vala b/tests/test-umockdev-run.vala
+index 6b2b23c..81fd7b0 100644
+--- a/tests/test-umockdev-run.vala
b/tests/test-umockdev-run.vala
+@@ -593,7 +593,8 @@ t_input_touchpad ()
+ // clean up lockfile after killed X server
+ if (FileUtils.remove ("/tmp/.X5-lock") < 0)
+ debug("failed to clean up /tmp/.X5-lock: %m");
+-checked_remove ("/tmp/.X11-unix/X5");
++if (FileUtils.remove ("/tmp/.X11-unix/X5") < 0)
++debug("failed to clean up .X11-unix/X5: %m");
+
+ assert_cmpstr (xinput_err, CompareOperator.EQ, "");
+ assert_cmpint (xinput_exit, CompareOperator.EQ, 0);
+--
+2.39.2
+
Bug#1035739: securefs: Autopkg test-failure
Package: securefs Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch X-Debbugs-Cc: heinrich.schucha...@canonical.com Dear Maintainer, Autopkgtests fail. This is fixed for amd64, arm64, ppc64el with this patch. * Set SECUREFS_BINARY in debian/test/control (LP: #2018707). Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers mantic APT policy: (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.0-21-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru securefs-0.13.1+ds/debian/tests/control securefs-0.13.1+ds/debian/tests/control --- securefs-0.13.1+ds/debian/tests/control 2023-01-27 03:31:37.0 +0100 +++ securefs-0.13.1+ds/debian/tests/control 2023-05-08 07:14:48.0 +0200 @@ -1,4 +1,4 @@ -Test-Command: cd obj-x86_64-linux-gnu && python3 ../test/simple_test.py +Test-Command: cd obj-`dpkg-architecture -q DEB_BUILD_GNU_TYPE` && SECUREFS_BINARY=`pwd`/securefs python3 ../test/simple_test.py Depends: fuse, libcrypto++-dev, libfuse-dev, @@ -7,6 +7,6 @@ python3 Restrictions: build-needed, isolation-machine, allow-stderr -Test-Command: cd obj-x86_64-linux-gnu && ./securefs_test +Test-Command: cd obj-`dpkg-architecture -q DEB_BUILD_GNU_TYPE` && ./securefs_test Depends: fuse, libcrypto++-dev, libfuse-dev, libjsoncpp-dev, libutf8proc-dev Restrictions: build-needed, allow-stderr
Bug#1035723: r-cran-dtplyr: Autopkgtests fail
Package: r-cran-dtplyr
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: heinrich.schucha...@canonical.com
Dear Maintainer,
Autopkgtests fail due to a missing upstream patch.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix autopkgtests (LP: #2018713)
d/p/0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers mantic
APT policy: (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.2.0-21-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
r-cran-dtplyr-1.2.2/debian/patches/0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
r-cran-dtplyr-1.2.2/debian/patches/0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
---
r-cran-dtplyr-1.2.2/debian/patches/0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
1970-01-01 01:00:00.0 +0100
+++
r-cran-dtplyr-1.2.2/debian/patches/0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
2023-05-08 08:34:58.0 +0200
@@ -0,0 +1,99 @@
+From b4733a7d1e1b5406bf3dd4299e85654566c7a68b Mon Sep 17 00:00:00 2001
+From: DavisVaughan
+Date: Wed, 14 Dec 2022 11:49:47 -0500
+Subject: [PATCH] Use snapshots for errors that dplyr owns now
+Origin:
https://github.com/tidyverse/dtplyr/commit/b4733a7d1e1b5406bf3dd4299e85654566c7a68b
+---
+ tests/testthat/_snaps/step-subset-slice.md | 46 ++
+ tests/testthat/test-step-subset-slice.R| 21 ++
+ 2 files changed, 59 insertions(+), 8 deletions(-)
+
+diff --git a/tests/testthat/_snaps/step-subset-slice.md
b/tests/testthat/_snaps/step-subset-slice.md
+index 4c43050..128112a 100644
+--- a/tests/testthat/_snaps/step-subset-slice.md
b/tests/testthat/_snaps/step-subset-slice.md
+@@ -1,3 +1,49 @@
++# slice_*() checks for empty ...
++
++Code
++ slice_head(dt, 5)
++Condition
++ Error in `slice_head()`:
++ ! `n` must be explicitly named.
++ i Did you mean `slice_head(n = 5)`?
++Code
++ slice_tail(dt, 5)
++Condition
++ Error in `slice_tail()`:
++ ! `n` must be explicitly named.
++ i Did you mean `slice_tail(n = 5)`?
++Code
++ slice_min(dt, x, 5)
++Condition
++ Error in `slice_min()`:
++ ! `n` must be explicitly named.
++ i Did you mean `slice_min(n = 5)`?
++Code
++ slice_max(dt, x, 5)
++Condition
++ Error in `slice_max()`:
++ ! `n` must be explicitly named.
++ i Did you mean `slice_max(n = 5)`?
++Code
++ slice_sample(dt, 5)
++Condition
++ Error in `slice_sample()`:
++ ! `n` must be explicitly named.
++ i Did you mean `slice_sample(n = 5)`?
++
++---
++
++Code
++ slice_min(dt)
++Condition
++ Error in `slice_min()`:
++ ! `order_by` is absent but must be supplied.
++Code
++ slice_max(dt)
++Condition
++ Error in `slice_max()`:
++ ! `order_by` is absent but must be supplied.
++
+ # check_slice_catches common errors
+
+ Code
+diff --git a/tests/testthat/test-step-subset-slice.R
b/tests/testthat/test-step-subset-slice.R
+index 3141f19..b209b76 100644
+--- a/tests/testthat/test-step-subset-slice.R
b/tests/testthat/test-step-subset-slice.R
+@@ -127,14 +127,19 @@ test_that("arguments to sample are passed along", {
+
+ test_that("slice_*() checks for empty ...", {
+ dt <- lazy_dt(data.frame(x = 1:10))
+- expect_error(slice_head(dt, 5), class = "rlib_error_dots_nonempty")
+- expect_error(slice_tail(dt, 5), class = "rlib_error_dots_nonempty")
+- expect_error(slice_min(dt, x, 5), class = "rlib_error_dots_nonempty")
+- expect_error(slice_max(dt, x, 5), class = "rlib_error_dots_nonempty")
+- expect_error(slice_sample(dt, 5), class = "rlib_error_dots_nonempty")
+-
+- expect_error(slice_min(dt), "missing")
+- expect_error(slice_max(dt), "missing")
++
++ expect_snapshot(error = TRUE, {
++slice_head(dt, 5)
++slice_tail(dt, 5)
++slice_min(dt, x, 5)
++slice_max(dt, x, 5)
++slice_sample(dt, 5)
++ })
++
++ expect_snapshot(error = TRUE, {
++slice_min(dt)
++slice_max(dt)
++ })
+ })
+
+ test_that("slice_*() checks for constant n= and prop=", {
+--
+2.39.2
+
diff -Nru r-cran-dtplyr-1.2.2/debian/patches/series
r-cran-dtplyr-1.2.2/debian/patches/series
--- r-cran-dtplyr-1.2.2/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ r-cran-dtplyr-1.2.2/debian/patches/series 2023-05-08 08:34:58.0
+0200
@@ -0,0 +1 @@
+0001-Use-snapshots-for-errors-that-dplyr-owns-now.patch
Bug#1031765: pgrep: signal handler matching breaks argument parsing
Upstream has merged https://github.com/ganeti/ganeti/pull/1692, commit
9cd67e6a81c6 ("uidpool_unittest: avoid using negative UIDs") to solve
the issue.
Additionally the following patch is needed to fix a separate problem
with testing:
a40748ab26fc ("py-tests: make tests compatible with roman 3.2+")
Best regards
Heinrich
Bug#1031765: pgrep: signal handler matching breaks argument parsing
Upstream bug report created: https://github.com/ganeti/ganeti/issues/1691 Ubuntu bug LP #2009498
Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2
Hello Vagrant, copying initrd to high memory overwrites internal EFI structures. setenv initrd_high 0x setenv fdt_high 0x solves the problem on the Odroid C2. Best regards Heinrich
Bug#1027329: OpenVSwitch: Enable DPDK for RISC-V architecture
Source: openvswitch Version: 3.1.0~git20221212.739bcf2-3 Severity: wishlist Version 22.11 of package DPDK provides support for the RISC-V architecture. We should allow OpenVSwitch to make use of it. Best regards Heinrich
Bug#1024354: DPDK: missing riscv64 build
Package: dpdk Version: 22.11~rc2-1 Severity: wishlist DPDK 22.11 contains RISC-V support. It would be great if you could enable it in the Debian packaging. Best regards Heinrich
Bug#1023616: opensbi: Emulation of fence.tso hangs in endless loop
Package: opensbi
Version: 1.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Dear Maintainer,
* Fix emulation of fence.tso hanging in endless loop on Allwinner D1
d/p/lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
(LP: #1995860)
Thanks for considering the patch.
Best regards
Heinrich
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-proposed
APT policy: (500, 'lunar-proposed'), (500, 'lunar')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-21-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
opensbi-1.1/debian/patches/lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
opensbi-1.1/debian/patches/lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
---
opensbi-1.1/debian/patches/lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
1970-01-01 01:00:00.0 +0100
+++
opensbi-1.1/debian/patches/lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
2022-11-07 14:25:01.0 +0100
@@ -0,0 +1,36 @@
+From 111afc12306e4368fa112f97d31ea802c4561294 Mon Sep 17 00:00:00 2001
+From: Rahul Pathak
+Date: Fri, 12 Aug 2022 19:24:42 +0530
+Subject: [PATCH] lib: sbi_illegal_insn: Fix FENCE.TSO emulation infinite trap
+ loop
+
+In case of missing "FENCE.TSO" instruction implementation,
+opensbi can emulate the "FENCE.TSO" with "FENCE RW,RW", but
+mepc was not incremented to continue from the next instruction
+causing infinite trap.
+
+Fixes: cb8271c8 ("lib: sbi_illegal_insn: Add emulation for fence.tso")
+Signed-off-by: Rahul Pathak
+Reviewed-by: Andrew Jones
+Reviewed-by: Xiang W
+Reviewed-by: Samuel Holland
+Origin:
https://github.com/riscv-software-src/opensbi/commit/111afc12306e4368fa112f97d31ea802c4561294
+---
+ lib/sbi/sbi_illegal_insn.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/sbi/sbi_illegal_insn.c b/lib/sbi/sbi_illegal_insn.c
+index ecd3508..9691bce 100644
+--- a/lib/sbi/sbi_illegal_insn.c
b/lib/sbi/sbi_illegal_insn.c
+@@ -40,6 +40,7 @@ static int misc_mem_opcode_insn(ulong insn, struct
sbi_trap_regs *regs)
+ /* Errata workaround: emulate `fence.tso` as `fence rw, rw`. */
+ if ((insn & INSN_MASK_FENCE_TSO) == INSN_MATCH_FENCE_TSO) {
+ smp_mb();
++ regs->mepc += 4;
+ return 0;
+ }
+
+--
+2.37.2
+
diff -Nru opensbi-1.1/debian/patches/series opensbi-1.1/debian/patches/series
--- opensbi-1.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ opensbi-1.1/debian/patches/series 2022-11-07 13:18:42.0 +0100
@@ -0,0 +1 @@
+lib-sbi_illegal_insn-Fix-FENCE.TSO-emulation-infinit.patch
Bug#1019391: #1020099 is duplicate to #1019391
Bug report #1020099 is duplicate to #1019391 The issue is fixed by upstream patches available at https://github.com/lovasoa/marshmallow_dataclass/commits/master In Ubuntu we use LP #1991064 for tracking. Best regards Heinrich
Bug#1020849: python-exchangelib: autopkgtest failure in EWSDateTimeTest.test_generate()
Package: python-exchangelib
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Dear Maintainer,
autopkgtest EWSDateTimeTest.test_generate() because the time zones defined by
package tzdata and
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml
differ for Kiev.
Cf. "Tests failure due to Kiev timezone"
https://github.com/ecederstrand/exchangelib/issues/1120
In Ubuntu, the attached patch was applied:
* Timezone "Europe/Kyiv" exists in tzdata but not in the webpage
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml
Add patch d/p/ubuntu-kyiv-quirk.patch to let autopkgtests succeed.
(LP: #1990843)
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers kinetic-proposed
APT policy: (500, 'kinetic-proposed'), (500, 'kinetic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-15-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-exchangelib-4.7.6/debian/patches/series
python-exchangelib-4.7.6/debian/patches/series
--- python-exchangelib-4.7.6/debian/patches/series 2022-09-08
18:06:14.0 +0200
+++ python-exchangelib-4.7.6/debian/patches/series 2022-09-27
09:46:34.0 +0200
@@ -1,2 +1,3 @@
0001-Do-not-depend-on-tzdata-use-local-timezone-database.patch
0002-add-kyiv.patch
+ubuntu-kyiv-quirk.patch
diff -Nru python-exchangelib-4.7.6/debian/patches/ubuntu-kyiv-quirk.patch
python-exchangelib-4.7.6/debian/patches/ubuntu-kyiv-quirk.patch
--- python-exchangelib-4.7.6/debian/patches/ubuntu-kyiv-quirk.patch
1970-01-01 01:00:00.0 +0100
+++ python-exchangelib-4.7.6/debian/patches/ubuntu-kyiv-quirk.patch
2022-09-27 09:45:34.0 +0200
@@ -0,0 +1,21 @@
+From: Heinrich Schuchardt
+Subject: [PATCH] fix CLDR_TO_MS_TIMEZONE_MAP testing
+
+Timezone "Europe/Kyiv" exists in tzdata but not in webpage CLDR_WINZONE_URL.
+To overcome autopkgtest failures remove the entry when testing.
+
+--- a/tests/test_ewsdatetime.py
b/tests/test_ewsdatetime.py
+@@ -198,9 +198,11 @@
+ # generate_map() requires access to unicode.org, which may be
unavailable. Don't fail test, since this is
+ # out of our control.
+ return
++# Timezone "Europe/Kyiv" exists in tzdata but not in webpage
CLDR_WINZONE_URL
++expected_map = {key : CLDR_TO_MS_TIMEZONE_MAP[key] for key in
CLDR_TO_MS_TIMEZONE_MAP if key != "Europe/Kyiv"}
+ self.assertEqual(type_version, CLDR_WINZONE_TYPE_VERSION)
+ self.assertEqual(other_version, CLDR_WINZONE_OTHER_VERSION)
+-self.assertDictEqual(tz_map, CLDR_TO_MS_TIMEZONE_MAP)
++self.assertDictEqual(tz_map, expected_map)
+
+ @requests_mock.mock()
+ def test_generate_failure(self, m):
Bug#1019004: U-Boot does not find ESP
On 9/3/22 18:25, Vagrant Cascadian wrote: On 2022-09-03, Heinrich Schuchardt wrote: U-Boot 2022.07 may not find EFI system partition where UEFI variables are stored. This can lead to booting via UEFI to fail. Just for clarity, this is not a regression from 2022.04? The problem does not exist in 2022.04. It is specific to 2022.07 Best regards Heinrich
Bug#1019004: U-Boot does not find ESP
Package: u-boot Version: 2022.07+dfsg-1 Severity: normal U-Boot 2022.07 may not find EFI system partition where UEFI variables are stored. This can lead to booting via UEFI to fail. The following upstream patch fixes this: commit d5391bf02b9dc6a84fe33ba913caf70061909950 efi_loader: ensure all block devices are probed Best regards Heinrich
Bug#986708: closed by Mark Hindley (Re: Bug#986708: adopted rsnapshot)
Am 18. Juni 2022 12:27:10 MESZ schrieb Debian Bug Tracking System : >This is an automatic notification regarding your Bug report >which was filed against the wnpp package: > >#986708: O: sispmctl -- Control Gembird SIS-PM programmable power outlet strips > >It has been closed by Mark Hindley . > >Their explanation is attached below along with your original report. >If this explanation is unsatisfactory and you have not received a >better one in a separate message then please contact Mark Hindley > by >replying to this email. > > The bug report was about sispmctl and not rsnapshot. So uploading a new version of rsnapshot cannot resolve it. Best regards Heinrich
Bug#900799: linux-image-arm64: dts: rockchip: correct voltage selector Firefly-RK3399
On 6/1/22 11:28, Diederik de Haas wrote: On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings wrote: Version: 4.17.2-1~exp1 On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt wrote: Please, add this patch to the Debian kernel patches until it is added upstream. Cf. https://lkml.org/lkml/2018/6/4/781 This was applied in the above merge but not mentioned in the changelog due to a mis-merge. In response Heiko says in https://lkml.org/lkml/2018/6/19/1167: "and dropped again. Sadly it looks like the patch causes conflicts with at least one firefly board in a kernelci lab. My own is currently not ready to use, so I cannot look myself right now. The issue kernelci people described sounded quite a lot like the one in your commit message, so my current theory is that the suspend-voltage-selector must in some form corespond to the cpu_b_sleep_h gpio setting we're currently not handling at all, which would therefore depend on how the bootloader sets this up." It's also not part of current upstream master, so this is a DTS change that is specific for Debian and possibly not needed and/or incorrect? Heinrich, can you tell us more about the current status of this patch? I have not been working on the board in the last years. My impression at the time was that one would have to detect the current state of the board at runtime which matches what you wrote. Best regards Heinrich
Bug#1010894: python-cheroot version number does not conform to PEP440
On 5/13/22 13:07, julien.pu...@gmail.com wrote:
Le vendredi 13 mai 2022 à 11:18 +0200, Heinrich Schuchardt a écrit :
On 5/12/22 17:17, julien.pu...@gmail.com wrote:
I propose to add the following patch to my package:
Description: make the package return a PEP440-compatible version
number
Author: Julien Puydt
Forwarded: Debian-specific
--- python-cheroot.orig/cheroot/__init__.py
+++ python-cheroot/cheroot/__init__.py
@@ -11,5 +11,7 @@
try:
__version__ =
pkg_resources.get_distribution('cheroot').version
+ if __version__.find('+ds') != -1:
+ __version__ = __version__[:__version__.find('+ds')]
This will not work for anything but +ds.
Does it solve your issue with the Debian package now?
Indeed if upstream had a more generic fix, that is the best solution,
That is why I created
https://github.com/cherrypy/cheroot/pull/507
but in the mean time, I can live with a Debian-specific patch.
Your patch works fine as long a your version appendix starts with +ds.
Best regards
Heinrich
Cheers,
J.Puydt
Bug#1010894: python-cheroot version number does not conform to PEP440
On 5/12/22 17:17, julien.pu...@gmail.com wrote:
Le jeudi 12 mai 2022 à 17:04 +0200, Heinrich Schuchardt a écrit :
On 5/12/22 15:36, julien.pu...@gmail.com wrote:
Le jeudi 12 mai 2022 à 15:20 +0200, Heinrich Schuchardt a écrit :
On 5/12/22 14:55, julien.pu...@gmail.com wrote:
Let me ask bluntly: how is it a problem?
$ python3
>>> import cheroot
>>> print cheroot.__version__
8.6.0+ds1
>>> from distutils.version import StrictVersion
>>> StrictVersion(cheroot.__version__)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.10/distutils/version.py", line 40, in
__init__
self.parse(vstring)
File "/usr/lib/python3.10/distutils/version.py", line 137, in
parse
raise ValueError("invalid version number '%s'" % vstring)
ValueError: invalid version number '8.6.0+ds1'
>>>
If there were any issue with general Python packages versioning
in
Debian, perhaps you should contact the Debian Python
Maintainers
team?
You could patch this line to solve the problem:
cheroot/__init__.py:13:
__version__ = pkg_resources.get_distribution('cheroot').version
Ok, distutils is unhappy, but:
1. distutils is obsolete: https://peps.python.org/pep-0632/
2. your example doesn't look like a real-world situation.
You err. See the linked issue on launchpad.net. Ceph does not work
due
to your deviation from upstream version numbers.
You're right, I had forgotten about this!
I propose to add the following patch to my package:
Description: make the package return a PEP440-compatible version number
Author: Julien Puydt
Forwarded: Debian-specific
--- python-cheroot.orig/cheroot/__init__.py
+++ python-cheroot/cheroot/__init__.py
@@ -11,5 +11,7 @@
try:
__version__ = pkg_resources.get_distribution('cheroot').version
+if __version__.find('+ds') != -1:
+__version__ = __version__[:__version__.find('+ds')]
This will not work for anything but +ds.
I have created a more generic patch in
https://github.com/cherrypy/cheroot/pull/507
using a regular expression to extract the valid part of the version number.
Best regards
Heinrich
except Exception:
__version__ = 'unknown'
Would that solve your issue?
Cheers,
J.Puydt
Bug#1010894: python-cheroot version number does not conform to PEP440
On 5/12/22 15:36, julien.pu...@gmail.com wrote:
Le jeudi 12 mai 2022 à 15:20 +0200, Heinrich Schuchardt a écrit :
On 5/12/22 14:55, julien.pu...@gmail.com wrote:
Let me ask bluntly: how is it a problem?
$ python3
>>> import cheroot
>>> print cheroot.__version__
8.6.0+ds1
>>> from distutils.version import StrictVersion
>>> StrictVersion(cheroot.__version__)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.10/distutils/version.py", line 40, in
__init__
self.parse(vstring)
File "/usr/lib/python3.10/distutils/version.py", line 137, in
parse
raise ValueError("invalid version number '%s'" % vstring)
ValueError: invalid version number '8.6.0+ds1'
>>>
If there were any issue with general Python packages versioning in
Debian, perhaps you should contact the Debian Python Maintainers
team?
You could patch this line to solve the problem:
cheroot/__init__.py:13:
__version__ = pkg_resources.get_distribution('cheroot').version
Ok, distutils is unhappy, but:
1. distutils is obsolete: https://peps.python.org/pep-0632/
2. your example doesn't look like a real-world situation.
You err. See the linked issue on launchpad.net. Ceph does not work due
to your deviation from upstream version numbers.
Best regards
Heinrich
I don't want to diverge from upstream -- however trivial the patch,
unless there's some actual problem to fix.
Cheers,
J.Puydt
Bug#1010894: python-cheroot version number does not conform to PEP440
On 5/12/22 14:55, julien.pu...@gmail.com wrote:
Hi,
Le jeudi 12 mai 2022 à 14:45 +0200, Heinrich Schuchardt a écrit :
Package: python-cheroot
Version: 8.6.0+ds1-2
Severity: normal
Python package versions like 8.6.0+ds1 do not conform to PEP440. This
leads to errors in Ceph as reported in
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1967139
It's not a Python package version ; it's a Debian package version, so
PEP440 doesn't apply.
Unfortunately this number is propagated into cheroot.__version__.
Is this something to be corrected in this package?
Or is this a general problem with how we do Python packaging?
Let me ask bluntly: how is it a problem?
$ python3
>>> import cheroot
>>> print cheroot.__version__
8.6.0+ds1
>>> from distutils.version import StrictVersion
>>> StrictVersion(cheroot.__version__)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.10/distutils/version.py", line 40, in __init__
self.parse(vstring)
File "/usr/lib/python3.10/distutils/version.py", line 137, in parse
raise ValueError("invalid version number '%s'" % vstring)
ValueError: invalid version number '8.6.0+ds1'
>>>
If there were any issue with general Python packages versioning in
Debian, perhaps you should contact the Debian Python Maintainers team?
You could patch this line to solve the problem:
cheroot/__init__.py:13:
__version__ = pkg_resources.get_distribution('cheroot').version
Best regards
Heinrich
Cheers,
J.Puydt
Bug#1010894: python-cheroot version number does not conform to PEP440
Package: python-cheroot
Version: 8.6.0+ds1-2
Severity: normal
Hello Julien,
Python package versions like 8.6.0+ds1 do not conform to PEP440. This
leads to errors in Ceph as reported in
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1967139
Allowable package versions are defined in PEP440
(https://peps.python.org/pep-0440/) as
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]
So 8.6.0a1 would be legal. 8.6.0+ds1 is illegal.
Is this something to be corrected in this package?
Or is this a general problem with how we do Python packaging?
Best regards
Heinrich
Bug#995462: bbrun: fails to build on RISC-V
On 5/11/22 01:24, Vagrant Cascadian wrote: Control: tags 995462 +moreinfo On 2021-10-01, Heinrich Schuchardt wrote: Package: bbrun Version: 1.6-8 Severity: normal Building on RISC-V fails with: cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode Please, remove debian/patches/05_gcc5-gnu89.patch Hrm. bbrun 1.6-8 builds successfully on riscv64 with toolchains currently in sid, as well as the few additional commits in git. Are you still able to reproduce the failure? The patch for supporting gcc5 could maybe be dropped regardless if it really isn't needed anymore... live well, vagrant Building on riscv64 Ubuntu Jammy succeeds with current Debian sid sources. As no development release uses GCC 5 the patch should be dropped anyway. Ubuntu Jammy and Kinetic do not contain the patch. Best regards Heinrich
Bug#1010358: ugene: Fix for non-constant SIGSTKSZ
Package: ugene
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Dear Maintainer,
ugene 40.1+dfsg-1 fails to build on Ubuntu.
* Fix for non-constant SIGSTKSZ (LP: #1970417)
* Build on amd64 only.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-27-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ugene-40.1+dfsg/debian/control ugene-40.1+dfsg/debian/control
--- ugene-40.1+dfsg/debian/control 2021-10-19 12:55:46.0 +0200
+++ ugene-40.1+dfsg/debian/control 2022-04-26 14:25:30.0 +0200
@@ -1,9 +1,9 @@
Source: ugene
-Maintainer: Debian Med Packaging Team
+Maintainer: Maintainer: Debian Med Packaging Team
Uploaders: Steffen Moeller ,
Andreas Tille ,
Olivier Sallou
-Section: non-free/science
+Section: multiverse/science
XS-Autobuild: yes
Priority: optional
Build-Depends: qtbase5-dev,
@@ -30,7 +30,7 @@
Rules-Requires-Root: no
Package: ugene
-Architecture: any
+Architecture: amd64
Depends: ${shlibs:Depends},
ugene-data,
${misc:Depends}
diff -Nru ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
--- ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
1970-01-01 01:00:00.0 +0100
+++ ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
2022-04-26 14:24:36.0 +0200
@@ -0,0 +1,32 @@
+From: David Faure
+Date: Wed, 15 Dec 2021 22:26:40 +0100
+Subject: [PATCH] Fix for non-constant SIGSTKSZ
+
+On glibc > 2.33, `SIGSTKSZ` might not be constant (in which case
+it expands to a call to `sysconf` which returns a `long int`); see
+https://sourceware.org/pipermail/libc-alpha/2020-October/118513.html
+
+Pass unsigned explicitly to std::max, to avoid relying on template
+argument deduction. This works both with the old-style constant
+`SIGSTKSZ` and the new configurable one.
+
+Initially based on https://chromium-review.googlesource.com/c/2776379
+
+Change-Id: I9fc95337f973e871b84735ce822b5e11ba73ea8c
+Reviewed-on:
https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3340721
+Reviewed-by: Mark Mentovai
+---
+ src/client/linux/handler/exception_handler.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/libs_3rdparty/breakpad/src/client/linux/handler/exception_handler.cc
b/src/libs_3rdparty/breakpad/src/client/linux/handler/exception_handler.cc
+@@ -141,7 +141,7 @@
+ // SIGSTKSZ may be too small to prevent the signal handlers from overrunning
+ // the alternative stack. Ensure that the size of the alternative stack is
+ // large enough.
+- static const unsigned kSigStackSize = std::max(16384, SIGSTKSZ);
++ const unsigned kSigStackSize = std::max(16384, SIGSTKSZ);
+
+ // Only set an alternative stack if there isn't already one, or if the
current
+ // one is too small.
diff -Nru ugene-40.1+dfsg/debian/patches/series
ugene-40.1+dfsg/debian/patches/series
--- ugene-40.1+dfsg/debian/patches/series 2021-10-19 12:55:46.0
+0200
+++ ugene-40.1+dfsg/debian/patches/series 2022-04-26 14:25:30.0
+0200
@@ -3,3 +3,4 @@
do_not_build_phylip.patch
# only partly addressed by upstream
use_debian_sqlite.patch
+Fix-for-non-constant-SIGSTKSZ.patch
Bug#1006926: flash-kernel
Hello Vagrant, is the suggestion I made in https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/29 fine with you? Then I would update the pull request accordingly. Best regards Heinrich
Bug#1006926: flash-kernel: add support for SiFive Unmatched board
Merge request created: https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/29
Bug#1007911: meta-gnome3: Don't require libreoffice on riscv64 where it is not available
Package: meta-gnome3 Version: 1%40+1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu jammy ubuntu-patch Dear Maintainer, LibreOffice is not available on riscv64. Don't require libreoffice on riscv64 where it is not available Edit In Ubuntu, the attached patch was applied to achieve the following: * Don't require libreoffice on riscv64 where it is not available (LP: #1965304) Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy APT policy: (500, 'jammy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru meta-gnome3-41+1/debian/control meta-gnome3-41+1ubuntu1/debian/control --- meta-gnome3-41+1/debian/control 2021-11-15 21:44:25.0 +0100 +++ meta-gnome3-41+1ubuntu1/debian/control 2022-03-17 14:07:01.0 +0100 @@ -6,7 +6,7 @@ Section: metapackages Priority: optional Maintainer: Debian GNOME Maintainers -Uploaders: Jeremy Bicha +Uploaders: Emilio Pozuelo Monfort , Josselin Mouette , Laurent Bigonville , Michael Biebl Standards-Version: 4.5.0 Rules-Requires-Root: no Build-Depends: debhelper-compat (= 13), @@ -121,10 +121,10 @@ evolution (>= 3.36), gnome-sound-recorder, gnome-tweaks (>= 3.30), - libreoffice-gnome, - libreoffice-writer, - libreoffice-calc, - libreoffice-impress, + libreoffice-gnome [!riscv64], + libreoffice-writer [!riscv64], + libreoffice-calc [!riscv64], + libreoffice-impress [!riscv64], libgsf-bin, rhythmbox (>= 3.0), seahorse (>= 3.36), diff -Nru meta-gnome3-41+1/debian/control.in meta-gnome3-41+1ubuntu1/debian/control.in --- meta-gnome3-41+1/debian/control.in 2021-11-15 21:44:25.0 +0100 +++ meta-gnome3-41+1ubuntu1/debian/control.in 2022-03-17 14:07:01.0 +0100 @@ -117,10 +117,10 @@ evolution (>= 3.36), gnome-sound-recorder, gnome-tweaks (>= 3.30), - libreoffice-gnome, - libreoffice-writer, - libreoffice-calc, - libreoffice-impress, + libreoffice-gnome [!riscv64], + libreoffice-writer [!riscv64], + libreoffice-calc [!riscv64], + libreoffice-impress [!riscv64], libgsf-bin, rhythmbox (>= 3.0), seahorse (>= 3.36),
Bug#1006938: docker.io lacks buildx
Package: docker.io Version: 20.10.11+dfsg1-2 Severity: wishlist buildx is a CLI plugin for docker, see https://docs.docker.com/buildx/working-with-buildx/, https://github.com/docker/buildx/. It is used by many build scripts for Docker tools. It would be great to have it available in Debian. Best regards Heinrich
Bug#1006926: flash-kernel: add support for SiFive Unmatched board
Package: flash-kernel
Version: 3.104
Severity: wishlist
Tags: patch
As boards using the riscv64 architecture can be booted from U-Boot via
the booti command like arm64 boards we should start adding these to the
package.
The three appended patches
* add a bootscr.uboot-generic script for riscv64
* provide the database entry for the SiFive Unmatched board
* enable building on riscv64
The main benefit of the package I see is that when booting via GRUB it
can be used to supply the newest device-tree before launching GRUB via
the preboot hook.
Best regards
HeinrichFrom 94d1eba3ffdfdca6917a7975b35197f1aae70e26 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt
Date: Tue, 8 Mar 2022 11:03:16 +0100
Subject: [PATCH 3/3] debian/control: enable building for riscv64
riscv64 boards use device-trees. So we should provide the flash-kernel
package for them.
Signed-off-by: Heinrich Schuchardt
---
debian/control | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index d37b6d5..89e6751 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Git: https://salsa.debian.org/installer-team/flash-kernel.git
Rules-Requires-Root: no
Package: flash-kernel
-Architecture: arm64 armel armhf
+Architecture: arm64 armel armhf riscv64
Depends: ${misc:Depends},
devio,
initramfs-tools (>= 0.92f),
@@ -31,7 +31,7 @@ Section: debian-installer
Priority: standard
Package-Type: udeb
Build-Profiles:
-Architecture: arm64 armel armhf
+Architecture: arm64 armel armhf riscv64
XB-Subarchitecture: kirkwood orion5x s3c24xx mx5 generic
Provides: bootable-system
Depends: cdebconf-udeb, installed-base
--
2.34.1
From d43ffd2af4fd5387fa20909ccf0b51fbbba76626 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt
Date: Tue, 8 Mar 2022 10:18:49 +0100
Subject: [PATCH 2/3] db/all.db: add SiFive HiFive Unmatched A00
Add the SiFive HiFive Unmatched board to the database.
Ubuntu uses the 'generic' flavor while Debian uses 'riscv64'.
Add both to the database.
Signed-off-by: Heinrich Schuchardt
---
db/all.db | 7 +++
1 file changed, 7 insertions(+)
diff --git a/db/all.db b/db/all.db
index 951effe..585e45c 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1719,6 +1719,13 @@ Boot-DTB-Path: /boot/dtb
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: no
+Machine: SiFive HiFive Unmatched A00
+Kernel-Flavors: generic riscv64
+DTB-Id: sifive/hifive-unmatched-a00.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
Machine: Sinlinx SinA31s Development Board
Kernel-Flavors: armmp armmp-lpae
Boot-Script-Path: /boot/boot.scr
--
2.34.1
From 44be15212b83a2c72de6a0c8a79c49cef7442494 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt
Date: Tue, 8 Mar 2022 11:24:30 +0100
Subject: [PATCH 1/3] riscv64: add bootscr.uboot-generic
riscv64 uses booti not bootz. So we have to add a separate
bootscr.uboot-generic.
Signed-off-by: Heinrich Schuchardt
---
bootscript/riscv64/bootscr.uboot-generic | 56
1 file changed, 56 insertions(+)
create mode 100644 bootscript/riscv64/bootscr.uboot-generic
diff --git a/bootscript/riscv64/bootscr.uboot-generic b/bootscript/riscv64/bootscr.uboot-generic
new file mode 100644
index 000..33f90d2
--- /dev/null
+++ b/bootscript/riscv64/bootscr.uboot-generic
@@ -0,0 +1,56 @@
+# Bootscript using the new unified bootcmd handling
+#
+# Expects to be called with the following environment variables set:
+#
+# devtype e.g. mmc/scsi etc
+# devnum The device number of the given type
+# bootpart The partition containing the boot files
+# distro_bootpart The partition containing the boot files
+# (introduced in u-boot mainline 2016.01)
+# prefix Prefix within the boot partiion to the boot files
+# kernel_addr_rAddress to load the kernel to
+# fdt_addr_r Address to load the FDT to
+# ramdisk_addr_r Address to load the initrd to.
+#
+# The uboot must support the booti and generic filesystem load commands.
+
+if test -n "${console}"; then
+ setenv bootargs "${bootargs} console=${console}"
+fi
+
+setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@
+@@UBOOT_ENV_EXTRA@@
+
+if test -z "${fk_kvers}"; then
+ setenv fk_kvers '@@KERNEL_VERSION@@'
+fi
+
+# These two blocks should be the same apart from the use of
+# ${fk_kvers} in the first, the syntax supported by u-boot does not
+# lend itself to removing this duplication.
+
+if test -n "${fdtfile}"; then
+ setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
+else
+ setenv fdtpath dtb-${fk_kvers}
+fi
+
+if test -z "${distro_bootpart}"; then
+ setenv partition ${bootpart}
+else
+ setenv partition ${distro_bootpart}
+fi
+
+@@UBOOT_PREBOOT_EXTRA@@
+
+load ${devtype} ${devnum}:${partition} ${kernel_addr
Bug#1006918: docker.io: RISC-V support missing for docker.io
Package: docker.io Version: 20.10.11+dfsg1-2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu jammy ubuntu-patch Dear Maintainer, docker.io can be easily enabled to support the riscv64 architecture by adding it in debian control. *** /tmp/tmp8s296zdv/bug_body In Ubuntu, the attached patch was applied to achieve the following: * Enable riscv64 architecture (LP: #1963920) Thanks for considering the patch. Best regards Heinrich -- System Information: Debian Release: bookworm/sid APT prefers jammy APT policy: (500, 'jammy') Architecture: riscv64 Kernel: Linux 5.15.0-1004-generic (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru docker.io-20.10.12/debian/control docker.io-20.10.12/debian/control --- docker.io-20.10.12/debian/control 2022-01-14 20:23:16.0 +0100 +++ docker.io-20.10.12/debian/control 2022-03-07 16:57:50.0 +0100 @@ -1,8 +1,7 @@ Source: docker.io Section: admin Priority: optional -Maintainer: Ubuntu Developers -XSBC-Original-Maintainer: Paul Tagliamonte +Maintainer: Paul Tagliamonte Uploaders: Docker Packaging Team , Tianon Gravi Build-Conflicts: golang-github-docker-docker-dev @@ -32,7 +31,7 @@ XS-Go-Import-Path: github.com/docker/docker Package: docker.io -Architecture: amd64 arm64 armhf i386 ppc64el s390x +Architecture: amd64 arm64 armhf i386 ppc64el riscv64 s390x Depends: adduser, containerd (>= 1.2.6-0ubuntu1~), iptables,
Bug#1006765: ITS: sispmctl
Package: sispmctl Version: 3.1-1 Severity: important X-Debbugs-CC: m...@qa.debian.org X-Debbugs-CC: Uwe Hermann The current Debian package has major deficiencies: The most important one being that current hardware is not supported (#929612) New upstream releases resolving the issues have not been packaged for years by Debian. Responses by the package maintainer are missing. As I am the maintainer of the upstream package in https://sourceforge.net/projects/sispmctl/ I would like to take over the maintainership for the package. Best regards Heinrich Schuchardt
Bug#1003395: plfit FTBFS on s390x
Control: tags -1 + patch As already indicated in https://github.com/ntamas/plfit/issues/38 the problem is related to the size of long double. The appended debdiff solved the problem on Ubuntu Jammy by forcing long double to 64bit. Best regards Heinrichdiff -Nru plfit-0.9.3+ds/debian/changelog plfit-0.9.3+ds/debian/changelog --- plfit-0.9.3+ds/debian/changelog 2022-01-13 21:16:01.0 +0100 +++ plfit-0.9.3+ds/debian/changelog 2022-02-25 14:48:50.0 +0100 @@ -1,3 +1,9 @@ +plfit (0.9.3+ds-1ubuntu1) jammy; urgency=medium + + * use 64bit long double on s390x (LP: #1962311) + + -- Heinrich Schuchardt Fri, 25 Feb 2022 14:48:50 +0100 + plfit (0.9.3+ds-1build1) jammy; urgency=medium * No-change rebuild with Python 3.10 as default version diff -Nru plfit-0.9.3+ds/debian/control plfit-0.9.3+ds/debian/control --- plfit-0.9.3+ds/debian/control 2021-11-11 16:14:27.0 +0100 +++ plfit-0.9.3+ds/debian/control 2022-02-25 14:20:56.0 +0100 @@ -1,5 +1,6 @@ Source: plfit -Maintainer: Debian Science Maintainers +Maintainer: Ubuntu Developers +XSCB-Original-Maintainer: Debian Science Maintainers Uploaders: Jerome Benoit Section: math Priority: optional diff -Nru plfit-0.9.3+ds/debian/rules plfit-0.9.3+ds/debian/rules --- plfit-0.9.3+ds/debian/rules 2021-11-16 15:06:43.0 +0100 +++ plfit-0.9.3+ds/debian/rules 2022-02-25 14:45:09.0 +0100 @@ -7,6 +7,11 @@ BUILDIR_STATIC=_BUILD_STATIC BUILDIR_SHARED=_BUILD_SHARED +DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH 2>/dev/null) +ifneq (,$(filter s390x,$(DEB_HOST_ARCH))) +export DEB_CFLAGS_APPEND = -mlong-double-64 +endif + %: dh $@ --buildsystem=cmake --with python3 --builddirectory=$(BUILDIR_SHARED)
Bug#986844: ranger: ftbfs - autopkgtest flakiness
The problem is still evident in Ubuntu's testing landscape https://autopkgtest.ubuntu.com/packages/r/ranger/jammy/amd64 and in Debian https://tests.reproducible-builds.org/debian/history/armhf/ranger.html Ubuntu maintainers would prefer to avoid a diff to Debian. Could you, please, consider the suggested patch. Best regards Heinrich
Bug#995402: libclass-dbi-sweet-perl: FTBFS: test failure
Related Ubuntu bug https://bugs.launchpad.net/debiantesting/+bug/1961751 Suggested solution: drop package as upstream is not maintained anymore
Bug#1005802: autopkgtest-buildvm-ubuntu-cloud does not use SMP
Package: autopkgtest Version: 5.19 Severity: wishlist autopkgtest-buildvm-ubuntu-cloud is quite slow due to QEMU running on a single core: qemu-system-x86_64 -m 512 -smp 1 cpus=2 would be a more reasonable default value. This may require raising the default memory size too. The command should provide a parameter to set the number of cpu cores to use. Best regards Heinrich
Bug#1003155: opensbi: tar.xz is not supported by 'git archive'
Package: opensbi
Version: 1.0-1
Severity: normal
Dear Vagrant,
The opensbi package has a maintainer script debian/bin/git-snapshot with
commands
archive=tar.xz
git archive \
--format=${archive} \
tar.xz is not a valid archive format. 'git archive -l' gives this list:
* tar
* tgz
* tar.gz
* zip
Please, change the maintainer script to use --format=tar and issue a
separate command to compress with xz.
Best regards
Heinrich
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
Bug#999558: unpack_bootimg: TypeError: 'float' object cannot be interpreted as an integer
Package: mkbootimg Version: 1:10.0.0+r36-7 Severity: normal Observed in Ubuntu Impish Launchpad bug 1950789 Unpacking an Android boot image results in an error: $ unpack_bootimg --boot_img akernel boot_magic: b'ANDROID!' Traceback (most recent call last): File "/usr/bin/unpack_bootimg", line 153, in main() File "/usr/bin/unpack_bootimg", line 149, in main unpack_bootimage(args) File "/usr/bin/unpack_bootimg", line 127, in unpack_bootimage extract_image(image_info[0], image_info[1], args.boot_img, File "/usr/bin/unpack_bootimg", line 35, in extract_image bootimage.seek(offset) TypeError: 'float' object cannot be interpreted as an integer unpack_bootimg.py of https://android.googlesource.com/platform/system/tools/mkbootimg (tag: android-s-v2-preview-1) does not show the problem. Best regards Heinrich
Bug#996760: vim: Ubuntu Jammy Jellyfish missing in supported distributions
Package: vim Version: 2:8.2.3455-2 Severity: wishlist The next Ubuntu release will be Jammy Jellyfish. https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668 Please, add it to the list of supported distributions: --- vim-8.2.3455.orig/runtime/syntax/debchangelog.vim +++ vim-8.2.3455/runtime/syntax/debchangelog.vim @@ -24,7 +24,8 @@ let s:supported = [ \ 'jessie', 'stretch', 'buster', 'bullseye', 'bookworm', \ 'trixie', 'sid', 'rc-buggy', \ - \ 'trusty', 'xenial', 'bionic', 'focal', 'hirsute', 'impish', 'devel' + \ 'trusty', 'xenial', 'bionic', 'focal', 'hirsute', 'impish', 'jammy', + \ 'devel' \ ] let s:unsupported = [ \ 'frozen', 'buzz', 'rex', 'bo', 'hamm', 'slink', 'potato', --- vim-8.2.3455.orig/runtime/syntax/debsources.vim +++ vim-8.2.3455/runtime/syntax/debsources.vim @@ -26,7 +26,8 @@ let s:supported = [ \ 'jessie', 'stretch', 'buster', 'bullseye', 'bookworm', \ 'trixie', 'sid', 'rc-buggy', \ - \ 'trusty', 'xenial', 'bionic', 'focal', 'hirsute', 'impish', 'devel' + \ 'trusty', 'xenial', 'bionic', 'focal', 'hirsute', 'impish', 'jammy', + \ 'devel' \ ] let s:unsupported = [ \ 'buzz', 'rex', 'bo', 'hamm', 'slink', 'potato', Best regards Heinrich
Bug#995718: grub2: enable RISC-V support
Package: grub2 Version: 2.04-20 Severity: wishlist When upgrading to grub 2.06, please, consider enabling RISC-V support. The patches currently are still in review upstream. I hold a copy in: https://github.com/xypron/grub-build/tree/qemu-riscv64/patch as 0001-loader-drop-argv-argument-in-grub_initrd_load.patch 0001-efi-add-definition-of-LoadFile2-protocol.patch 0001-efi-implemented-LoadFile2-initrd-loading-protocol-fo.patch 0001-linux-ignore-FDT-unless-we-need-to-modify-it.patch 0001-loader-Move-arm64-linux-loader-to-common-code.patch 0001-RISC-V-Update-image-header.patch 0001-RISC-V-Use-common-linux-loader.patch Best regards Heinrich
Bug#995472: a2jmidid fails to build on RISC-V
Package: a2jmidid
Version: 9-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
Dear Maintainer,
building on RISC-V fails.
In Ubuntu, the attached patch was applied to achieve the following:
* Enable building on RISC-V (LP: #1945803)
Thanks for considering the patch.
-- System Information:
Debian Release: 11.0
APT prefers impish
APT policy: (500, 'impish')
Architecture: riscv64
Kernel: Linux 5.13.0-1003-generic (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
--- a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
1970-01-01 01:00:00.0 +0100
+++ a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
2021-10-01 16:18:06.0 +0200
@@ -0,0 +1,47 @@
+From 2c3fbef6854743416d95d85b1565dde51668488c Mon Sep 17 00:00:00 2001
+From: Heinrich Schuchardt
+Date: Fri, 1 Oct 2021 16:15:29 +0200
+Subject: [PATCH 1/1] sigsegv: enable RISC-V build
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Avoid build error
+
+../sigsegv.c:104:39: error: ‘mcontext_t’ has no member named ‘gregs’;
+did you mean ‘__gregs’?
+ 104 | ucontext->uc_mcontext.gregs[i]
+ | ^
+
+Signed-off-by: Heinrich Schuchardt
+---
+ sigsegv.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/sigsegv.c b/sigsegv.c
+index fb4456e..6930185 100644
+--- a/sigsegv.c
b/sigsegv.c
+@@ -91,7 +91,9 @@ static void signal_segv(int signum, siginfo_t* info,
void*ptr) {
+ a2j_error("info.si_errno = %d", info->si_errno);
+ a2j_error("info.si_code = %d (%s)", info->si_code,
si_codes[info->si_code]);
+ a2j_error("info.si_addr = %p", info->si_addr);
+-#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD_kernel__)
&& !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) &&
!defined(__aarch64__)
++#if !defined(__alpha__) && !defined(__ia64__) && \
++!defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__)
&& \
++!defined(__sh__) && !defined(__aarch64__) && !defined(__riscv)
+ for(i = 0; i < NGREG; i++)
+ a2j_error("reg[%02d] = 0x" REGFORMAT, i,
+ #if defined(__powerpc__) && !defined(__powerpc64__)
+@@ -108,7 +110,7 @@ static void signal_segv(int signum, siginfo_t* info,
void*ptr) {
+ ucontext->uc_mcontext.gregs[i]
+ #endif
+ );
+-#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64 */
++#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64, riscv */
+
+ #if defined(SIGSEGV_STACK_X86) || defined(SIGSEGV_STACK_IA64)
+ # if defined(SIGSEGV_STACK_IA64)
+--
+2.32.0
+
diff -Nru a2jmidid-9/debian/patches/series a2jmidid-9/debian/patches/series
--- a2jmidid-9/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ a2jmidid-9/debian/patches/series2021-10-01 16:18:52.0 +0200
@@ -0,0 +1 @@
+0001-sigsegv-enable-RISC-V-build.patch
Bug#995462: bbrun: fails to build on RISC-V
Package: bbrun Version: 1.6-8 Severity: normal Building on RISC-V fails with: cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode Please, remove debian/patches/05_gcc5-gnu89.patch Best regards Heinrich
Bug#995151: vim: impish missing in debchangelog.vim
Package: vim Version: 2:8.2.2434-3 Severity: minor Please, add impish to the list of supported Ubuntu releases in these lines: usr/share/vim/vim82/syntax/debsources.vim:29: \ 'trusty', 'xenial', 'bionic', 'focal', 'groovy', 'hirsute', 'devel' usr/share/vim/vim82/syntax/debchangelog.vim:27: \ 'trusty', 'xenial', 'bionic', 'focal', 'groovy', 'hirsute', 'devel' Cf. https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1944419 Best regards Heinrich
Bug#992419: U-Boot using wrong memory type for device-trees.
Package: u-boot-sifive Version: 2021.07+dfsg-1 Severity: normal U-Boot currently uses an incorrect memory type EfiReservedMemory for device paths. This leads to boot failures on riscv64 Linux when booting via UEFI (probably due to some further bug in the kernel). Please, consider applying the following patches queued for v2021.10-rc3: [PATCH 4/5] efi_loader: use EfiBootServicesData for device path https://lists.denx.de/pipermail/u-boot/2021-August/458248.html [PATCH 5/5] efi_loader: use EfiBootServicesData for DP to text https://lists.denx.de/pipermail/u-boot/2021-August/458252.html Best regards Heinrich
Bug#992094: e2fsprogs: mke2fs fails to create file system
Package: e2fsprogs Version: 1.46.3-1 Severity: normal https://ci.debian.net/data/autopkgtest/unstable/amd64/e/e2fsprogs/14285096/log.gz shows the following errors for debian/tests/fuse2fs: mke2fs: No such file or directory while trying to determine filesystem size /sbin/e2label: No such file or directory while trying to open /tmp/autopkgtest-lxc.xu4_8zmj/downtmp/autopkgtest_tmp/test-image.img Somehow mke2fs cannot interpret the size argument 8M. The debian/tests/ directory is unchanged relative to release 1.46.2. Hence this is a regression which needs to be fixed. Best regards Heinrich
Bug#992035: mozc not built for riscv64
Package: mozc Version: 2.26.4220.100+dfsg-4 Severity: normal Dear maintainer, please, add architecture riscv64 to the mozc build targets. Best regards Heinrich
Bug#991933: mokutil: RISC-V build missing
Package: mokutil Version: 0.4.0-1 Severity: normal Tags: patch Usertags: origin-ubuntu impish ubuntu-patch Dear maintainer, building mokutil for RISC-V only requires debian/control to be adjusted. See Ubuntu package mokutil 0.4.0-1ubuntu1. U-Boot already supports booting via UEFI on RISC-V including secure boot. With mokutil we can display the relevant information. As SetVariable() is not implemented we cannot update anything. EDK II should allow setting variables. Currently the HiFive Unleashed is the only supported RISC-V board. Best regards Heinrich
Bug#991854: dmidecode
On 04.08.21 00:51, Jessica Clarke wrote: On 3 Aug 2021, at 23:42, Paul Wise wrote: On Tue, 03 Aug 2021 20:14:57 +0200 Jörg Frings-Fürst wrote: because of the bugreport[1] I would like to ask here if it is useful to compile dmidecode also for riscv64? Apparently the SMBIOS spec v3.3.0 and later includes RISC-V support: https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md I've no idea if dmidecode meaningfully works on RISC-V hardware though? I’m unaware of any systems that provide it. The whole EDK2+ACPI+SMBIOS ecosystem remains rather far off for RISC-V at this point, especially given ACPI will only include bindings for the future generation of interrupt controllers and thus will never be supported for the current generation of hardware. If it compiles then it might as well be enabled, but this hardly seems essential, nor worth Ubuntu carrying a patch for. Looking at dmidecode itself, the primary reason it shouldn’t be Architecture: any is it assumes unaligned access and little-endianness by default unless you put -DALIGNMENT_WORKAROUND/-DBIGENDIAN in CFLAGS manually, which is atrocious software engineering practice in many respects... and for added fun it defines its own u64 type as a struct containing a pair of u32’s (also manually typedef’ed to unsigned int) whose order depends on BIGENDIAN. Jess When booting the HiFive Unmatched via U-Boot's UEFI implementation dmidecode will show information about the firmware and the board serial number: Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2021.10-rc1-00106-g98b352ffeb Release Date: 10/01/2021 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 21.10 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Unknown Product Name: Unknown Product Version: Not Specified Serial Number: SF105SZ212200xxx UUID: 30314653-5335-325a-3132-323030373036 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Further work in U-Boot will be needed to fill the missing fields. Best regards Heinrich
Bug#991854: dmidecode: not build for riscv64
Package: dmidecode
Version: 3.3-2
Severity: normal
Tags: patch
Usertags: origin-ubuntu impish ubuntu-patch
Dear Maintainer,
please, enable building dmidecode on riscv64. This requires only changes
to debian/control:
diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
--- dmidecode-3.3/debian/control2021-05-07 06:54:34.0 +
+++ dmidecode-3.3/debian/control2021-08-02 15:22:49.0 +
@@ -11,7 +11,7 @@
Package: dmidecode
Priority: important
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: SMBIOS/DMI table decoder
@@ -30,7 +30,7 @@
Package: dmidecode-udeb
Section: debian-installer
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
Package-Type: udeb
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: SMBIOS/DMI table decoder (udeb)
Best regards
Heinrich
diff -Nru dmidecode-3.3/debian/changelog dmidecode-3.3/debian/changelog
--- dmidecode-3.3/debian/changelog 2021-05-17 16:53:43.0 +
+++ dmidecode-3.3/debian/changelog 2021-08-02 15:25:54.0 +
@@ -1,3 +1,9 @@
+dmidecode (3.3-2ubuntu1) impish; urgency=medium
+
+ * Add riscv64 build architecture (LP: #1938705)
+
+ -- Heinrich Schuchardt Mon, 02 Aug 2021 17:25:54 +0200
+
dmidecode (3.3-2) unstable; urgency=medium
* Add upstream recommended patches (Closes: #987033):
diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
--- dmidecode-3.3/debian/control 2021-05-07 06:54:34.0 +
+++ dmidecode-3.3/debian/control 2021-08-02 15:22:49.0 +
@@ -11,7 +11,7 @@
Package: dmidecode
Priority: important
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: SMBIOS/DMI table decoder
@@ -30,7 +30,7 @@
Package: dmidecode-udeb
Section: debian-installer
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
Package-Type: udeb
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: SMBIOS/DMI table decoder (udeb)
Bug#988217: bootefi causes boot failure with boot.scr
The original problem report showed the following situation was hit:
common/malloc_simple.c:29:
log_err("alloc space exhausted\n");
You cannot expect normal system behavior when reaching this situation.
The available space for simple malloc is defined by:
CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000
CONFIG_SYS_MALLOC_F_LEN=0x2000
I assume that the problem arises in main U-Boot not in SPL. Please,
increase CONFIG_SYS_MALLOC_F_LEN and check if this error message goes away.
Best regards
Heinrich
Bug#864807: b53_mdio module doesn't get loaded automatically on Lamobo R1
On 5/15/21 3:15 PM, Salvatore Bonaccorso wrote: Hi, Is this bug still an issue with recent kernels or can the issue be closed? Regards, Salvatore I am not using this board anymore. Best regards Heinrich
Bug#988413: u-boot-tools: mkeficapsule missing
Package: u-boot-tools Version: 2021.04~rc4+dfsg-1 Severity: wishlist Dear Vagrant, please, consider adding mkeficapsule to the u-boot-tools package. The tool is need for preparing capsules for updating the firmware using the UEFI API. A description is available at https://u-boot.readthedocs.io/en/latest/board/emulation/qemu_capsule_update.html?highlight=mkeficapsule#enabling-capsule-authentication Best regards Heinrich
Bug#988231: gnu-efi: package for riscv64
After updating the source the only change I needed for packaging was:
--- debian/control 2021-02-04 11:03:03.0 +
+++ debian/control 2021-05-08 10:27:56.638548003 +
@@ -13,7 +13,7 @@
Homepage: http://sourceforge.net/projects/gnu-efi/
Package: gnu-efi
-Architecture: any-amd64 any-i386 any-arm64 armhf
+Architecture: any-amd64 any-i386 any-arm64 armhf riscv64
Depends: ${misc:Depends}
Description: Library for developing EFI applications
GNU toolchain for building applications that can run in the environment
Bug#988231: gnu-efi: package for riscv64
Package: gnu-efi
Version: 3.0.9-2
Severity: wishlist
gnu-efi is a build dependency for a bunch of other packages. Currently
it is missing on RISC-V.
My patches to support riscv64 were merged with commit 3676bc353c83
("Merge /u/xypron/gnu-efi/ branch riscv64 into master").
Please, consider packaging for riscv64. I guess due to the freeze this
would have to go to experimental first.
Best regards
Heinrich
Bug#983475: shim-signed-common: failure to install w/o SetVariable()
Am 30. April 2021 20:06:22 MESZ schrieb Steve McIntyre : >Control: reassign -1 grub2-common > >Hi Heinrich, > >[ reassigning to grub2-common, the package which includes grub-install >] > >On Wed, Feb 24, 2021 at 09:08:15PM +0100, Heinrich Schuchardt wrote: >>Package: shim-signed-common >>Version: 1.33+15+1533136590.3beb971-7 >>Severity: normal >> >>Dear Maintainer, >> >>on systems using U-Boot as firmware the UEFI runtime service >>SetVariable() is not available. Variable Boot has to be set >manually >>from the U-Boot console. >> >>The installation of shim-signed-common fails with: >> >>The following NEW packages will be installed: >> shim-signed-common >>0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. >>Need to get 0 B/13.3 kB of archives. >>After this operation, 50.2 kB of additional disk space will be used. >>Preconfiguring packages ... >>Can't exec "/tmp/shim-signed-common.config.PoZZwF": Permission denied >at >>/usr/lib/aarch64-linux-gnu/perl-base/IPC/Open3.pm line 178. >>open2: exec of /tmp/shim-signed-common.config.PoZZwF configure >failed: >>Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59. >>Selecting previously unselected package shim-signed-common. >>(Reading database ... 149437 files and directories currently >installed.) >>Preparing to unpack >>.../shim-signed-common_1.33+15+1533136590.3beb971-7_all.deb ... >>Unpacking shim-signed-common (1.33+15+1533136590.3beb971-7) ... >>Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ... >>Installing for arm64-efi platform. >>grub-install: warning: Cannot set EFI variable Boot. >>grub-install: warning: efivarfs_set_variable: failed to create >>/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c >>for writing: Read-only file system. >>grub-install: warning: _efi_set_variable_mode: ops->set_variable() >>failed: Read-only file system. >>grub-install: error: failed to register the EFI boot entry: Read-only >>file system. >>dpkg: error processing package shim-signed-common (--configure): >> installed shim-signed-common package post-installation script >>subprocess returned error exit status 1 >>Errors were encountered while processing: >> shim-signed-common >> >>To make the package usable with U-Boot the installation should not >fail >>but complete with a warning. > >Apologies for not responding earlier... > >This is a complicated situation, and there is no single right answer >at the moment. On platforms where EFI variables are settable >(e.g. most x86 machines, arm64 server machines), we absolutely *must* >report failure to install boot variables - this will make the system >fail to boot after installation. But on other platforms (e.g. most >current U-Boot systems), we can't install variables and instead we'll >have to install to the removable media path. AFAIK the U-Boot >developers are trying to add support for setting EFI variables on many >of their platforms, so hopefully this problem will go away soon. This will require OP-TEE and StandAloneMM. The problem will persist on most boards > >In the meantime, to do a better job we need a reliable way to detect >if the platform can't support writing of EFI variables. Suggestions >welcome. :-/ SetVariable() must return EFI_UNSUPPORTED in this case. With UEFI 2.8+ you could also look at the EFI_RT_PROPERTIES_TABLE configuration table to identify unsupported runtime services. But Linux will only provide access to the table with CONFIG_EFI_TEST=y. Best regards Heinrich
Bug#986708: Orphan sispmctl
Package: wnpp Severity: normal The package maintainer of package sispmctl has not shown any activity since 2012: * Bug reports remain unanswered. * Upstream releases are ignored. The current release is available at https://sourceforge.net/projects/sispmctl/files/sispmctl/sispmctl-4.9/ For repackaging you could use https://github.com/xypron/sispmctl/tree/debian/debian as a starting point. Best regards Heinrich
Bug#984705: kamoso: unable to find or load wrappercamerabinsrc plugin
Package: kamoso
X-Debbugs-Cc: xypron.g...@gmx.de
Version: 20.12.1-1
Severity: normal
Dear Maintainer,
when trying to run kamoso the following errors where shown on the
console ending with "unable to find or load wrappercamerabinsrc plugin".
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ActionToolBar.qml:110:18:
QML ToolBarLayout: Binding loop detected for property "actions"
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ActionToolBar.qml:110:18:
QML ToolBarLayout: Binding loop detected for property "actions"
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ActionToolBar.qml:110:18:
QML ToolBarLayout: Binding loop detected for property "actions"
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:162:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:99:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/OverlayDrawer.qml:284:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/OverlayDrawer.qml:284:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:162:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:99:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/ActionButton.qml:221:13:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/ActionButton.qml:209:13:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:162:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:99:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:162:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:99:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:139:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
Bug#983475: shim-signed-common: failure to install w/o SetVariable()
Package: shim-signed-common Version: 1.33+15+1533136590.3beb971-7 Severity: normal Dear Maintainer, on systems using U-Boot as firmware the UEFI runtime service SetVariable() is not available. Variable Boot has to be set manually from the U-Boot console. The installation of shim-signed-common fails with: The following NEW packages will be installed: shim-signed-common 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/13.3 kB of archives. After this operation, 50.2 kB of additional disk space will be used. Preconfiguring packages ... Can't exec "/tmp/shim-signed-common.config.PoZZwF": Permission denied at /usr/lib/aarch64-linux-gnu/perl-base/IPC/Open3.pm line 178. open2: exec of /tmp/shim-signed-common.config.PoZZwF configure failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59. Selecting previously unselected package shim-signed-common. (Reading database ... 149437 files and directories currently installed.) Preparing to unpack .../shim-signed-common_1.33+15+1533136590.3beb971-7_all.deb ... Unpacking shim-signed-common (1.33+15+1533136590.3beb971-7) ... Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ... Installing for arm64-efi platform. grub-install: warning: Cannot set EFI variable Boot. grub-install: warning: efivarfs_set_variable: failed to create /sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system. grub-install: error: failed to register the EFI boot entry: Read-only file system. dpkg: error processing package shim-signed-common (--configure): installed shim-signed-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: shim-signed-common To make the package usable with U-Boot the installation should not fail but complete with a warning. Best regards Heinrich Schuchardt -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-3-arm64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shim-signed-common depends on: ii debconf [debconf-2.0] 1.5.74 ii mokutil0.3.0+1538710437.fb6250f-1+b1 shim-signed-common recommends no packages. shim-signed-common suggests no packages. -- debconf information: shim/enable_secureboot: false shim/title/secureboot: shim/disable_secureboot: true shim/error/secureboot_key_mismatch: shim/error/bad_secureboot_key: shim/secureboot_explanation:
Bug#983034: plasma-workspace-wayland: hanging in ksplashqml
On 19.02.21 19:40, Dennis Filder wrote: > Control: tag -1 + moreinfo bullseye sid > > If you cannot switch to console with Ctrl-Alt-F2 then this is a strong > indicator that the bug is in the kernel, probably nouveau. > > If you can reproduce this reliably it would help a lot if you could > provide the output of these commands after the bug has happened: > > dmesg > strace -f -p $(pidof ksplashqml) 2>&1 | dd bs=1k count=20 > journalctl -ab > > You may have to run some of them as root. > dmesg shows a crash in the nouveau driver: [ 441.529012] [ cut here ] [ 441.529076] WARNING: CPU: 1 PID: 1964 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put+0x84/0x9c [nouveau] [ 441.529078] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc rfkill overlay nls_ascii nls_cp437 vfat fat snd_hda_codec_hdmi aes_ce_blk crypto_simd snd_hda_intel cryptd snd_intel_dspcfg aes_ce_cipher snd_hda_codec ghash_ce gf128mul libaes sha2_ce snd_hda_core snd_hwdep snd_pcm sha256_arm64 sha1_ce snd_timer evdev snd soundcore sg efi_pstore omap_rng rng_core sbsa_gwdt armada_thermal fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod hid_generic usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic nouveau i2c_mux_pca954x i2c_mux ahci_platform libahci_platform libahci marvell10g libata crct10dif_ce [ 441.529194] crct10dif_common scsi_mod i2c_algo_bit ttm xhci_plat_hcd drm_kms_helper marvell xhci_hcd drm mvpp2 usbcore i2c_mv64xxx mvmdio mdio_devres sfp mdio_i2c phylink of_mdio phy_generic fixed_phy libphy sdhci_xenon_driver sdhci_pltfm usb_common phy_mvebu_cp110_comphy fixed sdhci [ 441.529236] CPU: 1 PID: 1964 Comm: kworker/1:0 Not tainted 5.10.0-3-arm64 #1 Debian 5.10.13-1 [ 441.529238] Hardware name: SolidRun Armada 8040 MacchiatoBin/Armada 8040 MacchiatoBin, BIOS EDK II Mar 26 2020 [ 441.529284] Workqueue: events nouveau_cli_work [nouveau] [ 441.529289] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 441.529332] pc : nvif_vmm_put+0x84/0x9c [nouveau] [ 441.529375] lr : nvif_vmm_put+0x78/0x9c [nouveau] [ 441.529376] sp : 8000119cbc80 [ 441.529378] x29: 8000119cbc80 x28: · [ 441.529383] x27: 386ac5329f28 x26: 0001· [ 441.529387] x25: dead0100 x24: dead0122· [ 441.529391] x23: 386ac5329f18 x22: 386ac5077300· [ 441.529395] x21: 386ac5329f08 x20: 386ac2b00080· [ 441.529398] x19: 8000119cbce8 x18: · [ 441.529402] x17: x16: bbff1d518580· [ 441.529406] x15: x14: · [ 441.529410] x13: x12: 0040· [ 441.529414] x11: bbff1dcf5ec0 x10: 0ad0· [ 441.529417] x9 : bbfea5a3d3f0 x8 : fefefefefefefeff· [ 441.529421] x7 : 8888 x6 : 8000119cbcb8· [ 441.529425] x5 : x4 : 0008· [ 441.529429] x3 : 048a x2 : · [ 441.529433] x1 : x0 : fffe· [ 441.529437] Call trace: [ 441.529480] nvif_vmm_put+0x84/0x9c [nouveau] [ 441.529523] nouveau_vma_del+0x9c/0xe0 [nouveau] [ 441.529565] nouveau_gem_object_delete_work+0x48/0x80 [nouveau] [ 441.529607] nouveau_cli_work+0xe8/0x180 [nouveau] [ 441.529616] process_one_work+0x1d4/0x490 [ 441.529619] worker_thread+0x188/0x504 [ 441.529622] kthread+0x130/0x134 [ 441.529625] ret_from_fork+0x10/0x38 [ 441.529628] ---[ end trace 28675099a596659e ]--- :set nonumber Best regards Heinrich
Bug#983034: plasma-workspace-wayland: hanging in ksplashqml
Package: plasma-workspace-wayland Version: 4:5.20.5-3 Severity: grave Dear Maintainer, from SDDM I try to start a Wayland KDE session. The whole GUI freezes. CTRL-ALT-FN2 cannot be used to open a terminal session. SSH login is still possible. Top reports 100 % CPU load for ksplashqml. Mainboard is MacchiatoBIN with 16 GiB RAM. Video card is GeForce GT 710 with nouveau driver. Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-3-arm64 root=UUID= ro quiet The problem only occurs in Wayland sessions. X11 KDE is working fine. Best regards Heinrich Schuchardt -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-3-arm64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-workspace-wayland depends on: ii kwayland-integration 5.20.5-1 ii kwin-wayland 4:5.20.5-1 ii libc6 2.31-9 ii libkf5configcore5 5.78.0-4 ii libkf5coreaddons5 5.78.0-2 ii libkworkspace5-5 4:5.20.5-3 ii libqt5core5a 5.15.2+dfsg-4 ii libqt5dbus5 5.15.2+dfsg-4 ii libstdc++610.2.1-6 ii plasma-workspace 4:5.20.5-3 ii qtwayland55.15.2-2 plasma-workspace-wayland recommends no packages. plasma-workspace-wayland suggests no packages. -- no debconf information
Bug#982842: open-iscsi: do not use iscsistart in the boot process
On 15.02.21 18:02, Lee Duncan wrote: > On 2/15/21 6:48 AM, Ritesh Raj Sarraf wrote: > I cannot access this bug, so I will reply to all here ... By CCing 982...@bugs.debian.org the bug report is updated. > > In general, you do not set up initrd to boot into all iSCSI targets, > only the ones with "startup" set to "onboot". Then, later, as part of > the system coming up, once the real root is established and networking > is up, do you log into all "automatic" targets using open-iscsi. > > So the idea isn't to log into all targets at initrd time, just the same > ones you log into now (i.e. "onboot" targets, needed to boot) using > iscsid/iscsiadm instead of iscsistart. Note that SUSE only supports the > root and /usr partitions being remote at boot time. If you have > something like /opt you want to mount, it has to be done later (in our > systems). > > I hope this clarification helps. > My current configuration is: iscsid.conf:40: # node.startup = automatic nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:4: node.startup = manual nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:52: node.conn[0].startup = manual File /etc/iscsi/iscsi.initramfs specifies the root device. HWADDR="01:02:03:04:05:06" ISCSI_TARGET_NAME="iqn.2000-01.de.xypron:pine-a64-lts" ISCSI_TARGET_IP="192.168.0.1" ISCSI_TARGET_PORT="3260" ISCSI_TARGET_GROUP="1" ISCSI_USERNAME="user" ISCSI_PASSWORD="password" Where would "onboot" fit into the image? What makes a target an "onboot" target? Do you simply mean the one specified in /etc/iscsi/iscsi.initramfs? Best regards Heinrich
Bug#982842: open-iscsi: do not use iscsistart in the boot process
Package: open-iscsi Version: 2.1.3-2 Severity: wishlist An upstream maintainer suggested that Debian should not use iscsistart for booting from an iSCSI volume but instead include iscsid and iscsiadm in the initrd. The same is already done in SUSE. Please, consider such a change for Debian Bookworm. Forwarded Message Subject:Re: [open-iscsi/open-iscsi] iscsistart fails with 15 - session exists with ipv6 (#241) Date: Fri, 12 Feb 2021 15:29:41 -0800 From: Lee Duncan Reply-To: open-iscsi/open-iscsi To: open-iscsi/open-iscsi CC: Heinrich Schuchardt , Mention @gonzoleeman <https://github.com/gonzoleeman> Let me emphasize again: iscsistart is not great. Using iscsiadm/iscsid is still the recommended way to use open-iscsi. Debian uses iscsistart when booting from iSCSI. Is this the wrong way to do it? Cf. https://salsa.debian.org/linux-blocks-team/open-iscsi/-/blob/master/debian/extra/initramfs.hook <https://salsa.debian.org/linux-blocks-team/open-iscsi/-/blob/master/debian/extra/initramfs.hook> The proper way to use open-iscsi is to (1) start the daemon, then (2) use iscsiadm to talk to the daemon. There are a couple of problems with the iscsistart approach: first, it has no error handling. All the error handling is built into iscsid. Sure, some of it might have gotten copied to iscsistart, but not most of it. For example, once iscsistart exits, there is *no* error handling at all. The second problem is that iscsistart is not maintained, since it's not used as much. It also has other issues, like not setting up the session correctly, so that trying to log out of that session fails on the first attempt. I'm fairly sure this approach was taken because it's more complex to start them daemon then use iscsiadm. But it's not a lot more complex. That's the approach we take at SUSE. To be fair, there are shortcomings even when using iscsid/iscsiadm. In our case, when we switch from virtual root to the real root disc, we stop then restart the iscsid daemon. So even in our case there is a window when no error handling can occur. But iscsistart is still part of the open-iscsi distribution, so until and unless somebody removes it, it's supported, even if I like to discourage it's use. (I also discourage use of iscsi NOPs, if that matters, so this isn't the only windmill I tilt at.) I hope that answers your question. If you wanted to convert debian to using iscsid/iscsiadm, I'd be glad to help!
Bug#982369: [PATCH] all.db: add support for ODROID-C4, -HC4, -N2, -N2Plus
Package: flash-kernel Version: 3.104 Severity: normal Tags: patch Add missing data base entries for: * Hardkernel ODROID-C4 * Hardkernel ODROID-HC4 * Hardkernel ODROID-N2 * Hardkernel ODROID-N2Plus Signed-off-by: Heinrich Schuchardt --- db/all.db | 28 1 file changed, 28 insertions(+) diff --git a/db/all.db b/db/all.db index 0d1d33d..426247f 100644 --- a/db/all.db +++ b/db/all.db @@ -584,6 +584,34 @@ Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools +Machine: Hardkernel ODROID-C4 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-sm1-odroid-c4.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-HC4 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-sm1-odroid-hc4.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-N2 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-g12b-odroid-n2.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-N2Plus +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-g12b-odroid-n2-plus.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Hardkernel ODROID-U3 board based on Exynos4412 Kernel-Flavors: armmp armmp-lpae DTB-Id: exynos4412-odroidu3.dtb -- 2.30.0
Bug#980085: open-iscsi: initiator does not connect
On 2/7/21 8:36 PM, Chris Hofstaedtler wrote: Hello Heinrich, I'm going to upload upstream's fix. Maybe you can give it a try. Best, Chris Debian release 2.1.3-2 added +upstream/0001-iscsiadm-Fix-memory-leak-in-iscsiadm.patch +upstream/0002-Fix-iscsiadm-segfault-when-exiting.patch +upstream/0003-Fix-iscsistart-login-issue-when-target-is-delayed.patch I have built the package from https://salsa.debian.org/linux-blocks-team/open-iscsi commit 7334ed475e26b8 This works for me but still shows the warning iscsistart: initiator reported error (15 - session exists) Tested-by: Heinrich Schuchardt
Bug#980085: open-iscsi: initiator does not connect
Hello Chris,
on my system a partial revert solves the problem:
diff --git a/usr/iscsid_req.c b/usr/iscsid_req.c
index a3aba6d..3bbf5b9 100644
--- a/usr/iscsid_req.c
+++ b/usr/iscsid_req.c
@@ -156,7 +156,7 @@ int iscsid_response(int fd, iscsiadm_cmd_e cmd,
iscsiadm_rsp_t *rsp,
if (!err) {
if (poll_wait)
continue;
- return ISCSI_ERR_SESSION_NOT_CONNECTED;
+ return ISCSI_ERR_ISCSID_NOTCONN;
} else if (err < 0) {
if (errno == EINTR)
continue;
[8.110782] SCSI subsystem initialized
[8.121305] Loading iSCSI transport class v2.0-870.
[8.136984] iscsi: registered transport (tcp)
iscsistart: version 2.1.3+
iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1
iscsistart: initiator reported error (15 - session exists)
iscsistart: version 2.1.3+
[ 11.116244] dwmac-sun8i 1c3.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[ 11.124686] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.[ 11.231909]
scsi host0: iSCSI Initiator over TCP/IP
168.0.1:3260,1
iscsistart: Connection1:0 to [target: iqn.2000-01.de.xypron:disk1, po[
11.279574] scsi 0:0:0:0: RAID IET Controller
0001 PQ: 0 ANSI: 5
rtal: 192.168.0.1,3260] through [iface: default] is operational now
[ 11.301919] scsi 0:0:0:1: Direct-Access IET VIRTUAL-DISK
0001 PQ: 0 ANSI: 5
[ 11.327734] sd 0:0:0:1: Power-on or device reset occurred
[ 11.336418] sd 0:0:0:1: [sda] 100663296 512-byte logical blocks:
(51.5 GB/48.0 GiB)
[ 11.344182] sd 0:0:0:1: [sda] 4096-byte physical blocks
[ 11.350139] sd 0:0:0:1: [sda] Write Protect is off
[ 11.356083] sd 0:0:0:1: [sda] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 11.392053] sda: sda1 sda2 sda3 sda4
[ 11.403161] sd 0:0:0:1: [sda] Attached SCSI disk
Maybe you want to check this with your short-time disabling of network
in QEMU.
Best regards
Heinrich
Bug#980085: open-iscsi: initiator does not connect
On 14.01.21 20:26, Chris Hofstaedtler wrote: > Hi everyone, > > * Chris Hofstaedtler [210114 19:20]: >> * Heinrich Schuchardt [210114 18:52]: >>>>> iscsistart: version 2.1.3 >>>>> iscsistart: Logging into iqn.2000-01.de.xypron:disk1 >>>>> 192.168.0.1:3260,1 >>>>> iscsistart: initiator reported error (32 - target likely not >>>>> connected) >>>>> >>>>> I downgraded to open-iscsi and libopeniscsiusr to version 2.1.2-2 and >>>>> reinstalled the kernel package. >> >> Could you try rebuilding 2.1.3-1 with this upstream patch reverted? >> https://github.com/open-iscsi/open-iscsi/commit/9258c8eae046d98511d92912983778ca57ba201f >> >> That seems to have changed timeout behaviour, so maybe that "fixed" >> something broken that nevertheless was needed on your system. > > Heinrich: here is a proposed source package: > https://people.debian.org/~zeha/open-iscsi/ > (incl. amd64 binaries, but they are useless to you) > > I gave this some more tries in my test VM, and from what I can tell > there is a race between the iscsi login and the NIC becoming ready. > (In my test VM, the NIC is immediately ready - but I can "unplug" it > and "plug" it back in in just the right moment to simulate a slow > link setup.) > > The 2.1.2 code gave you just a bit more time (and maybe one retry) > to win this race. The 2.1.3 code just flat fails when the NIC is not > ready, at iscsi login time. > > Maybe the old variant is good enough on Heinrich's system. But it > looks like this would break on an "enterprise network", where the > Ethernet link would take many seconds to come online... > > Not sure if we can claim "iscsi root is supposed to work" where it > would usually be deployed. But I don't know about 2.0.x or earlier. > > Chris > Dear Chris, reverting the patch solves my problem: iscsistart: version 2.1.3 iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1 iscsistart: initiator reported error (15 - session exists) iscsistart: version 2.1.3 [ 10.636168] dwmac-sun8i 1c3.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 10.644613] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.[ 10.732030] scsi host0: iSCSI Initiator over TCP/IP 168.0.1:3260,1 iscsistart: Connection1:0 to [target: iqn.2000-01.de.xypron:disk1, po[ 10.779595] scsi 0:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 rtal: 192.168.0.1,3260] through [iface: default] is operational now [ 10.801637] scsi 0:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 [ 10.826829] sd 0:0:0:1: Power-on or device reset occurred [ 10.835649] sd 0:0:0:1: [sda] 100663296 512-byte logical blocks: (51.5 GB/48.0 GiB) [ 10.843421] sd 0:0:0:1: [sda] 4096-byte physical blocks [ 10.849319] sd 0:0:0:1: [sda] Write Protect is off [ 10.855275] sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Best regards Heinrich
Bug#980085: open-iscsi: initiator does not connect
On 14.01.21 17:02, Ritesh Raj Sarraf wrote: > Hi Heinrich, > > On Thu, 2021-01-14 at 11:23 +0100, Heinrich Schuchardt wrote: >> On my system open-iscsi and libopeniscsiusr where upgraded to 2.1.3- >> 1. >> >> With a kernel installed after this upgrade my system cannot boot from >> an >> iSCSI LUN: >> >> iscsistart: version 2.1.3 >> iscsistart: Logging into iqn.2000-01.de.xypron:disk1 >> 192.168.0.1:3260,1 >> iscsistart: initiator reported error (32 - target likely not >> connected) >> >> I downgraded to open-iscsi and libopeniscsiusr to version 2.1.2-2 and >> reinstalled the kernel package. >> > > > I don't know how to react, whether I should thank you or not. > > That's the last version I had uploaded, 2.1.2. And it did clear my > tests, that of an iscsi root disk. > > Now that I know 2.1.3 has broken iscsi root setup, I will be cautious > when/if trying to debug that issue, when time permits. > Hello Ritesh, thank you for looking into this. According to https://tracker.debian.org/pkg/open-iscsi Chris migrated 2.1.3-1 to testing. I replaced %s/iscsistart/iscsistart -d 8/g in file /usr/share/initramfs-tools/scripts/local-top/iscsi to get the extended log at the end of the mail. I hope that helps. >> Now the system boots with: >> >> iscsistart: Logging into iqn.2000-01.de.xypron:disk1 >> 192.168.0.1:3260,1 >> iscsistart: initiator reported error (15 - session exists) >> iscsistart: version 2.1.2 >> iscsistart: Logging into iqn.2000-01.de.xypron:disk1 >> 192.168.0.1:3260,1 >> iscsistart: Connection1:0 to [target: iqn.2000-01.de.xypron:disk1, >> portal: 192.168.0.1,3260] through [iface: default] is operational now > > Just for my own sake. Since the new upgrade broke your setup, how did > you revert back to the older iscsi initiator (2.1.2) for the root LUN ? > Did you build this setup on a VM ? > Did you have snapshots of the root LUN ? Only the newest initrd was concerned. So I could still boot with an old kernel after selecting it in GRUB. You can find old packages on https://snapshot.debian.org/. You could also consider chroot'ing into the image from your workstation. Best regards Heinrich Boot log Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... sh: -d: unknown operand IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP[ 7.484587] dwmac-sun8i 1c3.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) RARP [7.502403] dwmac-sun8i 1c3.ethernet eth0: No Safety Features support found [7.509764] dwmac-sun8i 1c3.ethernet eth0: No MAC Management Counters available [7.517438] dwmac-sun8i 1c3.ethernet eth0: PTP not supported by HW [7.524608] dwmac-sun8i 1c3.ethernet eth0: configuring for phy/rgmii-id link mode IP-Config: eth0 guessed broadcast address 192.168.0.255 IP-Config: eth0 complete: address: 192.168.0.18 broadcast: 192.168.0.255 netmask: 255.255.255.0 gateway: 192.168.0.254 dns0 : 0.0.0.0 dns1 : 0.0.0.0 rootserver: 192.168.0.254 rootpath: filename : [7.570722] SCSI subsystem initialized [7.581238] Loading iSCSI transport class v2.0-870. [7.597809] iscsi: registered transport (tcp) iscsistart: in ctldev_open iscsistart: created NETLINK_ISCSI socket... iscsistart: InitiatorName=iqn.1993-08.org.debian:01:xxx iscsistart: InitiatorAlias=(none) iscsistart: TargetName=iqn.2000-01.de.xypron:disk1 iscsistart: TPGT=1 iscsistart: IP Address=192.168.0.1 iscsistart: version 2.1.3 iscsistart: current time 7 iscsistart: nothing on pend_list, deactivating alarm iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1 iscsistart: poll result 1 iscsistart: in read_transports iscsistart: Adding new transport tcp iscsistart: Matched transport tcp iscsistart: sysfs_attr_get_value: open '/class/iscsi_transport/tcp'/'handle' iscsistart: sysfs_attr_get_value: open '/class/iscsi_transport/tcp'/'caps' iscsistart: Allocted session 0xfb4531d0 iscsistart: authentication setup complete... iscsistart: resolved 192.168.0.1 to 192.168.0.1 iscsistart: setting iface default, dev , set ip , hw , transport tcp. iscsistart: get ev context 0xfb44b180 iscsistart: set TCP recv window size to 524288, actually got 425984 iscsistart: set TCP send window size to 524288, actually got 425984 iscsistart: connecting to 192.168.0.1:3260 iscsistart: sched conn context 0xfb44b180 event 2, tmo 0 iscsistart: thread 0xfb44b180 schedule: delay 0 state 3 iscsistart: Setting login timer 0xfb45b138 timeout 30 iscsistart: thread fb45b138 delete: state 3 iscsistart: thread 0xfb45b138 schedule: delay 30 state 3 iscsistart: new thread 0xfb45b138 due 38 is first item on pend_list iscsistart:
Bug#980085: open-iscsi: initiator does not connect
The same problem is described in: https://github.com/open-iscsi/open-iscsi/issues/241
Bug#980085: open-iscsi: initiator does not connect
Package: open-iscsi Version: 2.1.3-1 Severity: important On my system open-iscsi and libopeniscsiusr where upgraded to 2.1.3-1. With a kernel installed after this upgrade my system cannot boot from an iSCSI LUN: iscsistart: version 2.1.3 iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1 iscsistart: initiator reported error (32 - target likely not connected) I downgraded to open-iscsi and libopeniscsiusr to version 2.1.2-2 and reinstalled the kernel package. Now the system boots with: iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1 iscsistart: initiator reported error (15 - session exists) iscsistart: version 2.1.2 iscsistart: Logging into iqn.2000-01.de.xypron:disk1 192.168.0.1:3260,1 iscsistart: Connection1:0 to [target: iqn.2000-01.de.xypron:disk1, portal: 192.168.0.1,3260] through [iface: default] is operational now -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.10.7-fwts-arm64+ (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages open-iscsi depends on: ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libisns0 0.100-3 ii libkmod2 28-1 ii libmount1 2.36.1-4 ii libopeniscsiusr2.1.3-1 ii libssl1.1 1.1.1i-1 ii libsystemd0247.2-4 ii udev 247.2-4
Bug#975705: marked as pending in cura
https://salsa.debian.org/3dprinting-team/cura/-/commit/871fcb258aa11077c3a6e16651fbcb44953e932e did not build cf. https://salsa.debian.org/3dprinting-team/cura/-/pipelines/205268 Best regards Heinrich
Bug#976093: linux-image-5.9.0-3-arm64: Network failure NanoPi Neo Plus2
The NanoPi Neo Plus2 is struck by the same error. I just sent out a patch: arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode rgmii-id https://lore.kernel.org/linux-arm-kernel/20201129194512.1475586-1-xypron.g...@gmx.de/T/#u
Bug#976093: linux-image-5.9.0-3-arm64: Network failure Pine A64 LTS
Package: src:linux X-Debbugs-Cc: xypron.g...@gmx.de Version: 5.9.9-1 Severity: normal Tags: patch upstream Dear Maintainer, since Bullseye switched to Linux v5.9 my Pine A64 LTS board fails to boot via iSCSI. I have posted a patch upstream. Please, consider it for inclusion: [PATCH 1/1] arm64: dts: allwinner: A64 Sopine: phy-mode rgmii https://lore.kernel.org/linux-arm-kernel/20201129162627.1244808-1-xypron.g...@gmx.de/T/#u Best regards Heinrich -- Package-specific info: ** Version: Linux version 5.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-17) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.9-1 (2020-11-19)
Bug#824954: IRT: [bug #52939] [PATCH] 10_linux: support loading device trees
Am 27. November 2020 04:18:06 MEZ schrieb Elliott Mitchell : >The patch to have GRUB load a device-tree is interesting. This is >certainly worthy of discussion. > >Three issues come up when looking though: > >First, your patch modifies /etc/grub.d/10_linux, but misses >/etc/grub.d/10_linux_xen. /etc/grub.d/10_linux_xen needs a fairly >similar treatment. > >Second, rather than having this get buried inside Debian bug #824954, >you >should instead file a new bug against grub-common. > >Third, there may be a need for extra guarding to ensure these sections >*only* get invoked on ARM devices (I'm fairly sure the *exact* *same* >file is shipped for all architectures). RISC-V uses device-trees too. Some ARM devices use ACPI instead of device-trees. The main issue is that fix-ups are not applied by U-Boot when GRUB loads the device-tree. A UEFI protocol for device tree fix ups would be needed. This issue has been discussed in this years Device Tree Evolution project (https://www.linaro.org/engineering/core/devicetree-evolution/). Best regards Heinrich
Bug#973909: libreoffice-impress: crash when exiting presentation mode
I was not able to reproduce the problem with libreoffice-impress (1:7.0.3-4). Best regards Heinrich
Bug#974017: glusterfs-common: SyntaxWarning: "is" with a literal
Package: glusterfs-common Version: 8.2-1 Severity: normal Dear maintainer, updating Python3 leads to the following warning: running python rtupdate hooks for python3.8... /usr/lib/x86_64-linux-gnu/glusterfs/python/syncdaemon/syncdutils.py:728: SyntaxWarning: "is" with a literal. Did you mean "=="? if dirpath is "/": I guess this "is" should be replaced by "==" because we don't want to check for an interned string here. Best regards Heinrich -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages glusterfs-common depends on: ii attr 1:2.4.48-5 ii e2fsprogs1.45.6-1 ii libacl1 2.2.53-8 ii libaio1 0.3.112-8 ii libc62.31-4 ii libgfapi08.2-1 ii libgfchangelog0 8.2-1 ii libgfrpc08.2-1 ii libgfxdr08.2-1 ii libglusterd0 8.2-1 ii libglusterfs08.2-1 ii libssl1.11.1.1h-1 ii libtirpc31.2.6-3 ii liburcu6 0.12.1-1 ii libuuid1 2.36-3+b2 ii libxml2 2.9.10+dfsg-6.1 ii psmisc 23.3-1 ii python3 3.8.6-1 ii python3-jwt 1.7.1-2 ii python3-prettytable 0.7.2-5 ii python3-requests 2.24.0+dfsg-1 ii xfsprogs 5.6.0-1+b2 ii zlib1g 1:1.2.11.dfsg-2 glusterfs-common recommends no packages. glusterfs-common suggests no packages. -- no debconf information
