Bug#769003: libjogl2-java: FTBFS on arm64, ppc64el, s390x
Control: reassign -1 libgluegen2-build-java 2.2.4-1 Control: affects -1 libjogl2-java On Mon, Nov 10, 2014 at 05:53:43PM +0100, Hector Oron wrote: Your package fails to build from source on Debian autobuilder network. Please check your package build logs at: https://buildd.debian.org/status/package.php?p=libjogl2-javasuite=sid arm64 full log at: https://buildd.debian.org/status/fetch.php?pkg=libjogl2-javaarch=arm64ver=2.2.4%2Bdfsg-1stamp=1415253649 This is a recurrence of #733310, which happened because missing-arch-symbol.diff was incorrectly rebased across the upstream change in http://jogamp.org/git/?p=gluegen.git;a=commitdiff;h=addb639e6dde90519f772a66222eb86107b35176. Here's a fix. * Fix missing-arch-symbol.diff to cover the gcc case as well as clang (closes: #769003). diff -Nru gluegen2-2.2.4/debian/patches/missing-arch-symbol.diff gluegen2-2.2.4/debian/patches/missing-arch-symbol.diff --- gluegen2-2.2.4/debian/patches/missing-arch-symbol.diff 2014-10-20 15:35:29.0 +0100 +++ gluegen2-2.2.4/debian/patches/missing-arch-symbol.diff 2014-11-11 10:57:44.0 + @@ -1,8 +1,18 @@ -Index: gluegen-v2.2.0/make/stub_includes/platform/glibc-compat-symbols.h +Index: b/make/stub_includes/platform/glibc-compat-symbols.h === gluegen-v2.2.0.orig/make/stub_includes/platform/glibc-compat-symbols.h 2014-08-10 15:38:43.065816752 +0200 -+++ gluegen-v2.2.0/make/stub_includes/platform/glibc-compat-symbols.h 2014-08-10 15:38:43.065816752 +0200 -@@ -30,7 +30,8 @@ +--- a/make/stub_includes/platform/glibc-compat-symbols.h b/make/stub_includes/platform/glibc-compat-symbols.h +@@ -22,7 +22,8 @@ + #elif defined(__amd64__) +#define GLIBC_COMPAT_SYMBOL(FFF) __asm__(.symver #FFF , #FFF @GLIBC_2.2.5); + #else +- #define GLIBC_COMPAT_SYMBOL(FFF) __asm__(.symver #FFF , #FFF @GLIBC_2.0); ++ /* Don't try to guess a wrong version */ ++ #define GLIBC_COMPAT_SYMBOL(FFF) + #endif /*__amd64__*/ + #elif defined(__clang__) + #if defined(__arm__) +@@ -30,7 +31,8 @@ #elif defined(__amd64__) #define GLIBC_COMPAT_SYMBOL(FFF) asm(.symver #FFF , #FFF @GLIBC_2.2.5); #else Thanks, -- Colin Watson [cjwat...@ubuntu.com] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#726389: commons-daemon: diff for NMU version 1.0.15-5.2
Control: tag -1 pending Dear maintainer, I've prepared an NMU for commons-daemon (versioned as 1.0.15-5.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. I took the liberty of including a very similar patch for ppc64el, already tested on Ubuntu. Per earlier feedback on this bug, I also forwarded this upstream. Regards, -- Colin Watson [cjwat...@debian.org] diff -Nru commons-daemon-1.0.15/debian/changelog commons-daemon-1.0.15/debian/changelog --- commons-daemon-1.0.15/debian/changelog 2014-10-24 05:36:43.0 +0100 +++ commons-daemon-1.0.15/debian/changelog 2014-11-06 11:48:28.0 + @@ -1,3 +1,11 @@ +commons-daemon (1.0.15-5.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add arm64 support (closes: #726389). + * Add ppc64el support. + + -- Colin Watson cjwat...@debian.org Thu, 06 Nov 2014 11:48:27 + + commons-daemon (1.0.15-5.1) unstable; urgency=low * Non-maintainer upload. diff -Nru commons-daemon-1.0.15/debian/patches/arm64.diff commons-daemon-1.0.15/debian/patches/arm64.diff --- commons-daemon-1.0.15/debian/patches/arm64.diff 1970-01-01 01:00:00.0 +0100 +++ commons-daemon-1.0.15/debian/patches/arm64.diff 2014-11-06 11:30:03.0 + @@ -0,0 +1,37 @@ +Description: Add ARM64 support +Author: Colin Watson cjwat...@ubuntu.com +Forwarded: https://issues.apache.org/jira/browse/DAEMON-308 +Last-Update: 2014-11-06 + +Index: b/src/native/unix/configure +=== +--- a/src/native/unix/configure b/src/native/unix/configure +@@ -2697,6 +2697,11 @@ + supported_os=arm + HOST_CPU=arm + ;; ++ aarch64) ++CFLAGS=$CFLAGS -DCPU=\\\aarch64\\\ ++supported_os=aarch64 ++HOST_CPU=aarch64 ++;; + *) + echo $as_me:$LINENO: result: failed 5 + echo ${ECHO_T}failed 6 +Index: b/src/native/unix/support/apsupport.m4 +=== +--- a/src/native/unix/support/apsupport.m4 b/src/native/unix/support/apsupport.m4 +@@ -176,6 +176,11 @@ + supported_os=arm + HOST_CPU=arm + ;; ++ aarch64) ++CFLAGS=$CFLAGS -DCPU=\\\aarch64\\\ ++supported_os=aarch64 ++HOST_CPU=aarch64 ++;; + *) + AC_MSG_RESULT([failed]) + AC_MSG_ERROR([Unsupported CPU architecture $host_cpu]);; diff -Nru commons-daemon-1.0.15/debian/patches/ppc64el.diff commons-daemon-1.0.15/debian/patches/ppc64el.diff --- commons-daemon-1.0.15/debian/patches/ppc64el.diff 1970-01-01 01:00:00.0 +0100 +++ commons-daemon-1.0.15/debian/patches/ppc64el.diff 2014-11-06 11:47:23.0 + @@ -0,0 +1,37 @@ +Description: Add ppc64el support +Author: Colin Watson cjwat...@ubuntu.com +Forwarded: https://issues.apache.org/jira/browse/DAEMON-326 +Last-Update: 2014-11-06 + +Index: b/src/native/unix/configure +=== +--- a/src/native/unix/configure b/src/native/unix/configure +@@ -2702,6 +2702,11 @@ + supported_os=aarch64 + HOST_CPU=aarch64 + ;; ++ powerpc64le) ++CFLAGS=$CFLAGS -DCPU=\\\powerpc64le\\\ ++supported_os=powerpc64le ++HOST_CPU=powerpc64le ++;; + *) + echo $as_me:$LINENO: result: failed 5 + echo ${ECHO_T}failed 6 +Index: b/src/native/unix/support/apsupport.m4 +=== +--- a/src/native/unix/support/apsupport.m4 b/src/native/unix/support/apsupport.m4 +@@ -181,6 +181,11 @@ + supported_os=aarch64 + HOST_CPU=aarch64 + ;; ++ powerpc64le) ++CFLAGS=$CFLAGS -DCPU=\\\powerpc64le\\\ ++supported_os=powerpc64le ++HOST_CPU=powerpc64le ++;; + *) + AC_MSG_RESULT([failed]) + AC_MSG_ERROR([Unsupported CPU architecture $host_cpu]);; diff -Nru commons-daemon-1.0.15/debian/patches/series commons-daemon-1.0.15/debian/patches/series --- commons-daemon-1.0.15/debian/patches/series 2014-10-24 05:34:58.0 +0100 +++ commons-daemon-1.0.15/debian/patches/series 2014-11-06 11:46:44.0 + @@ -3,3 +3,5 @@ s390x_support.diff hurd_support.diff mips_abi_n32_n64_support.diff +arm64.diff +ppc64el.diff __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#756311: javatools: another archdir change for ppc64el
Package: javatools Version: 0.46 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch utopic https://packages.qa.debian.org/o/openjdk-7/news/20140707T173510Z.html changed the archdir for ppc64el to just ppc64 rather than ppc64le. I checked with Matthias and he confirmed that this was intentional: we should update that to use ppc64. ppc64el was my own invention because we didn't have any official name. Now that the ppc64 support is upstream, just use this. * The archdir for ppc64el is now ppc64. diff -Nru javatools-0.46/java-arch.sh javatools-0.46ubuntu2/java-arch.sh --- javatools-0.46/java-arch.sh 2013-12-24 16:19:20.0 + +++ javatools-0.46ubuntu2/java-arch.sh 2014-07-28 17:34:33.0 +0100 @@ -24,7 +24,7 @@ echo ppc ;; ppc64el) - echo ppc64le + echo ppc64 ;; hppa) echo parisc Thanks, -- Colin Watson [cjwat...@ubuntu.com] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#734011: Can’t build a package using closure-compiler
to libclosure-compiler-java, but instead with jarwrappers and/or openjdk-7, although it's going to take some more digging to figure out what to do about two packages trying to register the same magic number with binfmt-support. (Colin, I hope that you don't mind that I added you to the cc: I thought you could probably say right off whether its feasible to have two packages trying to use binfmt-support in this manner.) This is what I designed the detectors scheme for: you can find documentation of it in doc/detectors in the binfmt-support source package (or /usr/share/doc/binfmt-support/detectors as of 2.1.1-1). If a set of packages need to install binfmts with the same magic or the same extension, then they're ideally supposed to add detectors to their binfmt specification to further narrow down which real interpreter ought to be executed. In this case, what actually happens is that run-detectors will try anything with a detector first, followed by anything without a detector; so jardetector will get its turn first, and then it will fall back to jexec if jardetector declines. I guess that's OK? We do need to figure out why update-binfmts isn't registering things correctly, though. I notice that /usr/share/binfmts/jar is an alternative, which may have some interesting effects; compare #734197. -- Colin Watson [cjwat...@debian.org] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#726389: commons-daemon: add arm64 support
Package: commons-daemon Version: 1.0.15-2 Severity: important Tags: patch User: debian-...@lists.debian.org Usertags: arm64 This patch adds support for the new arm64 architecture. * Add arm64 support. diff -Nru commons-daemon-1.0.15/debian/patches/arm64.diff commons-daemon-1.0.15/debian/patches/arm64.diff --- commons-daemon-1.0.15/debian/patches/arm64.diff 1970-01-01 01:00:00.0 +0100 +++ commons-daemon-1.0.15/debian/patches/arm64.diff 2013-10-15 10:18:22.0 +0100 @@ -0,0 +1,37 @@ +Description: Add ARM64 support +Author: Colin Watson cjwat...@ubuntu.com +Forwarded: no +Last-Update: 2013-10-15 + +Index: b/src/native/unix/configure +=== +--- a/src/native/unix/configure b/src/native/unix/configure +@@ -2697,6 +2697,11 @@ + supported_os=arm + HOST_CPU=arm + ;; ++ aarch64) ++CFLAGS=$CFLAGS -DCPU=\\\aarch64\\\ ++supported_os=aarch64 ++HOST_CPU=aarch64 ++;; + *) + echo $as_me:$LINENO: result: failed 5 + echo ${ECHO_T}failed 6 +Index: b/src/native/unix/support/apsupport.m4 +=== +--- a/src/native/unix/support/apsupport.m4 b/src/native/unix/support/apsupport.m4 +@@ -171,6 +171,11 @@ + supported_os=arm + HOST_CPU=arm + ;; ++ aarch64) ++CFLAGS=$CFLAGS -DCPU=\\\aarch64\\\ ++supported_os=aarch64 ++HOST_CPU=aarch64 ++;; + *) + AC_MSG_RESULT([failed]) + AC_MSG_ERROR([Unsupported CPU architecture $host_cpu]);; diff -Nru commons-daemon-1.0.15/debian/patches/series commons-daemon-1.0.15/debian/patches/series --- commons-daemon-1.0.15/debian/patches/series 2013-04-05 20:48:30.0 +0100 +++ commons-daemon-1.0.15/debian/patches/series 2013-10-15 10:14:36.0 +0100 @@ -1,2 +1,3 @@ libgcj_PR31700.diff kfreebsd_support.diff +arm64.diff Thanks, -- Colin Watson [cjwat...@ubuntu.com] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#726389: commons-daemon: add arm64 support
On Tue, Oct 15, 2013 at 11:52:19AM +0200, Emmanuel Bourg wrote: Could you please forward it upstream? I'll merge it and update the Debian package when Commons Daemon 1.0.16 is out. Done: https://issues.apache.org/jira/browse/DAEMON-308 -- Colin Watson [cjwat...@ubuntu.com] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#706419: cofoja: fails to build with OpenJDK 7
Package: cofoja Version: 1.0~r139-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch saucy cofoja fails to build with OpenJDK 7, because the unmappable character diagnostics that were warnings in OpenJDK 6 are now errors. These start with: [javac] /build/buildd/cofoja-1.0~r139/src/com/google/java/contract/AllowUnusedImport.java:30: error: unmappable character for encoding ASCII [javac] * @author nhat.minh...@huoc.org (Nhat Minh L??) This can be fixed by forcing the encoding, as in the following patch. I don't know if it's strictly necessary to touch all these javac invocations, but figured it was better to be safe. * Force source file encoding to UTF-8. diff -Nru cofoja-1.0~r139/debian/patches/encoding cofoja-1.0~r139/debian/patches/encoding --- cofoja-1.0~r139/debian/patches/encoding 1970-01-01 01:00:00.0 +0100 +++ cofoja-1.0~r139/debian/patches/encoding 2013-04-30 00:54:07.0 +0100 @@ -0,0 +1,54 @@ +Description: Force encoding to UTF-8 +Author: Colin Watson cjwat...@ubuntu.com +Forwarded: no +Last-Update: 2013-04-30 + +Index: b/build.xml +=== +--- a/build.xml b/build.xml +@@ -93,7 +93,7 @@ + mkdir dir=${obj.dir}/tmp@{stage} / + mkdir dir=${obj.dir}/stage@{stage} / + javac srcdir=${src.dir} destdir=${obj.dir}/tmp@{stage} +- debug=true includeantruntime=false ++ debug=true includeantruntime=false encoding=UTF-8 + classpath refid=base.class.path / + compilerarg value=-processorpath / + compilerarg value=@{bootstrappath}:${asm.jar} / +@@ -148,7 +148,7 @@ + mkdir dir=${obj.dir}/bare / + javac srcdir=${src.dir} destdir=${obj.dir}/bare +debug=${debug} +- includeantruntime=false ++ includeantruntime=false encoding=UTF-8 + classpath refid=base.class.path / + /javac + /target +@@ -165,7 +165,7 @@ + requirejar property=bootstrap.jar / + mkdir dir=${obj.dir}/build / + javac srcdir=${build.dir} destdir=${obj.dir}/build +- debug=true includeantruntime=false ++ debug=true includeantruntime=false encoding=UTF-8 + classpath + path refid=base.class.path / + pathelement path=${java.class.path} / +@@ -202,7 +202,7 @@ + requirejar property=junit.jar / + mkdir dir=${obj.dir}/test / + javac srcdir=${test.dir} destdir=${obj.dir}/test +- debug=true includeantruntime=false ++ debug=true includeantruntime=false encoding=UTF-8 + classpath + path refid=test.class.path / + pathelement path=${obj.dir}/stage2 / +@@ -216,7 +216,7 @@ + + target name=buildtest2 depends=buildtest1,stage2 + javac srcdir=${test.dir} destdir=${obj.dir}/test +- debug=true includeantruntime=false ++ debug=true includeantruntime=false encoding=UTF-8 + classpath + path refid=test.class.path / + pathelement path=${obj.dir}/stage2 / diff -Nru cofoja-1.0~r139/debian/patches/series cofoja-1.0~r139/debian/patches/series --- cofoja-1.0~r139/debian/patches/series 2013-04-10 14:50:48.0 +0100 +++ cofoja-1.0~r139/debian/patches/series 2013-04-30 00:51:48.0 +0100 @@ -1 +1,2 @@ remove_version_from_generated_jar +encoding Thanks, -- Colin Watson [cjwat...@ubuntu.com] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#580840: javatools: use 'readlink -f' instead of realpath
Package: javatools Version: 0.30 Severity: wishlist Couldn't javatools use 'readlink -f' (in coreutils, which is Essential) rather than realpath, and thus avoid an extra dependency? Thanks, -- Colin Watson [cjwat...@debian.org] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Re: Bug#136993: binfmt-support: package javawrapper somewhere
On Tue, Apr 13, 2010 at 08:35:14PM +0200, Niels Thykier wrote: I noticed this very old bug and wondered if it is still relevant. Currently there is a jarwrapper package that uses binfmt-support to allow jar-files to be executed. Almost. It's probably more use to most people than my javawrapper implementation is, I agree. When I wrote javawrapper, it was in the early days of Java and it was still common enough to just build a pile of .class files rather than a .jar file. I wrote javawrapper because I was fed up with concocting the correct syntax to get the Java interpreter to start with a given .class file. This still seems as though it could be useful in some situations. CCing the javatools maintainers; would it be possible to merge some of the functionality of http://www.chiark.greenend.org.uk/~cjwatson/code/javawrapper/javawrapper-1.0.tar.gz into jarwrapper? Thanks, -- Colin Watson [cjwat...@debian.org] __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.