Bug#776275: os-prober: add mips64el support
Package: os-prober
Version: 1.65
diff -Nru os-prober-1.65/debian/control os-prober-1.65+mips/debian/control
--- os-prober-1.65/debian/control 2014-11-12 23:18:54.0 +0800
+++ os-prober-1.65+mips/debian/control 2015-01-19 18:46:01.0 +0800
@@ -11,7 +11,7 @@
Package: os-prober-udeb
Package-Type: udeb
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna
(= 1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc
mipsel kfreebsd-i386 kfreebsd-amd64]
+Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna
(= 1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc
mipsel mips64el mipsn32el kfreebsd-i386 kfreebsd-amd64]
Provides: os-prober
Description: utility to detect other OSes on a set of drives
This package is to be used by boot loader installers to detect other OSes
--
YunQiang Su
diff -Nru os-prober-1.65/debian/control os-prober-1.65+mips/debian/control
--- os-prober-1.65/debian/control 2014-11-12 23:18:54.0 +0800
+++ os-prober-1.65+mips/debian/control 2015-01-19 18:46:01.0 +0800
@@ -11,7 +11,7 @@
Package: os-prober-udeb
Package-Type: udeb
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna (=
1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc mipsel
kfreebsd-i386 kfreebsd-amd64]
+Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna (=
1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc mipsel mips64el
mipsn32el kfreebsd-i386 kfreebsd-amd64]
Provides: os-prober
Description: utility to detect other OSes on a set of drives
This package is to be used by boot loader installers to detect other OSes
Bug#775726: base-installer: add mips64el support
Package: base-installer Version: 1.152 This patch add mips64el support to base-installer. mips64el has 4 kernel flavors now: loongson-3 5kc-malta sb1-bcm91250a octeon -- YunQiang Su base-install-mips64el.debdiff Description: Binary data
Bug#775723: grub2-yeeloong: cannot work with 3A laptop
Package: src:grub2 Version: 2.02~beta2-20 I have noticed that 3A-yeeloong support of grub has merged upstream, and also included in current tarball. I tested it on a 3A-yeeloong, it cannot not boot. It makes the laptop just poweroff. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775722: grub2: fix mips64el build
Package: src:grub2
Version: 2.02~beta2-20
With this patch, grub2 can be built on mips64el.
Can you review it ?
--
YunQiang Su
diff -Nru grub2-2.02~beta2/debian/control grub2-2.02~beta2/debian/control
--- grub2-2.02~beta2/debian/control 2015-01-03 20:21:00.0 +0800
+++ grub2-2.02~beta2/debian/control 2015-01-19 17:58:02.0 +0800
@@ -89,7 +89,7 @@
# Not Architecture: any because this package contains some things which are
# only built when there is a real platform (e.g. grub-install), and the rest
# of the package is not very useful in a utilities-only build.
-Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc
any-sparc64 any-mipsel any-ia64 any-arm any-arm64
+Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc
any-sparc64 any-mipsel any-mips64el any-mips64el any-ia64 any-arm any-arm64
Depends: grub-common (= ${binary:Version}), dpkg (= 1.15.4) | install-info,
${shlibs:Depends}, ${misc:Depends}
Replaces: grub, grub-legacy, grub-common ( 1.99-1), grub-pc ( 2.00-4),
grub-ieee1275 ( 2.00-4), grub-efi ( 1.99-1), grub-coreboot ( 2.00-4),
grub-linuxbios ( 1.99-1), grub-efi-ia32 ( 2.00-4), grub-efi-amd64 (
2.00-4), grub-efi-ia64 ( 2.00-4), grub-ieee1275 ( 2.00-4), grub-yeeloong
( 2.00-4)
Conflicts: grub ( 0.97-54), grub-legacy, ${legacy-doc-conflicts}
@@ -652,7 +652,7 @@
guest (i.e. PV-GRUB) to be present in the control domain filesystem.
Package: grub-yeeloong-bin
-Architecture: any-mipsel
+Architecture: any-mipsel any-mips64el
Depends: ${shlibs:Depends}, ${misc:Depends}, grub-common (= ${binary:Version})
Replaces: grub-common ( 1.98+20100617-2), grub-yeeloong ( 1.99-1)
Multi-Arch: foreign
@@ -673,7 +673,7 @@
Package: grub-yeeloong-dbg
Section: debug
-Architecture: any-mipsel
+Architecture: any-mipsel any-mips64el
Depends: ${misc:Depends}, grub-yeeloong-bin (= ${binary:Version}), grub-common
(= ${binary:Version})
Multi-Arch: foreign
Description: GRand Unified Bootloader, version 2 (Yeeloong debug files)
@@ -681,7 +681,7 @@
need these if you are trying to debug GRUB using its GDB stub.
Package: grub-yeeloong
-Architecture: any-mipsel
+Architecture: any-mipsel any-mips64el
Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (=
${binary:Version}), grub-yeeloong-bin (= ${binary:Version}), ucf
Replaces: grub-common ( 1.98+20100617-2)
Multi-Arch: foreign
@@ -701,7 +701,7 @@
Package: grub-theme-starfield
# Could be Architecture: any, but in practice this package is useless in a
# utilities-only build.
-Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc
any-sparc64 any-mipsel any-ia64 any-arm any-arm64
+Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc
any-sparc64 any-mipsel any-mips64el any-ia64 any-arm any-arm64
Depends: ${misc:Depends}, grub-common (= ${binary:Version})
Multi-Arch: foreign
Description: GRand Unified Bootloader, version 2 (starfield theme)
diff -Nru grub2-2.02~beta2/debian/patches/mips32.diff
grub2-2.02~beta2/debian/patches/mips32.diff
--- grub2-2.02~beta2/debian/patches/mips32.diff 1970-01-01 08:00:00.0
+0800
+++ grub2-2.02~beta2/debian/patches/mips32.diff 2015-01-19 17:58:02.0
+0800
@@ -0,0 +1,104 @@
+Index: grub2-2.02~beta2/configure.ac
+===
+--- grub2-2.02~beta2.orig/configure.ac 2015-01-15 02:03:29.0 +0800
grub2-2.02~beta2/configure.ac 2015-01-15 02:12:50.793920793 +0800
+@@ -85,17 +85,23 @@
+ TARGET_CPPFLAGS=$TARGET_CPPFLAGS -I\$(top_srcdir)/include
+ TARGET_CPPFLAGS=$TARGET_CPPFLAGS -I\$(top_builddir)/include
+
++m32_option=-m32
++m64_option=-m64
+ case $target_cpu in
+ i[[3456]]86)target_cpu=i386 ;;
+ amd64) target_cpu=x86_64 ;;
+ sparc) target_cpu=sparc64 ;;
+- mipsel|mips64el)
++ mipsel|mips64el|mipsn32el)
+ target_cpu=mipsel;
+ machine_CPPFLAGS=$machine_CPPFLAGS -DGRUB_CPU_MIPSEL=1;
++ m32_option=-mabi=32
++ m64_option=-mabi=64
+ ;;
+- mips|mips64)
++ mips|mips64|mipsn32)
+ target_cpu=mips;
+ machine_CPPFLAGS=$machine_CPPFLAGS -DGRUB_CPU_MIPS=1;
++ m32_option=-mabi=32
++ m64_option=-mabi=64
+ ;;
+ arm*)
+ target_cpu=arm;
+@@ -179,7 +185,7 @@
+
+ if test x$platform != xemu ; then
+case $target_cpu in
+- i386 | powerpc) target_m32=1 ;;
++ i386 | powerpc | mips | mipsel) target_m32=1 ;;
+ x86_64 | sparc64) target_m64=1 ;;
+esac
+ fi
+@@ -352,8 +358,8 @@
+ unset ac_cv_c_bigendian
+
+ if test x$target_cpu-$platform = xsparc64-emu ; then
+- CFLAGS=$CFLAGS -m64
+- HOST_CFLAGS=$HOST_CFLAGS -m64
++ CFLAGS=$CFLAGS $m64_option
++ HOST_CFLAGS=$HOST_CFLAGS $m64_option
+ fi
+
+ AC_C_BIGENDIAN
+@@ -586,19 +592,19 @@
+
+ if test x$target_m32 = x1; then
+ # Force 32-bit mode.
+- TARGET_CFLAGS=$TARGET_CFLAGS -m32
Bug#774832: gluegen2: add mips64(el) and mipsn32(el) support
Package: gluegen2
Version: 2.2.4-2
This patch adds mips64(el) and mipsn32(el) support.
Please consider it.
--
YunQiang Su
Index: gluegen2-2.2.4/make/build.xml
===
--- gluegen2-2.2.4.orig/make/build.xml 2015-01-08 14:24:57.996411411 +0800
+++ gluegen2-2.2.4/make/build.xml 2015-01-08 15:27:57.281729646 +0800
@@ -294,6 +294,30 @@
property name=linker.cfg.id
value=linker.cfg.linux.mipsel /
/target
+target name=declare.linux.mipsn32 if=isLinuxMipsn32
+ echo message=Linux.mipsn32 /
+ property name=compiler.cfg.id
value=compiler.cfg.linux /
+ property name=linker.cfg.id
value=linker.cfg.linux.mipsn32 /
+/target
+
+target name=declare.linux.mipsn32el if=isLinuxMipsn32el
+ echo message=Linux.mipsn32el /
+ property name=compiler.cfg.id
value=compiler.cfg.linux /
+ property name=linker.cfg.id
value=linker.cfg.linux.mipsn32el /
+/target
+
+target name=declare.linux.mips64 if=isLinuxMips64
+ echo message=Linux.mips64 /
+ property name=compiler.cfg.id
value=compiler.cfg.linux /
+ property name=linker.cfg.id
value=linker.cfg.linux.mips64 /
+/target
+
+target name=declare.linux.mips64el if=isLinuxMips64el
+ echo message=Linux.mips64el /
+ property name=compiler.cfg.id
value=compiler.cfg.linux /
+ property name=linker.cfg.id
value=linker.cfg.linux.mips64el /
+/target
+
target name=declare.linux.ppc if=isLinuxPpc
echo message=Linux.ppc /
property name=compiler.cfg.id
value=compiler.cfg.linux /
@@ -336,7 +360,7 @@
property name=linker.cfg.id
value=linker.cfg.linux.sparc /
/target
-target name=declare.linux
depends=declare.linux.x86,declare.linux.amd64,declare.linux.alpha,declare.linux.ia64,declare.linux.hppa,declare.linux.mips,declare.linux.mipsel,declare.linux.ppc,declare.linux.ppc64,declare.linux.ppc64le,declare.linux.aarch64,declare.linux.s390,declare.linux.s390x,declare.linux.sparc,declare.linux.armv6.armel,declare.linux.armv6.armhf
if=isLinux
+target name=declare.linux
depends=declare.linux.x86,declare.linux.amd64,declare.linux.alpha,declare.linux.ia64,declare.linux.hppa,declare.linux.mips,declare.linux.mipsel,declare.linux.mipsn32,declare.linux.mipsn32el,declare.linux.mips64,declare.linux.mips64el,declare.linux.ppc,declare.linux.ppc64,declare.linux.ppc64le,declare.linux.aarch64,declare.linux.s390,declare.linux.s390x,declare.linux.sparc,declare.linux.armv6.armel,declare.linux.armv6.armhf
if=isLinux
property name=c.src.dir.os value=unix /
property name=java.includes.dir.platform
value=${java.includes.dir}/linux /
/target
Index: gluegen2-2.2.4/make/gluegen-cpptasks-base.xml
===
--- gluegen2-2.2.4.orig/make/gluegen-cpptasks-base.xml 2015-01-08
14:24:58.004223911 +0800
+++ gluegen2-2.2.4/make/gluegen-cpptasks-base.xml 2015-01-08
15:56:26.160709142 +0800
@@ -45,6 +45,10 @@
- isLinuxHppa
- isLinuxMips
- isLinuxMipsel
+ - isLinuxMipsn32
+ - isLinuxMipsn32el
+ - isLinuxMips64
+ - isLinuxMipsn64el
- isLinuxPpc
- isLinuxPpc64
- isLinuxPpc64le
@@ -132,6 +136,10 @@
- compiler.cfg.linux.hppa
- compiler.cfg.linux.mips
- compiler.cfg.linux.mipsel
+ - compiler.cfg.linux.mipsn32
+ - compiler.cfg.linux.mipsn32el
+ - compiler.cfg.linux.mips64
+ - compiler.cfg.linux.mips64el
- compiler.cfg.linux.ppc
- compiler.cfg.linux.ppc64
- compiler.cfg.linux.ppc64le
@@ -157,6 +165,10 @@
- linker.cfg.linux.hppa
- linker.cfg.linux.mips
- linker.cfg.linux.mipsel
+ - linker.cfg.linux.mipsn32
+ - linker.cfg.linux.mipsn32el
+ - linker.cfg.linux.mips64
+ - linker.cfg.linux.mips64el
- linker.cfg.linux.ppc
- linker.cfg.linux.s390
- linker.cfg.linux.s390x
@@ -389,6 +401,42 @@
condition property=mipsel
os arch=mipsel /
/condition
+condition property=isLinuxMipsn32
+ and
+istrue value=${isLinux} /
+os arch=mipsn32 /
+ /and
+/condition
+condition property=mipsn32
+ os arch=mipsn32 /
+/condition
+condition property=isLinuxMipsn32el
+ and
+istrue value=${isLinux} /
+os arch=mipsn32el /
+ /and
+/condition
+condition property=mipsn32el
+ os arch=mipsn32el /
+/condition
+condition property=isLinuxMips64
+ and
+istrue value=${isLinux} /
+os arch=mips64 /
+ /and
+/condition
+condition property=mips64
+ os arch=mips64 /
+/condition
+condition
Bug#774548: gcc-4.9: add with_deps_on_target_arch_pkgs back and rename packages
Package: src:gcc-4.9 Version: 4.9.2-10 This patch add with_deps_on_target_arch_pkgs back and when it is used, rename the packages, like gcc-4.9, with pattern like gcc-4.9-arch instead of gcc-4.9-triplet -- YunQiang Su 0001-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch Description: Binary data
Bug#774541: gcc-4.9: remove override with_deps_on_target_arch_pkgs
Package: gcc-4.9 Version: 4.9.2-10 Please remove override with_deps_on_target_arch_pkgs := in debian/rules.defs Which is not used any more. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774543: gcc-4.9: add DEB_CROSS_NO_BIARCH support
Package: src:gcc-4.9 Version: 4.9.2-10 Please add DEB_CROSS_NO_BIARCH option, so we can build it without biarch support if necessary. -- YunQiang Su 0003-allow-no-biarch.patch Description: Binary data
Bug#774208: cpl-plugin-kmos failed to run test on mips64el
Package: src:cpl-plugin-kmos
Version: 1.3.5+dfsg-1
With a modification for debian/patches/fix_test_fail.patch, it can be fixed.
Author: Ole Streicher deb...@liska.ath.cx
Description: Increase tolerance to fix FTBS on mips and ia64
Index: cpl-plugin-kmos-1.3.5+dfsg/irplib/tests/irplib_polynomial-test.c
===
--- cpl-plugin-kmos-1.3.5+dfsg.orig/irplib/tests/irplib_polynomial-test.c
2014-04-11 17:31:07.0 +0800
+++ cpl-plugin-kmos-1.3.5+dfsg/irplib/tests/irplib_polynomial-test.c
2014-12-30 17:24:30.234260459 +0800
@@ -567,16 +567,16 @@
const double root = cpl_vector_get(roots, i);
const double residual = cpl_polynomial_eval_1d(p1d, root, NULL);
-cpl_test_abs(root, cpl_vector_get(self, i), tolerance);
+cpl_test_abs(root, cpl_vector_get(self, i), 2*tolerance);
-cpl_test_abs(residual, 0.0, resitol);
+cpl_test_abs(residual, 0.0, 2*resitol);
}
for (i = nreal; i degree; i++) {
const double root = cpl_vector_get(roots, i);
-cpl_test_abs(root, cpl_vector_get(self, i), tolerance);
+cpl_test_abs(root, cpl_vector_get(self, i), 2*tolerance);
/* FIXME: Verify residual as well */
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766366: src:choreonoid: FTBFS on ppc64el: cast from pointer to udword loses precision
On Fri, 14 Nov 2014 19:42:31 + Edmund Grimley Evans edmund.grimley.ev...@gmail.com wrote: And to make it work on arm64 too, please make it: #if defined(__x86_64) || defined(__PPC64__) || defined(__aarch64__) Maybe, #if defined(__LP64__) || defined(__ILP64__) || defined(__LLP64__) is a better option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766708: counterfeiting the summary of the bootstrap sprint
I have a suggestion: Wookey, can you use package name like cpp-4.9-armhf instead of cpp-4.9-arm-linux-gnuabihf ? Then we can have both schemes in archive? Wookey, can you remove cross-gcc-* packages from archive temporarily? Doko, can you merge the attached patches? In 0006-gcc-pkg-rename.patch, and when define with_deps_on_target_arch_pkgs, gcc-4.9-ARCH will be generated instead of gcc-4.9-triplet. On Fri, Dec 5, 2014 at 11:28 AM, YunQiang Su wzss...@gmail.com wrote: On Thu, 04 Dec 2014 20:41:57 +0100 Matthias Klose d...@debian.org wrote: So in the last email Wookey enumerates a lot of things what he did during the last months. Maybe he should have mentioned his ballerina lessons used for his performances during the DebConf talks too. However ever all of these have in common, that this has nothing to do at all with the work he committed to do. Further he cites a paragraph from the debian-bootstrap sprint summary, which reads: The report from that meeting https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results says: -- 3.13. Multiarch cross-toolchains vs single-arch cross-toolchains This contentious issue was discussed, and is partly covered under other headings. Wookey prefers the multiarch builds, Doko prefers the single-arch bootstrap builds. We agreed that either provides useful cross-toolchains. It's not clear whether it's easier to fix the Ubuntu cross-toolchain-base packages to do a bootstrap build in Debian, or to fix the blockers for multiarch builds in the archive. Whichever is working first should get uploaded. Good summery, and I also prefer multiarch builds and I also maintain it for mips64el. And more: multiarch builds can also bootstrap. I bootstrapped mips64el in this way, and now, it need some dirty hacks,while if we wish, we can make it much more clean. As I noticed that, the argument that to remove multiarch builds includes (wish I am right): 1. multiarch builds make single-arch some more difficult, and maintain 2 way is not a esay way. Yes, while it is more difficult not impossible. 2. multiarch builds needs cross depends, which is hard for Debian infrastructure Yes, this is a problem for now, while I think this is the direction we are stepping for. 3. Bootstrap need single-arch No, this is wrong, we can bootstrap Debian with multiarch builds. The steps are: 1. cross binutils - we have it in archive. 2. stage1 gcc, with only C support, and libgcc is also disabled. 3. stage1 glibc - it is a fake libc6, we can patch glibc to archive it. 4. linux-libc-dev - we can use stage1 gcc to get it. src:linux support it now. 5. stage2 gcc - it has shared and static libraries support now and libgcc etc are still disabled 6. stage2 glibc - now we can use stage2 gcc to build glib, and we can get libc6(-dev) and multilib libc6. 7. stage3 gcc, now we can build a gcc with C,C++,Go, D and fortran support. In every step, we get some DEBs, and we can install some of them, and go to the next step. Of course, these steps may make some trouble for packages like gcc-4.8-armhf-cross. If we split it to more than one source packages, it is still possible when infrastructure support. If you repack these DEBs, it also can archive the goal of current gcc-4.8-armhf-cross. By the way, if we remove single-arch build, this package will be much more clean than now, lots of hacks can be removed from current gcc-4.9 and make life more happy. According to https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results?action=diffrev1=30rev2=31 the last sentence was added on Aug 29 during DebConf, long after the sprint happened, with a commment must be almost the final review, without mentioning anything. I call this counterfeiting the summary of the sprint. I assume this helped to convince other people to sneak in these packages into Debian. What is this if not bad faith? Again, the rest of the email talking about willing to work together doesn't match the his actions at all. Matthias -- YunQiang Su 0001-libgcc-4.9-dev-depends-equal.patch Description: Binary data 0002-gcc_cross_multiarch.patch Description: Binary data 0003-allow-no-biarch.patch Description: Binary data 0004-gxx-crossbase-substvar.patch Description: Binary data 0005-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch Description: Binary data 0006-gcc-pkg-rename.patch Description: Binary data
Bug#773300: Improve glibc bootstrap
Sorry, forgot to attach the new patch.
On Thu, Dec 18, 2014 at 11:44 PM, YunQiang Su wzss...@gmail.com wrote:
Thank you for pointing them out.
On Wed, Dec 17, 2014 at 3:10 AM, Helmut Grohne hel...@subdivi.de wrote:
On Tue, Dec 16, 2014 at 11:39:40PM +0800, YunQiang Su wrote:
Hi, the attached patch can improve bootstrapping of glibc.
Partially, this seems to be a duplicate of #766877. Maybe these should
be merged?
It produces the similiar stage1 glibc
(libc6/libc6-dev and multilib version of them),
at the same time, the dependencies of them are also correct.
The documentation and rationale of this patch are scarce. I have a few
comments on individual hunks though.
diff -Nru glibc-2.19/debian/rules glibc-2.19/debian/rules
--- glibc-2.19/debian/rules 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/rules 2014-12-10 23:16:28.0 +
@@ -143,8 +143,12 @@
endif
endif
+ifeq ($(DEB_STAGE),stage2)
+ DEB_BUILD_PROFILES+=stage2
+endif
+
ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
- DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
+ DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)
DEB_INDEP_REGULAR_PACKAGES =
DEB_UDEB_PACKAGES =
else
I have no clue how one would build the libc in stage1. The gcc stage1
does not provide the means for doing so. If anything those packages
would be empty. I.e. this seems rather wrong to me.
Yes, it is a empty package and are used only for meeting dependency.
It is only for stage1, and it can make things simple.
I don't treat it as a problem.
diff -Nru glibc-2.19/debian/sysdeps/linux.mk
glibc-2.19/debian/sysdeps/linux.mk
--- glibc-2.19/debian/sysdeps/linux.mk 2014-07-16 18:43:31.0 +
+++ glibc-2.19/debian/sysdeps/linux.mk 2014-12-10 23:11:05.0 +
@@ -16,11 +16,7 @@
endif
ifndef LINUX_SOURCE
- ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-LINUX_HEADERS := /usr/include
- else
-LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
- endif
+ LINUX_HEADERS := /usr/include
LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
LINUX_HEADERS := $(LINUX_SOURCE)/include
This breaks the supported cross build method.
- ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
+ ifeq ($(shell dpkg-query --status
linux-libc-dev-$(DEB_HOST_ARCH)-cross 2/dev/null),)
LINUX_HEADERS := /usr/include
else
LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
endif
+ LINUX_HEADERS := /usr/include
LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
LINUX_HEADERS := $(LINUX_SOURCE)/include
Will it be ok? I am not very sure whether
linux-libc-dev-$(DEB_HOST_ARCH)-cross
will be installed in the support method scheme.
diff -Nru glibc-2.19/debian/sysdeps/mips64.mk
glibc-2.19/debian/sysdeps/mips64.mk
--- glibc-2.19/debian/sysdeps/mips64.mk 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/sysdeps/mips64.mk 2014-12-11 03:50:09.0 +
@@ -59,5 +59,5 @@
# create a symlink for the 32 bit dynamic linker in /lib
define libc6-mips32_extra_pkg_install
mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf ../libo32/ld.so.1 debian/libc6-mips32/lib
endef
This violates a should in Debian policy section 10.5.
Will mv OK?
mv -f debian/libc6-mips32/libo32/{ld.so.1,ld-*.so} debian/libc6-mips32/lib
I tested it. It works on mips64el.
Helmut
--
YunQiang Su
--
YunQiang Su
glibc.debdiff
Description: Binary data
Bug#773300: Improve glibc bootstrap
Thank you for pointing them out.
On Wed, Dec 17, 2014 at 3:10 AM, Helmut Grohne hel...@subdivi.de wrote:
On Tue, Dec 16, 2014 at 11:39:40PM +0800, YunQiang Su wrote:
Hi, the attached patch can improve bootstrapping of glibc.
Partially, this seems to be a duplicate of #766877. Maybe these should
be merged?
It produces the similiar stage1 glibc
(libc6/libc6-dev and multilib version of them),
at the same time, the dependencies of them are also correct.
The documentation and rationale of this patch are scarce. I have a few
comments on individual hunks though.
diff -Nru glibc-2.19/debian/rules glibc-2.19/debian/rules
--- glibc-2.19/debian/rules 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/rules 2014-12-10 23:16:28.0 +
@@ -143,8 +143,12 @@
endif
endif
+ifeq ($(DEB_STAGE),stage2)
+ DEB_BUILD_PROFILES+=stage2
+endif
+
ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
- DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
+ DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)
DEB_INDEP_REGULAR_PACKAGES =
DEB_UDEB_PACKAGES =
else
I have no clue how one would build the libc in stage1. The gcc stage1
does not provide the means for doing so. If anything those packages
would be empty. I.e. this seems rather wrong to me.
Yes, it is a empty package and are used only for meeting dependency.
It is only for stage1, and it can make things simple.
I don't treat it as a problem.
diff -Nru glibc-2.19/debian/sysdeps/linux.mk
glibc-2.19/debian/sysdeps/linux.mk
--- glibc-2.19/debian/sysdeps/linux.mk 2014-07-16 18:43:31.0 +
+++ glibc-2.19/debian/sysdeps/linux.mk 2014-12-10 23:11:05.0 +
@@ -16,11 +16,7 @@
endif
ifndef LINUX_SOURCE
- ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-LINUX_HEADERS := /usr/include
- else
-LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
- endif
+ LINUX_HEADERS := /usr/include
LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
LINUX_HEADERS := $(LINUX_SOURCE)/include
This breaks the supported cross build method.
- ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
+ ifeq ($(shell dpkg-query --status
linux-libc-dev-$(DEB_HOST_ARCH)-cross 2/dev/null),)
LINUX_HEADERS := /usr/include
else
LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
endif
+ LINUX_HEADERS := /usr/include
LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
LINUX_HEADERS := $(LINUX_SOURCE)/include
Will it be ok? I am not very sure whether linux-libc-dev-$(DEB_HOST_ARCH)-cross
will be installed in the support method scheme.
diff -Nru glibc-2.19/debian/sysdeps/mips64.mk
glibc-2.19/debian/sysdeps/mips64.mk
--- glibc-2.19/debian/sysdeps/mips64.mk 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/sysdeps/mips64.mk 2014-12-11 03:50:09.0 +
@@ -59,5 +59,5 @@
# create a symlink for the 32 bit dynamic linker in /lib
define libc6-mips32_extra_pkg_install
mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf ../libo32/ld.so.1 debian/libc6-mips32/lib
endef
This violates a should in Debian policy section 10.5.
Will mv OK?
mv -f debian/libc6-mips32/libo32/{ld.so.1,ld-*.so} debian/libc6-mips32/lib
I tested it. It works on mips64el.
Helmut
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
Waoo, great work.
Now I understand what it is for.
Looong Looong ago, something may make libn32blabla depend on
lib64blabla in control,
so this snap of code exits.
Now we don't have this problem, all libn32blabla depends on
Depends: gcc-4.9-base (= ${gcc:Version}), ${dep:libcbiarch},
${shlibs:Depends}, ${misc:Depends}
No lib64blabla in them, so we should remove these codes.
On Tue, Dec 16, 2014 at 3:34 PM, Helmut Grohne hel...@subdivi.de wrote:
On Wed, Dec 10, 2014 at 09:54:01AM +0100, Matthias Klose wrote:
I can't remember. please ask the Debian mips maintainers. I assume, extending
the expression to entirely remove empty fields should work around this for
now.
I did X-Debbugs-Cc the submission to debian-mips@l.d.o. So now I did
some archeology:
* The affected code was inserted in the gcc-4.4 era.
* It is inserted in SVN revision 4707.
* The commit message closes #594540.
Unfortunately the bug report is rather scarce on details, but it appears
to be talking about library packages. So I went ahead and restricted the
match to lib$biarch. The immediate effect is that it no longer matches
mips64el and thus leaves the Recommends on libc alone. Thus the stage1
becomes installable. I did not notice any excess dependencies.
I could not verify further stages as the stage2 build fails linking the
n32 libc.so, because it insists on linking the 64 one. The latter may be
an error in my build environment.
Nevertheless, I am attaching a patch for what I believe to be the
correct solution.
Helmut
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773300: Improve glibc bootstrap
Package: src:glibc Version: 2.20-1 Hi, the attached patch can improve bootstrapping of glibc. It produces the similiar stage1 glibc (libc6/libc6-dev and multilib version of them), at the same time, the dependencies of them are also correct. So it will more smooth to bootstrap Debian. Please consider it in the future version (2.20?) -- YunQiang Su glibc.debdiff Description: Binary data
Bug#772665: produces broken cross compiler packages for mips64el
On Wed, 10 Dec 2014 09:54:01 +0100 Matthias Klose d...@debian.org wrote: Control: tags -1 + moreinfo help On 12/09/2014 08:46 PM, Helmut Grohne wrote: Package: src:gcc-4.9 Version: 4.9.2-5 User: helm...@debian.org Usertags: rebootstrap When building a cross compiler for mips64el (and possibly other mips architectures), some binary packages are broken. $ dpkg-deb -I ./libn32gcc-4.9-dev-mips64el-cross_4.9.2-5_all.deb new debian package, version 2.0. size 86302 bytes: control archive=850 bytes. 503 bytes,14 lines control 854 bytes, 9 lines md5sums Package: libn32gcc-4.9-dev-mips64el-cross Source: gcc-4.9 Version: 4.9.2-5 Architecture: all Maintainer: Debian GCC Maintainers debian-...@lists.debian.org Installed-Size: 2484 Depends: gcc-4.9-base (= 4.9.2-5) Recommends: Section: libdevel Priority: optional Homepage: http://gcc.gnu.org/ Description: GCC support library (n32 development files) This package contains the headers and static library files necessary for building C programs which use libgcc, libgomp, libquadmath, libssp or libitm. $ Please pay attention to the value of Recommends. It is an empty field, but the field is still there. This makes e.g. apt-get update choke: | Reading package lists... | E: Problem parsing dependency Recommends | E: Error occurred while processing libn32gcc-4.9-dev-mips64el-cross (NewVersion2) | E: Problem with MergeList /var/lib/apt/lists/... | E: The package lists or status file could not be parsed or opened. One wonders how an empty Recommends field can end up in the control file, when dpkg-gencontrol explicitly discards empty fields. In fact, the field is not empty after the dpkg-gencontrol invocation. Instead it contains: | Recommends: libc6-dev-mips64el-cross (= 2.13-5) A bit later the following command is executed during build: | sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+64[^,]+(, *|$)//g;/^(Dep|Rec|Sug)/s/libgcc1-mips64el-cross/libn32gcc1-mips64el-cross/;/^(Dep|Rec|Sug)/s/ *, *$//' debian/libn32gcc-4.9-dev-mips64el-cross/DEBIAN/control The first command in the sed expression discards the libc dependency. It comes from debian/rules.defs: | ifneq (,$(filter $(DEB_TARGET_ARCH), mips mipsel mips64 mips64el mipsn32 mipsn32el)) | define cross_mangle_control | $(if $(findstring lib64,$(1)),sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+32[^$(COMMA)]+($(COMMA) *|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_l64gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA) *$$//' debian/$(1)/DEBIAN/control,@:) | $(if $(findstring libn32,$(1)),sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+64[^$(COMMA)]+($(COMMA) *|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_ln32gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA) *$$//' debian/$(1)/DEBIAN/control,@:) I believe that it should be just a workaround in the dark age that control.m4 cannot process some triarch situation. Now we have control.m4 workable, so I believe that we can remove them. It was used by with_deps_on_target_arch_pkgs only, so it is useless now. You can remove these lines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
On Thu, Dec 11, 2014 at 4:57 PM, Matthias Klose d...@debian.org wrote: On 12/11/2014 09:35 AM, YunQiang Su wrote: I believe that it should be just a workaround in the dark age that control.m4 cannot process some triarch situation. Now we have control.m4 workable, so I believe that we can remove them. It was used by with_deps_on_target_arch_pkgs only, so it is useless now. You can remove these lines. Please could you verify that, and attach a build log of such a triarch cross build? In recent modifications: ifneq (,$(filter $(DEB_TARGET_ARCH), mips mipsel mips64 mips64el mipsn32 mipsn32el)) - ifneq ($(with_deps_on_target_arch_pkgs),yes) -define cross_mangle_control + define cross_mangle_control $(if $(findstring lib64,$(1)),sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+32[^$(COMMA)]+($(COMMA) *|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_l64gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA) *$$//' debian/$(1)/DEBIA N/control,@:) $(if $(findstring libn32,$(1)),sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+64[^$(COMMA)]+($(COMMA) *|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_ln32gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA) *$$//' debian/$(1)/DEBIAN/control,@:) -endef - else -define cross_mangle_control -endef - endif + endef You removed with_deps_on_target_arch_pkgs condition before it. It was used only when with_deps_on_target_arch_pkgs set, and also now when with_deps_on_target_arch_pkgs set, it is also useless. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766708: counterfeiting the summary of the bootstrap sprint
On Thu, 04 Dec 2014 20:41:57 +0100 Matthias Klose d...@debian.org wrote: So in the last email Wookey enumerates a lot of things what he did during the last months. Maybe he should have mentioned his ballerina lessons used for his performances during the DebConf talks too. However ever all of these have in common, that this has nothing to do at all with the work he committed to do. Further he cites a paragraph from the debian-bootstrap sprint summary, which reads: The report from that meeting https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results says: -- 3.13. Multiarch cross-toolchains vs single-arch cross-toolchains This contentious issue was discussed, and is partly covered under other headings. Wookey prefers the multiarch builds, Doko prefers the single-arch bootstrap builds. We agreed that either provides useful cross-toolchains. It's not clear whether it's easier to fix the Ubuntu cross-toolchain-base packages to do a bootstrap build in Debian, or to fix the blockers for multiarch builds in the archive. Whichever is working first should get uploaded. Good summery, and I also prefer multiarch builds and I also maintain it for mips64el. And more: multiarch builds can also bootstrap. I bootstrapped mips64el in this way, and now, it need some dirty hacks,while if we wish, we can make it much more clean. As I noticed that, the argument that to remove multiarch builds includes (wish I am right): 1. multiarch builds make single-arch some more difficult, and maintain 2 way is not a esay way. Yes, while it is more difficult not impossible. 2. multiarch builds needs cross depends, which is hard for Debian infrastructure Yes, this is a problem for now, while I think this is the direction we are stepping for. 3. Bootstrap need single-arch No, this is wrong, we can bootstrap Debian with multiarch builds. The steps are: 1. cross binutils - we have it in archive. 2. stage1 gcc, with only C support, and libgcc is also disabled. 3. stage1 glibc - it is a fake libc6, we can patch glibc to archive it. 4. linux-libc-dev - we can use stage1 gcc to get it. src:linux support it now. 5. stage2 gcc - it has shared and static libraries support now and libgcc etc are still disabled 6. stage2 glibc - now we can use stage2 gcc to build glib, and we can get libc6(-dev) and multilib libc6. 7. stage3 gcc, now we can build a gcc with C,C++,Go, D and fortran support. In every step, we get some DEBs, and we can install some of them, and go to the next step. Of course, these steps may make some trouble for packages like gcc-4.8-armhf-cross. If we split it to more than one source packages, it is still possible when infrastructure support. If you repack these DEBs, it also can archive the goal of current gcc-4.8-armhf-cross. By the way, if we remove single-arch build, this package will be much more clean than now, lots of hacks can be removed from current gcc-4.9 and make life more happy. According to https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results?action=diffrev1=30rev2=31 the last sentence was added on Aug 29 during DebConf, long after the sprint happened, with a commment must be almost the final review, without mentioning anything. I call this counterfeiting the summary of the sprint. I assume this helped to convince other people to sneak in these packages into Debian. What is this if not bad faith? Again, the rest of the email talking about willing to work together doesn't match the his actions at all. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768167: dpkg-architecture export DEB_TARGET_* make cross build failure
Package: src:gcc-4.9 Version: 4.9.2-1 In the past, dpkg-architecture doesn't export DEB_TARGET_* Vars, so in rules.defs ifdef DEB_TARGET_GNU_TYPE TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) else # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif DEB_TARGET_ARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) works But now, when DEB_TARGET_GNU_TYPE and DEB_TARGET_ARCH always define, we can not get cross complier with debian/target file or DEB_GCC_TARGET var. Modifying it to this can fix this problem # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) DEB_TARGET_ARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) GCC 4.8 also has the same problem. -- YunQiang Su --- gcc-4.9-4.9.2/debian/rules.defs 2014-11-06 00:12:34.0 +0800 +++ gcc-4.9/debian/rules.defs 2014-11-06 00:03:38.081051557 +0800 @@ -89,33 +89,30 @@ ifdef GCC_TARGET DEB_GCC_TARGET := $(GCC_TARGET) endif -ifdef DEB_TARGET_GNU_TYPE - TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) -else - # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested - # by toolchain-source maintainer - DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) - ifndef DEB_TARGET_ARCH -ifneq (,$(DEBIAN_TARGET_FILE)) - DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) + +# allow debian/target to be used instead of DEB_GCC_TARGET - this was requested +# by toolchain-source maintainer +DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) +ifndef DEB_TARGET_ARCH + ifneq (,$(DEBIAN_TARGET_FILE)) +DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) + else +ifdef DEB_GCC_TARGET + DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else - ifdef DEB_GCC_TARGET -DEB_TARGET_ARCH := $(DEB_GCC_TARGET) - else -DEB_TARGET_ARCH := $(DEB_HOST_ARCH) - endif + DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif - TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif +TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) -DEB_TARGET_ARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) -DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) -DEB_TARGET_ARCH_CPU?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) -DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) -DEB_TARGET_GNU_TYPE?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) -DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) -DEB_TARGET_MULTIARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) +DEB_TARGET_ARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) +DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) +DEB_TARGET_ARCH_CPU:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) +DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) +DEB_TARGET_GNU_TYPE:= $(call vafilt
Bug#768167: dpkg-architecture export DEB_TARGET_* make cross build failure
On Thu, 6 Nov 2014 00:15:13 +0800 YunQiang Su wzss...@gmail.com wrote: Package: src:gcc-4.9 Version: 4.9.2-1 In the past, dpkg-architecture doesn't export DEB_TARGET_* Vars, so in rules.defs ifdef DEB_TARGET_GNU_TYPE TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) else # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif DEB_TARGET_ARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) works But now, when DEB_TARGET_GNU_TYPE and DEB_TARGET_ARCH always define, we can not get cross complier with debian/target file or DEB_GCC_TARGET var. Modifying it to this can fix this problem # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH This line is also need to be removed, so update the patch. ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) --- gcc-4.9-4.9.2/debian/rules.defs 2014-11-06 00:12:34.0 +0800 +++ gcc-4.9/debian/rules.defs 2014-11-06 00:34:16.521099152 +0800 @@ -89,33 +89,28 @@ ifdef GCC_TARGET DEB_GCC_TARGET := $(GCC_TARGET) endif -ifdef DEB_TARGET_GNU_TYPE - TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) + +# allow debian/target to be used instead of DEB_GCC_TARGET - this was requested +# by toolchain-source maintainer +DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) +ifneq (,$(DEBIAN_TARGET_FILE)) + DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else - # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested - # by toolchain-source maintainer - DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) - ifndef DEB_TARGET_ARCH -ifneq (,$(DEBIAN_TARGET_FILE)) - DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) -else - ifdef DEB_GCC_TARGET -DEB_TARGET_ARCH := $(DEB_GCC_TARGET) - else -DEB_TARGET_ARCH := $(DEB_HOST_ARCH) - endif -endif + ifdef DEB_GCC_TARGET +DEB_TARGET_ARCH := $(DEB_GCC_TARGET) + else +DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif - TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif +TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) -DEB_TARGET_ARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) -DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) -DEB_TARGET_ARCH_CPU?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) -DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) -DEB_TARGET_GNU_TYPE?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) -DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) -DEB_TARGET_MULTIARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) +DEB_TARGET_ARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) +DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) +DEB_TARGET_ARCH_CPU:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) +DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) +DEB_TARGET_GNU_TYPE:= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) +DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) +DEB_TARGET_MULTIARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) ifeq ($(DEB_TARGET_GNU_TYPE),i486-linux-gnu) DEB_TARGET_GNU_TYPE = i586-linux-gnu
Bug#762775: pynfft: FTBFS: dh: unable to load addon sphinxdoc
On Wed, 24 Sep 2014 22:56:11 -0400 Aaron M. Ucko u...@debian.org 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
Bug#766984: geographiclib: fix symbols for mips64(el) and ppc64el
On Mon, 27 Oct 2014 20:06:34 +0800 YunQiang Su wzss...@gmail.com wrote: Package: geographiclib Version: 1.37-2 libgeographic13's symbol file has an error for mips64(el) and a warning for both mips64(el) and ppc64el diff -Nru geographiclib-1.37/debian/libgeographic13.symbols geographiclib-1.37/debian/libgeographic13.symbols --- geographiclib-1.37/debian/libgeographic13.symbols 2014-09-30 14:10:09.0 +0800 +++ geographiclib-1.37/debian/libgeographic13.symbols 2034-12-21 17:17:57.0 +0800 @@ -221,7 +221,7 @@ _ZN13GeographicLib7Utility3strIcEESsT_i@Base 1.37 _ZN13GeographicLib7Utility3strIiEESsT_i@Base 1.37 _ZN13GeographicLib7Utility5fractIdEET_RKSs@Base 1.37 - (arch=armel armhf mips mipsel powerpc)_ZN13GeographicLib7Utility6lookupERKSsc@Base 1.37-1 + (arch=armel armhf mips mipsel mips64 mips64el powerpc ppc64el)_ZN13GeographicLib7Utility6lookupERKSsc@Base 1.37-1 _ZN13GeographicLib7Utility9ParseLineERKSsRSsS3_@Base 1.37 _ZN13GeographicLib8Geodesic12SinCosSeriesEbddPKdi@Base 1.37 _ZN13GeographicLib8Geodesic3C1fEdPd@Base 1.37 @@ -440,7 +440,7 @@ _ZNSt6vectorItSaItEEaSERKS1_@Base 1.37 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EOS6_S7_@Base 1.37 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_@Base 1.37 - (arch=!hurd-i386 !i386 !kfreebsd-i386)_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_@Base 1.37 + (arch=!hurd-i386 !i386 !kfreebsd-i386 !mips64 !mips64el)_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_@Base 1.37 _ZTIN13GeographicLib13GeographicErrE@Base 1.37 _ZTSN13GeographicLib13GeographicErrE@Base 1.37 _ZTVN13GeographicLib13GeographicErrE@Base 1.37 I NMUed this package with the attached patch. -- YunQiang Su geographiclib.debdiff Description: Binary data
Bug#766951: hyperic-sigar: don't use -m64 for mips64(el) and arm64
On Mon, 27 Oct 2014 15:44:35 +0800 YunQiang Su wzss...@gmail.com wrote:
Package: hyperic-sigar
Version: 1.6.4+dfsg-2
When build this package it set '-m64' for mips64(el) and arm64.
This patch can fix this problem.
Index:
hyperic-sigar-1.6.4+dfsg/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
===
---
hyperic-sigar-1.6.4+dfsg.orig/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2013-01-28 06:39:57.0 +0800
+++
hyperic-sigar-1.6.4+dfsg/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2034-12-21 14:48:11.186686096 +0800
@@ -75,7 +75,8 @@
if (ArchName.is64()) {
getProject().setProperty(jni.arch64, true);
if (ArchLoader.IS_LINUX) {
-if (!osArch.equals(ia64)) {
+if (!osArch.equals(ia64) !osArch.equals(mips64el)
+ !osArch.equals(mips64)
!osArch.equals(aarch64)) {
getProject().setProperty(jni.gccm, -m64);
}
}
I NMUed this package with the attached patch.
--
YunQiang Su
hyperic-sigar.debdiff
Description: Binary data
Bug#767598: webkit2gtk: ftbfs on mips64el
Package: src:webkit2gtk Version: 2.6.2+dfsg1-1 Webkit2gtk has the same problem with webkitgtk, please apply the same patch to it. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767459: qbs: FTBFS on mips64/mips64el: endian problem
Package: qbs Version: 1.3.2+dfsg-1 Users: debian-m...@lists.debian.org Usertags: mips-port mips-patch Please add mips64/mips64el/mipsn32/mipsn32el in endianness.diff In these 4 archs, mips64 and mipsn32 are big endian and mips64el and mipsn32el are little endian. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725651: qtwebkit failed to build on mips64el
Any progress of this bug? On Mon, 26 May 2014 11:47:53 +0800 Yunqiang Su wzss...@gmail.com wrote: On Fri, May 9, 2014 at 11:13 AM, Yunqiang Su wzss...@gmail.com wrote: The upstream uses this patch. https://codereview.qt-project.org/#change,73290 and it has been merged. It is this patch. On Tue, Oct 22, 2013 at 11:43 PM, YunQiang Su wzss...@gmail.com wrote: On Wed, Oct 9, 2013 at 10:30 PM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: On Tuesday 08 October 2013 13:58:43 YunQiang Su wrote: On Mon, Oct 7, 2013 at 9:46 PM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: On Monday 07 October 2013 09:32:12 YunQiang Su wrote: Package: qtwebkit Version: 2.2.1-6 On mips64el, qtwebkit has the same problem like qt4. The attachment is the patch. Or where should I apply it to upstream? Hi YunQiang! As a rule of thumb, if it's something that does not involve packaging, pushing the patchs upstream is normally the best idea. An exception could be a patch that introduces something that is very Debian-related, but most of the time this can also be pushed upstream somehow. Thanks, I see. I am wondering about which component should it involve to qt? I have pushed this patch to qt/qt4/qtscripts. If the problem is in qtwebkit, then push it to qtwebkit. If in doubt, join upstream's irc #qt on freenode and ask. As you noticed, I pushed it the qt4 in Qt's gerrit. The new version of patch is Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- YunQiang Su -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713331: sphinxsearch: FTBFS: [automake-1.13 warning: linking libraries using a, non-POSIX]
I packaged the newer version 2.2.5. I will upload this package to 10 days delay. I have interesting to maintain it in future. If you don't think it is ok, please cancel this upload. On Wed, Oct 29, 2014 at 9:12 PM, YunQiang Su wzss...@gmail.com wrote: On Tue, 21 Oct 2014 18:36:58 +0530 Brahadambal Srinivasan la...@linux.vnet.ibm.com wrote: Package: sphinxsearch Version: 2.0.4-1.1 Followup-For: Bug #713331 Tags: patch X-Debbugs-Cc: bren...@br.ibm.com User: debian-powe...@lists.debian.org Usertags: ppc64el User: debian-de...@lists.debian.org Usertags: autoreconf Dear Maintainer, The package sphinxsearch fails to build on ppc64le, because of changes required in libtool, aclocal.m4 and configure.ac. This patch includes autotools-dev and a couple of changes in configure.ac to the package so that it builds correctly. Thanks for considering the patch! I tested your patch on mips64el, it works well. Thanks and regards, Brahadambal -- System Information: *** End of the template - remove these template lines *** Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.16-trunk-powerpc64le (SMP w/32 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713331: sphinxsearch: FTBFS: [automake-1.13 warning: linking libraries using a, non-POSIX]
On Tue, 21 Oct 2014 18:36:58 +0530 Brahadambal Srinivasan la...@linux.vnet.ibm.com wrote: Package: sphinxsearch Version: 2.0.4-1.1 Followup-For: Bug #713331 Tags: patch X-Debbugs-Cc: bren...@br.ibm.com User: debian-powe...@lists.debian.org Usertags: ppc64el User: debian-de...@lists.debian.org Usertags: autoreconf Dear Maintainer, The package sphinxsearch fails to build on ppc64le, because of changes required in libtool, aclocal.m4 and configure.ac. This patch includes autotools-dev and a couple of changes in configure.ac to the package so that it builds correctly. Thanks for considering the patch! I tested your patch on mips64el, it works well. Thanks and regards, Brahadambal -- System Information: *** End of the template - remove these template lines *** Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.16-trunk-powerpc64le (SMP w/32 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738376: postgresql-hll: FTBFS: dh: Unknown sequence debian/control.in (choose from: binary binary-arch binary-indep build build-arch build-indep clean install install-arch install-indep)
On Sun, 9 Feb 2014 17:55:12 +0100 David =?iso-8859-1?Q?Su=E1rez?= david.sephi...@gmail.com wrote: Source: postgresql-hll Version: 2.7-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20140208 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): fakeroot debian/rules clean dh debian/control.in dh: Unknown sequence debian/control.in (choose from: binary binary-arch binary-indep build build-arch build-indep clean install install-arch install-indep) make: *** [debian/control.in] Error 2 I NMUed this package with the attached patch. The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2014/02/08/postgresql-hll_2.7-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. postgresql-hll.debdiff Description: Binary data
Bug#767316: mate-control-center: should depend on libmarco-dev with version
Package: src:mate-control-center Version: 1.8.3+dfsg1-1 https://buildd.debian.org/status/fetch.php?pkg=mate-control-centerarch=sparcver=1.8.3%2Bdfsg1-1stamp=1414021145 configure: error: Package requirements (libmarco-private = 1.8.2) were not met: Requested 'libmarco-private = 1.8.2' but version of libmarco-private is 1.8.1 -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766951: hyperic-sigar: don't use -m64 for mips64(el) and arm64
Package: hyperic-sigar
Version: 1.6.4+dfsg-2
When build this package it set '-m64' for mips64(el) and arm64.
This patch can fix this problem.
Index:
hyperic-sigar-1.6.4+dfsg/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
===
---
hyperic-sigar-1.6.4+dfsg.orig/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2013-01-28 06:39:57.0 +0800
+++
hyperic-sigar-1.6.4+dfsg/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2034-12-21 14:48:11.186686096 +0800
@@ -75,7 +75,8 @@
if (ArchName.is64()) {
getProject().setProperty(jni.arch64, true);
if (ArchLoader.IS_LINUX) {
-if (!osArch.equals(ia64)) {
+if (!osArch.equals(ia64) !osArch.equals(mips64el)
+ !osArch.equals(mips64)
!osArch.equals(aarch64)) {
getProject().setProperty(jni.gccm, -m64);
}
}
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766953: llvm-toolchain-3.5: please provide lldb for mips64(el)
Package: llvm-toolchain-3.5 Version: 1:3.5-6 lldb built on mips64(el), while in debian/control, there is no this package. Please add mips64 and mips64el into the arch list for lldb. The same situation for llvm-toolchain-snapshot. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766963: llvm-defaults: add mips64 and mips64el to lldb list
Package: src:llvm-defaults Version: 0.24 Please add mips64 and mips64el to lldb support list in debian/rules. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766984: geographiclib: fix symbols for mips64(el) and ppc64el
Package: geographiclib Version: 1.37-2 libgeographic13's symbol file has an error for mips64(el) and a warning for both mips64(el) and ppc64el diff -Nru geographiclib-1.37/debian/libgeographic13.symbols geographiclib-1.37/debian/libgeographic13.symbols --- geographiclib-1.37/debian/libgeographic13.symbols 2014-09-30 14:10:09.0 +0800 +++ geographiclib-1.37/debian/libgeographic13.symbols 2034-12-21 17:17:57.0 +0800 @@ -221,7 +221,7 @@ _ZN13GeographicLib7Utility3strIcEESsT_i@Base 1.37 _ZN13GeographicLib7Utility3strIiEESsT_i@Base 1.37 _ZN13GeographicLib7Utility5fractIdEET_RKSs@Base 1.37 - (arch=armel armhf mips mipsel powerpc)_ZN13GeographicLib7Utility6lookupERKSsc@Base 1.37-1 + (arch=armel armhf mips mipsel mips64 mips64el powerpc ppc64el)_ZN13GeographicLib7Utility6lookupERKSsc@Base 1.37-1 _ZN13GeographicLib7Utility9ParseLineERKSsRSsS3_@Base 1.37 _ZN13GeographicLib8Geodesic12SinCosSeriesEbddPKdi@Base 1.37 _ZN13GeographicLib8Geodesic3C1fEdPd@Base 1.37 @@ -440,7 +440,7 @@ _ZNSt6vectorItSaItEEaSERKS1_@Base 1.37 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EOS6_S7_@Base 1.37 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_@Base 1.37 - (arch=!hurd-i386 !i386 !kfreebsd-i386)_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_@Base 1.37 + (arch=!hurd-i386 !i386 !kfreebsd-i386 !mips64 !mips64el)_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_@Base 1.37 _ZTIN13GeographicLib13GeographicErrE@Base 1.37 _ZTSN13GeographicLib13GeographicErrE@Base 1.37 _ZTVN13GeographicLib13GeographicErrE@Base 1.37 -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766993: jackd2: FTBFS with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4
Package: jackd2 Version: 1.9.10+20140719git3eb0ae6a~dfsg-2 When building jackd2 with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4, it fails: CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wall CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wall CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro -j4 ./waf-light configure --prefix=/usr --classic --libdir=/usr/lib/mips64el-linux-gnuabi64 --alsa --dbus /bin/sh: 1: -j4: not found The attached patch can fix it. -- YunQiang Su diff -Nru jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/rules jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/rules --- jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/rules 2014-09-25 03:36:18.0 +0800 +++ jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/rules 2034-12-21 20:32:39.0 +0800 @@ -39,12 +39,15 @@ # Minimum assured version referenced upstream as library API/ABI ABI = 0.118.0 +WAF_EXTRA_ARGS=$(shell echo '$(DEB_MAKE_EXTRA_ARGS)' | sed 's/-j[0-9]*//g') +WAF_JOBS=$(shell echo '$(DEB_MAKE_EXTRA_ARGS)' | grep -o -- '-j[0-9]*') + waf-configure-options = --prefix=/usr --classic waf-configure-options += --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) waf-configure-options += $(if $(filter linux,$(DEB_HOST_ARCH_OS)),--alsa --dbus) waf-configure-options += $(if $(filter amd64 i386 powerpc,$(DEB_HOST_ARCH)),--firewire) -DEB_MAKE_INVOKE = $(DEB_MAKE_EXTRA_ARGS) ./waf-light -v --destdir=$(CURDIR)/debian/tmp +DEB_MAKE_INVOKE = $(WAF_EXTRA_ARGS) ./waf-light -v --destdir=$(CURDIR)/debian/tmp $(WAF_JOBS) DEB_MAKE_INSTALL_TARGET = install # TODO: use distclean and drop related clean target, when (or if) @@ -75,7 +78,7 @@ common-configure-impl:: debian/stamp-waf-configure debian/stamp-waf-configure: chmod +x ./waf-light - $(DEB_MAKE_EXTRA_ARGS) ./waf-light configure $(waf-configure-options) + $(WAF_EXTRA_ARGS) ./waf-light configure $(waf-configure-options) $(WAF_JOBS) touch $@ clean:: rm -f debian/stamp-waf-configure
Bug#766993: jackd2: FTBFS with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4
On Mon, Oct 27, 2014 at 9:58 PM, Jonas Smedegaard d...@jones.dk wrote: Quoting YunQiang Su (2014-10-27 14:32:43) When building jackd2 with DEB_BUILD_PARALLEL=1 DEB_BUILD_OPTIONS=parallel=4, it fails: CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wall CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wall CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro -j4 ./waf-light configure --prefix=/usr --classic --libdir=/usr/lib/mips64el-linux-gnuabi64 --alsa --dbus /bin/sh: 1: -j4: not found The attached patch can fix it. Thanks! If I understand your patch correctly (have only read it briefly) the first lines are better written without making shell calls, like this: WAF_EXTRA_ARGS = $(filter-out -j%,$(DEB_MAKE_EXTRA_ARGS)) WAF_JOBS = $(filter -j%,$(DEB_MAKE_EXTRA_ARGS)) Yes, using functions from make should be better. ...and even better by using underlying variable instead of extracting from DEB_MAKE_EXTRA_ARGS. I am not very familiar with cdbs, so no idea about it. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752054: commons-daemon: add mips abi n32, n64 support
On Thu, 19 Jun 2014 15:10:25 +0800 Sphinx Jiang yishan...@gmail.com wrote: Index: commons-daemon-1.0.15/src/native/unix/support/apsupport.m4 === --- commons-daemon-1.0.15.orig/src/native/unix/support/apsupport.m4 2014-06-19 05:40:23.0 + +++ commons-daemon-1.0.15/src/native/unix/support/apsupport.m4 2014-06-19 05:46:23.202817468 + @@ -113,7 +113,7 @@ LDCMD=/opt/C/bin/cc HOST_CPU=osd ;; - mips) + mips | mipsn32 | mips64) CFLAGS=$CFLAGS -DCPU=\\\mips\\\ supported_os=mips HOST_CPU=mips @@ -142,7 +142,7 @@ fi CFLAGS=$CFLAGS -DCPU=\\\$HOST_CPU\\\ -DSO_EXT=\\\sl\\\ ;; - mipsel) + mipsel | mipsn32el | mips64el) CFLAGS=$CFLAGS -DCPU=\\\mipsel\\\ supported_os=mipsel HOST_CPU=mipsel I NMUed this package with the attached patch to 5-delay. commons-daemon.debdiff Description: Binary data
Bug#766590: ekiga: ftbfs on mips64 and mips64el
Package: ekiga Version: 4.0.1-4 Control: user debian-m...@lists.debian.org Control: usertags -1 + mips-port Control: usertags -1 + mips-patch mips64 use os type mips64-linux-gnuabi64 mips64el - mips64el-linux-gnuabi64 mipsn32 - mips64-linux-gnuabin32 mipsn32el - mips64el-linux-gnuabin32 So please add linux-gnuabi* to this list. Index: ekiga-4.0.1/configure.ac === --- ekiga-4.0.1.orig/configure.ac 2034-12-18 13:43:19.0 +0800 +++ ekiga-4.0.1/configure.ac 2034-12-18 14:15:24.705290366 +0800 @@ -90,7 +90,7 @@ gm_platform=solaris ;; - linux-gnulp | linux-gnu | linux-gnuspe | linux-gnueabi* | linux | Linux) + linux-gnulp | linux-gnu | linux-gnuspe | linux-gnuabi* | linux-gnueabi* | linux | Linux) gm_platform=linux ;; -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724145: libaosd: FTBFS: make[1]: *** No rule to make target `buildsys.mk'. Stop.
On Sun, 17 Nov 2013 16:44:54 +0100 Michael Ablassmeier a...@grinser.de wrote: tags 724145 + patch thanks hi, see attached patch which should fix this FTBFS. If OK for you i would NMU if not and you have any other plans with this package for the next upload and are in need of a sponsor just get in touch with me :-) It's time for NUM it, I think. Can you do it? bye, - michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763681: not a regression
On Mon, 20 Oct 2014 07:31:34 -0500
=?iso-8859-1?Q?Juli=E1n_Moreno_Pati=F1o?= jul...@debian.org wrote:
Control: severity -1 serious
Hello,
I don't think so, openrc built fine in those arches.
https://buildd.debian.org/status/logs.php?pkg=openrcarch=armel
https://buildd.debian.org/status/logs.php?pkg=openrcarch=armhf
In the revision 0.12.4+20131230-8 built ok, something in the next revision
0.12.4+20131230-9 broke the build.
Checking the git repository, there are a lot of changes.
git diff debian/0.12.4+20131230-8 debian/0.12.4+20131230-9
Also, checking the build logs, I saw the something similar in the failing
arches:
armel:
* Missing hidden defs:$\nrc_deptree_remove_loopdependency.8686
[ !! ]
armhf:
* Missing hidden defs:$\nrc_deptree_remove_loopdependency.8703
[ !! ]
ppc64el:
* Missing hidden defs:$\nrc_deptree_remove_loopdependency.6877
rc_deptree_unapm_getdependencies
[ !! ]
I met the same situation on mips64el, 0.12.4+20131230-9 built
successfully, while
0.13.1-2 failed.
Kind regards,
--
Juli�n Moreno Pati�o
Debian Developer
�.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' �http://debian.org/
��`- � GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724145: libaosd: FTBFS: make[1]: *** No rule to make target `buildsys.mk'. Stop.
On Sun, 17 Nov 2013 16:44:54 +0100 Michael Ablassmeier a...@grinser.de wrote: tags 724145 + patch thanks hi, see attached patch which should fix this FTBFS. If OK for you i would NMU if not and you have any other plans with this package for the next upload and are in need of a sponsor just get in touch with me :-) I will NMU it with this patch. bye, - michael libaosd.debdiff Description: Binary data
Bug#765675: libtrio: FTBFS on arm64
On Fri, 17 Oct 2014 10:44:51 +0100 Edmund Grimley Evans edmund.grimley.ev...@gmail.com wrote: Source: libtrio Version: 1.16+dfsg1-2 It failed to build on arm64: https://buildd.debian.org/status/package.php?p=libtriosuite=sid The error was: Verification failed in regression.c:620. Expected 03.142e+03 Got 03.141e+03 I met the same problem on mips64el. The test is expecting 3141.5 to be rounded up to 3142 rather than down to 3141, but I don't think you can expect consistent results from a test like that with the way libtrio is implemented using the machine's floating-point arithmetic. (It's using long double, which is 128 bits on arm64 but 80 on amd64, for example.) You should probably delete or modify that test, and any other test that expects an exact half to be rounded in a particular direction. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766134: coinutils: lapack and blas support is not really enabled
Package: src:coinutils
Version: 2.9.15-1
Severity: serious
Tag: patched
liblapack and libblas are in the building depends list while in build log,
there are lines:
checking whether -lblas has BLAS... no
checking for COIN-OR package Blas... skipped check via pkg-config,
redirect to fallback
checking for COIN-OR package Blas (fallback)... no, dependency
coinblas not available
checking whether -llapack has LAPACK... no
checking for COIN-OR package Lapack... skipped check via pkg-config,
redirect to fallback
checking for COIN-OR package Lapack (fallback)... no, dependency
coinlapack not available
If add gfortran to build-deps, it works well like this[1]
checking whether -lblas has BLAS... yes: -lblas
checking whether LAPACK is already available with BLAS library... no
checking whether -llapack has LAPACK... yes: -llapack
When blas and lapack enabled, coinor-libcoinutils-dev should depends on
liblapack-dev and libblas-dev. if not so, coinor-osi will ftbfs, as
the pkgconfig file
contains such informations.
[1].
http://mips64el.debian.net/debian/buildlog/c/coinutils_2.9.15-1/coinutils_2.9.15-1_mips64el-20140905-1939.build
diff -Nru coinutils-2.9.15/debian/control coinutils-2.9.15/debian/control
--- coinutils-2.9.15/debian/control 2014-09-04 19:47:26.0 +0800
+++ coinutils-2.9.15/debian/control 2034-12-15 13:37:17.0 +0800
@@ -4,7 +4,7 @@
Maintainer: Debian Science Team
debian-science-maintain...@lists.alioth.debian.org
Uploaders: Miles Lubin miles.lu...@gmail.com
Build-Depends: debhelper (= 9), doxygen, graphviz, liblapack-dev,
- libbz2-dev, zlib1g-dev, autotools-dev
+ libbz2-dev, zlib1g-dev, autotools-dev, gfortran
Standards-Version: 3.9.5
Vcs-Git: git://anonscm.debian.org/debian-science/packages/coinutils.git
Vcs-Browser:
http://anonscm.debian.org/gitweb/?p=debian-science/packages/coinutils.git
@@ -31,7 +31,7 @@
Package: coinor-libcoinutils-dev
Section: libdevel
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, coinor-libcoinutils3 (=
${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, coinor-libcoinutils3 (=
${binary:Version}), liblapack-dev, libblas-dev
Provides: libcoinutils-dev
Conflicts: libcoinutils-dev
Replaces: libcoinutils-dev
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757082: rt-app: use __u64 in both src/rt-app_utils.h and src/rt-app_utils.c
On Tue, 5 Aug 2014 15:18:26 +0800 YunQiang Su wzss...@gmail.com wrote: Package: rt-app Version: 0.2~alpha2.20140716 For the return type of function: timespec_to_nsec, in src/rt-app_utils.h, it is 'unsigned long long', while in src/rt-app_utils.c it is '__u64'. I think __u64 is a better option. This causes it ftbfs on mips64el. I NMUed this package to 5-delay with the attached patch. -- YunQiang Su rt-app.debdiff Description: Binary data
Bug#754266: celestia ftbfs on mips64el
On Wed, 9 Jul 2014 17:40:42 +0800 Yunqiang Su s...@debian.org wrote:
Package: celestia
Version: 1.6.1+dfsg-3
in image.{cpp,h}, it uses 'mips' as variable name,
while on mips64el, it is a macro.
I NMUed this package to 5-delay with the attached patch.
celestia.debdiff
Description: Binary data
Bug#754361: open-invaders: add mips64 and mips64el into 64bit list in fix_pmask_amd64.patch
On Thu, 10 Jul 2014 18:40:12 +0800 YunQiang Su s...@debian.org wrote: Package: open-invaders Version: 0.3-4 diff -Nru open-invaders-0.3/debian/patches/fix_pmask_amd64.patch open-invaders-0.3/debian/patches/fix_pmask_amd64.patch --- open-invaders-0.3/debian/patches/fix_pmask_amd64.patch 2011-09-04 04:04:47.0 +0800 +++ open-invaders-0.3/debian/patches/fix_pmask_amd64.patch 2014-07-10 16:03:13.0 +0800 @@ -7,7 +7,7 @@ //don't worry about setting it incorrectly //you'll get a compile error if you do, not a run-time error -#define MASK_WORD_BITBITS 5 -+#if defined(__alpha__) || defined(__ia64__) || defined(__x86_64__) || defined(__s390x__) || (defined(__sparc__) defined(__arch64__)) ++#if defined(__alpha__) || defined(__ia64__) || defined(__x86_64__) || defined(__s390x__) || defined(__mips64) || (defined(__sparc__) defined(__arch64__)) + #define MASK_WORD_BITBITS 6 +#else + #define MASK_WORD_BITBITS 5 I NMUed this packages to 5-delay with the attached patch, which fixes arm64, ppc64el, x32 and mips64el. open-invaders.debdiff Description: Binary data
Bug#719058: libgc symbols error on mips64(el)
I NMUed libgc with this patch to 5-delay. On Sun, May 4, 2014 at 11:04 PM, Yunqiang Su wzss...@gmail.com wrote: On Mon, Aug 12, 2013 at 5:48 AM, Sune Vuorela s...@debian.org wrote: On Sunday 11 August 2013 21:47:59 Christoph Egger wrote: Hi! YunQiang Su wzss...@gmail.com writes: Mips64(el) 's symbols is a little different, or it will ftbfs. Hmm strange. Maybe the symbols helper doesn't know mips64(el) yet? I would be quite surprised if pkgkde-symbolshelper knew about mips64(el) (and n32 for that sake) without any patches. I have patched pkgkde, it works well now. For libgc, we have still something to do for symbols. There are some symbols are marked !mips !mipsel, we should add !mips64 !mips64el to them. The buildlog is attached. Patches are most welcome. /Sune -- How can I uninstall the mousepad? From the panel within Photoshop 8.4 you either need to get access over a RW cache, or have not to boot with the tool to a Fast PCI kernel to the shell over the analogic BIOS password on a folder of a directory for uploading the DVD window. -- Yunqiang Su -- YunQiang Su libgc.debdiff Description: Binary data
Bug#763007: fftw3: add mips64 and mips64el into long double support list
On Sat, 27 Sep 2014 10:02:09 +0800 YunQiang Su wzss...@gmail.com wrote: Package: fftw3 Version: 3.3.4-1 On mips64 and mips64el, double is 64bit and long double is 128bit. So please enable them for long double support. I NMUed this package with delay-5, with arm64 and ppc64el to the long double support list. -- YunQiang Su fftw3.debdiff Description: Binary data
Bug#727179: Please update symbol table to support mips64(el) and mipsn32(el)
On Wed, 23 Oct 2013 12:25:18 +0800 YunQiang Su wzss...@gmail.com wrote: Package: ghostscript Version: 9.05~dfsg-8 The attached patch can make be builtable on mips64el platform. I will NUM this package with the attached patch to 5-delay. It seems there is a new symbol: PDFDocEncodingLookup@Base Should it be added? -- YunQiang Su ghostscript.debdiff Description: Binary data
Bug#727179: Please update symbol table to support mips64(el) and mipsn32(el)
On Tue, Oct 14, 2014 at 5:50 PM, Jonas Smedegaard d...@jones.dk wrote: Hi YunQiang Su, (just curious - which part is personal name and which your family name?) Quoting YunQiang Su (2014-10-14 11:17:50) On Wed, 23 Oct 2013 12:25:18 +0800 YunQiang Su wzss...@gmail.com wrote: The attached patch can make be builtable on mips64el platform. I will NUM this package with the attached patch to 5-delay. Please feel free to upload with no delay. Or, if interested, join the maintainance team :-D It seems there is a new symbol: PDFDocEncodingLookup@Base Should it be added? Yes, please - but check (e.g. in build logs of other archs) whether it should go into the common or e.g. endian-specific Symbols snippet. It has been added in a previous version to common. Thanks! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758654: nqp and mipsel
On Thu, Oct 9, 2014 at 2:34 PM, Dominique Dumont d...@debian.org wrote: On Thursday 09 October 2014 11:33:10 YunQiang Su wrote: I tested it. Nqp can build without any patch now. So what to do is just add mips mipsel mips64 mips64el to arch-list in debian/control. nqp 2014.07-2 failed to build on mips: https://buildd.debian.org/status/fetch.php?pkg=nqparch=mipsver=2014.07-2stamp=1409928787 I tested it on mips64el with 2014.07-3. I will test it on mipsel. Which version did you test ? -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761805: gammaray fix mips64el support
On Tue, 16 Sep 2014 14:54:30 +0800 YunQiang Su wzss...@gmail.com wrote: Package: gammaray Version: 2.1.0-3 In debian/patches/debian-archs-fix-build.patch, there is a line: elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL mips64 AND CMAKE_SIZEOF_VOID_P EQUAL 4) It works for mipsel/mips ports and mipsn32(el) ports, while not for mips64(el), as the e_machine is the same for o32, n32, and n64. So for all mips ports, use the same may be an option, aka elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL mips64) I nmued this package to delay 5 with the attached patch. -- YunQiang Su gammaray.debdiff Description: Binary data
Bug#748911: src:opal: FTBFS on 64 bits arch
NUMed with this patch. On Thu, Oct 9, 2014 at 8:31 PM, Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com wrote: Hi YunQiang, On 09/27/2014 01:12 AM, YunQiang Su wrote: Can any ppc64el and arm64 guys help to test this patch? On 10/07/2014 11:58 PM, YunQiang Su wrote: I will NMU ptlib with the attached debdiff. If you don't agree with it, please cancel it or ask me to do it. Sorry for missing this one for a few days. For ppc64el, there's a small change required, because the machine name is powerpc64le (suffix 'le' vs. 'el'): $ sed 's,ppc64el | powerpc64el,powerpc64le,' -i ptlib.debdiff With that change, the ptlib package built successfully, and configure messages changed: from: configure: WARNING: CPU powerpc64le not recognized - proceed with caution! configure: OSTYPE set to linux configure: OSRELEASE set to 3.16-trunk-powerpc64le configure: MACHTYPE set to powerpc64le to: configure: OSTYPE set to linux configure: OSRELEASE set to 3.16-trunk-powerpc64le configure: MACHTYPE set to ppc64 Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- YunQiang Su ptlib.debdiff Description: Binary data
Bug#761935: shine: ftbfs on mips64el
I nmued this package to delay-5 with the attached patch. On Fri, Oct 10, 2014 at 9:50 AM, Aníbal Monsalve Salazar ani...@debian.org wrote: Control: severity -1 important On Wed, 2014-09-17 10:44:47 +0800, YunQiang Su wrote: Package: shine Version: 3.1.0-2 In debian/rules, there are lines: ifneq (,$(findstrings mips,$(DEB_HOST_ARCH))) CFLAGS+= -mips32r2 export CFLAGS endif It will make all mips* ports use mips32r2. change it to ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH))) can fix this problem. -- YunQiang Su Hello Romain, YunQiang forgot to set the severity of this bug report. Port bugs are at least important. ;-) Cheers, Aníbal shine.debdiff Description: Binary data
Bug#752059: ctfutils: add mips64 support
On Thu, 19 Jun 2014 15:37:19 +0800 Sphinx Jiang yishan...@gmail.com wrote: Index: ctfutils-9.2/sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h === --- ctfutils-9.2.orig/sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h 2011-02-28 03:41:40.0 +0800 +++ ctfutils-9.2/sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h 2014-06-19 15:22:27.320825153 +0800 @@ -403,7 +403,7 @@ #define_INT_ALIGNMENT 4 #define_FLOAT_ALIGNMENT4 #define_FLOAT_COMPLEX_ALIGNMENT4 -#if defined(__mips_n64) +#if defined(__mips64) Ohh, on N32 project __mips64 is also defined, it means that 64bit registers are available. So for N64, we should use #if defined(__mips64) defined(__LP64__) #define_LONG_ALIGNMENT 8 #define_LONG_LONG_ALIGNMENT8 #define_DOUBLE_ALIGNMENT 8 I NMUed it with the attached patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748325: cln: fix mips64(el) build
Any idea about this patch? On Tue, Sep 30, 2014 at 4:07 AM, Richard B. Kreckel krec...@ginac.de wrote: On 09/25/2014 08:40 AM, YunQiang Su wrote: I tested this patch. It fixes more. __mips64 defines for both N32 and N64, so we should use __LP64__ to determine. Both big- and little- endian define __mips__,so __mips__ || __mipsel__ is not needed. Wait a minute. If I am not mistaken, __mips64__ should be defined by the configure script in include/cln/host_cpu.h, generated from include/cln/host_cpu.h.in. What does include/cln/host_cpu.h look like on your machine? Moreover, in your patch for include/cln/types.h, the parenthesis appear to be wrong. -richard. -- Richard B. Kreckel http://in.terlu.de/~kreckel/ -- YunQiang Su Index: cln-1.3.3/m4/general.m4 === --- cln-1.3.3.orig/m4/general.m42034-12-02 20:27:27.723746593 +0800 +++ cln-1.3.3/m4/general.m4 2034-12-02 20:28:04.094843192 +0800 @@ -153,7 +153,7 @@ host_cpu=arm ;; changequote([,])dnl - mips ) + mips* ) AC_CACHE_CHECK([for 64-bit MIPS], cl_cv_host_mips64, [ AC_EGREP_CPP(yes, [#if defined(_MIPS_SZLONG) Index: cln-1.3.3/include/cln/object.h === --- cln-1.3.3.orig/include/cln/object.h 2034-12-02 20:27:27.708121592 +0800 +++ cln-1.3.3/include/cln/object.h 2034-12-02 20:31:01.571419597 +0800 @@ -22,7 +22,7 @@ #if defined(__m68k__) #define cl_word_alignment 2 #endif -#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) || (defined(__sparc__) !defined(__arch64__)) || defined(__hppa__) || defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || (defined(__s390__) !defined(__s390x__)) || defined(__sh__) || (defined(__x86_64__) defined(__ILP32__)) +#if defined(__i386__) || (defined(__mips__) !defined(__LP64__)) || (defined(__sparc__) !defined(__arch64__)) || defined(__hppa__) || defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || (defined(__s390__) !defined(__s390x__)) || defined(__sh__) || (defined(__x86_64__) defined(__ILP32__)) #define cl_word_alignment 4 #endif #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || (defined(__sparc__) defined(__arch64__)) || (defined(__x86_64__) !defined(__ILP32__)) || defined(__s390x__) || defined(__aarch64__) Index: cln-1.3.3/include/cln/types.h === --- cln-1.3.3.orig/include/cln/types.h 2034-12-02 20:27:27.715934093 +0800 +++ cln-1.3.3/include/cln/types.h 2034-12-02 20:34:42.946436939 +0800 @@ -76,7 +76,7 @@ // Integer type used for counters. // Constraint: sizeof(uintC) = sizeof(uintL) - #if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__))) + #if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__))) #define intCsize long_bitsize typedef long sintC; typedef unsigned long uintC; @@ -127,7 +127,7 @@ typedef int sintD; typedef unsigned int uintD; #else // we are not using GMP, so just guess something reasonable -#if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__))) +#if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__))) #define intDsize 64 typedef sint64 sintD; typedef uint64 uintD;
Bug#758654: nqp and mipsel
On Mon, Aug 25, 2014 at 2:04 AM, Dominique Dumont d...@debian.org wrote: Hello The build script of nqp-2014.07 has changed so your patch does not apply anymore. I tested it. Nqp can build without any patch now. So what to do is just add mips mipsel mips64 mips64el to arch-list in debian/control. Thank you very much. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748911: src:opal: FTBFS on 64 bits arch
I will NMU ptlib with the attached debdiff. If you don't agree with it, please cancel it or ask me to do it. On Sat, Sep 27, 2014 at 12:12 PM, YunQiang Su wzss...@gmail.com wrote: Control: reassign -1 src:ptlib On Thu, 22 May 2014 10:45:51 +0200 Erwan Prioul er...@linux.vnet.ibm.com wrote: Package: src:opal Version: 3.10.10~dfsg-2.2 Severity: normal Tags: patch Dear Maintainer, The attached patch has been applied on Ubuntu to fix a FTBFS on 64 bits arch. I think a better fix is for ptlib, as in its pkgconfig file there is no P_64BIT defined as other 64bit platform in arm64, ppc64el, mips64, mips64el I reassigned this bug to src:ptlib. I think the attached patch can fix this problem, while it is only tested on mips64el. Can any ppc64el and arm64 guys help to test this patch? Thanks for considering the patch. Erwan Prioul. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- YunQiang Su ptlib.debdiff Description: Binary data
Bug#735572: re: player: FTBFS: error: too few arguments to function 'sg_error sg_init(int)'
On Sat, Sep 27, 2014 at 11:26 AM, peter green plugw...@p10link.net wrote: Your NMU diff contains the changelog entry +player (3.0.2+dfsg-4.2) unstable; urgency=medium + + * Fix for API changes of libstatgrab version 0.90 (Closes: #735572) +- Update build dependency accordingly to libstatgrab-dev (= 0.90) + + [YunQiang Su] + * ruby-playerc.install: Use multiarch path. + + -- Peter Michael Green plugw...@raspbian.org Wed, 19 Mar 2014 01:30:56 + If you are the one who determined that a set of changes was ready for upload your name/email needs to be in the changelog trailer (with attribution of individual changes to their authors in the changelog body as appropriate). The date/time in the changelog trailer should also reflect at least approximately the time the upload was prepared. Please remove your upload from the delayed queue, fix the changelog and reupload. Furthermore please be careful to avoid doing this again in future. Putting someone elses name in the changelog trailer for an upload you prepare is essentially impersonating them. Canceled -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758097: portabase: fix mips64el build
On Thu, 14 Aug 2014 17:06:29 +0800 YunQiang Su wzss...@gmail.com wrote: Package: portabase Version: 2.1+git20120910-1 Portabase ftbfs on mips64el, and with this tiny patch it can build now. Index: portabase-2.1+git20120910/metakit/include/mk4.h === --- portabase-2.1+git20120910.orig/metakit/include/mk4.h 2012-09-17 08:56:23.0 + +++ portabase-2.1+git20120910/metakit/include/mk4.h 2014-08-14 08:25:45.727508267 + @@ -102,7 +102,8 @@ #if !defined (_WIN32) !defined (q4_LONG64) #if defined (_PA_RISC2_0) || defined (__powerpc64__) || defined(__sparcv9) || \ defined(__x86_64__) || defined(__s390x__) || defined(__alpha) || \ - (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) + (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) || \ + defined(__mips64) #define q4_LONG64 1 #endif #endif I NMUed this package with the attached patch. It should fix FTBFS for mips64(el), arm64, sparc64 and x32. -- YunQiang Su diff -Nru portabase-2.1+git20120910/debian/changelog portabase-2.1+git20120910/debian/changelog --- portabase-2.1+git20120910/debian/changelog 2012-09-18 12:44:42.0 +0800 +++ portabase-2.1+git20120910/debian/changelog 2014-09-26 17:34:02.0 +0800 @@ -1,3 +1,10 @@ +portabase (2.1+git20120910-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS on mips64(el), x32, arm64, sparc64. + + -- YunQiang Su s...@debian.org Fri, 26 Sep 2014 17:32:10 +0800 + portabase (2.1+git20120910-1) unstable; urgency=low * New upstream version [September 2012]. diff -Nru portabase-2.1+git20120910/debian/patches/64bit.patch portabase-2.1+git20120910/debian/patches/64bit.patch --- portabase-2.1+git20120910/debian/patches/64bit.patch1970-01-01 08:00:00.0 +0800 +++ portabase-2.1+git20120910/debian/patches/64bit.patch2014-09-26 17:31:21.0 +0800 @@ -0,0 +1,17 @@ +Index: portabase-2.1+git20120910/metakit/include/mk4.h +=== +--- portabase-2.1+git20120910.orig/metakit/include/mk4.h 2012-09-17 16:56:23.0 +0800 portabase-2.1+git20120910/metakit/include/mk4.h2014-09-26 17:31:16.503415273 +0800 +@@ -101,8 +101,10 @@ + // and here's the other end of the scale... + #if !defined (_WIN32) !defined (q4_LONG64) + #if defined (_PA_RISC2_0) || defined (__powerpc64__) || defined(__sparcv9) || \ +-defined(__x86_64__) || defined(__s390x__) || defined(__alpha) || \ +- (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) ++ (defined(__x86_64__) defined(__LP64__)) || defined(__s390x__) || defined(__alpha) || \ ++ (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) || \ ++ (defined(__mips64) defined(__LP64__)) || defined(__aarch64__) || \ ++ (defined(__sparc__) defined(__LP64__)) + #define q4_LONG64 1 + #endif + #endif diff -Nru portabase-2.1+git20120910/debian/patches/series portabase-2.1+git20120910/debian/patches/series --- portabase-2.1+git20120910/debian/patches/series 2012-09-17 22:14:29.0 +0800 +++ portabase-2.1+git20120910/debian/patches/series 2014-09-26 17:17:17.0 +0800 @@ -1 +1,2 @@ build.patch +64bit.patch
Bug#735572: re: player: FTBFS: error: too few arguments to function 'sg_error sg_init(int)'
On Wed, 19 Mar 2014 02:11:15 + peter green plugw...@p10link.net wrote: Based on the patches for razorqt and various examples found by googling I made player build. I have not tested it beyond that and I didn't find any proper documention for the new parameters so i'm not positive it is correct. Debdiff atached and uploaded to raspbian. No intent to NMU in debian. I nmued this package to 5-days delay queue with the attached patch. diff -Nru player-3.0.2+dfsg/debian/changelog player-3.0.2+dfsg/debian/changelog --- player-3.0.2+dfsg/debian/changelog 2013-09-06 14:14:40.0 +0800 +++ player-3.0.2+dfsg/debian/changelog 2014-09-26 22:04:54.0 +0800 @@ -1,3 +1,13 @@ +player (3.0.2+dfsg-4.2) unstable; urgency=medium + + * Fix for API changes of libstatgrab version 0.90 (Closes: #735572) +- Update build dependency accordingly to libstatgrab-dev (= 0.90) + + [YunQiang Su] + * ruby-playerc.install: Use multiarch path. + + -- Peter Michael Green plugw...@raspbian.org Wed, 19 Mar 2014 01:30:56 + + player (3.0.2+dfsg-4.1) unstable; urgency=low * Non-maintainer upload. diff -Nru player-3.0.2+dfsg/debian/control player-3.0.2+dfsg/debian/control --- player-3.0.2+dfsg/debian/control2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/control2014-09-26 18:30:08.0 +0800 @@ -2,7 +2,7 @@ Section: science Priority: extra Maintainer: Michael Janssen jamu...@debian.org -Build-Depends: debhelper (= 7.0.50~), autotools-dev, libgsl0-dev, libcv-dev, libhighgui-dev, libcvaux-dev, libgtk2.0-dev, libdc1394-22-dev, libboost-signals-dev, libboost-thread-dev, swig, libjpeg-dev, python-support, doxygen, linux-libc-dev | linux-kernel-headers, libgnomecanvas2-dev, python-dev, freeglut3-dev, graphviz, ruby, ruby-dev, libtheora-dev, libgeos-dev, libpqxx3-dev, libxmu-dev, libcvaux-dev, libasound2-dev, libstatgrab-dev, cmake, libusb-dev, libv4l-dev +Build-Depends: debhelper (= 7.0.50~), autotools-dev, libgsl0-dev, libcv-dev, libhighgui-dev, libcvaux-dev, libgtk2.0-dev, libdc1394-22-dev, libboost-signals-dev, libboost-thread-dev, swig, libjpeg-dev, python-support, doxygen, linux-libc-dev | linux-kernel-headers, libgnomecanvas2-dev, python-dev, freeglut3-dev, graphviz, ruby, ruby-dev, libtheora-dev, libgeos-dev, libpqxx3-dev, libxmu-dev, libcvaux-dev, libasound2-dev, libstatgrab-dev (= 0.90), cmake, libusb-dev, libv4l-dev XS-Python-Version: all Standards-Version: 3.9.3 Homepage: http://playerstage.sourceforge.net/ diff -Nru player-3.0.2+dfsg/debian/liblodo3.0-dev.install player-3.0.2+dfsg/debian/liblodo3.0-dev.install --- player-3.0.2+dfsg/debian/liblodo3.0-dev.install 2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/liblodo3.0-dev.install 2014-09-26 20:31:39.0 +0800 @@ -1,2 +1,2 @@ -usr/lib/liblodo.so +usr/lib//liblodo.so usr/include/player-3.0/libpmap/lodo.h diff -Nru player-3.0.2+dfsg/debian/liblodo3.0.install player-3.0.2+dfsg/debian/liblodo3.0.install --- player-3.0.2+dfsg/debian/liblodo3.0.install 2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/liblodo3.0.install 2014-09-26 20:31:39.0 +0800 @@ -1 +1 @@ -usr/lib/liblodo.so.* +usr/lib//liblodo.so.* diff -Nru player-3.0.2+dfsg/debian/libplayerc++3.0-dev.install player-3.0.2+dfsg/debian/libplayerc++3.0-dev.install --- player-3.0.2+dfsg/debian/libplayerc++3.0-dev.install2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/libplayerc++3.0-dev.install2014-09-26 20:31:39.0 +0800 @@ -1,4 +1,4 @@ -usr/lib/libplayerc++.so +usr/lib//libplayerc++.so usr/include/player-3.0/libplayerc++ -usr/lib/pkgconfig/playerc++.pc +usr/lib//pkgconfig/playerc++.pc usr/share/cmake/Modules/UsePlayerC++.cmake usr/lib/player-3.0 diff -Nru player-3.0.2+dfsg/debian/libplayerc3.0-dev.install player-3.0.2+dfsg/debian/libplayerc3.0-dev.install --- player-3.0.2+dfsg/debian/libplayerc3.0-dev.install 2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/libplayerc3.0-dev.install 2014-09-26 20:31:39.0 +0800 @@ -1,4 +1,4 @@ -usr/lib/libplayerc.so +usr/lib//libplayerc.so usr/include/player-3.0/libplayerc -usr/lib/pkgconfig/playerc.pc +usr/lib//pkgconfig/playerc.pc usr/share/cmake/Modules/UsePlayerC.cmake usr/lib/player-3.0 diff -Nru player-3.0.2+dfsg/debian/libplayerc++3.0.install player-3.0.2+dfsg/debian/libplayerc++3.0.install --- player-3.0.2+dfsg/debian/libplayerc++3.0.install2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/libplayerc++3.0.install2014-09-26 20:31:39.0 +0800 @@ -1 +1 @@ -usr/lib/libplayerc++.so.* +usr/lib//libplayerc++.so.* diff -Nru player-3.0.2+dfsg/debian/libplayerc3.0.install player-3.0.2+dfsg/debian/libplayerc3.0.install --- player-3.0.2+dfsg/debian/libplayerc3.0.install 2012-03-26 07:17:30.0 +0800 +++ player-3.0.2+dfsg/debian/libplayerc3.0.install 2014-09-26 20:31:39.0 +0800 @@ -1 +1 @@ -usr/lib/libplayerc.so.* +usr/lib
Bug#758491: percona-xtrabackup: wrong mips64 asm in taocrypt
On Mon, 18 Aug 2014 10:35:29 +0800 YunQiang Su wzss...@gmail.com wrote: Package: percona-xtrabackup Version: 2.2.3-2 In extra/yassl/taocrypt/src/integer.cpp there is a problem in mips64 asm. Please fix it. This patch has been applied to MySQL, it works well. Index: percona-xtrabackup-2.2.3/extra/yassl/taocrypt/src/integer.cpp === --- percona-xtrabackup-2.2.3.orig/extra/yassl/taocrypt/src/integer.cpp 2014-07-23 01:13:52.0 +0800 +++ percona-xtrabackup-2.2.3/extra/yassl/taocrypt/src/integer.cpp 2033-12-08 16:07:06.314007266 +0800 @@ -189,7 +189,7 @@ a (a), rm (b) : cc); #elif defined(__mips64) -__asm__(dmultu %2,%3 : =h (r.halfs_.high), =l (r.halfs_.low) +__asm__(dmultu %2,%3 : =d (r.halfs_.high), =lc (r.halfs_.low) : r (a), r (b)); #elif defined(_M_IX86) I will NMU this package this the attached patch. -- YunQiang Su percona-xtrabackup.debdiff Description: Binary data
Bug#746998: pyfftw: FTBFS on architectures without long double
On Thu, 22 May 2014 08:00:51 +0100 Ghislain Vaillant ghisv...@gmail.com wrote: Hi Aurelien, Thanks for reporting this issue. I'd have to check with upstream the best approach for dealing with this. I am not sure whether you can enable / disable support for specific precisions in pyfftw. I think the author assumed that all these precisions were available. I could restrict the package build to selected architectures that provide all precisions for now, whilst upstream finds a solution to this. How does that sound ? In this case, I'd need to know which architectures are currently failing besides mips64. This bug is about mipsel/mips aka 32bit mips, not about mips64(el). You are confused due to he uses a 64bit kernel with 32bit userland. I noticed that in fftw3, long double support is enabled on i386, while the long double on i386 is 12Byte, quite strange, as other ones are all 16Byte. Please let me know what you think, Cheers, Ghislain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763007: fftw3: add mips64 and mips64el into long double support list
Package: fftw3 Version: 3.3.4-1 On mips64 and mips64el, double is 64bit and long double is 128bit. So please enable them for long double support. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758097: portabase: fix mips64el build
On Sat, Sep 27, 2014 at 10:33 AM, Dmitry Smirnov only...@debian.org wrote: On Fri, 26 Sep 2014 18:22:38 YunQiang Su wrote: I NMUed this package with the attached patch. Thanks for your help and apologies for delay. Just one suggestion: next time when doing NMU please allow maintainer to take action -- that's what DELAYED queue is for. Sorry for it. It is due to mistake operation. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748911: src:opal: FTBFS on 64 bits arch
Control: reassign -1 src:ptlib
On Thu, 22 May 2014 10:45:51 +0200 Erwan Prioul
er...@linux.vnet.ibm.com wrote:
Package: src:opal
Version: 3.10.10~dfsg-2.2
Severity: normal
Tags: patch
Dear Maintainer,
The attached patch has been applied on Ubuntu to fix a FTBFS on 64 bits
arch.
I think a better fix is for ptlib, as in its pkgconfig file there is
no P_64BIT defined
as other 64bit platform in
arm64, ppc64el, mips64, mips64el
I reassigned this bug to src:ptlib.
I think the attached patch can fix this problem, while it is only
tested on mips64el.
Can any ppc64el and arm64 guys help to test this patch?
Thanks for considering the patch.
Erwan Prioul.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: ptlib-2.10.10~dfsg/configure.ac
===
--- ptlib-2.10.10~dfsg.orig/configure.ac2034-11-21 10:56:41.345832345
+0800
+++ ptlib-2.10.10~dfsg/configure.ac 2034-11-21 10:56:41.330207343 +0800
@@ -324,7 +324,7 @@
MACHTYPE=ppc
;;
- ppc64 | powerpc64 )
+ ppc64 | powerpc64 | ppc64el | powerpc64el )
MACHTYPE=ppc64
P_64BIT=1
LIB64=1
@@ -345,6 +345,17 @@
MACHTYPE=s390
;;
+ aarch64 )
+ MACHTYPE=arm64
+ P_64BIT=1
+LIB64=1
+ ;;
+ mips64 | mips64el )
+ MACHTYPE=mips64
+ P_64BIT=1
+LIB64=1
+ ;;
+
* )
MACHTYPE=$target_cpu
AC_MSG_WARN(CPU $target_cpu not recognized - proceed with caution!)
Index: ptlib-2.10.10~dfsg/configure
===
--- ptlib-2.10.10~dfsg.orig/configure 2013-02-20 10:12:27.0 +0800
+++ ptlib-2.10.10~dfsg/configure2034-11-21 10:57:54.220838053 +0800
@@ -4649,7 +4649,7 @@
MACHTYPE=ppc
;;
- ppc64 | powerpc64 )
+ ppc64 | powerpc64 | ppc64el | powerpc64el )
MACHTYPE=ppc64
P_64BIT=1
LIB64=1
@@ -4670,6 +4670,17 @@
MACHTYPE=s390
;;
+ aarch64 )
+ MACHTYPE=arm64
+ P_64BIT=1
+LIB64=1
+ ;;
+ mips64 | mips64el )
+ MACHTYPE=mips64
+ P_64BIT=1
+LIB64=1
+ ;;
+
* )
MACHTYPE=$target_cpu
{ $as_echo $as_me:${as_lineno-$LINENO}: WARNING: \CPU $target_cpu not
recognized - proceed with caution!\ 5
Bug#748325: cln: fix mips64(el) build
I tested this patch. It fixes more.
__mips64 defines for both N32 and N64, so we should use __LP64__ to determine.
Both big- and little- endian define __mips__,so
__mips__ || __mipsel__ is not needed.
On Thu, Sep 25, 2014 at 1:15 AM, Richard B. Kreckel krec...@ginac.de wrote:
On 09/24/2014 11:57 AM, YunQiang Su wrote:
On Thu, May 22, 2014 at 9:14 AM, Yunqiang Su wzss...@gmail.com wrote:
On Mon, May 19, 2014 at 2:00 PM, Richard B. Kreckel krec...@ginac.de
wrote:
On 05/16/2014 10:20 AM, Yunqiang Su wrote:
Package: cln
Version: 1.3.3-1
This patch fix cln build on mips64 and mips64el.
Thanks very much for your patch!
I've just one question: Why switch from __mips64__ to __mips64?
I remember (a long time back, admittedly), that I had to switch the
other way, from __mips64 to __mips64__ to make things work.
Ohhh, both of them work now.
Keep __mips64__ should be OK.
Sorry for it.
There do be no __mips64__, so we should change it to __mips64.
Can you, please, prepare a patch, test if it works, and send it to me? I
won't hesitate applying it.
-richard.
--
Richard B. Kreckel
http://in.terlu.de/~kreckel/
--
YunQiang Su
diff --git a/include/cln/object.h b/include/cln/object.h
index 50517b9..b54b93a 100644
--- a/include/cln/object.h
+++ b/include/cln/object.h
@@ -22,10 +22,10 @@ namespace cln {
#if defined(__m68k__)
#define cl_word_alignment 2
#endif
-#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) ||
(defined(__sparc__) !defined(__arch64__)) || defined(__hppa__) ||
defined(__arm__) || defined(__rs6000__) || defined(__m88k__) ||
defined(__convex__) || (defined(__s390__) !defined(__s390x__)) ||
defined(__sh__) || (defined(__x86_64__) defined(__ILP32__))
+#if defined(__i386__) || (defined(__mips__) !defined(__LP64__) ) ||
(defined(__sparc__) !defined(__arch64__)) || defined(__hppa__) ||
defined(__arm__) || defined(__rs6000__) || defined(__m88k__) ||
defined(__convex__) || (defined(__s390__) !defined(__s390x__)) ||
defined(__sh__) || (defined(__x86_64__) defined(__ILP32__))
#define cl_word_alignment 4
#endif
-#if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) ||
defined(__powerpc64__) || (defined(__sparc__) defined(__arch64__)) ||
(defined(__x86_64__) !defined(__ILP32__)) || defined(__s390x__) ||
defined(__aarch64__)
+#if defined(__alpha__) || defined(__ia64__) || (defined(__mips64)
defined(__LP64__))|| defined(__powerpc64__) || (defined(__sparc__)
defined(__arch64__)) || (defined(__x86_64__) !defined(__ILP32__)) ||
defined(__s390x__) || defined(__aarch64__)
#define cl_word_alignment 8
#endif
#if !defined(cl_word_alignment)
diff --git a/include/cln/types.h b/include/cln/types.h
index 30d040e..bc16496 100644
--- a/include/cln/types.h
+++ b/include/cln/types.h
@@ -48,7 +48,7 @@
#undef HAVE_LONGLONG
#endif
#endif
- #if defined(HAVE_LONGLONG) (defined(__alpha__) || defined(__ia64__) ||
defined(__mips64__) || defined(__powerpc64__) || defined(__s390x__) ||
(defined(__sparc__) defined(__arch64__)) || defined(__x86_64__)) ||
defined(__aarch64__)
+ #if defined(HAVE_LONGLONG) (defined(__alpha__) || defined(__ia64__) ||
defined(__mips64) || defined(__powerpc64__) || defined(__s390x__) ||
(defined(__sparc__) defined(__arch64__)) || defined(__x86_64__)) ||
defined(__aarch64__)
// 64 bit registers in hardware
#define HAVE_FAST_LONGLONG
#endif
@@ -76,7 +76,7 @@
// Integer type used for counters.
// Constraint: sizeof(uintC) = sizeof(uintL)
- #if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__)
|| defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__)
defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__)))
+ #if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) || defined(__ia64__)
|| defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__)
defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) ||
(defined(__mips64) defined(__LP64__
#define intCsize long_bitsize
typedef long sintC;
typedef unsigned long uintC;
@@ -127,7 +127,7 @@
typedef int sintD;
typedef unsigned int uintD;
#else // we are not using GMP, so just guess something reasonable
-#if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) ||
defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__)
defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) ||
defined(__aarch64__)))
+#if (defined(HAVE_FAST_LONGLONG) (defined(__alpha__) ||
defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__)
defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) ||
defined(__aarch64__) || (defined(__mips64) defined(__LP64__
#define intDsize 64
typedef sint64 sintD;
typedef uint64 uintD;
diff --git a/src/base/cl_low.h b/src/base/cl_low.h
index c4c25ab..acf84f5 100644
--- a/src/base/cl_low.h
+++ b/src/base/cl_low.h
@@ -826,14 +826,14
Bug#762669: clippoly: ./clippolytest t1 Assertion `inp_ort(q,s1) = 0' failed on mips64el
Package: src:clippoly Version: 0.11-6 When building clippoly on mips64el, it failed to build due to failure of test 1 and 2. lt-clippolytest: graphadd.cc:149: void recursive_intersection(const hvec2_t, const hvec2_t, const hvec2_t, const hvec2_t, hvec2_t): Assertion `inp_ort(q,s1) = 0' failed. [1]6062 IOT instruction ./clippolytest t1 -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748325: cln: fix mips64(el) build
On Thu, May 22, 2014 at 9:14 AM, Yunqiang Su wzss...@gmail.com wrote: On Mon, May 19, 2014 at 2:00 PM, Richard B. Kreckel krec...@ginac.de wrote: On 05/16/2014 10:20 AM, Yunqiang Su wrote: Package: cln Version: 1.3.3-1 This patch fix cln build on mips64 and mips64el. Thanks very much for your patch! I've just one question: Why switch from __mips64__ to __mips64? I remember (a long time back, admittedly), that I had to switch the other way, from __mips64 to __mips64__ to make things work. Ohhh, both of them work now. Keep __mips64__ should be OK. Sorry for it. There do be no __mips64__, so we should change it to __mips64. -richy. -- .''`. Richard B. Kreckel : :' : krec...@debian.org `. `' krec...@ginac.de `-http://www.ginac.de/~kreckel/ -- Yunqiang Su -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748325: cln: fix mips64(el) build
On Wed, Sep 24, 2014 at 5:57 PM, YunQiang Su wzss...@gmail.com wrote: On Thu, May 22, 2014 at 9:14 AM, Yunqiang Su wzss...@gmail.com wrote: On Mon, May 19, 2014 at 2:00 PM, Richard B. Kreckel krec...@ginac.de wrote: On 05/16/2014 10:20 AM, Yunqiang Su wrote: Package: cln Version: 1.3.3-1 This patch fix cln build on mips64 and mips64el. Thanks very much for your patch! I've just one question: Why switch from __mips64__ to __mips64? I remember (a long time back, admittedly), that I had to switch the other way, from __mips64 to __mips64__ to make things work. I have no idea about it. __mips64__ doesn't work for now. Ohhh, both of them work now. Keep __mips64__ should be OK. Sorry for it. There do be no __mips64__, so we should change it to __mips64. -richy. -- .''`. Richard B. Kreckel : :' : krec...@debian.org `. `' krec...@ginac.de `-http://www.ginac.de/~kreckel/ -- Yunqiang Su -- YunQiang Su -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761946: blacs-mpi: mark mips64 and mips64el as openmpi archs
Package: blacs-mpi Version: 1.1-31.4 Please mark mips64 and mips64el as openmpi archs in debian/rules. I test it on mips64el. it works. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760609: rsbackup: FTBFS: no binary artifacts found
On Tue, 9 Sep 2014 09:30:14 -0700 Matthew Vernon
matth...@chiark.greenend.org.uk wrote:
Hi,
Thanks for the report; I�ll get to this once I�m home from travelling (so not
for a week or so yet) unless someone gets an NMU in first.
The answer for post-jessie is perhaps to re-package to use debhelper for the
building, but I think a more minimal patch would be better for jessie.
It is quite easy.
In debian/rules:
binary: binary-arch binary-indep
binary-arch:
binary-indep: binary-${PACKAGE}
binary: binary-arch binary-indep
binary-arch: binary-${PACKAGE}
binary-indep:
can fix this problem.
Regards,
Matthew
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761978: mixxx: fix mips64el build
Package: mixxx Version: 1.11.0~dfsg-3 Please add 'mips64', 'mips64el', 'mipsn32', 'mipsn32el', to debian/patches/1001-buildsystem.patch I tested it on mips64el. It works well. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698796: mixxx: FTBFS: Exception: invalid machine type
On Wed, 23 Jan 2013 20:06:41 +0100 Thorsten Glaser t...@mirbsd.de wrote: Source: mixxx Version: 1.10.1~dfsg0-1 Severity: important Justification: fails to build from source (but built successfully in the past) can you try to add m68k to debian/patches/1001-buildsystem.patch Hi, your package fails to build for mysterious reasons. Please see the attached build log. -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 3.2.0-4-atari Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762001: marisa: FBTFS on mips64el
Package: marisa Version: 0.2.4-7 in lib/marisa/base.h, defined(__sparc64__) || defined(__mips64__) || defined(__aarch64__) || defined(__s390x__) the __mips64__ should be __mips64 instead of __mips64__ -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761805: gammaray fix mips64el support
Package: gammaray Version: 2.1.0-3 In debian/patches/debian-archs-fix-build.patch, there is a line: elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL mips64 AND CMAKE_SIZEOF_VOID_P EQUAL 4) It works for mipsel/mips ports and mipsn32(el) ports, while not for mips64(el), as the e_machine is the same for o32, n32, and n64. So for all mips ports, use the same may be an option, aka elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL mips64) -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761935: shine: ftbfs on mips64el
Package: shine Version: 3.1.0-2 In debian/rules, there are lines: ifneq (,$(findstrings mips,$(DEB_HOST_ARCH))) CFLAGS+= -mips32r2 export CFLAGS endif It will make all mips* ports use mips32r2. change it to ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH))) can fix this problem. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759216: [PKG-Openstack-devel] Bug#759216: Fwd: Re: Bug#759216: sheepdog: Init script missing corosync dependency
On Fri, Sep 12, 2014 at 3:20 PM, Thomas Goirand z...@debian.org wrote: Hi, I believe this message should have reached the BTS, so I'm forwarding it to the relevant bug. My take on this: it's ok to add a Should-Start: corosync in the sheepdog init script. It will work regardless if we're using corosync or not (in other words: it can't hurt...). As corosync service is disabled by default by itself's init scirpt (/etc/default/corosync). So, I don't think it is a good idea for us to Should-Start it. Anyway, if nothing bad happens, we can add Should-Start: corosync If I hear nothing form the current maintainer of Sheepdog, I'll do that. Thomas Goirand (zigo) Original Message Subject:Re: [PKG-Openstack-devel] Bug#759216: sheepdog: Init script missing corosync dependency Date: Mon, 25 Aug 2014 14:32:40 +0200 From: Valerio Pachera siri...@gmail.com Reply-To: Tracking bugs and development for OpenStack openstack-de...@lists.alioth.debian.org To: Tracking bugs and development for OpenStack openstack-de...@lists.alioth.debian.org Hi, I think this assumption is wrong. Sheepdog can use different cluster managers. Corosync has proven to be problematic in some situation and it doesn't support anyway more than 10 nodes. I strongly recommend to build sheepdog package so it supports also zookeeper. (If Im not worng, the package already use --enable-zookeper, but please check it). Zookeeper configuration is not more difficult than corosync, supports way more nodes, it doesn't need to be run on each node. Because we can't know what cluster manager the user is going to be using, I think it's better not to start nor require corosync as dependency. Valerio. ___ Openstack-devel mailing list openstack-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761275: Remove 5kc-malta loongson-2e/f and octeon from flavor list of mips64el
Package: src:linux Version: 3.16.2-2 After talking on Debconf14, we are planning switch mips64el back to mips64r2 ISA. So 5kc-malta, and loongson-2e/f don't support mips64r2 ISA, and octeon need patch for little endian. In this patch, we also fix a ftbfs problem, due to lacking of a newline at end of defines file. -- YunQiang Su diff --git a/debian/config/mips64/defines b/debian/config/mips64/defines index 6558f0d..5ff622c 100644 --- a/debian/config/mips64/defines +++ b/debian/config/mips64/defines @@ -30,3 +30,4 @@ hardware-long: Cavium Networks Octeon [octeon_image] configs: kernelarch-mips/config.octeon + diff --git a/debian/config/mips64el/defines b/debian/config/mips64el/defines index 41bc336..0911e9e 100644 --- a/debian/config/mips64el/defines +++ b/debian/config/mips64el/defines @@ -1,10 +1,7 @@ [base] flavours: sb1-bcm91250a - loongson-2e - loongson-2f loongson-3 - octeon kernel-arch: mips [build] @@ -20,28 +17,6 @@ hardware-long: Broadcom BCM91250A systems (aka SWARM) [sb1-bcm91250a_image] configs: kernelarch-mips/config.sb1-bcm91250a -[5kc-malta_description] -hardware: MIPS Malta -hardware-long: MIPS Malta boards - -[5kc-malta_image] -configs: kernelarch-mips/config.5kc-malta - -[loongson-2e_description] -hardware: Loongson 2E -hardware-long: Lemote Loongson 2E systems - -[loongson-2e_image] -configs: kernelarch-mips/config.loongson-2e - -[loongson-2f_description] -hardware: Loongson 2F -hardware-long: Lemote Loongson 2F systems - -[loongson-2f_image] -recommends: libc6-loongson2f -configs: kernelarch-mips/config.loongson-2f - [loongson-3_description] hardware: Loongson 3A/3B hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) @@ -49,9 +24,3 @@ hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) [loongson-3_image] configs: kernelarch-mips/config.loongson-3 -[octeon_description] -hardware: Octeon -hardware-long: Cavium Networks Octeon - -[octeon_image] -configs: kernelarch-mips/config.octeon diff --git a/debian/installer/mips64el/kernel-versions b/debian/installer/mips64el/kernel-versions index 0759981..d0e38a8 100644 --- a/debian/installer/mips64el/kernel-versions +++ b/debian/installer/mips64el/kernel-versions @@ -1,7 +1,3 @@ # arch version flavour installedname suffix build-depends mips64el - sb1-bcm91250a - y - -mips64el - 5kc-malta - y - -mips64el - loongson-2e - y - -mips64el - loongson-2f - y - mips64el - loongson-3- y - -mips64el - octeon- y - diff --git a/debian/installer/mips64el/modules/mips64el-5kc-malta b/debian/installer/mips64el/modules/mips64el-5kc-malta deleted file mode 12 index 84b512e..000 --- a/debian/installer/mips64el/modules/mips64el-5kc-malta +++ /dev/null @@ -1 +0,0 @@ -../../mips/modules/mips-4kc-malta \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-loongson-2e b/debian/installer/mips64el/modules/mips64el-loongson-2e deleted file mode 12 index b62930d..000 --- a/debian/installer/mips64el/modules/mips64el-loongson-2e +++ /dev/null @@ -1 +0,0 @@ -../../mipsel/modules/mipsel-loongson-2e \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-loongson-2f b/debian/installer/mips64el/modules/mips64el-loongson-2f deleted file mode 12 index 58388bb..000 --- a/debian/installer/mips64el/modules/mips64el-loongson-2f +++ /dev/null @@ -1 +0,0 @@ -../../mipsel/modules/mipsel-loongson-2f \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-octeon b/debian/installer/mips64el/modules/mips64el-octeon deleted file mode 12 index da584c6..000 --- a/debian/installer/mips64el/modules/mips64el-octeon +++ /dev/null @@ -1 +0,0 @@ -../../mips/modules/mips-octeon \ No newline at end of file
Bug#631427: Bug#671032: Processed: Re: Bug#631427: gcc-4.6: FTBFS with GCC_TARGET
On Fri, Sep 12, 2014 at 2:15 PM, Matthias Klose d...@debian.org wrote: Control: reassign -1 debhelper Control: tags -1 -patch dh_strip can do it now with setting DEB_HOST_GNU_TYPE The attached patch can fix this bug. No, it can't handle cases with HOST and TARGET code in packages, and you only do it for some library packages. Sorry for this misunderstanding. For gcc-4.9 for multiarch cross toolchains, maybe my patch is enough. Can you consider it? Please see that this issue was cloned for debhelper, and there is #631427 for GCC. Matthias -- To unsubscribe, send mail to 671032-unsubscr...@bugs.debian.org. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761275: Remove 5kc-malta loongson-2e/f and octeon from flavor list of mips64el
On Sat, Sep 13, 2014 at 12:14 AM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2014-09-12 at 18:26 +0800, YunQiang Su wrote: Package: src:linux Version: 3.16.2-2 After talking on Debconf14, we are planning switch mips64el back to mips64r2 ISA. So 5kc-malta, and loongson-2e/f don't support mips64r2 ISA, and octeon need patch for little endian. In this patch, we also fix a ftbfs problem, due to lacking of a newline at end of defines file. No, the 'missing newline' messages in the diff refer to the symlinks. This is normal as the text of a symlink should be a path with no added newline. On IRC, you pointed to the build log: http://mips64el.debian.net/debian/buildlog/l/linux_3.16.2-2/linux_3.16.2-2_mips64el-20140909-1906.build The fatal error is: could not find kernel image at /usr/share/kernel-wedge/commands/install-files line 101, KVERS line 3. Line 3 of debian/installer/mips64el/kernel-versions is for 5kc-malta, which is *not* listed in debian/config/mips64el/defines, i.e. we weren't actually building a kernel with that configuration. That's why removing the rest of its configuration fixes this failure. Yes. Thank you for fixing this problem. In the second build log you pointed to, after you removed these flavours, I found: kernel-wedge install-files 3.16-1 install -D -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/boot/vmlinux-3.16-1-sb1-bcm91250a debian/kernel-image-3.16-1-sb1-bcm91250a-di/boot/vmlinux-3.16-1-sb1-bcm91250a install -d debian/kernel-image-3.16-1-sb1-bcm91250a-di/lib/modules/3.16-1-sb1-bcm91250a install -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/lib/modules/3.16-1-sb1-bcm91250a/modules.builtin debian/linux-image-3.16-1-sb1-bcm91250a/lib/modules/3.16-1-sb1-bcm91250a/modules.order debian/kernel-image-3.16-1-sb1-bcm91250a-di/lib/modules/3.16-1-sb1-bcm91250a/ install -D -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/boot/System.map-3.16-1-sb1-bcm91250a debian/kernel-image-3.16-1-sb1-bcm91250a-di/boot/System.map-3.16-1-sb1-bcm91250a kernel-wedge copy-modules 3.16-1 sb1-bcm91250a 3.16-1-sb1-bcm91250a cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-sb1-bcm91250a/mips64el-sb1-bcm91250a kernel-wedge find-dups 3.16-1-sb1-bcm91250a kernel-wedge find-unpackaged 3.16-1-sb1-bcm91250a 3.16-1-sb1-bcm91250a These modules from 3.16-1-sb1-bcm91250a are unpackaged: [...] kernel-wedge strip-modules 3.16-1-sb1-bcm91250a install -D -m 644 debian/linux-image-3.16-1-loongson-3/boot/vmlinux-3.16-1-loongson-3 debian/kernel-image-3.16-1-loongson-3-di/boot/vmlinux-3.16-1-loongson-3 install -d debian/kernel-image-3.16-1-loongson-3-di/lib/modules/3.16-1-loongson-3 install -m 644 debian/linux-image-3.16-1-loongson-3/lib/modules/3.16-1-loongson-3/modules.builtin debian/linux-image-3.16-1-loongson-3/lib/modules/3.16-1-loongson-3/modules.order debian/kernel-image-3.16-1-loongson-3-di/lib/modules/3.16-1-loongson-3/ install -D -m 644 debian/linux-image-3.16-1-loongson-3/boot/System.map-3.16-1-loongson-3 debian/kernel-image-3.16-1-loongson-3-di/boot/System.map-3.16-1-loongson-3 kernel-wedge copy-modules 3.16-1 loongson-3 3.16-1-loongson-3 cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-loongson-3/mips64el-loongson-3 kernel-wedge find-dups 3.16-1-loongson-3 kernel-wedge find-unpackaged 3.16-1-loongson-3 3.16-1-loongson-3 These modules from 3.16-1-loongson-3 are unpackaged: [...] kernel/drivers/staging/speakup/speakup.ko kernel/drivers/staging/speakup/speakup_acntpc.ko kernel/drivers/staging/speakup/speakup_acntsa.ko kernel/drivers/staging/speakup/speakup_apollo.ko kernel/drivers/staging/speakup/speakup_audptr.ko kernel/drivers/staging/speakup/speakup_bns.ko kernel/drivers/staging/speakup/speakup_decext.ko kernel/drivers/staging/speakup/speakup_dectlk.ko kernel/drivers/staging/speakup/speakup_dtlk.ko kernel/drivers/staging/speakup/speakup_dummy.ko kernel/drivers/staging/speakup/speakup_keypc.ko kernel/drivers/staging/speakup/speakup_ltlk.ko kernel/drivers/staging/speakup/speakup_soft.ko kernel/drivers/staging/speakup/speakup_spkout.ko kernel/drivers/staging/speakup/speakup_txprt.ko [...] kernel-wedge strip-modules 3.16-1-loongson-3 kernel-wedge check kernel-image-3.16-1-sb1-bcm91250a-di nic-modules-3.16-1-sb1-bcm91250a-di nic-wireless-modules-3.16-1-sb1-bcm91250a-di nic-shared-modules-3.16-1-sb1-bcm91250a-di usb-serial-modules-3.16-1-sb1-bcm91250a-di ppp-modules-3.16-1-sb1-bcm91250a-di pata-modules-3.16-1-sb1-bcm91250a-di cdrom-core-modules-3.16-1-sb1-bcm91250a-di scsi
Bug#671032: Bug#631427: gcc-4.6: FTBFS with GCC_TARGET
Control: reassign -1 gcc-4.9 On Tue, 01 May 2012 14:01:19 +0200 Matthias Klose d...@debian.org wrote: clone 631427 -1 reassign -1 debhelper retitle -1 dh_strip should handle both host and target objects thanks On 23.06.2011 21:17, Adam Borowski wrote: Package: src:gcc-4.6 Version: 4.6.0-14 Severity: normal Hi! When building a cross compiler, there are two problems: 1. hardcoded use of gcc-4.4 without a declared build-dependency. now uses gcc. You can't always rely on newer gcc versions for non primary or non secondary architectures. 2. dh_strip is used both on objects for the build and host arch. This does not work. You'd need to either: a) call either native or cross strip appropriately b) build-depend on binutils-multiarch c) Loic Minier suggested there is some way to force dh_strip to do a), although for whatever reason it doesn't work in current unstable these packages can contain both code for the host and the target. dh_strip should either provide a way to handle these automatically, or accept an option for the strip binary to use (and then -X could be used to not strip some objects). dh_strip can do it now with setting DEB_HOST_GNU_TYPE The attached patch can fix this bug. diff -u gcc-4.9-4.9.1/debian/rules.d/binary-d.mk gcc-4.9-4.9.1/debian/rules.d/binary-d.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-d.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-d.mk @@ -117,7 +117,7 @@ debian/dh_doclink -p$(p_libphobos) $(p_base) endif - dh_strip -p$(p_libphobos) + $(cross_strip) dh_strip -p$(p_libphobos) dh_compress -p$(p_libphobos) dh_fixperms -p$(p_libphobos) dh_shlibdeps -p$(p_libphobos) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-fortran.mk gcc-4.9-4.9.1/debian/rules.d/binary-fortran.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-fortran.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-fortran.mk @@ -97,7 +97,7 @@ cp debian/$(p_l).overrides debian/$(p_l)/usr/share/lintian/overrides/$(p_l); \ fi - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) @@ -137,7 +137,7 @@ debian/dh_doclink -p$(p_l) $(p_base) debian/dh_rmemptydirs -p$(p_l) - dh_strip -p$(p_l) + $(cross_strip) dh_strip -p$(p_l) dh_compress -p$(p_l) dh_fixperms -p$(p_l) $(cross_shlibdeps) dh_shlibdeps -p$(p_l) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-go.mk gcc-4.9-4.9.1/debian/rules.d/binary-go.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-go.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-go.mk @@ -101,7 +101,7 @@ debian/dh_doclink -p$(p_l) $(p_base) debian/dh_doclink -p$(p_d) $(p_base) - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-libasan.mk gcc-4.9-4.9.1/debian/rules.d/binary-libasan.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-libasan.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-libasan.mk @@ -35,7 +35,7 @@ cp debian/$(p_l).overrides debian/$(p_l)/usr/share/lintian/overrides/$(p_l); \ fi - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-libatomic.mk gcc-4.9-4.9.1/debian/rules.d/binary-libatomic.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-libatomic.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-libatomic.mk @@ -30,7 +30,7 @@ debian/dh_doclink -p$(p_l) $(p_base) debian/dh_doclink -p$(p_d) $(p_base) - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-libcilkrts.mk gcc-4.9-4.9.1/debian/rules.d/binary-libcilkrts.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-libcilkrts.mk +++ gcc-4.9-4.9.1/debian/rules.d/binary-libcilkrts.mk @@ -35,7 +35,7 @@ cp debian/$(p_l).overrides debian/$(p_l)/usr/share/lintian/overrides/$(p_l); \ fi - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) diff -u gcc-4.9-4.9.1/debian/rules.d/binary-libgcc.mk gcc-4.9-4.9.1/debian/rules.d/binary-libgcc.mk --- gcc-4.9-4.9.1/debian/rules.d/binary-libgcc.mk +++
Bug#750593: [xml/sgml-pkgs] Bug#750593: xsltproc: bus error on some architectures
On Tue, Aug 19, 2014 at 9:32 AM, YunQiang Su wzss...@gmail.com wrote: On Tue, Aug 19, 2014 at 8:44 AM, Martin Schwenke mar...@meltin.net wrote: On Wed, 4 Jun 2014 22:27:03 +0200 Ivo De Decker ivo.dedec...@ugent.be wrote: On some architectures (like i386), xsltproc fails with Bus error when running /usr/bin/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml with the attached version of man.xsl and smb.conf.5.tmp.xml. This is done during the samba build. It fails on armel, armhf and i386, but doesn't fail on other architectures. I'm also seeing it fail on i386. Bizarrely, it doesn't fail when run under valgrind or gdb, so unable to get any clues that way. :-( I met the same problem on mips64el. For many packages, it fails in sbuild, while when dpkg-buildpackage manually, everything seems good. With this tiny script, I can catch crash with gdb: PH=/usr/bin/ $PH/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml pid=`pgrep xsltproc`; gdb $PH/xsltproc $pid While it seems helpless: (gdb) bt #0 0x00fff592e83c in ?? () peace happiness, martin ___ debian-xml-sgml-pkgs mailing list debian-xml-sgml-p...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs -- YunQiang Su -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750593: [xml/sgml-pkgs] Bug#750593: xsltproc: bus error on some architectures
This is the backtrace log. Wish it help. It always crashs in a i386 schroot env. On Wed, Sep 10, 2014 at 6:48 PM, YunQiang Su wzss...@gmail.com wrote: On Tue, Aug 19, 2014 at 9:32 AM, YunQiang Su wzss...@gmail.com wrote: On Tue, Aug 19, 2014 at 8:44 AM, Martin Schwenke mar...@meltin.net wrote: On Wed, 4 Jun 2014 22:27:03 +0200 Ivo De Decker ivo.dedec...@ugent.be wrote: On some architectures (like i386), xsltproc fails with Bus error when running /usr/bin/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml with the attached version of man.xsl and smb.conf.5.tmp.xml. This is done during the samba build. It fails on armel, armhf and i386, but doesn't fail on other architectures. I'm also seeing it fail on i386. Bizarrely, it doesn't fail when run under valgrind or gdb, so unable to get any clues that way. :-( I met the same problem on mips64el. For many packages, it fails in sbuild, while when dpkg-buildpackage manually, everything seems good. With this tiny script, I can catch crash with gdb: PH=/usr/bin/ $PH/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml pid=`pgrep xsltproc`; gdb $PH/xsltproc $pid While it seems helpless: (gdb) bt #0 0x00fff592e83c in ?? () peace happiness, martin ___ debian-xml-sgml-pkgs mailing list debian-xml-sgml-p...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs -- YunQiang Su -- YunQiang Su -- YunQiang Su gdb.txt.xz Description: Binary data
Bug#729767: H5detect failed to run on mips64el
On Fri, Sep 5, 2014 at 6:29 AM, pini p...@pustule.org wrote: Hi, Does this failure still occur with release 1.8.13 in unstable? If so an access to a porterbox would be appreciated. It works now. thank you very much. Thanks, _g. YunQiang Su a écrit , Le 17/11/2013 02:40: Package: hdf5 Version: 1.8.11-5 I try to build hdf5 on mips64el, while H5detect failed to build. If you need to use porterbox, please contact with me. syq@thor ./debian/build/src/H5detect ~/hdf5/hdf5-1.8.11 /* Generated automatically by H5detect -- do not edit */ /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Copyright by The HDF Group. * * Copyright by the Board of Trustees of the University of Illinois. * * All rights reserved. * * * * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the files COPYING and Copyright.html. COPYING can be found at the root * * of the source code distribution tree; Copyright.html can be found at the * * root level of an installed copy of the electronic HDF5 document set and * * is linked from the top-level documents page. It can also be found at * * http://hdfgroup.org/HDF5/doc/Copyright.html. If you do not have * * access to either file, you may request a copy from h...@hdfgroup.org. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Created:Nov 17, 2013 *syq@thor * * Purpose:This machine-generated source code contains *information about the various integer and *floating point numeric formats found on this *architecture. The parameters below should be *checked carefully and errors reported to the *HDF5 maintainer. * *Each of the numeric formats listed below are *printed from most significant bit to least *significant bit even though the actual bytes *might be stored in a different order in *memory. The integers above each binary byte *indicate the relative order of the bytes in *memory; little-endian machines have *decreasing numbers while big-endian machines *have increasing numbers. * *The fields of the numbers are printed as *letters with `S' for the mantissa sign bit, *`M' for the mantissa magnitude, and `E' for *the exponent. The exponent has an associated *bias which can be subtracted to find the *true exponent.The radix point is assumed *to be before the first `M' bit. Any bit *of a floating-point value not falling into one *of these categories is printed as a question *mark. Bits of integer types are printed as *`I' for 2's complement and `U' for magnitude. * *If the most significant bit of the normalized *mantissa (always a `1' except for `0.0') is *not stored then an `implicit=yes' appears *under the field description. In thie case, *the radix point is still assumed to be *before the first `M' but after the implicit *bit. * * Modifications: * *DO NOT MAKE MODIFICATIONS TO THIS FILE! *It was generated by code in `H5detect.c'. * *- */ [1]8971 illegal hardware instruction ./debian/build/src/H5detect syq@thor gdb ./debian/build/src/H5detect ~/hdf5/hdf5-1.8.11 GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) Copyright (C) 2013 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. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/syq/hdf5/hdf5-1.8.11/debian/build/src/H5detect...done. (gdb) r Starting program: /home/syq/hdf5/hdf5-1.8.11/./debian/build/src/H5detect [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/mips64el-linux-gnuabi64/libthread_db.so.1. Program received signal SIGBUS, Bus error. 0x00fff7f8defc in raise () from /lib/mips64el-linux-gnuabi64/libpthread.so.0 (gdb) backtrace #0 0x00fff7f8defc in raise () from /lib
Bug#747385: failing pcre3 builds
On Wed, Sep 3, 2014 at 7:48 AM, Thorsten Glaser t...@mirbsd.de wrote: Hi, it could be that you must disable the JIT on mips64el, too. http://mips64el.debian.net/debian/buildlog/p/pcre3_1%3a8.35-3/pcre3_8.35-3_mips64el-20140724-1633.build It builds successfully on mips64el :-) See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760327 bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758654: nqp: add mips64el support
Package: nqp
Version: 2014.04-3
With this patch, nqp can build on mips64el. Please consider it.
--
YunQiang Su
diff -Nru nqp-2014.04/debian/control nqp-2014.04/debian/control
--- nqp-2014.04/debian/control 2014-07-14 18:14:13.0 +0800
+++ nqp-2014.04/debian/control 2033-12-13 15:57:32.0 +0800
@@ -15,7 +15,7 @@
Homepage: https://github.com/perl6/nqp
Package: nqp
-Architecture: i386 amd64 armel armhf mips mipsel powerpc ppc64el
kfreebsd-amd64 kfreebsd-i386
+Architecture: i386 amd64 armel armhf mips mipsel mips64el powerpc ppc64el
kfreebsd-amd64 kfreebsd-i386
Depends: ${shlibs:Depends},
${misc:Depends},
${parrot:Depends}
diff -Nru nqp-2014.04/debian/patches/add_mips64el_arch
nqp-2014.04/debian/patches/add_mips64el_arch
--- nqp-2014.04/debian/patches/add_mips64el_arch1970-01-01
08:00:00.0 +0800
+++ nqp-2014.04/debian/patches/add_mips64el_arch2033-12-13
16:04:11.0 +0800
@@ -0,0 +1,13 @@
+Index: nqp-2014.04/3rdparty/dyncall/configure
+===
+--- nqp-2014.04.orig/3rdparty/dyncall/configure2033-12-13
15:56:00.0 +0800
nqp-2014.04/3rdparty/dyncall/configure 2033-12-13 16:04:06.715022106
+0800
+@@ -198,7 +198,7 @@
+ CONFIG_ARCH=mips32
+ elif [ $ARCH = mipsel ] || [ $ARCH = pmax ]; then
+ CONFIG_ARCH=mips32el
+-elif [ $ARCH = loongson ]; then
++elif [ $ARCH = loongson ] || [ $ARCH = mips64el ]; then
+ CONFIG_ARCH=mips64el
+ elif [ $ARCH = sparc ] || [ $ARCH = sparc64 ]; then
+ CONFIG_ARCH=sparc
diff -Nru nqp-2014.04/debian/patches/series nqp-2014.04/debian/patches/series
--- nqp-2014.04/debian/patches/series 2014-07-14 18:14:13.0 +0800
+++ nqp-2014.04/debian/patches/series 2033-12-13 16:01:08.0 +0800
@@ -5,3 +5,4 @@
07_disable-serialization-tests.patch
fix-missing-prototype
add_ppc64el_arch
+add_mips64el_arch
Bug#758530: libraw: update symbols file for mips64el
Package: libraw Version: 0.16.0-6 Sorry for the previous patch, there are 2 segments, I only update one. -- YunQiang Su diff -Nru libraw-0.16.0/debian/libraw10.symbols libraw-0.16.0/debian/libraw10.symbols --- libraw-0.16.0/debian/libraw10.symbols 2014-07-21 12:18:25.0 + +++ libraw-0.16.0/debian/libraw10.symbols 2014-08-18 22:30:56.0 + @@ -765,15 +765,15 @@ (c++)LibRaw_file_datastream::tell()@Base 0.16.0 (c++)LibRaw_file_datastream::valid()@Base 0.16.0 (c++)LibRaw_file_datastream::~LibRaw_file_datastream()@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw_file_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw_buffer_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw_buffer_datastream::LibRaw_buffer_datastream(void*, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw_bigfile_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw_abstract_datastream::tempbuffer_open(void*, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw::open_buffer(void*, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw::calloc(unsigned int, unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw::malloc(unsigned int)@Base 0.16.0 - (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !ppc64 !ppc64el !s390x !sparc64)LibRaw::realloc(void*, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw_file_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw_buffer_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw_buffer_datastream::LibRaw_buffer_datastream(void*, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw_bigfile_datastream::read(void*, unsigned int, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw_abstract_datastream::tempbuffer_open(void*, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw::open_buffer(void*, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw::calloc(unsigned int, unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw::malloc(unsigned int)@Base 0.16.0 + (c++|arch=!alpha !amd64 !arm64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64)LibRaw::realloc(void*, unsigned int)@Base 0.16.0 (c++|optional=gcc-4.9)std::ctypechar::do_widen(char) const@Base 0.16.0 default_data_callback@Base 0.16.0 default_memory_callback@Base 0.16.0
Bug#750593: [xml/sgml-pkgs] Bug#750593: xsltproc: bus error on some architectures
On Tue, Aug 19, 2014 at 8:44 AM, Martin Schwenke mar...@meltin.net wrote: On Wed, 4 Jun 2014 22:27:03 +0200 Ivo De Decker ivo.dedec...@ugent.be wrote: On some architectures (like i386), xsltproc fails with Bus error when running /usr/bin/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml with the attached version of man.xsl and smb.conf.5.tmp.xml. This is done during the samba build. It fails on armel, armhf and i386, but doesn't fail on other architectures. I'm also seeing it fail on i386. Bizarrely, it doesn't fail when run under valgrind or gdb, so unable to get any clues that way. :-( I met the same problem on mips64el. For many packages, it fails in sbuild, while when dpkg-buildpackage manually, everything seems good. peace happiness, martin ___ debian-xml-sgml-pkgs mailing list debian-xml-sgml-p...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758491: percona-xtrabackup: wrong mips64 asm in taocrypt
Package: percona-xtrabackup Version: 2.2.3-2 In extra/yassl/taocrypt/src/integer.cpp there is a problem in mips64 asm. Please fix it. This patch has been applied to MySQL, it works well. Index: percona-xtrabackup-2.2.3/extra/yassl/taocrypt/src/integer.cpp === --- percona-xtrabackup-2.2.3.orig/extra/yassl/taocrypt/src/integer.cpp 2014-07-23 01:13:52.0 +0800 +++ percona-xtrabackup-2.2.3/extra/yassl/taocrypt/src/integer.cpp 2033-12-08 16:07:06.314007266 +0800 @@ -189,7 +189,7 @@ a (a), rm (b) : cc); #elif defined(__mips64) -__asm__(dmultu %2,%3 : =h (r.halfs_.high), =l (r.halfs_.low) +__asm__(dmultu %2,%3 : =d (r.halfs_.high), =lc (r.halfs_.low) : r (a), r (b)); #elif defined(_M_IX86) -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758088: pspp failed to run test on mips64el
Package: pspp Version: 0.7.9+git20120620-1.2 --- - 2033-12-08 08:27:16.958411009 +0800 +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/951/stdout 2033-12-08 08:27:16.940752178 +0800 @@ -1,15 +1,15 @@ Variable 0 is string, label is A Short String Variable Value Labels: = threes - = ones = twos + = ones Variable 1 is longstring, label is A Long String Variable Value Labels: Variable 2 is numeric, label is A Numeric Variable Value Labels: 1 = Unity -3 = Thripality 2 = Duality +3 = Thripality Variable 3 is date, label is A Date Variable Value Labels: Variable 4 is dollar, label is A Dollar Variable 951. perl-module.at:335: 951. Perl read system file (perl-module.at:335): FAILED (perl-module.at:370) # -*- compilation -*- 957. perl-module.at:703: testing Perl Pspp.t ... ./perl-module.at:706: perl -MText::Diff -e '' || exit 77 ./perl-module.at:707: LD_LIBRARY_PATH=$abs_top_builddir/src/.libs \ DYLD_LIBRARY_PATH=$abs_top_builddir/src/.libs \ $PERL -I$abs_top_builddir/perl-module/blib/arch \ -I$abs_top_builddir/perl-module/blib/lib $abs_top_builddir/perl-module/t/Pspp.t --- - 2033-12-08 08:27:26.272479944 +0800 +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/957/stdout 2033-12-08 08:27:26.257159156 +0800 @@ -23,7 +23,7 @@ ok 22 - Value label for long string ok 23 - Check output 2 ok 24 - Dictionary survives sysfile -ok 25 - Basic reader operation +not ok 25 - Basic reader operation ok 26 - Streaming of files Formatted string is 11-SEP-2001 08:20 ok 27 - format_value function @@ -35,6 +35,6 @@ ok 33 - Missing Value Positive ok 34 - Missing Value Positive SYS ok 35 - Missing Value Positive Num -ok 36 - Custom Attributes +not ok 36 - Custom Attributes ok 37 - Case count -- YunQiang Su testsuite.log.xz Description: Binary data
Bug#758097: portabase: fix mips64el build
Package: portabase Version: 2.1+git20120910-1 Portabase ftbfs on mips64el, and with this tiny patch it can build now. Index: portabase-2.1+git20120910/metakit/include/mk4.h === --- portabase-2.1+git20120910.orig/metakit/include/mk4.h 2012-09-17 08:56:23.0 + +++ portabase-2.1+git20120910/metakit/include/mk4.h 2014-08-14 08:25:45.727508267 + @@ -102,7 +102,8 @@ #if !defined (_WIN32) !defined (q4_LONG64) #if defined (_PA_RISC2_0) || defined (__powerpc64__) || defined(__sparcv9) || \ defined(__x86_64__) || defined(__s390x__) || defined(__alpha) || \ - (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) + (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) || \ + defined(__mips64) #define q4_LONG64 1 #endif #endif -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754360: libraw: fix symbols for mips64 and mips64el
Control: reopen -1 On Thu, 10 Jul 2014 18:33:22 +0800 YunQiang Su wzss...@gmail.com wrote: Package: libraw Version: 0.16.0-5 Add mips64 and mips64el to the list of 64bit ports. You didn't add mips64 and mips64el to the '!' list, such as !amd64 etc. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758106: ploop ftbfs on mips64el
Package: ploop
Version: 1.11-1
On mips64el, long long and long has the same 64bit width, while
they are totally different type.
Not very sure about why.
--
YunQiang Su
Index: ploop-1.11/lib/balloon_util.c
===
--- ploop-1.11.orig/lib/balloon_util.c 2033-12-08 10:13:44.066252533 +0800
+++ ploop-1.11/lib/balloon_util.c 2033-12-08 10:13:44.050627531 +0800
@@ -273,14 +273,14 @@
ploop_err(0,
Image corrupted: L2[%u] == %u
(max=%llu),
clu + j - l2_slot, delta-l2[j],
- (rlen - 1) * B2S(cluster));
+ (long long unsigned)(rlen - 1) *
B2S(cluster));
return(SYSEXIT_PLOOPFMT);
}
if (ridx delta-l1_size) {
ploop_err(0,
Image corrupted: L2[%u] == %u
(min=%llu),
clu + j - l2_slot, delta-l2[j],
- delta-l1_size * B2S(cluster));
+ (long long unsigned)(delta-l1_size *
B2S(cluster)));
return(SYSEXIT_PLOOPFMT);
}
@@ -538,14 +538,14 @@
ploop_err(0,
Image corrupted: L2[%u] == %u (max=%llu) (2),
clu, delta-l2[l2_slot],
- (rlen - 1) * B2S(cluster));
+ (long long unsigned)((rlen - 1) *
B2S(cluster)));
return SYSEXIT_PLOOPFMT;
}
if (ridx ridx delta-l1_size) {
ploop_err(0,
Image corrupted: L2[%u] == %u (min=%llu) (2),
clu, delta-l2[l2_slot],
- delta-l1_size * B2S(cluster));
+ (long long unsigned)(delta-l1_size *
B2S(cluster)));
return SYSEXIT_PLOOPFMT;
}
Index: ploop-1.11/lib/check.c
===
--- ploop-1.11.orig/lib/check.c 2014-04-04 06:09:18.0 +0800
+++ ploop-1.11/lib/check.c 2033-12-08 10:14:00.597503828 +0800
@@ -552,7 +552,7 @@
ploop_err(0, Delta file %s contains
uninitialized blocks
(offset=%llu len=%llu)
which are not aligned to
cluster size,
- image, fm_ext[i].fe_logical,
fm_ext[i].fe_length);
+ image, (long long
unsigned)fm_ext[i].fe_logical, (long long unsigned)fm_ext[i].fe_length);
if (fill_hole(image, fd, fm_ext[i].fe_logical,
fm_ext[i].fe_logical +
fm_ext[i].fe_length, log, repair))
Index: ploop-1.11/lib/ploop.c
===
--- ploop-1.11.orig/lib/ploop.c 2014-04-04 06:09:18.0 +0800
+++ ploop-1.11/lib/ploop.c 2033-12-08 10:38:39.667932199 +0800
@@ -273,7 +273,7 @@
if (sectors max) {
ploop_err(0, An incorrect block device size is specified: %llu
sectors.
The maximum allowed size is %llu sectors,
- sectors, max);
+ (long long unsigned)sectors, (long long
unsigned)max);
return -1;
}
return 0;
@@ -2273,7 +2273,7 @@
ploop_err(0, Unable to change image
size to %lu
sectors, minimal size
is %llu,
(long)new_fs_size,
- (blocks -
available_balloon_size));
+ (long long
unsigned)(blocks - available_balloon_size));
ret = SYSEXIT_PARAM;
goto err;
}
Index: ploop-1.11/lib/balloon.c
===
--- ploop-1.11.orig/lib/balloon.c 2014-04-04 06:09:18.0 +0800
+++ ploop-1.11/lib/balloon.c2033-12-08 10:42:29.695293969 +0800
@@ -860,7 +860,7 @@
range.minlen = MAX(MAX_DISCARD_CLU * cluster, minlen_b);
for (; range.minlen = minlen_b; range.minlen /= 2) {
- ploop_log(1, Call FITRIM, for minlen=%lld, range.minlen);
+ ploop_log(1, Call FITRIM, for minlen=%llu, (unsigned long
long)range.minlen
Bug#757318: v4l2loopback: ftbfs with DEB_BUILD_PARALLEL=1
Package: v4l2loopback Version: 0.8.0-2 When build v4l2loopback on mips64el, I get a problem: Adding cdbs dependencies to debian/v4l2loopback-utils.substvars dh_installdirs -pv4l2loopback-utils dh_installdocs -pv4l2loopback-utils ./README ./NEWS ./TODO ./AUTHORS dh_installexamples -pv4l2loopback-utils dh_installman -pv4l2loopback-utils man/v4l2loopback-ctl.1: No such file or directory at /usr/bin/dh_installman line 130. make: *** [binary-install/v4l2loopback-utils] Error 2 /usr/share/cdbs/1/rules/debhelper.mk:211: recipe for target 'binary-install/v4l2loopback-utils' failed dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 It seems due to PARALLEL build. http://mips64el.debian.net/debian/buildlog/v/v4l2loopback_0.8.0-2/v4l2loopback_0.8.0-2_mips64el-20140730-1933.build -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757324: pvm: add mips64el support in debian/getpvmarch
Package: pvm Version: 3.4.5-12.5 In debian/getpvmarch, the mips and mipsel staff may be changed to mips*) echo LINUXMIPS ;; I tested it on mips64el. it works well. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757082: rt-app: use __u64 in both src/rt-app_utils.h and src/rt-app_utils.c
Package: rt-app Version: 0.2~alpha2.20140716 For the return type of function: timespec_to_nsec, in src/rt-app_utils.h, it is 'unsigned long long', while in src/rt-app_utils.c it is '__u64'. I think __u64 is a better option. This causes it ftbfs on mips64el. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757084: qof, mips64el: expected [112346 / 10000000] = [112346 / 9999999] double 6 figs
Package: qof Version: 0.8.7-1 When try to build qof on mips64el, I got an error when run test: test-numeric FAILURE expected [112346 / 1000] = [112346 / 999] double 6 figs test-numeric.c:68 Executed 102859 tests. There was 1 failure. FAIL: test-numeric You can get the build log from: http://mips64el.debian.net/debian/buildlog/q/qof_0.8.7-1/qof_0.8.7-1_mips64el-20140710-2018.build -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741785: seems upstream has fixed the readline issue with the libseed ftbfs issue.
On Sun, 13 Apr 2014 10:29:15 +0530 =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?= shirisha...@gmail.com wrote: Hi there, Just was wondering about libseed transition, saw the bug and saw the upstream comment. https://bugzilla.gnome.org/show_bug.cgi?id=725602#c2 Looking at the web interface for seed it seems to be this commit :- https://git.gnome.org/browse/seed/commit/?id=cf772e792fd64f70ee2c714e0b5eaf527ce35467 I tested this patch on mips64el. It works well. Any progress of it? Looking forward to an updated seed in testing soonish :) -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756586: searchandrescue: FTBFS on mips64el
Source: searchandrescue Version: 1.5.0-1 Severity: normal Tags: patch Please add mips64 and mips64el into sar/platforms.ini, like the ppc64el and arm64, aka, add PlatformSearchPathLib = /usr/lib/mips64el-linux-gnuabi64/ PlatformSearchPathLib = /usr/lib/mips64-linux-gnuabi64/ -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
