Bug#1075694: xxkb: ftbfs with GCC-14

[YunQiang Su]

On Tue, 5 Nov 2024 11:25:58 +0800 Bo YU  wrote:
> Hi,
>
> On Tue, Nov 05, 2024 at 10:56:09AM +0800, Bo YU wrote:
> >Hi,
> ...
> >
> >I have uploaded it to mentor also. Please review it. Could you upload it
> >if there are no other issues? TIA.
> >
> >```
> >
> >The source builds the following binary packages:
> >
> >  xxkb - Keyboard state indicator and switcher for xkb
> >
> >To access further information about this package, please visit the following 
> >URL:
> >
> >  https://mentors.debian.net/package/xxkb/
> >
> >Alternatively, you can download the package with 'dget' using this command:
> >
> >  dget -x 
> > https://mentors.debian.net/debian/pool/main/x/xxkb/xxkb_1.11.1-3.dsc
> >
> >Changes since the last upload:
> >
> > xxkb (1.11.1-3) unstable; urgency=medium
> > .
> >   * QA upload.
> >   * Add 0004-fix-ftbfs-on-gcc-14.patch to fix the ftbfs issue.
> > (Closes: #1075694)
> >   * Set std-ver to 4.7.0.
> >   * Add Rules-Requires-Root on d/control.
> >   * Add doc-base for xxkb.
> >   * debian/rules: pass CFLAGS to dh_auto_build.
>
> Sorry for the useless entry of the chanelog, I have this with v2.
>

It has a couple of problems:
1. it fails to run multiple times of `dpkg-buildpackage -B` due to
that the generated Makefile is not cleaned.
You may need to clean it.
2. The changelog entry `* debian/rules: pass CFLAGS to dh_auto_build.`
is misleading.
3. Hardcode hardening options is not a good idea.
You can do something like
override_dh_auto_build:
HARDEN_CFLAGS="`dpkg-buildflags --get CFLAGS` `dpkg-buildflags
--get LDFLAGS`" \
dh_auto_build
 And in Imakefile
  CDEBUGFLAGS = -O2 -Wall -g $(HARDEN_CFLAGS)

4. It seems that it can support librsvg. Why is it not enabled?

>

Bug#1075684: xshisen: ftbfs with GCC-14

[YunQiang Su]

On Tue, 5 Nov 2024 10:43:19 +0800 Bo YU  wrote:
> Hi,
>
> >configure:673:1: error: return type defaults to 'int' [-Wimplicit-int]
> >  673 | main(){return(0);}
> >  | ^~~~
> >configure: failed program was:
> >
> >#line 671 "configure"
> >#include "confdefs.h"
> >
>
> I proposed one patch to fix the issue, please review it.
> And I did some minor changes with QA upload also, but this will
> need sponsorship for me. TIA
>

LGTM, and I uploaded it with 5-days delayed.

> (I have uploaded it to mentor, but no send RFS to save reportbug ID:))
>
> ```
> The source builds the following binary packages:
>
>xshisen - Shisen-sho puzzle game for X11
>
> To access further information about this package, please visit the following 
> URL:
>
>https://mentors.debian.net/package/xshisen/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>dget -x 
> https://mentors.debian.net/debian/pool/main/x/xshisen/xshisen_1.51-10.dsc
>
> Changes since the last upload:
>
>   xshisen (1:1.51-10) unstable; urgency=medium
>   .
> * QA upload.
> * Add 2001-fix-ftbfs-gcc-14.patch to fix ftbfs on gcc-14.
>   (Closes: #1075684)
> * DEB_BUILD_MAINT_OPTIONS = hardening=+all to fix lintian warning.
>
> ```
>
>
> --
> Regards,
> --
>Bo YU
>

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#1052345: src:binutils-mipsen: fails to migrate to testing for too long: FTBFS

[YunQiang Su]

It's now buildable.

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#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#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#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#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#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#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#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#983706: gzip FTBFS on mips64el: FAIL: timestamp

[YunQiang Su]

Adrian Bunk  于2021年3月1日周一 下午5:27写道：
>
> On Mon, Mar 01, 2021 at 10:59:20AM +0800, YunQiang Su wrote:
> > Adrian Bunk  于2021年3月1日周一 上午7:13写道：
> > >
> > > Source: gzip
> > > Version: 1.10-2
> > > Severity: serious
> > > Tags: ftbfs
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=gzip&arch=mips64el&ver=1.10-3&stamp=1614531854&raw=0
> >
> > It seems due to some problem of kernel or filesystem:
> >...
> > > On the porterbox eller, 1.10-2 fails the same as 1.10-3.
> > > 1.10-3 builds in a buster chroot.
>
> This implies that what changed is in userspace.
>
> >...
> > On x86:
> > syq@vm208:~$ touch -t 196912312359.59 in
> > syq@vm208:~$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@vm208:~$ cp -a in in.xx
> > syq@vm208:~$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in.xx
> >
> > On mips:
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ cp -a in in.xx
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Feb  7  2106 in.xx
>
> On eller the difference is that in buster
> the "ls -l in" already shows the 2106 date:
>
> (buster_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Feb  7  2106 in
>
> (sid_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Dec 31  1969 in

With some digging, we found the real problem:
mips64 has y2106 problem

the struct stat in asm/stat.h, the timestamp is unsigned int (uint32_t),
so in the SYS_stat, -1 is converted to 0xff.

Then in glibc wrapper of stat, 0x need to convert to int64_t, then,
it is converted to 2016.

So, current, for gzip, we can just ignore the test fails on mips64el.

To solve this problem: I guess that we can wrap `statx' instead of
`stat' in glibc.
Since the timestamp in bits/stat.h is 64bit, there will no ABI broken.

>
>
> cu
> Adrian



-- 
YunQiang Su

Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

[YunQiang Su]

p -Nlv
> method  crc date  time   compresseduncompressed  ratio 
> uncompressed_name
> defla  Feb  7 06:28  20   0   0.0% 
> stdout
> + status=0
> + test 0 -eq 0
> + :
> + gzip --no-name
> + Exit 1
> + set +e
> + exit 1
> + exit 1
> + remove_tmp_
> + __st=1
> + cleanup_
> + :
> + test  = yes
> + cd /<>/builddir/tests
> + chmod -R u+rwx /<>/builddir/tests/gt-timestamp.TDZE
> + rm -rf /<>/builddir/tests/gt-timestamp.TDZE
> + exit 1
> FAIL timestamp (exit status: 1)
>
> 
> Testsuite summary for gzip 1.10
> 
> # TOTAL: 22
> # PASS:  21
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See tests/test-suite.log
> Please report to bug-g...@gnu.org
> 
> make[5]: *** [Makefile:1674: test-suite.log] Error 1
>
>
>
> On the porterbox eller, 1.10-2 fails the same as 1.10-3.
> 1.10-3 builds in a buster chroot.
>
> The breakage is likely caused or triggered by a change to
> some other package like gcc/glibc/...
>
> The linux-mips list is CC'ed.
>


-- 
YunQiang Su

Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel

[YunQiang Su]

https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u
This patch for kernel can fix this problem.

Let's wait for the reply of kernel upstream community.

Bastian Blank  于2021年2月11日周四 下午2:57写道：
>
> Moin
>
> On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote:
> > > Could the mips porters comment on this? Given that we're close to the 
> > > release
> > > of bullseye, I'm not convinced it's a good idea to change this now.
>
> This option is also a dependency of several types of CPU support.  So it
> might not be feasable to disable.
>
> > Yes. It will be a problem to run with buster's golang program on
> > bullseys's kernel.
> > Let's have another way to get this problem sloved without revert this 
> > changes.
>
> Sure, by discontinuing support for go on mips for example.
>
> > Maybe detect the golang applications and run them in FP32 mode?
>
> The kernel already does.  But it seems go decided to set the FPXX marker
> on it's objects.  See https://github.com/golang/go/issues/39435
>
> Bastian
>
> --
> Captain's Log, star date 21:34.5...
>

Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel

[YunQiang Su]

Ivo De Decker  于2021年2月9日周二 下午9:45写道：
>
> Hi,
>
> On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote:
> > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote:
> > > On 2020-05-28 09:04, YunQiang Su wrote:
> > > > Adrian Bunk  于2020年5月21日周四 下午3:40写道：
> > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > > > > > Adrian Bunk  于2020年5月21日周四 上午4:44写道：
> > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > > > > > >
> > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's 
> > > > > > > > finally
> > > > > > > > built, by a longson builder.
> > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller 
> > > > > > > > is also
> > > > > > > > octeon, it also can't build any go program.
> > > > > > >
> > > > > > > On eller golang-1.14 fails to build both in sid and buster 
> > > > > > > chroots.
> > > > > > >
> > > > > > > golang-1.11 also fails to build in a buster chroot with floating 
> > > > > > > point
> > > > > > > test errors.
> > > > > > >
> > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > > > > > >
> > > > > > > The only kernel configuration change on eller in the buster point
> > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed 
> > > > > > > would
> > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> > > > > >
> > > > > > It is just support O32_FP64. I don't expect it will have any effect.
> > > > > > Since currently, the toolchain/libraries are all FPXX.
> > > > >
> > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain?
> > > >
> > > > you are right. the current golang still output FP32 object...
> > > > So, we think that it is buggy.
> > > >
> > > > Since Loongson CPU has some strange behaviour, it even can work...
> > > > Let's try to patch golang to support FPXX or FP64.
> > > >
> > > > https://github.com/golang/go/issues/39289
> > >
> > > That's probably a solution for bullseye/sid, however we can't backport
> > > such changes and rebuild the go world in buster. I therefore think that
> > > for buster the kernel change has to be reverted.
> >
> > What is clear at this point is that the kernel change should be reverted
> > in buster since it causes a regression (including build failures on
> > buildds). I am cloning this bug for a revert in the kernel of
> > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826
> >
> > I am marking the version in bullseye as found since we might run into
> > the same problem again when buster DSAs will be built on machines
> > running the bullseye kernel after the release of bullseye. It might be
> > possible to mitigate this problem (e.g. in the kernel or by keeping some
> > buildd running with the buster kernel), but without an open bug this
> > issue might get forgotten and then resurface after the bullseye release.
>
> Could the mips porters comment on this? Given that we're close to the release
> of bullseye, I'm not convinced it's a good idea to change this now.

Yes. It will be a problem to run with buster's golang program on
bullseys's kernel.
Let's have another way to get this problem sloved without revert this changes.

Maybe detect the golang applications and run them in FP32 mode?

>
> Cheers,
>
> Ivo
>
>

Bug#979085: openmpi: sync data struct with pmix

[YunQiang Su]

Control: reassign 979085 openmpi

Pmix4 has some changes on its pmix_server.h, while openmpi has a old one,
Which make sopt ftbfs on some architectures: mips64el, ia64 etc.




mips64el.patch
Description: Binary data
On Sun, 3 Jan 2021 17:52:22 +0800 YunQiang Su  wrote:
> On Sun, 3 Jan 2021 11:11:02 +0800 YunQiang Su  wrote:
> > On Sun, 03 Jan 2021 00:08:34 +0800 Shengjing Zhu  wrote:
> > > Source: sopt
> > > Version: 3.0.1-11
> > > Severity: serious
> > > X-Debbugs-Cc: z...@debian.org
> > > 
> > > 
> > > When binNMU sopt, it FTBFS on mips64el, please check log at
> > > https://buildd.debian.org/status/fetch.php?pkg=sopt&arch=mips64el&ver=3.0.1-11%2Bb1&stamp=1609594267&raw=0
> > > 
> > > The following tests FAILED:
> > >19 - communicator (Bus error)
> > 
> > It seems like a “aligned” problem.
> > I guess it is due to a problem of spdlog.
> > 
> > Let’s have a debug.
> 
> I found the problem:…
> 
> Pmix4 add a new member `client_connected2’ to pmix_server_module_t.
> While openmpi doesn’t set the value to it in pmix3x_server_north.c.
> 
> On some architecture, it make the value of `client_connected2’ as Random 
> value instead of NULL.
> 
> So it is a problem of openmpi, I think.
> 
> > 
> > >20 - serial_vs_parallel_padmm (Bus error)
> > >21 - mpi_wavelets (Bus error)
> > >22 - mpi_session (Bus error)
> > > 
> > > The failed tests seem all related mpi, so I think it's not related to 
> > > spdlog
> > > or fmtlib. openmpi bumped its version from 4.0.5 to 4.1.0 on 2020-12-21. I
> > > guess it's related to this change of openmpi.
> > > 
> > > 
> > 
> > 

Bug#979085: FTBFS on mips64el

[YunQiang Su]

On Sun, 3 Jan 2021 11:11:02 +0800 YunQiang Su  wrote:
> On Sun, 03 Jan 2021 00:08:34 +0800 Shengjing Zhu  wrote:
> > Source: sopt
> > Version: 3.0.1-11
> > Severity: serious
> > X-Debbugs-Cc: z...@debian.org
> > 
> > 
> > When binNMU sopt, it FTBFS on mips64el, please check log at
> > https://buildd.debian.org/status/fetch.php?pkg=sopt&arch=mips64el&ver=3.0.1-11%2Bb1&stamp=1609594267&raw=0
> > 
> > The following tests FAILED:
> >  19 - communicator (Bus error)
> 
> It seems like a “aligned” problem.
> I guess it is due to a problem of spdlog.
> 
> Let’s have a debug.

I found the problem:…

Pmix4 add a new member `client_connected2’ to pmix_server_module_t.
While openmpi doesn’t set the value to it in pmix3x_server_north.c.

On some architecture, it make the value of `client_connected2’ as Random value 
instead of NULL.

So it is a problem of openmpi, I think.

> 
> >  20 - serial_vs_parallel_padmm (Bus error)
> >  21 - mpi_wavelets (Bus error)
> >  22 - mpi_session (Bus error)
> > 
> > The failed tests seem all related mpi, so I think it's not related to spdlog
> > or fmtlib. openmpi bumped its version from 4.0.5 to 4.1.0 on 2020-12-21. I
> > guess it's related to this change of openmpi.
> > 
> > 
> 
> 

Bug#979085: FTBFS on mips64el

[YunQiang Su]

On Sun, 03 Jan 2021 00:08:34 +0800 Shengjing Zhu  wrote:
> Source: sopt
> Version: 3.0.1-11
> Severity: serious
> X-Debbugs-Cc: z...@debian.org
> 
> 
> When binNMU sopt, it FTBFS on mips64el, please check log at
> https://buildd.debian.org/status/fetch.php?pkg=sopt&arch=mips64el&ver=3.0.1-11%2Bb1&stamp=1609594267&raw=0
> 
> The following tests FAILED:
>19 - communicator (Bus error)

It seems like a “aligned” problem.
I guess it is due to a problem of spdlog.

Let’s have a debug.

>20 - serial_vs_parallel_padmm (Bus error)
>21 - mpi_wavelets (Bus error)
>22 - mpi_session (Bus error)
> 
> The failed tests seem all related mpi, so I think it's not related to spdlog
> or fmtlib. openmpi bumped its version from 4.0.5 to 4.1.0 on 2020-12-21. I
> guess it's related to this change of openmpi.
> 
> 

Bug#962533: mlpack FTBFS on mips64el: relocation truncated to fit

[YunQiang Su]

Adrian Bunk  于 2020年6月9日周二 下午11:18写道：

> Source: mlpack
> Version: 3.3.1-1
> Severity: serious
> Tags: ftbfs
>
> It seems Boost 1.67 -> 1.71 increased something:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=mlpack&arch=mips64el&ver=3.3.1-1%2Bb1&stamp=1591444281&raw=0
>
> ...
> /usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -ftemplate-depth=1000
> -Wno-unused-function -O3 -fopenmp  -Wl,-z,relro -Wl,-z,now -rdynamic
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o  -o ../../../../bin/mlpack_cf
> -Wl,-rpath,/<>/obj-mips64el-linux-gnuabi64/lib:
> ../../../../lib/libmlpack.so.3.3 /usr/lib/libarmadillo.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_program_options.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_unit_test_framework.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_serialization.so -lpthread
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::basic_ostream >& std::operator<<  std::char_traits, std::allocator >(std::basic_ostream std::char_traits >&, std::__cxx11::basic_string std::char_traits, std::allocator > const&)':
> /usr/include/c++/9/bits/basic_string.h:6421:(.text+0x300): relocation
> truncated to fit: R_MIPS_CALL16 against `std::basic_ostream std::char_traits >& std::__ostream_insert std::char_traits >(std::basic_ostream
> >&, char const*, long)@@GLIBCXX_3.4.9'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function `void
> std::__cxx11::basic_string,
> std::allocator >::_M_construct(char*, char*,
> std::forward_iterator_tag)':
> /usr/include/c++/9/bits/basic_string.tcc:219:(.text+0x760): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string std::char_traits, std::allocator >::_M_create(unsigned long&,
> unsigned long)@@GLIBCXX_3.4.21'
> /usr/include/c++/9/bits/basic_string.tcc:233:(.text+0x7c0): relocation
> truncated to fit: R_MIPS_CALL16 against `__stack_chk_fail@@GLIBC_2.4'
> /usr/include/c++/9/bits/basic_string.tcc:212:(.text+0x7d0): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__throw_logic_error(char
> const*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `__gnu_cxx::new_allocator std::char_traits, std::allocator > >::allocate(unsigned long,
> void const*)':
> /usr/include/c++/9/ext/new_allocator.h:114:(.text+0xb34): relocation
> truncated to fit: R_MIPS_CALL16 against `operator new(unsigned
> long)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > >
> >::_S_check_init_len(unsigned long,
> std::allocator,
> std::allocator > > const&)':
> /usr/include/c++/9/bits/stl_vector.h:1767:(.text+0xbc4): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__throw_length_error(char
> const*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::__cxx11::basic_string,
> std::allocator >*
> std::__uninitialized_copy::__uninit_copy std::char_traits, std::allocator > const*,
> std::__cxx11::basic_string,
> std::allocator >*>(std::__cxx11::basic_string std::char_traits, std::allocator > const*,
> std::__cxx11::basic_string,
> std::allocator > const*, std::__cxx11::basic_string std::char_traits, std::allocator >*)':
> /usr/include/c++/9/bits/stl_uninitialized.h:86:(.text+0xbd0): relocation
> truncated to fit: R_MIPS_CALL16 against `__cxa_begin_catch@@CXXABI_1.3'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function `void
> std::_Destroy_aux::__destroy std::char_traits, std::allocator
> >*>(std::__cxx11::basic_string,
> std::allocator >*, std::__cxx11::basic_string std::char_traits, std::allocator >*)':
> /usr/include/c++/9/bits/stl_construct.h:107:(.text+0xbe0): relocation
> truncated to fit: R_MIPS_CALL16 against `__cxa_rethrow@@CXXABI_1.3'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::_Vector_base,
> std::allocator >, std::allocator std::char_traits, std::allocator > >
> >::_M_deallocate(std::__cxx11::basic_string,
> std::allocator >*, unsigned long)':
> /usr/include/c++/9/bits/stl_vector.h:350:(.text+0xbf8): relocation
> truncated to fit: R_MIPS_CALL16 against `operator
> delete(void*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `__gnu_cxx::new_allocator std::char_traits, std::allocator > >::~new_allocator()':
> /usr/include/c++/9/ext/new_allocator.h:89:(.text+0xc04): relocation
> truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::__cxx11::basic_string,
> std::allocator >::_M_dispose()':
> /usr/include/c++/9/bits/basic_string.h:231:(.text+0xc1c): additional
> relocation overflows omitted from the output
>

just add -mxgot to cxxflags.
there are 2 type of GOT in mips: one use fewer insn while has a length
limitaion; another uses more insns while has a big address space support.

collect2: error: ld returned 1 exit status
> make[4]: ***
> [src/mlpack/methods/cf/CMakeFiles/mlpack

Bug#953584: libsbml: FTBFS on mipsel

[YunQiang Su]

Andreas Tille  于2020年3月11日周三 下午4:00写道：
>
> Hi Ivo,
>
> On Tue, Mar 10, 2020 at 09:35:25PM +, Ivo De Decker wrote:
> > The latest upload of libsbml to unstable fails on mipsel:
> >
> > https://buildd.debian.org/status/package.php?p=libsbml
>
> This says:
>
> ...
> [100%] Building CXX object 
> src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o
> /tmp/ccOdlaux.s: Assembler messages:
> /tmp/ccOdlaux.s: Fatal error: can't close 
> CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o: memory exhausted
> make[4]: *** 
> [src/bindings/python/CMakeFiles/binding_python_lib.dir/build.make:645: 
> src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o] 
> Error 1
> make[4]: Leaving directory '/<>/build'
> make[3]: *** [CMakeFiles/Makefile2:694: 
> src/bindings/python/CMakeFiles/binding_python_lib.dir/all] Error 2
> ...
>
> If there is no chance to extend the memory on this porter machine I

Currently no...
In fact all of 32bit platform may meet this problem, and mipsel is the
first one.
It is not due to the lack of memory on build machine. Instead, it is
due to the 2GiB userspace memory limiation.
the value of i386 is 3GiB.

I have a plan to figure out a gcc64/binutils64 toolchain for these
32bit architectures.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950642
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950652

This schema cannot work on all 32bit architectures, since some of them
doesn't have paired 64bit machines.


> think the best idea is to exclude this architecture where probability
> that this package is used is pretty close to zero anyway.

You can do so for now.

>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
YunQiang Su

Bug#951237: glibc/mips: bpo patch: mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]

[YunQiang Su]

Package: src:glibc
Version: 2.29
Severity: serious

https://sourceware.org/bugzilla/show_bug.cgi?id=25523
https://sourceware.org/git/?p=glibc.git;a=commit;h=4fbba6fe904d0094ddc4284066b3860d119cbd4a

mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]

According to [gcc documentation][1], temporary variables must be used for
the desired content to not be call-clobbered.

Fix the Linux inline syscall templates by adding temporary variables,
much like what x86 did before
(commit 381a0c26d73e0f074c962e0ab53b99a6c327066d).

Tested with gcc 9.2.0, both cross-compiled and natively on Loongson
3A4000.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html

Bug#951115: ns3: FTBFS on mipsel (OOM of the linker)

[YunQiang Su]

Martin Quinson  于2020年2月11日周二 下午6:46写道：
>
> Source: src:ns3
> Version: 3.30+dfsg-3.1
> Severity: serious
> Tag: ftbfs
> Tag: help
>
> Hello,
>
> I'm the maintainer of this package. I'm opening this bug to discuss the issue
> with whom may be interested, and keep track of the discussion.

I am the first maintainer of ns3 and thanks for continue to maintain it.
And I am the mips* porter ...

>
> The package is currently trying to enter testing to fix 2 (easy) RC bugs, but
> fails to do so because builds fail on mipsel with the following message:

It's due to 2GiB virtual memory limitation.
I am working on figure out a host64 toolchain.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950527
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950652

>
> --
> as: out of memory allocating 17107680 bytes after a total of 567459840 bytes
> /tmp/cc23jwIU.s: Assembler messages:
> /tmp/cc23jwIU.s: Fatal error: can't close /<>/ns-3.30/build-
> shared/src/lte/bindings/ns3module.cc.7.o: memory exhausted
> --
>
> I tried to reduce the memory consumption with the following chunks in
> debian/rules:
>
> --
> ifeq ($(DEB_HOST_GNU_CPU),mipsel)
>   # Drop the debug symbols all together on mipsel to avoid OOM causing FTBFS
>   export DEB_CFLAGS_MAINT_STRIP=-g
>   export DEB_CXXFLAGS_MAINT_STRIP=-g
> endif
> LDFLAGS+=-Wl,--as-needed
>
> # Define CFLAGS and friends to harden the build -- must come any addition to
> these variables
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/buildflags.mk
>
> ifeq ($(DEB_HOST_GNU_CPU),mipsel)
>   # Further reduce the memory consumption on mipsel
>   LDFLAGS += -Wl,--reduce-memory-overheads -Wl,--no-keep-memory
> endif
> ---
>
> The version that failed on the buildd servers does not have these changes, but
> I tested it on the porterbox. I manually inspected the command-line parameters
> passed to the parser, and it seem to be all right. Compiling without -g and
> linking with the reduce-memory-overheads (unless I'm wrong). But this is not
> sufficient: I get exactly the same error message.
>
> In addition, I don't think that this is a real bug of as. ns-3 is a very large
> library, and upstream is not paying a lot of effort on reducing its size or
> optimizing the linking phase. I don't have any idea of how to fix it myself.
>

I guess you can drop mipsel support for now,
and maybe some other 32bit ports.

>
> I guess that I should ask for the removal of the mipsel version of this
> package, but I'm not entirely sure. I'd love to have ns-3 building on

Go ahead.

> every platform, even if I'm certain that nobody will ever try to use
> it on this platform. This is a rather inefficient simulator used in
> science. Users will more probably deploy it to a fast compute server.
> But still, if possible, being compilable on mipsel too would be
> healthy for the software, if I could.
>
> Any help or advice is really really welcomed. Everything is in the salsa 
> repository.
>
> Thanks,
> Mt
>
> --
> Vae Soli.



-- 
YunQiang Su

Bug#950525: broken symlink: /usr/lib/gcc//9/libgcc_s.so{,.1}

[YunQiang Su]

Package: src:gcc-9
Version: 9.2.1-25
Severity: serious
X-Debug-Cc: debian-s...@lists.debian.org

On i386
# file /usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1
/usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1: broken symbolic link to
/lib/i386-linux-gnu/libgcc_s.so.1

On s390x:
$ file /usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so*
/usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so: broken symbolic link to
/lib/s390x-linux-gnu/libgcc_s.so.1

Which make some packages ftbfs on s390x:
https://buildd.debian.org/status/fetch.php?pkg=zlib&arch=s390x&ver=1%3A1.2.11.dfsg-1.2&stamp=1580704985&raw=0

Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[YunQiang Su]

> test num/mod.rs - sync::atomic::AtomicI8::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_min (line 62) ... FAILED
> command did not execute successfully: "/usr/bin/cargo" "test" 
> "-Zconfig-profile" "--target" "mipsel-unknown-linux-gnu" 
> "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "--release" "--features" 
> "panic-unwind backtrace" "--manifest-path" 
> "/<>/src/libtest/Cargo.toml" "--no-fail-fast" "-p" "core" "--"
> test stats::tests::test_min_max_nan ... FAILED
> command did not execute successfully: "/usr/bin/cargo" "test" 
> "-Zconfig-profile" "--target" "mipsel-unknown-linux-gnu" 
> "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "--release" "--features" 
> "panic-unwind backtrace" "--manifest-path" 
> "/<>/src/libtest/Cargo.toml" "--no-fail-fast" "-p" "test" "--"
> test [run-make] run-make-fulldeps/relocation-model ... FAILED
> command did not execute successfully: 
> "/<>/build/mipsel-unknown-linux-gnu/stage0-tools-bin/compiletest"
>  "--compile-lib-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/lib" "--run-lib-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/lib/rustlib/mipsel-unknown-linux-gnu/lib"
>  "--rustc-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/bin/rustc" 
> "--rustdoc-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/bin/rustdoc" 
> "--src-base" "/<>/src/test/run-make-fulldeps" "--build-base" 
> "/<>/build/mipsel-unknown-linux-gnu/test/run-make-fulldeps" 
> "--stage-id" "stage2-mipsel-unknown-linux-gnu" "--mode" "run-make" "--target" 
> "mipsel-unknown-linux-gnu" "--host" "mipsel-unknown-linux-gnu" 
> "--llvm-filecheck" "/usr/lib/llvm-8/bin/FileCheck" "--linker" 
> "mipsel-linux-gnu-gcc" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 
> -Zunstable-options  
> -Lnative=/<>/build/mipsel-unknown-linux-gnu/native/rust-test-helpers"
>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
> -Lnative=/<>/build/mipsel-unknown-linux-gnu/native/rust-test-helpers"
>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
> "--cc" "cc" "--cxx" "c++" "--cflags" "-ffunction-sections -fdata-sections 
> -fPIC -g -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security" "--llvm-components" "aarch64 
> aarch64asmparser aarch64asmprinter aarch64codegen aarch64desc 
> aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all 
> all-targets amdgpu amdgpuasmparser amdgpuasmprinter amdgpucodegen amdgpudesc 
> amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser 
> armasmprinter armcodegen armdesc armdisassembler arminfo armutils asmparser 
> asmprinter avr avrasmparser avrasmprinter avrcodegen avrdesc avrdisassembler 
> avrinfo binaryformat bitreader bitwriter bpf bpfasmparser bpfasmprinter 
> bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage 
> debuginfocodeview debuginfodwarf debuginfomsf debuginfopdb demangle 
> dlltooldriver engine executionengine fuzzmutate globalisel hexagon 
> hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo 
> instcombine instrumentation interpreter ipo irreader lanai lanaiasmparser 
> lanaiasmprinter lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver 
> lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser 
> mipsasmprinter mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser 
> msp430 msp430asmparser msp430asmprinter msp430codegen msp430desc 
> msp430disassembler msp430info native nativecodegen nvptx nvptxasmprinter 
> nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option 
> optremarks orcjit passes perfjitevents powerpc powerpcasmparser 
> powerpcasmprinter powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo 
> profiledata runtimedyld scalaropts selectiondag sparc sparcasmparser 
> sparcasmprinter sparccodegen sparcdesc sparcdisassembler sparcinfo support 
> symbolize systemz systemzasmparser systemzasmprinter systemzcodegen 
> systemzdesc systemzdisassembler systemzinfo tablegen target textapi 
> transformutils vectorize webassembly webassemblyasmparser 
> webassemblyasmprinter webassemblycodegen webassemblydesc 
> webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser 
> x86asmprinter x86codegen x86desc x86disassembler x86info x86utils xcore 
> xcoreasmprinter xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" 
> "--llvm-cxxflags" "-I/usr/lib/llvm-8/include -std=c++11  -fno-exceptions 
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" "--ar" 
> "ar" "--llvm-bin-dir" "/usr/lib/llvm-8/bin" "--adb-path" "adb" 
> "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
> Summary: exit code 1, counted 42 tests failed.
> 24 maximum allowed. Aborting the build.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


-- 
YunQiang Su

Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[YunQiang Su]

 FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU16::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU32::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicU8::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicUsize::fetch_min (line 62) ... FAILED
> command did not execute successfully: "/usr/bin/cargo" "test" 
> "-Zconfig-profile" "--target" "mipsel-unknown-linux-gnu" 
> "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "--release" "--features" 
> "panic-unwind backtrace" "--manifest-path" 
> "/<>/src/libtest/Cargo.toml" "--no-fail-fast" "-p" "core" "--"
> test stats::tests::test_min_max_nan ... FAILED
> command did not execute successfully: "/usr/bin/cargo" "test" 
> "-Zconfig-profile" "--target" "mipsel-unknown-linux-gnu" 
> "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "--release" "--features" 
> "panic-unwind backtrace" "--manifest-path" 
> "/<>/src/libtest/Cargo.toml" "--no-fail-fast" "-p" "test" "--"
> test [run-make] run-make-fulldeps/relocation-model ... FAILED
> command did not execute successfully: 
> "/<>/build/mipsel-unknown-linux-gnu/stage0-tools-bin/compiletest"
>  "--compile-lib-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/lib" "--run-lib-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/lib/rustlib/mipsel-unknown-linux-gnu/lib"
>  "--rustc-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/bin/rustc" 
> "--rustdoc-path" 
> "/<>/build/mipsel-unknown-linux-gnu/stage2/bin/rustdoc" 
> "--src-base" "/<>/src/test/run-make-fulldeps" "--build-base" 
> "/<>/build/mipsel-unknown-linux-gnu/test/run-make-fulldeps" 
> "--stage-id" "stage2-mipsel-unknown-linux-gnu" "--mode" "run-make" "--target" 
> "mipsel-unknown-linux-gnu" "--host" "mipsel-unknown-linux-gnu" 
> "--llvm-filecheck" "/usr/lib/llvm-8/bin/FileCheck" "--linker" 
> "mipsel-linux-gnu-gcc" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 
> -Zunstable-options  
> -Lnative=/<>/build/mipsel-unknown-linux-gnu/native/rust-test-helpers"
>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
> -Lnative=/<>/build/mipsel-unknown-linux-gnu/native/rust-test-helpers"
>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
> "--cc" "cc" "--cxx" "c++" "--cflags" "-ffunction-sections -fdata-sections 
> -fPIC -g -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security" "--llvm-components" "aarch64 
> aarch64asmparser aarch64asmprinter aarch64codegen aarch64desc 
> aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all 
> all-targets amdgpu amdgpuasmparser amdgpuasmprinter amdgpucodegen amdgpudesc 
> amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser 
> armasmprinter armcodegen armdesc armdisassembler arminfo armutils asmparser 
> asmprinter avr avrasmparser avrasmprinter avrcodegen avrdesc avrdisassembler 
> avrinfo binaryformat bitreader bitwriter bpf bpfasmparser bpfasmprinter 
> bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage 
> debuginfocodeview debuginfodwarf debuginfomsf debuginfopdb demangle 
> dlltooldriver engine executionengine fuzzmutate globalisel hexagon 
> hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo 
> instcombine instrumentation interpreter ipo irreader lanai lanaiasmparser 
> lanaiasmprinter lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver 
> lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser 
> mipsasmprinter mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser 
> msp430 msp430asmparser msp430asmprinter msp430codegen msp430desc 
> msp430disassembler msp430info native nativecodegen nvptx nvptxasmprinter 
> nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option 
> optremarks orcjit passes perfjitevents powerpc powerpcasmparser 
> powerpcasmprinter powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo 
> profiledata runtimedyld scalaropts selectiondag sparc sparcasmparser 
> sparcasmprinter sparccodegen sparcdesc sparcdisassembler sparcinfo support 
> symbolize systemz systemzasmparser systemzasmprinter systemzcodegen 
> systemzdesc systemzdisassembler systemzinfo tablegen target textapi 
> transformutils vectorize webassembly webassemblyasmparser 
> webassemblyasmprinter webassemblycodegen webassemblydesc 
> webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser 
> x86asmprinter x86codegen x86desc x86disassembler x86info x86utils xcore 
> xcoreasmprinter xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" 
> "--llvm-cxxflags" "-I/usr/lib/llvm-8/include -std=c++11  -fno-exceptions 
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" "--ar" 
> "ar" "--llvm-bin-dir" "/usr/lib/llvm-8/bin" "--adb-path" "adb" 
> "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
> Summary: exit code 1, counted 42 tests failed.
> 24 maximum allowed. Aborting the build.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


-- 
YunQiang Su

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

YunQiang Su  于2019年11月30日周六 上午11:19写道：
>
> YunQiang Su  于2019年11月29日周五 下午2:21写道：
> >
> > 在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> > > On 28.11.19 18:09, YunQiang Su wrote:
> > > > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > > > Package: src:gcc-9
> > > > > > Version: 9.2.1-20
> > > > > > Severity: serious
> > > > > > Tags: sid bullseye
> > > > > >
> > > > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > > > likely triggered
> > > > > > by the LTO build enabled in -20.
> > > > > >
> > > > > > bootstrap comparison failure!
> > > > > > libbacktrace/elf.o differs
> > > > > > libbacktrace/.libs/elf.o differs
> > > > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > > >
> > > > > Please could you have a look?
> > > >
> > > > sure. I will look at it tomorrow
> > >
> > > hmm, that also fails in gcc-7, which didn't see any code changes from
> > > 7.5.0-1 to
> > > 7.5.0-2.
> >
> > Maybe, it meets a buggy machine?
>
> due to the Loongson's patch to add sync?

I am sure that this is due to that change.
So, please rollback that changes for now. I will try to dig out why.

>
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

YunQiang Su  于2019年11月29日周五 下午2:21写道：
>
> 在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> > On 28.11.19 18:09, YunQiang Su wrote:
> > > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > > Package: src:gcc-9
> > > > > Version: 9.2.1-20
> > > > > Severity: serious
> > > > > Tags: sid bullseye
> > > > >
> > > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > > likely triggered
> > > > > by the LTO build enabled in -20.
> > > > >
> > > > > bootstrap comparison failure!
> > > > > libbacktrace/elf.o differs
> > > > > libbacktrace/.libs/elf.o differs
> > > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > >
> > > > Please could you have a look?
> > >
> > > sure. I will look at it tomorrow
> >
> > hmm, that also fails in gcc-7, which didn't see any code changes from
> > 7.5.0-1 to
> > 7.5.0-2.
>
> Maybe, it meets a buggy machine?

due to the Loongson's patch to add sync?

>


-- 
YunQiang Su

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> On 28.11.19 18:09, YunQiang Su wrote:
> > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > Package: src:gcc-9
> > > > Version: 9.2.1-20
> > > > Severity: serious
> > > > Tags: sid bullseye
> > > > 
> > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > likely triggered
> > > > by the LTO build enabled in -20.
> > > > 
> > > > bootstrap comparison failure!
> > > > libbacktrace/elf.o differs
> > > > libbacktrace/.libs/elf.o differs
> > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > 
> > > Please could you have a look?
> > 
> > sure. I will look at it tomorrow
> 
> hmm, that also fails in gcc-7, which didn't see any code changes from
> 7.5.0-1 to
> 7.5.0-2.

Maybe, it meets a buggy machine?

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

Matthias Klose  于2019年11月28日周四 下午5:51写道：
>
> On 28.11.19 10:44, Matthias Klose wrote:
> > Package: src:gcc-9
> > Version: 9.2.1-20
> > Severity: serious
> > Tags: sid bullseye
> >
> > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most likely 
> > triggered
> > by the LTO build enabled in -20.
> >
> > bootstrap comparison failure!
> > libbacktrace/elf.o differs
> > libbacktrace/.libs/elf.o differs
> > make[4]: *** [Makefile:24878: compare] Error 1
>
> Please could you have a look?

sure. I will look at it tomorrow

>


-- 
YunQiang Su

Bug#941919: fixed in libopengl-perl 0.7000+dfsg-4

[YunQiang Su]

On Mon, 07 Oct 2019 16:34:50 + gregor herrmann  wrote:
> Source: libopengl-perl
> Source-Version: 0.7000+dfsg-4
>
> We believe that the bug you reported is fixed in the latest version of
> libopengl-perl, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.

This patch doesn't work with mesa 18.
So you should Build-Deps with mesa >= 19~

>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 941...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> gregor herrmann  (supplier of updated libopengl-perl 
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon,  7 Oct 2019 18:10:42 CEST
> Source: libopengl-perl
> Binary:
> Architecture: source
> Version: 0.7000+dfsg-4
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Perl Group 
> Changed-By: gregor herrmann 
> Description:
> Closes: 941919
> Changes:
>  libopengl-perl (0.7000+dfsg-4) unstable; urgency=medium
>  .
>* Update debian/patches/glext.patch.
>  The old way of copying #include's into glext_types.h does not work 
> anymore
>  with mesa 19.x. Adjust utils/glext_procs.pl.
>  (Closes: #941919)
>* Declare compliance with Debian Policy 4.4.1.
>* Use debhelper-compat.
>* debian/watch: use uscan version 4.
>* Remove obsolete fields Name, Contact from debian/upstream/metadata.
> Checksums-Sha256:
>  19644041c83f6147607b6114caf78697acf0b536dbaf6828f3810eda81d36898 2407 
> libopengl-perl_0.7000+dfsg-4.dsc
>  b1c8450c9a088d5d19bf5d5bfd3ac89d02309db2769925abc9787afc8497161b 12528 
> libopengl-perl_0.7000+dfsg-4.debian.tar.xz
>  a8587c750ac28306ed7ec3e650984f860b849ccb5143de92cff3bd611d2bd508 8601 
> libopengl-perl_0.7000+dfsg-4_sourceonly.buildinfo
> Checksums-Sha1:
>  45b98890f9742e9cceaefe9c45a8338b85e4987c 2407 
> libopengl-perl_0.7000+dfsg-4.dsc
>  834b2e7cb8c4ca188eb608c3925414c05149 12528 
> libopengl-perl_0.7000+dfsg-4.debian.tar.xz
>  57175e40e5c222746d6886fac41dd92b8ffc5f9e 8601 
> libopengl-perl_0.7000+dfsg-4_sourceonly.buildinfo
> Files:
>  330e134cf7d85dc612c51f680dd83993 2407 perl optional 
> libopengl-perl_0.7000+dfsg-4.dsc
>  d1cc26de136dca2cc96f726a67296133 12528 perl optional 
> libopengl-perl_0.7000+dfsg-4.debian.tar.xz
>  975e78b5957655a90bd041944fc43799 8601 - - 
> libopengl-perl_0.7000+dfsg-4_sourceonly.buildinfo

Bug#933958: golang-1.12: ftbfs with golang-1.12

[YunQiang Su]

Package: src:golang-1.12
Version: 1.12.7-2
Severity: serious

As golang defaults has been upgrade to golang-1.12.
With the test of build golang-1.12, I meet the same problem on
amd64 as currently mipsel.

failed to initialize build cache at
/sbuild-nonexistent/.cache/go-build: mkdir /sbuild-nonexistent:
permission denied

https://buildd.debian.org/status/fetch.php?pkg=golang-1.12&arch=mipsel&ver=1.12.7-2&stamp=1564842229&raw=0

-- 
YunQiang Su

Bug#932287: glib2.0: FTBFS on mips64el: linking 32-bit code with 64-bit code

[YunQiang Su]

Simon McVittie  于2019年7月18日周四 上午2:03写道：
>
> On Wed, 17 Jul 2019 at 12:18:14 +0100, Simon McVittie wrote:
> > It looks like the culprit might be commit 
> > d04b9c371d277fa45ba20ad83642e57af50381e7:
> > https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
> > Is that objcopy invocation wrong for mips64el? Does mips64el objcopy perhaps
> > default to a different ABI?
>
> Looks like plain objcopy produces MIPS-I objects, whereas invoking it
> in the normal way via the compiler frontend produces MIPS64r2 objects:
>
> (sid_mips64el-dchroot)smcv@eller ~/glib % file 
> debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o
> debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o: ELF 64-bit LSB 
> relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), with debug_info, not stripped
> (sid_mips64el-dchroot)smcv@eller ~/glib % file 
> debian/build/deb/gio/tests/test_resources2.o
> debian/build/deb/gio/tests/test_resources2.o: ELF 64-bit LSB relocatable, 
> MIPS, MIPS-I version 1 (SYSV), not stripped
>

I guess you are right, objcopy doesn't alter the object file correctly.
We need to patch it.

> Regards,
> smcv
>


-- 
YunQiang Su

Bug#921198: mipsel speed: UTM8 vs Loongson 3A (was: Bug#921198: hard to track down)

[YunQiang Su]

Andreas Metzler  于2019年2月3日周日 下午6:51写道：
>
> On 2019-02-03 Willi Mann  wrote:
> > just for the record, I tried to reproduce the build failure on eller
> > (mipsel porterbox), but it builds fine there. I'm wondering whether the
> > timeout set on line 232 of tests/srp.c (40 seconds) is too short for
> > slower build hosts.
>
> Hello,
>
> The two builds on mipsel-aql-01.debian and mipsel-aql-02.debian.org
> (both Processor: LS3A-RS780-1w (Quad Core Loongson 3A))failed, the third
> try on mipsel-sil-01.debian.org (Processor: Rhino Labs UTM8) succeeded.
>
> Eller also has the same hardware (Processor: Rhino Labs UTM8) as the
> succeeding build-machine and gnutls builds reliably there. The failing
> test (srp) takes 22 seconds there.

Cavium's CPU works well much better than Loongson's

>
> Is the Loongson that much slower?

In generally, it is not due to Loongson is slower, but about the
Loongson's CPU is buggy.
https://patchwork.linux-mips.org/patch/21333/

We are working on add more Cavium's machines.
And Loongson claims that their future CPU won't be so buggy.

@Aurelien, gnutls28 should be another packages that should be pinned
on Cavium's CPU.

>
> cu Andreas
> (x-debbugs-cc-ing both Willi and porter mailing list)
> --
> `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'
>


-- 
YunQiang Su

Bug#864340: mariadb-10.1 FTBFS on mips64el on Loongson: Installing system database killed with signal TERM after 150 minutes of inactivity

[YunQiang Su]

Adrian Bunk  于2017年6月7日周三 下午4:33写道：
>
> Source: mariadb-10.1
> Version: 10.1.22-3
> Severity: serious
>
> https://buildd.debian.org/status/logs.php?pkg=mariadb-10.1&arch=mips64el
>
> ...
> # Run testsuite
> cd builddir/mysql-test && ./mtr --force --testcase-timeout=30 
> --suite-timeout=540 --retry=3 --parallel=4 --skip-test-list=unstable-tests  
> || exit 1 ;
> Logging: /«PKGBUILDDIR»/mysql-test/mysql-test-run.pl  --force 
> --testcase-timeout=30 --suite-timeout=540 --retry=3 --parallel=4 
> --skip-test-list=unstable-tests
> vardir: /«PKGBUILDDIR»/builddir/mysql-test/var
> Removing old var directory...
> Creating var directory '/«PKGBUILDDIR»/builddir/mysql-test/var'...
> Checking supported features...
> MariaDB Version 10.1.24-MariaDB-3
>  - SSL connections supported
> Sphinx 'indexer' binary not found, sphinx suite will be skipped
> Using suites: 
> main-,archive-,binlog-,binlog_encryption-,csv-,encryption-,federated-,funcs_1-,funcs_2-,handler-,heap-,innodb-,innodb_fts-,innodb_zip-,maria-,mariabackup-,multi_source-,optimizer_unfixed_bugs-,parts-,percona-,perfschema-,plugins-,roles-,rpl-,sys_vars-,unit-,vcol-,wsrep-,connect,mroonga/wrapper,mroonga/storage,oqgraph,sequence,spider,spider/bg,sql_discovery,metadata_lock_info,query_response_time
> Collecting tests...
> Installing system database...
> debian/rules:92: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Terminated
> E: Caught signal ‘Terminated’: terminating immediately
> make: *** wait: No child processes.  Stop.
> make: *** Waiting for unfinished jobs
> make: *** wait: No child processes.  Stop.
> Build killed with signal TERM after 150 minutes of inactivity
>
>
> It seems to always fail on Loongson buildds but never on others.

Yes. Loongson has some bugs, and I am working on workaround it with
patch toolchain.
I just looking for the example. thank you.

>
> Based on how it fails, I suspect mariadb-10.1 on mips64el is
> completely broken on Loongson.



-- 
YunQiang Su

Bug#886907: libgadu: ftbfs due to -Werror and gnutls_compression_get_name deprecated

[YunQiang Su]

Package: libgadu
Version: 1:1.12.2-2
Severity: serious

With recent rebuild libgadu, it failed to build, as it use -Werror,
and gnutls_compression_get_name, while this function is marked as
deprecated now.

-- 
YunQiang Su

Bug#884331: python3-defaults: please update, as python3-distutils cannot install now

[YunQiang Su]

Package: python3-defaults
Version: 3.6.3-2
Severity: grave

python3-distutils depends on python3>=3.6.4~rc1,
while the current python3-default is still 3.6.3-2.

Please update the python3-defaults package.


-- 
YunQiang Su

Bug#879636: #879636: virtual memory exhausted: Cannot allocate memory

[YunQiang Su]

I guess we should set this param for mips/mipsel by default?

On Thu, Nov 23, 2017 at 5:20 AM, Mathieu Malaterre  wrote:
> On Wed, Nov 22, 2017 at 2:24 PM, Mathieu Malaterre  wrote:
>> Dear mips gurus,
>>
>> Could someone please suggest a fix for the following FTBFS issue for
>> OpenVDB package:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=mipsel&ver=4.0.2-1&stamp=1508213166&raw=0
>>
>> Thanks much
>
> Turns out that --param ggc-min-expand=10 worked just fine on eller.d.o.
>
> Sorry for the noise,
>



-- 
YunQiang Su

Bug#785565: [Ns-developers] State of ns3 in the Debian distribution

[YunQiang Su]

Sorry for everyone.
I didn't take care of ns3 for years.

I will update it in few days.

On Thu, Oct 5, 2017 at 3:54 AM, Martin Quinson
 wrote:
> Hello Tom, thanks for your reply.
>
> On Wed, Oct 04, 2017 at 06:08:01PM +, Tom Henderson wrote:
>> Hi Martin, responses inline below.
>>
>> On 10/04/2017 05:26 AM, Martin Quinson wrote:
>> > Hello dear developers,
>> >
>> > Also, if you have an easy way to drop these dependencies (by disabling
>> > them at build time), that could solve the issue on our side.  I know I
>> > should RTFM for that, but I fail to find the time, and I would
>> > appreciate this help in the package maintainance, please. The current
>> > build receipe is here (that's a makefile):
>> > http://sources.debian.net/src/ns3/3.26%2Bdfsg-1/debian/rules/
>> There isn't an ns-3 build dependency on netanim.  The pyviz visualizer is
>> automatically left out of the configuration if the prerequisites are not
>> found by Waf.  Is this sufficient (if we don't resolve these package
>> dependencies in time)?
>
> Ok, then I will rebuild the package without that dependency, upload
> it, and it should do the trick for now, I guess. I'll keep you posted.
>
>> We are about to make a new ns-3 release (3.27).  We also noticed that the
>> netanim package in Debian stretch is very old (3.100+ while we are now at
>> 3.108).  Can we work towards replacing the old versions with the new
>> versions in the current release of Debian, or must we wait until the next
>> Debian release?
>
> There is a plenty of time before the next official Debian release
> (maybe one year and half). So we can definitely work something out for
> Debian. Ubuntu regularly picks the packages in the Debian rolling
> release as a basis for their own releases, but I'm unaware of their
> schedule. I'd say that March 2018 is the target for the next LTS
> release of Ubuntu.
>
> The problem is that I have personnally I don't have any personal
> interest in netanim myself, and absolutely no time to devote to that
> task. If you can come up with a patch against the packaging scripts
> that refresh it, I can certainly mentor the package upload.
>
> Thanks, Mt.
>
> --
> It's so easy to laugh, it's so easy to hate,
> it takes strength to be gentle and kind.  -- Morrissey, I Know It's Over.



-- 
YunQiang Su

Bug#848574: Fwd: Re: [open-mpi/ompi] Failure on mips64el (#2922)

[YunQiang Su]

The package in experimental (2.0.2-1) seems having no this problem.

On Sun, 5 Feb 2017 19:11:04 + Alastair McKinstry
 wrote:
> This hints at a linker issue on stretch
>
>  Forwarded Message 
> Subject: Re: [open-mpi/ompi] Failure on mips64el (#2922)
> Date: Sun, 05 Feb 2017 09:18:36 -0800
> From: Paul H. Hargrove 
> Reply-To: open-mpi/ompi
> 
>
> To: open-mpi/ompi 
> CC: Alastair McKinstry , Author
> 
>
>
>
> @ggouaillardet 
> Yes, I have both mips64 and mips64el and test thee ABIs
> (|-mabi={32,n32,64}|) on each.
> All 6 passed my testing of 2.0.2rc4, which included running the ring
> examples (|ring_{c,mpih,usempi,usempif08}|) with two ranks on 1 node.
> My tests are on Octeon II systems running Debian Wheezy, and are not
> mine to upgrade.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> .
>

Bug#848574: openmpi: frequent segfault in linker on mips64el

[YunQiang Su]

On Sun, 18 Dec 2016 13:44:32 + Ansgar Burchardt  wrote:
> Package: libopenmpi-dev
> Version: 2.0.2~git.20161225-8
> Severity: important
>
> [ CC'ed debian-mips@ as a segfault in the linker might not be a bug in MPI ]
>
> OpenMPI crashed frequenly in the runtime linker on mips64el, even for a
> trivial program calling just MPI_Init and MPI_Finalize:
>
> +---
> | #include 
> |
> | int main(int argc, char** argv)
> | {
> |   MPI_Init(&argc, &argv);
> |   MPI_Finalize();
> |   return 0;
> | }
> +---[ test.cc ]
>
> After building with `mpic++ -o test test.cc`, I often get the following
> backtrace from the core file:
>
> +---
> | Core was generated by `./test'.
> | Program terminated with signal SIGSEGV, Segmentation fault.
> | #0  elf_machine_runtime_link_map (gpreg=, 
> stub_pc=1099310712688)
> | at ../sysdeps/mips/dl-trampoline.c:84
> | 84 ../sysdeps/mips/dl-trampoline.c: No such file or directory.
> | [Current thread is 1 (LWP 2837)]
> | (gdb) bt
> | #0  elf_machine_runtime_link_map (gpreg=, 
> stub_pc=1099310712688)
> | at ../sysdeps/mips/dl-trampoline.c:84
> | #1  __dl_runtime_resolve (sym_index=151, return_address=, 
> old_gpreg=,
> | stub_pc=1099310712688) at ../sysdeps/mips/dl-trampoline.c:125
> | #2  0x00fff5e341ac in _dl_runtime_resolve () from /lib64/ld.so.1
> | Backtrace stopped: frame did not save the PC
> +---[ backtrace from `gdb ./test core` ]

It is quite strange that it won't fail if run with gdb.

>
> I noticed as src:dune-common/2.5.0-1 failed on mips64el even though the last
> upload build sucessfully.
>
> Ansgar
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: mips64el (mips64)
>
> Kernel: Linux 4.7.0-0.bpo.1-octeon (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
>
> Versions of packages libopenmpi-dev depends on:
> ii  libc6   2.24-8
> ii  libhwloc-dev1.11.5-1
> ii  libhwloc5   1.11.5-1
> ii  libibverbs-dev  1.2.1-2

Bug#851412: FTBFS on mips*, tests fail with SIGSEGV

[YunQiang Su]

On Sun, Jan 15, 2017 at 1:15 AM, Michael Biebl  wrote:
> Am 14.01.2017 um 18:02 schrieb Michael Biebl:
>
>> binutils_2.27.90.20170114-1. Building in stretch chroot though was
>> successful. So my observation is:
>>
>> binutils_2.27.90.20170114-1: fails
>> binutils_2.27.90.20170113-1: fails
>> binutils_2.27.51.20161220-1: ok
>>
>> So it looks like a mips related regression in binutils at a first
>> glance. In the past, systemd built reasonably reliably on mips* [3].
>
> A notable difference (aside from binutils) between the sid and stretch
> chroot is gcc-6, which is at version 6.2.1-5 in stretch and 6.3.0-2 in
> unstable.
> I couldn't test this combination (old binutils + new gcc) on the porter
> boxes though.
>

I tried to build a package libsystemd0-dbgsym, and test it with gdb,
it seems all binary linked with libsystemd will fail.

root@thor:/tmp# gdb /usr/bin/top
GNU gdb (Debian 7.12-4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64el-linux-gnuabi64".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/top...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/top
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/mips64el-linux-gnuabi64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
_IO_new_fclose (fp=0x1) at iofclose.c:48
48  iofclose.c: No such file or directory.
(gdb) bt
#0  _IO_new_fclose (fp=0x1) at iofclose.c:48
#1  0x00fff7c96d28 in _init () from
/lib/mips64el-linux-gnuabi64/libsystemd.so.0
#2  0x00fff7fdb9d0 in call_init (l=0xfff7fc4120,
argc=argc@entry=1, argv=argv@entry=0xfff5c8,
env=env@entry=0xfff5d8) at dl-init.c:58
#3  0x00fff7fdbba8 in call_init (env=0xfff5d8,
argv=0xfff5c8, argc=1, l=) at dl-init.c:30
#4  _dl_init (main_map=0xfff7fff848, argc=,
argv=0xfff5c8, env=0xfff5d8) at dl-init.c:120
#5  0x00fff7fca450 in _dl_start_user () from /lib64/ld.so.1
Backtrace stopped: frame did not save the PC


It seems that binutils generate bad shared lib.


> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



-- 
YunQiang Su

Bug#851412: FTBFS on mips*, tests fail with SIGSEGV

[YunQiang Su]

On Sun, Jan 15, 2017 at 1:15 AM, Michael Biebl  wrote:
> Am 14.01.2017 um 18:02 schrieb Michael Biebl:
>
>> binutils_2.27.90.20170114-1. Building in stretch chroot though was
>> successful. So my observation is:
>>
>> binutils_2.27.90.20170114-1: fails
>> binutils_2.27.90.20170113-1: fails
>> binutils_2.27.51.20161220-1: ok
>>
>> So it looks like a mips related regression in binutils at a first
>> glance. In the past, systemd built reasonably reliably on mips* [3].
>
> A notable difference (aside from binutils) between the sid and stretch
> chroot is gcc-6, which is at version 6.2.1-5 in stretch and 6.3.0-2 in
> unstable.
> I couldn't test this combination (old binutils + new gcc) on the porter
> boxes though.
>

I tried to build a package libsystemd0-dbgsym, and test it with gdb,
it seems all binary linked with libsystemd will fail.

root@thor:/tmp# gdb /usr/bin/top
GNU gdb (Debian 7.12-4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64el-linux-gnuabi64".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/top...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/top
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/mips64el-linux-gnuabi64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
_IO_new_fclose (fp=0x1) at iofclose.c:48
48  iofclose.c: No such file or directory.
(gdb) bt
#0  _IO_new_fclose (fp=0x1) at iofclose.c:48
#1  0x00fff7c96d28 in _init () from
/lib/mips64el-linux-gnuabi64/libsystemd.so.0
#2  0x00fff7fdb9d0 in call_init (l=0xfff7fc4120,
argc=argc@entry=1, argv=argv@entry=0xfff5c8,
env=env@entry=0xfff5d8) at dl-init.c:58
#3  0x00fff7fdbba8 in call_init (env=0xfff5d8,
argv=0xfff5c8, argc=1, l=) at dl-init.c:30
#4  _dl_init (main_map=0xfff7fff848, argc=,
argv=0xfff5c8, env=0xfff5d8) at dl-init.c:120
#5  0x00fff7fca450 in _dl_start_user () from /lib64/ld.so.1
Backtrace stopped: frame did not save the PC


It seems that binutils generate bad shared lib.


> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



-- 
YunQiang Su

Bug#834856: [Debian-med-packaging] Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[YunQiang Su]

On Fri, Oct 14, 2016 at 3:47 PM, Emilio Pozuelo Monfort
 wrote:
> Control: severity -1 serious
>
> On Fri, 19 Aug 2016 22:29:48 -0700 Afif Elghraoui  wrote:
>> Control: severity -1 important
>> Control: tag -1 + help
>>
>> Hello and thank you for the report.
>>
>> على الجمعـة 19 آب 2016 ‫14:48، كتب Jonathan Jackson:
>> > Package: python-pysam
>> > Version: 0.9.1.4+ds-1
>> > Severity: grave
>> > Justification: renders package unusable
>> >
>>
>> While the package may be unusable on mips64el, it works well for the
>> vast majority of users as I understand it, so this situation deserves a
>> severity of 'important' rather than 'grave'.
>
> mips64el is a release architecture, thus this bug is serious.

mips64el seems building successfully now, while mipsel fails.
I guess it is due to Loongson machine.

Let me have a give-back on mipsel.

>
>> > Python-pysam packages failed to build on March 24th on a mips64el
>> > architecture. Here is the tail of the failed-build log:
>> >
>> [...]
>>
>> I'd be happy to apply any patch that resolves this problem, but porting
>> work is beyond what I can commit to do for this package.
>
> Cc'ing debian-mips, maybe they can provide some help.
>
> Cheers,
> Emilio
>



-- 
YunQiang Su

Bug#826446: NMU

[YunQiang Su]

On Tue, 16 Aug 2016 20:47:32 +0800 "gustavo panizzo (gfa)"
 wrote:
> Hello
>
> I'm preparing an NMU for this package, I will push it on the next days

I uploaded this package, so you won't need to nmu it.
Thank you very much.

>
> cheers
>
> --
> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
>
> keybase: https://keybase.io/gfa

Bug#826937: libgnatprj6: undefined symbol: __gnat_objlist_file_supported

[YunQiang Su]

On Fri, Jun 17, 2016 at 9:58 PM, YunQiang Su  wrote:
> On Fri, 10 Jun 2016 10:08:11 +0200 Emilio Pozuelo Monfort
>  wrote:
>> Package: libgnatprj6
>> Version: 6.1.1-6
>> Severity: serious
>>
>> A few days ago, libgnatprj6 was working just fine. However it looks like
>> one of the recent uploads has broken it, causing undefined references:
>>
>> https://buildd.debian.org/status/logs.php?pkg=asis&ver=2015-1%2Bb1
>> https://buildd.debian.org/status/logs.php?pkg=libgnatcoll&ver=1.7gpl2015-1%2Bb3
>> https://buildd.debian.org/status/logs.php?pkg=libgtkada&ver=3.8.3-1%2Bb2
>
> With the attached patch, gprbuild can executable correctly, and the above
> package can be built.
>
> To build prefix.c for target, I have to get a config.h file and define
> some macro.
>

With this patch, the cross build also successfully.

>>
>> Cheers,
>> Emilio
>>
>>



-- 
YunQiang Su

Bug#826937: libgnatprj6: undefined symbol: __gnat_objlist_file_supported

[YunQiang Su]

On Fri, 10 Jun 2016 10:08:11 +0200 Emilio Pozuelo Monfort
 wrote:
> Package: libgnatprj6
> Version: 6.1.1-6
> Severity: serious
>
> A few days ago, libgnatprj6 was working just fine. However it looks like
> one of the recent uploads has broken it, causing undefined references:
>
> https://buildd.debian.org/status/logs.php?pkg=asis&ver=2015-1%2Bb1
> https://buildd.debian.org/status/logs.php?pkg=libgnatcoll&ver=1.7gpl2015-1%2Bb3
> https://buildd.debian.org/status/logs.php?pkg=libgtkada&ver=3.8.3-1%2Bb2

With the attached patch, gprbuild can executable correctly, and the above
package can be built.

To build prefix.c for target, I have to get a config.h file and define
some macro.

>
> Cheers,
> Emilio
>
>
diff --git a/debian/patches/ada-libgnatprj.diff 
b/debian/patches/ada-libgnatprj.diff
index 70043fa..3ce8b46 100644
--- a/debian/patches/ada-libgnatprj.diff
+++ b/debian/patches/ada-libgnatprj.diff
@@ -95,7 +95,7 @@ Index: b/src/libgnatprj/Makefile.in
 +
 +# Add some object files compiled from C sources.  prefix.o requires
 +# some objects from libiberty and from gcc.
-+# OBJECTS += common-targhooks.o errors.o hooks.o link.o prefix.o targetm.o
++OBJECTS += link.o prefix.o
 +
 +# These object files have already been built, both PIC and non-PIC.
 +# prefix.o depends on them.
@@ -124,12 +124,12 @@ Index: b/src/libgnatprj/Makefile.in
 +
 +obj-shared/%.o: %.c
 +  $(GPP) -c -fPIC $(CFLAGS) -DHAVE_CONFIG_H -pedantic \
-+ -I@srcdir@/../gcc -I@srcdir@/../include -I@srcdir@/../libcpp/include 
-I../../gcc -DUSED_FOR_TARGET \
++ -I. -I@srcdir@/../gcc -I@srcdir@/../include 
-I@srcdir@/../libcpp/include -I../../gcc -DUSED_FOR_TARGET \
 + $< -o $@
 +
 +obj-shared/prefix.o: @srcdir@/../gcc/prefix.c
 +  $(GPP) -c -fPIC $(CFLAGS) -DPREFIX=\"@prefix@\" 
-DBASEVER=\"$(BASEVER)\" \
-+ -I@srcdir@/../gcc -I@srcdir@/../include -I../../gcc 
-I@srcdir@/../libcpp/include -DUSED_FOR_TARGET \
++ -I. -I@srcdir@/../gcc -I@srcdir@/../include -I../../gcc 
-I@srcdir@/../libcpp/include -DUSED_FOR_TARGET \
 + $< -o $@
 +
 +obj-shared:
@@ -150,12 +150,12 @@ Index: b/src/libgnatprj/Makefile.in
 +
 +obj-static/%.o: %.c
 +  $(GPP) -c $(CFLAGS) -DHAVE_CONFIG_H -pedantic \
-+ -I@srcdir@/../gcc -I@srcdir@/../include -I@srcdir@/../libcpp/include 
-I../../gcc -DUSED_FOR_TARGET \
++ -I. -I@srcdir@/../gcc -I@srcdir@/../include 
-I@srcdir@/../libcpp/include -I../../gcc -DUSED_FOR_TARGET \
 + $< -o $@
 +
 +obj-static/prefix.o: @srcdir@/../gcc/prefix.c
 +  $(GPP) -c $(CFLAGS) -DPREFIX=\"@prefix@\" -DBASEVER=\"$(BASEVER)\" \
-+ -I@srcdir@/../gcc -I@srcdir@/../include -I../../gcc 
-I@srcdir@/../libcpp/include -DUSED_FOR_TARGET \
++ -I. -I@srcdir@/../gcc -I@srcdir@/../include -I../../gcc 
-I@srcdir@/../libcpp/include -DUSED_FOR_TARGET \
 + $< -o $@
 +
 +obj-static:
@@ -277,7 +277,7 @@ Index: b/src/libgnatprj/configure.ac
 ===
 --- /dev/null
 +++ b/src/libgnatprj/configure.ac
-@@ -0,0 +1,146 @@
+@@ -0,0 +1,557 @@
 +# Configure script for libada.
 +#   Copyright 2003, 2004 Free Software Foundation, Inc.
 +#
@@ -308,12 +308,423 @@ Index: b/src/libgnatprj/configure.ac
 +AC_CANONICAL_HOST
 +AC_CANONICAL_TARGET
 +
++GCC_NO_EXECUTABLES
++AC_PROG_CC
++AC_GNU_SOURCE
++AC_PROG_CPP_WERROR
++
++AC_PROG_CC_C_O
++# autoconf is lame and doesn't give us any substitution variable for this.
++if eval "test \"`echo '$ac_cv_prog_cc_'${ac_cc}_c_o`\" = no"; then
++  NO_MINUS_C_MINUS_O=yes
++else
++  OUTPUT_OPTION='-o $@'
++fi
++AC_SUBST(NO_MINUS_C_MINUS_O)
++AC_SUBST(OUTPUT_OPTION)
++
++AC_C_CONST
++AC_C_INLINE
++AC_C_BIGENDIAN
++
++dnl When we start using libtool:
++dnl AM_PROG_LIBTOOL
++
++dnl When we start using automake:
++dnl AM_CONFIG_HEADER(config.h:config.in)
++AC_CONFIG_HEADER(config.h:config.in)
++
 +sinclude(../config/acx.m4)
 +ACX_NONCANONICAL_TARGET
 +
 +# Need to pass this down for now :-P
 +AC_PROG_LN_S
 +
++# It's OK to check for header files.  Although the compiler may not be
++# able to link anything, it had better be able to at least compile
++# something.
++AC_CHECK_HEADERS(sys/file.h sys/param.h limits.h stdlib.h malloc.h string.h 
unistd.h strings.h sys/time.h time.h sys/resource.h sys/stat.h sys/mman.h 
fcntl.h alloca.h sys/pstat.h sys/sysmp.h sys/sysinfo.h machine/hal_sysinfo.h 
sys/table.h sys/sysctl.h sys/systemcfg.h stdint.h stdio_ext.h process.h 
sys/prctl.h)
++AC_HEADER_SYS_WAIT
++AC_HEADER_TIME
++
++# Determine sizes of some types.
++AC_CHECK_SIZEOF([int])
++AC_CHECK_SIZEOF([long])
++AC_CHECK_SIZEOF([size_t])
++
++AC_TYPE_INTPTR_T
++AC_TYPE_UINTPTR_T
++AC_TYPE_SSIZE_T
++
++# Given the above check, we always have uintptr_t or a fallback
++# definition.  So define HAVE_UINTPTR_T in case any imported code
++# relies on it.
++AC_DEFINE(HAVE_UINTPTR_T, 1, [Define if you have the \`uintptr_t' type.])
++
++AC_TYPE_PID_T
++
++# This is the list of functions which libiberty will provide 

Bug#826365: patch to build libgnat* as target instead of host libraries breaks native builds

[Yunqiang Su]

> 在 2016年6月7日，23:45，YunQiang Su  写道：
> 
> In ada-gnattools-cross.diff, there are 3 lines, like this:
> 
> +# We will use the just-built compiler to compile and link everything.
> +GCC=../gcc/xgcc -B../gcc/
> +GXX=../gcc/xg++ -B../gcc/
> 
> adding -no-pie option for GCC and GXX will make gcc-6 buildable with
> --enable-default-pie option on amd64 platform.
> I have no other machines to test it on other platform.
> Maybe you can test it on you PPA.
> 
> aka, modified to:
> 
> +# We will use the just-built compiler to compile and link everything.
> +GCC=../gcc/xgcc -B../gcc/ -no-pie
> +GXX=../gcc/xg++ -B../gcc/ -no-pie
> 
> On Mon, Jun 6, 2016 at 12:36 AM, Matthias Klose  wrote:
>> On 05.06.2016 17:46, YunQiang Su wrote:
>>> I see. You means ftbfs when  --enable-default-pie,
>>> and it is enabled for Ubuntu by default now.
>> 
>> yes, but see the debian-devel ML about turning this on.  I haven't yet 
>> checked
>> if the s390x issue really is related to that (it shows up there as a 
>> segfault,
>> different than on amd64).
>> 
> 
> 

This patch also fixes the ftbfs on powerpc.

gnat-pie.diff
Description: Binary data

> 
> --
> YunQiang Su



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#826365: patch to build libgnat* as target instead of host libraries breaks native builds

[YunQiang Su]

In ada-gnattools-cross.diff, there are 3 lines, like this:

+# We will use the just-built compiler to compile and link everything.
+GCC=../gcc/xgcc -B../gcc/
+GXX=../gcc/xg++ -B../gcc/

adding -no-pie option for GCC and GXX will make gcc-6 buildable with
--enable-default-pie option on amd64 platform.
I have no other machines to test it on other platform.
Maybe you can test it on you PPA.

aka, modified to:

+# We will use the just-built compiler to compile and link everything.
+GCC=../gcc/xgcc -B../gcc/ -no-pie
+GXX=../gcc/xg++ -B../gcc/ -no-pie

On Mon, Jun 6, 2016 at 12:36 AM, Matthias Klose  wrote:
> On 05.06.2016 17:46, YunQiang Su wrote:
>> I see. You means ftbfs when  --enable-default-pie,
>> and it is enabled for Ubuntu by default now.
>
> yes, but see the debian-devel ML about turning this on.  I haven't yet checked
> if the s390x issue really is related to that (it shows up there as a segfault,
> different than on amd64).
>



-- 
YunQiang Su

Bug#826365: patch to build libgnat* as target instead of host libraries breaks native builds

[YunQiang Su]

On Sun, Jun 5, 2016 at 11:36 PM, YunQiang Su  wrote:
> On Sun, Jun 5, 2016 at 8:08 AM, Matthias Klose  wrote:
>> Package: src:gcc-6
>> Version: 6.1.1-5
>> Severity: serious
>>
>> The patch applied in 6.1.1-5 to build libgnat* as target instead of host
>> libraries breaks native builds.
>>
>> on powerpc:
>>
>> /usr/bin/powerpc-linux-gnu-ld: cannot find -latomic
>> collect2: error: ld returned 1 exit status
>> Makefile:195: recipe for target 'gnatlink-static' failed
>> make[4]: *** [gnatlink-static] Error 1
>> make[4]: *** Waiting for unfinished jobs
>>
>> on amd64, when configured with --enable-default-pie:
>>
>> /usr/bin/x86_64-linux-gnu-ld: ../gcc/libcommon-target.a(prefix.o): relocation
>> R_X86_64_32
>>  against `.rodata.str1.1' can not be used when making a shared object; 
>> recompile
>> with -fP
>> IC
>> ../gcc/libcommon-target.a: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>> Makefile:209: recipe for target 'gnatmake-static' failed
>> make[4]: *** [gnatmake-static] Error 1
>> make[4]: Leaving directory '/«PKGBUILDDIR»/build/gnattools'
>> Makefile:11407: recipe for target 'all-gnattools' failed
>> make[3]: *** [all-gnattools] Error 2
>>
>> on s390x, when configured with --enable-default-pie:
>
> I only noticed the failure on sparc64 and powerpc.
> Did you pop up the patches?

I see. You means ftbfs when  --enable-default-pie,
and it is enabled for Ubuntu by default now.

>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#826365: patch to build libgnat* as target instead of host libraries breaks native builds

[YunQiang Su]

On Sun, Jun 5, 2016 at 8:08 AM, Matthias Klose  wrote:
> Package: src:gcc-6
> Version: 6.1.1-5
> Severity: serious
>
> The patch applied in 6.1.1-5 to build libgnat* as target instead of host
> libraries breaks native builds.
>
> on powerpc:
>
> /usr/bin/powerpc-linux-gnu-ld: cannot find -latomic
> collect2: error: ld returned 1 exit status
> Makefile:195: recipe for target 'gnatlink-static' failed
> make[4]: *** [gnatlink-static] Error 1
> make[4]: *** Waiting for unfinished jobs
>
> on amd64, when configured with --enable-default-pie:
>
> /usr/bin/x86_64-linux-gnu-ld: ../gcc/libcommon-target.a(prefix.o): relocation
> R_X86_64_32
>  against `.rodata.str1.1' can not be used when making a shared object; 
> recompile
> with -fP
> IC
> ../gcc/libcommon-target.a: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:209: recipe for target 'gnatmake-static' failed
> make[4]: *** [gnatmake-static] Error 1
> make[4]: Leaving directory '/«PKGBUILDDIR»/build/gnattools'
> Makefile:11407: recipe for target 'all-gnattools' failed
> make[3]: *** [all-gnattools] Error 2
>
> on s390x, when configured with --enable-default-pie:

I only noticed the failure on sparc64 and powerpc.
Did you pop up the patches?

-- 
YunQiang Su

Bug#799993: librdkafka: FTBFS: error: assuming signed overflow does not occur when assuming that (X + c) >= X is always true

[YunQiang Su]

On Fri, 25 Sep 2015 08:04:59 +0100 Chris Lamb  wrote:
> Source: librdkafka
> Version: 0.8.6-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> librdkafka fails to build from source in unstable/amd64:
>
>   [..]
>
>   gcc -MD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
>   -D_FORTIFY_SOURCE=2 -g -O2 -fPIC -Wall -Werror -Wfloat-equal
>   -Wpointer-arith -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fPIC -Wall
>   -Werror -Wfloat-equal -Wpointer-arith -g -O2 -fstack-protector-strong
>   -Wformat -Werror=format-security -g -O2 -fstack-protector-strong
>   -Wformat -Werror=format-security -g -O2 -fstack-protector-strong
>   -Wformat -Werror=format-security -c rdlog.c -o rdlog.o
>   rdlog.c: In function 'rd_hexdump':
>   rdlog.c:39:6: error: assuming signed overflow does not occur when
>   assuming that (X + c) >= X is always true [-Werror=strict-overflow]
>void rd_hexdump (FILE *fp, const char *name, const void *ptr, size_t
>len) {
> ^
>   cc1: all warnings being treated as errors
>   ../mklove/Makefile.base:70: recipe for target 'rdlog.o' failed
>   make[2]: *** [rdlog.o] Error 1
>   make[2]: Leaving directory '/tmp/buildd/librdkafka-0.8.6/src'
>
>   [..]
>
> The full build log is attached or can be viewed here:
>
> 
> https://reproducible.debian.net/logs/unstable/amd64/librdkafka_0.8.6-1.build1.log.gz

I NMUed this package to 5-days delay with the attached patch.

>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-


librdkafka.debdiff
Description: Binary data

Bug#801597: hardening-wrapper doesn't wrap gcc-5

[YunQiang Su]

On Wed, 04 Nov 2015 19:26:55 +0100 Sven Joachim  wrote:
> Control: severity -1 grave
>
> On 2015-10-21 13:41 +0200, Matthias Klose wrote:
>
> > hardening-wrapper doesn't wrap gcc-5. not sure if this is by intent ...
>
> Given that gcc-5 is the default compiler, this makes the package rather
> useless, so I'm bumping the severity.

I uploaded this package to 3-days delay.

>
> Cheers,
>Sven
>
>


hardening-wrapper.debdiff
Description: Binary data

Bug#802579: binutils changed ld.bfd / ld.gold files and symlinks

[YunQiang Su]

On Sat, 14 Nov 2015 02:20:40 +0100 Matthias Klose  wrote:
> Control: severity -1 serious
>
> binutils built from the 2.26 branch is now in unstable.
>
>

I uploaded this packages with the attached patch to 3-days delay.


hardening-wrapper.debdiff
Description: Binary data

Bug#796402: slgsl: FTBFS:

[YunQiang Su]

On Fri, 21 Aug 2015 20:03:45 +0100 Chris Lamb  wrote:
> retitle 796402 slgsl: FTBFS: unable to find the gsl library and header
> file
> thanks

I NMUed this package with the attached patch.

>
> (Whoops, better title..)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
>


slgsl.debdiff
Description: Binary data

Bug#790284: ssm: FTBFS with glibc 2.21 and gcc-5

[YunQiang Su]

On Sat, 27 Jun 2015 14:02:19 -0700 Daniel Schepler  wrote:
> Source: ssm
> Version: 1.3-2
> Severity: normal
>
> From my pbuilder build log, using a setup preferring glibc and gcc-defaults
> from experimental:

I NMUed this package to unstable with the attached patch.

>
> ...
>dh_fixperms -O--dbg-package=libssm1-dbg
>dh_strip -O--dbg-package=libssm1-dbg
>dh_makeshlibs -O--dbg-package=libssm1-dbg
> dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> dpkg-gensymbols: warning: debian/libssm1/DEBIAN/symbols doesn't match 
> completely debian/libssm1.symbols
> --- debian/libssm1.symbols (libssm1_1.3-2+bpb6_amd64)
> +++ dpkg-gensymbolsJTEyob   2015-06-14 08:50:56.737157172 +
> @@ -433,7 +433,7 @@
>   _ZTSN3ssm6XAlignE@Base 1.3
>   _ZTSN3ssm8SortDistE@Base 1.3
>   _ZTSN3ssm9MultAlignE@Base 1.3
> - _ZTV7CStream@Base 1.3
> +#MISSING: 1.3-2+bpb6# _ZTV7CStream@Base 1.3
>   _ZTVN3ssm10GraphMatchE@Base 1.3
>   _ZTVN3ssm10XAlignTextE@Base 1.3
>   _ZTVN3ssm12SortMappingsE@Base 1.3
> dh_makeshlibs: failing due to earlier errors
> debian/rules:9: recipe for target 'binary' failed
> make: *** [binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> --
> Daniel Schepler
>
>


ssm.debdiff
Description: Binary data

Bug#805060: Postfix ftbfs with Linux kernel version 4+

[YunQiang Su]

Package: src:postfix
Version: 2.11.3-1
Severity: serious

When build postfix on a machine running Linux 4+,
it will ftbfs, with error like:

(echo "# Do not edit -- this file documents how Postfix was built for
your machine."; /bin/sh makedefs) >makedefs.tmp
ATTENTION:
ATTENTION: Unknown system type: Linux 4.2.0-1-powerpc64
ATTENTION:

-- 
YunQiang Su

Bug#790252: libpgf: FTBFS with glibc 2.21 and gcc-5

[YunQiang Su]

On Tue, 7 Jul 2015 18:22:19 -0400 Martin Michlmayr  wrote:
> retitle 790252 libpgf: FTBFS with gcc-5 (symbols)
> thanks
>
> * Daniel Schepler  [2015-06-27 11:17]:
> > Source: libpgf
> > Version: 6.14.12-3
> > Severity: normal
> >
> > >From my pbuilder build log, using a setup preferring glibc and gcc-defaults
> > from experimental:
>
> I see the same with GCC 5 and the glibc from unstable.

I NMUed this package with the attached patch to 5-days delay.

>
> --
> Martin Michlmayr
> Linux for HP Helion, Hewlett-Packard
>
>


libpgf.debdiff
Description: Binary data

Bug#798765: xtrs: FTBFS with GCC 5: trs_memory.c:152:6: error: type of 'state' defaults to 'int' [-Werror=implicit-int]

[YunQiang Su]

On Sat, 12 Sep 2015 14:17:11 +0200 Andreas Beckmann  wrote:
> Package: xtrs
> Version: 4.9c-3.4
> Severity: serious
> Tags: sid stretch
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> xtrs FTBFS in sid with GCC 5:
>
> [...]
> /usr/bin/make DEBUG="-Wall -Werror -Wno-error=unused-but-set-variable -O2 -g 
> -D_REENTRANT" PREFIX=/usr
> make[1]: Entering directory '/tmp/buildd/xtrs-4.9c'
> cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT  
> -DDEFAULT_ROM='"/usr/local/lib/xtrs/level2rom.hex"' 
> -DDEFAULT_ROM3='"/usr/local/lib/xtrs/romimage.m3"' 
> -DDEFAULT_ROM4P='"/usr/local/lib/xtrs/romimage.m4p"' -DREADLINE 
> -DDISKDIR='"."' -I/usr/include/X11 
> -DAPPDEFAULTS='"/usr/X11/lib/X11/app-defaults"' -DKBWAIT -DHAVE_SIGIO   -c -o 
> z80.o z80.c
> cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT  
> -DDEFAULT_ROM='"/usr/local/lib/xtrs/level2rom.hex"' 
> -DDEFAULT_ROM3='"/usr/local/lib/xtrs/romimage.m3"' 
> -DDEFAULT_ROM4P='"/usr/local/lib/xtrs/romimage.m4p"' -DREADLINE 
> -DDISKDIR='"."' -I/usr/include/X11 
> -DAPPDEFAULTS='"/usr/X11/lib/X11/app-defaults"' -DKBWAIT -DHAVE_SIGIO   -c -o 
> main.o main.c
> cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT  
> -DDEFAULT_ROM='"/usr/local/lib/xtrs/level2rom.hex"' 
> -DDEFAULT_ROM3='"/usr/local/lib/xtrs/romimage.m3"' 
> -DDEFAULT_ROM4P='"/usr/local/lib/xtrs/romimage.m4p"' -DREADLINE 
> -DDISKDIR='"."' -I/usr/include/X11 
> -DAPPDEFAULTS='"/usr/X11/lib/X11/app-defaults"' -DKBWAIT -DHAVE_SIGIO   -c -o 
> load_cmd.o load_cmd.c
> cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT  
> -DDEFAULT_ROM='"/usr/local/lib/xtrs/level2rom.hex"' 
> -DDEFAULT_ROM3='"/usr/local/lib/xtrs/romimage.m3"' 
> -DDEFAULT_ROM4P='"/usr/local/lib/xtrs/romimage.m4p"' -DREADLINE 
> -DDISKDIR='"."' -I/usr/include/X11 
> -DAPPDEFAULTS='"/usr/X11/lib/X11/app-defaults"' -DKBWAIT -DHAVE_SIGIO   -c -o 
> load_hex.o load_hex.c
> cc -Wall -Werror -Wno-error=unused-but-set-variable -O2 -g -D_REENTRANT  
> -DDEFAULT_ROM='"/usr/local/lib/xtrs/level2rom.hex"' 
> -DDEFAULT_ROM3='"/usr/local/lib/xtrs/romimage.m3"' 
> -DDEFAULT_ROM4P='"/usr/local/lib/xtrs/romimage.m4p"' -DREADLINE 
> -DDISKDIR='"."' -I/usr/include/X11 
> -DAPPDEFAULTS='"/usr/X11/lib/X11/app-defaults"' -DKBWAIT -DHAVE_SIGIO   -c -o 
> trs_memory.o trs_memory.c
> trs_memory.c: In function 'mem_romin':
> trs_memory.c:152:6: error: type of 'state' defaults to 'int' 
> [-Werror=implicit-int]
>  void mem_romin(state)
>   ^
> cc1: all warnings being treated as errors
> : recipe for target 'trs_memory.o' failed
> make[1]: *** [trs_memory.o] Error 1
> make[1]: Leaving directory '/tmp/buildd/xtrs-4.9c'
> debian/rules:34: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2

I NMUed this package with the attached patch to 5 days delay.

>
>
> Andreas
>
>


xtrs.debdiff
Description: Binary data

Bug#778180: xemacs21: ftbfs with GCC-5

[YunQiang Su]

On Thu, 13 Aug 2015 10:10:09 -0600 Brett Johnson  wrote:
> On 08/13/2015 09:51 AM, Mark Brown wrote:
> > Who would I submit a patch for the packaging to?!
>
> Lol. Sorry, I didn't notice you were the maintainer ;)

Any progress of this bug?
It blocks some packages in to build for mips64el port.

> --
> Brett Johnson 
>
>

Bug#798288: x11-xserver-utils failed to build with gcc 5

[YunQiang Su]

Package: x11-xserver-utils
Version: 7.7+4
Severity: serious

cpp-5 insert some comments when replace macros,
so it makes sessreg manpages fail to build.

https://buildd.debian.org/status/fetch.php?pkg=x11-xserver-utils&arch=mips64el&ver=7.7%2B4&stamp=1441629791



-- 
YunQiang Su
GCC may insert some comments everywhere when replace placeholders.
GCC 5 just does it here.

Index: b/sessreg/man/Makefile.am
===
--- a/sessreg/man/Makefile.am
+++ b/sessreg/man/Makefile.am
@@ -11,7 +11,8 @@ AM_CPPFLAGS = -I$(top_builddir) -I$(top_
 filenames.sed: filenames.sed.c
$(AM_V_GEN)$(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(srcdir)/filenames.sed.c | \
-   $(SED) -n -e '/s|__/ p' -e '/^\/__/ p' > $@
+   $(SED) -n -e '/s|__/ p' -e '/^\/__/ p' -e'/ *|g$$/ p' -e'/ 
*"\/var.*"$$/ p' | \
+$(SED) 's/ *//g' | $(SED) '/|$$/{N;s/\n//}' | $(SED) 
'/"$$/{N;s/\n//}' > $@
 
 # String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
 MAN_SUBSTS += -f filenames.sed

Bug#754753: healpix-cxx: FTBFS on armel: testsuite timeout

[YunQiang Su]

I NMUed this package with the attached patch to 5-delay queue.

If any objection, contact me or cut it.

On Mon, Mar 30, 2015 at 5:25 PM, YunQiang Su  wrote:
> On Mon, 14 Jul 2014 02:11:42 +0200 Cyril Brulebois  wrote:
>> Source: healpix-cxx
>> Version: 3.11.2-7
>> Severity: serious
>> Justification: FTBFS
>>
>> Hi,
>>
>> your package no longer builds on armel:
>> | libtool: link: g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 
>> -Wformat -Werror=format-security -fopenmp -fno-tree-vectorize 
>> -fno-math-errno -funsafe-math-optimizations -fno-trapping-math 
>> -fno-rounding-math -fno-signaling-nans -fcx-limited-range 
>> -fomit-frame-pointer -Wl,-z -Wl,relro -o hpxtest Healpix_cxx/hpxtest.o  
>> ./.libs/libhealpix_cxx.a -lcfitsio -lpthread -fopenmp
>> | make[1]: Leaving directory '/«PKGBUILDDIR»'
>> |dh_auto_test -a
>> | make[1]: Entering directory '/«PKGBUILDDIR»'
>> | make  check-TESTS
>> | make[2]: Entering directory '/«PKGBUILDDIR»'
>> | make[3]: Entering directory '/«PKGBUILDDIR»'
>> | make[3]: *** Deleting file 'hpxtest.log'
>> | Terminated
>> | make[2]: *** [check-TESTS] Terminated
>> | make[3]: *** [hpxtest.log] Terminated
>> | make[1]: *** [check-am] Terminated
>> | Makefile:1557: recipe for target 'check-TESTS' failed
>> | Makefile:1578: recipe for target 'hpxtest.log' failed
>> | Makefile:1763: recipe for target 'check-am' failed
>> | make: *** wait: No child processes.  Stop.
>> | make: *** Waiting for unfinished jobs
>> | make: *** wait: No child processes.  Stop.
>> | Build killed with signal TERM after 150 minutes of inactivity
>
> It is not a real FTBFS indeed.
> The test 'hpxtest' cost to much time and armel has a quite poor performance, 
> so
> the test is killed by sbuild.
>
> So if we output some information when building, it will not be killed by 
> sbuild.
>
> in `test-drivers':
>
> "$@" >$log_file 2>&1
>
> -->>>>>>>>>>>
>
> "$@" 2>&1 | tee $log_file
>
> will fix this problem.
>
>
>>
>> Full build log:
>>   
>> https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=armel&ver=3.11.2-7&stamp=1405237595
>>
>> Mraw,
>> KiBi.
>>
>>



-- 
YunQiang Su


healpix-cxx.debdiff
Description: Binary data

Bug#754753: healpix-cxx: FTBFS on armel: testsuite timeout

[YunQiang Su]

On Mon, 14 Jul 2014 02:11:42 +0200 Cyril Brulebois  wrote:
> Source: healpix-cxx
> Version: 3.11.2-7
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> your package no longer builds on armel:
> | libtool: link: g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 
> -Wformat -Werror=format-security -fopenmp -fno-tree-vectorize -fno-math-errno 
> -funsafe-math-optimizations -fno-trapping-math -fno-rounding-math 
> -fno-signaling-nans -fcx-limited-range -fomit-frame-pointer -Wl,-z -Wl,relro 
> -o hpxtest Healpix_cxx/hpxtest.o  ./.libs/libhealpix_cxx.a -lcfitsio 
> -lpthread -fopenmp
> | make[1]: Leaving directory '/«PKGBUILDDIR»'
> |dh_auto_test -a
> | make[1]: Entering directory '/«PKGBUILDDIR»'
> | make  check-TESTS
> | make[2]: Entering directory '/«PKGBUILDDIR»'
> | make[3]: Entering directory '/«PKGBUILDDIR»'
> | make[3]: *** Deleting file 'hpxtest.log'
> | Terminated
> | make[2]: *** [check-TESTS] Terminated
> | make[3]: *** [hpxtest.log] Terminated
> | make[1]: *** [check-am] Terminated
> | Makefile:1557: recipe for target 'check-TESTS' failed
> | Makefile:1578: recipe for target 'hpxtest.log' failed
> | Makefile:1763: recipe for target 'check-am' failed
> | make: *** wait: No child processes.  Stop.
> | make: *** Waiting for unfinished jobs
> | make: *** wait: No child processes.  Stop.
> | Build killed with signal TERM after 150 minutes of inactivity

It is not a real FTBFS indeed.
The test 'hpxtest' cost to much time and armel has a quite poor performance, so
the test is killed by sbuild.

So if we output some information when building, it will not be killed by sbuild.

in `test-drivers':

"$@" >$log_file 2>&1

-->>>

"$@" 2>&1 | tee $log_file

will fix this problem.


>
> Full build log:
>   
> https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=armel&ver=3.11.2-7&stamp=1405237595
>
> Mraw,
> KiBi.
>
>


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730903: mutrace ftbfs

[YunQiang Su]

On Fri, 4 Apr 2014 14:59:53 +0300 Riku Voipio  wrote:
> Hi,
>
> > The libiberty.h is provided by libiberty-dev and installed in
> > /usr/include/libiberty/libiberty.h.
>
> unfortunately this change isn't enough. Due to some other changes,
> linking against static libbfd doesn't work:
>
> gcc -std=gnu99 -shared -fPIC   
> .libs/libmutrace_backtrace_symbols_la-backtrace-symbols.o /usr/lib/libbfd.a 
> -lrt -ldl  -pthread -O2   -pthread -Wl,-soname 
> -Wl,libmutrace-backtrace-symbols.so -o .libs/libmutrace-backtrace-symbols.so
> /usr/bin/ld: /usr/lib/libbfd.a(bfd.o): relocation R_X86_64_32 against 
> `.rodata.str1.1' can not be used when making a shared object; recompile with 
> -fPIC
> /usr/lib/libbfd.a: error adding symbols: Bad value

I didn't meet this problem.


> collect2: error: ld returned 1 exit status
>
> while dynamic linking against libbfd is not considered allowed.

It works for me to add -I/usr/include/libiberty/ to
libmutrace_backtrace_symbols_la_CFLAGS  in
Makefile.am.

It works well on both amd64 and mips64el.

>
> This leaves the code stuck in no-building area. Considering dropping the 
> package.
>
> Riku
>
>
>


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762775: pynfft: FTBFS: dh: unable to load addon sphinxdoc

[YunQiang Su]

On Wed, 24 Sep 2014 22:56:11 -0400 "Aaron M. Ucko"  wrote:
> Source: pynfft
> Version: 1.3.2-1
> Severity: serious
> Justification: fails to build from source
>
> Builds of pynfft in minimal environments geared for building its
> architecture-dependent binary packages (e.g., on the autobuilders)
> have been failing:
>
>   dh clean --with python2,python3,sphinxdoc --buildsystem=pybuild
>   dh: unable to load addon sphinxdoc: Can't locate 
> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the 
> Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: /etc/perl 
> /usr/local/lib/«arch»/perl/5.20.0 /usr/local/share/perl/5.20.0 
> /usr/lib/«arch»/perl5/5.20 /usr/share/perl5 /usr/lib/«arch»/perl/5.20 
> /usr/share/perl/5.20 /usr/local/lib/site_perl .) at (eval 13) line 2.
>   BEGIN failed--compilation aborted at (eval 13) line 2.
>
>   make: *** [clean] Error 2
>   debian/rules:10: recipe for target 'clean' failed
>
> Could you please either conditionalize the usage of --with sphinxdoc
> appropriately or move python-sphinx into the main Build-Depends field?
> In the latter case, please bump the version to (>= 1.2.2+dfsg-2~) to
> avoid running into errors if there is no actual documentation to
> install.  (See #745690.)

I will NMU it with the attached patch.

>
> Thanks!
>
>


pynfft.debdiff
Description: Binary data