Bug#1070474: time sync overflows on ARCH armhf(Debian 12, bookworm) with systemd-timesyncd.service

[Perr Zhang]

I debuged the systemd core file:
--
root@archlinux:/# gdb /usr/bin/systemd core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/systemd...
Reading symbols from 
/usr/lib/debug/.build-id/08/012654d6118a0fa2d1b816477ee009edee155f.debug...

warning: exec file is newer than core file.
[New LWP 23696]
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/sbin/init earlyprintk'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb6b674c8 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
120 ../sysdeps/unix/syscall-template.S: No such file or directory.
[Current thread is 1 (LWP 23696)]
(gdb) thread apply all bt

Thread 2 (Thread 0xb69b6d00 (LWP 1)):
warning: Couldn't find general-purpose registers in core file.
Python Exception : Register 13 is not available
#0   in ?? ()

Thread 1 (LWP 23696):
#0  0xb6b674c8 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1  0x004220d2 in crash (sig=6, siginfo=, context=) at ../src/core/crash-handler.c:83
#2  
#3  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#4  0xb6b9850c in __pthread_kill_implementation (threadid=3063639296, signo=6, 
no_tid=) at pthread_kill.c:43
#5  0xb6b67322 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#6  0xb6b580ac in __GI_abort () at abort.c:79
#7  0xb6d78d00 in log_assert_failed () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#8  0xb6d8f85e in now () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#9  0xb6d8f8d0 in triple_timestamp_get () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#10 0xb6e08388 in sd_event_wait () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#11 0xb6e0958a in sd_event_run () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#12 0xb6f22e68 in manager_loop () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-core-252.so
#13 0x0041bb6a in invoke_main_loop (ret_error_message=0xbe8e0a3c, 
ret_switch_root_init=, ret_switch_root_dir=, ret_fds=0xbe8e0a34, ret_shutdown_verb=, 
ret_retval=, saved_rlimit_memlock=0xbe8e0a50, 
saved_rlimit_nofile=0xbe8e0a60, m=) at ../src/core/main.c:1904
#14 main (argc=2, argv=0xbe8e0ed4) at ../src/core/main.c:2993
(gdb) 
--

the assert of now() failed at 
https://github.com/systemd/systemd/blob/e8dc52766e1fdb4f8c09c3ab654d1270e1090c8d/src/basic/time-util.c#L53
assert_se(clock_gettime(map_clock_id(clock_id), ) == 0); //clock_gettime() 
syscall should failed with EOVERFLOW which means the kernel time exceeds year 
2038 at that time point

Bug#1068292: haskell-pandoc build failed in loong64

[JiaLing Zhang]

Source: haskell-pandoc
Version: 3.1.3-1
Severity: normal
Tags: ftbfs
Usertags: loong64
X-Debbugs-Cc: zhangjial...@loongson.cn, fanp...@loongson.cn 
zhangdan...@loongson.cn

Dear Maintainer,

The haskell-pandoc build failed in buildd.debian.org for loong64 , The error 
log is  
https://buildd.debian.org/status/fetch.php?pkg=haskell-pandoc=loong64=3.1.3-1=1709428706=0

The compile error is:

"
/usr/bin/ld.bfd: 
/usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o):
 relocation R_LARCH_B26 overflow 0xf5fec6a4
Dump relocate record:
stack top   relocation name symbol
at 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x0):
...
0x R_LARCH_NONE `' + 3(0x3)

at 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x4):
0x R_LARCH_GOT_PC_HI20  `main'
0x R_LARCH_RELAX`'

...


/usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o):
 in function `.LVL4':
(.text+0x38): relocation truncated to fit: R_LARCH_B26 against symbol 
`pthread_mutex_lock@@GLIBC_2.36' defined in .plt section in 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o
/usr/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
ghc-9.4.7: `loongarch64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 880.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc returned exit"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 610
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 473
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25

"

When links there will have a "relocation R_LARCH_B26 overflow" for the binary 
too large . When we use 
DEB_SETUP_GHC_CONFIGURE_ARGS=--enable-executable-dynamic -O2  to build , this 
will build fine . 

Please , If we chould add this build options in Debian/rules ? If no ,How 
chould I do for this problem?


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1037914: closed by Debian FTP Masters (reply to Matthew Grant ) (Bug#1037914: fixed in wsdd 2:0.7.1-4)

[ZHANG Yuntian]

Hi Matthew,

wsdd's source repo [1] is currently broken so I can't check what you 
did, but how does it have anything to do with cloud-initramfs-growroot? 
I don't think it is in the dependency tree of the latter package.


1: https://salsa.debian.org/debian/wsdd.git

On 2024/2/18 08:51, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the cloud-initramfs-growroot package:

#1037914: cloud-initramfs-growroot: missing dependencies in initramfs

It has been closed by Debian FTP Masters  (reply to 
Matthew Grant ).

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 Debian FTP Masters 
 (reply to Matthew Grant 
) by
replying to this email.




--
Best regards,

ZHANG, Yuntian

Operating System Developer
Radxa Computer Co., Ltd
Shenzhen, China

Bug#1059972: marked as pending in dpdk

[Zhang Na]

On Thu, 15 Feb 2024 15:25:48 + Luca Boccassi wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #1059972 in dpdk reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> 
https://salsa.debian.org/debian/dpdk/-/commit/9123ab5f4458c40a9d2ede624febd0dfefe15372

>
> 
> d/rules, d/control, d/*.symbols: Add loong64 support (Closes: #1059972)
>
> Thanks to Zhang Na for the changes.
>
> Luca checked with upstream and there is regular CI and it is
> considered to be a supported architecture.
> 
>
> (this message was generated automatically)
> --
> Greetings
>
> https://bugs.debian.org/1059972
>
>

Thanks Luca! If you have any questions, you can contact me.

Bug#1063307: clickhouse: Please enable build in loong64

[JiaLing Zhang]

Source: clickhouse
Version: 18.16.1+ds-7.4
Severity: normal
Tags: patch loong64

Dear Maintainer,

Please help to enable clickhouse build in loong64

Thanks,
JiaLing Zhang


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- debian/control.org  2024-02-06 03:31:48.289444973 +
+++ debian/control  2023-09-04 16:32:26.0 +
@@ -54,7 +54,7 @@
 Vcs-Browser: https://salsa.debian.org/debian/ClickHouse
 
 Package: clickhouse-common
-Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x loong64 mips64el 
sparc64 riscv64 hppa
+Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x mips64el sparc64 
riscv64 hppa
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: column-oriented database system (common files)
  ClickHouse is a column-oriented database management system that allows
@@ -63,7 +63,7 @@
  This package provides common files for both ClickHouse server and client.
 
 Package: clickhouse-server
-Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x loong64 mips64el 
sparc64 riscv64 hppa
+Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x mips64el sparc64 
riscv64 hppa
 Depends: ${misc:Depends}, ${shlibs:Depends}, clickhouse-common (= 
${binary:Version}), adduser
 Recommends: clickhouse-client (= ${binary:Version})
 Description: column-oriented database system (server runner)
@@ -73,7 +73,7 @@
  This package provides ClickHouse server runner.
 
 Package: clickhouse-client
-Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x loong64 mips64el 
sparc64 riscv64 hppa
+Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x mips64el sparc64 
riscv64 hppa
 Depends: ${misc:Depends}, ${shlibs:Depends}, clickhouse-common (= 
${binary:Version})
 Description: column-oriented database system (cli client)
  ClickHouse is a column-oriented database management system that allows
@@ -82,7 +82,7 @@
  This package provides ClickHouse CLI client.
 
 Package: clickhouse-tools
-Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x loong64 mips64el 
sparc64 riscv64 hppa
+Architecture: any-amd64 ia64 arm64 ppc64el ppc64 s390x mips64el sparc64 
riscv64 hppa
 Depends: ${misc:Depends}, ${shlibs:Depends}, clickhouse-common (= 
${binary:Version})
 Description: column-oriented database system (tools)
  ClickHouse is a column-oriented database management system that allows

Bug#1062598: libpod: Add support for LoongArch

[JiaLing Zhang]

Source: libpod
Version: 4.9.0+ds1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please help to add support for loong64.I have build it in my local
machine.


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- libpod-4.9.0+ds1.orig/Makefile
+++ libpod-4.9.0+ds1/Makefile
@@ -164,6 +164,7 @@ CROSS_BUILD_TARGETS := \
bin/podman.cross.linux.arm64 \
bin/podman.cross.linux.386 \
bin/podman.cross.linux.s390x \
+   bin/podman.cross.linux.loong64 \
bin/podman.cross.linux.mips \
bin/podman.cross.linux.mipsle \
bin/podman.cross.linux.mips64 \
--- libpod-4.9.0+ds1.orig/pkg/machine/fcos.go
+++ libpod-4.9.0+ds1/pkg/machine/fcos.go
@@ -91,6 +91,8 @@ func GetFcosArch() string {
arch = "aarch64"
case "riscv64":
arch = "riscv64"
+   case "loong64":
+   arch = "loongarch64"
default:
arch = "x86_64"
}

Bug#1062026: autopkgtest: add loongarch64 support

[Zhang Na]

Package: autopkgtest
Version: 5.31.2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loongarch64 support, thanks!




-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages autopkgtest depends on:
ii  apt-utils   2.7.7
ii  libdpkg-perl1.22.1
ii  mawk1.3.4.20231126-1
ii  procps  2:4.0.4-2
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.32.2-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  genisoimage  
pn  lxc  
pn  lxd  
pn  ovmf 
pn  ovmf-ia32
pn  podman   
pn  python3-distro-info  
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-2
pn  vmdb2
pn  zerofree 

-- no debconf information
>From 588a76ea2f332ae68f204ed658b54216e136f10a Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 30 Jan 2024 07:37:07 +
Subject: [PATCH] add loongarch64 support

---
 lib/autopkgtest_qemu.py | 5 -
 tests/qemu  | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index df24970..c3b45ff 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -374,7 +374,7 @@ class Qemu:
 argv.extend(['-machine', 'type=virt,gic-version=max'])
 else:
 argv.extend(['-machine', 'virt'])
-elif self.qemu_architecture in ('arm', 'riscv64'):
+elif self.qemu_architecture in ('arm', 'riscv64', 'loongarch64'):
 argv.extend(['-machine', 'virt'])
 elif (
 self.qemu_architecture in ('i386', 'x86_64') and
@@ -531,6 +531,7 @@ class Qemu:
 # cris not in dpkg-architecture -L
 # hppa
 # i386
+'loongarch64': 'loong64',
 # m68k
 # microblaze not in dpkg-architecture -L
 # microblazeel not in dpkg-architecture -L
@@ -569,6 +570,7 @@ class Qemu:
 'cris',
 'hppa',
 'i386',
+'loongarch64',
 'm68k',
 'microblaze',
 'microblazeel',
@@ -623,6 +625,7 @@ class Qemu:
 # hppa
 # i386
 # ia64?
+'loong64': 'loongarch64',
 # m32r?
 # m68k
 # mips
diff --git a/tests/qemu b/tests/qemu
index bbc92b5..6876478 100755
--- a/tests/qemu
+++ b/tests/qemu
@@ -58,6 +58,7 @@ class QemuTestCase(unittest.TestCase):
 self.assertEqual(get('armel'), 'arm')
 self.assertEqual(get('armhf'), 'arm')
 self.assertEqual(get('i386'), 'i386')
+self.assertEqual(get('loong64'), 'loongarch64')
 self.assertEqual(get('m68k'), 'm68k')
 self.assertEqual(get('mips'), 'mips')
 self.assertEqual(get('mips64'), 'mips64')
@@ -77,6 +78,7 @@ class QemuTestCase(unittest.TestCase):
 self.assertEqual(get('aarch64'), 'arm64')
 self.assertEqual(get('arm'), 'armhf')
 self.assertEqual(get('i386'), 'i386')
+self.assertEqual(get('loongarch64'), 'loong64')
 self.assertEqual(get('m68k'), 'm68k')
 self.assertEqual(get('mips'), 'mips')
 self.assertEqual(get('mips64'), 'mips64')
-- 
2.43.0

Bug#1061730: openjfx: add loongarch64 support

[Zhang Na]

Source: openjfx
Version: 11.0.11+1-3.1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
  I have a patch and a suggestion!
  Firstly, I submitted a loongarch64's patch for openjfx-11, but it does not 
support webkit as the minimum version of LoongArch's g++ is 13;
  Secondly, I suggest upgrading to the latest version of openjfx, which already 
supports LoongArch and also supports g++13, looking forward to your reply. Of 
course, I also saw the same question(#1023702 and #1041527), but there was no 
response, but I still look forward to it.
  
  Thanks!



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From fc418a426205deb8e198f51a374bcfc125f96111 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 29 Jan 2024 08:37:58 +
Subject: [PATCH] Add LoongArch support

---
 debian/control | 2 +-
 debian/gradle.properties.loong64   | 4 
 debian/rules   | 4 
 .../gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h | 2 +-
 modules/javafx.web/src/main/native/CMakeLists.txt  | 2 ++
 .../src/main/native/Source/JavaScriptCore/CMakeLists.txt   | 7 +++
 .../ThirdParty/icu/source/i18n/double-conversion-utils.h   | 2 +-
 .../javafx.web/src/main/native/Source/WTF/wtf/PageBlock.h  | 2 +-
 .../src/main/native/Source/WTF/wtf/PlatformCPU.h   | 6 ++
 .../javafx.web/src/main/native/Source/WTF/wtf/dtoa/utils.h | 2 +-
 10 files changed, 28 insertions(+), 5 deletions(-)
 create mode 100644 debian/gradle.properties.loong64

diff --git a/debian/control b/debian/control
index d6bff1a3..aff82e6a 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: antlr4,
default-jdk,
default-jdk-doc,
flex,
-   g++-11,
+   g++-11 [!loong64],
gperf,
gradle (>= 4.4),
gradle-debian-helper (>= 2.0),
diff --git a/debian/gradle.properties.loong64 b/debian/gradle.properties.loong64
new file mode 100644
index ..47cc7b48
--- /dev/null
+++ b/debian/gradle.properties.loong64
@@ -0,0 +1,4 @@
+COMPILE_WEBKIT = false
+COMPILE_MEDIA = true
+GRADLE_VERSION_CHECK = false
+CONF = Release
diff --git a/debian/rules b/debian/rules
index 63f7f36a..4e4aafc0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,11 @@ export NUMBER_OF_PROCESSORS ?= $(shell nproc)
dh $@ --buildsystem=gradle --no-parallel --with maven-repo-helper
 
 override_dh_auto_configure-arch:
+ifneq (,$(filter $(DEB_HOST_ARCH), loong64))
+   cp debian/gradle.properties.loong64 gradle.properties
+else
cp debian/gradle.properties .
+endif
 
 override_dh_auto_configure-indep:
echo "GRADLE_VERSION_CHECK = false" >> gradle.properties
diff --git 
a/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
 
b/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
index c889459e..dbc9bcda 100644
--- 
a/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
+++ 
b/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
@@ -107,7 +107,7 @@
  */
 #if defined(__alpha__) || defined(__arc__) || defined(__arm__) || 
defined(__aarch64__) || defined(__bfin) || defined(__hppa__) || 
defined(__nios2__) || defined(__MICROBLAZE__) || defined(__mips__) || 
defined(__or1k__) || defined(__sh__) || defined(__SH4__) || defined(__sparc__) 
|| defined(__sparc) || defined(__ia64__) || defined(_M_ALPHA) || 
defined(_M_ARM) || defined(_M_IA64) || defined(__xtensa__) || defined(__e2k__)
 #  define GST_HAVE_UNALIGNED_ACCESS 0
-#elif defined(__i386__) || defined(__i386) || defined(__amd64__) || 
defined(__amd64) || defined(__x86_64__) || defined(__ppc__) || 
defined(__ppc64__) || defined(__powerpc__) || defined(__powerpc64__) || 
defined(__m68k__) || defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) 
|| defined(__s390__) || defined(__s390x__) || defined(__zarch__)
+#elif defined(__i386__) || defined(__i386) || defined(__amd64__) || 
defined(__amd64) || defined(__x86_64__) || defined(__ppc__) || 
defined(__ppc64__) || defined(__powerpc__) || defined(__powerpc64__) || 
defined(__m68k__) || defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) 
|| defined(__s390__) || defined(__s390x__) || defined(__zarch__) || 
defined(__loongarch__)
 #  define GST_HAVE_UNALIGNED_ACCESS 1
 #else
 #  error "Could not detect architecture; don't know whether it supports 
unali

Bug#1061135: mlton: Add support for loongarch64

[JiaLing Zhang]

Source: mlton
Severity: normal
Tags: patch ftbfs loong64
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
  Mlton is not support loongarch64 now , I port and bootstrap it in
loongarch64 . Please help to support mlton loongarch64 in debian. 

Thanks,
JiaLing Zhang
--- mlton-20210117+dfsg.orig/basis-library/mlton/platform.sig
+++ mlton-20210117+dfsg/basis-library/mlton/platform.sig
@@ -9,7 +9,7 @@ signature MLTON_PLATFORM =
sig
   structure Arch:
  sig
-datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | m68k |
+datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 | m68k |
  MIPS | MIPS64 | PowerPC | PowerPC64 | RISCV |
  RISCV64 | S390 | Sparc | X86
 
--- mlton-20210117+dfsg.orig/basis-library/mlton/platform.sml
+++ mlton-20210117+dfsg/basis-library/mlton/platform.sml
@@ -23,6 +23,7 @@ structure MLtonPlatform: MLTON_PLATFORM
 (ARM64, "ARM64"),
 (HPPA, "HPPA"),
 (IA64, "IA64"),
+(LoongArch64, "LoongArch64"),
 (m68k, "m68k"),
 (MIPS, "MIPS"),
 (MIPS64, "MIPS64"),
--- mlton-20210117+dfsg.orig/basis-library/primitive/prim-mlton.sml
+++ mlton-20210117+dfsg/basis-library/primitive/prim-mlton.sml
@@ -154,6 +154,7 @@ structure Platform =
  | ARM64
  | HPPA
  | IA64
+ | LoongArch64
  | m68k
  | MIPS
  | MIPS64
@@ -173,6 +174,7 @@ structure Platform =
 | "arm64" => ARM64
 | "hppa" => HPPA
 | "ia64" => IA64
+| "loongarch64" => LoongArch64
 | "m68k" => m68k
 | "mips" => MIPS
 | "mips64" => MIPS64
--- mlton-20210117+dfsg.orig/bin/platform
+++ mlton-20210117+dfsg/bin/platform
@@ -109,6 +109,9 @@ parisc*)
 ia64*)
 HOST_ARCH=ia64
 ;;
+loongarch64*)
+HOST_ARCH=loongarch64
+;;
 m68k*)
 HOST_ARCH=m68k
 ;;
--- mlton-20210117+dfsg.orig/lib/stubs/mlton-stubs/mlton.sml
+++ mlton-20210117+dfsg/lib/stubs/mlton-stubs/mlton.sml
@@ -159,7 +159,7 @@ structure MLton: MLTON =
 
 structure Arch =
struct
-  datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 |
+  datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 |
m68k | MIPS | MIPS64 | PowerPC | PowerPC64 | 
RISCV |
RISCV64 | S390 | Sparc | X86
 
@@ -169,6 +169,7 @@ structure MLton: MLTON =
  (ARM64, "ARM64"),
  (HPPA, "HPPA"),
  (IA64, "IA64"),
+ (LoongArch64,"LoongArch64"),
  (m68k, "m68k"),
  (MIPS, "MIPS"),
  (MIPS64, "MIPS64"),
--- mlton-20210117+dfsg.orig/lib/stubs/mlton-stubs/platform.sig
+++ mlton-20210117+dfsg/lib/stubs/mlton-stubs/platform.sig
@@ -9,7 +9,7 @@ signature MLTON_PLATFORM =
sig
   structure Arch:
  sig
-datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | m68k |
+datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 | m68k |
  MIPS | MIPS64 | PowerPC | PowerPC64 | RISCV | RISCV64 
|
  S390 | Sparc | X86
 
--- mlton-20210117+dfsg.orig/mlton/main/main.fun
+++ mlton-20210117+dfsg/mlton/main/main.fun
@@ -199,6 +199,7 @@ fun defaultAlignIs8 () =
| ARM64 => true
| HPPA => true
| IA64 => true
+   | LoongArch64 => true
| MIPS => true
| MIPS64 => true
| RISCV64 => true
--- mlton-20210117+dfsg.orig/runtime/cenv.h
+++ mlton-20210117+dfsg/runtime/cenv.h
@@ -99,6 +99,8 @@ COMPILE_TIME_ASSERT(sizeof_double__is_ei
 #include "platform/hppa.h"
 #elif (defined (__ia64__))
 #include "platform/ia64.h"
+#elif (defined (__loongarch64))
+#include "platform/loongarch64.h"
 #elif (defined (__m68k__))
 #include "platform/m68k.h"
 #elif (defined (__mips64))
--- /dev/null
+++ mlton-20210117+dfsg/runtime/gdtoa/arith.h
@@ -0,0 +1,6 @@
+#define IEEE_8087
+#define Arith_Kind_ASL 1
+#define Long int
+#define Intcast (int)(long)
+#define Double_Align
+#define X64_bit_pointers
--- /dev/null
+++ mlton-20210117+dfsg/runtime/gdtoa/gd_qnan.h
@@ -0,0 +1,3 @@
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x7ff8
+#define d_QNAN1 0x0
--- mlton-20210117+dfsg.orig/runtime/platform/linux.c
+++ mlton-20210117+dfsg/runtime/platform/linux.c
@@ -28,6 +28,9 @@ static void catcher (__attribut

Bug#1060823: baler: Update debian/control for loong64

[Zhang Na]

Source: baler
Version: 1.3.0-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/control for loong64, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 2425b38cb0d0a926ae1c4f7c5c5d7e85b1103797 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 15 Jan 2024 02:23:00 +
Subject: [PATCH] Update debian/control for loong64

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f94651a..8f5cb41 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Homepage: https://github.com/baler-collaboration/baler/
 
 Package: python3-baler
 Section: python
-Architecture: amd64 arm64 ppc64el s390x riscv64
+Architecture: amd64 arm64 loong64 ppc64el s390x riscv64
 Multi-Arch: foreign
 Depends:
  ${python3:Depends},
-- 
2.43.0

Bug#1060298: pocl: update llvm version in debian/control

[Zhang Na]

Source: pocl
Version: 4.0-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update llvm version in debian/control, thanks! The latest
  version of LLVM is 16 in Debian. Convenient support for more new
  architectures.


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 318a56cba2c1fe681fc453fdf91858f6ca66e993 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 8 Jan 2024 10:02:05 +
Subject: [PATCH] update llvm-16 in  debian/control

---
 debian/control | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index db25d45..a732143 100644
--- a/debian/control
+++ b/debian/control
@@ -7,10 +7,10 @@ Uploaders: Vincent Danjean ,
 Build-Depends:
  debhelper-compat (= 13),
  gcc (>= 4:13),
- clang-15,
- libclang-15-dev,
- libclang-cpp15-dev,
- llvm-15-dev,
+ clang-16, 
+ libclang-16-dev,
+ libclang-cpp16-dev,
+ llvm-16-dev,
  cmake,
  libhwloc-dev,
  ocl-icd-dev,
-- 
2.43.0

--- debian/libpocl2.symbols (libpocl2_4.0-3_loong64)
+++ dpkg-gensymbolsd953pV   2024-01-08 10:12:19.307182559 +
@@ -25,40 +25,40 @@
  
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb0EEclEcE5__nul@Base
 3.0
  
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb1EEclEcE5__nul@Base
 3.0
  _ZN4pocl23eraseFunctionAndCallersEPN4llvm8FunctionE@Base 1.8-3~visibility
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
 0.11
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
 1.6-2~hardening
+#MISSING: 4.0-3# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
 0.11
+#MISSING: 4.0-3# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3# 
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
 1.6-2~hardening
 #MISSING: 1.8# 
(optional=templinst|arch=mipsel)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
 1.1-6~llvm6.0+gcc8
  
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEPc{size_t}PKc{size_t}{size_t}@Base
 4.0-2~gcc13
-#MISSING: 1.8# 
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4swapERS4_@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKc{size_t}@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_@Base
 1.6-2~hardening
-#MISSING: 4.0-2~gcc13# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateE{size_t}{size_t}PKc{size_t}@Base
 4
- (optional=templinst|arch=amd64 arm64 mips64el ppc64el riscv64 
sparc64)_ZNSt8_Rb_treeIN3spv10DecorationES1_St9_IdentityIS1_ESt4lessIS1_ESaIS1_EE16_M_insert_uniqueIRKS1_EESt4pairISt17_Rb_tree_iteratorIS1_EbEOT_@Base
 4
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE24_M_get_insert_unique_posERKS5_@Base
 1.0
-#MISSING: 1.8# 
(optional=tem

Bug#1060127: radare2: Add basic support for LoongArch

[Zhang Na]

Source: radare2
Version: 5.5.0+dfsg-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add basic support for LoongArch, without this patch, building on LoongArch 
will fail.
  https://github.com/radareorg/radare2/pull/19505, the PR has been merged.



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 2fcdd59ed81bd016ca9a43529f082feac0277bfe Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Sat, 6 Jan 2024 07:01:31 +
Subject: [PATCH] add loongarch support

---
 libr/core/cconfig.c   |  2 +-
 libr/debug/p/debug_native.c   |  4 ++
 libr/debug/p/native/linux/linux_debug.c   |  2 +
 libr/debug/p/native/linux/linux_debug.h   |  6 ++
 .../p/native/linux/reg/linux-loongarch64.h| 66 +++
 .../r_jemalloc/internal/jemalloc_internal.h   |  3 +
 libr/include/r_types.h|  4 ++
 libr/include/r_util/r_sys.h   |  2 +
 8 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 libr/debug/p/native/linux/reg/linux-loongarch64.h

diff --git a/libr/core/cconfig.c b/libr/core/cconfig.c
index e995238..4ac8560 100644
--- a/libr/core/cconfig.c
+++ b/libr/core/cconfig.c
@@ -3668,7 +3668,7 @@ R_API int r_core_config_init(RCore *core) {
r_config_set_getter (cfg, "dbg.swstep", 
(RConfigCallback)__dbg_swstep_getter);
 
 // TODO: This should be specified at first by the debug backend when attaching
-#if __arm__ || __mips__
+#if __arm__ || __mips__ || __loongarch__
SETICB ("dbg.bpsize", 4, _dbgbpsize, "Size of software breakpoints");
 #else
SETICB ("dbg.bpsize", 1, _dbgbpsize, "Size of software breakpoints");
diff --git a/libr/debug/p/debug_native.c b/libr/debug/p/debug_native.c
index bd7c686..bcfe04a 100644
--- a/libr/debug/p/debug_native.c
+++ b/libr/debug/p/debug_native.c
@@ -1622,6 +1622,10 @@ RDebugPlugin r_debug_plugin_native = {
.bits = R_SYS_BITS_32 | R_SYS_BITS_64,
.arch = "mips",
.canstep = false,
+#elif __loongarch
+   .bits = R_SYS_BITS_32 | R_SYS_BITS_64,
+   .arch = "loongarch",
+   .canstep = false,
 #elif __powerpc__
 # if __powerpc64__
.bits = R_SYS_BITS_32 | R_SYS_BITS_64,
diff --git a/libr/debug/p/native/linux/linux_debug.c 
b/libr/debug/p/native/linux/linux_debug.c
index 569aa71..34700bc 100644
--- a/libr/debug/p/native/linux/linux_debug.c
+++ b/libr/debug/p/native/linux/linux_debug.c
@@ -39,6 +39,8 @@ char *linux_reg_profile (RDebug *dbg) {
} else {
 #  include "reg/linux-mips64.h"
}
+#elif __loongarch__
+#  include "reg/linux-loongarch64.h"
 #elif (__i386__ || __x86_64__)
if (dbg->bits & R_SYS_BITS_32) {
 #if __x86_64__
diff --git a/libr/debug/p/native/linux/linux_debug.h 
b/libr/debug/p/native/linux/linux_debug.h
index 55cebb6..0f2f882 100644
--- a/libr/debug/p/native/linux/linux_debug.h
+++ b/libr/debug/p/native/linux/linux_debug.h
@@ -105,6 +105,12 @@ struct powerpc_regs_t {
 #include 
 typedef ut64 mips64_regs_t [274];
 #define R_DEBUG_REG_T mips64_regs_t
+
+#elif __loongarch__
+
+#include 
+typedef ut64 la_regs_t [274];
+#define R_DEBUG_REG_T la_regs_t
 #endif
 #endif
 
diff --git a/libr/debug/p/native/linux/reg/linux-loongarch64.h 
b/libr/debug/p/native/linux/reg/linux-loongarch64.h
new file mode 100644
index 000..ae85d66
--- /dev/null
+++ b/libr/debug/p/native/linux/reg/linux-loongarch64.h
@@ -0,0 +1,66 @@
+#if 0
+   reg  nameusage
+   ---+---+-
+   0zero   always zero
+   1 rareturn address
+   2 tpTLS
+   3 spstack pointer
+   4-11  a0-a7 argument
+   4-5   v0-v1 return value
+   12-20 t0-t8 temp
+   21x reserved
+   22fpframe point
+   23-31 s0-s8 subroutine registe variables
+#endif
+
+   return strdup (
+   "=PCpc\n"
+   "=SPsp\n"
+   "=BPfp\n"
+   "=A0a0\n"
+   "=A1a1\n"
+   "=A2a2\n"
+   "=A3a3\n"
+   "=A4a0\n"
+   "=A5a1\n"
+   "=A6a2\n"
+   "=A7a3\n"
+   "gprzero.64 0   0\n"
+   "gprra  .64 8   0\n"
+   "gprtp  .64 16  0\n"
+   "gprsp  .64 24  0\n"
+   /* args *

Bug#1060120: freebsd-glue: modify gcc version for build

[Zhang Na]

Source: freebsd-glue
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
 
  Please modify gcc version for build, thanks! 
  I think the gcc version should not be fixed, but should be greater
  than a certain version, unless the required features only exist on a
  specific version.

  example:

  - gcc-9,
  + gcc (>= 9),



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 8ffd030b321a6c602cb91c60df5241b46ce7bc10 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Sat, 6 Jan 2024 03:44:19 +
Subject: [PATCH] modify gcc version for build

---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 1699ffe..87faabe 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders:
  Steven Chamberlain ,
 Build-Depends:
  debhelper (>= 8.0),
- gcc-9,
+ gcc (>= 9),
  kfreebsd-kernel-headers (>= 10.0~3) [kfreebsd-any],
  freebsd-mk,
  bmake,
diff --git a/debian/rules b/debian/rules
index b11b752..503ee26 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ DEB_HOST_ARCH_OS?= $(shell dpkg-architecture 
-qDEB_HOST_ARCH_OS)
 # Determine host architecture compiler
 DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 ifeq ($(origin CC),default)
-CC := $(DEB_HOST_GNU_TYPE)-gcc-9
+CC := $(DEB_HOST_GNU_TYPE)-gcc
 endif
 
 # Determine build architecture compiler
-- 
2.43.0

Bug#1060050: petsc: update debian/control for loong64

[Zhang Na]

Source: petsc
Version: 3.19.6
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/control for loong64, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 912ec965986f52472d9784ff5ef9fafa780f0162 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Fri, 5 Jan 2024 09:15:06 +
Subject: [PATCH] update debian/control for loong64

---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 82c8c6b4..3fb2c8e2 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper-compat (= 13), python3, gfortran,
  liblapack-dev | libopenblas-dev | libatlas-base-dev | liblapack.so,
  libsuitesparse-dev (>= 1:5.6.0),
  libhypre-dev (>= 2.21.0),
- libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64],
+ libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64 loong64],
  libptscotch-dev,
  libhdf5-mpi-dev (>= 1.10.6+repack-1),
  libscalapack-mpi-dev,
@@ -370,7 +370,7 @@ Section: libdevel
 Depends: libpetsc64-real3.19 (= ${binary:Version}),
  libpetsc3.19-dev-common (= ${source:Version}),
  ${MPI:Depends},
- libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64],
+ libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64 loong64],
  libmumps64-dev,
  libtrilinos-zoltan-dev [amd64 arm64 ppc64el s390x ppc64],
  gfortran,
@@ -418,7 +418,7 @@ Section: debug
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libpetsc-real3.19-dev (= ${binary:Version}),
  libpetsc3.19-dev-common (= ${source:Version}),
- libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64],
+ libhypre64m-dev (>= 2.21.0) [amd64 arm64 mips64el ppc64el s390x alpha ia64 
ppc64 riscv64 sparc64 loong64],
  libtrilinos-zoltan-dev [amd64 arm64 ppc64el s390x ppc64],
  ${misc:Depends}, ${shlibs:Depends},
  python3, ${python3:Depends}
-- 
2.43.0

Bug#1060035: prison-kf5: update debian/libkf5prison5.symbols for loong64

[Zhang Na]

Source: prison-kf5
Version: 5.107.0-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/libkf5prison5.symbols for loong64, thanks!




-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From f14c6fa0c27d50ac29696ec75717d81ecae0f7b7 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Fri, 5 Jan 2024 03:16:47 +
Subject: [PATCH] update debian/libkf5prison5.symbols for loong64

---
 debian/libkf5prison5.symbols | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libkf5prison5.symbols b/debian/libkf5prison5.symbols
index ac6aae6..187cf42 100644
--- a/debian/libkf5prison5.symbols
+++ b/debian/libkf5prison5.symbols
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 5.85.0 alpha amd64 arm64 armel armhf hurd-i386 i386 
ia64 m68k mips64el ppc64el riscv64 sh4 x32
+# SymbolsHelper-Confirmed: 5.85.0 alpha amd64 arm64 armel armhf hurd-i386 i386 
ia64 loong64 m68k mips64el ppc64el riscv64 sh4 x32
 libKF5Prison.so.5 libkf5prison5 #MINVER#
 * Build-Depends-Package: libkf5prison-dev
  _ZN6Prison13createBarcodeENS_11BarcodeTypeE@Base 5.25.0~
-- 
2.43.0

Bug#1059972: dpdk: add loong64 support

[Zhang Na]

Source: dpdk
Version: 23.11-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
 
  Add loong64 support, please! I have verified it on my PC. Thanks!

build log:
dpkg-deb --root-owner-group --build debian/librte-acl24 ..
dpkg-deb: building package 'librte-acl24' in 
'../librte-acl24_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build 
debian/.debhelper/librte-acl24/dbgsym-root ..
dpkg-deb: building package 'librte-acl24-dbgsym' in 
'../librte-acl24-dbgsym_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build debian/librte-baseband-acc24 ..
dpkg-deb: building package 'librte-baseband-acc24' in 
'../librte-baseband-acc24_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build 
debian/.debhelper/librte-baseband-acc24/dbgsym-root ..
dpkg-deb: building package 'librte-baseband-acc24-dbgsym' in 
'../librte-baseband-acc24-dbgsym_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build 
debian/librte-baseband-fpga-5gnr-fec24 ..
dpkg-deb: building package 'librte-baseband-fpga-5gnr-fec24' in 
'../librte-baseband-fpga-5gnr-fec24_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build 
debian/.debhelper/librte-baseband-fpga-5gnr-fec24/dbgsym-root ..
dpkg-deb: building package 'librte-baseband-fpga-5gnr-fec24-dbgsym' in 
'../librte-baseband-fpga-5gnr-fec24-dbgsym_23.11-1_loong64.deb'.
dpkg-deb --root-owner-group --build 
debian/librte-baseband-fpga-lte-fec24 ..
dpkg-deb: building package 'librte-baseband-fpga-lte-fec24' in 
'../librte-baseband-fpga-lte-fec24_23.11-1_loong64.deb'.
 dpkg-genbuildinfo --build=binary -O../dpdk_23.11-1_loong64.buildinfo
 dpkg-genchanges --build=binary -O../dpdk_23.11-1_loong64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-source: info: using options from dpdk-23.11/debian/source/options: 
--extend-diff-ignore=(^|/)(\.gitreview|\.git|maven_env.txt)$
dpkg-buildpackage: info: binary-only upload (no source included)





-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 7b855f81eee81ea607830e377c649d27d9774cb0 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Thu, 4 Jan 2024 09:16:42 +
Subject: [PATCH] add loong64 support

---
 debian/control  | 396 ++--
 debian/librte-eal24.symbols |   2 +-
 debian/rules|   2 +-
 3 files changed, 200 insertions(+), 200 deletions(-)

diff --git a/debian/control b/debian/control
index 9c3f7f9..4d151fb 100644
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,7 @@ Vcs-Browser: https://salsa.debian.org/debian/dpdk
 
 Package: dpdk
 Section: admin
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Depends: pci.ids | hwdata,
  pciutils,
  procps,
@@ -90,7 +90,7 @@ Description: Data Plane Development Kit (runtime)
  This package contains the runtime environment to run DPDK applications.
 
 Package: librte-meta-baseband
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Multi-Arch: same
 Depends: ${librte:Baseband},
  ${misc:Depends},
@@ -101,7 +101,7 @@ Description: Data Plane Development Kit (baseband libraries)
  This is a metapackage to pull in all the librte baseband libraries.
 
 Package: librte-meta-bus
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Multi-Arch: same
 Depends: ${librte:Bus},
  ${misc:Depends},
@@ -112,7 +112,7 @@ Description: Data Plane Development Kit (bus libraries)
  This is a metapackage to pull in all the librte bus libraries.
 
 Package: librte-meta-common
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Multi-Arch: same
 Depends: ${librte:Common},
  ${misc:Depends},
@@ -123,7 +123,7 @@ Description: Data Plane Development Kit (common libraries)
  This is a metapackage to pull in all the librte common libraries.
 
 Package: librte-meta-compress
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Multi-Arch: same
 Depends: ${librte:Compress},
  ${misc:Depends},
@@ -134,7 +134,7 @@ Description: Data Plane Development Kit (compress libraries)
  This is a metapackage to pull in all the librte compress libraries.
 
 Package: librte-meta-crypto
-Architecture: amd64 arm64 ppc64el riscv64
+Architecture: amd64 arm64 ppc64el riscv64 loong64
 Multi-Arch: same
 Depends: ${librte:Crypto},
  ${misc:Depends},
@@ -145,7 +145,7 @@ Description: Data Plane Development Kit (crypto librar

Bug#1059952: curl: update debian/control for loong64

[Zhang Na]

Package: curl
Version: 8.2.1-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/control for loong64, thanks!

Na Zhang


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages curl depends on:
ii  libc6 2.37-13
ii  libcurl4  8.2.1-1
ii  libssl3   3.1.4-2
ii  zlib1g1:1.3.dfsg-3

curl recommends no packages.

curl suggests no packages.

-- no debconf information
>From 7d2909a4b5c970e041e6733e1ae750f736fa9cbd Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Thu, 4 Jan 2024 01:30:59 +
Subject: [PATCH] update debian/control for loong64

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 953ffb4..b06d3c3 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Build-Depends:
  openssh-server ,
  python3:native ,
  python3-impacket ,
- gnutls-bin [amd64 arm64 armel armhf i386 mips64el mipsel s390x powerpc ppc64 
riscv64] ,
+ gnutls-bin [amd64 arm64 armel armhf i386 loong64 mips64el mipsel s390x 
powerpc ppc64 riscv64] ,
  quilt,
  stunnel4 ,
  zlib1g-dev,
-- 
2.43.0

Bug#1059550: jellyfish: add loong64 support

[Zhang Na]

Source: jellyfish
Version: 2.3.1-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
  
  Please add loong64 support in debian/control, thanks!

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 59324455b12992fad1eb016174805c4a26661131 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Thu, 28 Dec 2023 07:03:30 +
Subject: [PATCH] add loong64 support

---
 debian/control | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index 77a0fba..9c13507 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Homepage: https://github.com/gmarcais/Jellyfish
 Rules-Requires-Root: no
 
 Package: jellyfish
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libjellyfish-2.0-2 (= ${binary:Version})
@@ -49,7 +49,7 @@ Description: count k-mers in DNA sequences
  format using the "jellyfish dump" command.
 
 Package: libjellyfish-2.0-2
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
@@ -73,7 +73,7 @@ Description: count k-mers in DNA sequences (dynamic library 
of jellyfish)
  jellyfish is linked to.
 
 Package: libjellyfish-2.0-dev
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Section: libdevel
 Depends: ${misc:Depends},
  libjellyfish-2.0-2 (= ${binary:Version})
@@ -96,7 +96,7 @@ Description: count k-mers in DNA sequences (development files 
of jellyfish)
  header files)
 
 Package: python3-dna-jellyfish
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Section: python
 Depends: ${python3:Depends},
  ${misc:Depends},
@@ -119,7 +119,7 @@ Description: count k-mers in DNA sequences (Python bindings 
of jellyfish)
  This package contains the Python bindings of jellyfish.
 
 Package: libjellyfish-perl
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Multi-Arch: same
 Section: perl
 Depends: ${perl:Depends},
-- 
2.43.0

Bug#1059508: tcsh: Compilation failed on multiple architectures

[Zhang Na]

Please try again,  I did not occur this error. This has nothing to do 
with the architecture, perhaps you can help solve this permission problem.



## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
68. commands.at:1041: testing nice ...
./commands.at:1045: tcsh -f -c 'nice set var=1; echo $?var'
--- /dev/null    2023-08-30 13:17:09.0 +
+++ /<>/testsuite.dir/at-groups/68/stderr 2023-09-01 
09:12:12.022965657 +

@@ -0,0 +1 @@
+setpriority: Permission denied.
68. commands.at:1041: 68. nice (commands.at:1041): FAILED (commands.at:1045)

Bug#1059508: tcsh: Compilation failed on multiple architectures

[Zhang Na]

Source: tcsh
Version: 6.24.10-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  https://buildd.debian.org/status/package.php?p=tcsh=sid
  Compilation failed on multiple architectures, the reason for failure is the 
same. You should compile using regular users instead of root. The shell prompts 
for root and user are different, and testing will result in errors for root.
  I have verified on Loong64.
  Many packages depend on tcsh, please help compile them through,
  thanks!

   my test:
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'tcsh-dbgsym' in 
'../tcsh-dbgsym_6.24.10-3_loong64.deb'.
dpkg-deb: building package 'tcsh' in '../tcsh_6.24.10-3_loong64.deb'.
 dpkg-genbuildinfo -O../tcsh_6.24.10-3_loong64.buildinfo
 dpkg-genchanges -O../tcsh_6.24.10-3_loong64.changes
dpkg-genchanges: info: not including original source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: binary and diff upload (original source NOT included)
zhangna@localhost:~/tcsh-1/tcsh-6.24.10$ ls ../
build.log  tcsh_6.24.10-3.debian.tar.xz  
tcsh_6.24.10-3_loong64.changes
tcsh-6.24.10   tcsh_6.24.10-3.dsc
tcsh_6.24.10-3_loong64.deb
tcsh-dbgsym_6.24.10-3_loong64.deb  tcsh_6.24.10-3_loong64.buildinfo  
tcsh_6.24.10.orig.tar.gz
zhangna@localhost:~$ arch
loongarch64



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1059262: trilinos: add loongarch64 support

[Zhang Na]

Source: trilinos
Version: 13.2.0-5
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please add loong64 support in debian/control, thanks!

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 5228d627563b76c942c0ffb84121269f8a350586 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Fri, 22 Dec 2023 07:18:59 +
Subject: [PATCH] add loongarch64 support

---
 debian/control | 176 -
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/debian/control b/debian/control
index 3caba1cb..0a56f351 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Vcs-Git: https://salsa.debian.org/science-team/trilinos.git
 Vcs-Browser: https://salsa.debian.org/science-team/trilinos
 
 Package: trilinos-all-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${misc:Depends}, ${mydevpackages}
@@ -50,7 +50,7 @@ Description: object-oriented framework for large-scale 
problems - development fi
  This package depends on all Trilinos development packages.
 
 Package: trilinos-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${misc:Depends}
@@ -65,7 +65,7 @@ Description: object-oriented framework for large-scale 
problems - development fi
  This package contains the development header and some makefile templates.
 
 Package: libtrilinos-amesos-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -77,7 +77,7 @@ Description: direct sparse solver package - runtime files
  This package contains the dynamic libraries.
 
 Package: libtrilinos-amesos-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 # Manually add libtrilinos-trilinosss-dev as dependency until
@@ -92,7 +92,7 @@ Description: direct sparse solver package - development files
  This package provides headers.
 
 Package: libtrilinos-amesos2-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -104,7 +104,7 @@ Description: next generation direct sparse solver package - 
runtime files
  This package contains the dynamic libraries.
 
 Package: libtrilinos-amesos2-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 # Manually add libtrilinos-trilinosss-dev as dependency until
@@ -119,7 +119,7 @@ Description: next generation direct sparse solver package - 
development files
  This package provides headers.
 
 Package: libtrilinos-anasazi-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -134,7 +134,7 @@ Description: large-scale eigenvalue algorithms - runtime 
files
  This package contains the dynamic libraries.
 
 Package: libtrilinos-anasazi-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 Depends: libtrilinos-anasazi-13.2 (= ${binary:Version}), trilinos-dev, 
${misc:Depends}
@@ -150,7 +150,7 @@ Description: large-scale eigenvalue algorithms - 
development files
  This package provides headers.
 
 Package: libtrilinos-aztecoo-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -164,7 +164,7 @@ Description: object-oriented interface to the Aztec solver 
- runtime files
  This package contains the dynamic libraries.
 
 Package: libtrilinos-aztecoo-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 Depends: liblapack-dev, libtrilinos-aztecoo-13.2 (= ${binary:Version}), 
trilinos-dev, ${misc:Depends}
@@ -179,7 +179,7 @@ Description: object-oriented interface to the Aztec solver 
- development files
  This package provides headers.
 
 Package: libtrilinos-belos-13.2
-Architect

Bug#1059214: python-skbio: add loong64 support

[Zhang Na]

Source: python-skbio
Version: 0.5.9-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
  
  Please add loong64 support in debian/control, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 2519e11aeacee9685b00a063046c4e7a43f50e34 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Thu, 21 Dec 2023 11:30:42 +
Subject: [PATCH] add loong64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 8d89f0f..53c1a02 100644
--- a/debian/control
+++ b/debian/control
@@ -54,7 +54,7 @@ Description: Data structures, algorithms, educational 
resources for bioinformati
 Build-Profiles: 
 
 Package: python3-skbio
-Architecture: amd64 arm64 mips64el ppc64el riscv64
+Architecture: amd64 arm64 mips64el ppc64el riscv64 loong64
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  ${python3:Depends},
-- 
2.43.0

Bug#1059207: aseba: add loong64 support

[Zhang Na]

Source: aseba
Version: 1.6.99+dfsg-8
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support

diff --git a/debian/control b/debian/control
index 1dad46e..b4c3cb4 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Vcs-Git: https://salsa.debian.org/science-team/aseba.git
 Homepage: https://github.com/aseba-community/aseba

 Package: aseba
-Architecture: any-amd64 any-i386 arm64 mips64el mipsel riscv64 s390x ppc64el
+Architecture: any-amd64 any-i386 arm64 mips64el mipsel riscv64 s390x ppc64el 
loong64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: aseba-plugin-blockly


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1059021: baconqrcode: add loongarch64 support

[Zhang Na]

Source: baconqrcode
Version: 2.0.8-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loongarch64 support, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 853fa5b2b72851a26f29498335c2e4b99523cee7 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 12:32:08 +
Subject: [PATCH] add loongarch64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9205873..8cdd33b 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Rules-Requires-Root: no
 Depends: php, ${phpcomposer:Debian-require}
 
 Package: php-bacon-qr-code
-Architecture: any-amd64 any-arm64 any-ppc64 any-ppc64el any-s390x any-mips64el 
any-riscv64 any-sparc64 any-sparc64 any-ia64
+Architecture: any-amd64 any-arm64 any-ppc64 any-ppc64el any-s390x any-mips64el 
any-riscv64 any-sparc64 any-sparc64 any-ia64 any-loong64
 Depends: php-imagick, ${misc:Depends}, ${phpcomposer:Debian-require}
 Recommends: ${phpcomposer:Debian-recommend}
 Suggests: ${phpcomposer:Debian-suggest}
-- 
2.43.0

Bug#1058998: discosnp: add loong64 support

[Zhang Na]

Source: discosnp
Version: 1:2.6.2-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support, fix debian/contorl.
  Dependent package libgatbcore-dev, similar questions have been submitted 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058714)



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 29960adf5bd9e0598c6625d4e884dec8a3bd6b55 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 07:36:18 +
Subject: [PATCH] add loong64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f7a7afd..d0a9ddc 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Homepage: http://colibread.inria.fr/discosnp/
 Rules-Requires-Root: no
 
 Package: discosnp
-Architecture: any-amd64 arm64 mips64el ppc64el ia64 ppc64 riscv64 sparc64 alpha
+Architecture: any-amd64 arm64 mips64el ppc64el ia64 ppc64 riscv64 sparc64 
alpha loong64
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  ${python3:Depends},
-- 
2.43.0

Bug#1058992: odil: add loong64 support

[Zhang Na]

Source: odil
Version: 0.12.2-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support, please! Thanks.

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 6c23feb87e751cae8de5661a2f343f538c3f6b48 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 06:24:05 +
Subject: [PATCH] add loong64 support

---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 2204f1c..8ae7434 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Homepage: https://github.com/lamyj/odil
 Rules-Requires-Root: no
 
 Package: libodil0
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x alpha ia64 
powerpc ppc64 riscv64 x32
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x alpha ia64 
powerpc ppc64 riscv64 x32 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
@@ -55,7 +55,7 @@ Description: C++11 library for the DICOM standard
  This package contains the shared library.
 
 Package: libodil-dev
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x loong64
 Multi-Arch: same
 Section: libdevel
 Depends: libodil0 (= ${binary:Version}),
@@ -94,7 +94,7 @@ Description: C++11 library for the DICOM standard 
(documentation)
  This package contains the documentation files.
 
 Package: python3-odil
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x loong64
 Multi-Arch: foreign
 Section: python
 Depends: libodil0 (= ${binary:Version}),
-- 
2.43.0

Bug#1058919: pktanon: add loong64 support

[Zhang Na]

On Mon, 18 Dec 2023 10:20:19 + Zhang Na wrote:
> Source: pktanon
> Version: 2~git20160407.0.2bde4f2+dfsg-11
> Severity: normal
> X-Debbugs-Cc: zhan...@loongson.cn
>
> Dear Maintainer,
>
> Add loong64 support, please.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unreleased
> APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
>
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU 
threads)
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 
(charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set

> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
>

diff --git a/debian/control b/debian/control
index 1d1c793..9612928 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Vcs-Git: https://salsa.debian.org/debian/pktanon.git
 Vcs-Browser: https://salsa.debian.org/debian/pktanon

 Package: pktanon
-Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 
m68k powerpc ppc64 riscv64 sh4 sparc64 x32
+Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 
m68k powerpc ppc64 riscv64 sh4 sparc64 x32 loong64

 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: profile-based traffic anonymizer
  PKtAnon performs network trace anonymization, e.g. on pcap files.
--
2.43.0

>From 99e9175ab4a768f66958c7aae32d3e2accb61102 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 18 Dec 2023 10:17:07 +
Subject: [PATCH] add loong64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 1d1c793..9612928 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Vcs-Git: https://salsa.debian.org/debian/pktanon.git
 Vcs-Browser: https://salsa.debian.org/debian/pktanon
 
 Package: pktanon
-Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
+Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32 loong64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: profile-based traffic anonymizer
  PKtAnon performs network trace anonymization, e.g. on pcap files.
-- 
2.43.0

Bug#1058919: pktanon: add loong64 support

[Zhang Na]

Source: pktanon
Version: 2~git20160407.0.2bde4f2+dfsg-11
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support, please.



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1058907: princeprocessor: Add support for loong64

[Zhang Na]

Package: princeprocessor
Version: 0.22-5
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please add 'loong64' to the 'Architecture' field in the debian/control file, 
patch file is attached.

Thanks,
Zhang Na

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages princeprocessor depends on:
ii  libc6  2.37-13

princeprocessor recommends no packages.

princeprocessor suggests no packages.

-- no debconf information
diff -Naur princeprocessor-0.22-orj/debian/control 
princeprocessor-0.22/debian/control
--- princeprocessor-0.22-orj/debian/control 2023-12-11 12:55:39.0 
+
+++ princeprocessor-0.22/debian/control 2023-12-18 07:29:58.031494138 +
@@ -11,7 +11,7 @@
 Homepage: https://github.com/hashcat/princeprocessor
 
 Package: princeprocessor
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha kfreebsd-amd64 ppc64 
riscv64 sparc64 x32
+Architecture: amd64 arm64 mips64el ppc64el s390x alpha kfreebsd-amd64 ppc64 
riscv64 sparc64 x32 loong64
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Description: standalone password candidate generator using the PRINCE algorithm

Bug#1057765: atril: Blured in fullscreen mode if I have used GDK_DPI_SCALE & GDK_SCALE

[Zhang Xiaowei]

Package: atril
Version: 1.26.0-2+b1
Severity: normal

   * What led up to the situation?

If I
$ GDK_DPI_SCALE=0.8 GDK_SCALE=2 atril xxx.pdf

And press F11 to enter fullscreen mode. It's blured.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

$ GDK_DPI_SCALE=0.8 GDK_SCALE=2 atril xxx.pdf

Press F11 to enter fullscreen.

   * What was the outcome of this action?

It's blured.

   * What outcome did you expect instead?

$ GDK_DPI_SCALE=1 GDK_SCALE=1 atril xxx.pdf

It's clear.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.13 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages atril depends on:
ii  atril-common 1.26.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
hi  libatk1.0-0  2.50.0-1
ii  libatrildocument31.26.0-2+b1
ii  libatrilview31.26.0-2+b1
hi  libc62.37-12
ii  libcaja-extension1   1.26.1-1
hi  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
hi  libglib2.0-0 2.78.1-4
hi  libgtk-3-0   3.24.38-6
ii  libice6  2:1.0.10-1
ii  libsecret-1-00.21.1-1
ii  libsm6   2:1.2.3-1
ii  libxml2  2.9.14+dfsg-1.3+b1
ii  shared-mime-info 2.4-1

Versions of packages atril recommends:
hi  dbus-user-session [default-dbus-session-bus]  1.14.10-3
hi  dbus-x11 [dbus-session-bus]   1.14.10-3
ii  gvfs  1.52.1-1

Versions of packages atril suggests:
ii  caja  1.26.1-1
ii  poppler-data  0.4.12-1
ii  unrar 1:7.0.4-1

-- no debconf information

Bug#1057757: qbs: FTBFS on loong64 for dh_makeshlibs

[JiaLing Zhang]

Package: qbs
Version: 2.1.2-1
Severity: normal
Tags: FTBFS loong64
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

  Hi, I found qbs build failed on loong64 for symbols file less loong64 arch, 
Please looks 
https://buildd.debian.org/status/fetch.php?pkg=qbs=loong64=2.1.2-1=1697186185=0

Thanks,
JiaLing

Bug#1055636: ogre: Add loongarch64 support

[JiaLing Zhang]

Package: ogre-1.9
Severity: serious
File: ogre
Tags: upstream patch ftbfs loong64
Justification: fails to build from source
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

This package need support for loongarch64,Please help.
--- ogre-1.9-1.9.0+dfsg1.orig/OgreMain/include/OgrePlatform.h
+++ ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgrePlatform.h
@@ -166,7 +166,7 @@ namespace Ogre {
 #endif
 
 /* Find the arch type */
-#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) || 
defined(__alpha__) || defined(__ia64__) || defined(__s390__) || 
defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) || 
defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen 
== 64))
+#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) || 
defined(__alpha__) || defined(__ia64__) || defined(__s390__) || 
defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) || 
defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen 
== 64)) || defined(__loongarch64)
 #   define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64
 #else
 #   define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32

Bug#1053593: polyml: Please support for loongarch64

[JiaLing Zhang]

Source: polyml
Version: 5.7.1-5
Severity: normal
Tags: ftbfs upstream loongarch64


Hello , the upstream polyml has been support loongarch64 . Chould we
update the source . 

Bug#1053588: ghc: Please add support for loongarch64

[JiaLing Zhang]

Source: ghc
Version: 9.4.6-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source

hello,The upstream ghc-9.6.3 has been support loongarch64.Chould we
update the source ?

Bug#1052603: ode: Please add loongarch64 support .

[JiaLing Zhang]

Source: ode
Version: 2:0.16.2-1
Severity: normal
Tags: patch loongarch64

Hello!
  
   The package build failed in buildd and The ode upstream has support 
loongarch64 ,Please help to fix this .

Thanks,
JiaLing


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: ode upstream has support loongarch64. 
Author: JiaLing Zhang 

--- ode-0.16.2.orig/include/ode/odeconfig.h
+++ ode-0.16.2/include/ode/odeconfig.h
@@ -84,6 +84,7 @@
 #if defined(__aarch64__) || defined(__alpha__) || defined(__ppc64__) \
 || defined(__s390__) || defined(__s390x__) || defined(__zarch__) \
 || defined(__mips__) || defined(__powerpc64__) || defined(__riscv) \
+|| defined(__loongarch64) \
 || (defined(__sparc__) && defined(__arch64__))
 #include 
 typedef int64_t dint64;

Bug#1052595: liburcu: Please add support for loong64

[JiaLing Zhang]

Source: liburcu
Version: 0.14.0-1
Severity: serious
Tags: ftbfs loongarch64

Hello!

the liburcu build failed in buildd , the upstream have support
loongarch. Please update the source.

thanks!
JiaLing

[1]: 
https://github.com/urcu/userspace-rcu/commit/dc46a9c324ae94d89da41ea9a3f97503115df88e

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[Mouse Zhang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ukui-kwin":

* Package name : ukui-kwin
   Version  : 5.27.5-1
   Upstream contact : plasma-de...@kde.org
* URL  : https://gitee.com/openkylin/ukui-kwin
* License  : LGPL-2+, GPL-2+, BSD-3-clause, GFDL-NIV-1.2+, 
LGPL-2.1+3+KDEeV, GPL-2+3+KDEeV, LGPL-2.1+3+KDEeV-translations
* Vcs  : https://gitee.com/openkylin/ukui-kwin
   Section  : kde

The source builds the following binary packages:

  ukui-kwin-common - UKUI window manager, common files
  ukui-kwin-data - UKUI window manager data files
  ukui-kwin-dev - UKUI window manager - devel files
  ukui-kwin-wayland - UKUI window manager, wayland version, PREVIEW release
  ukui-kwin-x11 - UKUI window manager, X11 version
  libukui-kwineffects14 - UKUI window manager effects library
  libukui-kwinglutils14 - UKUI window manager gl utils library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/ukui-kwin/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/u/ukui-kwin/ukui-kwin_5.27.5-1.dsc

Changes for the initial release:

ukui-kwin (5.27.5-1) unstable; urgency=medium
.
   * Initial release. (Closes: #1050847)

Regards,

Bug#1051916: mingw-w64 add loongarch support.

[JiaLing Zhang]

Source: mingw-w64
Version: 11.0.1-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source

Hello!

The mingw-w64 build failed in buildd , we should add loongarch support
for this . Please help to fix this problem .

Thanks,
JiaLing

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mingw-w64=loong64=11.0.1-2=1692597666=0
Description: Add loongarch support
Author: JiaLing Zhang 

--- mingw-w64-11.0.1.orig/mingw-w64-tools/widl/include/basetsd.h
+++ mingw-w64-11.0.1/mingw-w64-tools/widl/include/basetsd.h
@@ -331,6 +331,8 @@ typedef ULONG_PTR KAFFINITY, *PKAFFINITY
 # define WORDS_BIGENDIAN
 #elif defined(__hppa__)
 # undef  WORDS_BIGENDIAN
+#elif defined(__loongarch__) && defined(__loongarch64)
+# undef  WORDS_BIGENDIAN
 #elif defined(__m68k__)
 # define WORDS_BIGENDIAN
 #elif defined(__riscv) && __riscv_xlen == 64

Bug#1050426: u3-tool: Please add loong64 to architecture list

[JiaLing Zhang]

Source: u3-tool
Version: 0.3-3
Severity: wishlist
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please add loong64 to architecture list. I can confirm this could build in 
loong64 . 

Bug#1050420: mozc:Please add loong64 to architectures list

[JiaLing Zhang]

Source: mozc
Version: 2.28.4715.102+dfsg-2.2
Severity: wishlist
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please add loong64 to architectures list .

Bug#1050320: ltrace:please add support for loong64

[JiaLing Zhang]

Source: ltrace
Version: 0.7.3-6.4
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

The upstream has support loongarch , Please add support for loong64.

Bug#1050318: kgb: please add support for loong64

[JiaLing Zhang]

Source: kgb
Version: 1.0b4+ds-14
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
Please add loong64 to architectures list. I have build this in loong64.

Bug#1050156: flash-kernel: Please add loong64 to architectures list.

[JiaLing Zhang]

Source: flash-kernel
Version: 3.107
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
Please add loong64 to architectrues list . 

Bug#1050154: dmidecode:Please add loong64 to architecture list.

[JiaLing Zhang]

Package: dmidecode
Version: 3.5-2
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
Please add loong64 to architecture list .

Bug#1050068: ddccontrol: Please add loong64 to architectures list.

[JiaLing Zhang]

Package: ddccontrol
Version: 0.6.0-8
Severity: wishlist
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please add loong64 to architectures list , This package chould build in loong64 
. 

Bug#1049992: acpi: Please add loong64 architecture for acpi package.

[JiaLing Zhang]

Package: acpi
Version: acpi_1.7-1.2
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please add 'loong64' to architecture stanza of debian/control.


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Bug#1040031: bird2: Version bump request (v2.13.1)

[Zhang Zongyu]

Package: bird2
Version: 2.0.12-7
Severity: wishlist

Dear Maintainer,

There is a new version of bird2 available on the project homepage: 2.13.1.
It was released on Jun 22 2023.

The new version includes all the patches that Debian carries now.

It also includes the following:
 o BGP: Fix role check when no capability option is present
 o Filter: Fixed segfault when a case option had an empty block
 o Babel: IPv4 via IPv6 extension (RFC 9229)
 o Babel: Improve authentication on lossy networks
 o BGP: New 'allow bgp_med' option
 o BSD: Support for IPv4 routes with IPv6 nexthop on FreeBSD
 o Experimental BMP protocol implementation
 o Important bugfixes

The new version supports more features of the Babel protocol,
the IPv4 via IPv6 extension (RFC 9229).
It is a nice feature that simplifies address management significantly.
Users will be happy to see it landing on Debian.

Thank you.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-9-arm64 (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

Versions of packages bird2 depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  libc62.36-9
ii  libreadline8 8.2-1.3
ii  libssh-gcrypt-4  0.10.5-2
ii  libtinfo66.4-4
ii  ucf  3.0043+nmu1

bird2 recommends no packages.

Versions of packages bird2 suggests:
pn  bird2-doc  

-- Configuration Files:
/etc/bird/envvars [Errno 13] Permission denied: '/etc/bird/envvars'

-- no debconf information

Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs

[ZHANG, Yuntian]

Package: cloud-initramfs-growroot
Version: 0.18.debian13
Severity: important
X-Debbugs-Cc: y...@radxa.com

Dear Maintainer,

cloud-initramfs-growroot was working for our custom Debian 11 system,
but when we created the Debian 12 system, the following errors were
observed during booting:

GROWROOT: /sbin/growpart: 824: /sbin/growpart: grep: not found
/sbin/growpart: 853: /sbin/growpart: sed: not found
WARN: unknown label 
/sbin/growpart: 354: /sbin/growpart: sed: not found
FAILED: sed failed on dump output
/sbin/growpart: 83: /sbin/growpart: rm: not found

Needless to say the root partition was not grown. We had to add
following lines to get it working again:

# in /usr/share/initramfs-tools/hooks/growroot:
copy_exec /usr/bin/grep /bin
copy_exec /usr/bin/sed /bin
copy_exec /usr/bin/rm /bin
copy_exec /usr/bin/awk /bin

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.33-1-stable (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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)

Versions of packages cloud-initramfs-growroot depends on:
ii  cloud-utils  0.33-1
ii  fdisk2.38.1-5+b1
ii  initramfs-tools  0.142
ii  util-linux   2.38.1-5+b1

cloud-initramfs-growroot recommends no packages.

cloud-initramfs-growroot suggests no packages.

-- no debconf information

Bug#1027786: RFP: limine -- Modern, advanced, portable, multiprotocol bootloader.

[Eric Zhang]

Package: wnpp
Severity: wishlist

* Package name: limine
  Version : 4.20221230.0
  Upstream Author : mintsuki 
* URL : https://limine-bootloader.org/
* License : BSD
  Programming Lang: C
  Description : Modern, advanced, portable, multiprotocol bootloader.

Limine is an advanced, portable, multiprotocol bootloader that supports Linux,
multiboot 1 and 2, the native Limine boot protocol, and more. 

Limine is a very fast bootloader, and higly configurable. It is easier and
faster to configure compared to GNU GRUB as changing the configuration only
involves editing limine.cfg in /boot. I use it in one of my Arch Linux install
and it has been working great for me so far.

Limine has been packaged in Alpine Linux and EasyOS. It is also avaliable in the
AUR for Arch Linux. I would like to have the Debain team package it so it can be
adopted in the Debian environment.

Bug#1027125: kmplayer: desktop entry contains unsuported arguments

[ZHANG Yuntian]

Package: kmplayer
Version: 1:0.12.0b-3+b1
Severity: important
X-Debbugs-Cc: y...@radxa.com

Dear Maintainer,

After installing kmplayer, I found out I cannot open media files via GUI file
manager. After opening the desktop entry, I found out it contains unsupported
command line options "-caption %c %i", which causes the program to fail early.

After removing them the file association works correctly.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.110-1-rockchip (SMP w/6 CPU threads)
Kernel taint flags: TAINT_WARN
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)

Versions of packages kmplayer depends on:
ii  dbus-x111.12.24-0+deb11u1
ii  kio 5.78.0-5
ii  libc6   2.31-13+deb11u5
ii  libcairo2   1.16.0-5
ii  libdbus-1-3 1.12.24-0+deb11u1
ii  libdbus-glib-1-20.110-6
ii  libglib2.0-02.66.8-1
ii  libgtk2.0-0 2.24.33-2
ii  libkf5bookmarks55.78.0-2
ii  libkf5completion5   5.78.0-3
ii  libkf5configcore5   5.78.0-4
ii  libkf5configwidgets55.78.0-2
ii  libkf5coreaddons5   5.78.0-4
ii  libkf5i18n5 5.78.0-2
ii  libkf5iconthemes5   5.78.0-2
ii  libkf5kdelibs4support5  5.78.0-2
ii  libkf5kiocore5  5.78.0-5
ii  libkf5kiowidgets5   5.78.0-5
ii  libkf5mediaplayer5  5.78.0-2
ii  libkf5parts55.78.0-3
ii  libkf5textwidgets5  5.78.0-2
ii  libkf5widgetsaddons55.78.0-2
ii  libkf5xmlgui5   5.78.0-2
ii  libphonon4qt5-4 4:4.11.1-4
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5dbus5 5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5svg5  5.15.2-3
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libqt5x11extras55.15.2-2
ii  libqt5xml5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1
ii  libxcb1 1.14-3
ii  phonon4qt5  4:4.11.1-4

kmplayer recommends no packages.

Versions of packages kmplayer suggests:
pn  ffmpeg 
ii  konqueror  4:20.12.0-4
pn  mplayer
pn  vdr
pn  xawtv  

-- no debconf information

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

Hi, 

need to revert commit 066ecde6d826b4 "mmc: meson-gx: add SDIO interrupt support"

http://lists.infradead.org/pipermail/linux-amlogic/2022-December/014532.html

upstream has a WIP patch:
http://lists.infradead.org/pipermail/linux-amlogic/2022-December/014547.html

I don't have time to submit a patch to debian kernel.

could someone help?

BR.
Ning.

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

On Wed, Dec 21, 2022 at 05:29:25PM +0100, Diederik de Haas wrote:
> On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> > Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> > a self-built kernel from current master, it seems more likely to be an
> > upstream issue/regression.
> 
> I just noticed the following part from that linux-amlogic post:
> > I native build kernel from debian's kernel repo:
> > https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> > https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> > ures/arm64/meson all follow debian's kernel config.
original patches are:
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/features/npu
and
0001, 0002, 0004, 0005, 0006, 0007, 0021, 0022, 0037 in
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/features/khadas

> 
> That path doesn't seem to exist anymore, but got redirected to 'just' the 
> master branch and noticed the latest commit "update patches from khadas".
> When I looked into that, I saw there were a LOT of additional patches :-O
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
> features/khadas

I just want to apply all vendor patches to check whether wifi works.

you can review all patches, it not related to WIFI, thus I don't think
WIFI could magicly work.

> 
> The test I suggested in my previous reply would still be useful, but it could 
> also be that your patch-set is at fault.
this is reasonable suspect.

I also use default debian kernel:
https://packages.debian.org/experimental/arm64/linux-image-6.1.0-0-arm64/download
WIFI stop work in 2mins. Logs are same, I don't duplicate.

Default debian kernel 6.0 is good, and 6.1 is bad, this is a regression.

upstream and vendor said they didn't see this issue, thus report to
debian for help.

BR.
Ning.

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

On Wed, Dec 21, 2022 at 05:29:25PM +0100, Diederik de Haas wrote:
> On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> > Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> > a self-built kernel from current master, it seems more likely to be an
> > upstream issue/regression.
> 
> I just noticed the following part from that linux-amlogic post:
> > I native build kernel from debian's kernel repo:
> > https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> > https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> > ures/arm64/meson all follow debian's kernel config.
These patches are confirmed not related this issue.
> 
> That path doesn't seem to exist anymore, but got redirected to 'just' the 
> master branch and noticed the latest commit "update patches from khadas".
> When I looked into that, I saw there were a LOT of additional patches :-O
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
> features/khadas


khadas is the vendor, I tried to apply vendor's patches to make wifi
work.

you can just use default debian 6.1 kernel, to reproduce the issue.

> 
> The test I suggested in my previous reply would still be useful, but it could 
> also be that your patch-set is at fault.

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

Package: linux-image-arm64
Version: 6.1-1~exp1



Hi Debian Kernel Team

WIFI works well for my Arm64 SBCs (Khadas VIM1 & VIM3), both are Amlogic
SBC, S905x and A311D, with kernel 6.0 and early versions.

these two boards are well supported by debian kernel, with all functions
work out of box.

After update to 6.1, it stops work.

WIFI doesn't response, please check attached logs.

before send this bug to debian, I have asked upsteam[0], and device
vendor, whether they observe same issue, but the answers are no.

thus I suspect this is the problem of debian kernel.

[0] http://lists.infradead.org/pipermail/linux-amlogic/2022-December/014544.html

[  363.500845] INFO: task kworker/0:0:7 blocked for more than 120 seconds.
[  363.506290]   Tainted: G C 6.1.0-0-arm64 #1 Debian 
6.1-1~exp1
[  363.513749] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  363.521463] task:kworker/0:0 state:D stack:0 pid:7 ppid:2  
flags:0x0008
[  363.521478] Workqueue: events sdio_irq_work
[  363.521497] Call trace:
[  363.521502]  __switch_to+0xe4/0x160
[  363.521513]  __schedule+0x340/0x970
[  363.521521]  schedule+0x58/0xf0
[  363.521529]  __mmc_claim_host+0x104/0x290
[  363.521538]  sdio_irq_work+0x2c/0x90
[  363.521547]  process_one_work+0x1f4/0x460
[  363.521558]  worker_thread+0x188/0x4d0
[  363.521566]  kthread+0xe0/0xe4
[  363.521573]  ret_from_fork+0x10/0x20
[  363.521596] INFO: task kworker/u13:0:92 blocked for more than 120 seconds.
[  363.528292]   Tainted: G C 6.1.0-0-arm64 #1 Debian 
6.1-1~exp1
[  363.535758] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  363.543544] task:kworker/u13:0   state:D stack:0 pid:92ppid:2  
flags:0x0008
[  363.543557] Workqueue: brcmf_wq/mmc2:0001:1 brcmf_sdio_dataworker [brcmfmac]
[  363.543593] Call trace:
[  363.543596]  __switch_to+0xe4/0x160
[  363.543606]  __schedule+0x340/0x970
[  363.543614]  schedule+0x58/0xf0
[  363.543620]  __mmc_claim_host+0x104/0x290
[  363.543630]  sdio_claim_host+0x2c/0x40
[  363.543638]  brcmf_sdio_dataworker+0xa4/0x2174 [brcmfmac]
[  363.543665]  process_one_work+0x1f4/0x460
[  363.543674]  worker_thread+0x188/0x4d0
[  363.543681]  kthread+0xe0/0xe4
[  363.543688]  ret_from_fork+0x10/0x20
[  363.543714] INFO: task NetworkManager:515 blocked for more than 120 seconds.
[  363.550564]   Tainted: G C 6.1.0-0-arm64 #1 Debian 
6.1-1~exp1
[  363.557234] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  363.564613] task:NetworkManager  state:D stack:0 pid:515   ppid:1  
flags:0x000c
[  363.564622] Call trace:
[  363.564624]  __switch_to+0xe4/0x160
[  363.564632]  __schedule+0x340/0x970
[  363.564638]  schedule+0x58/0xf0
[  363.564643]  __mmc_claim_host+0x104/0x290
[  363.564650]  sdio_claim_host+0x2c/0x40
[  363.564656]  brcmf_sdio_bus_txctl+0x124/0x1b0 [brcmfmac]
[  363.564676]  brcmf_proto_bcdc_msg+0xb8/0x110 [brcmfmac]
[  363.564695]  brcmf_proto_bcdc_query_dcmd+0x48/0x1ec [brcmfmac]
[  363.564713]  brcmf_fil_cmd_data+0xe8/0x124 [brcmfmac]
[  363.564733]  brcmf_fil_cmd_data_get+0x50/0x80 [brcmfmac]
[  363.564751]  brcmf_cfg80211_dump_station+0xc0/0x15c [brcmfmac]
[  363.564770]  nl80211_dump_station+0x134/0x240 [cfg80211]
[  363.564808]  netlink_dump+0x114/0x2d4
[  363.564815]  __netlink_dump_start+0x154/0x304
[  363.564831]  genl_family_rcv_msg_dumpit+0x8c/0x140
[  363.564839]  genl_rcv_msg+0x1f0/0x264
[  363.564845]  netlink_rcv_skb+0x64/0x130
[  363.564851]  genl_rcv+0x40/0x5c
[  363.564857]  netlink_unicast+0x2d4/0x33c
[  363.564862]  netlink_sendmsg+0x1d8/0x450
[  363.564868]  sock_sendmsg+0x5c/0x70
[  363.564876]  sys_sendmsg+0x290/0x2f4
[  363.564880]  ___sys_sendmsg+0xb4/0x110
[  363.564885]  __sys_sendmsg+0x8c/0xf0
[  363.564890]  __arm64_sys_sendmsg+0x2c/0x40
[  363.564895]  invoke_syscall+0x50/0x120
[  363.564903]  el0_svc_common.constprop.0+0x4c/0xf4
[  363.564910]  do_el0_svc+0x34/0xd0
[  363.564916]  el0_svc+0x34/0xd4
[  363.564923]  el0t_64_sync_handler+0xf4/0x120
[  363.564928]  el0t_64_sync+0x18c/0x190
[  363.564937] INFO: task brcmf_wdog/mmc2:534 blocked for more than 120 seconds.
[  363.571596]   Tainted: G C 6.1.0-0-arm64 #1 Debian 
6.1-1~exp1
[  363.578802] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  363.586366] task:brcmf_wdog/mmc2 state:D stack:0 pid:534   ppid:2  
flags:0x0008
[  363.586373] Call trace:
[  363.586375]  __switch_to+0xe4/0x160
[  363.586381]  __schedule+0x340/0x970
[  363.586385]  schedule+0x58/0xf0
[  363.586389]  schedule_timeout+0x14c/0x180
[  363.586395]  __wait_for_common+0xd4/0x254
[  363.586400]  wait_for_completion+0x28/0x3c
[  363.586404]  mmc_wait_for_req_done+0x30/0xf0
[  363.586411]  mmc_wait_for_req+0xb8/0x10c
[  363.586415]  mmc_wait_for_cmd+0x6c/0xb0
[  363.586420]  mmc_io_rw_direct+0xa4/0x140
[  363.586425]  sdio_readb+0x54/0xa4
[  363.586430]  

Bug#1025954: u-boot-menu | add kalsrseed support (!7)

[Zhang Ning]

On Mon, Dec 12, 2022 at 09:29:25PM +, Vagrant Cascadian (@vagrant) wrote:
> 
> 
> 
> Vagrant Cascadian commented:
> 
> 
> This apparently causes issues with older u-boot versions:
> 
> https://bugs.debian.org/1025954

it just prints warning to  console, does it reject to boot?



> 
> I will revert this change until more testing can be done...
> 
> -- 
> Reply to this email directly or view it on GitLab: 
> https://salsa.debian.org/debian/u-boot-menu/-/merge_requests/7#note_361514
> You're receiving this email because of your account on salsa.debian.org.
> 
> 

Bug#1024617: CVE-2022-2601 is still not fixed on buster

[Zhang Boyang]

Package: grub2
Tags: security

Hi,

Although there are patches in `debian/patches/cve_2022_2601/`, they are 
not used by `debian/patches/series`. So the vulnerability is still not 
fixed in buster even its SBAT==3.


Bullseye seems OK. However, it seems debian's SBAT numbers should be 
bumped, so bullseye also needs an update.



Best Regards,
Zhang Boyang

Bug#1021694: linux-image-5.19.0-2-amd64: Some USB3.0 UAS devices does not work properly (R/W get stuck w/o involving file system)

[Zhang Chi]

Please discard this bugreport -- later I found this reproduces on the old
kernel as well and is probably a hardware issue.

On Thu, 13 Oct 2022 00:16:25 -0700 Chi Zhang  wrote:
> Package: src:linux
> Version: 5.19.11-1
> Severity: important
> X-Debbugs-Cc: zhangchi...@gmail.com
>
> Dear Maintainer,
>
> Using certain USB3.0 UAS devices (JMS567 bridge or ASM1153E + Micron M600)
> seems to be not working, but everything works after rebooting into an
older
> kernel (linux-image-5.10.0-18-amd64).
>
> File system does not seem to be involved as running tools like diskscan
on the
> whole device triggers the issue too.
>
> Symptom is R/W get stuck after a few MB is read/written. Sometimes running
> smartctl somehow nudges it a bit.
>
> Kernel logs will be attached.
>
>
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
>
> ** Model information
> sys_vendor: Dell Inc.
> product_name: Precision Tower 3430
> product_version:
> chassis_vendor: Dell Inc.
> chassis_version:
> bios_vendor: Dell Inc.
> bios_version: 1.20.0
> board_vendor: Dell Inc.
> board_name: 00CV7F
> board_version: A00
>
> ** PCI devices:
> 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 4-core
Workstation Processor Host Bridge/DRAM Registers [Coffee Lake S]
[8086:3e18] (rev 07)
> DeviceName: Onboard - Other
> Subsystem: Dell 8th Gen Core 4-core Workstation Processor Host
Bridge/DRAM Registers [Coffee Lake S] [1028:0860]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  Latency: 0
> IOMMU group: 0
> Capabilities: 
> Kernel driver in use: ie31200_edac
> Kernel modules: ie31200_edac
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-S
GT2 [UHD Graphics P630] [8086:3e96] (prog-if 00 [VGA controller])
> DeviceName: Onboard - Video
> Subsystem: Dell HD Graphics P630 [1028:0860]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 135
> IOMMU group: 1
> Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=16M]
> Region 2: Memory at 8000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 3000 [size=64]
> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> Capabilities: 

Bug#1017399: linux-image-5.18.0-4-loongson-3: does not boot when using zstd compressed initrd

[Rongwei Zhang]

Package: src:linux
Version: 5.18.16-1
Severity: important
X-Debbugs-Cc: pudh4...@gmail.com

Dear Maintainer,

I'm currently using a Loongson 3A4000 based system as my desktop computer.
After generating an initramfs image for the new kernel, it failed to boot.

Following serial console output was observed:

[0.00] Linux version 5.18.0-4-loongson-3 (debian-
ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils
for Debian) 2.38.90.20220713) #1 SMP PREEMPT Debian 5.18.16-1 (2022-08-10)
[0.00] CpuClock = 18
[0.00] The bridge chip is LS7A
[0.00] CP0_Config3: CP0 16.3 (0xdc8030a0)
[0.00] CP0_PageGrain: CP0 5.1 (0x2800)
[0.00] NUMA: Discovered 4 cpus on 1 nodes
[0.00] Node0: mem_type:1, mem_start:0x20, mem_size:0xee MB
[0.00]start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
[0.00] Node0: mem_type:2, mem_start:0x9020, mem_size:0x6fe MB
[0.00]start_pfn:0x24080, end_pfn:0x4, num_physpages:0x1fb00
[0.00] Node0: mem_type:2, mem_start:0x12000, mem_size:0x1600 MB
[0.00]start_pfn:0x48000, end_pfn:0xa, num_physpages:0x77b00
[0.00] Node0's addrspace_offset is 0x0
[0.00] Node0: start_pfn=0x80, end_pfn=0xa
[0.00] NUMA: set cpumask cpu 0 on node 0
[0.00] NUMA: set cpumask cpu 1 on node 0
[0.00] NUMA: set cpumask cpu 2 on node 0
[0.00] NUMA: set cpumask cpu 3 on node 0
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 0014c001 (ICT Loongson-3)
[0.00] FPU revision is: 00f70501
[0.00] MSA revision is: 00060140
[0.00] OF: fdt: No chosen node found, continuing without
[0.00] MIPS: machine is loongson,loongson64g-4core-ls7a
[0.00] Initial ramdisk at: 0x98000a49 (20085726 bytes)
[0.00] software IO TLB: mapped [mem
0x0020c000-0x0220c000] (32MB)
[0.00] SMBIOS 3.0 present.
[0.00] DMI: SANCOG SANCOG-QingLong-L402-V1.0-DeskTop/SANCOG-
QingLong-L402-V1.0-DeskTop, BIOS Kunlun-L402-V4.1.4 05/25/2020
[0.00] Detected 4 available CPU(s)
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes.
[0.00] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64
bytes
[0.00] Unified victim cache 256kB 16-way, linesize 64 bytes.
[0.00] Unified secondary cache 8192kB 16-way, linesize 64 bytes.
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0020-0x]
[0.00]   Normal   [mem 0x0001-0x00027fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0020-0x0eff]
[0.00]   node   0: [mem 0x9020-0x]
[0.00]   node   0: [mem 0x00012000-0x00027fff]
[0.00] Initmem setup node 0 [mem 0x0020-0x00027fff]
[0.00] On node 0, zone DMA32: 128 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 1152 pages in unavailable ranges
[0.00] percpu: Embedded 13 pages/cpu s170416 r8192 d34384 u212992
[0.00] Fallback order for Node 0: 0
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 488325
[0.00] Policy zone: Normal
[0.00] Kernel command line:
root=UUID=acb13fb9-2b52-4308-b49a-aebfcf6bacbb ro nohz=off swiotlb=16384
console=tty0 console=ttyS0,115200n8 rd_start=0x8a49
rd_size=0x1327bde
[0.00] Dentry cache hash table entries: 1048576 (order: 9, 8388608
bytes, linear)
[0.00] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes,
linear)
[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off
[0.00] Memory: 2204720K/7843840K available (10712K kernel code, 1755K
rwdata, 2876K rodata, 2672K init, 16853K bss, 164832K reserved, 0K cma-
reserved)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 31083 entries in 31 pages
[0.00] ftrace: allocated 31 pages with 5 groups
[0.00] trace event string verifier disabled
[0.00] rcu: Preemptible hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4.
[0.00]  Trampoline variant of Tasks RCU enabled.
[0.00]  Rude variant of Tasks RCU enabled.
[0.00]  Tracing variant of Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 320
[0.00] ISA Bridge: /bus@1000/isa@1800
[0.00]  IO 0x1800..0x1801  ->
0x
[0.00] clocksource: MIPS: mask: 0x max_cycles: 0x,
max_idle_ns: 2123622718 ns
[

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/6/26 17:03, Thomas Schmitt wrote:

New version:
   
https://dev.lovelyhq.com/libburnia/libisoburn/commit/0e8227e76ae4c4f24097cfac2f415ef8e25ae4e7



Tested with:

1) Merge 17 DVDs, on Debian and Alpine Linux environment.

2) Merge 2 DLBDs, on Debian and Alpine Linux environment.

3) Run d-i cdrom-checker, on 4 merged ISOs from 1) and 2).

4) Test install into virtual machine, using 4 merged ISOs.

5) Install some random packages.

All OK! Thank you again :)

Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/6/26 03:30, Thomas Schmitt wrote:

Complexity-wise this replaces a slow O(n) algorithm by a faster O(n) and
an additional O(n * log(n)) run. At some size of Debian the slow speed
of the linear loop will be compensated by the sorting complexity.
But there is still room: A sort of 11,000 lines lasts about 0.03 seconds.



Theoretically if both file is already sorted, we can use the `-m' option 
(e.g. `sort -m -k 2 A.txt B.txt') to merge them in O(n) like mergesort. 
However I don't think O(n * log(n)) is a bottleneck so we may just keep 
it simple and stupid.



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

Some good news, I tested:

1) Build my unofficial DVD set (17 DVDs), and merge them using the merge 
script on my Debian machine.


2) Build my unofficial DLBD set (2 DLBDs), and merge them using the 
merge script on my Debian machine.


3) Merge 2 DLBDs using the merge script under a Alpine Linux environment 
(everything is almost busybox).


4) Run d-i cdrom-check on merged.iso from 1), 2), and 3).

5) Do fresh install into virtual machine, then install random packages 
selected from {SOME-ISO-NAME}.list.gz .


These experiments all succeeded. Thank you very much! Good Job! :)

On 2022/6/24 00:53, Thomas Schmitt wrote:

Run time for an All-in-one ISO is estimated about 6 to 7 times the time
of DVD-1+2+3.
So i expect ~230 seconds for full MD5 regeneration, ~ 50 seconds for
a loop that runs on dash, and ~6 seconds with a bashism.

For now i decided to take the 50 seconds with dash.


I think runtime is not a issue, 50 seconds is totally acceptable. But if 
you really want to reduce runtime I would suggest using `sort -s -u -k 2 
merged_md5sum.txt' instead of processing each line by hand. By using 
stable sort (`-s') and unique (`-u'), only first record of duplicate set 
will be output. So as long as md5sum.txt in Disc1 comes first, it will 
definitely in final result. I saw there are some other logic to process 
md5 records from different group of files, so we can use `grep' and 
`grep -v' to split them, process them separately, then merge them 
finally. Unfortunately the option `-s' of `sort' is not standard 
(although widely accepted), and BusyBox has bugs about it and must use 
`sort -s -k 2 | uniq -f 1' to workaround (Link: 
https://bugs.busybox.net/show_bug.cgi?id=14871).



Thank you again :)

Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi

On 2022/6/21 04:17, Thomas Schmitt wrote:

Hi,



Thanks for the detailed explanation! I think we can ignore minor 
differences, since creating a bit-for-bit reproducible image seems too 
hard for us.



md5sum.txt


Ouch. My script sorts the merged lines by the MD5 fields rather than by
the file paths.
Further this sorting is subject to locale settings, which is hardly
desirable, if the sequence of lines has a meaning at all.


I think maybe we should just create the md5sum from scratch? (or we can 
just reuse those md5sum of .deb only) Because some file definitely 
changed (like READMEs or files under /dists/...). A bad md5sum.txt will 
cause cdrom-checker in d-i to fail. (Fortunately it's not a standard 
step, but user can invoke it under `Advance options - Expert install')


Link: 
https://salsa.debian.org/installer-team/cdrom-checker/-/blob/master/main.c



Thank you again :)

Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/6/19 17:23, Thomas Schmitt wrote:

Hi,

i tested merging of /firmware directories with barely sufficently
complete
   debian-11.0.0-amd64-DLBD-[12].iso.tmp
from aborted jigdo-lite runs.

All files which are reported as being only in CUSTOM(all-in-one) by
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011343#115
are listed by xorriso as present in the emerging ISO, of which i
suppressed the actual production out of storage space reasons.

So if the next diff between self-made CUSTOM(all-in-one) and merged.iso
shows again missing files in /firmware, i have to ask for full listings
of the /firmware trees in DLBD-1, DLBD-2, CUSTOM(all-in-one), and
merged.iso .



I tested my self-baked ISOs again. To make things clear, I'd like 
explain my testing process in details.


1) Create a private mirror. (= a local latest debian mirror)
2) Create my own version of my-DLBD1.iso and my-DLBD2.iso from my 
private mirror.
3) Create my own version of my-CUSTOM.iso (all-in-one) from my private 
mirror, as ground-truth.

4) Merge my-DLBD1.iso and my-DLBD2.iso, as merged.iso, using merge script.
5) Compare merged.iso and my-CUSTOM.iso.

Note that I'm not using official-11.0.0-DLBD1.iso and 
official-11.0.0-DLBD2.iso to create merged.iso. The reason behind it is:


1) There is no official-11.0.0-CUSTOM.iso (all-in-one) as ground-truth 
for comparing if merge(official-11.0.0-DLBD1.iso, 
official-11.0.0-DLBD2.iso) == official-11.0.0-CUSTOM.iso
2) There will be a lot of differences when comparing 
merge(official-11.0.0-DLBD1.iso, official-11.0.0-DLBD2.iso) == 
my-CUSTOM.iso, because my-CUSTOM.iso is created from my private mirror, 
which contains updates from 11.0.0 to current time.
3) So, to minimize differences, I choose create DLBD1.iso and DLBD2.iso 
myself from my private mirror, then compare merge(my-DLBD1.iso, 
my-DLBD2.iso) == my-CUSTOM.iso


Unfortunately I don't know how the official DLBDs are created, so I try 
my best to change CONF.sh in `debian-cd' package, in order to minimize 
the structure differences between my-DLBD1.iso and official-DLBD1.iso.


Then, back to the test results. This time the difference in /firmware is:

Only in /groundtruth/firmware: 
arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb


I don't think this is the merge script's fault. This .deb is not exist 
in both my-DLBD1.iso and my-DLBD2.iso. I think the reason might be 
misconfiguration in my CONF.sh or some bug in `debian-cd'.


# diff <((ls /dlbd1/firmware/; ls /dlbd2/firmware/)|sort|uniq) <(ls 
/groundtruth/firmware|sort)

1a2
> arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb

There are other differences in filesystem-tree. Some of them seems 
harmless, e.g. Disc-title differs. If you are interested in them, please 
refer to the attachments. MD5 are stripped as usual due to size reasons.



Best Regards,
Zhang BoyangFiles /mnt/.disk/cd_type and /groundtruth/.disk/cd_type differ
Files /mnt/.disk/info and /groundtruth/.disk/info differ
Files /mnt/.disk/mkisofs and /groundtruth/.disk/mkisofs differ
Files /mnt/README.html and /groundtruth/README.html differ
Files /mnt/README.txt and /groundtruth/README.txt differ
Files /mnt/boot/grub/efi.img and /groundtruth/boot/grub/efi.img differ
diff: /mnt/debian: recursive directory loop
Files /mnt/dists/bullseye/Release and /groundtruth/dists/bullseye/Release differ
Files /mnt/dists/bullseye/contrib/binary-amd64/Packages.gz and 
/groundtruth/dists/bullseye/contrib/binary-amd64/Packages.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-cs.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-cs.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-da.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-da.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-de.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-de.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-en.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-en.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-es.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-es.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-fr.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-fr.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-it.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-it.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-ja.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-ja.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-pl.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-pl.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-pt.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-pt.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-pt_BR.gz and 
/groundtruth/dists/bullseye/contrib/i18n/Translation-pt_BR.gz differ
Files /mnt/dists/bullseye/contrib/i18n/Translation-ru.gz and 
/groundtruth/dists/bullseye/con

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hello,

Thanks for making this program! I will definitely try it as soon as I 
finished my current work!


Thank you again :)

Best Regards,
Zhang Boyang

On 2022/6/15 19:17, Thomas Schmitt wrote:

Hi,

although it was not the final solution of this bug report, i beefed up
my merger script for Debian ISOs so that it can combine an arbitrary
number of ISOs (within the limits of /dev/loop* and mount(8)).
Maybe it can serve as answer for the next time this wish comes up.

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hello,

Here is a patch for another bug. Please refer to the commit message for 
details.


Sorry to disturb you again. 

Best Regards,
Zhang BoyangFrom d569b4fbc4233673032a1c5f7463890d5e2223dd Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Fri, 10 Jun 2022 15:16:33 +0800
Subject: [PATCH v6] Fix crash caused by invalid term->yorig

The SCR(x, y) may return negative value if term->yorig is negative or
too large, causing memory corruption and crash. There are two ways to
trigger this bug.

1) When scrolling up, term->yorig is decremented by one. If term->yorig
   is zero, it can be -1 after the decrement, so SCR(0, 0) will become
   negative, causing crash. Below is the test command:

   bterm -f myfont.bgf -- python3 -c 'print("hello\033Mworld"); input("OK!")'

2) When scrolling down, term->yorig is incremented by one. There is no
   check for integer overflow. When term->yorig is large enough, the
   calculation in SCR(x, y) will overflow and it will return negative
   value, causing crash. Below is the test command:

   bterm -f myfont.bgf -- python3 -c 'print("\n"*22); input("OK!")'

This patch fixes the problem by limiting term->yorig to [0, term->ysize)
so there will be no negative value or overflow anymore.
---
 bogl-term.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bogl-term.c b/bogl-term.c
index 2d35d1d..f7fd735 100644
--- a/bogl-term.c
+++ b/bogl-term.c
@@ -188,7 +188,7 @@ cursor_down (struct bogl_term *term)
 }
 
 dirty_scroll(term);
-++term->yorig;
+term->yorig = (term->yorig + 1) % term->ysize;
 
 for (i = 0; i < term->xsize; i++)
 {
@@ -464,7 +464,7 @@ bogl_term_out (struct bogl_term *term, char *s, int n)
 
 /* Move all other lines down.  Fortunately, this is easy.  */
 dirty_backscroll(term);
-term->yorig--;
+term->yorig = (term->yorig - 1 + term->ysize) % term->ysize;
 
 /* Clear the top line.  */
 for (i = SCR (0, 0); i < SCR (term->xsize, 0); i++)
-- 
2.30.2

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

Changes in [PATCH v5]:

Fix-incorrect-signal-handling.patch:
  Fix compiler warnings about implicit declaration of bogl_signal().

Font-scaler.patch
  Use a lookup table to speed up font scaling.

===

I'm sorry for sending a lot of emails to you, but I think this email is 
probably the last one of this email series. :-)


Best Regards,
Zhang BoyangFrom 7d399b7223bc194c0b61aab8c6bd252fd0d43ded Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Tue, 24 May 2022 12:58:01 +0800
Subject: [PATCH v5 2/4] Fix incorrect signal handling

There are problems in signal handlers. Signal handlers must not call any
non-async-signal-safe functions, and they must save-restore errno if
errno is modified inside signal handlers. This patch fixes these
problems by deferring real tasks to main loop. This patch also
introduces bogl_signal(), which wraps around sigaction() thus signal
handlers can be installed in a portable way. Since signal related
problems are fixed, the previously temporarily disabled font unmapping
is now re-enabled.
---
 bogl.c  | 50 +-
 bogl.h  |  2 ++
 boglP.h |  2 ++
 bterm.c | 36 ++--
 4 files changed, 55 insertions(+), 35 deletions(-)

diff --git a/bogl.c b/bogl.c
index 6b9996b..86bc1e0 100644
--- a/bogl.c
+++ b/bogl.c
@@ -65,6 +65,7 @@
 /* Global variables. */
 int bogl_xres, bogl_yres, bogl_bpp;	/* bogl.h */
 int bogl_refresh;
+volatile int vt_switch_pending = 0;
 volatile char *bogl_frame;		/* boglP.h */
 int bogl_drawing;
 int bogl_line_len;
@@ -120,7 +121,7 @@ static void draw_disable (void);
 static void kbd_init (void);
 static void kbd_done (void);
 
-static void vt_switch (int);
+static void sigusr2 (int);
 
 static struct fb_fix_screeninfo fb_fix;
 /* Initialize BOGL. */
@@ -181,7 +182,7 @@ bogl_init (void)
   mode.relsig = SIGUSR2;
   mode.acqsig = SIGUSR2;
 
-  signal (SIGUSR2, vt_switch);
+  bogl_signal (SIGUSR2, sigusr2);
 
   if (-1 == ioctl (tty, VT_SETMODE, ))
 return bogl_fail ("can't set VT mode: %s", strerror (errno));
@@ -295,7 +296,7 @@ bogl_done (void)
 
   munmap ((void *) bogl_frame, fb_fix.smem_len);
   
-  signal (SIGUSR2, SIG_DFL);
+  bogl_signal (SIGUSR2, SIG_DFL);
 
   ioctl (tty, KDSETMODE, KD_TEXT);
 
@@ -583,32 +584,18 @@ draw_disable (void)
 /* Signal handler called whenever the kernel wants to switch to or
from our tty. */
 static void
-vt_switch (int sig unused)
+sigusr2 (int sig unused)
 {
-  signal (SIGUSR2, vt_switch);
+  vt_switch_pending = 1;
+}
+void
+vt_switch (void)
+{
+  vt_switch_pending = 0;
 
-  /* If a BOGL drawing function is in progress then we cannot mode
- switch right now because the drawing function would continue to
- scribble on the screen after the switch.  So disable further
- drawing and schedule an alarm to try again in .1 second. */
   if (bogl_drawing)
 {
-  draw_disable ();
-
-  signal (SIGALRM, vt_switch);
-  
-  {
-	struct itimerval duration;
-	
-	duration.it_interval.tv_sec = 0;
-	duration.it_interval.tv_usec = 0;
-	duration.it_value.tv_sec = 0;
-	duration.it_value.tv_usec = 10;
-	if (-1 == setitimer (ITIMER_REAL, , NULL))
-	  bogl_fail ("can't set timer: %s", strerror (errno));
-  }
-  
-  return;
+  abort();
 }
   
   if (visible)
@@ -666,3 +653,16 @@ bogl_cloexec(int fd)
 
   return 0;
 }
+
+/* Install signal handler in a portable way (i.e. sigaction wrapper) */
+int
+bogl_signal(int signum, void (*handler) (int))
+{
+  struct sigaction sa;
+
+  sa.sa_handler = handler;
+  sigemptyset (_mask);
+  sa.sa_flags = SA_RESTART;
+
+  return sigaction (signum, , NULL);
+}
diff --git a/bogl.h b/bogl.h
index 3b2cb83..4d99788 100644
--- a/bogl.h
+++ b/bogl.h
@@ -69,6 +69,8 @@ extern int bogl_xres, bogl_yres, bogl_ncols;
 
 /* 1=Must refresh screen due to tty change. */
 extern int bogl_refresh;
+extern volatile int vt_switch_pending;
+extern void vt_switch (void);
 
 /* Generic routines. */
 int bogl_init (void);
diff --git a/boglP.h b/boglP.h
index be99979..9a2b4aa 100644
--- a/boglP.h
+++ b/boglP.h
@@ -27,4 +27,6 @@ int bogl_fail (const char *, ...);
 
 int bogl_cloexec (int fd);
 
+int bogl_signal (int signum, void (*handler) (int));
+
 #endif /* boglP_h */
diff --git a/bterm.c b/bterm.c
index dfae8b9..e86a748 100644
--- a/bterm.c
+++ b/bterm.c
@@ -39,6 +39,7 @@
 #include 
 
 #include "bogl.h"
+#include "boglP.h"
 #include "bogl-bgf.h"
 #include "bogl-term.h"
 
@@ -160,7 +161,6 @@ void sigchld(int sig)
   quit_status = status;
 quit = 1;
   }
-  signal(SIGCHLD, sigchld);
   errno = errsv;
 }
 
@@ -176,7 +176,7 @@ void spawn_shell(int ptyfd, int ttyfd, char * const *command_args)
   child_pid = fork();
   if (child_pid) {
 /* Change ownership and permissions of ttyfd device! */
-signal(SIGCHLD, sigchld);
+bogl_signal(SIGCHLD, sigchld);
 return;
   }
 
@@ -212,10 +212,16 @@ void set_window_size(int tt

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

Changes in [PATCH V3]:

Please refer to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011609#30

Changes in [PATCH V4]:

Tiny improvement: detect 8K+ monitors and assign 8x scale factor for them.


Best Regards,
Zhang BoyangFrom 540b82ac07c5a582da3d6e6ad1cdc2fd83c36b2e Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Mon, 23 May 2022 14:10:52 +0800
Subject: [PATCH v4 1/4] Better font reload handling

Previous font reload code will leak a mmap on each reload. This patch
adds the ability to munmap old font after reload. However, this also
introduces a bug, if font reload is triggered while drawing in progress,
after signal handler returns, the drawing code will continue to use old
font which has been freed, causing crash. So the munmap is temporarily
disabled until we fix async-signal-safety problems completely.
---
 bogl-bgf.c | 63 +++---
 bogl-bgf.h |  1 +
 bterm.c|  9 
 3 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/bogl-bgf.c b/bogl-bgf.c
index 1032028..beed3c8 100644
--- a/bogl-bgf.c
+++ b/bogl-bgf.c
@@ -5,38 +5,55 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bogl.h"
 #include "boglP.h"
 #include "bogl-font.h"
+#include "bogl-bgf.h"
+
+struct bogl_bgf {
+  void *f;/* mmap area */
+  off_t size; /* size of mmap area */
+  struct bogl_font font; /* font descriptor */
+};
+#define bgf_of(font) \
+  ((struct bogl_bgf *)((char *)(font) - offsetof(struct bogl_bgf, font)))
 
 struct bogl_font *bogl_mmap_font(char *file)
 {
-  int fd;
+  struct bogl_bgf *bgf = NULL;
+  struct bogl_font *font = NULL;
+  int fd = -1;
   struct stat buf;
-  void *f;
-  struct bogl_font *font;
+  void *f = MAP_FAILED;
+
+  bgf = (struct bogl_bgf *)malloc(sizeof(struct bogl_bgf));
+  if (!bgf)
+goto fail;
+  font = >font;
 
   fd = open(file, O_RDONLY);
   if (fd == -1)
-return 0;
+goto fail;
 
   if (bogl_cloexec(fd) < 0)
-return 0;
+goto fail;
 
   if (fstat(fd, ))
-return 0;
+goto fail;
+  bgf->size = buf.st_size;
+
+  if (buf.st_size < 4)
+goto fail;
 
   f = mmap(0, buf.st_size, PROT_READ, MAP_SHARED, fd, 0);
-  if (f == (void *)-1)
-return 0;
+  if (f == MAP_FAILED)
+goto fail;
+  bgf->f = f;
 
   if (memcmp("BGF1", f, 4))
-return 0;
-
-  font = (struct bogl_font *)malloc(sizeof(struct bogl_font));
-  if (!font)
-return 0;
+goto fail;
 
   memcpy(font, f + 4, sizeof(*font));
   font->name = ((void *)font->name - (void *)0) + f;
@@ -44,5 +61,25 @@ struct bogl_font *bogl_mmap_font(char *file)
   font->index = ((void *)font->index - (void *)0) + f;
   font->content = ((void *)font->content - (void *)0) + f;
 
+done:
+  if (fd != -1)
+close(fd);
   return font;
+
+fail:
+  if (bgf) {
+free(bgf);
+bgf = NULL;
+font = NULL;
+  }
+  if (f != MAP_FAILED)
+munmap(f, buf.st_size);
+  goto done;
+}
+
+void bogl_munmap_font(struct bogl_font *font)
+{
+  struct bogl_bgf *bgf = bgf_of(font);
+  munmap(bgf->f, bgf->size);
+  free(bgf);
 }
diff --git a/bogl-bgf.h b/bogl-bgf.h
index e9fb994..f14a260 100644
--- a/bogl-bgf.h
+++ b/bogl-bgf.h
@@ -1,2 +1,3 @@
 
 struct bogl_font *bogl_mmap_font(char *file);
+void bogl_munmap_font(struct bogl_font *font);
diff --git a/bterm.c b/bterm.c
index 605644f..dfae8b9 100644
--- a/bterm.c
+++ b/bterm.c
@@ -224,11 +224,10 @@ void reload_font(int sig)
   return;
 }
   
-  /* This leaks a mmap.  Since the font reloading feature is only expected
- to be used once per session (for instance, in debian-installer, after
- the font is replaced with a larger version containing more characters),
- we don't worry about the leak.  */
-  free(term->font);
+  /* BUG: Unmapping old font in this signal handler may cause crash if
+ drawing is in progress, so disable this temporarily until we fix
+ async-signal-safety problems completely. */
+  //bogl_munmap_font(term->font);
 
   term->font = font;
   term->xstep = bogl_font_glyph(term->font, ' ', 0);
-- 
2.30.2

From b222a9a15b0a2706927ecde8ce163243b076bbcb Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Tue, 24 May 2022 12:58:01 +0800
Subject: [PATCH v4 2/4] Fix incorrect signal handling

There are problems in signal handlers. Signal handlers must not call any
non-async-signal-safe functions, and they must save-restore errno if
errno is modified inside signal handlers. This patch fixes these
problems by deferring real tasks to main loop. This patch also
introduces bogl_signal(), which wraps around sigaction() thus signal
handlers can be installed in a portable way. Since signal related
problems are fixed, the previously temporarily disabled font unmapping
is now re-enabled.
---
 bogl.c  | 50 +-
 bogl.h  |  2 ++
 boglP.h |  2 ++
 bterm.c | 35 +--
 4 files changed, 54 insertions(+

Bug#1012256: unifont: Japanese variant not installed

[Zhang Boyang]

Package: unifont

Hi,

Unifont provide Japanese variant of the font but I found unifont_jp.xxx 
is not installed on my debian system. After some digging, I found the 
root cause is the Makefile just didn't install them although they were 
built. I created a patch that would fix this problem. I sent this patch 
to upstream (unifoundry at unifoundry.com) but I haven't received any 
reply from upstream. I found the upstream was once maintained this 
package, so I think it might be useful to send my patch here.



Best Regards,
Zhang BoyangFrom d56098fc38aadb25d6b8fc394fdfacf943fa0785 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Sun, 22 May 2022 19:07:10 +0800
Subject: [PATCH] Modify Makefile to install Japanese variants

---
 Makefile  | 5 +
 font/Makefile | 5 +
 2 files changed, 10 insertions(+)

diff --git a/Makefile b/Makefile
index 0886cfd..e3cd96c 100644
--- a/Makefile
+++ b/Makefile
@@ -131,11 +131,16 @@ install: bindir libdir docdir
 	if [ ! -d font/compiled ] ; then \
 	   install -m0644 -p font/precompiled/unifont-$(VERSION).hex   $(PKGDEST)/unifont.hex && \
 	   install -m0644 -p font/precompiled/unifont-$(VERSION).bmp $(PKGDEST)/unifont.bmp ; \
+	   install -m0644 -p font/precompiled/unifont_jp-$(VERSION).hex   $(PKGDEST)/unifont_jp.hex && \
+	   install -m0644 -p font/precompiled/unifont_jp-$(VERSION).bmp $(PKGDEST)/unifont_jp.bmp ; \
 	else \
 	   install -m0644 -p font/compiled/unifont-$(VERSION).hex   $(PKGDEST)/unifont.hex && \
 	   install -m0644 -p font/compiled/unifont-$(VERSION).bmp $(PKGDEST)/unifont.bmp ; \
+	   install -m0644 -p font/compiled/unifont_jp-$(VERSION).hex   $(PKGDEST)/unifont_jp.hex && \
+	   install -m0644 -p font/compiled/unifont_jp-$(VERSION).bmp $(PKGDEST)/unifont_jp.bmp ; \
 	fi
 	gzip $(GZFLAGS) $(PKGDEST)/unifont.bmp
+	gzip $(GZFLAGS) $(PKGDEST)/unifont_jp.bmp
 
 clean:
 	$(MAKE) -C src  clean
diff --git a/font/Makefile b/font/Makefile
index aa760d5..c2d681c 100644
--- a/font/Makefile
+++ b/font/Makefile
@@ -648,6 +648,7 @@ precompiled: all
 	  $(COMPILED_DIR)/unifont_csur-$(VERSION).pcf.gz \
 	  $(COMPILED_DIR)/unifont_csur-$(VERSION).ttf \
 	  $(COMPILED_DIR)/unifont_jp-$(VERSION).bdf.gz \
+	  $(COMPILED_DIR)/unifont_jp-$(VERSION).pcf.gz \
 	  $(COMPILED_DIR)/unifont_jp-$(VERSION).ttf \
 	  $(COMPILED_DIR)/unifont_sample-$(VERSION).hex \
 	  $(COMPILED_DIR)/unifont_sample-$(VERSION).bdf.gz \
@@ -693,18 +694,22 @@ install:
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/Unifont-APL8x16-$(VERSION).psf.gz $(CONSOLEDEST)/Unifont-APL8x16.psf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont-$(VERSION).pcf.gz $(PCFDEST)/unifont.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_sample-$(VERSION).pcf.gz  $(PCFDEST)/unifont_sample.pcf.gz ; \
+	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_jp-$(VERSION).pcf.gz  $(PCFDEST)/unifont_jp.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_csur-$(VERSION).pcf.gz$(PCFDEST)/unifont_csur.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont-$(VERSION).ttf$(TTFDEST)/unifont.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_sample-$(VERSION).ttf $(TTFDEST)/unifont_sample.ttf ; \
+	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_jp-$(VERSION).ttf $(TTFDEST)/unifont_jp.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_csur-$(VERSION).ttf   $(TTFDEST)/unifont_csur.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/precompiled/unifont_upper-$(VERSION).ttf  $(TTFDEST)/unifont_upper.ttf ; \
 	else \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/Unifont-APL8x16-$(VERSION).psf.gz $(CONSOLEDEST)/Unifont-APL8x16.psf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont-$(VERSION).pcf.gz $(PCFDEST)/unifont.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_sample-$(VERSION).pcf.gz  $(PCFDEST)/unifont_sample.pcf.gz ; \
+	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_jp-$(VERSION).pcf.gz  $(PCFDEST)/unifont_jp.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_csur-$(VERSION).pcf.gz$(PCFDEST)/unifont_csur.pcf.gz ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont-$(VERSION).ttf$(TTFDEST)/unifont.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_sample-$(VERSION).ttf $(TTFDEST)/unifont_sample.ttf ; \
+	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_jp-$(VERSION).ttf $(TTFDEST)/unifont_jp.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_csur-$(VERSION).ttf   $(TTFDEST)/unifont_csur.ttf ; \
 	   $(INSTALL) -m0644 -p $(CURDIR)/$(COMPILED_DIR)/unifont_upper-$(VERSION).ttf  $(TTFDEST)/unifont_upper.ttf ; \
 	fi
-- 
2.30.2

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

I forgot to attach the patches in the last mail. Here are the updated 
patches.


Best Regards,
Zhang BoyangFrom 540b82ac07c5a582da3d6e6ad1cdc2fd83c36b2e Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Mon, 23 May 2022 14:10:52 +0800
Subject: [PATCH v3 1/4] Better font reload handling

Previous font reload code will leak a mmap on each reload. This patch
adds the ability to munmap old font after reload. However, this also
introduces a bug, if font reload is triggered while drawing in progress,
after signal handler returns, the drawing code will continue to use old
font which has been freed, causing crash. So the munmap is temporarily
disabled until we fix async-signal-safety problems completely.
---
 bogl-bgf.c | 63 +++---
 bogl-bgf.h |  1 +
 bterm.c|  9 
 3 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/bogl-bgf.c b/bogl-bgf.c
index 1032028..beed3c8 100644
--- a/bogl-bgf.c
+++ b/bogl-bgf.c
@@ -5,38 +5,55 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bogl.h"
 #include "boglP.h"
 #include "bogl-font.h"
+#include "bogl-bgf.h"
+
+struct bogl_bgf {
+  void *f;/* mmap area */
+  off_t size; /* size of mmap area */
+  struct bogl_font font; /* font descriptor */
+};
+#define bgf_of(font) \
+  ((struct bogl_bgf *)((char *)(font) - offsetof(struct bogl_bgf, font)))
 
 struct bogl_font *bogl_mmap_font(char *file)
 {
-  int fd;
+  struct bogl_bgf *bgf = NULL;
+  struct bogl_font *font = NULL;
+  int fd = -1;
   struct stat buf;
-  void *f;
-  struct bogl_font *font;
+  void *f = MAP_FAILED;
+
+  bgf = (struct bogl_bgf *)malloc(sizeof(struct bogl_bgf));
+  if (!bgf)
+goto fail;
+  font = >font;
 
   fd = open(file, O_RDONLY);
   if (fd == -1)
-return 0;
+goto fail;
 
   if (bogl_cloexec(fd) < 0)
-return 0;
+goto fail;
 
   if (fstat(fd, ))
-return 0;
+goto fail;
+  bgf->size = buf.st_size;
+
+  if (buf.st_size < 4)
+goto fail;
 
   f = mmap(0, buf.st_size, PROT_READ, MAP_SHARED, fd, 0);
-  if (f == (void *)-1)
-return 0;
+  if (f == MAP_FAILED)
+goto fail;
+  bgf->f = f;
 
   if (memcmp("BGF1", f, 4))
-return 0;
-
-  font = (struct bogl_font *)malloc(sizeof(struct bogl_font));
-  if (!font)
-return 0;
+goto fail;
 
   memcpy(font, f + 4, sizeof(*font));
   font->name = ((void *)font->name - (void *)0) + f;
@@ -44,5 +61,25 @@ struct bogl_font *bogl_mmap_font(char *file)
   font->index = ((void *)font->index - (void *)0) + f;
   font->content = ((void *)font->content - (void *)0) + f;
 
+done:
+  if (fd != -1)
+close(fd);
   return font;
+
+fail:
+  if (bgf) {
+free(bgf);
+bgf = NULL;
+font = NULL;
+  }
+  if (f != MAP_FAILED)
+munmap(f, buf.st_size);
+  goto done;
+}
+
+void bogl_munmap_font(struct bogl_font *font)
+{
+  struct bogl_bgf *bgf = bgf_of(font);
+  munmap(bgf->f, bgf->size);
+  free(bgf);
 }
diff --git a/bogl-bgf.h b/bogl-bgf.h
index e9fb994..f14a260 100644
--- a/bogl-bgf.h
+++ b/bogl-bgf.h
@@ -1,2 +1,3 @@
 
 struct bogl_font *bogl_mmap_font(char *file);
+void bogl_munmap_font(struct bogl_font *font);
diff --git a/bterm.c b/bterm.c
index 605644f..dfae8b9 100644
--- a/bterm.c
+++ b/bterm.c
@@ -224,11 +224,10 @@ void reload_font(int sig)
   return;
 }
   
-  /* This leaks a mmap.  Since the font reloading feature is only expected
- to be used once per session (for instance, in debian-installer, after
- the font is replaced with a larger version containing more characters),
- we don't worry about the leak.  */
-  free(term->font);
+  /* BUG: Unmapping old font in this signal handler may cause crash if
+ drawing is in progress, so disable this temporarily until we fix
+ async-signal-safety problems completely. */
+  //bogl_munmap_font(term->font);
 
   term->font = font;
   term->xstep = bogl_font_glyph(term->font, ' ', 0);
-- 
2.30.2

From b222a9a15b0a2706927ecde8ce163243b076bbcb Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Tue, 24 May 2022 12:58:01 +0800
Subject: [PATCH v3 2/4] Fix incorrect signal handling

There are problems in signal handlers. Signal handlers must not call any
non-async-signal-safe functions, and they must save-restore errno if
errno is modified inside signal handlers. This patch fixes these
problems by deferring real tasks to main loop. This patch also
introduces bogl_signal(), which wraps around sigaction() thus signal
handlers can be installed in a portable way. Since signal related
problems are fixed, the previously temporarily disabled font unmapping
is now re-enabled.
---
 bogl.c  | 50 +-
 bogl.h  |  2 ++
 boglP.h |  2 ++
 bterm.c | 35 +--
 4 files changed, 54 insertions(+), 35 deletions(-)

diff --git a/bogl.c b/bogl.c
index 6b9996b..86bc1e0 100644
--- a/bogl.c
+++ b/bogl.c
@@ -65,6 +65,7 @@
 /*

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

Thanks for reviewing. I did some changes on my patch. I also closed the 
PR on salsa because we are using debian bug tracker instead of gitlab 
pull requests.



On 2022/5/30 03:49, Samuel Thibault wrote:


Then is it not possible to exchange the patch order? So that whatever
the number of patches being applied, things work completely.


The two patch is tightly related. I guess why the original code leak a 
font mmap intentionally is just to avoid the 
font-unmap-during-drawing-will-cause-crash problem. The 
async-signal-safefy patch will defer font reloading to main loop to 
avoid this problem (and fix other problems like calling malloc() in 
signal handlers which is very dangerous).


I updated my patch. The first patch (Better font reload handling) will 
comment out the call to bogl_munmap_font(), avoiding crash but still 
have a leak, just like the original code. So if someone only applies the 
first patch, it will work as before (not crash but still leak memory). 
The second patch (Fix incorrect signal handling) will re-enable the call 
previously commented out in first patch. So if someone want to apply the 
second patch, he/she must apply the first patch first, make dependency 
more clear. So, things are always working if (a) only first patch is 
applied, or (b) both first and second patch are applied, or (c) non of 
these two patch are applied, and (d) it is not possible to only apply 
second patch because the patch command will complain about conflicts.




While at it, please use MAP_FAILED rather than the hardcoded (void*)-1


Fixed. :-)



This looks unrelated and bogus?


This is because I want to maintain a constant look of signal handlers. 
The reason behind it is there is no need to call signal() to install 
handler again because glibc's signal() now provide BSD semantics per man 
page of signal(). I updated my patch and use a sigaction wrapper to 
address this explicitly, and this will make the code more portable.




Do you have a reference that documents this?


Unfortunately there is no document about this, mainly because this is a 
workaround for buggy drivers. I updated comments in code to address this 
more explicitly.




MAP_FAILED here as well.


Fixed. :-)



Please make these an inline function rather than copy/pasting them from
bogl_mmap_font.


Fixed. :-)



Best Regards,
Zhang Boyang

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

This is the v2 patch series. There are some reordering, squashing, and 
minor changes compared to previously proposed patch series.


An all-in-one patch for quilt is also attached, which can be directly 
applied to the git repo. (Same as the merge request it self)From c8de527c0c0ff5b8e2a3c10c1d26e5674ffccf50 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Tue, 24 May 2022 01:27:10 +0800
Subject: [PATCH v2 1/8] Better quit handling

Previous SIGCHLD handler is not async-signal-safe because it calls
exit(), and it also doesn't save-restore errno. Using _exit() will be
async-signal-safe safe but will result in unclean quit. In the end, this
patch will set a flag variable in signal handler, then defer real
cleanup and quitting to main loop.
---
 bterm.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/bterm.c b/bterm.c
index d7b574f..605644f 100644
--- a/bterm.c
+++ b/bterm.c
@@ -64,7 +64,7 @@ static const unsigned char palette[16][3] =
 
 static int child_pid = 0;
 static struct termios ttysave;
-static int quit = 0;
+static volatile int quit = 0, quit_status = 0;
 
 /* Out of memory.  Give up. */
 static void out_of_memory (void)
@@ -144,24 +144,29 @@ void send_hangup(void)
 
 void sigchld(int sig)
 {
+  int errsv = errno;
   int status;
   if (waitpid(child_pid, , WNOHANG) > 0) {
 child_pid = 0;
 /* Reset ownership and permissions of ttyfd device? */
 tcsetattr(0, TCSAFLUSH, );
 if (WIFEXITED (status))
-  exit(WEXITSTATUS (status));
-if (WIFSIGNALED (status))
-  exit(128 + WTERMSIG (status));
-if (WIFSTOPPED (status))
-  exit(128 + WSTOPSIG (status));
-exit(status);
+  quit_status = WEXITSTATUS (status);
+else if (WIFSIGNALED (status))
+  quit_status = 128 + WTERMSIG (status);
+else if (WIFSTOPPED (status))
+  quit_status = 128 + WSTOPSIG (status);
+else
+  quit_status = status;
+quit = 1;
   }
   signal(SIGCHLD, sigchld);
+  errno = errsv;
 }
 
 void sigterm(int sig)
 {
+	quit_status = 128 + SIGTERM;
 	quit = 1;
 }
 
@@ -420,5 +425,5 @@ int main(int argc, char *argv[])
 }
   }
 
-  return 0;
+  exit(quit_status);
 }
-- 
2.30.2

From 302952c64952197d694039358df407ec3ffa418a Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Mon, 23 May 2022 14:10:52 +0800
Subject: [PATCH v2 2/8] Better font reload handling

Previous font reload code will leak a mmap on each reload. This patch
adds the ability to munmap old font after reload. However, this also
introduces a bug, if font reload is triggered while drawing in progress,
after signal handler returns, the drawing code will continue to use old
font which has been freed, causing crash. This will be fixed in next
patch.
---
 bogl-bgf.c | 61 +++---
 bogl-bgf.h |  1 +
 bterm.c|  6 +-
 3 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/bogl-bgf.c b/bogl-bgf.c
index 1032028..0383f4f 100644
--- a/bogl-bgf.c
+++ b/bogl-bgf.c
@@ -5,38 +5,55 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bogl.h"
 #include "boglP.h"
 #include "bogl-font.h"
+#include "bogl-bgf.h"
+
+struct bogl_bgf {
+  void *f;/* mmap area */
+  off_t size; /* size of mmap area */
+  struct bogl_font font; /* font descriptor */
+};
+#define bgf_of(font) \
+  ((struct bogl_bgf *)((char *)(font) - offsetof(struct bogl_bgf, font)))
 
 struct bogl_font *bogl_mmap_font(char *file)
 {
-  int fd;
+  struct bogl_bgf *bgf = NULL;
+  struct bogl_font *font = NULL;
+  int fd = -1;
   struct stat buf;
-  void *f;
-  struct bogl_font *font;
+  void *f = (void *)-1;
+
+  bgf = (struct bogl_bgf *)malloc(sizeof(struct bogl_bgf));
+  if (!bgf)
+goto fail;
+  font = >font;
 
   fd = open(file, O_RDONLY);
   if (fd == -1)
-return 0;
+goto fail;
 
   if (bogl_cloexec(fd) < 0)
-return 0;
+goto fail;
 
   if (fstat(fd, ))
-return 0;
+goto fail;
+  bgf->size = buf.st_size;
+
+  if (buf.st_size < 4)
+goto fail;
 
   f = mmap(0, buf.st_size, PROT_READ, MAP_SHARED, fd, 0);
   if (f == (void *)-1)
-return 0;
+goto fail;
+  bgf->f = f;
 
   if (memcmp("BGF1", f, 4))
-return 0;
-
-  font = (struct bogl_font *)malloc(sizeof(struct bogl_font));
-  if (!font)
-return 0;
+goto fail;
 
   memcpy(font, f + 4, sizeof(*font));
   font->name = ((void *)font->name - (void *)0) + f;
@@ -44,5 +61,25 @@ struct bogl_font *bogl_mmap_font(char *file)
   font->index = ((void *)font->index - (void *)0) + f;
   font->content = ((void *)font->content - (void *)0) + f;
 
+done:
+  if (fd != -1)
+close(fd);
   return font;
+
+fail:
+  if (bgf) {
+free(bgf);
+bgf = NULL;
+font = NULL;
+  }
+  if (f != (void *)-1)
+munmap(f, buf.st_size);
+  goto done;
+}
+
+void bogl_munmap_font(struct bogl_font *font)
+{
+  struct bogl_bgf *bgf = bgf_of(font);
+  munmap(bgf->f, bgf->size);
+  free(bgf);
 }
di

Bug#1012035: reprotest: Salsa CI randomly fails because dpkg-source can't change timestamp

[Zhang Boyang]

Package: reprotest

Hello,

I found Salsa CI reprotest on my repo fails when "FAKETIME variation: 
faketime = [balabala]" is decided. The relevant output is:


dpkg-source: error: cannot change timestamp for 
build-experiment-1/.pc/applied-patches: Invalid argument


Full log is here:
https://salsa.debian.org/zhangboyang/bogl/-/jobs/2825734

When "FAKETIME variation: enabled but chosen randomly not to fake!" is 
decided, job finished successfully. For example:

https://salsa.debian.org/debian/bogl/-/jobs/2815352

I'm not sure if this is a problem in reprotest or somewhere else. Please 
point me out if I'm wrong.



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

ools_2.4+dfsg-2_amd64.deb

Only in /groundtruth/firmware: firm-phoenix-ware_4.7.5+repack-1_all.deb
Only in /groundtruth/firmware: 
firmware-microbit-micropython-dl_1.2.4+dfsg-8_all.deb
Only in /groundtruth/firmware: 
firmware-microbit-micropython-doc_1.0.1-2_all.deb

Only in /groundtruth/firmware: firmware-microbit-micropython_1.0.1-2_all.deb
Only in /groundtruth/firmware: firmware-tomu_2.0~rc7-2_all.deb
Only in /groundtruth/firmware: gnome-firmware_3.36.0-1_amd64.deb
Files /mnt/isolinux/boot.cat and /groundtruth/isolinux/boot.cat differ
Files /mnt/isolinux/f1.txt and /groundtruth/isolinux/f1.txt differ
Files /mnt/isolinux/isolinux.bin and /groundtruth/isolinux/isolinux.bin 
differ

Files /mnt/md5sum.txt and /groundtruth/md5sum.txt differ

Most differs come from READMEs, and dist/ directory. ( I haven't tried 
advance features of merger script yet, I will try it later)


The further details is in the attached file. I will try to analysis it.
(For size reasons, lines with md5 in it is filtered out by "sed -i -E -e 
'/[a-f0-9]{32,32}/d' diff.details.txt")


Best Regards,
Zhang Boyangdiff -r /mnt/.disk/cd_type /groundtruth/.disk/cd_type
1c1
< bluray
---
> full_cd
diff -r /mnt/.disk/info /groundtruth/.disk/info
1c1
< Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 DLBD Binary-1 
20220528-13:35
\ No newline at end of file
---
> Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 CUSTOM Binary-1 
> 20220528-14:56
\ No newline at end of file
diff -r /mnt/.disk/mkisofs /groundtruth/.disk/mkisofs
1c1
< xorriso -as mkisofs -r -checksum_algorithm_iso sha256,sha512 -V 'Debian 
11.0.0 amd64 1' -o /srv/mirror/debian-cd-test/debian-11.0.0-amd64-DLBD-1.iso 
-checksum-list /srv/mirror/tmp/bullseye/checksum-check 
-jigdo-checksum-algorithm md5 -jigdo-force-checksum /pool/ -jigdo-min-file-size 
1024 -jigdo-exclude 'README*' -jigdo-exclude /doc/ -jigdo-exclude /md5sum.txt 
-jigdo-exclude /.disk/ -jigdo-exclude /pics/ -jigdo-exclude 'Release*' 
-jigdo-exclude 'Packages*' -jigdo-exclude 'Sources*' -jigdo-force-md5 /pool/ 
-jigdo-jigdo /srv/mirror/debian-cd-test/debian-11.0.0-amd64-DLBD-1.jigdo 
-jigdo-template /srv/mirror/debian-cd-test/debian-11.0.0-amd64-DLBD-1.template 
-jigdo-map Debian=/home/zby/debian/ -jigdo-exclude boot1 -J -joliet-long 
-cache-inodes -isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin -b 
isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table 
-no-emul-boot -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot 
-isohybrid-gpt-basdat -isohybrid-apm-hfsplus boot1 CD1
---
> xorriso -as mkisofs -r -checksum_algorithm_iso sha256,sha512 -V 'Debian 
> 11.0.0 amd64 1' -o 
> /srv/mirror/debian-cd-test/debian-11.0.0-amd64-CUSTOM-1.iso -checksum-list 
> /srv/mirror/tmp/bullseye/checksum-check -jigdo-checksum-algorithm md5 
> -jigdo-force-checksum /pool/ -jigdo-min-file-size 1024 -jigdo-exclude 
> 'README*' -jigdo-exclude /doc/ -jigdo-exclude /md5sum.txt -jigdo-exclude 
> /.disk/ -jigdo-exclude /pics/ -jigdo-exclude 'Release*' -jigdo-exclude 
> 'Packages*' -jigdo-exclude 'Sources*' -jigdo-force-md5 /pool/ -jigdo-jigdo 
> /srv/mirror/debian-cd-test/debian-11.0.0-amd64-CUSTOM-1.jigdo -jigdo-template 
> /srv/mirror/debian-cd-test/debian-11.0.0-amd64-CUSTOM-1.template -jigdo-map 
> Debian=/home/zby/debian/ -jigdo-exclude boot1 -J -joliet-long -cache-inodes 
> -isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin -b 
> isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table 
> -no-emul-boot -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot 
> -isohybrid-gpt-basdat -isohybrid-apm-hfsplus boot1 CD1
diff -r /mnt/README.html /groundtruth/README.html
55c55
<   Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 DLBD Binary-1 
20220528-13:35
---
>   Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 CUSTOM Binary-1 
> 20220528-14:56
98,99c98,99
< Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 DLBD 
Binary-1 20220528-13:35
< which means that this disc is number 1 of a set of 2 discs
---
> Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 
> CUSTOM Binary-1 20220528-14:56
> which means that this disc is number 1 of a set of 1 discs
105c105
< discs, up to Binary-2, contain mostly special-interest programs.
---
> discs, up to Binary-1, contain mostly special-interest programs.
diff -r /mnt/README.txt /groundtruth/README.txt
1,16c1,2
< Result of a run of merge_2_debian_isos at 20220528-23:34
< Package pools and Packages lists were merged.
< The other files stem from the first input ISO.
< 
< Input ISO: debian-11.0.0-amd64-DLBD-1.iso
<  Debian GNU/Linux 11.0.0 "Bullseye" - Unofficial amd64 DLBD Binary-1
<20220528-13:35
< 
< Input ISO: debian-11.0.0-amd64-DLBD-2.is

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

Another small patch. :-)

Best Regards,
Zhang BoyangFrom ae763e89f00575e56a7242e27c9b0789c0de411e Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Sun, 29 May 2022 02:45:32 +0800
Subject: [PATCH] Don't call FBIOPAN_DISPLAY when using the vga16fb driver

When using vga16fb, there is no need to call FBIOPAN_DISPLAY, and it may
cause screen flicker on certain hardwares.
---
 bogl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/bogl.c b/bogl.c
index 9b628b1..5cbe96e 100644
--- a/bogl.c
+++ b/bogl.c
@@ -462,6 +462,15 @@ bogl_fb_set_palette (int c, int nc, const unsigned char palette[][3])
 void
 bogl_update (void)
 {
+#if BOGL_VGA16_FB
+  if (type == FB_TYPE_VGA_PLANES)
+{
+  /* There is no need to call FBIOPAN_DISPLAY when using vga16fb driver.
+ What's worse, it may cause screen flicker on certain hardwares.
+	 So make bogl_update() a no-op here. */
+  return;
+}
+#endif
   ioctl (fb, FBIOPAN_DISPLAY, _var);
 }
 
-- 
2.30.2

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Hi,

Here is another small patch. Please see the commit message of the patch 
for details. The merge request on salsa is also updated.



Best Regards,
Zhang BoyangFrom 36020995b989563efed3cfe6028cd93c192c0208 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Sat, 28 May 2022 16:39:23 +0800
Subject: [PATCH] Fix rightmost pixel of each line not cleared by
 bogl_vga16_text()

The bogl_vga16_clear() function use [x1, x2) as clear range, so there is
no need to minus x2 by 1.
---
 bogl-vga16.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bogl-vga16.c b/bogl-vga16.c
index 6c2cbcf..3fcbe51 100644
--- a/bogl-vga16.c
+++ b/bogl-vga16.c
@@ -373,7 +373,7 @@ bogl_vga16_text (int xx, int yy, const char *s, int n, int fg, int bg, int ul,
 {
   int x2 = xx + bogl_metrics (s, n, font);
   if (x2 >= bogl_xres)
-	x2 = bogl_xres - 1;
+	x2 = bogl_xres;
   
   bogl_vga16_clear (xx, yy, x2, yy + h, bg);
 }
-- 
2.30.2

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Zhang Boyang]

Package: bogl-bterm

Hello,

I made several improvements to bterm. Please see these patches for 
details. For convenience, I also created a merge request at 
https://salsa.debian.org/debian/bogl/-/merge_requests/2



Best Regards,
Zhang BoyangFrom 1e253d724658ffc22f1339212af3d2754249b251 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Mon, 23 May 2022 14:10:52 +0800
Subject: [PATCH 1/7] Better font reload handling

Previous font reload code will leak a mmap on each reload. This patch
adds the ability to munmap old font after reload. However, this also
introduces a bug, if font reload is triggered while drawing in progress,
after signal handler returns, the drawing code will continue to use old
font which has been freed, causing crash. This will be fixed in later
patches.
---
 bogl-bgf.c | 61 +++---
 bogl-bgf.h |  1 +
 bterm.c| 10 -
 3 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/bogl-bgf.c b/bogl-bgf.c
index 1032028..0383f4f 100644
--- a/bogl-bgf.c
+++ b/bogl-bgf.c
@@ -5,38 +5,55 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bogl.h"
 #include "boglP.h"
 #include "bogl-font.h"
+#include "bogl-bgf.h"
+
+struct bogl_bgf {
+  void *f;/* mmap area */
+  off_t size; /* size of mmap area */
+  struct bogl_font font; /* font descriptor */
+};
+#define bgf_of(font) \
+  ((struct bogl_bgf *)((char *)(font) - offsetof(struct bogl_bgf, font)))
 
 struct bogl_font *bogl_mmap_font(char *file)
 {
-  int fd;
+  struct bogl_bgf *bgf = NULL;
+  struct bogl_font *font = NULL;
+  int fd = -1;
   struct stat buf;
-  void *f;
-  struct bogl_font *font;
+  void *f = (void *)-1;
+
+  bgf = (struct bogl_bgf *)malloc(sizeof(struct bogl_bgf));
+  if (!bgf)
+goto fail;
+  font = >font;
 
   fd = open(file, O_RDONLY);
   if (fd == -1)
-return 0;
+goto fail;
 
   if (bogl_cloexec(fd) < 0)
-return 0;
+goto fail;
 
   if (fstat(fd, ))
-return 0;
+goto fail;
+  bgf->size = buf.st_size;
+
+  if (buf.st_size < 4)
+goto fail;
 
   f = mmap(0, buf.st_size, PROT_READ, MAP_SHARED, fd, 0);
   if (f == (void *)-1)
-return 0;
+goto fail;
+  bgf->f = f;
 
   if (memcmp("BGF1", f, 4))
-return 0;
-
-  font = (struct bogl_font *)malloc(sizeof(struct bogl_font));
-  if (!font)
-return 0;
+goto fail;
 
   memcpy(font, f + 4, sizeof(*font));
   font->name = ((void *)font->name - (void *)0) + f;
@@ -44,5 +61,25 @@ struct bogl_font *bogl_mmap_font(char *file)
   font->index = ((void *)font->index - (void *)0) + f;
   font->content = ((void *)font->content - (void *)0) + f;
 
+done:
+  if (fd != -1)
+close(fd);
   return font;
+
+fail:
+  if (bgf) {
+free(bgf);
+bgf = NULL;
+font = NULL;
+  }
+  if (f != (void *)-1)
+munmap(f, buf.st_size);
+  goto done;
+}
+
+void bogl_munmap_font(struct bogl_font *font)
+{
+  struct bogl_bgf *bgf = bgf_of(font);
+  munmap(bgf->f, bgf->size);
+  free(bgf);
 }
diff --git a/bogl-bgf.h b/bogl-bgf.h
index e9fb994..f14a260 100644
--- a/bogl-bgf.h
+++ b/bogl-bgf.h
@@ -1,2 +1,3 @@
 
 struct bogl_font *bogl_mmap_font(char *file);
+void bogl_munmap_font(struct bogl_font *font);
diff --git a/bterm.c b/bterm.c
index d7b574f..22cbef5 100644
--- a/bterm.c
+++ b/bterm.c
@@ -215,15 +215,13 @@ void reload_font(int sig)
   font = bogl_mmap_font (font_name);
   if (font == NULL)
 {
-  fprintf(stderr, "Bad font\n");
+  /* Fail silently. To simplify implementation, debian-installer may
+ trigger redundant font reload requests, and the font file may not
+ available at that time, so handle it gracefully. */
   return;
 }
   
-  /* This leaks a mmap.  Since the font reloading feature is only expected
- to be used once per session (for instance, in debian-installer, after
- the font is replaced with a larger version containing more characters),
- we don't worry about the leak.  */
-  free(term->font);
+  bogl_munmap_font(term->font);
 
   term->font = font;
   term->xstep = bogl_font_glyph(term->font, ' ', 0);
-- 
2.30.2

From 0f1b0b57a2b36ae4e04a5a32c9a55634a1cbae39 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Mon, 23 May 2022 22:07:37 +0800
Subject: [PATCH 2/7] Use ioctl(FBIOPAN_DISPLAY) to update screen after drawing

Some framebuffer driver like i915 need explicit notify after drawing,
otherwise modifications in graphics buffer will not be reflected on
screen, so use FBIOPAN_DISPLAY to do this notify.
---
 bogl-term.c |  1 +
 bogl.c  | 10 +-
 bogl.h  |  1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/bogl-term.c b/bogl-term.c
index d5780d3..1f68523 100644
--- a/bogl-term.c
+++ b/bogl-term.c
@@ -863,4 +863,5 @@ bogl_term_redraw (struct bogl_term *term)
 {
 show_cursor(term, 1);
 }
+bogl_update();
 }
diff --git a/bogl.c b/bogl.c
index 6b9996b..

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/5/23 01:18, Thomas Schmitt wrote:

How can i verify that the resulting ISO properly announces all its
packages ?
(If i install it to a VM, what must i do to challenge its completeness ?)


I came up with a idea. Maybe you can use 'debian-cd' to create a DLBD 
set, say disc A1 and A2, then create another ALL-IN-ONE set, say disc B. 
Then compare if A1+A2==B. There might be small differences, like the 
package order in Packages.gz, but I think if the overall format is OK, 
then it will be OK.



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

On 2022/5/21 22:59, Thomas Schmitt wrote:


Is there documentation from which i could learn how the stuff in (i guess)
/dists of DLBD-1 and DLBD-2 could be merged so that it properly describes
a merged pool tree ?

My rough idea would be:
- mount both ISOs
- derive merged /dists files
- run xorriso to let it
   - load DLBD-1 with its boot equipment
   - merge-in the pool tree of mounted DLBD-2
   - overwrite the old /dists files by the newly derived ones
   - automatically replay the commands for the loaded boot equipment
   - store the result as new .iso file

The second step is where i would need info or advise.




Hi,

Sorry but I'm not familiar with internal details of ISOs, and I guess 
there is no ready tool can merge two ISOs together. After a quick look 
on dists/, I think these files are in same format with theses on online 
mirrors, so referring apt's documentation might be useful. Also I found 
these files are just plain texts (or gzipped plain texts), the format 
might be very simple, I think.



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

On 2022/5/21 22:54, Linux-Fan wrote:

I admit a local mirror is more suitable for large set of computers. 
But for a small set of computers, for example, 1-5 computers, setting 
up a local mirror might be too heavy.


Actually I think this may be a misconception. Setting up a mirror for 
internal use is (from my experience with the `ftpsync` script, cf.
https://www.debian.org/mirror/ftpmirror) pretty straight-forward. AFAIK 
the minimal steps are as follows:


- Download and extract ftpsync to a location
- Configure distrib/etc/ftpsync.conf
- Setup a webserver to serve the mirror directory
- Invoke mirror script
- Then point clients to the webserver location



Thanks for this information. I think I overestimated the difficulty of 
creating a mirror.


The advantages of using a mirror over iso images are probably worth 
noting, too:


- No need to understand the working of jigdo


As a user, jigdo is easy :-) Feed 'jigdo-lite' with 'xxx.iso.jigdo' and 
then go to sleep. When you wake up, the 'xxx.iso' file is ready.



- Works well with all kinds of machines
   (physical, virtual, remote etc.)
- Can span multiple architectures:
   It should come as a huge advantage in storage requirements
   if you ever need more than one architecture because unlike the
   .iso-based approach only the architectures of interest will be
   contained in the mirror and packages common for all architectures
   will only be stored once.
- Can take advantage of better file system performance, load balanching
   and caching. This would probably only affect large installations,
   though. > - In case networking is really not wanted on client machines, a 
mirror
   can also be rsync'ed to target storage media and then referenced by
   `file://` entries in the client's `/etc/apt/sources.list`.



Indeed, a local mirror is more suitable in most cases. I only come up 
with a few cases that ISOs are more useful:


1) When installing packages using a mirror, the mirror machine must be 
powered on. There is no need for a dedicated mirror machine if using 
ISO. (This doesn't affect offline storage medias, though)


2) ISOs are faster to copy than a lot of small packages. (Rsync will be 
easier to update, though)


3) ISOs are easy to verify integrity. Run 'sha512sum -c SHA256SUMS' then 
you are confident there is no problem in its contents.


4) ISOs are easy to archive or create parity archives like PAR2 
archives. It's more robust than having lots of small files. (Creating 
tarballs may provide same advantages, though)


After all, I admit the advantages of ISOs are minor. But I think it's 
good to have an alternative :-)




HTH and YMMV
Linux-Fan

öö



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hello Andy,

Andrew M.A. Cater wrote:
> If the original poster wants one huge .iso as one file to download from
> cdimage.debian.org - then 2 x double layer Blu-Ray (say) as one file
would be 100GB or so.

Original poster here, IMO the iso needn't to be directly downloadable, 
officially signed jigdo files and checksums are sufficient, just like 
Blu-Ray variants. :-)



Best Regards,
Zhang Boyang

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/5/21 18:13, Andrew M.A. Cater wrote:

On Sat, May 21, 2022 at 01:33:02PM +0800, Zhang Boyang wrote:

Hi,

Indeed, I admit super-big-iso is a crazy idea, and a local mirror is more
useful in most cases. I think there is a few special cases that a
super-big-iso might be more useful.

1) Computers / Virtual Machines isolated from public internet or have no
network at all. It is convenient to have such an ISO to install software on
demand. A single file is much more convenient than setting up a local
mirror. It's also easy to manage or verify integrity, if frequent updates
are not needed.



If you have a computer isolated from the internet / with no network connectivitythen you 
are essentially "set and forget" - because the only way to update this
is to hand carry packages in for security updates or whatever. For that, you
can use the DL-BD sized .iso - you'll need a computer that's connected to the
'Net to build it via jigdo / jigit - but you'd need a computer connected to
the internet to donwload the DVD or any other medium.
 > The double-layer Blu-Ray disk sized medium is 50GB or so - so you 

could write

that to a 64G USB flash disk. We - the debian images team that build and test
the images - don't routinely create all those full size images and put them in
the archive - because that would be terabytes with every point release.
They're there if you need them.


Yes, I found only two DLBD images is sufficient to contain whole debian 
distribution as for now. If my idea is not accepted, I would use that :-)




Actually, setting up a local mirror is potentially almost as easy a use case
as using gigantic media files. That's exactly what many hosting companies
do in their data centres for their own use (and it's also in some of those
data centres  where some of the Debian country level mirrors are located).
So a large isolated network may find it useful to have a local mirror
updated periodically.


I admit a local mirror is more suitable for large set of computers. But 
for a small set of computers, for example, 1-5 computers, setting up a 
local mirror might be too heavy.





2) Archival purposes. If someone (in future, for example, in 2042) want to
install a very old debian system, he/she may grab the big ISO and all he/she
need is that single file. Although it's not easy to grab the file in far
future, but I guess there is always someone crazy enough to archive all
files, isn't it? :P



See, for example, snapshot.debian.org - which is growing. See also the
cdimage.debian.org archive directory where you can find most of the .iso
files for any release. Also, keeping large files around on disk for a long
time - there's some likelihood of data corruption. I'd hate a couple of
bit flips three quarters of the way through a 6TB file, say, to mean that
the whole thing isuseless.



IMO snapshot.debian.org is centralized platform, it might be lost if 
something very bad happened. For cdimage.debian.org, it's not sufficient 
to archive a full debian distribution because most files are jigdos.


For bit flip corruptions, I would recommand PAR2 (Parchive 2) which can 
use Reed-Solomon to create a parity archive, and that archive can be 
used to fix these corruptions.



I think setting up a new variant of image is not very costly for debian
since there are already many variants, so why not give people more choices
:-)


Best Regards,
Zhang Boyang

On 2022/5/21 07:09, Andy Simpkins wrote:

On 20 May 2022 15:11:09 BST, Zhang Boyang  wrote:

Package: debian-cd

Hello,

I suggest debian release a new variant of ISO images, the all-in-one images. 
These all-in-one image contains ALL debian packages in a single ISO image 
(possibly all source packages in another all-in-one ISO image). Of course there 
is no such optical media can hold such a big image, but it is useful for 
virtual-machines, remotely managed servers, and archival purposes. The 
theoretical size limit of an ISO9660 filesystem is about 8TB, which is 
sufficient for including all debian packages.

For the name of this variant, I suggest 'everything', 'allinone', 'world', 
'virt'.

p.s. This is my personal interest, and I would appreciate if you can kindly 
consider my suggestion.


Best Regards,
Zhang Boyang




Sorry to put a dampener on your suggestion but why would you need that?

Why not just mirror the archive to a local disk instead?

Then you have your copy of everything and can just point a netinst at your 
local mirror so you can install from there.

I think that would deliver on every use case that you would be able to use your 
big ISO image and more





Andy is absolutely right, I think.

If it helps, I'm the "other" Andy in the team along with Steve McIntyre -
and yes, I know the problems of copying large images around, have a local
mirror here and routinely build at least the single layer BD disk with
every point release.

This is a topic that comes up fairly frequently in our informal discussions

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

Indeed, I admit super-big-iso is a crazy idea, and a local mirror is 
more useful in most cases. I think there is a few special cases that a 
super-big-iso might be more useful.


1) Computers / Virtual Machines isolated from public internet or have no 
network at all. It is convenient to have such an ISO to install software 
on demand. A single file is much more convenient than setting up a local 
mirror. It's also easy to manage or verify integrity, if frequent 
updates are not needed.


2) Archival purposes. If someone (in future, for example, in 2042) want 
to install a very old debian system, he/she may grab the big ISO and all 
he/she need is that single file. Although it's not easy to grab the file 
in far future, but I guess there is always someone crazy enough to 
archive all files, isn't it? :P


I think setting up a new variant of image is not very costly for debian 
since there are already many variants, so why not give people more 
choices :-)



Best Regards,
Zhang Boyang

On 2022/5/21 07:09, Andy Simpkins wrote:

On 20 May 2022 15:11:09 BST, Zhang Boyang  wrote:

Package: debian-cd

Hello,

I suggest debian release a new variant of ISO images, the all-in-one images. 
These all-in-one image contains ALL debian packages in a single ISO image 
(possibly all source packages in another all-in-one ISO image). Of course there 
is no such optical media can hold such a big image, but it is useful for 
virtual-machines, remotely managed servers, and archival purposes. The 
theoretical size limit of an ISO9660 filesystem is about 8TB, which is 
sufficient for including all debian packages.

For the name of this variant, I suggest 'everything', 'allinone', 'world', 
'virt'.

p.s. This is my personal interest, and I would appreciate if you can kindly 
consider my suggestion.


Best Regards,
Zhang Boyang




Sorry to put a dampener on your suggestion but why would you need that?

Why not just mirror the archive to a local disk instead?

Then you have your copy of everything and can just point a netinst at your 
local mirror so you can install from there.

I think that would deliver on every use case that you would be able to use your 
big ISO image and more

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Package: debian-cd

Hello,

I suggest debian release a new variant of ISO images, the all-in-one 
images. These all-in-one image contains ALL debian packages in a single 
ISO image (possibly all source packages in another all-in-one ISO 
image). Of course there is no such optical media can hold such a big 
image, but it is useful for virtual-machines, remotely managed servers, 
and archival purposes. The theoretical size limit of an ISO9660 
filesystem is about 8TB, which is sufficient for including all debian 
packages.


For the name of this variant, I suggest 'everything', 'allinone', 
'world', 'virt'.


p.s. This is my personal interest, and I would appreciate if you can 
kindly consider my suggestion.



Best Regards,
Zhang Boyang

Bug#1011262: WISHLIST: Offical DVD-DL images?

[Zhang Boyang]

Package: debian-cd

Hello,

I found debian provide several variants of iso images, including CD, 
DVD, Blu-Ray, etc. However, an important variant of iso image, DVD-DL 
image, is not officially released. DVD-DL (8.5G, Dual Layer DVD) nearly 
doubles the capacity compared to ordinary DVD (4.7G). As software become 
bigger and bigger, I think it is beneficial to release offical DVD-DL 
images.


To my knowledge, most optical disc drives in PC and servers are DVD 
drives, which are compatible with DVD-DL discs. And I rarely seen a 
computer with Blu-Ray drives. So releasing DVD-DL images can benefit 
these users directly. (Gentoo already releases their Live ISO image in 
DVD-DL, and Microsoft also release Windows in DVD-DL)



Best Regards,
Zhang Boyang

Bug#1011261: The digest algorithm in SHA512SUMS.sign is SHA256

[Zhang Boyang]

Package: debian-cd

Hello,

I downloaded debian iso and its SHA512SUMS file. However, when I use gpg 
to verify authenticity of SHA512SUMS, I found the signature file use 
SHA256 as its digest algorithm. Although SHA256 is pretty safe, it's 
seem strange that sign a SHA512SUMS with SHA256. I think it's better to 
sign SHA512SUMS with SHA512.


Best Regards,
Zhang Boyang


$ LANG=C gpg -v --verify SHA512SUMS.sign
gpg: assuming signed data in 'SHA512SUMS'
gpg: Signature made Sun Mar 27 05:22:41 2022 CST
gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: using pgp trust model
gpg: Good signature from "Debian CD signing key 
" [unknown]

gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the 
owner.

Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B
gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096

Bug#1003138: Some related links

[Yousen Zhang]

A related/similar post on Windows is
https://stackoverflow.com/questions/44153858/linking-against-boost-python-3-6-cant-find-boost-python-instead-of-boost-pytho

As I had set using python 3.9, but ld will always tried to link
libboost_python instead of libboost_python3.9

I also checked the header  /usr/include/boost/python/detail/config.hpp
It shows
#define BOOST_LIB_NAME BOOST_PYTHON_CONCAT(boost_python, PY_MAJOR_VERSION,
PY_MINOR_VERSION)

I suspect this package won't work properly out the PY_MAJOR_VERSION and
PY_MINOR_VERSION defined in /usr/include/python3.9/Python.h

Bug#1003138: libboost-tools-dev: Conflicts between libboost-tools-dev and libboost-python-dev

[Yousen Zhang]

Package: libboost-tools-dev
Version: 1.74.0.3
Severity: normal

Dear Maintainer,

I tried to compile a simple tutorial following the link [1].

I tried to run

bjam under example/tutorial after prepending the following to Jamroot file:

  using python : 3.9
   : /usr/bin/python3
   : /usr/include/python3.9
   : /usr/lib/python3.9/config-3.9-x86_64-linux-gnu
   ;

However, it always encounter

  /usr/bin/ld: cannot find -lboost_python
  collect2: error: ld returned 1 exit status

  "g++"-o "hello_ext.cpython-39-x86_64-linux-gnu.so" -Wl,-h -Wl,
hello_ext.cpython-39-x86_64-linux-gnu.so -shared -Wl,--start-group
"hello.o"  -Wl,-Bstatic  -Wl,-Bdynamic -lboost_python -ldl -lpthread -lutil
-Wl,--end-group -fPIC -g

I tried to manually compile, replace boost_python with boost_python39,
through
   g++ -o "hello_ext.cpython-39-x86_64-linux-gnu.so" -Wl,-h -Wl,
hello_ext.cpython-39-x86_64-linux-gnu.so -shared -Wl,--start-group
"hello.o"  -Wl,-Bstatic  -Wl,-Bdynamic -lboost_python39 -ldl -lpthread
-lutil -Wl,--end-group -fPIC -g

It succeeds.

I was wondering if this is from the conflicts between the building tools
and libraries for boost-python. I am a novice and please correct me if I am
wrong.

I worked on WSL2-Debian Stable. And I installed build-essential,
python3-dev, libboost-python-dev, and libboost-tools-dev.

Library versions via apt search are:
libboost-python-dev/stable,now 1.74.0.3 amd64
libboost-tools-dev/stable,now 1.74.0.3 amd64
python3-dev/stable,now 3.9.2-3 amd64
build-essential/stable,now 12.9 amd64

Best regards,

Yousen

[1] https://github.com/boostorg/python/tree/develop/example/tutorial

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.60.1-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libboost-tools-dev depends on:
ii  libboost1.74-tools-dev  1.74.0-9

libboost-tools-dev recommends no packages.

libboost-tools-dev suggests no packages.

-- no debconf information

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[Zhang Boyang]

Hello,

I created a merge request on salsa.debian.org. The patch is same as my 
last email's.


Here is the URL:
https://salsa.debian.org/apt-team/apt/-/merge_requests/204

Best regards,
Zhang Boyang

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[Zhang Boyang]

Hello,

On 2021/11/25 21:03, David Kalnischkies wrote:

Hi,

On Thu, Nov 25, 2021 at 07:30:45PM +0800, Zhang Boyang wrote:

It seems my last email was marked spam. It's strange that the bug tracker
has received my reply but the mailing list didn't. Please correct me if I
misunderstand the situation.


Indeed, looks like your mail was dropped at some point. If you supply
sufficient details listmasters might be able to tell you what exactly
went wrong.

(The BTS seems to assign your mails ~ -10 points which is very good, but
  at the same time the list mail which passed through got 0, which is not
  bad, but also not particular good citing e.g. "MIME_BASE64_TEXT_BOGUS(1)
  R_DKIM_REJECT(1)". With patches you might be better of in salsa btw.)

I talked to the listmaster. The listmaster told me my mail is too large 
for deity mail list. I will try to reduce my mail size in future :)





The patch is attached again for convenience. This patch implemented Anders's
idea. The signal handler will only set a flag. After signal handler
completed, the pselect() in pkgDPkgPM::Go() will return immediately with
errno set to EINTR. Then, progress->Pluse() is called by pkgDPkgPM::Go(),
and PackageManagerFancy::Pluse() will redraw the status bar.


Not having looked at the issue itself I just gave the patch a casual
glance: PackageManagerFancy is a public – hence exported – interface,
so you can't change member variables or add virtual methods as that
breaks the ABI.



I revised my patch. Now the patch only add static member variables, 
which is not harmful to ABI. The Pluse() method already exists in base 
class but newly overridden. I think this change will not crash existing 
programs. However, existing compiled programs can still use 
BaseClass::Pluse() because compilers may optimize virtual calls. 
Personally I think this is not harmful because this will only cause 
status line not redrawing, which may consider acceptable.



At some point we will have one I am sure, but if at all possible it
could be better to investigate if that can be solved some other way.
(Not exactly sure why that is public at all, given there seems to also
  be a factory function to be able to hide it?)



If the Pluse() must not be overridden. I think the only way is to modify 
pkgDPkgPM::Go(), let it call some static method in PackageManagerFancy 
just after pselect(). However I'm not sure because I'm new to apt.



Can we perhaps make it (still) easier to reproduce? apt can be told to
use a different dpkg via Dir::Bin::dpkg – can we have that be a script
which just spits out 'offending' lines (= is it the fd messages or the
messages on stdout for example – or both) ?



Yes, with temporary modifications to code. I added another patch, which 
will call malloc() in a tight loop while simulating. To reproduce the 
problem, apply that patch and send SIGWINCH to apt continuously, like:


while :; do killall -SIGWINCH apt; done

Then, run apt like:

./apt install -s gnome

You will see apt crash in few seconds after install simulation started.



(Sorry for not being very specific at the moment as I am a bit starved
  for Debian time; will try to give that some proper thought/review
  ~next week)


Best regards

David Kalnischkies



Have a nice day :)
Zhang BoyangFrom 4c8f9d5ab13f3069caefeada38658b72f0ad1782 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Thu, 2 Dec 2021 00:16:07 +0800
Subject: [PATCH 1/2] Make heavy use of malloc() while simulating

---
 apt-pkg/algorithms.cc | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/apt-pkg/algorithms.cc b/apt-pkg/algorithms.cc
index fb0b7dca7..27bbe5490 100644
--- a/apt-pkg/algorithms.cc
+++ b/apt-pkg/algorithms.cc
@@ -119,6 +119,16 @@ bool pkgSimulate::Install(PkgIterator iPkg,string File)
 }
 bool pkgSimulate::RealInstall(PkgIterator iPkg,string /*File*/)
 {
+   // Use malloc() heavily, try trigger bug #852757
+   for (int round = 1; round <= 10; round++)
+   {
+  vector arr;
+  for (int sz = 1; sz <= 100; sz++)
+ arr.push_back(malloc(sz));
+  for (auto ptr: arr)
+ free(ptr);
+   }
+
// Adapt the iterator
PkgIterator Pkg = Sim.FindPkg(iPkg.Name(), iPkg.Arch());
Flags[Pkg->ID] = 1;
-- 
2.30.2

From ff09c6cacb3c2b5878d44fb370bf460fd27f6ec3 Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Thu, 2 Dec 2021 00:21:48 +0800
Subject: [PATCH 2/2] Fix incorrect SIGWINCH handling

Previously, status line is redrawn in signal handler. However, the
drawing code make heavy use of std::string and other syscalls, which may
not be async-signal-safe. This will cause deadlock, overwritten errno,
even silent memory corruption.

This patch implemented Anders Kaseorg's idea. The signal handler will
only set a flag, which is async-signal-safe, and actual redrawing will
be deferred to PackageManagerFancy::Pulse().

Note that the virtual function PackageManagerFancy::Pulse() already
exists in base class but newly overridden in PackageMa

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[Zhang Boyang]

Hello,

It seems my last email was marked spam. It's strange that the bug 
tracker has received my reply but the mailing list didn't. Please 
correct me if I misunderstand the situation.


My previous reply can be viewed at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852757


The patch is attached again for convenience. This patch implemented 
Anders's idea. The signal handler will only set a flag. After signal 
handler completed, the pselect() in pkgDPkgPM::Go() will return 
immediately with errno set to EINTR. Then, progress->Pluse() is called 
by pkgDPkgPM::Go(), and PackageManagerFancy::Pluse() will redraw the 
status bar.


I looked around for similar bugs. I found #947279 might be the same bug, 
but I don't have much evidence.


Best regards,
Zhang BoyangFrom 6cdd7fe9476a8149bc5bf18f70f9a8a30ba92d3a Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Wed, 24 Nov 2021 23:34:04 +0800
Subject: [PATCH] Fix incorrect SIGWINCH handling

Previously, status line is redrawn in signal handler. However, the
drawing code make heavy use of std::string and other syscalls, which may
not be async-signal-safe. This will cause deadlock, overwritten errno,
even silent memory corruption.

With this patch, the signal handler will only set a flag, which is
async-signal-safe, and actual redrawing will be deferred to Pulse().

Closes: #852757
---
 apt-pkg/install-progress.cc | 31 +--
 apt-pkg/install-progress.h  |  8 +---
 2 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/apt-pkg/install-progress.cc b/apt-pkg/install-progress.cc
index aadd28e51..99f16bffa 100644
--- a/apt-pkg/install-progress.cc
+++ b/apt-pkg/install-progress.cc
@@ -222,22 +222,22 @@ PackageManagerFancy::PackageManagerFancy()
: d(NULL), child_pty(-1)
 {
// setup terminal size
-   old_SIGWINCH = signal(SIGWINCH, PackageManagerFancy::staticSIGWINCH);
-   instances.push_back(this);
+   if (instances++ == 0)
+  old_SIGWINCH = signal(SIGWINCH, PackageManagerFancy::staticSIGWINCH);
 }
-std::vector PackageManagerFancy::instances;
+int PackageManagerFancy::instances = 0;
+sighandler_t PackageManagerFancy::old_SIGWINCH;
+volatile sig_atomic_t PackageManagerFancy::SIGWINCH_flag = 0;
 
 PackageManagerFancy::~PackageManagerFancy()
 {
-   instances.erase(find(instances.begin(), instances.end(), this));
-   signal(SIGWINCH, old_SIGWINCH);
+   if (--instances == 0)
+  signal(SIGWINCH, old_SIGWINCH);
 }
 
-void PackageManagerFancy::staticSIGWINCH(int signum)
+void PackageManagerFancy::staticSIGWINCH(int)
 {
-   std::vector::const_iterator I;
-   for(I = instances.begin(); I != instances.end(); ++I)
-  (*I)->HandleSIGWINCH(signum);
+   SIGWINCH_flag = 1;
 }
 
 PackageManagerFancy::TermSize
@@ -294,13 +294,24 @@ void PackageManagerFancy::SetupTerminalScrollArea(int nr_rows)
  }
 }
 
-void PackageManagerFancy::HandleSIGWINCH(int)
+void PackageManagerFancy::HandleSIGWINCH()
 {
int const nr_terminal_rows = GetTerminalSize().rows;
SetupTerminalScrollArea(nr_terminal_rows);
DrawStatusLine();
 }
 
+void PackageManagerFancy::Pulse()
+{
+   if (SIGWINCH_flag)
+   {
+  SIGWINCH_flag = 0;
+  int errsv = errno;
+  HandleSIGWINCH();
+  errno = errsv;
+   }
+}
+
 void PackageManagerFancy::Start(int a_child_pty)
 {
child_pty = a_child_pty;
diff --git a/apt-pkg/install-progress.h b/apt-pkg/install-progress.h
index 94b66ed9b..d1dd3eb8a 100644
--- a/apt-pkg/install-progress.h
+++ b/apt-pkg/install-progress.h
@@ -125,12 +125,14 @@ namespace Progress {
 void * const d;
  private:
 APT_HIDDEN static void staticSIGWINCH(int);
-static std::vector instances;
+static int instances;
+static sighandler_t old_SIGWINCH;
+static volatile sig_atomic_t SIGWINCH_flag;
 APT_HIDDEN bool DrawStatusLine();
 
  protected:
 void SetupTerminalScrollArea(int nr_rows);
-void HandleSIGWINCH(int);
+void HandleSIGWINCH();
 
 typedef struct {
int rows;
@@ -138,12 +140,12 @@ namespace Progress {
 } TermSize;
 TermSize GetTerminalSize();
 
-sighandler_t old_SIGWINCH;
 int child_pty;
 
  public:
 PackageManagerFancy();
 virtual ~PackageManagerFancy();
+virtual void Pulse() APT_OVERRIDE;
 virtual void Start(int child_pty=-1) APT_OVERRIDE;
 virtual void Stop() APT_OVERRIDE;
 virtual bool StatusChanged(std::string PackageName,
-- 
2.30.2

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Frederick Zhang]

I'm also experiencing this issue on my Raspberry Pi. It seems that it
had been reported to upstream [1] and fixed in [2].

[1] https://github.com/jirka-h/haveged/issues/41
[2] 
https://github.com/jirka-h/haveged/commit/159dcde28fa2deb3c6d5722dce9fe384f08202b7

On Sun, 14 Mar 2021 00:39:40 -0800 Rick Thomas  wrote:

Package: haveged
Version: 1.9.14-1
Severity: normal

Dear Maintainer,

I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
Bullseye and now haveged crashes.

$ sudo service haveged status
* haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h ago
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 1610 (code=killed, signal=SYS)
CPU: 247ms

Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
restart counter is at 5.
Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
algorithm.
Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated too 
quickly.
Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 'signal'.
Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on the 
HAVEGE algorithm.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 5.10.0-4-marvell
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages haveged depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libhavege2   1.9.14-1
ii  lsb-base 11.1.0

haveged recommends no packages.

Versions of packages haveged suggests:
ii  apparmor  2.13.6-9

-- no debconf information




--
Best regards,
Frederick Zhang

Email: frederick...@tsundere.moe
PGP:   8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D


OpenPGP_signature
Description: OpenPGP digital signature

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Junchao Zhang]

On Sun, May 31, 2020 at 10:33 AM Drew Parsons  wrote:

> On 2020-05-27 22:00, Junchao Zhang wrote:
> > On Wed, May 27, 2020 at 12:09 AM Drew Parsons 
> > wrote:
> >
> >> On 2020-05-24 10:01, Drew Parsons wrote:
> >>> On 2020-05-23 23:45, Satish Balay wrote:
> >>>>
> >>>> One more issue: Most externalpackages don't support
> >> 64bit-indices.
> >> ...
> >>>> We haven't tried using MUMPS in this mode with PETSc
> >>>
> >>> This will be the interesting test. I'll start with the 64-bit
> >> build of
> >>> MUMPS and see how tests hold up.
> >>
> >> The PETSc mumps tests seem to be robust with respect to 64 bit.
> >> (64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer
> >> -DINTSIZE64)
> >>
> >> That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
> >> and 64 bit PETSc passes its tests with 32 bit MUMPS.
> >>
> >> The test in question that's passing is src/snes/tutorials/ex19, run
> >> with
> >> 'make runex19_fieldsplit_mumps'
> >> Perhaps it's not stress-testing 64 bit conditions.
> >
> > Could you provide more details, e.g., the error stack trace?
>
>
>
> Hi Junchao, PETSc's mumps test runs fine, there is no error to trace as
> such, just a diff with the reference output.
>
> With 32-bit PETSc and 64-bit [PORD] MUMPS,
>
> $ mpirun -n 2 ./ex19 -pc_type fieldsplit -pc_fieldsplit_block_size 4
> -pc_fieldsplit_type SCHUR -pc_fieldsplit_0_fields 0,1,2
> -pc_fieldsplit_1_fields 3 -fieldsplit_0_pc_type lu -fieldsplit_1_pc_type
> lu -snes_monitor_short -ksp_monitor_short
> -fieldsplit_0_pc_factor_mat_solver_type mumps
> -fieldsplit_1_pc_factor_mat_solver_type mumps
>
> returns the result:
>
> lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
>0 SNES Function norm 0.239155
>  0 KSP Residual norm 0.235858
>  1 KSP Residual norm < 1.e-11
>1 SNES Function norm 6.81968e-05
>  0 KSP Residual norm 2.30906e-05
>  1 KSP Residual norm < 1.e-11
>2 SNES Function norm < 1.e-11
> Number of SNES iterations = 2
>
>
> where output/ex19_fieldsplit_5.out has
>
> lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
>0 SNES Function norm 0.239155
>  0 KSP Residual norm 0.239155
>  1 KSP Residual norm < 1.e-11
>1 SNES Function norm 6.81968e-05
>  0 KSP Residual norm 6.81968e-05
>  1 KSP Residual norm < 1.e-11
>2 SNES Function norm < 1.e-11
> Number of SNES iterations = 2
>
>
> So the diff in this case is
>
> $make runex19_fieldsplit_mumps
> 3c3
> < 0 KSP Residual norm 0.239155
> ---
> > 0 KSP Residual norm 0.235858
> 6c6
> < 0 KSP Residual norm 6.81968e-05
> ---
> > 0 KSP Residual norm 2.30906e-05
>
I tested it with both 32-bit and 64-bit. They had the same result as yours.
It seems we need to update the output file in the repo. I will do it.
Thanks.

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Junchao Zhang]

On Wed, May 27, 2020 at 12:09 AM Drew Parsons  wrote:

> On 2020-05-24 10:01, Drew Parsons wrote:
> > On 2020-05-23 23:45, Satish Balay wrote:
> >>
> >> One more issue: Most externalpackages don't support 64bit-indices.
> ...
> >> We haven't tried using MUMPS in this mode with PETSc
> >
> > This will be the interesting test. I'll start with the 64-bit build of
> > MUMPS and see how tests hold up.
>
>
> The PETSc mumps tests seem to be robust with respect to 64 bit.
> (64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer
> -DINTSIZE64)
>
> That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
> and 64 bit PETSc passes its tests with 32 bit MUMPS.
>
> The test in question that's passing is src/snes/tutorials/ex19, run with
> 'make runex19_fieldsplit_mumps'
> Perhaps it's not stress-testing 64 bit conditions.
>
Could you provide more details, e.g., the error stack trace?


>
> Drew
>

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Junchao Zhang]

On Sat, May 23, 2020 at 1:49 AM Drew Parsons  wrote:

> On 2020-05-23 14:18, Jed Brown wrote:
> > Drew Parsons  writes:
> >
> >> Hi, the Debian project is discussing whether we should start providing
> >> a
> >> 64 bit build of PETSc (which means we'd have to upgrade our entire
> >> computational library stack, starting from BLAS and going through MPI,
> >> MUMPS, etc).
> >
> > You don't need to change BLAS or MPI.
>
> I see, the PETSc API allows for PetscBLASInt and PetscMPIInt distinct
> from PetscInt. That gives us more flexibility. (In any case, the Debian
> BLAS maintainer is already providing blas64 packages. We've started
> discussions about MPI).
>
> But what about MUMPS? Would MUMPS need to be built with 64 bit support
> to work with 64-bit PETSc?
> (the MUMPS docs indicate that its 64 bit support needs 64-bit versions
> of BLAS, SCOTCH, METIS and MPI).
>
In MUMPS's manual, it is called full 64-bit. Out of the same memory
bandwidth concern, MUMPS also supports selective 64-bit, in a sense it only
uses int64_t for selected variables. One can still use it with 32-bit BLAS,
MPI etc.  We support selective 64-bit MUMPS starting from petsc-3.13.0


>
>
> >> A default PETSc build uses 32 bit addressing to index vectors and
> >> matrices.  64 bit addressing can be switched on by configuring with
> >> --with-64-bit-indices=1, allowing much larger systems to be handled.
> >>
> >> My question for petsc-maint is, is there a reason why 64 bit indexing
> >> is
> >> not already activated by default on 64-bit systems?  Certainly C
> >> pointers and type int would already be 64 bit on these systems.
> >
> > Umm, x86-64 Linux is LP64, so int is 32-bit.  ILP64 is relatively
> > exotic
> > these days.
>
>
> oh ok. I had assumed int was 64 bit on x86-64. Thanks for the
> correction.
>
>
> >> Is it a question of performance?  Is 32 bit indexing executed faster
> >> (in
> >> the sense of 2 operations per clock cycle), such that 64-bit
> >> addressing
> >> is accompanied with a drop in performance?
> >
> > Sparse iterative solvers are entirely limited by memory bandwidth;
> > sizeof(double) + sizeof(int64_t) = 16 incurs a performance hit relative
> > to 12 for int32_t.  It has nothing to do with clock cycles for
> > instructions, just memory bandwidth (and usage, but that is less often
> > an issue).
> >
> >> In that case we'd only want to use 64-bit PETSc if the system being
> >> modelled is large enough to actually need it. Or is there a different
> >> reason that 64 bit indexing is not switched on by default?
> >
> > It's just about performance, as above.
>
>
> Thanks Jed.  That's good justification for us to keep our current 32-bit
> built then, and provide a separate 64-bit build alongside it.
>
>
> >  There are two situations in
> > which 64-bit is needed.  Historically (supercomputing with thinner
> > nodes), it has been that you're solving problems with more than 2B
> > dofs.
> > In today's age of fat nodes, it also happens that a matrix on a single
> > MPI rank has more than 2B nonzeros.  This is especially common when
> > using direct solvers.  We'd like to address the latter case by only
> > promoting the row offsets (thereby avoiding the memory hit of promoting
> > column indices):
> >
> > https://gitlab.com/petsc/petsc/-/issues/333
>
> An interesting extra challenge.
>
>
> > I wonder if you are aware of any static analysis tools that can
> > flag implicit conversions of this sort:
> >
> > int64_t n = ...;
> > for (int32_t i=0; i >   ...
> > }
> >
> > There is -fsanitize=signed-integer-overflow (which generates a runtime
> > error message), but that requires data to cause overflow at every
> > possible location.
>
> I'll ask the Debian gcc team and the Science team if they have ideas
> about this.
>
> Drew
>

Bug#953352: Heap-buffer-overflow in jhead-3.04

[Hanfang Zhang]

Package: jhead
Version: 3.04

A heap-buffer-overflow issue was discovered in jhead-3.04:gpsinfo.c:161.

Please run following command to reproduce it,
./jhead poc

Here is the detail log:
$ ./jhead poc

Nonfatal Error : 'poc' Extraneous 10 padding bytes before section E1

Nonfatal Error : 'poc' Illegal value pointer for tag 0100 in Exif

Nonfatal Error : 'poc' Illegal value pointer for tag fe0f in Exif

Nonfatal Error : 'poc' Illegal value pointer for tag 0110 in Exif
=
==29343==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xb5e03e98 at pc 0x08059e85 bp 0xbffbf488 sp 0xbffbf478
READ of size 1 at 0xb5e03e98 thread T0
#0 0x8059e84 in ProcessGpsInfo /home/test/afl/jhead-3.04/gpsinfo.c:161
#1 0x8055a15 in ProcessExifDir /home/test/afl/jhead-3.04/exif.c:866
#2 0x8056260 in process_EXIF /home/test/afl/jhead-3.04/exif.c:1041
#3 0x804fdb8 in ReadJpegSections /home/test/afl/jhead-3.04/jpgfile.c:287
#4 0x8050190 in ReadJpegFile /home/test/afl/jhead-3.04/jpgfile.c:379
#5 0x804cad9 in ProcessFile /home/test/afl/jhead-3.04/jhead.c:905
#6 0x8049cfa in main /home/test/afl/jhead-3.04/jhead.c:1756
#7 0xb77b8636 in __libc_start_main
(/lib/i386-linux-gnu/libc.so.6+0x18636)
#8 0x804b65b  (/home/test/BinFuzz/jhead+0x804b65b)

AddressSanitizer can not describe address in more detail (wild memory
access suspected).
SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/test/afl/jhead-3.04/gpsinfo.c:161 ProcessGpsInfo
Shadow bytes around the buggy address:
  0x36bc0780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc0790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc07a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc07b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc07c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x36bc07d0: fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc07e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc07f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc0800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc0810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36bc0820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
==29343==ABORTING

This issue was raised by binary-security-lab of Sichuan University, for
fuzzing research work.


poc
Description: Binary data

Bug#446036: Job Offer!!!

[Mr. Wen Li Zhang]

We have a job offer for you. Reply to this email for more details. 

Wen Li Zhang 

Bug#407722: Job Offer For You.

[Mr. Wen Li Zhang]

We have a job offer for you. Reply to this email for more details. 

Wen Li Zhang 

Bug#939662: 回复: Bug#939662 closed by Stephen Kitt (Re: Bug#939662: sys/mman.h not found)

[Zhang Hao]

Dear

Even though I use the parameter "--host=x86_64-w64-32", the gperftools makefile 
dos not passed.
And The gperftools support "mingw-w64" to cross compile on linux.
You can find it on "https://github.com/gperftools/gperftools/issues/878;.
And I have report this issue in 
"https://github.com/gperftools/gperftools/issues/1108;.
The developer told me this is a "#include ." issue, not gperftools' 
problem.




发件人: Debian Bug Tracking System 
发送时间: 2019年9月7日 23:48
收件人: Zhang Hao 
主题: Bug#939662 closed by Stephen Kitt  (Re: Bug#939662: 
sys/mman.h not found)

This is an automatic notification regarding your Bug report
which was filed against the mingw-w64 package:

#939662: sys/mman.h not found

It has been closed by Stephen Kitt .

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 Stephen Kitt 
 by
replying to this email.


--
939662: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939662
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#939662: sys/mman.h not found

[Zhang Hao]

Package: mingw-w64
Version: 6.0.0-3
Severity: serious
Tags: a11y ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

  Firstly I export my host as "x86_64-w64-mingw32" and then install the 
gcc-mingw-w64,g++-mingw-w64 and some tolls to compile.
  Secondly, I clone the source of gperftools from github to compile the 
tcmalloc.
  But this error "sys/mman.h not found" occured when I run the command "make" 
after the commands "sh autogen.sh" and "./configure mingw-w64" finished.
  I really not found the mman.h in the directory of mingw64.
  I need your help.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mingw-w64 depends on:
ii  g++-mingw-w64  8.3.0-19+21.4
ii  gcc-mingw-w64  8.3.0-19+21.4

mingw-w64 recommends no packages.

mingw-w64 suggests no packages.

-- no debconf information

Bug#929743: boinc-client: Default installation miss "slots" directory made the boincmgr gray out.

[Zhang Xiaowei]

Package: boinc-client
Version: 7.14.2+dfsg-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

As title says. I just apt-get install and run boincmgr as usual at the first 
time.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When I run the boincmgr, all items grayed out.

   * What was the outcome of this action?

This is my systctl status says:
● boinc-client.service - Berkeley Open Infrastructure Network Computing Client
   Loaded: loaded (/lib/systemd/system/boinc-client.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2019-05-30 08:59:17 CST; 8min ago
 Docs: man:boinc(1)
 Main PID: 8352 (boinc)
Tasks: 2 (limit: 4915)
   Memory: 6.3M
   CGroup: /system.slice/boinc-client.service
   └─8352 /usr/bin/boinc

30-May-2019 08:59:20 [---]suspend work if non-BOINC CPU load exceeds 25%
30-May-2019 08:59:20 [---](to change preferences, visit a project web site 
or select Preferences in the Manager)
30-May-2019 08:59:20 [---] Setting up project and slot directories
dir_open: Could not open directory 'slots' from '/var/lib/boinc-client'.
30-May-2019 08:59:20 [---] Checking active tasks
30-May-2019 08:59:20 [---] Setting up GUI RPC socket
30-May-2019 08:59:20 [---] gui_rpc_auth.cfg is empty - no GUI RPC password 
protection
30-May-2019 08:59:20 [---] Checking presence of 0 project files
30-May-2019 08:59:20 [---] This computer is not attached to any projects
30-May-2019 08:59:20 Initialization completed

After mkdir under /var/lib/boinc, it's all perfect and rainbowed in.

● boinc-client.service - Berkeley Open Infrastructure Network Computing Client
   Loaded: loaded (/lib/systemd/system/boinc-client.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2019-05-30 09:10:21 CST; 4s ago
 Docs: man:boinc(1)
 Main PID: 10947 (boinc)
Tasks: 2 (limit: 4915)
   Memory: 6.3M
   CGroup: /system.slice/boinc-client.service
   └─10947 /usr/bin/boinc

30-May-2019 09:10:23 [---]don't use GPU while active
30-May-2019 09:10:23 [---]suspend work if non-BOINC CPU load exceeds 25%
30-May-2019 09:10:23 [---](to change preferences, visit a project web site 
or select Preferences in the Manager)
30-May-2019 09:10:23 [---] Setting up project and slot directories
30-May-2019 09:10:23 [---] Checking active tasks
30-May-2019 09:10:23 [---] Setting up GUI RPC socket
30-May-2019 09:10:23 [---] gui_rpc_auth.cfg is empty - no GUI RPC password 
protection
30-May-2019 09:10:23 [---] Checking presence of 0 project files
30-May-2019 09:10:23 [---] This computer is not attached to any projects
30-May-2019 09:10:23 Initialization completed

Bondezirojn.

From Zhang Xiaowei

-- Package-specific info:
-- Contents of /etc/default/boinc-client:
# This file is /etc/default/boinc-client, it is a configuration file for the
# /etc/init.d/boinc-client init script.

# Set this to 1 to enable and to 0 to disable the init script.
ENABLED="1"

# Set this to 1 to enable advanced scheduling of the BOINC core client and
# all its sub-processes (reduces the impact of BOINC on the system's
# performance).
SCHEDULE="1"

# The BOINC core client will be started with the permissions of this user.
BOINC_USER="boinc"

# This is the data directory of the BOINC core client.
BOINC_DIR="/var/lib/boinc-client"

# This is the location of the BOINC core client, that the init script uses.
# If you do not want to use the client program provided by the boinc-client
# package, you can specify here an alternative client program.
#BOINC_CLIENT="/usr/local/bin/boinc"
BOINC_CLIENT="/usr/bin/boinc"

# Here you can specify additional options to pass to the BOINC core client.
# Type 'boinc --help' or 'man boinc' for a full summary of allowed options.
#BOINC_OPTS="--allow_remote_gui_rpc"
BOINC_OPTS=""

# Scheduling options

# Set SCHEDULE="0" if prefering to run with upstream default priority
# settings.

# Nice levels. When systems are truly busy, e.g. because of too many active
# scientific applications started by the boinc client, there is a chance for
# the boinc client not to be granted sufficient opportunity to check for
# scientific applications to be alive and make the (wrong) decision to
# terminate the scientific app. This is particularly an issue with many
# apps started in parallel on modern multi-core systems and extra overheads
# for the download and uploads of files with the project servers. Another
# concern is the latency for scientific applications to communicate with the
# graphics card, which should be low. All such values should be set and
# controled from within the BOINC client. The Debian init script also sets
# extra constrains via chrt on real time performance and via ionice on 
# I/O performance, which is beyond the regular BOINC client. It then was
# too easy to use that code to also constrain minimal