Bug#930235: libnet 1.1.6 does not call SO_BINDTODEVICE

[YunQiang Su]

> 
> If no objection, I will NMU this package with 10days delay in a
couple of days.
> If any objection, please cancel it.
> 

I just uploaded libnet with 10 days delay with the attached
.debian.tar.xz



libnet_1.3+dfsg-0.1.debian.tar.xz
Description: application/xz-compressed-tar

Bug#930235: libnet 1.1.6 does not call SO_BINDTODEVICE

[YunQiang Su]

On Sat, 8 Jun 2019 20:35:24 -0400 Italo Cunha  wrote:
> Subject: libnet1: libnet 1.1.6 does not call SO_BINDTODEVICE
> Package: libnet1
> Version: 1.1.6+dfsg-3
> Severity: normal
>
> Dear Maintainer,
>
> libnet 1.1.6 only calls setsockopt to bind to a specific device on
> AF_INET6 sockets [1].
>
> This bug is fixed on libnet 1.2 [2] after refactoring socket control
> code.
>

If no objection, I will NMU this package with 10days delay in a couple of days.
If any objection, please cancel it.

> [1] 
> https://github.com/sam-github/libnet/blob/libnet-1.1.6/libnet/src/libnet_raw.c
>
> [2] 
> https://github.com/sam-github/libnet/commit/83c84a92a2c8bd49a7c103c7edfcdc74df4c28e0
>
>
> -- System Information:
> Debian Release: 9.9
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libnet1 depends on:
> ii  libc6  2.24-11+deb9u4
> ii  multiarch-support  2.24-11+deb9u4
>
> libnet1 recommends no packages.
>
> libnet1 suggests no packages.
>
> -- no debconf information
>
>


libnet-1.1.6-1.3.debdiff
Description: Binary data

Bug#1080457: LLVM 19 ftbfs with linker error

[YunQiang Su]

This patch can fix this problem.


llvm toolchain-19.debdiff
Description: Binary data

Bug#1080457: LLVM 19 ftbfs with linker error

[YunQiang Su]

Matthias Klose  于2024年9月4日周三 19:03写道：
>
> Package: src:llvm-toolchain-19
> Version: 1:19.1.0~++rc4-1
> Severity: important
> Tags: sid trixie
> X-Debbugs-CC: debian-m...@lists.debian.org
>
> FAILED: lib/libMLIR.so.19.1
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in f
> unction `mlir::linalg::LinalgDialect::initialize()':
> /usr/lib/gcc/mips64el-linux-gnuabi64/14/../../../../include/c++/14/bits/unique_ptr.h:1076:(.tex
> t._ZN4mlir6linalg13LinalgDialect10initializeEv+0x8c): relocation
> truncated to fit: R_MIPS_CALL1
> 6 against `operator new(unsigned long)@@GLIBCXX_3.4'
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in f
> unction `mlir::linalg::LinalgDialect::initialize()':
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:195:(.text._ZN4mlir6linal
> g13LinalgDialect10initializeEv+0x98): relocation truncated to fit:
> R_MIPS_GOT_DISP against `gua

Another example that requires -mxgot.
I will have a try with -mxgot.

> rd variable for
> mlir::detail::TypeIDResolver void>::resolveTypeI
> D()::id'
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:196:(.text._ZN4mlir6linal
> g13LinalgDialect10initializeEv+0xac): relocation truncated to fit:
> R_MIPS_GOT_DISP against `mli
> r::detail::TypeIDResolver void>::resolveTypeID()::id'
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in f
> unction `mlir::linalg::LinalgDialect::initialize()':
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/IR/Dialect.h:197:(.text._ZN4mlir6linalg13L
> inalgDialect10initializeEv+0xd4): relocation truncated to fit:
> R_MIPS_CALL16 against `mlir::Dia
> lect::addInterface(std::unique_ptr std::default_delete erface> >)'
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in f
> unction `mlir::linalg::LinalgDialect::initialize()':
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:195:(.text._ZN4mlir6linal
> g13LinalgDialect10initializeEv+0xfc): relocation truncated to fit:
> R_MIPS_GOT_DISP against `gua
> rd variable for
> mlir::detail::TypeIDResolver void>::resolveTypeI
> D()::id'
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:196:(.text._ZN4mlir6linal
> g13LinalgDialect10initializeEv+0x118): relocation truncated to fit:
> R_MIPS_GOT_DISP against `ml
> ir::detail::TypeIDResolver void>::resolveTypeID()::id'
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:195:(.text._ZN4mlir6linal
> g13LinalgDialect10initializeEv+0x14c): relocation truncated to fit:
> R_MIPS_GOT_DISP against `guard variable for
> mlir::detail::TypeIDResolver void>::resolveTypeID()::id'
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:196:(.text._ZN4mlir6linalg13LinalgDialect10initializeEv+0x168):
> relocation truncated to fit: R_MIPS_GOT_DISP against
> `mlir::detail::TypeIDResolver void>::resolveTypeID()::id'
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in function `mlir::linalg::LinalgDialect::initialize()':
> /usr/lib/gcc/mips64el-linux-gnuabi64/14/../../../../include/c++/14/bits/stl_pair.h:882:(.text._ZN4mlir6linalg13LinalgDialect10initializeEv+0x1dc):
> relocation truncated to fit: R_MIPS_GOT_DISP against
> `mlir::detail::TypeIDResolver::id'
> tools/mlir/lib/Dialect/Linalg/IR/CMakeFiles/obj.MLIRLinalgDialect.dir/LinalgDialect.cpp.o:
> in function `mlir::linalg::LinalgDialect::initialize()':
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:196:(.text._ZN4mlir6linalg13LinalgDialect10initializeEv+0x1e4):
> relocation truncated to fit: R_MIPS_GOT_DISP against
> `mlir::detail::TypeIDResolver void>::resolveTypeID()::id'
> build-llvm/tools/clang/stage2-bins/mlir/include/mlir/Support/TypeID.h:196:(.text._ZN4mlir6linalg13LinalgDialect10initializeEv+0x220):
> additional relocation overflows omitted from the output
> clang++: error: linker command failed with exit code 1 (use -v to see
> invocation)
>


-- 
YunQiang Su

Bug#1065416: requesting input on recent posts to #1065416

[YunQiang Su]

Helmut Grohne  于2024年8月24日周六 19:20写道：
>
> On Fri, Aug 23, 2024 at 04:08:28PM +0800, Yunqiang Su wrote:
> > I struggled with the build system, and I know the real problem:
>
> Thanks for chiming in!
>
> > 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an 
> > cross toolchain of a port
> > that Debian is not supported yet.  The example is 
> > src:cross-toolchain-base-mipsen.
> > I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6.
> >
> >
> > 2. It is not OK to search base headers when we configure gcc itself.
> > 
> > https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/
> >
> > GCC/configure.ac detects features by the headers of linux/glibc.
> > Let’s have a example: we are building a mips64el cross toolchain on a 
> > amd64 machine:
> >  If gcc/configure.ac sees /usr/include/limits.h before than 
> > /usr/mips64el-linux-gnuabi64/include/limits.h
> > Our mips64el-linux-gnuabi64-gcc will have some problem.
> >
> > And you can find the `fixinclude` in GCC for more information.
>
> I think this is a bad example on multiple levels. For one thing,
> limits.h is glibc and not linux. Then, it is not actually
> architecture-dependent[1] (otherwise it could not be in /usr/include
> directly) and finally, the way gcc deals with limits.h is known broken
> for seven years and has a patch, see see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677.
>

Sure. That's why I think that we should keep kernel headers in
/usr//include for now before that we can be sure that these problem
has been fixed.

> As Bastian pointed out earlier, the exact location of the kernel headers
> is not that important so long as gcc constructs a symlink farm for a
> build-time sysroot. To me, it is not obvious that keeping a non-trivial
> number of linux-libc-dev-$arch-cross packages duplicating content from
> linux-libc-dev is the superior solution to constructing changing the
> build of gcc-cross.
>

One reason I'd prefer to keep the duplicating contents is that we may need to
have cross-toolchains for non debian official ports.

> > @Mattias In fact. The current gcc-X-cross searches /usr/include when 
> > configure, it is dangerous.
> >   --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/  
> > —prefix=/usr
> > Is not good.
> > The prefer way should be `—prefix=/usr` only  with my patch.
>
> Again, I disagree. One of the biggest benefits of multiarch is that you
> get to no longer distinguish between build-time paths from run-time
> paths and always assume your sysroot to be / resulting in a lot of
> simplification. We certainly want all of our cross compilers to search
> /usr/include, so consulting that directory at build time actually makes
> sense from a multiarch point of view. The multiarch way to deal with
> architecture-specific differences (and headers that do not exist for all
> architectures) is to move them to /usr/include/ such that
> /usr/include only ever contains fully architecture-independent headers.
>

Keeping duplicating headers of glibc/linux-kernel won't break multiarch support.

> So this is dangerous in the sense that we still have some
> architecture-dependent headers in /usr/include directly. If you happen
> to know any affected headers, I suggest filing bugs with the owning
> packages and ask them to move them to the triplet subdirectory.
>

The configure.ac of GCC won't try to find headers in multiarch directories.
So if we move all architecture-dependent headers into /usr/include/,
gcc will have some trouble to build itself, especially for multilib support.

That's why gcc-multilib symlinks /usr/include/x86_64-linux-gnu/asm to
/usr/include/asm.

You can have a try to build gcc without gcc-multilib installed with
../configure --target=x86_64-linux-gnu --enable-multilib

Or you can have a try to build cross-gcc with gcc-multilib installed:
   ../configure --target=aarch64-linux-gnu
Then some mistake of feature detection will happen.

Thus it may be the best solution for cross-toolchains to have itself
kernel/glibc headers.

> Helmut
>
> [1] Technically, this is a lie if we consider competing libc
> implementations. As Debian treats the libc as part of the
> architecture, we'd really require gcc's and musl's limits.h to equal
> here, but in reality musl just install theirs to the multiarch.
> However, since musl-linux-any is not bootstrappable, for practical
> matters, limits.h is architecture-independent on reasonable Debian
> architectures including ports.
>


-- 
YunQiang Su

Bug#1065416: requesting input on recent posts to #1065416

[Yunqiang Su]

I struggled with the build system, and I know the real problem:

1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an cross 
toolchain of a port
that Debian is not supported yet.  The example is 
src:cross-toolchain-base-mipsen.
I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6.


2. It is not OK to search base headers when we configure gcc itself.

https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/

GCC/configure.ac detects features by the headers of linux/glibc.
Let’s have a example: we are building a mips64el cross toolchain on a amd64 
machine:
 If gcc/configure.ac sees /usr/include/limits.h before than 
/usr/mips64el-linux-gnuabi64/include/limits.h
Our mips64el-linux-gnuabi64-gcc will have some problem.

And you can find the `fixinclude` in GCC for more information. 


@Mattias In fact. The current gcc-X-cross searches /usr/include when configure, 
it is dangerous.
  --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/  —prefix=/usr
Is not good.
The prefer way should be `—prefix=/usr` only  with my patch.

Bug#1069367: qemu: FTBFS on arm64: build-dependency not installable: gcc-powerpc64-linux-gnu

[YunQiang Su]

> 2024年8月12日 13:49，Michael Tokarev  写道：
> 
> 12.08.2024 08:27, YunQiang Su wrote:
> 
>> Why not submit a bug to src:gcc-14-cross.
> 
> There's no requirement for arch-all packages to be buildable on
> every architecture.  As long as arch-all is built on amd64, I
> see no reason to submit bug reports.
> 

Sure, while arm64 is powerful enough for it now ;)

>> It should be easy to add ppc64 target on host arm64.
> 
> Why arm64, why not all the rest?  Please keep in mind gcc is a
> large thing and requires quite some resources to build, esp.
> on slower architectures.  Basically, amd64 is the fastest we

Arm64 porters are working on trying to do such work.
They requested me to add arm64 support of src:gcc-N-cross-mipsen
years ago.

> have, which also happens to be the most widely used.  As long
> as it works, I wont bother.
> 

So, I guess that the arm64 porters may wish they have ppc64 cross toolchain.

> /mjt
> 
> -- 
> GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
> New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
> ECDF 2C8E
> Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
> 8044 65C5
> Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1069367: qemu: FTBFS on arm64: build-dependency not installable: gcc-powerpc64-linux-gnu

[YunQiang Su]

On Sat, 20 Apr 2024 15:28:18 +0200 Lucas Nussbaum  wrote:
> On 20/04/24 at 15:39 +0300, Michael Tokarev wrote:
> > 20.04.2024 15:33, Lucas Nussbaum wrote:
> > [..]
> > > This is part of a mass rebuild, first building on arm64 and then on
> > > armhf and armel. So I'm not suggesting anything. :-)
> > 
> > Aha.
> > 
> > > Is this failing because the build is trying to build arch:all packages,
> > > that can only be built on amd64? If so, the bug severity could be
> > > lowered, clearly.
> > 
> > Well.  Yes, this is exactly the case.  qemu uses quite a few 
> > cross-compilers to
> > build various firmware components.  This is arch-all package 
> > qemu-system-data.
> > Most of these cross-compilers are available on x86 _only_, including the
> > mentioned gcc-powerpc64-linux-gnu.
> > 
> > I especially made these deps to be in Build-Depends-Indep only, - to be able
> > to (re)build qemu on non-x86 by using `apt --arch-only`.
> > 
> > I can't say this is a bug to begin with, - wrt lowering its severity.  If it
> > is a bug, it's a bug in gcc, not qemu (since it is gcc which does not 
> > provide
> > these cross-compilers on all architectures).  Or in the build environment.
> 
> Sure. The only reason for leaving a bug behind is that, if there had
> been a "FTBFS everywhere except amd64 when building arch-indep
> packages", I would have caught this and not filed this bug. wishlist +
> wontfix would be OK.
> 

Why not submit a bug to src:gcc-14-cross.
It should be easy to add ppc64 target on host arm64.

> Lucas
> 
>

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

[YunQiang Su]

在 2024-08-03星期六的 21:28 +0200，Michael Biebl写道：
> [adding back #1077038 to CC]
> Am 03.08.24 um 17:29 schrieb YunQiang Su:
> > 在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> > > On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne
> > > 
> > > wrote:
> > > > Package: ipwatchd
> > > > Version: 1.3.0-1+nmu1
> > > > Severity: serious
> > > > Justification: do not introduce aliased files into trixie
> > > > X-Debbugs-Cc: YunQiang Su 
> > > > User: helm...@debian.org
> > > > Usertags: dep17m2
> > > > Filename: /lib/systemd/system/ipwatchd.service
> > > > 
> > > > Hi,
> > > > 
> > 
> > I am planing to upload a new version with this debdiff.
> > Any idea?
> 
> Looks ok to me.
> 
> Keep in mind that dh-sequence-movetousr is not a permanent solution.
> 
> Ideally upstream would use pkg-config as outlined by Helmut instead
> of 
> hard-coding /lib/system in src/Makefile

Thanks. I am using pkgconf now.

I just uploaded a new very with this debdiff, and with 5 days delay.
diff -Nru ipwatchd-1.3.0/debian/changelog ipwatchd-1.3.0/debian/changelog
--- ipwatchd-1.3.0/debian/changelog	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/changelog	2024-08-03 23:10:58.0 +0800
@@ -1,3 +1,17 @@
+ipwatchd (1.3.0-1+nmu2) unstable; urgency=medium
+
+  * Bump standard version to 4.7.0.
+  * Patch src/Makefile to install system service to output of
+pkgconf --variable systemdsystemunitdir systemd.
+ - Closes: #1077038
+ - Build depends on systemd-dev, pkgconf.
+  * Rewrite debian/rules with debhelper 7 override style.
+  * Pre-Depends on ${misc:Pre-Depends} instead of hardcoded
+init-system-helpers (>= 1.66).
+  * Refresh patch with -p ab --no-timestamps --no-index. 
+
+ -- YunQiang Su   Sat, 03 Aug 2024 23:10:58 +0800
+
 ipwatchd (1.3.0-1+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ipwatchd-1.3.0/debian/control ipwatchd-1.3.0/debian/control
--- ipwatchd-1.3.0/debian/control	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/control	2024-08-03 23:10:58.0 +0800
@@ -2,13 +2,13 @@
 Section: net
 Priority: optional
 Maintainer: Jaroslav Imrich 
-Build-Depends: debhelper-compat (= 13), libpcap-dev, libnet1-dev
-Standards-Version: 3.9.2
+Build-Depends: debhelper-compat (= 13), libpcap-dev, libnet1-dev, pkgconf, systemd-dev
+Standards-Version: 4.7.0
 Homepage: http://ipwatchd.sf.net
 
 Package: ipwatchd
 Architecture: linux-any
-Pre-Depends: init-system-helpers (>= 1.66)
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: IP conflict detection tool
  IPwatchD is a simple daemon that analyses all incoming ARP packets in order
diff -Nru ipwatchd-1.3.0/debian/patches/fix-cflags.diff ipwatchd-1.3.0/debian/patches/fix-cflags.diff
--- ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-08-03 23:10:58.0 +0800
@@ -1,7 +1,5 @@
-Index: ipwatchd-1.3.0/src/Makefile
-===
 ipwatchd-1.3.0.orig/src/Makefile
-+++ ipwatchd-1.3.0/src/Makefile
+--- a/src/Makefile
 b/src/Makefile
 @@ -1,8 +1,8 @@
  # IPwatchD - IP conflict detection tool for Linux
  # Copyright (C) 2007-2018 Jaroslav Imrich 
diff -Nru ipwatchd-1.3.0/debian/patches/series ipwatchd-1.3.0/debian/patches/series
--- ipwatchd-1.3.0/debian/patches/series	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/patches/series	2024-08-03 23:10:58.0 +0800
@@ -1 +1,2 @@
 fix-cflags.diff
+systemd-service-path.diff
diff -Nru ipwatchd-1.3.0/debian/patches/systemd-service-path.diff ipwatchd-1.3.0/debian/patches/systemd-service-path.diff
--- ipwatchd-1.3.0/debian/patches/systemd-service-path.diff	1970-01-01 08:00:00.0 +0800
+++ ipwatchd-1.3.0/debian/patches/systemd-service-path.diff	2024-08-03 23:10:58.0 +0800
@@ -0,0 +1,30 @@
+Index: yyy/src/Makefile
+===
+--- yyy.orig/src/Makefile
 yyy/src/Makefile
+@@ -44,14 +44,14 @@ distclean: clean
+ 
+ install:
+ 	mkdir -p $(DESTDIR)/etc
+-	mkdir -p $(DESTDIR)/lib/systemd/system
++	mkdir -p $(DESTDIR)/$(SYSTEMD_UNITDIR)
+ 	mkdir -p $(DESTDIR)/usr/sbin
+ 	mkdir -p $(DESTDIR)/usr/share/man/man8
+ 	mkdir -p $(DESTDIR)/usr/share/man/man5
+ 	mkdir -p $(DESTDIR)/usr/share/man/man1
+ 	cp ipwatchd $(DESTDIR)/usr/sbin
+ 	cp ipwatchd-script $(DESTDIR)/usr/sbin
+-	cp ipwatchd.service $(DESTDIR)/lib/systemd/system
++	cp ipwatchd.service $(DESTDIR)/$(SYSTEMD_UNITDIR)
+ 	cp ipwatchd.conf $(DESTDIR)/etc
+ 	cp ../doc/ipwatchd.8.gz $(DESTDIR)/usr/share/man/man8
+ 	cp ../doc/ipwatchd.conf.5.gz $(DESTDIR)/usr/share/man/man5
+@@ -60,7 +60,7 @@ install:
+ uninstall:
+ 	rm $(DESTDIR)/usr/sbin/ipwatchd

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

[YunQiang Su]

在 2024-08-03星期六的 21:00 +0200，Michael Biebl写道：
> Am 03.08.24 um 16:25 schrieb YunQiang Su:
> > 在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> 
> > > I also noticed, that the package added a Pre-Depends on
> > > init-system-helpers (>= 1.66) without a proper explanation why.
> > > 
> > 
> > lintian warned about that when I didn't add it.
> 
> Can you quote the exact lintian warning?
> Which version of lintian did you use?
> 

It was my fault.

The warning was:
skip-systemd-native-flag-missing-pre-depends (does not satisfy init-
system-helpers:any) 

In fact I can use Pre-Depends: ${misc:Pre-Depends} instead of 
 Pre-Depends: init-system-helpers (>= 1.66).

I am using the lintian 2.118.0.


> 
> Regards,
> Michael

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

[YunQiang Su]

在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne 
> wrote:
> > Package: ipwatchd
> > Version: 1.3.0-1+nmu1
> > Severity: serious
> > Justification: do not introduce aliased files into trixie
> > X-Debbugs-Cc: YunQiang Su 
> > User: helm...@debian.org
> > Usertags: dep17m2
> > Filename: /lib/systemd/system/ipwatchd.service
> > 
> > Hi,
> > 

I am planing to upload a new version with this debdiff.
Any idea?
diff -Nru ipwatchd-1.3.0/debian/changelog ipwatchd-1.3.0/debian/changelog
--- ipwatchd-1.3.0/debian/changelog	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/changelog	2024-08-03 23:10:58.0 +0800
@@ -1,3 +1,14 @@
+ipwatchd (1.3.0-1+nmu2) unstable; urgency=medium
+
+  * Build-depends on dh-sequence-movetousr to install systemd service to
+/usr/lib instead of /lib.  Closes: #1077038.
+  * Rewrite debian/rules with debhelper 7 override style.
+  * Pre-Depends on ${misc:Pre-Depends} instead of hardcoded
+init-system-helpers (>= 1.66).
+  * Refresh patch with -p ab --no-timestamps --no-index. 
+
+ -- YunQiang Su   Sat, 03 Aug 2024 23:10:58 +0800
+
 ipwatchd (1.3.0-1+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ipwatchd-1.3.0/debian/control ipwatchd-1.3.0/debian/control
--- ipwatchd-1.3.0/debian/control	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/control	2024-08-03 23:07:12.0 +0800
@@ -2,13 +2,13 @@
 Section: net
 Priority: optional
 Maintainer: Jaroslav Imrich 
-Build-Depends: debhelper-compat (= 13), libpcap-dev, libnet1-dev
+Build-Depends: debhelper-compat (= 13), dh-sequence-movetousr, libpcap-dev, libnet1-dev
 Standards-Version: 3.9.2
 Homepage: http://ipwatchd.sf.net
 
 Package: ipwatchd
 Architecture: linux-any
-Pre-Depends: init-system-helpers (>= 1.66)
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: IP conflict detection tool
  IPwatchD is a simple daemon that analyses all incoming ARP packets in order
diff -Nru ipwatchd-1.3.0/debian/patches/fix-cflags.diff ipwatchd-1.3.0/debian/patches/fix-cflags.diff
--- ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-08-03 23:10:58.0 +0800
@@ -1,7 +1,5 @@
-Index: ipwatchd-1.3.0/src/Makefile
-===
 ipwatchd-1.3.0.orig/src/Makefile
-+++ ipwatchd-1.3.0/src/Makefile
+--- a/src/Makefile
 b/src/Makefile
 @@ -1,8 +1,8 @@
  # IPwatchD - IP conflict detection tool for Linux
  # Copyright (C) 2007-2018 Jaroslav Imrich 
diff -Nru ipwatchd-1.3.0/debian/rules ipwatchd-1.3.0/debian/rules
--- ipwatchd-1.3.0/debian/rules	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/rules	2024-08-03 23:03:12.0 +0800
@@ -1,60 +1,19 @@
 #!/usr/bin/make -f
-# -*- makefile -*-
+include /usr/share/dpkg/buildtools.mk
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all
-
-build: build-stamp
-
-build-stamp: 
-	dh_testdir
-	CPPFLAGS=`dpkg-buildflags --get CPPFLAGS` \
-	CFLAGS="`dpkg-buildflags --get CFLAGS` $$CPPFLAGS" \
-	LDFLAGS=`dpkg-buildflags --get LDFLAGS` \
-	CC=$(DEB_HOST_GNU_TYPE)-gcc \
-	   $(MAKE) -C src
-	touch $@
-
-# Added just to remove lintian warning debian-rules-missing-recommended-target
-build-arch build-indep: build
-
-clean: 
-	dh_testdir
-	dh_testroot
-	rm -f build-stamp configure-stamp
+export DH_VERBOSE = 1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export CC
+
+%:
+	dh $@
+
+override_dh_auto_clean:
 	$(MAKE) -C src distclean
-	dh_clean 
 
-install: build
-	dh_testdir
-	dh_testroot
-	dh_prep  
-	dh_installdirs
+override_dh_auto_build:
+	CFLAGS="$(CFLAGS) $(CPPFLAGS)" $(MAKE) -C src
+
+override_dh_auto_install:
 	$(MAKE) -C src DESTDIR=$(CURDIR)/debian/ipwatchd install
-	# Remove upstream manpages causing lintian error manpage-not-compressed-with-max-compression
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man1/ipwatchd-script.1.gz
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man5/ipwatchd.conf.5.gz
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man8/ipwatchd.8.gz
-
-binary-indep: install
-
-binary-arch: install
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs 
-	dh_installdocs
-	dh_installman debian/ipwatchd.8 debian/ipwatchd.conf.5 debian/ipwatchd-script.1
-	dh_installinit
-	dh_link
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
 
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

[YunQiang Su]

在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne 
> wrote:
> > Package: ipwatchd
> > Version: 1.3.0-1+nmu1
> > Severity: serious
> > Justification: do not introduce aliased files into trixie
> > X-Debbugs-Cc: YunQiang Su 
> > User: helm...@debian.org
> > Usertags: dep17m2
> > Filename: /lib/systemd/system/ipwatchd.service
> > 
> > Hi,
> > 
> > your last upload added /lib/systemd/system/ipwatchd.service, which
> > is an
> > aliased location. We should not add any aliased files to trixie at
> > this
> > time hence filing at rc severity. Please move the unit to /usr. A
> > simple
> > way is adding dh-sequence-movetousr to Build-Depends. Consider
> > doing the
> > move in the upstream build system instead or relying on pkgconf
> > --variable systemdsystemunitdir systemd to provide the target
> > location.
> 
> 
> I also noticed, that the package added a Pre-Depends on 
> init-system-helpers (>= 1.66) without a proper explanation why.
> 

lintian warned about that when I didn't add it.

> Also, you probably should call dh_installsystemd as part of
> debian/rules 

Yes. I guess that we should switch debian/rules to the style of
override_..

> (dh does this automatically for you), to ensure that the service is 
> properly enabled and (re)started.
> 
> Regards,
> Michael

Bug#1070022: libretro-beetle-psx FTBFS on mips64el with -Werror=implicit-function-declaration

[YunQiang Su]

On Sun, 28 Apr 2024 20:00:36 +0300 Adrian Bunk  wrote:
> Source: libretro-beetle-psx
> Version: 0.9.38.6+git20151019-3
> Severity: serious
> Tags: ftbfs patch trixie sid
> 
> https://buildd.debian.org/status/fetch.php?pkg=libretro-beetle-psx&arch=mips64el&ver=0.9.38.6%2Bgit20151019-3%2Bb1&stamp=1714231581&raw=0
> 
> ...
> libretro-common/rthreads/rthreads.c: In function ‘scond_wait_timeout’:
> libretro-common/rthreads/rthreads.c:410:4: error: implicit declaration of 
> function ‘gettimeofday’ [-Werror=implicit-function-declaration]
>   410 |gettimeofday(&tm, NULL);
>   |^~~~
> cc1: some warnings being treated as errors
> make[2]: *** [Makefile:264: libretro-common/rthreads/rthreads.o] Error 1

I see there is some mips specific code in /rthreads.c

#elif defined(xxx__mips__)
   struct timeval tm;

   gettimeofday(&tm, NULL);
   now.tv_sec = tm.tv_sec;
   now.tv_nsec = tm.tv_usec * 1000;
#elif !defined(GEKKO)


I think that is not needed now. Let’s just remove it.

Otherwise, we should include  since gettimeofday needs it.

Bug#1071555: gcc-14: Drop sys-auxv-header.diff

[YunQiang Su]

Package: src:gcc-14

I find that `sys-auxv-header.diff` is not useful now.

In `AC_CHECK_HEADERS`, `sys/auxv.h` is already here, we don't need to add it.

```
/* Define to 1 if you have the  header file. */
#ifndef USED_FOR_TARGET
#undef HAVE_SYS_AUXV_H
#endi
```
is also duplicated.

```
+#ifdef HAVE_SYS_AUXV_H
+# include 
+#endif
```
in driver-rs6000.cc, it is not needed.
AT_NULL does be used, while it is defined in /usr/include/elf.h,
which is included by /usr/include/link.h

Maybe we need a upstream patch to make things clearer, while downstream patch
is not needed now.

Bug#1070678: nproc show different cores count with /proc/cpuinfo

[YunQiang Su]

Package: coreutils
Version: 9.4-3.1

CPU: AMD Ryzen 7 6800U with Radeon Graphics
Kernel version: 6.7.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1
(2024-04-24) x86_64 GNU/Linux


Too save power, I use the attached script to disable CPU cores, and
run it every minute
by cron. It depends `nproc` to determine the count of cores currently.

When the system is idle,  so the CPU cores is 2, and then I start to
build kernel with -j16.
And 2 more cores are enabled soon, while `nproc` always claims that
there are only 2 cores
are enabled.


disable-cores.sh
Description: application/shellscript

Bug#1068365: util-linux: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al

[YunQiang Su]

Chris Hofstaedtler  于2024年4月4日周四 16:27写道：
>
> Source: util-linux
> Version: 2.40-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: debian-m...@lists.debian.org
> Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867
>
> Apparently on mips64el we have a kernel issue that make
> mkfds-multiplexing-{pselect6,poll,ppoll} fail.
> Upstream discussion here: https://github.com/util-linux/util-linux/issues/2867
>
> FlyGoat commented last week:
> > Thanks for reporting, will ask for stable backport after getting this 
> > merged.
>
> MIPS porters, please also check the upstream discussion and if possible
> see if we can get this into the Debian kernels.
>

Yes. I talked with Jiaxun. I think that we should accept this patch to Debian.

> Thanks,
> Chris
>


-- 
YunQiang Su

Bug#1067857: cross-toolchain-base: linux-libc-dev is not installed automatic

[YunQiang Su]

Package: cross-toolchain-base

We does state that libc6-dev-arm64-cross depends on
linux-libc-dev-arm64-cross, while

  apt install libc6-dev-arm64-cross

won't install linux-libc-dev-arm64-cross automatically.

Any ideas?

-- 
YunQiang Su

Bug#1058571: gnupg2: please enable TPM2 support

[YunQiang Su]

Andreas Metzler  于2024年2月3日周六 14:42写道：
>
> On 2024-02-03 YunQiang Su  wrote:
> > On Wed, 13 Dec 2023 11:17:10 +0800 YunQiang Su  wrote:
> >> Package: src:gnupg2
> >> Version: 2.4.3-2
>
> >> TPM2 support has been introduced into GnuPG since 2.3.
> >> https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html
> >>
> >> While TPM2 support is not enabled for Debian's gnupg2 package
> >> in experimental:
> [...]
> > Hi, Andreas
> > I noticed that you have 2 uploads of gnupg 2.4 to experimental in recent 
> > days.
> > Is there any reason that no enabling TPM2 support?
> > Is TPM2 support buggy?
>
> Hello,
>
> I am doing noninvasive minimal changes only, keeping the packaging up to
> date with upstream releases.
>

Thanks. I noticed that Fedora has enabled TPM2 (Intel) support.
I guess it's time for us to do so.

> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

Bug#1058571: gnupg2: please enable TPM2 support

[YunQiang Su]

On Wed, 13 Dec 2023 11:17:10 +0800 YunQiang Su  wrote:
> Package: src:gnupg2
> Version: 2.4.3-2
> 
> TPM2 support has been introduced into GnuPG since 2.3.
> https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html
> 
> While TPM2 support is not enabled for Debian's gnupg2 package
> in experimental:
> 
> https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=i386&ver=2.4.3-2&stamp=1695644413&raw=0
> 
> TPM:   no
> 
>

Hi, Andreas
I noticed that you have 2 uploads of gnupg 2.4 to experimental in recent days.
Is there any reason that no enabling TPM2 support?
Is TPM2 support buggy?

Bug#1052345: src:binutils-mipsen: fails to migrate to testing for too long: FTBFS

[YunQiang Su]

It's now buildable.

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Guilhem Moulin  于2023年12月31日周日 21:50写道：
>
> On Sun, 31 Dec 2023 at 21:22:36 +0800, YunQiang Su wrote:
> >> Is there any reason to not just use systemd-cryptenroll?
> >
> > Yes. I tried to use systemd-cryptenroll, while it cannot work with
> > cryptsetup-suspend.
> > I need a way to suspend or hibernate without disks decrypted.
>
> Seems like this should be a wishlist bug against cryptsetup-suspend not
> an ITP.  I don't foresee any reason why this wouldn't work once #1023700
> and #1031254 are fixed.
>

systemd-cryptsetup doesn't have suspend support.
cryptsetup-suspend will fails.
I tried with "systemd-cryptsetup detach", while it is not allowed for a using
system.

> > The passphrase is stored in /var/cache, and switch_root will clean
> > all of them, so I guess it won't leak.
>
> The partition might be backed by plain-test drives or similar, so it
> can't be used to write sensitive data.
>

This script will only in initramfs, so /var/cache will always be an ramfs.

> --
> Guilhem.

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Guilhem Moulin  于2023年12月31日周日 21:23写道：
>
> Hi,
>
> On Sun, 31 Dec 2023 at 18:49:30 +0800, YunQiang Su wrote:
> > 2 mthods are supported for 2 FA:
> > - Yubikey Challenge
> > - TPM2 Keypair
>
> If your concern is to make these work with cryptsetup-initramfs, there
> are #1023700 and #1031254 open against src:cryptsetup.  The plan is to

I tried some methods before I write this script, and I also tried dracut.
Yes, dracut works well with cryptsetup-initramfs.

The problem for me is that none of these ways, can work with suspend.
I mean that when the PC resumes from suspend, I wish that the disk is
encrypted instead of decrypted.

In fact, hibernate is an option for me, but currently, Linux kernel cannot
support hibernate if crypt disk is used.

> have that in trixie.  Did you check if the solutions proposed there
> cover your use case?  Otherwise, IMHO a wishlist bug against
> src:cryptsetup would be better than using a separate source package.
>

If this scripts can be accepted into src:cryptset, I will be very glad to
help it happen.
Yes, I noticed  cryptsetup-suspend does in src:cryptsetup, while
src:yubikey-luks is a seperate source package.

I tried src:yubikey-luks, while it leaks some features, and upstream
seems not active now.
https://github.com/cornelinux/yubikey-luks/pull/92

> > PIN-less is also supported, if the PINs are present in
> > /etc/cryptsetup/2fa.conf.
>
> I'm not really thrilled to see /etc/cryptsetup (and /lib/cryptsetup)
> used outside src:cryptsetup.  These directories are not documented as
> drop-in.
>
> --
> Guilhem.

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Ansgar  于2023年12月31日周日 20:51写道：
>
> On Sun, 2023-12-31 at 18:49 +0800, YunQiang Su wrote:
> > * Package name: cryptsetup-2fa
> >   Version : 0.1
> >   Upstream Contact: YunQiang Su 
> > * URL : https://github.com/wzssyqa/cryptsetup-2fa/
> > * License : BSD-2
> >   Programming Lang: SHELL
> >   Description : 2FA plugin for cryptsetup
> >
> > 2 mthods are supported for 2 FA:
> >   - Yubikey Challenge
> >   - TPM2 Keypair
> > PIN-less is also supported, if the PINs are present in
> > /etc/cryptsetup/2fa.conf.
> >
> > Since I am not expert of security and encrypt:
> > CODE Review is requested here, too.
>
> Is there any reason to not just use systemd-cryptenroll?

Yes. I tried to use systemd-cryptenroll, while it cannot work with
cryptsetup-suspend.
I need a way to suspend or hibernate without disks decrypted.

> It seems to be a more featureful implementation and also doesn't
> require storing PINs in plain text in configuration files like

My script doesn't *require* storing PIN.
You can just leave the config blank, it will prompt for PIN.

> /etc/cryptsetup/2fa/2fa.conf as README instructs users to do here.
> Nor does it store plain text credentials in /var/cache.
>

This is used, if a user has multi disks/partitions, and all of them have
same PIN, to ask for PIN only one time.

The passphrase is stored in /var/cache, and switch_root will clean
all of them, so I guess it won't leak.

> Ansgar
>
> PS: I also don't understand why cryptsetup-2fa-enroll(1) references
> privacyIDEA.

Thanks. Removed.

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Marco d'Itri  于2023年12月31日周日 19:27写道：
>
> On Dec 31, YunQiang Su  wrote:
>
> >   Upstream Contact: YunQiang Su 
> > * URL : https://github.com/wzssyqa/cryptsetup-2fa/
> What are the benefits of this compared to systemd-cryptenroll?
>

systemd-cryptenroll cannot work with cryptsetup-suspend.


> --
> ciao,
> Marco

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 
X-Debbugs-Cc: debian-de...@lists.debian.org, s...@debian.org

* Package name: cryptsetup-2fa
  Version : 0.1
  Upstream Contact: YunQiang Su 
* URL : https://github.com/wzssyqa/cryptsetup-2fa/
* License : BSD-2
  Programming Lang: SHELL
  Description : 2FA plugin for cryptsetup

2 mthods are supported for 2 FA:
  - Yubikey Challenge
  - TPM2 Keypair
PIN-less is also supported, if the PINs are present in
/etc/cryptsetup/2fa.conf.

Since I am not expert of security and encrypt:
CODE Review is requested here, too.

Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

[YunQiang Su]

Package: src:gnupg2
Version: 2.4.3-2

> gpg --quick-generate-key "A User " rsa2048  
>   
>   ~
gpg: directory '/home//.gnupg' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: error writing public keyring '[keyboxd]': Attempt to write a
readonly SQL database
Key generation failed: Attempt to write a readonly SQL database

The problem is due to when create gnupg 2.4+ will add a "common.conf"
in new created ~/.gnupg directory, with "use-keyboxd", while keyboxed
is not enabled on Debian yet.
https://github.com/gpg/gnupg/blob/master/README

-- 
YunQiang Su

Bug#1058571: gnupg2: please enable TPM2 support

[YunQiang Su]

Package: src:gnupg2
Version: 2.4.3-2

TPM2 support has been introduced into GnuPG since 2.3.
https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html

While TPM2 support is not enabled for Debian's gnupg2 package
in experimental:

https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=i386&ver=2.4.3-2&stamp=1695644413&raw=0

TPM:   no

Bug#1057628: im-config: support zsh as login shell and wayland env

[YunQiang Su]

Package: src:im-config
Version: 0.57-2
Control: block -1 by 1057627

1. For wayland, gnome-session use $SHELL to restart.
https://salsa.debian.org/gnome-team/gnome-session/-/commit/5fee64f74925291f211f289dcfb3f1cf522c1546
2. im-config contains a file: /etc/profile.d/im-config_wayland.sh
to start input method in wayland env.
3. If zsh is set to login shell, the input method won't start,
since zsh doesn't use /etc/profile.


Please put a symlink of /etc/profile.d/im-config_wayland.sh
to /etc/zsh/zlogin.d/im-config_wayland.sh

Bug#1057627: zsh: add /etc/zsh/zlogin.d directory

[YunQiang Su]

Package: src:zsh
Version: 5.9-5

Please add an /etc/zsh/zlogin.d directory and add something like

if [ -d /etc/zsh/zlogin.d ]; then
  for i in /etc/zsh/zlogin.d/*.sh; do
if [ -r $i ]; then
  . $i
fi
  done
  unset i
fi

Bash does this in /etc/profile, so that other packages can put
some init scripts here.

Background:
1. For wayland, gnome-session use $SHELL to restart.
https://salsa.debian.org/gnome-team/gnome-session/-/commit/5fee64f74925291f211f289dcfb3f1cf522c1546
2. im-config contains a file: /etc/profile.d/im-config_wayland.sh
to start input method in wayland env.
3. If zsh is set to login shell, the input method won't start,
since zsh doesn't use /etc/profile.

Bug#1049455: Binutils: mips-gold patch was refreshed incorrectly

[YunQiang Su]

>
> is the debian/patches/gold-mips patch still needed?

For Debian, we can remove it now.
The only problem is that the default output of gold will be always o32,
but it won't be a problem for us: ld is merely called directly,
and gold is not the default ld.

> If yes, please could
> you submit this upstream?
>

Yes. I submitted, while it is waiting for approval of gold maintainers.

Bug#1049455: Binutils: mips-gold patch was refreshed incorrectly

[YunQiang Su]

Matthias Klose  于2023年10月12日周四 14:29写道：
>
> On 04.10.23 01:10, YunQiang Su wrote:
> > On Fri, 18 Aug 2023 09:48:44 +0200 Matthias Klose  wrote:
> >> Control: tags -1 + moreinfo
> >>
> >> please get that accepted upstream, and then backported to the 2.41 branch.
> >
> > I think that we can use '--enable-targets=all’ for all mips ports:
>
> no, --enable-targets=all has other issues. And it wouldn't be orthogonal to 
> the
> other architectures.
>
> please get this addressed upstream, and then backported to the 2.41 branch.
>

http://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c27eff41737c95a84c01bd1f498931ad2323141c
http://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=eb49941e7e16bfcd71bd76544c84bf347b03e64f

Patches have been back-ported.
This problem may be solved with the next binutils uploading.

>

Bug#1056116: llvm-toolchain-17 ftbfs on mips64el

[YunQiang Su]

On Fri, Nov 17, 2023 at 09:28:38AM +0100, Sylvestre Ledru wrote:

> 
> We (llvm) moved to github for contributions
> 
> please move the review request on this platform
> 
The red banner on Phabricator tells us don't do so.

Bug#1056116: llvm-toolchain-17 ftbfs on mips64el

[YunQiang Su]

On Fri, Nov 17, 2023 at 09:05:22AM +0100, Matthias Klose wrote:
> Package: src:llvm-toolchain-17
> Version: 1:17.0.5-1
> Severity: important
> Tags: sid trixie
> X-Debbugs-CC: debian-m...@lists.debian.org
> 
> see
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17&arch=mips64el&ver=1%3A17.0.3-1%7Eexp1&stamp=1697551933&raw=1
> 
> FAILED: 
> /<>/build-llvm/lib/clang/17/lib/linux/libclang_rt.asan-mips64el.so
> 
> [...]
> compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.mips64el.dir/asan_interceptors.cpp.o:
> in function `pthread_getschedparam':
> asan_interceptors.cpp:(.text+0x460): relocation truncated to fit:
> R_MIPS_PC16 against `__interceptor_pthread_getschedparam'
> compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.mips64el.dir/asan_interceptors.cpp.o:
> in function `getaddrinfo':
> asan_interceptors.cpp:(.text+0x468): relocation truncated to fit:
> R_MIPS_PC16 against `__interceptor_getaddrinfo'
> [...]
>

https://reviews.llvm.org/D158491
The patch is awaiting for approval by upstream.

Bug#1055909: VIM: adding "set mouse=" into /etc/vim/vimrc doesn't work

[YunQiang Su]

Package: src:vim
Version: 2:9.0.2103-1

In general, I love the default settings of VIM, while "set mount=a" is
an exception.
So I try to add "set mount=" in to /etc/vim/vimrc or /etc/vim/vimrc.local,
but it doesn't work.

With `vim -V xx.txt`, it shows that the /etc/vim/vimrc is sourced very
earlier than files in
/usr/share/vim. Maybe, it is the real problem.

Yes, I can add "~/.vimrc", while with this file exists, some other
config is missing,
like setting curse postion to the last edit.

Bug#1049455: Binutils: mips-gold patch was refreshed incorrectly

[YunQiang Su]

On Fri, 18 Aug 2023 09:48:44 +0200 Matthias Klose  wrote:
> Control: tags -1 + moreinfo
> 
> please get that accepted upstream, and then backported to the 2.41 branch.

I think that we can use '--enable-targets=all’ for all mips ports:

diff --git a/debian/rules b/debian/rules
index 7a5d4f5..5b133c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -531,29 +531,29 @@ CONFARGS_TARGET_riscv64   = --with-isa-spec=2.2
 
 CONFARGS_TARGET_kfreebsd-i386  = --enable-targets=x86_64-kfreebsd-gnu
 
-CONFARGS_TARGET_mips   = 
--enable-targets=mips64-linux-gnuabi64,mips64-linux-gnuabin32
+CONFARGS_TARGET_mips   = --enable-targets=all
 
-CONFARGS_TARGET_mipsel = 
--enable-targets=mips64el-linux-gnuabi64,mips64el-linux-gnuabin32 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mipsel = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mipsn32= 
--enable-targets=mips64-linux-gnuabi64,mips-linux-gnu
+CONFARGS_TARGET_mipsn32= --enable-targets=all
 
-CONFARGS_TARGET_mipsn32el  = 
--enable-targets=mips64el-linux-gnuabi64,mipsel-linux-gnu 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mipsn32el  = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mips64 = 
--enable-targets=mips64-linux-gnuabin32,mips-linux-gnu
+CONFARGS_TARGET_mips64 = --enable-targets=all
 
-CONFARGS_TARGET_mips64el   = 
--enable-targets=mips64el-linux-gnuabin32,mipsel-linux-gnu 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mips64el   = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mipsr6 = 
--enable-targets=mipsisa64r6-linux-gnuabi64,mipsisa64r6-linux-gnuabin32
+CONFARGS_TARGET_mipsr6 = --enable-targets=all
 
-CONFARGS_TARGET_mipsr6el   = 
--enable-targets=mipsisa64r6el-linux-gnuabi64,mipsisa64r6el-linux-gnuabin32
+CONFARGS_TARGET_mipsr6el   = --enable-targets=all
 
-CONFARGS_TARGET_mipsn32r6  = 
--enable-targets=mipsisa64r6-linux-gnuabi64,mipsisa32r6-linux-gnu
+CONFARGS_TARGET_mipsn32r6  = --enable-targets=all
 
-CONFARGS_TARGET_mipsn32r6el= 
--enable-targets=mipsisa64r6el-linux-gnuabi64,mipsisa32r6el-linux-gnu
+CONFARGS_TARGET_mipsn32r6el= --enable-targets=all
 
-CONFARGS_TARGET_mips64r6   = 
--enable-targets=mipsisa64r6-linux-gnuabin32,mipsisa32r6-linux-gnu
+CONFARGS_TARGET_mips64r6   = --enable-targets=all
 
-CONFARGS_TARGET_mips64r6el = 
--enable-targets=mipsisa64r6el-linux-gnuabin32,mipsisa32r6el-linux-gnu
+CONFARGS_TARGET_mips64r6el = --enable-targets=all
 
 CONFARGS_TARGET_aarch64= --enable-targets=aarch64_be-linux-gnu
 

Bug#1050432: rpy2: FTBFS on mips64el

[YunQiang Su]

Dirk Eddelbuettel  于2023年8月27日周日 16:52写道：
>
>
> On 27 August 2023 at 14:09, YunQiang Su wrote:
> | Dirk Eddelbuettel  于2023年8月27日周日 00:15写道：
> | >
> | >
> | > Hi all,
> | >
> | > As the test failures for complex valued variables appeared to be systemic 
> on
> | > the 'mips64el' platform, I buckled down, taught myself some Python ==:-) 
> and
> | > conditioned the number of failing tests away via
> | >
> | >   @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 
> 'little',
> | >   reason="Complex tests fails for 'mips64el'.")
> | >
> | > Maybe the porters team can shed some light on why we needed it, and if 
> this
> | > worked (the autobuilders will tell us soon enough) I can pass the patch 
> on to
> | > Laurent for a possible inclusion upstream.
> | >
> |
> | Sorry for the late reply. I can work on it.
>
> Appreciate that!
>
> (While my fix corrected the build, it is a stop-gap as it avoids the issue. A
> real fix would be good.)
>
> | Do you knwo any way to run a single testcase?
>
> Can you start from the unit tests I conditioned out?  Each of those has
> simple expression with a complex in it. Those should be executable directly
> in the Python interpreter. You probably need all the build-deps (python, R,
> rpy2, numpy, ...) installed.
>

Maybe there is something wrong with ffi. (In fact the complex support of mips
was added by me. ;)

I am looking for a way to use debug to debug the extensions.
If you have any documents, can you point it to me.

> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



-- 
YunQiang Su

Bug#1050432: rpy2: FTBFS on mips64el

[YunQiang Su]

Dirk Eddelbuettel  于2023年8月27日周日 00:15写道：
>
>
> Hi all,
>
> As the test failures for complex valued variables appeared to be systemic on
> the 'mips64el' platform, I buckled down, taught myself some Python ==:-) and
> conditioned the number of failing tests away via
>
>   @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 
> 'little',
>   reason="Complex tests fails for 'mips64el'.")
>
> Maybe the porters team can shed some light on why we needed it, and if this
> worked (the autobuilders will tell us soon enough) I can pass the patch on to
> Laurent for a possible inclusion upstream.
>

Sorry for the late reply. I can work on it.
Do you knwo any way to run a single testcase?

> Cheers,  Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>


-- 
YunQiang Su

Bug#1050431: binutils-mipsen: FTBFS on all architectures

[YunQiang Su]

Paul Gevers  于2023年8月24日周四 22:51写道：
>
> Source: binutils-mipsen
> Version: 10+c4
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> Control: block 1040626 by -1
>
> Dear maintainer,
>
> The latest upload of binutils-mipsen failed to build from source on
> all architectures. Apart from this being an issue by itself, it's also
> blocking progress in other RC bugs.
>
> https://buildd.debian.org/status/package.php?p=binutils-mipsen&ver=10

It is blocked by
#1049455 - Binutils: mips-gold patch was refreshed incorrectly
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049455

I am also working on it upstream:
[PATCH v3 1/2] Gold/MIPS: Improve MIPS support in configure.tgt (sourceware.org)
https://sourceware.org/pipermail/binutils/2023-August/129118.html

>
> Paul
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
YunQiang Su

Bug#1049993: gcc: add symlink for path with vendored-triple

[YunQiang Su]

Package: src:gcc-13
Version: 13.2.0-4

Can we consider adding a symlink from non-vendor triples to vendored triples?
For example:
 /usr/lib/gcc/x86_64-linux-gnu -> /usr/lib/gcc/x86_64-unknown-linux-gnu

LLVM guys complains about it:
https://reviews.llvm.org/D158183#4596086



-- 
YunQiang Su

Bug#1049455: Binutils: mips-gold patch was refreshed incorrectly

[YunQiang Su]

Package: src:binutils
Version: 2.41-4

It makes binutils-mipsen fails to build:
https://buildd.debian.org/status/fetch.php?pkg=binutils-mipsen&arch=amd64&ver=10%2Bc5&stamp=1692086940&raw=0

See: https://sourceware.org/pipermail/binutils/2023-August/129043.html

Please use this patch,

diff --git a/gold/configure.tgt b/gold/configure.tgt
index 4b54e08d27f..d09bb76ef02 100644
--- a/gold/configure.tgt
+++ b/gold/configure.tgt
@@ -153,13 +153,27 @@ aarch64*-*)
  targ_big_endian=false
  targ_extra_big_endian=true
  ;;
-mips*el*-*-*|mips*le*-*-*)
+mips64*el*-*-* | mipsisa64*le*-*-*)
+ targ_obj=mips
+ targ_machine=EM_MIPS_RS3_LE
+ targ_size=64
+ targ_big_endian=false
+ targ_extra_big_endian=true
+ ;;
+mips*el*-*-*)
  targ_obj=mips
  targ_machine=EM_MIPS_RS3_LE
  targ_size=32
  targ_big_endian=false
  targ_extra_big_endian=true
  ;;
+mips64*-*-* | mipsisa64*-*-*)
+ targ_obj=mips
+ targ_machine=EM_MIPS
+ targ_size=64
+ targ_big_endian=true
+ targ_extra_big_endian=false
+ ;;
 mips*-*-*)
  targ_obj=mips
  targ_machine=EM_MIPS

-- 
YunQiang Su

Bug#1043274: kernel handbook: mention dpkg-architecture

[YunQiang Su]

Package: debian-kernel-handbook
Version: 1.0.21

In
 4.5.5. Building packages for one flavour
It should mention that we can use dpkg-architecture to support cross-building:

For example we can:

dpkg-architecture -a mips64el -c \
make -f debian/rules.gen \
binary-arch_mips64el_none_loongson-3



-- 
YunQiang Su

Bug#1043114: Please remove mipsel port from testing and sid

[YunQiang Su]

Package: ftp.debian.org
X-Debbugs-CC: debian-m...@lists.debian.org, d...@debian.org,
debian-rele...@lists.debian.org

Since the Y2038 problem, 2G user space memory limit,
and some lack of manpower,  It's time for us to drop mipsel support
from the list of official release architectures.

Note: please keep mips64el for now.

-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

Ohh, Mozjs102 is using WASM now, which generates some MIPS SIMD instructions.
Interestingly, Let's try to rebuild mozjs102 with llvm-15, and then
maybe llvm-16.
I may need to help fix llvm-toolchain-16/snapshot first.


-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

Simon McVittie  于2023年8月4日周五 22:20写道：
>
> On Fri, 04 Aug 2023 at 13:21:59 +0100, Simon McVittie wrote:
> > On Fri, 04 Aug 2023 at 20:05:20 +0800, YunQiang Su wrote:
> > > I am continue working on (EE) failed to write to Xwayland fd: Broken
> > > pipe problem.
>
> I notice that the perf-* tests are new in version 44, so if the equivalent
> functionality had been failing on mips*el before, we wouldn't know.
>

It's due to another segfault. I am digging it.

> Can you confirm whether gnome-shell/unstable works on a mips*el desktop
> system?
>
> If that works, please try building
> https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71 with
> DEB_BUILD_OPTIONS=nocheck: does that work or crash on a mips*el desktop?
>

I will have a try tomorrow.

> Thanks
> smcv



-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

YunQiang Su  于2023年8月4日周五 19:40写道：
>
> Simon McVittie  于2023年8月4日周五 19:26写道：
> >
> > Control: forwarded -1 
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6877
> >
> > On Fri, 04 Aug 2023 at 15:50:32 +0800, YunQiang Su wrote:
> > > 156   if (rpath)
> > > 157 paths = g_strsplit (strtab + rpath->d_un.d_val, ":", -1);
> > > 158   else
> > > 159 paths = g_strsplit (strtab + runpath->d_un.d_val, ":", -1);
> > >  // <- segfault here due to
> >
> > Thanks, that's very useful information.
> >
> > After some printf debugging on eller, I think what is happening here is
> > that GNOME Shell is assuming that the d_un.d_val of the DT_STRTAB is
> > an absolute pointer, but on mips64el for whatever reason it's only an
> > offset, and it needs to be added to the base address of the executable
> > to get a real pointer.
> >
> > If I understand correctly, the value in the header in the binary on-disk
> > is just an offset, and on most architectures the dynamic linker overwrites
> > the offset with (base_address + offset) during loading/relocation - but
> > for whatever reason, mips64el isn't doing that.
> >
>
> Yes. It is this case. I guess it should be a glibc's bug, while during years,
> it is a feature now (;
> We cannot change this behaviour now.
>
> I am working on a patch for it, the real base address can be get by:
> ((getauxval(AT_PHDR) >> 8) <<8)
>
> > Instead of doing this low-level ELF manipulation, I'm testing a patch which
> > uses an environment variable to propagate the search path into the
> > executable - that seems less likely to go wrong on unusual architectures.
> >
> > smcv
>

FYI: this patch can fix the segfault problem in
maybe_add_rpath_introspection_paths

--- gnome-shell-44.3.orig/src/main.c
+++ gnome-shell-44.3/src/main.c
@@ -7,6 +7,7 @@
 #endif
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -129,6 +130,7 @@ shell_dbus_init (gboolean replace)
 }

 #ifdef HAVE_EXE_INTROSPECTION
+__attribute__((optimize("O0")))
 static void
 maybe_add_rpath_introspection_paths (void)
 {
@@ -150,6 +152,15 @@ maybe_add_rpath_introspection_paths (voi
 strtab = (const char *) dyn->d_un.d_val;
 }

+#if defined(__mips)
+  /* The d_val of DT_STRTAB, contains the offset of .dynstr
+   * and the start of elf is loaded, instead of absolute address.
+   * getauxval(AT_PHDR) is near enough with the start, and we are sure
+   * that the elf will be loaded page-aligned.
+   */
+  strtab = strtab + ((getauxval(AT_PHDR) >> 8) << 8);
+#endif
+
   if ((!rpath && !runpath) || !strtab)
 return;


I am continue working on (EE) failed to write to Xwayland fd: Broken
pipe problem.

>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

Simon McVittie  于2023年8月4日周五 19:26写道：
>
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6877
>
> On Fri, 04 Aug 2023 at 15:50:32 +0800, YunQiang Su wrote:
> > 156   if (rpath)
> > 157 paths = g_strsplit (strtab + rpath->d_un.d_val, ":", -1);
> > 158   else
> > 159 paths = g_strsplit (strtab + runpath->d_un.d_val, ":", -1);
> >  // <- segfault here due to
>
> Thanks, that's very useful information.
>
> After some printf debugging on eller, I think what is happening here is
> that GNOME Shell is assuming that the d_un.d_val of the DT_STRTAB is
> an absolute pointer, but on mips64el for whatever reason it's only an
> offset, and it needs to be added to the base address of the executable
> to get a real pointer.
>
> If I understand correctly, the value in the header in the binary on-disk
> is just an offset, and on most architectures the dynamic linker overwrites
> the offset with (base_address + offset) during loading/relocation - but
> for whatever reason, mips64el isn't doing that.
>

Yes. It is this case. I guess it should be a glibc's bug, while during years,
it is a feature now (;
We cannot change this behaviour now.

I am working on a patch for it, the real base address can be get by:
((getauxval(AT_PHDR) >> 8) <<8)

> Instead of doing this low-level ELF manipulation, I'm testing a patch which
> uses an environment variable to propagate the search path into the
> executable - that seems less likely to go wrong on unusual architectures.
>
> smcv



-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

>
> I will try to debug it.
>

With the first glance, it seems due to some difference of MIPS ELF format:
131 #ifdef HAVE_EXE_INTROSPECTION
132 static void
133 maybe_add_rpath_introspection_paths (void)
134 {
135   ElfW (Dyn) *dyn;
136   ElfW (Dyn) *rpath = NULL;
137   ElfW (Dyn) *runpath = NULL;
138   const char *strtab = NULL;
139   g_auto (GStrv) paths = NULL;
140   g_autofree char *exe_dir = NULL;
141   GStrv str;
142
143   for (dyn = _DYNAMIC; dyn->d_tag != DT_NULL; dyn++)
144 {
145   if (dyn->d_tag == DT_RPATH)
146 rpath = dyn;
147   else if (dyn->d_tag == DT_RUNPATH)
148 runpath = dyn;
149   else if (dyn->d_tag == DT_STRTAB)
150 strtab = (const char *) dyn->d_un.d_val;
151 }
152
153   if ((!rpath && !runpath) || !strtab)
154 return;
155
156   if (rpath)
157 paths = g_strsplit (strtab + rpath->d_un.d_val, ":", -1);
158   else
159 paths = g_strsplit (strtab + runpath->d_un.d_val, ":", -1);
 // <- segfault here due to
160
161   if (!paths)
162     return;

We are continuing to find the real problem.

-- 
YunQiang Su

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

Simon McVittie  于2023年8月4日周五 00:33写道：
>
> Source: gnome-shell
> Version: 44.3-1
> Severity: serious
> Tags: ftbfs experimental help
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: debian-m...@lists.debian.org
> User: debian-m...@lists.debian.org
> Usertags: mips64el mipsel
>
> gnome-shell 44 builds successfully on all release architectures except
> mips*el, but fails to build on mips*el. The three perf-* unit tests fail
> with exit status 1 and no obvious error messages:
> <https://buildd.debian.org/status/fetch.php?pkg=gnome-shell&arch=mips64el&ver=44.3-1&stamp=1688819000&raw=0>
> <https://buildd.debian.org/status/fetch.php?pkg=gnome-shell&arch=mipsel&ver=44.3-1&stamp=1688798824&raw=0>
>
> At the moment this is only in experimental, but we want to upload it to
> unstable soon, as part of the libmutter-12-0 transition
> <https://release.debian.org/transitions/html/auto-mutter.html>.
>

I will try to debug it.

> Is gnome-shell practically useful on mips-based hardware, or does it
> have hardware requirements that the mips family do not meet in practice?
> If nobody really uses it on mips*el, it might be better to do
> architecture-specific removals rather than attempting to debug and fix it.
>
> Or, if the mips porting team can confirm that GNOME 43 works in practice
> as a desktop environment on mips*el hardware, then it would be useful

Yes. There are some MIPS desktop cases.

> to try GNOME 44 from experimental on the same hardware (after building
> gnome-shell locally with DEB_BUILD_OPTIONS=nocheck) to check whether
> this is a practical problem.
>
> Thanks,
> smcv
>


-- 
YunQiang Su

Bug#1040621: binutils-mipsen: missing shlib dependencies

[YunQiang Su]

Adam Borowski  于2023年7月8日周六 11:36写道：
>
> Source: binutils-mipsen
> Version: 10+c3
> Severity: grave
> Justification: renders package unusable
>
> mips* binutils tools crash on startup:
> $ mips64el-linux-gnuabi64-as
> mips64el-linux-gnuabi64-as: error while loading shared libraries: 
> libsframe.so.0: cannot open shared object file: No such file or directory
>
> The culprit is:
> $ ldd /usr/lib/x86_64-linux-gnu/libopcodes-2.40.50-mips64el.20230611.so
> libsframe.so.0 => not found
> which would be prevented by package relationships/DAK/etc, had the
> dependency on libsframe be included in binaries you produce.
>

It seems that just rebuilding can solve this problem.
I will upload a new version.

>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
> (120, 'experimental'), (1, 'experimental-debug')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)



-- 
YunQiang Su

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[YunQiang Su]

Aurelien Jarno  于2023年5月6日周六 04:30写道：
>
> Source: linux
> Version: 5.10.178-3
> Severity: important
> X-Debbugs-Cc: d...@debian.org, debian-m...@lists.debian.org, s...@debian.org
>
> Following the point release, the buildd mipsel-osuosl-03.d.o does not
> boot anymore, with errors in the AHCI controller:
>
> [   35.912147] ata4.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action 
> 0x6 frozen
> [   35.919769] ata4.00: failed command: WRITE FPDMA QUEUED
> [   35.924968] ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 29 ncq 
> dma 16384 out
> [   35.924968]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
> (timeout)
> [   35.940097] ata4.00: status: { DRDY }
> [   35.943743] ata4: hard resetting link
>
> While that initially looks like a hardware issue, it appears that
> reverting the kernel to 5.10.162-1 (from 5.10.178-3) fixes the issue.
> Strangely mipsel.osuosl-05.d.o, which seems to be similar hardware (CPU,
> motherboard and SATA drive), does not exhibit the same issue.
>

Maybe the different firmwares are used for them...
CCed Huacai and Jiaxun.

> You'll find attached the output of /proc/cpuinfo, lspci and the full
> boot log.



-- 
YunQiang Su

Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el

[YunQiang Su]

Paul Gevers  于2023年4月27日周四 04:26写道：
>
> Hi mips porters,
>
> On Fri, 24 Feb 2023 23:10:29 + James Addison  wrote:
> > Source: gcc-11
> > Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
> >
> > Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is 
> > the
> > upstream report matching this bug.  I found it from a related GitHub 
> > issue[1]
> > for matplotlib.
> >
> > The GCC bug reporter has done some work to create a minimal reproducer case.
> > Could you check whether the issue reported there is the same one as here?  
> > (I
> > will do eventually, but am not familiar with C and do not have mips hardware
> > available so it may take some time)
> >
> > [1] - https://github.com/matplotlib/matplotlib/issues/21789
>
> We're you ever made aware of this bug in gcc-11 and gcc-12? Maybe a bit
> of your help is appropriate.
>

Sorry about that I forget this bug...
I will dig it.

> Paul



-- 
YunQiang Su

Bug#1030740: gcc: update-patches target doesn't recognize env

[YunQiang Su]

Package: src:gcc-13

the `update-patches` target in debian/rules.patches doesn't use the env
   QUILT_REFRESH_ARGS="--no-timestamps --no-index -pab"
   QUILT_DIFF_ARGS="--no-timestamps --no-index -pab"
 passed to it.

The fellow changes seems work well.

update-patches: $(series_stamp)
   export QUILT_PATCHES=$(patchdir); \
   export QUILT_REFRESH_ARGS="--no-timestamps --no-index -pab"; \
   export QUILT_DIFF_ARGS="--no-timestamps --no-index -pab"; \
-   while quilt push; do quilt refresh; done
+. while quilt push; do quilt refresh --no-timestamps --no-index -pab; done


PS: is it a good idea to run `quilt pop -a` before refresh patches?

--
YunQiang Su

Bug#1030568: src:cross-toolchain-base-mipsen: fails to migrate to testing for too long: unsatisfiable Build-Depends

[YunQiang Su]

Paul Gevers  于2023年2月5日周日 15:03写道：
>
> Source: cross-toolchain-base-mipsen
> Version: 21
> Severity: serious
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
> Dear maintainer(s) and mips* porter(s),
>
> Please consider this an official warning for the mipsel and mips64el
> ports. Several key packages that are specific for mips* are behind in
> testing for way too long (bug #1023706, #1026129, #1026128) and so far
> I've only seen action after reminders.
>
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 60 days as having a Release Critical bug in
> testing [1]. Your package src:cross-toolchain-base-mipsen has been
> trying to migrate for 61 days [2]. Hence, I am filing this bug. Your
> package has a Build-Depends on linux-source-6.0 but that's no longer the
> linux version in testing.
>
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
>

Sorry for the delay. I will do so in future.
And I will set up an CI to do so.

> Paul
>
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=cross-toolchain-base-mipsen



-- 
YunQiang Su

Bug#1025717: cross-toolchain-base-mipsen FTBFS: install: cannot change owner and permissions

[Yunqiang Su]

On Thu, 08 Dec 2022 00:00:35 +0200 Adrian Bunk  wrote:
> Source: cross-toolchain-base-mipsen
> Version: 22
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=cross-toolchain-base-mipsen&arch=all&ver=22&stamp=1670437077&raw=0

Fixed by version 23.

> 
> ...
> dh_installdirs -plinux-libc-dev-mips-cross \
>   usr/share/doc/linux-libc-dev-mips-cross \
>   usr/share/lintian/overrides \
>   usr/mips-linux-gnu
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross’: 
> Operation not permitted
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides’: Operation not 
> permitted
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu’: Operation not permitted
> dh_installdirs: error: install -m0755 -o 0 -g 0 -d 
> debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross 
> debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides 
> debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu returned exit code 1
> make: *** [debian/rules:162: stamp-dir/install-linux.mips] Error 25

Bug#1026206: g++-13: fails to compile #include due to __float128 vs fixincludes

[YunQiang Su]

On Fri, 16 Dec 2022 11:06:37 +0100 Helmut Grohne  wrote:
> Package: g++-13
> Version: 13-20221214-1
> Severity: serious
> 
> Hi Matthias,
> 
> thanks for pushing gcc-13 into experimental already. That leaves plenty
> of time to work on it. I've located a quite fundamental problem with it
> already:
> 
> $ cat test.c++
> #include 
> $ g++-13 -c test.c++
> In file included from /usr/include/stdio.h:430,
>  from test.c++:1:
> /usr/include/x86_64-linux-gnu/bits/floatn.h:87:9: error: multiple types in 
> one declaration
>87 | typedef __float128 _Float128;
>   | ^~
> /usr/include/x86_64-linux-gnu/bits/floatn.h:87:20: error: declaration does 
> not declare anything [-fpermissive]
>87 | typedef __float128 _Float128;
>   |^
> In file included from /usr/include/x86_64-linux-gnu/bits/floatn.h:120:
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:9: error: multiple 
> types in one declaration
>   214 | typedef float _Float32;
>   | ^
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:15: error: declaration 
> does not declare anything [-fpermissive]
>   214 | typedef float _Float32;
>   |   ^~~~
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:9: error: multiple 
> types in one declaration
>   251 | typedef double _Float64;
>   | ^~
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:16: error: declaration 
> does not declare anything [-fpermissive]
>   251 | typedef double _Float64;
>   |^~~~
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:9: error: multiple 
> types in one declaration
>   268 | typedef double _Float32x;
>   | ^~
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:16: error: declaration 
> does not declare anything [-fpermissive]
>   268 | typedef double _Float32x;
>   |^
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:14: error: multiple 
> types in one declaration
>   285 | typedef long double _Float64x;
>   |  ^~
> /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:21: error: declaration 
> does not declare anything [-fpermissive]
>   285 | typedef long double _Float64x;
>   | ^
> $
> 
> Jakub Jelinek kindly pointed out that bits/floatn.h and
> bits/floatn-common.h should be fixincluded. I can see that this is
> happening in a build log and that those fixed includes are not contained
> in any binary package. As such, this is not considered an upstream
> problem. I see that the packaging deletes include-fixed and fail to
> understand why that happens at this time. Do you have a better
> understanding?

I try to build a cross toolchain, it has this problem, too.
So, should it be an upstream bug? I guess.

Gcc git master has this problem, while branch gcc-12 doesn’t.

> 
> Helmut
> 
> 
> 

Bug#1026088: rdma-core: add mips64* to COHERENT_DMA_ARCHS

[YunQiang Su]

Yunqiang Su  于2022年12月14日周三 23:24写道：
>
> On Wed, 14 Dec 2022 22:47:53 +0800 YunQiang Su  wrote:
> > Source: rdma-core
> > Version: 33.2-1
> > Severity: serious
> > Tags: ftbfs
> >
> > Can you help to add the fellow 4 ports
> > mips64 mips64el mips64r6 mips64r6el
>
> mips mipsel mipsr6 mipsr6el
> are also needed.
>
> > to the list of
> > COHERENT_DMA_ARCHS
> > in debian/rules ?
> >
>
> Backport this patch can fix FTBFS on mipsel.
>
https://github.com/linux-rdma/rdma-core/commit/90a5793ec9a6b9462712d36d466042fa979249a9

> > --
> > YunQiang Su
> >
> >



-- 
YunQiang Su

Bug#1026088: rdma-core: add mips64* to COHERENT_DMA_ARCHS

[Yunqiang Su]

On Wed, 14 Dec 2022 22:47:53 +0800 YunQiang Su  wrote:
> Source: rdma-core
> Version: 33.2-1
> Severity: serious
> Tags: ftbfs
> 
> Can you help to add the fellow 4 ports
> mips64 mips64el mips64r6 mips64r6el

mips mipsel mipsr6 mipsr6el
are also needed.

> to the list of
> COHERENT_DMA_ARCHS
> in debian/rules ?
> 

Backport this patch can fix FTBFS on mipsel.

> -- 
> YunQiang Su
> 
> 

Bug#1026088: rdma-core: add mips64* to COHERENT_DMA_ARCHS

[YunQiang Su]

Source: rdma-core
Version: 33.2-1
Severity: serious
Tags: ftbfs

Can you help to add the fellow 4 ports
mips64 mips64el mips64r6 mips64r6el
to the list of
COHERENT_DMA_ARCHS
in debian/rules ?

-- 
YunQiang Su

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[YunQiang Su]

Mathieu Malaterre  于2022年12月9日周五 17:51写道：
>
> On Fri, Dec 9, 2022 at 10:29 AM Andreas Tille  wrote:
> >
> > Hi Mathieu,
> >
> > Am Tue, Dec 06, 2022 at 08:38:43AM +0100 schrieb Mathieu Malaterre:
> > > I do not have a clean answer to this, but in my experience it is
> > > getting more and more difficult to compile anything on mipsel with
> > > g++-12. The default option `-g -O2` seems to imply `take as much
> > > memory as you want to get things to compile` so this end up crossing
> > > the 2GB hard-limit.
> > >
> > > For example here is what webkit is doing to work around the symptoms:
> > >
> > > * 
> > > https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71
> >
> > Thanks for the hint.  I tried this but this does not work since the R
> > build system does not respect external set variables.  Since chances
> > are really low that this package will be used on mipsel I asked for
> > removal on this architecture.
>
> Totally agree! Let's start the cabal against mipsel as a release arch.
>

As the MIPS porter, in fact I don't anticipate it.
Since the current version has some problems; Y2038 is the most serious.

And we are also working on new mipsel port with:
 * -mnan=2008
 * -mfp64
 * -mmsa
 * -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
 * -D_TIME_BITS=64

-- 
YunQiang Su

Bug#1022169: llvm-toolchain-15: FTBFS on mips*el: static assertion failed: struct_kernel_stat_sz == sizeof(stat)

[YunQiang Su]

Simon McVittie  于2022年10月21日周五 19:36写道：
>
> Source: llvm-toolchain-15
> Version: 1:15.0.2-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source, making mesa unbuildable
> User: debian-m...@lists.debian.org
> Usertags: mipsel mips64el
> X-Debbugs-Cc: debian-m...@lists.debian.org, m...@packages.debian.org
> Control: affects -1 + src:mesa
>
> Quoting from mips64el buildd logs, but mipsel has a similar failure:
>
> > /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cpp:67:1:
> >  error: static assertion failed due to requirement 'struct_kernel_stat_sz 
> > == sizeof(stat)':
> > COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
>

https://reviews.llvm.org/D135553
It is due to large file support is enabled by default for 32bit compiler_rt.

> Strictly speaking this is not a regression because llvm-toolchain-15 was
> never built successfully on mips*el, but I think it should be treated as
> RC anyway, because older llvm-toolchain-* were buildable on mips*el (and
> mesa is already using llvm-toolchain-15, making it a key package).
>
> smcv
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
> 'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.0.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


-- 
YunQiang Su

Bug#1021691: llvm-toolchain-snapshot: mips need some patches

[YunQiang Su]

Package: llvm-toolchain-snapshot
Version: 1:16~++20220928062542+48b8dee773f3-1~exp1

The upstream compiler-rt and openmp have some problem,
and we are try to push the patches upstream:

https://reviews.llvm.org/D135552
https://reviews.llvm.org/D135735
https://reviews.llvm.org/D135565
https://reviews.llvm.org/D135553

-- 
YunQiang Su

Bug#1020989: trafficserver: failed to load plugin

[YunQiang Su]

Package: trafficserver
Version: 9.1.3+ds-2
Severity: grave

Since ATS 9, it tries to load plugins to /run/trafficserver, and then load them,
and it asks for the plugins to have execution permission.

While the /run filesystem on Debian is mounted with noexec option.

-- 
YunQiang Su

Bug#1016628: gcc-12: makes nodejs testsuite fail on mips64el/riscv64 only

[YunQiang Su]

Jérémy Lal  于2022年8月4日周四 18:39写道：
>
>
>
> Le jeu. 4 août 2022 à 12:36, Xi Ruoyao  a écrit :
>>
>> On Thu, 2022-08-04 at 18:18 +0800, YunQiang Su wrote:
>> > > Hi,
>> > >
>> > > If nodejs 18.6.0 is built using gcc-12, several tests fail,
>> > > but not when built using gcc-11 (all other things being equal).
>> > >
>> > > *Only* on mips64el and riscv64.
>> > >
>> > > In the logs, some new warnings show up, maybe that can help:
>> > > https://buildd.debian.org/status/fetch.php?pkg=nodejs&arch=mips64el&ver=18.6.0%2Bdfsg-4&stamp=1659454899&raw=0
>> > >
>> > > in particular:
>> > > /usr/include/c++/12/bits/atomic_base.h:488:31: warning: ‘long
>> > > unsigned int __atomic_load_8(const volatile void*, int)’ writing 8
>> > > bytes into a region of size 0 overflows the destination [-Wstringop-
>> > > overflow=]
>> > >488 | return __atomic_load_n(&_M_i, int(__m));
>> > >
>> >
>> > @Xi Ruoyao Is this what you are working on?
>>
>> If we have evidence showing it's a GCC code generation bug, I'll try to
>> fix it.  I don't have any interest in node.js.
>

I mean is it about then zero legth var in C++?

>
> No evidence yet.
> Upstream nodejs says it might very well be a bug on their side.
> I'll reassign accordingly.
>
>



-- 
YunQiang Su

Bug#1016628: gcc-12: makes nodejs testsuite fail on mips64el/riscv64 only

[YunQiang Su]

Jérémy Lal  于2022年8月4日周四 15:12写道：
>
> Package: gcc-12
> Version: 12.1.0-7
> Severity: important
> X-Debbugs-Cc: YunQiang Su 
> Control: forwarded -1 https://github.com/nodejs/node/issues/44126
>
> Hi,
>
> If nodejs 18.6.0 is built using gcc-12, several tests fail,
> but not when built using gcc-11 (all other things being equal).
>
> *Only* on mips64el and riscv64.
>
> In the logs, some new warnings show up, maybe that can help:
> https://buildd.debian.org/status/fetch.php?pkg=nodejs&arch=mips64el&ver=18.6.0%2Bdfsg-4&stamp=1659454899&raw=0
>
> in particular:
> /usr/include/c++/12/bits/atomic_base.h:488:31: warning: ‘long unsigned int 
> __atomic_load_8(const volatile void*, int)’ writing 8 bytes into a region of 
> size 0 overflows the destination [-Wstringop-overflow=]
>   488 | return __atomic_load_n(&_M_i, int(__m));
>

@Xi Ruoyao Is this what you are working on?

> Jérémy
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 gcc-12 depends on:
> ii  binutils   2.38.90.20220713-2
> ii  cpp-12 12.1.0-7
> ii  gcc-12-base12.1.0-7
> ii  libc6  2.33-8
> ii  libcc1-0   12.1.0-7
> ii  libgcc-12-dev  12.1.0-7
> ii  libgcc-s1  12.1.0-7
> ii  libgmp10   2:6.2.1+dfsg1-1
> ii  libisl23   0.25-1
> ii  libmpc31.2.1-2
> ii  libmpfr6   4.1.0-3
> ii  libstdc++6 12.1.0-7
> ii  libzstd1   1.5.2+dfsg-1
> ii  zlib1g 1:1.2.11.dfsg-4
>
> Versions of packages gcc-12 recommends:
> ii  libc6-dev  2.33-8
>
> Versions of packages gcc-12 suggests:
> pn  gcc-12-doc   
> pn  gcc-12-locales   
> pn  gcc-12-multilib  
>
> -- no debconf information



-- 
YunQiang Su

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[YunQiang Su]

Paul Gevers  于2022年3月31日周四 16:16写道：
>
> Hi YunQiang,
>
> On 24-03-2022 12:29, YunQiang Su wrote:
> > Yes. I am aware of it. And I am waiting for gcc-12-cross-mipsen to finish
> > building on all of these architectures.
>
> Although not clear to me why you wanted to wait, this happened 3.5 days
> ago. Will you do the source only upload soon?
>

The new version was uploaded.

> Paul



-- 
YunQiang Su

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[YunQiang Su]

Paul Gevers  于2022年3月24日周四 19:26写道：
>
> Hi YunQiang,
>
> On 22-03-2022 07:06, YunQiang Su wrote:
> > Paul Gevers  于2022年3月22日周二 04:04写道：
> >> On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
> >>> The Release Team considers packages that are out-of-sync between testing
> >>> and unstable for more than 60 days as having a Release Critical bug in
> >>> testing [1]. Your package src:gcc-defaults-mipsen has been trying to
> >>> migrate for 62 days [2].
> >>
> >> It's been 161 days now. We expect from you to solve these kind of
> >> issues, especially if they have been brought to your attention.
> >>
> >
> > ohh. sorry for it. I upload gcc-11-cross-mipsen some days ago.
> > I thought that gcc-defaults-mipsen will migrate ok.
> >
> > I will fix it just now.
>
> You are aware that gcc-12-cross-mipsen needs another source-only upload
> because it's new and you needed to upload all binaries but non-buildd
> built binaries are not allowed to migrate. Unfortunately on the current
> infrastructure binNMU's of arch:all binaries don't work.
> gcc-12-cross-mipsen needs to be able to migrate together with
> gcc-11-cross-mipsen (and gcc-defaults-mipsen).
>

Yes. I am aware of it. And I am waiting for gcc-12-cross-mipsen to finish
building on all of these architectures.

> Paul



-- 
YunQiang Su

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[YunQiang Su]

Paul Gevers  于2022年3月22日周二 04:04写道：
>
> Hi mips porters,
>
> On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
> > The Release Team considers packages that are out-of-sync between testing
> > and unstable for more than 60 days as having a Release Critical bug in
> > testing [1]. Your package src:gcc-defaults-mipsen has been trying to
> > migrate for 62 days [2].
>
> It's been 161 days now. We expect from you to solve these kind of
> issues, especially if they have been brought to your attention.
>

ohh. sorry for it. I upload gcc-11-cross-mipsen some days ago.
I thought that gcc-defaults-mipsen will migrate ok.

I will fix it just now.

> Paul



-- 
YunQiang Su

Bug#1006948: gcc-12: FTBFS on mips64el

[YunQiang Su]

On Tue, 08 Mar 2022 20:53:46 +0100 Paul Gevers  wrote:
> Source: gcc-12
> Version: 12-20220222-1
> Severity: serious
> Tags: ftbfs
> 
> Dear Matthias, GCC maintainers,
> 
> gcc-12 fails to build from source on mips64el in unstable. Normally this 
> isn't an issue, but it builds a Build-Depends of gcc-11 which now can't 
> migrate because it can't be build on mips64el.
> 

We are try our best to find the root cause of this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 


Currently: disable libphobo may be an option.

> Paul
> 
> 

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[YunQiang Su]

Graham Inggs  于2022年2月16日周三 18:57写道：
>
> Dear MIPS Porters
>
> Could somebody take a look a this issue please?
>

Thank you. I will take care about it.

>
> > Hi YunQiang,
> >
> > On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
> > > Your package src:gcc-defaults-mipsen has been trying to
> > > migrate for 62 days [2]. Hence, I am filing this bug.
> >
> > Any progress? It has been 1.5 months and I haven't seen anything
> > happening. This is NOK. gcc-defaults-mipsen is a key package, so I can't
> > just remove it. Please ensure the package can migrate. It seems to me
> > that your failing to build all kind of required packages, although it's
> > not clear if those should come from e.g. gcc-11 (which apparently
> > started to build again itself on mipsel and mips64el. I'm not versed
> > enough in how this piece of toolchain should work. If you need my help
> > as a Release Team member, don't hesitate to reach out, but I don't want
> > to spend time on reverse engineering this *.
> >
> > Paul
>


-- 
YunQiang Su

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[YunQiang Su]

Sandro Tosi  于2022年1月26日周三 05:16写道：
>
> > It is due to gcc-11 of mips64el.
> >
> > -O1, -O2 may generate bad code, while -O0 and -O3 works well.
> > As a workaround: we can:
> >
> > The attachment is a workaround patch.
>
> is there a bug against gcc-11 that i can track so that i dont have to
> keep this workaround forever but just until it's fixed in the right
> package? thanks
>

Yes. I cloned this bug as: #1004184
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



-- 
YunQiang Su

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[Yunqiang Su]

On Sat, 22 Jan 2022 18:23:13 +0800 YunQiang Su  wrote:
> On Sat, 22 Jan 2022 17:06:00 +0800 YunQiang Su  wrote:
>> On Tue, 23 Nov 2021 08:08:23 +0100 Ole Streicher  wrote:
>>> Source: matplotlib
>>> Severity: serious
>>> Version: 3.5.0-1
>>> Control: affects -1 yt
>>> Control: affects -1 astropy
>>> 
>>> With the new matplotlib version, I now have crashes with a segmentation 
>>> fault
>>> in at least two of my packages on mips64el, which cause a FTBFS: yt and
>>> astropy. On both packages, the crash happens here:
>>> 
>>> --8<
>>>   File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
>>> _draw_list_compositing_images
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 
>>> in draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
>>> _draw_list_compositing_images
>>>   File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
>>> line 436 in draw
>>> --8<
>>> 
>>> Build log on Astropy: 
>>> https://buildd.debian.org/status/fetch.php?pkg=astropy&arch=mips64el&ver=5.0-1&stamp=1637626067&raw=0
>>> 
>>> Build log on yt: 
>>> https://buildd.debian.org/status/fetch.php?pkg=yt&arch=mips64el&ver=4.0.1-3&stamp=1637588650&raw=0
>>> 
>>> This happens on both Python 3.9 and 3.10. The I will try to create a 
>>> stacktrace for it.
>>> 
>> 
>> It is due to gcc-11 of mips64el.
>> 
>> -O1, -O2 may generate bad code, while -O0 and -O3 works well.
>> As a workaround: we can:
>> 
>> The attachment is a workaround patch.
>> 
> 
> 
> 
> A better formatted patch with DEB__MAINT_APPEND

Should I NMU this package?

> 
>>> 

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[YunQiang Su]

On Sat, 22 Jan 2022 17:06:00 +0800 YunQiang Su <wzss...@gmail.com> wrote:> On Tue, 23 Nov 2021 08:08:23 +0100 Ole Streicher <oleb...@debian.org> wrote:> > Source: matplotlib> > Severity: serious> > Version: 3.5.0-1> > Control: affects -1 yt> > Control: affects -1 astropy> >> > With the new matplotlib version, I now have crashes with a segmentation fault> > in at least two of my packages on mips64el, which cause a FTBFS: yt and> > astropy. On both packages, the crash happens here:> >> > --8<> >    File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in draw> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in draw> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in _draw_list_compositing_images> >    File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 in draw> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in _draw_list_compositing_images> >    File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in draw> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in draw_wrapper> >    File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", line 436 in draw> > --8<> >> > Build log on Astropy: https://buildd.debian.org/status/fetch.php?pkg=astropy&arch=mips64el&ver=5.0-1&stamp=1637626067&raw=0> >> > Build log on yt: https://buildd.debian.org/status/fetch.php?pkg=yt&arch=mips64el&ver=4.0.1-3&stamp=1637588650&raw=0> >> > This happens on both Python 3.9 and 3.10. The I will try to create a stacktrace for it.> >> > It is due to gcc-11 of mips64el.> > -O1, -O2 may generate bad code, while -O0 and -O3 works well.> As a workaround: we can:> > The attachment is a workaround patch.> 

matplotlib-mips64el-o3.diff
Description: Binary data
A better formatted patch with DEB__MAINT_APPEND> >

Bug#1001168: [Debian-pan-maintainers] Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py

[YunQiang Su]

PICCA Frederic-Emmanuel
 于2022年1月22日周六 17:28写道：
>
> Is it not better to use the
>
> DEB__MAINT_APPEND
>
> variable in order to deal with this issue ?

Thanks, you are right. the patch looks better now.


-- 
YunQiang Su


matplotlib-mips64el-o3.diff
Description: Binary data

Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py

[YunQiang Su]

Graham Inggs  于2022年1月22日周六 16:48写道：
>
> On Sat, 22 Jan 2022 at 10:45, YunQiang Su  wrote:
> > Sure. I will.
>
> Thank you!

Patch sent: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000435

-- 
YunQiang Su

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[YunQiang Su]

On Tue, 23 Nov 2021 08:08:23 +0100 Ole Streicher  wrote:
> Source: matplotlib
> Severity: serious
> Version: 3.5.0-1
> Control: affects -1 yt
> Control: affects -1 astropy
>
> With the new matplotlib version, I now have crashes with a segmentation fault
> in at least two of my packages on mips64el, which cause a FTBFS: yt and
> astropy. On both packages, the crash happens here:
>
> --8<
>File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in draw
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in draw
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
> _draw_list_compositing_images
>File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 
> in draw
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
> _draw_list_compositing_images
>File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in 
> draw
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in 
> draw_wrapper
>File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
> line 436 in draw
> --8<
>
> Build log on Astropy: 
> https://buildd.debian.org/status/fetch.php?pkg=astropy&arch=mips64el&ver=5.0-1&stamp=1637626067&raw=0
>
> Build log on yt: 
> https://buildd.debian.org/status/fetch.php?pkg=yt&arch=mips64el&ver=4.0.1-3&stamp=1637588650&raw=0
>
> This happens on both Python 3.9 and 3.10. The I will try to create a 
> stacktrace for it.
>

It is due to gcc-11 of mips64el.

-O1, -O2 may generate bad code, while -O0 and -O3 works well.
As a workaround: we can:

The attachment is a workaround patch.

>


matplotlib-mips64el-o3.diff
Description: Binary data

Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py

[YunQiang Su]

Graham Inggs  于2022年1月22日周六 16:42写道：
>
> On Sat, 22 Jan 2022 at 10:12, YunQiang Su  wrote:
> > Let's have a try to build matplotlib with -O3, and try to build hkl with it.
> > If it works, we can workaround it for now.
> > I will continue to dig the real problem of gcc (maybe).
>
> To be clear, will you try building matplotlib with -O3 and if it
> works, send a patch to matplotlib?

Sure. I will.

-- 
YunQiang Su

Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py

[YunQiang Su]

Graham Inggs  于2022年1月22日周六 15:42写道：
>
> Hi YunQiang Su
>
> Have you been able to make any progress with this issue?
>
> If not, then we should consider asking ftp-master for temporary
> removal of the affected mips64el packages from testing.  We'd like to
> move the python3-defaults transition along.
>

Let's have a try to build matplotlib with -O3, and try to build hkl with it.
If it works, we can workaround it for now.
I will continue to dig the real problem of gcc (maybe).

> Regards
> Graham



-- 
YunQiang Su

Bug#1004137: upx-ucl: please back port patches for mips

[YunQiang Su]

Package: src:upx-ucl
Version: 3.96-3

https://github.com/upx/upx/commit/4fb1d41be8acd16849fab9622f35903d3fc4a7d9
https://github.com/upx/upx/commit/16b18e939641663806ae4862114b4b556883c7de

The current version of upx may break mips binary with uclibc or musl.
https://github.com/upx/upx/issues/387

-- 
YunQiang Su

Bug#1001168: Info received (Bug#1001168: Info received (Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py))

[YunQiang Su]

On Fri, 14 Jan 2022 23:34:57 +0800 YunQiang Su
 wrote:
> 在 2022/1/14 23:30, Sandro Tosi 写道:
> > On Fri, Jan 14, 2022 at 9:24 AM YunQiang Su  
> > wrote:
> >>
> >> On Mon, 3 Jan 2022 22:56:58 +0100 (CET) PICCA Frederic-emmanuel
> >>  wrote:
> >>   > Built with gcc-11 and -fno-lto it doesn not work.
> >>   >
> >>   >
> >> (sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
> >> ../../../test.py
> >>   > Segmentation fault
> >>   >
> >> (sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
> >> PYTHONPATH=. ../../../test.py
> >>   > Segmentation fault
> >>   >
> >>   >
> >>
> >> It seems due to gcc-11.
> >>
> >> I tried to build with gcc-10 on sid, it works again.
> >
> > yes, that's what PICCA found and reported at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72
> >
> > are you going to look into a fix for gcc-11?
> >
>
> Sure, I will dig it, since it may effect lots of other packages.
>

It is strange that -O1/-O2 fail, while -O0/-O3 succeed...

> > Thanks,
>
>
>

Bug#1001168: Info received (Bug#1001168: Info received (Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py))

[YunQiang Su]

在 2022/1/14 23:30, Sandro Tosi 写道:

On Fri, Jan 14, 2022 at 9:24 AM YunQiang Su  wrote:


On Mon, 3 Jan 2022 22:56:58 +0100 (CET) PICCA Frederic-emmanuel
 wrote:
  > Built with gcc-11 and -fno-lto it doesn not work.
  >
  >
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
../../../test.py
  > Segmentation fault
  >
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
PYTHONPATH=. ../../../test.py
  > Segmentation fault
  >
  >

It seems due to gcc-11.

I tried to build with gcc-10 on sid, it works again.


yes, that's what PICCA found and reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72

are you going to look into a fix for gcc-11?



Sure, I will dig it, since it may effect lots of other packages.


Thanks,

Bug#1001168: Info received (Bug#1001168: Info received (Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py))

[YunQiang Su]

On Mon, 3 Jan 2022 22:56:58 +0100 (CET) PICCA Frederic-emmanuel 
 wrote:

> Built with gcc-11 and -fno-lto it doesn not work.
>
> 
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
../../../test.py

> Segmentation fault
> 
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
PYTHONPATH=. ../../../test.py

> Segmentation fault
>
>

It seems due to gcc-11.

I tried to build with gcc-10 on sid, it works again.

Bug#1001699: gcc/MIPS, gdc defines wrong stat_t for N32 and N64

[YunQiang Su]

On Tue, 14 Dec 2021 23:36:58 +0800 YunQiang Su  wrote:
> Package: src:gcc-10
> Version: 10.3.0-13
> 
> This problem makes fstat get wrong result, and thus makes gcc-12 ftbfs
> on mips64el.

Real patch for gcc-10 instead of in fact for gcc-11.

> 
> -- 
> YunQiang Su

gdc-mips64-stat.patch
Description: Binary data

Bug#1001699: gcc/MIPS, gdc defines wrong stat_t for N32 and N64

[YunQiang Su]

Package: src:gcc-10
Version: 10.3.0-13

This problem makes fstat get wrong result, and thus makes gcc-12 ftbfs
on mips64el.

-- 
YunQiang Su


gdc-mips64-stat.patch
Description: Binary data

Bug#1001255: Fwd: binutils/mipsel: ld testsuite cost too much time due to lto, so failed

[YunQiang Su]

Package: src:binutils
Version: 2.37-10

Our mips32 build machines have so bad performance.
It costs to much time to run some ld testcase.

Here we just disable LTO for them.


mips32-ld-bootstrap-disable-lto.diff
Description: Binary data

Bug#995867: mipsel FTBFS (relocation truncated to fit: R_MIPS_CALL16)

[YunQiang Su]

Drew Parsons  于2021年10月26日周二 上午3:11写道：
>
> Hi mipsel porters,
>
> I need help resolving Bug#995867 [1]. xtensor implacably FTBFS.
>
> I thought it might have been related to memory constraints, since
> xtensor is a header-only library. But the problem is still present after
> reducing the test file to only one "optional" tests (unless that's still
> too big and need more radical reduction in object size).
>

add -mxgot build-time option can workaround this problem.

> Upstream has recently made a new release, but it doesn't seem to have
> made such changes to the test file structure that would significantly
> reduce the object size.  Perhaps the problem is something different.
>
> Drew
>
> [1] For your convenience:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995867
>


-- 
YunQiang Su

Bug#995773: linux-image-5.10.0-8-amd64: NMI panic on HP ProLiant DL380G6 and DL360G7

[Yunqiang Su]

On Wed, 6 Oct 2021 08:11:05 +0200 Claudio Kuenzler  
wrote:
> I've seen this too and documented my findings here:
> https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
> 
> (reason is the hpwdt module)
> 
> This bug is most likely a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 where the same
> NMI's are reported with Kernel 4.16 but with Kernel 5.10 the boot
> issues/crashes seem to be even worse.
> 
> Maintainers, please consider disabling (blacklisting) the hpwdt module by
> default (same as Ubuntu). If anyone REALLY needs it, it can be manually
> enabled.


My HPE ProLiant BL460c Gen9 has the same problem.
And with some debug, I find the problem is due to
   CONFIG_INTEL_IOMMU_DEFAULT_ON=y

So, as a workaround, we can use intel_iommu=off kernel option.

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

YunQiang Su  于2021年10月22日周五 下午10:36写道：
>
> Claudio Kuenzler  于2021年10月22日周五 下午2:03写道：
> >
> > The fact that a later Kernel versions work fine _could_ be because of a 
> > hpwdt commit after 5.10: 
> > https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817
> > I have not tested sid or a newer Kernel on our HP machines though.
> > If you've compiled your own Kernel and this one works (did your do a 
> > multiple reboot test?), maybe there's a difference in the Kernel "config"?
> >
> > What happens if you disable the hpwdt module as mentioned in the other bug 
> > reports? Does Bullseye with 5.10 and experimental with 5.14 work in this 
> > case?
>
> I test upstream linux and debian-linux with the same config.
> All of the upstream config works fine, while debian-linux has this problem.
> I guess it is due to one patch by Debian.
>

I find the real problem: it is due to intel_iommu by default.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934309

> --
> YunQiang Su



-- 
YunQiang Su

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Claudio Kuenzler  于2021年10月22日周五 下午2:03写道：
>
> The fact that a later Kernel versions work fine _could_ be because of a hpwdt 
> commit after 5.10: 
> https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817
> I have not tested sid or a newer Kernel on our HP machines though.
> If you've compiled your own Kernel and this one works (did your do a multiple 
> reboot test?), maybe there's a difference in the Kernel "config"?
>
> What happens if you disable the hpwdt module as mentioned in the other bug 
> reports? Does Bullseye with 5.10 and experimental with 5.14 work in this case?

I test upstream linux and debian-linux with the same config.
All of the upstream config works fine, while debian-linux has this problem.
I guess it is due to one patch by Debian.

-- 
YunQiang Su

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Claudio Kuenzler  于2021年10月22日周五 下午1:18写道：
>
> Also look at the following links and compare. Might be related or even the 
> same as you are seeing:
>
> https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995773
>

I built kernel by myself (5.14.12), same version as the current debian sid one.
   in fact 5.14.14 is also tested.
It won't trigger this problem.
And I make sure that hpwdt module is loaded.

No idea why Debian's kernel cannot work.

>
> On Thu, Oct 21, 2021 at 10:42 AM Yunqiang Su  wrote:
>>
>> On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su  wrote:
>> > Yunqiang Su  于2021年9月9日周四 上午11:11写道：
>> > >
>> > >
>> > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
>> > > > Package: src:linux
>> > > > Version: 5.10
>> > > >
>> > > > After upgrade to bullseyes' kernel, the system always hang after about 
>> > > > 10 min
>> > > > with an error from IML log
>> > > >
>> > > > An Unrecoverable System Error (NMI) has occurred (Service Information:
>> > > > 0x0008, 0x8948)
>> > > >
>> > > > Kernel 5.14 from experimental also has this problem.
>> > > > Kernel 4.19 works fine.
>> > > > Fedora 34 seems to be working well.
>> > >
>> > > This is the output of dmesg and lspci from both Fedora 34 and Debian 
>> > > bullseye.
>> > > Wish they are useful.
>> > >
>> >
>> > Finally, we find the problem:
>> >
>> > https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
>> > https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf
>> >
>> > In the first patch:
>> >They thought `err' is not used at all, and removed it.
>> > In the second patch:
>> >They add it back and a wrong value "-EINVAL" is given.
>> >
>> > Better KPI got.
>> >
>>
>> The NICs can be detected now, while the machine continue to hang…
>> 4.19.y works fine, while 5.10, 5.14 cannot.
>>
>> I think that we need more dig.
>>
>> > > >
>> > > > --
>> > > > YunQiang Su
>> > > >
>> > > >
>> >
>> >
>> >
>> > --
>> > YunQiang Su
>> >
>> >
>>


-- 
YunQiang Su

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[Yunqiang Su]

On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su  wrote:
> Yunqiang Su  于2021年9月9日周四 上午11:11写道：
> >
> >
> > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
> > > Package: src:linux
> > > Version: 5.10
> > >
> > > After upgrade to bullseyes' kernel, the system always hang after about 10 
> > > min
> > > with an error from IML log
> > >
> > > An Unrecoverable System Error (NMI) has occurred (Service Information:
> > > 0x0008, 0x8948)
> > >
> > > Kernel 5.14 from experimental also has this problem.
> > > Kernel 4.19 works fine.
> > > Fedora 34 seems to be working well.
> >
> > This is the output of dmesg and lspci from both Fedora 34 and Debian 
> > bullseye.
> > Wish they are useful.
> >
> 
> Finally, we find the problem:
> 
> https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
> https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf
> 
> In the first patch:
>They thought `err' is not used at all, and removed it.
> In the second patch:
>They add it back and a wrong value "-EINVAL" is given.
> 
> Better KPI got.
> 

The NICs can be detected now, while the machine continue to hang…
4.19.y works fine, while 5.10, 5.14 cannot.

I think that we need more dig.

> > >
> > > --
> > > YunQiang Su
> > >
> > >
> 
> 
> 
> -- 
> YunQiang Su
> 
> 

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

[YunQiang Su]

standalone-dynamic-mipsel.dir/wrappers_cpp.cpp.o
> >   -Wl,-rpath,"\$ORIGIN/../lib" && :
> > /usr/bin/ld: 
> > projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
> >  in function `scudo::atomic_u64::Type 
> > scudo::atomic_load(scudo::atomic_u64 const volatile*, 
> > scudo::memory_order)':
> > /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> > undefined reference to `__atomic_load_8'
> > /usr/bin/ld: 
> > /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> > undefined reference to `__atomic_load_8'
>

With this patch, I can this error has been gone:

Index: llvm-toolchain-13-13.0.0/compiler-rt/lib/scudo/standalone/CMakeLists.txt
===
--- 
llvm-toolchain-13-13.0.0.orig/compiler-rt/lib/scudo/standalone/CMakeLists.txt
+++ llvm-toolchain-13-13.0.0/compiler-rt/lib/scudo/standalone/CMakeLists.txt
@@ -137,6 +137,13 @@ append_list_if(COMPILER_RT_HAS_LIBPTHREA

 append_list_if(FUCHSIA zircon SCUDO_LINK_LIBS)

+if(CMAKE_HOST_SYSTEM_PROCESSOR MATCHES "mips" OR
+   CMAKE_HOST_SYSTEM_PROCESSOR MATCHES "mips64" OR
+   CMAKE_HOST_SYSTEM_PROCESSOR MATCHES "mipsel" OR
+   CMAKE_HOST_SYSTEM_PROCESSOR MATCHES "mips64el")
+  list(APPEND SCUDO_LINK_LIBS atomic)
+endif()
+
 if(COMPILER_RT_HAS_SCUDO_STANDALONE)
   add_compiler_rt_object_libraries(RTScudoStandalone
 ARCHS ${SCUDO_STANDALONE_SUPPORTED_ARCH}


But I meet a new problem:
/build/llvm-toolchain-13-13.0.0/lldb/source/Plugins/Process/Linux/NativeThreadLinux.cpp:96:
undefined reference to
`lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(lldb_private::ArchSpec
const&, lldb_private::process_linux::NativeThreadLinux&)'
/usr/bin/mips64el-linux-gnuabi64-ld:
/build/llvm-toolchain-13-13.0.0/lldb/source/Plugins/Process/Linux/NativeThreadLinux.cpp:96:
undefined reference to
`lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(lldb_private::ArchSpec
const&, lldb_private::process_linux::NativeThreadLinux&)'

I am digging it.

> smcv
>


-- 
YunQiang Su

Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel

[YunQiang Su]

Dmitry Shachnev  于2021年9月29日周三 下午7:47写道：
>
> Hi YunQiang!
>
> On Wed, Sep 29, 2021 at 09:09:46AM +0800, YunQiang Su wrote:
> > Ohh, the new mips linux kernel removes some macros: so now we can use
> > the same code as x86:
>
> Thank you for the patch! What I don’t like is hard-coding of 999u.
>

The 999u is due to that:
#if _MIPS_SIM == _MIPS_SIM_ABI32
#define __NR_Linux  4000
#endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
#if _MIPS_SIM == _MIPS_SIM_ABI64
#define __NR_Linux  5000
#endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */
#if _MIPS_SIM == _MIPS_SIM_NABI32
#define __NR_Linux  6000
#endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */

The o32/n64/n32 ABI is just from 4000/5000/6000.

> Do you know what is the actual number of syscalls? Is there a probability
> that it will be ≥ 1000 in the future?
>

In the previous version of Linux kernel, it expose
 __NR_64_Linux_syscalls
 __NR_32_Linux_syscalls
 __NR_N32_Linux_syscalls
for the real number of syscalls for the given Linux version.
While now, these macro has been tread as kernel internal values,
and cannot be get in userland.

Since 4000/5000/6000, ≥ will be impossbile without huge rework for kernel.

> --
> Dmitry Shachnev



-- 
YunQiang Su

Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel

[YunQiang Su]

YunQiang Su  于2021年9月28日周二 下午12:20写道：
>
> Adrian Bunk  于2021年9月28日周二 上午12:06写道：
> >
> > Source: qtwebengine-opensource-src
> > Version: 5.15.5+dfsg-2
> > Severity: serious
> > Tags: ftbfs
> >
> > https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src&arch=mips64el&ver=5.15.6%2Bdfsg-1&stamp=1632387575&raw=0
> >
> > ...
> > FAILED: obj/sandbox/linux/seccomp_bpf/syscall_set.o
> > /usr/bin/g++ -MMD -MF obj/sandbox/linux/seccomp_bpf/syscall_set.o.d 
> > -DSANDBOX_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 
> > -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 
> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES 
> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND 
> > -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -Igen 
> > -I../../3rdparty/chromium 
> > -I../../3rdparty/chromium/third_party/perfetto/include 
> > -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen 
> > -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/abseil-cpp 
> > -I../../3rdparty/chromium/third_party/boringssl/src/include 
> > -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out 
> > -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector 
> > -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread 
> > -D__SANE_USERSPACE_TYPES__ -mips64r2 -Wa,-mips64r2 -Wall -U_FORTIFY_SOURCE 
> > -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> > -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
> > -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers 
> > -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections 
> > -fno-omit-frame-pointer -g0 -fvisibility=hidden -std=gnu++14 -Wno-narrowing 
> > -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess 
> > -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type 
> > -Wno-deprecated-copy -fno-exceptions -fno-rtti -fvisibility-inlines-hidden 
> > -c ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc -o 
> > obj/sandbox/linux/seccomp_bpf/syscall_set.o
> > In file included from 
> > ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc:12:
> > ../../3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h:47:10: 
> > fatal error: asm/unistd_nr_n64.h: No such file or directory
> >47 | #include   // for __NR_64_Linux and 
> > __NR_64_Linux_syscalls
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863add648e709337919d2cfeefe4be49
> This commit change the struct of unistd*.h files.
> And I guess that we can just drop mipsel-linux-5.patch now.
> I am testing it.
>

Ohh, the new mips linux kernel removes some macros: so now we can use
the same code as x86:

Index: 
qtwebengine-opensource-src-5.15.6+dfsg/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
===
--- 
qtwebengine-opensource-src-5.15.6+dfsg.orig/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
+++ 
qtwebengine-opensource-src-5.15.6+dfsg/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
@@ -35,18 +35,11 @@
 #define MIN_GHOST_SYSCALL   (MIN_PRIVATE_SYSCALL + 0xfff0u)
 #define MAX_SYSCALL (MIN_GHOST_SYSCALL + 4u)

-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_32_BITS)
+#elif defined(ARCH_CPU_MIPS_FAMILY)

-#include   // for __NR_O32_Linux and __NR_Linux_syscalls
-#define MIN_SYSCALL __NR_O32_Linux
-#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + __NR_Linux_syscalls)
-#define MAX_SYSCALL MAX_PUBLIC_SYSCALL
-
-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_64_BITS)
-
-#include   // for __NR_64_Linux and __NR_64_Linux_syscalls
-#define MIN_SYSCALL __NR_64_Linux
-#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + __NR_64_Linux_syscalls)
+#include 
+#define MIN_SYSCALL __NR_Linux
+#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + 999u)
 #define MAX_SYSCALL MAX_PUBLIC_SYSCALL

 #elif defined(__aarch64__)

>
> >   |  ^~~~~
> > compilation terminated.
> > ...
> >
> >
> > Context:
> > https://sources.debian.org/src/qtwebengine-opensource-src/5.15.6+dfsg-1/debian/patches/mipsel-linux-5.patch/
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863a
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel

[YunQiang Su]

Adrian Bunk  于2021年9月28日周二 上午12:06写道：
>
> Source: qtwebengine-opensource-src
> Version: 5.15.5+dfsg-2
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src&arch=mips64el&ver=5.15.6%2Bdfsg-1&stamp=1632387575&raw=0
>
> ...
> FAILED: obj/sandbox/linux/seccomp_bpf/syscall_set.o
> /usr/bin/g++ -MMD -MF obj/sandbox/linux/seccomp_bpf/syscall_set.o.d 
> -DSANDBOX_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 
> -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND 
> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -Igen 
> -I../../3rdparty/chromium 
> -I../../3rdparty/chromium/third_party/perfetto/include 
> -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen 
> -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/abseil-cpp 
> -I../../3rdparty/chromium/third_party/boringssl/src/include 
> -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out 
> -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector 
> -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread 
> -D__SANE_USERSPACE_TYPES__ -mips64r2 -Wa,-mips64r2 -Wall -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
> -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers 
> -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections 
> -fno-omit-frame-pointer -g0 -fvisibility=hidden -std=gnu++14 -Wno-narrowing 
> -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess 
> -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type 
> -Wno-deprecated-copy -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -c 
> ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc -o 
> obj/sandbox/linux/seccomp_bpf/syscall_set.o
> In file included from 
> ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc:12:
> ../../3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h:47:10: 
> fatal error: asm/unistd_nr_n64.h: No such file or directory
>47 | #include   // for __NR_64_Linux and 
> __NR_64_Linux_syscalls

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863add648e709337919d2cfeefe4be49
This commit change the struct of unistd*.h files.
And I guess that we can just drop mipsel-linux-5.patch now.
I am testing it.


>   |  ^
> compilation terminated.
> ...
>
>
> Context:
> https://sources.debian.org/src/qtwebengine-opensource-src/5.15.6+dfsg-1/debian/patches/mipsel-linux-5.patch/
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863a
>


-- 
YunQiang Su

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Yunqiang Su  于2021年9月9日周四 上午11:11写道：
>
>
> On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
> > Package: src:linux
> > Version: 5.10
> >
> > After upgrade to bullseyes' kernel, the system always hang after about 10 
> > min
> > with an error from IML log
> >
> > An Unrecoverable System Error (NMI) has occurred (Service Information:
> > 0x0008, 0x8948)
> >
> > Kernel 5.14 from experimental also has this problem.
> > Kernel 4.19 works fine.
> > Fedora 34 seems to be working well.
>
> This is the output of dmesg and lspci from both Fedora 34 and Debian bullseye.
> Wish they are useful.
>

Finally, we find the problem:

https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf

In the first patch:
   They thought `err' is not used at all, and removed it.
In the second patch:
   They add it back and a wrong value "-EINVAL" is given.

Better KPI got.

> >
> > --
> > YunQiang Su
> >
> >



-- 
YunQiang Su

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[Yunqiang Su]

dmesg.debian.xz
Description: application/xz


dmesg.fedora.xz
Description: application/xz


lspci.debian.xz
Description: application/xz


lspci.fedora.xz
Description: application/xz

On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
> Package: src:linux
> Version: 5.10
> 
> After upgrade to bullseyes' kernel, the system always hang after about 10 min
> with an error from IML log
> 
> An Unrecoverable System Error (NMI) has occurred (Service Information:
> 0x0008, 0x8948)
> 
> Kernel 5.14 from experimental also has this problem.
> Kernel 4.19 works fine.
> Fedora 34 seems to be working well.

This is the output of dmesg and lspci from both Fedora 34 and Debian bullseye.
Wish they are useful.

> 
> --
> YunQiang Su
> 
> 

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Package: src:linux
Version: 5.10

After upgrade to bullseyes' kernel, the system always hang after about 10 min
with an error from IML log

An Unrecoverable System Error (NMI) has occurred (Service Information:
0x0008, 0x8948)

Kernel 5.14 from experimental also has this problem.
Kernel 4.19 works fine.
Fedora 34 seems to be working well.

--
YunQiang Su

Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[YunQiang Su]

Simon McVittie  于2021年9月3日周五 上午7:21写道：
>
> Source: gtk4
> Version: 4.4.0+ds1-3
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debian-m...@lists.debian.org
> Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
>
> GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
> preferred implementation and a Cairo fallback. Its regression tests draw
> various combinations of "render nodes" and check the results against
> reference PNG images.
>
> When using the "new" OpenGL renderer, "ngl", there's a weird rendering
> glitch on mips*el on two tests involving repeating a pattern: the top
> left pixel in each 2x2 block is darker than the other three.
> For more details and comparison images:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
>
> Is there anything unusual about the OpenGL implementation on mips*el
> that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
> (which I think is llvmpipe?), the same as any other machine without a GPU.
>
> The "old" OpenGL renderer, "gl", does not seem to suffer from this - but
> it is no longer the default, has been deleted in newer upstream versions,
> and crashes in two (unrelated) tests on mipsel, so I'm going to disable
> testing for "gl" in the next upload to avoid wasting machine resources and
> developer time on it.
>
> I'm going to skip these two tests on mips*el. I don't know what practical
> effect this will have on GTK applications; I would recommend that people
> who are interested in GUIs on mips*el should try the gtk-4-examples package
> when mips*el builds become available, and find out.
>

Thank you. We will dig it.
We (CIP United) are taking care about MIPS ecosystem, and feel free to contact
use for any MIPS problems.

> smcv
>


-- 
YunQiang Su

Bug#993059: dpkg-cross: support ld-linux-mipsn8.so.1 for MIPS r6

[YunQiang Su]

On Fri, 27 Aug 2021 09:28:47 +0800 YunQiang Su  wrote:
> Package: dpkg-cross
> Version: 2.6.18+nmu1
> 

Oh, sorry I paste the patch more than needed.
@@ -633,10 +633,13 @@ sub sub_build {
while () {
if ($multiarch =~ m/mips(isa)?64.*-linux.*-gnuabi64.*/) 
{

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa32)?.*-linux.*-gnu.*/) {
-   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
}
@@ -1065,6 +1068,7 @@ sub sub_build {
# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
# their ld.so.1 should be in lib32 and lib64.
next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld\.so\.1$:);
+   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld-linux-mipsn8\.so\.1$:);
next if ($multiarchtriplet eq "sparc64-linux-gnu" && $_ =~ 
m:lib/ld-linux\.so\.2$:);

# skip links to private modules and plugins that are not
This is the correct one, or see:
https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab.patch

> MIPS r6 uses different ld files as the previous version:
> 
> @@ -633,10 +633,13 @@ sub sub_build {
> while () {
> if ($multiarch =~
> m/mips(isa)?64.*-linux.*-gnuabi64.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa32)?.*-linux.*-gnu.*/) {
> -
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarchtriplet eq "sparc64-linux-gnu") {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
> }
> @@ -1065,6 +1068,7 @@ sub sub_build {
> # skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
> # their ld.so.1 should be in lib32 and lib64.
> next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld\.so\.1$:);
> +   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld-linux-mipsn8\.so\.1$:);
> next if ($multiarchtriplet eq "sparc64-linux-gnu" &&
> $_ =~ m:lib/ld-linux\.so\.2$:);
> 
> # skip links to private modules and plugins that are not
> @@ -1137,7 +1141,9 @@ sub sub_build {
> # Link the shlibs file
> if (-f "$src/DEBIAN/shlibs") {
> print "Installing shlibs file\n" if $verbose >= 2;
> -   fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   link_file("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   # FIXME: not enabling in this copy. needed?
> +   #fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> }
> 
> # Create the control file.
> 
> The patch is also avaiable from:
> https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab
> 
> 
> -- 
> YunQiang Su

Bug#893851: ffcall: Fix build for MIPS release 6

[YunQiang Su]

Sébastien Villemot  于2021年8月27日周五 上午1:57写道：
>
> Dear YunQiang,
>
> Le mercredi 28 mars 2018 à 10:49 +0200, Sébastien Villemot a écrit :
> > On Fri, Mar 23, 2018 at 09:38:04PM +0800, YunQiang Su wrote:
> > > On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
> > >  wrote:
> > > > On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
> > > > > On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su  
> > > > > wrote:
> > > > > > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
> > > > > >  wrote:
> > > > > > > Dear YunQiang,
> > > > > > >
> > > > > > > On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
> > > > > > > > Package: src:ffcall
> > > > > > > > Version: 2.1-1
> > > > > > > >
> > > > > > > > MIPS release 6 drops some instructions: bnel/beql included.
> > > > > > > > For r6, we should use bne/beq for replace.
> > > > > > > >
> > > > > > > > The patch has submit in salsa as a merge request.
> > > > > > > >
> > > > > > > > https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
> > > > > > >
> > > > > > > Thanks for your report and your patch.
> > > > > > >
> > > > > > > You may have overlooked the fact that these assembly files are 
> > > > > > > actually
> > > > > > > generated by GCC from C source code (see the DEP-3 header of
> > > > > > > debian/patches/mips-fpxx.patch), so your proposed patch is not 
> > > > > > > very
> > > > > > > maintainable in the long term.
> > > > > >
> > > > > > Oh, thanks. Since then, I guess we should generate these .S files
> > > > > > when build instead of put them in the source code.
> > > > > >
> > > > > > I will have a look at it.
> > > > >
> > > > > After read Makefile.devel, I think that we should call the right
> > > > > target in debian/rules.
> > > > > Should this the ideal way?
> > > >
> > > > This could be a possiblity, but this is not supported by upstream. And 
> > > > we would
> > > > have to patch this Makefile.devel to make it work (it expects 
> > > > non-standard
> > > > names for GCC). So I do not really like this solution.
> > > >
> > >
> > > In fact we can patch it to use $(CC), and pass it when we call these 
> > > targets,
> > > and then we can drop the patch for the .S/.s files.
> > > The length of patch file will be much shorter.
> > >
> > > Anyway, we will have to patch it.
> > > Wish my attached patch can change your mind. ;)
> >
> > I really don't like the kludge for mips in debian/rules.
> >
> > I think that all things considered I prefer your very first patch, which had
> > the advantage of being very small.
>
> I just wanted to inform you that, with the upload of ffcall 2.4, I had
> to drop your MIPS r6, because it no longer applies, and I don’t know
> how to refresh it.
>
> I think this shows that the best solution for MIPS r6 support would
> rather be to work directly with upstream, rather than applying a
> Debian-specific patch.
>

The upstream had some big restruct work and I think that the current source
can work with MIPS r6 out of box now.

> Best regards,
>
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
>


-- 
YunQiang Su