Bug#904055: ghc: Please backport important fix for unregisterised compiler
Source: ghc
Version: 8.2.2-4
Severity: normal
Tags: patch upstream
User: debian-...@lists.debian.org
Usertags: m68k
Hi!
I recently reported a GHC bug upstream which resulted in miscompiled
code when using an unregisterised compiler [1]. Upstream has managed
to track down the issue to GHC producing code that the C compiler
doesn't like. The bug was observed on m68k and sh4 in Debian, but
according to upstream, can affect any other target using an unregisterised
compiler.
The patch can be found in [2], I'm also attaching it. It would be
highly appreciated if the patch could be included in the next upload
so that future uploads of GHC 8.2.x will continue to work on the
affected architectures.
Thanks,
Adrian
> [1] https://ghc.haskell.org/trac/ghc/ticket/15338
> [2]
> https://git.haskell.org/ghc.git/commitdiff/8ec48990fee9e245bb2fe40dc6f65b61b8612157
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: driver: skip -Bsymbolic on unregisterised targets
Trac #15338 is yet another example where -Bsymbolic breaks
semantics of a C program: global variable duplication happens
and unsafePerformIO creates two stdout copies.
.
When -Bsymbolic is not used both C compiler and linker agree
on how global variables are handled. In case of sh4 it consists
on a few assertions:
.
1. global variable is exported from shared library
2. code is referred to this variable via GOT-like mechanism to allow
interposition
3. global variable is present .bss section on an executable
(as an R_*_COPY relocation: symbol contents is copied at executable
startup time)
4. and symbol in executable interposes symbol in shared library.
.
This way both code in shared library and code in executable refer
to a copy of global variable in .bss section of an executable.
.
Unfortunately -Bsymbolic option breaks assumption [2.] and generates
direct references to the symbol. This causes mismatch between
values seen from executable and values seen from shared library code.
.
This change disables '-Bsymbolic' for unregisterised targets.
--- ghc-8.2.2.orig/compiler/main/SysTools.hs
+++ ghc-8.2.2/compiler/main/SysTools.hs
@@ -1741,9 +1741,12 @@ linkDynLib dflags0 o_files dep_packages
---
let output_fn = case o_file of { Just s -> s; Nothing -> "a.out"; }
+unregisterised = platformUnregisterised (targetPlatform dflags)
let bsymbolicFlag = -- we need symbolic linking to resolve
--- non-PIC intra-package-relocations
-["-Wl,-Bsymbolic"]
+-- non-PIC intra-package-relocations for
+-- performance (where symbolic linking works)
+-- See Note [-Bsymbolic assumptions by GHC]
+["-Wl,-Bsymbolic" | not unregisterised]
runLink dflags (
map Option verbFlags
@@ -1800,3 +1803,27 @@ getFrameworkOpts dflags platform
-- reverse because they're added in reverse order from the cmd line:
framework_opts = concat [ ["-framework", fw]
| fw <- reverse frameworks ]
+
+{-
+Note [-Bsymbolic assumptions by GHC]
+
+
+GHC has a few assumptions about interaction of relocations in NCG and linker:
+
+1. -Bsymbolic resolves internal references when the shared library is linked,
+ which is important for performance.
+2. When there is a reference to data in a shared library from the main program,
+ the runtime linker relocates the data object into the main program using an
+ R_*_COPY relocation.
+3. If we used -Bsymbolic, then this results in multiple copies of the data
+ object, because some references have already been resolved to point to the
+ original instance. This is bad!
+
+We work around [3.] for native compiled code by avoiding the generation of
+R_*_COPY relocations.
+
+Unregisterised compiler can't evade R_*_COPY relocations easily thus we disable
+-Bsymbolic linking there.
+
+See related Trac tickets: #4210, #15338
+-}
Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype
Hello! Could we have the current version of the patch applied "as is" even though it does not meet the quality standards yet? Currently, klibc-utils is completely b0rked on sparc64 and anyone dist-upgrading their sparc64 machine will immediately break the machine upon next reboot. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault
Hello Pirate! On 07/18/2018 01:03 PM, John Paul Adrian Glaubitz wrote: >> I ran dpkg-buildpackage with gcc-8 in >> build depends and export CC=gcc-8 in rules. > > gcc-defaults is soon going to switch gcc to gcc-8 by default, so > all you have to do then is wait and ask the wanna-build team to > binNMU the package on all architectures. I don't think your last upload was a good idea as you apparently didn't test your change on all affected architectures. The testsuite still fails on mips64el and ppc64el. Please take advantage of the porterboxes we have in Debian [1] rather than just uploading a new version over and over again to test new changes. Adrian > [1] https://db.debian.org/machines.cgi -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault
On 07/18/2018 12:57 PM, Pirate Praveen wrote: > On 18/07/18 4:20 PM, John Paul Adrian Glaubitz wrote: >> Did you run the testsuite? >> > > testsuite is run during build. Not if you run add "nobench nocheck" to DEB_BUILD_OPTIONS like we do in Debian Ports for some architectures or if you cross-compile a package. It's therefore not taken for granted that the testsuite is run. > I ran dpkg-buildpackage with gcc-8 in > build depends and export CC=gcc-8 in rules. gcc-defaults is soon going to switch gcc to gcc-8 by default, so all you have to do then is wait and ask the wanna-build team to binNMU the package on all architectures. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault
On 07/18/2018 12:30 PM, Pirate Praveen wrote: > On 18/07/18 2:57 PM, John Paul Adrian Glaubitz wrote: >>> So I think it gives a us bit more time until these switch away from gcc-6. >> >> No, it won't because any package that does not build with gcc-8 is considered >> an RC bug. There is no way around this other than fixing the build on gcc-8. > > I tried to build using gcc-8 and it worked. The failures were with gcc-7 > (default gcc). Did you run the testsuite? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault
On 07/18/2018 11:13 AM, Pirate Praveen wrote: > reverse-depends -b gcc-6 > Reverse-Build-Depends > = > * caffe-contrib > * eztrace-contrib > * firefox-esr > * grub2 > * kfreebsd-10 > * linux > * lua-torch-cutorch > * squid3 > * starpu-contrib > > So I think it gives a us bit more time until these switch away from gcc-6. No, it won't because any package that does not build with gcc-8 is considered an RC bug. There is no way around this other than fixing the build on gcc-8. >> If you're seeing an internal compiler error (ICE), you should be >> advised to report the problem to gcc upstream. > > ok. Though on the buildd, this error was not present (only present on > the porterbox). Then it may also just be a kernel bug or hardware issue. Try a different porterbox. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault
On 07/18/2018 10:34 AM, Pirate Praveen wrote: > I was able to build it with gcc-6 installed and 'export CC=gcc-6' added > to debian/rules. > > Is it a good idea to build with gcc-6 in the short term? No. As gcc-6 is planned for removal soonish, it's unfortunately not a good idea. If you're seeing an internal compiler error (ICE), you should be advised to report the problem to gcc upstream. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
On 07/17/2018 06:03 PM, Ximin Luo wrote: > Aron, the next version 1.27.1 is already in binary-NEW so the same issue will > block testing migration again, when that gets accepted. Well, I have to partially take my criticism back. Aron has pointed out on IRC that rustc was not yet removed for mips64el, I thought that had happened but indeed that wasn't the case, just cargo was removed. So, his upload didn't really change anything in this regard. > Earlier you said "Binary only upload from porter is allowed [..]" but I am > not sure the other porters have access to a loongson-3a box. Will you > continue to run builds of new rustc versions on your box? I think that is the > key point here. DSA could blacklist rustc from being built on buildds other than eberlin but I assume they won't agree to applying such a hack. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
On 07/17/2018 04:51 PM, Aron Xu wrote: > I think you are too much defensive, while I don't mean offensive any how. Maybe you shouldn't automatically assume then that the other person doesn't know what they are talking about? > The thing to fix this forever is either of: > 1) Fix the software to make it build on all hardware; > 2) Blacklist the package on hardware that fails to build it. > > You are just blaming blindly here, and this will be my last response > to you on this very specific argument. Neither 1) nor 2) have happened, yet you decided to upload the package to unstable. Did you check back with the rust maintainers? rustc and cargo were already uploaded for mips64el and later removed because of the LLVM bug which made the package FTBFS on the buildds. I don't understand why you just went ahead and uploaded the package without seemingly checking back with the Rust maintainers. (Cross-)building and uploading rustc for a new architecture is not hard. Making the native compuiler actually work properly, on the other hand, is. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
On 07/17/2018 04:43 PM, Aron Xu wrote: > Binary only upload from porter is allowed but not encouraged, it works > similar to an initial upload with source+binary. Yes, I am fully aware how that works. I am a very active porter :). > As said this is temporary, blacklisting is needed and we are > just relaxing Rust maintainers from being worried too much > about migration. And you are missing an important part. The next time a new version of rustc gets upload, the package can end up on the wrong buildd and fail to build from source meaning that testing migration will be stuck. This is what my original mail was about. Unless you actively blacklist rustc from being built on the affected buildds through the buildds local configuration file, your workaround will not work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
On 07/17/2018 04:45 PM, Aron Xu wrote: > Want to add that, on Debian Ports porters are allowed to include some > trivial patches to make the package build/useful, while what I have > done is a binary-only build without any source package change. Aron, with all due respect: 1) You assume I don't know how any of this works even though I have probably done much more in this field in Debian than you. 2) I don't think you understand what the actual problem is here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
On 07/17/2018 02:29 PM, Aron Xu wrote: > As a temporary solution to unblock, I've built the package on a > loongson-3a box and uploaded. It is the same hardware as eberlin.d.o, > which in turn suggests this could be related to Cavium hardware. Unless DSA is willing to blacklist the rustc package on the buildd hardware where it doesn't build (if that's actually the case), this won't work and will cause the package to FTBFS if it hits the wrong buildd. For Debian Ports, this would be acceptable. Don't know about release architectures though. The policy could be different there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures
> On Jul 15, 2018, at 4:53 PM, Ximin Luo wrote: > > Please RM it so other architectures get into Debian testing. We can try again > later when the patch lands in LLVM. No need to reject, the packages already got rejected. Also, if there is a patch for LLVM to backport, I can do that, I have commit access. After that, I would start with mips64el first to avoid the memory issues. Adrian
Bug#881845: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures
On 07/15/2018 12:33 PM, Emilio Pozuelo Monfort wrote: > Ok. I wonder if there are other options for us here. At what point does it run > out of memory? Do you have a log? I don't have a log, unfortunately, because I'm always building on eller or minkus where I cannot use sbuild but just run dpkg-buildpackage directly. I can, however, run the output through "tee" to get a logfile. The error looked very similar to the one we have seen on 32-Bit ARM targets, see [1]. The same workaround used for arm* in the debian/rules file didn't help on mips* though. > BTW mips64el is failing to build on the buildds. It only built there once, on > eberlin. Is that the only mips64el buildd with an FPU? That could explain the > timeouts. No idea. I just know there is apparently still a bug in the atomics code on mips* in LLVM, see [2]. Adrian > [1] https://github.com/rust-lang/rust/issues/45854 > [2] https://bugs.llvm.org/show_bug.cgi?id=32020 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64
On 07/14/2018 06:20 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > Totally understandable. I ACK the change then. If you can create a merge > request on salsa the better, else I'll see to do it myself soon. > > Ideally it would be done in the experimental branch, as we plan to push that > version to unstable real soon now. I'm testing a better fix now. I just realized that JavaScriptCore does not enable ASLR on anything but Darwin x86_64. With the ASLR code that's in there, we might be able to get the code working on sparc64 with a little tweaking. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64
On 06/29/2018 07:32 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > Point is: is this a fix or papering over the real problem? I would like to > know *for sure* that I'm not applying a hack with this patch. In other words: > why it should use 32bits instead of 64? It's a workaround because the 64-bit tagged pointers assume a 48 bit virtual address space as on x86_64 while SPARC has a 52-bit virtual address space. And since the Linux kernel allocates memory from top to bottom, any tagged pointers will get mangled on sparc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#903483: mozjs52: FTBFS on m68k: not supported by build/moz.configure/init.configure
On 07/11/2018 01:11 PM, Simon McVittie wrote:
> On Wed, 11 Jul 2018 at 13:00:53 +0200, John Paul Adrian Glaubitz wrote:
>> On 07/10/2018 05:55 PM, John Paul Adrian Glaubitz wrote:
>>> Yes, I've seen that. I've most likely forgotten the hunk in question,
>>> I will provide an updated patch sonish, also one for riscv64.
>>
>> Attaching an updated patch.
>
> Thanks. Does the result work (at least minimally, e.g. the js52
> interpreter can print("hello, world")) on real m68k hardware?
And here's the demo that it actually works:
root@pacman:/srv/mozjs52# uname -a
Linux pacman 4.15.0-2-m68k #1 Debian 4.15.11-1 (2018-03-20) m68k GNU/Linux
root@pacman:/srv/mozjs52# gjs
gjs> print("hello, world")
hello, world
gjs>
root@pacman:/srv/mozjs52#
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#903483: mozjs52: FTBFS on m68k: not supported by build/moz.configure/init.configure
On 07/12/2018 04:02 AM, Finn Thain wrote: >> I just did a testbuild with the testsuite enabled and it seems all tests >> pass except for one: >> >> FAILED! SSN_pattern - 8 = 8 expected: NaN >> >> So, I guess mozjs52 mostly works on m68k. >> > > That was on vs93.physik.fu-berlin.de, right? Isn't that a Qemu instance? No, I made a local build. I don't make test builds on buildds ;). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#903483: mozjs52: FTBFS on m68k: not supported by build/moz.configure/init.configure
On 07/11/2018 01:11 PM, Simon McVittie wrote:
> On Wed, 11 Jul 2018 at 13:00:53 +0200, John Paul Adrian Glaubitz wrote:
>> On 07/10/2018 05:55 PM, John Paul Adrian Glaubitz wrote:
>>> Yes, I've seen that. I've most likely forgotten the hunk in question,
>>> I will provide an updated patch sonish, also one for riscv64.
>>
>> Attaching an updated patch.
>
> Thanks. Does the result work (at least minimally, e.g. the js52
> interpreter can print("hello, world")) on real m68k hardware?
I just did a testbuild with the testsuite enabled and it seems all tests
pass except for one:
FAILED! SSN_pattern - 8 = 8 expected: NaN
So, I guess mozjs52 mostly works on m68k.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#903483: mozjs52: FTBFS on m68k: not supported by build/moz.configure/init.configure
Control: tags -1 patch
Hi Simon!
On 07/10/2018 05:55 PM, John Paul Adrian Glaubitz wrote:
> Yes, I've seen that. I've most likely forgotten the hunk in question,
> I will provide an updated patch sonish, also one for riscv64.
Attaching an updated patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: John Paul Adrian Glaubitz
Date: Tue, 11 Jul 2018 12:58:00 +0200
Subject: Add support for m68k
Based on the patches sent to Firefox upstream.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325771
Last-Update: 2018-07-11
---
js/src/gc/Heap.h | 2 +-
js/src/jit/AtomicOperations.h| 2 ++
js/src/jsfriendapi.h | 2 +-
mfbt/double-conversion/utils.h | 2 ++
mfbt/tests/TestPair.cpp | 9 +++--
mfbt/tests/TestPoisonArea.cpp| 3 +++
python/mozbuild/mozbuild/configure/constants.py | 2 ++
.../mozbuild/mozbuild/test/configure/test_toolchain_configure.py | 2 ++
8 files changed, 20 insertions(+), 4 deletions(-)
Index: mozjs52-52.3.1/js/src/gc/Heap.h
===
--- mozjs52-52.3.1.orig/js/src/gc/Heap.h
+++ mozjs52-52.3.1/js/src/gc/Heap.h
@@ -282,7 +282,7 @@ struct Cell
protected:
inline uintptr_t address() const;
inline Chunk* chunk() const;
-} JS_HAZ_GC_THING;
+} JS_HAZ_GC_THING __attribute__ ((aligned(4)));
// A GC TenuredCell gets behaviors that are valid for things in the Tenured
// heap, such as access to the arena and mark bits.
Index: mozjs52-52.3.1/js/src/jit/AtomicOperations.h
===
--- mozjs52-52.3.1.orig/js/src/jit/AtomicOperations.h
+++ mozjs52-52.3.1/js/src/jit/AtomicOperations.h
@@ -326,6 +326,8 @@ AtomicOperations::isLockfree(int32_t siz
# include "jit/arm64/AtomicOperations-arm64.h"
#elif defined(JS_CODEGEN_MIPS32) || defined(JS_CODEGEN_MIPS64)
# include "jit/mips-shared/AtomicOperations-mips-shared.h"
+#elif defined(__m68k__)
+# include "jit/none/AtomicOperations-ppc.h"
#elif defined(__ppc__) || defined(__PPC__)
# include "jit/none/AtomicOperations-ppc.h"
#elif defined(__sh__)
Index: mozjs52-52.3.1/js/src/jsfriendapi.h
===
--- mozjs52-52.3.1.orig/js/src/jsfriendapi.h
+++ mozjs52-52.3.1/js/src/jsfriendapi.h
@@ -571,7 +571,7 @@ public:
uint32_t slotInfo;
static const uint32_t FIXED_SLOTS_SHIFT = 27;
-};
+} __attribute__ ((aligned(4)));
/**
* This layout is shared by all native objects. For non-native objects, the
Index: mozjs52-52.3.1/mfbt/double-conversion/utils.h
===
--- mozjs52-52.3.1.orig/mfbt/double-conversion/utils.h
+++ mozjs52-52.3.1/mfbt/double-conversion/utils.h
@@ -69,6 +69,8 @@
#else
#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
#endif // _WIN32
+#elif defined(__m68k__)
+#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
#else
#error Target architecture was not detected as supported by Double-Conversion.
#endif
Index: mozjs52-52.3.1/mfbt/tests/TestPair.cpp
===
--- mozjs52-52.3.1.orig/mfbt/tests/TestPair.cpp
+++ mozjs52-52.3.1/mfbt/tests/TestPair.cpp
@@ -29,14 +29,19 @@ using mozilla::Pair;
static_assert(sizeof(name##_2) == (size), \
"Pair<" #T2 ", " #T1 "> has an unexpected size");
+static constexpr size_t sizemax(size_t a, size_t b)
+{
+ return (a > b) ? a : b;
+}
+
INSTANTIATE(int, int, prim1, 2 * sizeof(int));
-INSTANTIATE(int, long, prim2, 2 * sizeof(long));
+INSTANTIATE(int, long, prim2, sizeof(long) + sizemax(sizeof(int), alignof(long)));
struct EmptyClass { explicit EmptyClass(int) {} };
struct NonEmpty { char mC; explicit NonEmpty(int) {} };
INSTANTIATE(int, EmptyClass, both1, sizeof(int));
-INSTANTIATE(int, NonEmpty, both2, 2 * sizeof(int));
+INSTANTIATE(int, NonEmpty, both2, sizeof(int) + alignof(int));
INSTANTIATE(EmptyClass, NonEmpty, both3, 1);
struct A { char dummy; explicit A(int) {} };
Index: mozjs52-52.3.1/mfbt/tests/TestPoisonArea.cpp
===
--- mozjs52-52.3.1.orig/mfbt/tests/TestPoisonArea.cpp
+++ mozjs52-52.3.1/mfbt/tests/TestPoisonArea.cpp
@@ -133,6 +133,9 @@
#elif defined _ARCH_PPC || defined _ARCH_PWR || defined _ARCH_PWR2
#define RETURN_INSTR 0x4E800020 /* blr */
+#elif defined __m68k__
+#define RETURN_INSTR 0x4E754E75 /* rts; rts */
+
#elif defined __sparc || defined __sparcv
Bug#903483: mozjs52: FTBFS on m68k: not supported by build/moz.configure/init.configure
Hi Simon! On 07/10/2018 04:50 PM, Simon McVittie wrote: > The merge request applied for #880693 doesn't seem to have covered > everything needed to build mozjs52 on m68k: > > checking for a shell... /bin/sh > checking for host system type... > ERROR: Unknown CPU type: m68k Yes, I've seen that. I've most likely forgotten the hunk in question, I will provide an updated patch sonish, also one for riscv64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898985: gdisk: FTBFS on sparc64, testsuite failure due to unaligned access
Hi! On 05/18/2018 11:37 PM, John Paul Adrian Glaubitz wrote: > The attached patch fixes the problem. It was indeed an alignment issue > which was caused by the incorrect use of "#pragma pack ()" throughout > the code as discovered by James Clarke [1]. > (...) > I am also about to send a pull request upstream. My patch has been merged upstream [1]. Could you upload a package with the patch included? Thanks, Adrian > [1] > https://sourceforge.net/p/gptfdisk/code/ci/2fb79510f0452e91b72cefa704268a569b9885e9/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64
Source: qtscript-opensource-src Version: 5.10.1+dfsg-2 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! I just noticed there is an easy workaround to address the Javascript crashes on sparc64 [1]. JavaScriptCore allows one to use a 32-bit JSValue - even on 64-bit systems. In fact, this is done on PPC64 for some reason. I have tried this for sparc64 as well and it seems that the Javascript engine works correctly with that change. Attaching a patch, please include in the next upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Description: Use 32-bit JSValue on sparc64 sparc64 has a very large virtual address space such that 64-bit tagged pointers can become corrupted. Workaround this problem by limiting JSValue to 32 bits. . Author: John Paul Adrian Glaubitz Last-Update: 2018-06-28 --- qtscript-opensource-src-5.10.1+dfsg.orig/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h +++ qtscript-opensource-src-5.10.1+dfsg/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h @@ -960,9 +960,9 @@ #endif #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && !defined(WTF_USE_JSVALUE32_64) -#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X) +#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X) #define WTF_USE_JSVALUE64 1 -#elif CPU(ARM) || CPU(PPC64) +#elif CPU(ARM) || CPU(PPC64) || CPU(SPARC64) #define WTF_USE_JSVALUE32 1 #elif OS(WINDOWS) && COMPILER(MINGW) /* Using JSVALUE32_64 causes padding/alignement issues for JITStubArg
Bug#902100: webkit2gtk: Please update patch fix-ftbfs-m68k.patch
Hi Geert!
On 06/22/2018 12:54 PM, Geert Uytterhoeven wrote:
>>> If anything relies on having a hole in between the two fields, explicit
>>> padding should be added.
>>
>> Well, I don't think we can add this change as this reduces the size of
>> the bitfield. Do you think we can just cut it in half without any issues?
>
> CSSProperty contains:
>
> StylePropertyMetadata m_metadata;
> RefPtr m_value;
>
> StylePropertyMetadata contains:
> uint16_t m_propertyID : 10;
> uint16_t m_isSetFromShorthand : 1;
> uint16_t m_indexInShorthandsVector : 2; // If this property was
> set as part of an ambiguous shorthand, gives the index in the
> shorthands vector.
> uint16_t m_important : 1;
> uint16_t m_implicit : 1; // Whether or not the property was set
> implicitly as the result of a shorthand.
> uint16_t m_inherited : 1;
> uint16_t pad;
>
> So the bitfield is in the first uint16_t, not in a uint32_t (yes, that matters
> on big endian).
But our problem is not endianess-related, is it? Our problem is that the
default alignment on m68k is 16 bits.
> Oops, I did miss StylePropertyMetadata already has padding.
> So the sizes of CSSProperty and SameSizeAsCSSProperty should already match.
>
> To avoid future endianness issues, you still may want to reflect this in
> SameSizeAsCSSProperty:
>
> --- webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp.orig
> 2018-06-22 10:40:49.389060321 +0200
> +++ webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp 2018-06-22
> 12:50:51.005024268 +0200
> @@ -29,7 +29,8 @@
> namespace WebCore {
>
> struct SameSizeAsCSSProperty {
> -uint32_t bitfields;
> +uint16_t bitfields;
> +uint16_t pad;
> void* value;
> };
I'm confused. The endinaness is not our problem at the moment, is it?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902100: webkit2gtk: Please update patch fix-ftbfs-m68k.patch
Hi Geert!
On 06/22/2018 10:44 AM, Geert Uytterhoeven wrote:
>> The patch fix-ftbfs-m68k.patch needs to be updated to fix the FTBFS
>> of webkit2gtk on m68k. I have done that, could you apply the attached
>> patch for the next upload?
>
> Thanks for your patch!
>
>> --- webkit2gtk-2.20.3.orig/Source/WTF/wtf/Platform.h
>> +++ webkit2gtk-2.20.3/Source/WTF/wtf/Platform.h
>> @@ -59,6 +59,11 @@
>> /* CPU() - the target CPU architecture */
>> /* CPU(KNOWN) becomes true if we explicitly support a target CPU. */
>>
>> +/* CPU(M68K) - m68k */
>> +#if defined(__m68k__)
>> +#define WTF_CPU_BIG_ENDIAN 1
>
> #define WTF_CPU_KNOWN 1
>
> The others do that, too, but nothing seems to rely on that.
That might be a leftover. I just refreshed the patch.
>> +#endif
>
>> --- webkit2gtk-2.20.3.orig/Source/WebCore/css/CSSProperty.cpp
>> +++ webkit2gtk-2.20.3/Source/WebCore/css/CSSProperty.cpp
>> @@ -33,7 +33,11 @@ struct SameSizeAsCSSProperty {
>> void* value;
>> };
>>
>> +#if defined(__m68k__)
>> +COMPILE_ASSERT(sizeof(CSSProperty) <= sizeof(SameSizeAsCSSProperty),
>> CSSProperty_should_stay_small);
>> +#else
>> COMPILE_ASSERT(sizeof(CSSProperty) == sizeof(SameSizeAsCSSProperty),
>> CSSProperty_should_stay_small);
>> +#endif
>
> These two structures are not equivalent!
> If anything assumes so, it will crash when dereferencing the pointer.
Hmm. The original patch came from Andreas using this comparison. I just extended
it. I can have a closer look if I find the time.
> The patch below makes them match:
>
> --- webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp.orig
> 2018-06-22 10:40:49.389060321 +0200
> +++ webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp 2018-06-22
> 10:40:52.681053717 +0200
> @@ -29,7 +29,7 @@
> namespace WebCore {
>
> struct SameSizeAsCSSProperty {
> -uint32_t bitfields;
> +uint16_t bitfields;
> void* value;
> };
>
> If anything relies on having a hole in between the two fields, explicit
> padding should be added.
Well, I don't think we can add this change as this reduces the size of
the bitfield. Do you think we can just cut it in half without any issues?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902100: webkit2gtk: Please update patch fix-ftbfs-m68k.patch
Source: webkit2gtk
Version: 2.20.3-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Hello!
The patch fix-ftbfs-m68k.patch needs to be updated to fix the FTBFS
of webkit2gtk on m68k. I have done that, could you apply the attached
patch for the next upload?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: John Paul Adrian Glaubitz
Subject: Fix FTBFS on m68k
Bug-Debian: https://bugs.debian.org/868126
Last-Update: 2017-07-11
Index: webkit2gtk-2.20.3/Source/WTF/wtf/Platform.h
===
--- webkit2gtk-2.20.3.orig/Source/WTF/wtf/Platform.h
+++ webkit2gtk-2.20.3/Source/WTF/wtf/Platform.h
@@ -59,6 +59,11 @@
/* CPU() - the target CPU architecture */
/* CPU(KNOWN) becomes true if we explicitly support a target CPU. */
+/* CPU(M68K) - m68k */
+#if defined(__m68k__)
+#define WTF_CPU_BIG_ENDIAN 1
+#endif
+
/* CPU(MIPS) - MIPS 32-bit and 64-bit */
#if (defined(mips) || defined(__mips__) || defined(MIPS) || defined(_MIPS_) ||
defined(__mips64))
#if defined(_ABI64) && (_MIPS_SIM == _ABI64)
Index: webkit2gtk-2.20.3/Source/WebCore/css/CSSProperty.cpp
===
--- webkit2gtk-2.20.3.orig/Source/WebCore/css/CSSProperty.cpp
+++ webkit2gtk-2.20.3/Source/WebCore/css/CSSProperty.cpp
@@ -33,7 +33,11 @@ struct SameSizeAsCSSProperty {
void* value;
};
+#if defined(__m68k__)
+COMPILE_ASSERT(sizeof(CSSProperty) <= sizeof(SameSizeAsCSSProperty),
CSSProperty_should_stay_small);
+#else
COMPILE_ASSERT(sizeof(CSSProperty) == sizeof(SameSizeAsCSSProperty),
CSSProperty_should_stay_small);
+#endif
CSSPropertyID StylePropertyMetadata::shorthandID() const
{
Index: webkit2gtk-2.20.3/Source/WebCore/dom/ElementRareData.cpp
===
--- webkit2gtk-2.20.3.orig/Source/WebCore/dom/ElementRareData.cpp
+++ webkit2gtk-2.20.3/Source/WebCore/dom/ElementRareData.cpp
@@ -46,6 +46,10 @@ struct SameSizeAsElementRareData : NodeR
void* pointers[8];
};
+#if defined(__m68k__)
+static_assert(sizeof(ElementRareData) <= sizeof(SameSizeAsElementRareData),
"ElementRareData should stay small");
+#else
static_assert(sizeof(ElementRareData) == sizeof(SameSizeAsElementRareData),
"ElementRareData should stay small");
+#endif
} // namespace WebCore
Index: webkit2gtk-2.20.3/Source/WebCore/dom/NodeRareData.cpp
===
--- webkit2gtk-2.20.3.orig/Source/WebCore/dom/NodeRareData.cpp
+++ webkit2gtk-2.20.3/Source/WebCore/dom/NodeRareData.cpp
@@ -38,6 +38,10 @@ struct SameSizeAsNodeRareData {
void* m_pointer[3];
};
+#if defined(__m68k__)
+COMPILE_ASSERT(sizeof(NodeRareData) <= sizeof(SameSizeAsNodeRareData),
NodeRareDataShouldStaySmall);
+#else
COMPILE_ASSERT(sizeof(NodeRareData) == sizeof(SameSizeAsNodeRareData),
NodeRareDataShouldStaySmall);
+#endif
} // namespace WebCore
Index: webkit2gtk-2.20.3/Source/WebCore/dom/ShadowRoot.cpp
===
--- webkit2gtk-2.20.3.orig/Source/WebCore/dom/ShadowRoot.cpp
+++ webkit2gtk-2.20.3/Source/WebCore/dom/ShadowRoot.cpp
@@ -47,7 +47,11 @@ struct SameSizeAsShadowRoot : public Doc
void* slotAssignment;
};
+#if defined(__m68k__)
+COMPILE_ASSERT(sizeof(ShadowRoot) <= sizeof(SameSizeAsShadowRoot),
shadowroot_should_stay_small);
+#else
COMPILE_ASSERT(sizeof(ShadowRoot) == sizeof(SameSizeAsShadowRoot),
shadowroot_should_stay_small);
+#endif
ShadowRoot::ShadowRoot(Document& document, ShadowRootMode type)
: DocumentFragment(document, CreateShadowRoot)
Index: webkit2gtk-2.20.3/Source/WebCore/rendering/style/RenderStyle.cpp
===
--- webkit2gtk-2.20.3.orig/Source/WebCore/rendering/style/RenderStyle.cpp
+++ webkit2gtk-2.20.3/Source/WebCore/rendering/style/RenderStyle.cpp
@@ -63,7 +63,11 @@ struct SameSizeAsBorderValue {
int m_restBits;
};
+#if defined(__m68k__)
+COMPILE_ASSERT(sizeof(BorderValue) <= sizeof(SameSizeAsBorderValue),
BorderValue_should_not_grow);
+#else
COMPILE_ASSERT(sizeof(BorderValue) == sizeof(SameSizeAsBorderValue),
BorderValue_should_not_grow);
+#endif
struct SameSizeAsRenderStyle {
void* dataRefs[7];
@@ -81,7 +85,11 @@ struct SameSizeAsRenderStyle {
#endif
};
+#if defined(__m68k__)
+static_assert(sizeof(RenderStyle) <= sizeof(SameSizeAsRenderStyle),
"RenderStyle should stay small");
+#else
static_assert(sizeof(RenderStyle) == sizeof(SameSizeAsRenderStyle),
"RenderStyle should stay small");
+#endif
RenderStyle& RenderStyle::defaultStyle()
Bug#901571: java-common: Please move powerpcspe to the list of Java 10 architectures
Source: java-common Version: 0.67 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpcspe Hi! As openjdk-10 has been bootstrapped, the default-jdk/jre for powerpcspe should be bumped from 9 to 10 so the default-jre/ jdk becomes installable again. I will take care of openjdk-10 on m68k soonish. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#901410: openjdk-11: Please include sparc64 build fixes
Source: openjdk-11
Version: 11~17-2
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
The two attached patches fix the openjdk-11 build on sparc64:
- JDK-8203301 - https://bugs.openjdk.java.net/browse/JDK-8203301
- JDK-8203787 - https://bugs.openjdk.java.net/browse/JDK-8203787
The latter of the two bugs has already been fixed upstream, the first
patch needs a second reviewer but I assume I can push the fix for the
Flight Recorder regression this week once I have a second ack.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
# HG changeset patch
# User glaubitz
# Date 1528818309 -7200
# Tue Jun 12 17:45:09 2018 +0200
# Node ID 8e5f28a9bab3fe554a2dc2c2e8970258f27d927a
# Parent 04f4e983c2f77d935641f89668aa3c4ccf8bffdd
8203301: Linux-sparc fails to build after JDK-8199712 (Flight Recorder)
diff -r 04f4e983c2f7 -r 8e5f28a9bab3
src/hotspot/cpu/sparc/vm_version_ext_sparc.cpp
--- a/src/hotspot/cpu/sparc/vm_version_ext_sparc.cppTue Jun 12 07:52:30
2018 -0700
+++ b/src/hotspot/cpu/sparc/vm_version_ext_sparc.cppTue Jun 12 17:45:09
2018 +0200
@@ -31,10 +31,13 @@
int VM_Version_Ext::_no_of_threads = 0;
int VM_Version_Ext::_no_of_cores = 0;
int VM_Version_Ext::_no_of_sockets = 0;
+#if defined(SOLARIS)
kid_t VM_Version_Ext::_kcid = -1;
+#endif
char VM_Version_Ext::_cpu_name[CPU_TYPE_DESC_BUF_SIZE] = {0};
char VM_Version_Ext::_cpu_desc[CPU_DETAILED_DESC_BUF_SIZE] = {0};
+#if defined(SOLARIS)
// get cpu information. It takes into account if the kstat chain id
// has been changed and update the info if necessary.
bool VM_Version_Ext::initialize_cpu_information(void) {
@@ -144,6 +147,13 @@
kstat_close(kc);
return true;
}
+#elif defined(LINUX)
+// get cpu information.
+bool VM_Version_Ext::initialize_cpu_information(void) {
+ // Not yet implemented.
+ return false;
+}
+#endif
int VM_Version_Ext::number_of_threads(void) {
initialize_cpu_information();
diff -r 04f4e983c2f7 -r 8e5f28a9bab3
src/hotspot/cpu/sparc/vm_version_ext_sparc.hpp
--- a/src/hotspot/cpu/sparc/vm_version_ext_sparc.hppTue Jun 12 07:52:30
2018 -0700
+++ b/src/hotspot/cpu/sparc/vm_version_ext_sparc.hppTue Jun 12 17:45:09
2018 +0200
@@ -27,8 +27,11 @@
#include "utilities/macros.hpp"
#include "vm_version_sparc.hpp"
+
+#if defined(SOLARIS)
#include
#include
+#endif
#define CPU_INFO"cpu_info"
#define CPU_TYPE"fpu_type"
@@ -45,7 +48,9 @@
static int _no_of_threads;
static int _no_of_cores;
static int _no_of_sockets;
+#if defined(SOLARIS)
static kid_t _kcid;
+#endif
static char _cpu_name[CPU_TYPE_DESC_BUF_SIZE];
static char _cpu_desc[CPU_DETAILED_DESC_BUF_SIZE];
diff -r 04f4e983c2f7 -r 8e5f28a9bab3
src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp
--- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Tue Jun 12
07:52:30 2018 -0700
+++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Tue Jun 12
17:45:09 2018 +0200
@@ -35,6 +35,13 @@
return frame(last_Java_sp(), frame::unpatchable, _anchor.last_Java_pc());
}
+bool JavaThread::pd_get_top_frame_for_profiling(frame* fr_addr, void*
ucontext, bool isInJava) {
+ ucontext_t* uc = (ucontext_t*) ucontext;
+ *fr_addr = frame((intptr_t*)uc->uc_mcontext.mc_i7, frame::unpatchable,
+ (address)uc->uc_mcontext.mc_gregs[MC_PC]);
+ return true;
+}
+
// For Forte Analyzer AsyncGetCallTrace profiling support - thread is
// currently interrupted by SIGPROF
bool JavaThread::pd_get_top_frame_for_signal_handler(frame* fr_addr,
diff -r 04f4e983c2f7 -r 8e5f28a9bab3
src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.hpp
--- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.hpp Tue Jun 12
07:52:30 2018 -0700
+++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.hpp Tue Jun 12
17:45:09 2018 +0200
@@ -85,8 +85,9 @@
_base_of_stack_pointer = sp;
}
- bool pd_get_top_frame_for_signal_handler(frame* fr_addr, void* ucontext,
-bool isInJava);
+ bool pd_get_top_frame_for_signal_handler(frame* fr_addr, void* ucontext,
bool isInJava);
+
+ bool pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool
isInJava);
// These routines are only used on cpu architectures that
// have separate register stacks (Itanium).
# HG changeset patch
# User glaubitz
# Date 1528196521 -7200
# Tue Jun 05 13:02:01 2018 +0200
# Node ID ee87876734c930d1dac3adedbcd5830177621e23
# Parent 4d6a5c267541768d62248d81e64cfeb94eeb8f20
8203787: Hotspot build broken on linux-sparc after 8202377
Reviewed-by: dholmes, eosterlund
diff -r 4d6a5c267541 -r ee87876734c9 src/hotspot/share/opto/library_call.cpp
--- a/src/hotspot/sha
Bug#901269: radeontop FTCBFS: uses the build architecture pkg-config
Hi Helmut! On 06/10/2018 08:55 PM, Helmut Grohne wrote: > Please consider applying the attached patch. Thanks for the patch. Wouldn't it make more sense though to just send the patch upstream? Upstream has a github repository, so opening a pull request should be easy. I can do that if you don't have the time though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#900817: ghc: Please drop obsolete patch powerpcspe-disable-FPU-code.patch
Source: ghc Version: 8.2.2-3 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpcspe Hi! The patch powerpcspe-disable-FPU-code.patch is obsolete and can be dropped, it was based upon wrong assumptions and flawed tests on my side, I have updated the bug report upstream as invalid as well [1]. Just passing "--enable-unregisterised" is actually enough to get GHC to build on PowerPCSPE e500v2. A complete native port would for PowerPCSPE would actually be more involved and would require more than just disabling this singular piece of assembly code, the native code generator (NGC) would have to reworked as well. Adrian > [1] https://ghc.haskell.org/trac/ghc/ticket/12075 --- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#900632: buildd: Please add an option to disable statistics mails
Source: sbuild Version: 0.76.0-1 Severity: normal Hello! buildd has this feature to send statistics mails with the subject line "Build Daemon Statistics". While buildd.conf allows setting the interval for those mails and also configuring a mail address for the recepient of these mails, there is actually no option to disable the statistics mails altogther. Being able to disable those mails would be a welcome feature as having a large zoo of buildds to maintain - like we do in Debian Ports - means that these mails get sent out quite often. And since we haven't really ever made any use of the statistics data so far, the mails just end up being deleted anyway. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881845: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures
On 05/28/2018 08:52 AM, Emilio Pozuelo Monfort wrote: > Any progress on these issues? I see that rust built on mips64el but it now > hangs. And mips/el are still uncompiled. I have not been able to build rustc natively on mips/mipsel because the process always runs out of memory when I try on minkus and eller. I tried the workaround from [1] to disable debuginfo for the standard library but that didn't help either. Adrian > [1] https://github.com/rust-lang/rust/issues/45854 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#900126: libgit2: Testsuite failures on 32-bit targets with 64-bit file offsets
Source: libgit2
Version: 0.23.1-1
Severity: serious
Tags: patch upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: mips
Hi!
Thanks for merging my patch to fix the alignment issue reported
in #900059. There is, however, an additional problem with libgit2
which causes the testsuite to fail on 32-bit systems [1]:
core::buffer..*** stack smashing detected ***:
terminated
3/3 Test #3: libgit2_clar-ssh .***Exception: Child aborted
3.47 sec
Loaded 343 suites:
Started (test status codes: OK='.' FAILURE='F' SKIPPED='S')
Since this issue is not visible in the git master branch of libgit2,
I assumed that this must have been fixed in the meantime. And, in
fact there is pull request which addresses this problem [2].
The fix is trivial and I can confirm it fixes the testsuite for me
on mipsel.
Please include the attached patch in the next upload.
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=libgit2=i386=0.27.0%2Bdfsg.1-0.3=1527339147=0
> [2] https://github.com/libgit2/libgit2/pull/4631
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From fac7eac451f99f722b54e7cd8761926837dd0fa5 Mon Sep 17 00:00:00 2001
From: Andreas Baumann <m...@andreasbaumann.cc>
Date: Thu, 19 Apr 2018 15:21:52 +0200
Subject: [PATCH] fixed stack smashing due to wrong size of struct stat on the
stack on 32-bit systems with 64-bit file descriptor offsets enabled (added
-D_FILE_OFFSET_BITS=64 when compiling the test suite)
---
tests/CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 775f33f2d..e73e7237c 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -9,6 +9,7 @@ SET(CLAR_FIXTURES "${CMAKE_CURRENT_SOURCE_DIR}/resources/")
SET(CLAR_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
ADD_DEFINITIONS(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
ADD_DEFINITIONS(-DCLAR_TMPDIR=\"libgit2_tests\")
+ADD_DEFINITIONS(-D_FILE_OFFSET_BITS=64)
INCLUDE_DIRECTORIES(${CLAR_PATH} ${libgit2_BINARY_DIR}/src)
FILE(GLOB_RECURSE SRC_TEST ${CLAR_PATH}/*/*.c ${CLAR_PATH}/*/*.h)
--
2.17.0
Bug#900059: libgit2: Testsuite failure due to alignment-related crashes
Source: libgit2
Version: 0.23.1-1
Severity: serious
Tags: patch upstream
Justification: fails to build from source
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
libgit2's testsuite fails because of an unaligned access which affects
both mipsel (and mips64el in experimental) as well as sparc64:
Test project /<>/libgit2-0.26.0+dfsg.1/build-debian-release
Start 1: libgit2_clar
Start 2: libgit2_clar-cred_callback
Start 3: libgit2_clar-proxy_credentials_in_url
Start 4: libgit2_clar-proxy_credentials_request
1/4 Test #3: libgit2_clar-proxy_credentials_in_url Passed0.07 sec
2/4 Test #2: libgit2_clar-cred_callback ... Passed0.07 sec
3/4 Test #4: libgit2_clar-proxy_credentials_request ... Passed0.07 sec
4/4 Test #1: libgit2_clar .***Exception: Bus error
60.88 sec
Loaded 338 suites:
Started
I have written a patch to address this issue which I have sent upstream [1]. I
am attaching the patch to this bug report so you can include it with the
Debian package.
However, I think you will have to update the libgit2 version in experimental
anyway as there are still some unrelated testsuite failures in that version
which are not caused by unaligned access.
Adrian
> [1] https://github.com/libgit2/libgit2/pull/4655
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 2ce5a21f46e78cdc3f04cb783e372828494199d5 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Fri, 25 May 2018 01:41:33 +0200
Subject: [PATCH] index: Fix alignment issues in write_disk_entry()
In order to avoid alignment issues on certain target architectures,
it is necessary to use memcpy() when modifying elements of a struct
inside a buffer returned by git_filebuf_reserve().
---
src/index.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/index.c b/src/index.c
index a867547fb..3dcb6dde7 100644
--- a/src/index.c
+++ b/src/index.c
@@ -2605,7 +2605,7 @@ static bool is_index_extended(git_index *index)
static int write_disk_entry(git_filebuf *file, git_index_entry *entry, const
char *last)
{
void *mem = NULL;
- struct entry_short *ondisk;
+ struct entry_short ondisk;
size_t path_len, disk_size;
int varint_len = 0;
char *path;
@@ -2633,9 +2633,7 @@ static int write_disk_entry(git_filebuf *file,
git_index_entry *entry, const cha
if (git_filebuf_reserve(file, , disk_size) < 0)
return -1;
- ondisk = (struct entry_short *)mem;
-
- memset(ondisk, 0x0, disk_size);
+ memset(mem, 0x0, disk_size);
/**
* Yes, we have to truncate.
@@ -2647,30 +2645,32 @@ static int write_disk_entry(git_filebuf *file,
git_index_entry *entry, const cha
*
* In 2038 I will be either too dead or too rich to care about this
*/
- ondisk->ctime.seconds = htonl((uint32_t)entry->ctime.seconds);
- ondisk->mtime.seconds = htonl((uint32_t)entry->mtime.seconds);
- ondisk->ctime.nanoseconds = htonl(entry->ctime.nanoseconds);
- ondisk->mtime.nanoseconds = htonl(entry->mtime.nanoseconds);
- ondisk->dev = htonl(entry->dev);
- ondisk->ino = htonl(entry->ino);
- ondisk->mode = htonl(entry->mode);
- ondisk->uid = htonl(entry->uid);
- ondisk->gid = htonl(entry->gid);
- ondisk->file_size = htonl((uint32_t)entry->file_size);
+ ondisk.ctime.seconds = htonl((uint32_t)entry->ctime.seconds);
+ ondisk.mtime.seconds = htonl((uint32_t)entry->mtime.seconds);
+ ondisk.ctime.nanoseconds = htonl(entry->ctime.nanoseconds);
+ ondisk.mtime.nanoseconds = htonl(entry->mtime.nanoseconds);
+ ondisk.dev = htonl(entry->dev);
+ ondisk.ino = htonl(entry->ino);
+ ondisk.mode = htonl(entry->mode);
+ ondisk.uid = htonl(entry->uid);
+ ondisk.gid = htonl(entry->gid);
+ ondisk.file_size = htonl((uint32_t)entry->file_size);
- git_oid_cpy(>oid, >id);
+ git_oid_cpy(, >id);
- ondisk->flags = htons(entry->flags);
+ ondisk.flags = htons(entry->flags);
if (entry->flags & GIT_IDXENTRY_EXTENDED) {
- struct entry_long *ondisk_ext;
- ondisk_ext = (struct entry_long *)ondisk;
- ondisk_ext->flags_extended = htons(entry->flags_extended &
+ struct entry_long ondisk_ext;
+ memcpy(_ext, , sizeof(struct entry_short));
+ ondisk_ext.flags_extended = htons(entry->flags_extended &
GIT_IDXENTRY_EXTENDED_FLAGS);
- path = ondisk_e
Bug#899038: [Pkg-rust-maintainers] Bug#899038: libgit2 0.27 transition
On 05/18/2018 05:52 PM, Pirate Praveen wrote: > libgit2 0.27 is now available in experimental. Please make sure your package > is ready for this version by the time we upload this package to unstable in > one to two weeks. The severity of this report will be raised to serious once > libgit2 0.27 is uploaded to unstable. You will most likely have to upgrade the libgit2 version to a newer 0.27 first though as there are still many architectures where the testsuite fails. FWIW, I have opened a pull request upstream which should address the alignment issues in libgit2 that affects both sparc64 and some of the mips architectures in Debian [1]. This patch should be included in any case, otherwise you will continue seeing the alignment-related crashes (Bus error). Adrian > [1] https://github.com/libgit2/libgit2/pull/4655 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898983: harfbuzz: FTBFS on sparc64, testsuite failures
Control: reassign -1 freetype It turns out that this issue goes away when building against a newer upstream version of freetype, so it's not a bug in harfbuzz. Looking at the git history for freetype, there is one potential fix which are not part of freetype 2.8.1: commit 3b3cb32dd2340d86d3165961a4bb3dbd44353075 Author: Werner Lemberg <w...@gnu.org> Date: Thu Sep 21 09:03:20 2017 +0200 [truetype] Fix `mmvar' array pointers. Without this change, clang's AddressSanitizer reports many runtime errors due to misaligned addresses. * src/truetype/ttgxvar.c (TT_Get_MM_Var): Use multiples of pointer size for sub-array offsets into `mmvar'. So, just updating to 2.9.1 should already probably fix this bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898985: gdisk: FTBFS on sparc64, testsuite failure due to unaligned access
Control: tags -1 +patch
The attached patch fixes the problem. It was indeed an alignment issue
which was caused by the incorrect use of "#pragma pack ()" throughout
the code as discovered by James Clarke [1].
The problem is that changing the default alignment using "#pragma pack (n)"
to n bytes does not only apply to the struct following the #pragma directive
but the all of the remaining code followed by the statement which results
in all kinds of structs to become unaligned.
According to the gcc documentation, "#pragma pack ()" switches the alignment
back to the previous value which would be the native alignment for a given
architecture. I have just done this and gdisk now builds fine for me
on sparc64 and passes the testsuite.
I am also about to send a pull request upstream.
Thanks,
Adrian
> [1]
> https://sourceforge.net/p/gptfdisk/discussion/939590/thread/eaf714bb/?limit=25#92b4
> [2]
> https://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Structure_002dPacking-Pragmas.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From c9dc1134413e8fa50f63354b78e84179b273896d Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Fri, 18 May 2018 23:30:05 +0200
Subject: [PATCH] Reset struct alignment back to standard after each #pragma
pack (n)
When using #pragma pack (n) to change the alignment for a struct
to n bytes, it is necessary to reset the alignment to the standard
value as otherwise the changed alignment is used throughout the
whole program code which causes other structs to become unaligned.
---
basicmbr.h | 1 +
bsd.h | 1 +
gpt.h | 1 +
mbrpart.h | 1 +
4 files changed, 4 insertions(+)
diff --git a/basicmbr.h b/basicmbr.h
index b809856..21f962e 100644
--- a/basicmbr.h
+++ b/basicmbr.h
@@ -34,6 +34,7 @@ struct TempMBR {
struct MBRRecord partitions[4];
uint16_t MBRSignature;
}; // struct TempMBR
+#pragma pack ()
// Possible states of the MBR
enum MBRValidity {invalid, gpt, hybrid, mbr};
diff --git a/bsd.h b/bsd.h
index ffbe5cc..cbd3588 100644
--- a/bsd.h
+++ b/bsd.h
@@ -89,5 +89,6 @@ class BSDData {
int GetNumParts(void);
GPTPart AsGPT(int i); // Return BSD part. as GPT part.
}; // struct MBRData
+#pragma pack ()
#endif
diff --git a/gpt.h b/gpt.h
index 2d7a1ce..f4bf470 100644
--- a/gpt.h
+++ b/gpt.h
@@ -57,6 +57,7 @@ struct GPTHeader {
uint32_t partitionEntriesCRC;
unsigned char reserved2[GPT_RESERVED];
}; // struct GPTHeader
+#pragma pack ()
// Data in GPT format
class GPTData {
diff --git a/mbrpart.h b/mbrpart.h
index f5892e7..0de365f 100644
--- a/mbrpart.h
+++ b/mbrpart.h
@@ -50,6 +50,7 @@ struct MBRRecord {
uint32_t firstLBA; // see above
uint32_t lengthLBA;
}; // struct MBRRecord
+#pragma pack ()
class MBRPart {
protected:
--
2.17.0
Bug#898981: [Pkg-rust-maintainers] Bug#898981: RM: cargo [mips64el] -- ROM; old binary on not-really-supported arch blocking testing migration
I am doing a fresh bootstrap of rustc_1.25 for mips64el now. Please do not remove cargo on mips64el. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898982: rustc: Please re-add workaround for LLVM bug 11663
For reference, the patch in question is: >From 7e62cd4e886a0e3f08e710e0625a7bed9ccbdf51 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> Date: Tue, 30 Jan 2018 03:00:16 +0100 Subject: [PATCH] Re-add workaround for LLVM bug 11663 --- lib/builtins/int_lib.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/lib/builtins/int_lib.h b/lib/builtins/int_lib.h index 9d09e2dc9..0b6266630 100644 --- a/lib/builtins/int_lib.h +++ b/lib/builtins/int_lib.h @@ -77,6 +77,28 @@ /* Include internal utility function declarations. */ #include "int_util.h" +/* + * Workaround for LLVM bug 11663. Prevent endless recursion in + * __c?zdi2(), where calls to __builtin_c?z() are expanded to + * __c?zdi2() instead of __c?zsi2(). + * + * Instead of placing this workaround in c?zdi2.c, put it in this + * global header to prevent other C files from making the detour + * through __c?zdi2() as well. + * + * This problem has been observed on FreeBSD for sparc64 and + * mips64 with GCC 4.2.1, and for riscv with GCC 5.2.0. + * Presumably it's any version of GCC, and targeting an arch that + * does not have dedicated bit counting instructions. + */ +#if ((defined(__sparc__) && defined(__arch64__)) || defined(__mips_n64) || defined(__mips_o64) || defined(__riscv__) \ + || (defined(_MIPS_SIM) && ((_MIPS_SIM == _ABI64) || (_MIPS_SIM == _ABIO64 +si_int __clzsi2(si_int); +si_int __ctzsi2(si_int); +#define__builtin_clz __clzsi2 +#define__builtin_ctz __ctzsi2 +#endif /* sparc64 || mips_n64 || mips_o64 || riscv */ + COMPILER_RT_ABI si_int __paritysi2(si_int a); COMPILER_RT_ABI si_int __paritydi2(di_int a); > [1] > https://github.com/rust-lang/compiler-rt/commit/7e62cd4e886a0e3f08e710e0625a7bed9ccbdf51.patch -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898985: gdisk: FTBFS on sparc64, testsuite failure due to unaligned access
Source: gdisk Severity: normal Tags: upstream User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! gdisk fails to build from source on sparc64 since the testsuite fails [1]. This is because gdisk itself crashes on sparc64 due to unaligned access: ./gdisk_test.sh [0;32m**SUCCESS**[m Temp disk sucessfully created [0;34m**Testing gdisk binary**[m ./gdisk_test.sh: line 110: 178613 Bus error $GDISK_BIN $TEMP_DISK < [1] > https://buildd.debian.org/status/fetch.php?pkg=gdisk=sparc64=1.0.3-1=1523838466=0 > [2] https://sourceforge.net/p/gptfdisk/discussion/939590/thread/eaf714bb/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898983: harfbuzz: FTBFS on sparc64, testsuite failures
Source: harfbuzz Version: 1.7.6-1+b1 Severity: normal Tags: upstream User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! harfbuzz FTBFS on sparc64 because tests/variations-rvrn.tests fails on sparc64 [1]. I have already reported the issue upstream and it just seems that the test scripts are not properly parsing the output from the testsuite runs: Running tests in ./tests/variations-rvrn.tests ../../../../util/hb-shape fonts/d23d76ea0909c14972796937ba072b5a40c1e257.ttf --verify --variations=FVTT=1 --unicodes U+0072 hb-shape --font-funcs=ft failed. FT funcs: OT funcs: [rvrn_base=0+1529] Actual: Expected: [rvrn_base=0+1529] This has been verified to be broken with harfbuzz from git master as well and I have therefore reported the issue upstream [2]. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=harfbuzz=sparc64=1.7.6-1=1523839301=0 > [2] https://github.com/harfbuzz/harfbuzz/issues/1034 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#880693: mozjs52: Please add support for m68k
On 05/18/2018 10:45 AM, Simon McVittie wrote: > Control: tags -1 pending > > On Fri, 03 Nov 2017 at 22:47:46 +0100, John Paul Adrian Glaubitz wrote: >> The attached patch adds support for m68k. > > Applied in the git repository by jbicha. I know. I was the one who opened the pull request. Includes fixes for ia64, m68k, sh4 and sparc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898982: rustc: Please re-add workaround for LLVM bug 11663
Source: rustc Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! With Rust 1.25, upstream unfortunately accidentally dropped an important workaround in compiler-rt which is necessary for the Rust compiler to work correctly on various targets including mips64, riscv64 and sparc64. The patch can be found in [1]. Please re-add the hunk to "int_lib.h" in compiler-rt, both for Rust 1.25 and 1.26. The workaround is being upstreamed with LLVM, but it has not fully landed there yet [2, 3]. It has been partially fixed, but not completely. Thanks, Adrian > [1] https://github.com/rust-lang/compiler-rt/pull/35/files > [2] https://reviews.llvm.org/D42902 > [3] https://reviews.llvm.org/D43146 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898981: [Pkg-rust-maintainers] Bug#898981: RM: cargo [mips64el] -- ROM; old binary on not-really-supported arch blocking testing migration
On 05/18/2018 10:22 AM, Ximin Luo wrote: > Package: ftp.debian.org > Severity: normal > > Hi, please remove cargo 0.25.0-2 on mips64el as it is blocking testing > migration of cargo 0.26.0-1. Not necessary. I will build cargo manually once rustc_1.25 is uploaded. I have just been waiting for rustc_1.25 to be uploaded to unstable. And, if possible, rustc_1.25 should be uploaded to experimental as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#894159: Bug#898542: qt4-x11: FTBFS with libicu60
Control: tags 898542 +patch
On 05/13/2018 03:35 PM, John Paul Adrian Glaubitz wrote:
openSUSE seems to have a patch [1] we can use that is also already used
in Fedora. I'll test it.
Attaching openSUSE's patch which fixes the problem for me.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: Fabian Vogt <fab...@ritter-vogt.de>
Subject: Fix build with ICU >= 59
ICU >= 59 requires C++11 for its header files.
Qt can't be compiled with -std=c++11 as a whole, so only enable
it for qlocale_icu.cpp.
Index: qt-everywhere-opensource-src-4.8.7/src/corelib/tools/tools.pri
===
--- qt-everywhere-opensource-src-4.8.7.orig/src/corelib/tools/tools.pri
+++ qt-everywhere-opensource-src-4.8.7/src/corelib/tools/tools.pri
@@ -102,7 +102,15 @@ contains(QT_CONFIG, zlib):include($$PWD/
else:include($$PWD/../../3rdparty/zlib_dependency.pri)
contains(QT_CONFIG,icu) {
-SOURCES += tools/qlocale_icu.cpp
+cpp11.name = cpp11
+cpp11.input = SOURCES_CPP11
+cpp11.dependency_type = TYPE_C
+cpp11.variable_out = OBJECTS
+cpp11.output = ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}$${first(QMAKE_EXT_OBJ)}
+cpp11.commands = $${QMAKE_CXX} $(CXXFLAGS) -std=c++11 $(INCPATH) -c ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT}
+QMAKE_EXTRA_COMPILERS += cpp11
+
+SOURCES_CPP11 += tools/qlocale_icu.cpp
DEFINES += QT_USE_ICU
}
Bug#894159: Bug#898542: qt4-x11: FTBFS with libicu60
On 05/13/2018 03:08 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > I have not checked if other distros ship a patch for this (or maybe > they switched to the embedded copy, if applicable). I will at some > point but I can't promise being fast here. openSUSE seems to have a patch [1] we can use that is also already used in Fedora. I'll test it. Adrian > [1] > https://build.opensuse.org/package/view_file/KDE:Qt/libqt4/fix-build-icu59.patch?expand=1 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#898542: qt4-x11: FTBFS with libicu60
Source: qt4-x11 Version: 4:4.8.7+dfsg-16 Severity: serious Justification: fails to build from source Hi! qt4-x11 fails to build from source due to incompatible changes in libicu60: g++ -c -include .pch/release-shared/QtCore -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthr ead -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_A SCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HA VE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3 -DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2 -DQT_HAVE_AVX -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++-64 -I. -I../../include -I../../include/QtCore -I.rc c/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o .obj/release-shared/qlocale_icu.o tools/qlocale_icu.cpp In file included from /usr/include/unicode/uversion.h:30:0, from tools/qlocale_icu.cpp:46: /usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a type; did you mean 'wchar_t'? typedef char16_t UChar; ^~~~ wchar_t In file included from tools/qlocale_icu.cpp:46:0: /usr/include/unicode/uversion.h:167:55: error: 'UChar' does not name a type; did you mean 'QChar'? u_versionFromUString(UVersionInfo versionArray, const UChar *versionString); ^ QChar In file included from /usr/include/unicode/unorm.h:24:0, from /usr/include/unicode/ucol.h:17, from tools/qlocale_icu.cpp:47: /usr/include/unicode/uiter.h:594:44: error: 'UChar' does not name a type; did you mean 'QChar'? uiter_setString(UCharIterator *iter, const UChar *s, int32_t length); ^ QChar I first discovered this issue on m68k [1], but also made a test build on amd64 to make sure this bug is not an artifact. I unfortunately don't have a patch yet to address this issue. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qt4-x11=m68k=4%3A4.8.7%2Bdfsg-16=1526192657=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
On 05/11/2018 11:20 PM, Mike Hommey wrote: >> The only patches we actually need are the one to fix skia on big-endian >> targets >> (I am currently in the process of upstreaming this one) and one tiny patch >> to fix an alignment issue on sparc64. > > For the record, the latter was explicitly rejected. I know. However, the person who wrote it is a security expert (and a friend of mine) and I trust him when he says the patch does not change any behavior or lower the security. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
Hi! With Firefox 60.0 ESR now in experimental, most of the sparc64-related patches are now part of the upstream source. The only patches we actually need are the one to fix skia on big-endian targets (I am currently in the process of upstreaming this one) and one tiny patch to fix an alignment issue on sparc64. Attaching both of them. The skia patch will also fix the build on s390x. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkColorPriv.h --- a/gfx/skia/skia/include/core/SkColorPriv.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/core/SkColorPriv.h Fri Apr 13 10:04:36 2018 +0300 @@ -55,17 +55,10 @@ * Here we enforce this constraint. */ -#ifdef SK_CPU_BENDIAN -#define SK_RGBA_R32_SHIFT 24 -#define SK_RGBA_G32_SHIFT 16 -#define SK_RGBA_B32_SHIFT 8 -#define SK_RGBA_A32_SHIFT 0 -#else -#define SK_RGBA_R32_SHIFT 0 -#define SK_RGBA_G32_SHIFT 8 -#define SK_RGBA_B32_SHIFT 16 -#define SK_RGBA_A32_SHIFT 24 -#endif +#define SK_RGBA_R32_SHIFT 0 +#define SK_RGBA_G32_SHIFT 8 +#define SK_RGBA_B32_SHIFT 16 +#define SK_RGBA_A32_SHIFT 24 #define SkGetPackedA32(packed) ((uint32_t)((packed) << (24 - SK_A32_SHIFT)) >> 24) #define SkGetPackedR32(packed) ((uint32_t)((packed) << (24 - SK_R32_SHIFT)) >> 24) diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkImageInfo.h --- a/gfx/skia/skia/include/core/SkImageInfo.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/core/SkImageInfo.h Fri Apr 13 10:04:36 2018 +0300 @@ -84,7 +84,7 @@ #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A) kN32_SkColorType = kRGBA__SkColorType, #else -#error "SK_*32_SHIFT values must correspond to BGRA or RGBA byte order" +kN32_SkColorType = kBGRA__SkColorType #endif }; diff -r ee1d1bf1dc8a gfx/skia/skia/include/gpu/GrTypes.h --- a/gfx/skia/skia/include/gpu/GrTypes.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/gpu/GrTypes.h Fri Apr 13 10:04:36 2018 +0300 @@ -344,15 +344,13 @@ static const int kGrPixelConfigCnt = kLast_GrPixelConfig + 1; // Aliases for pixel configs that match skia's byte order. -#ifndef SK_CPU_LENDIAN -#error "Skia gpu currently assumes little endian" -#endif #if SK_PMCOLOR_BYTE_ORDER(B,G,R,A) static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig; #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A) static const GrPixelConfig kSkia_GrPixelConfig = kRGBA__GrPixelConfig; #else -#error "SK_*32_SHIFT values must correspond to GL_BGRA or GL_RGBA format." +static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig; +static const GrPixelConfig kSkiaGamma_GrPixelConfig = kSBGRA__GrPixelConfig; #endif /** diff -r ee1d1bf1dc8a gfx/skia/skia/include/private/GrColor.h --- a/gfx/skia/skia/include/private/GrColor.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/private/GrColor.h Fri Apr 13 10:04:36 2018 +0300 @@ -74,7 +74,11 @@ * Since premultiplied means that alpha >= color, we construct a color with * each component==255 and alpha == 0 to be "illegal" */ +#ifdef SK_CPU_BENDIAN +#define GrColor_ILLEGAL 0xFF00 +#else #define GrColor_ILLEGAL (~(0xFF << GrColor_SHIFT_A)) +#endif #define GrColor_WHITE 0x #define GrColor_TRANSPARENT_BLACK 0x0 diff -r ee1d1bf1dc8a gfx/skia/skia/src/core/SkColorData.h --- a/gfx/skia/skia/src/core/SkColorData.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/src/core/SkColorData.h Fri Apr 13 10:04:36 2018 +0300 @@ -32,17 +32,10 @@ * Here we enforce this constraint. */ -#ifdef SK_CPU_BENDIAN -#define SK_BGRA_B32_SHIFT 24 -#define SK_BGRA_G32_SHIFT 16 -#define SK_BGRA_R32_SHIFT 8 -#define SK_BGRA_A32_SHIFT 0 -#else -#define SK_BGRA_B32_SHIFT 0 -#define SK_BGRA_G32_SHIFT 8 -#define SK_BGRA_R32_SHIFT 16 -#define SK_BGRA_A32_SHIFT 24 -#endif +#define SK_BGRA_B32_SHIFT 0 +#define SK_BGRA_G32_SHIFT 8 +#define SK_BGRA_R32_SHIFT 16 +#define SK_BGRA_A32_SHIFT 24 #if defined(SK_PMCOLOR_IS_RGBA) && defined(SK_PMCOLOR_IS_BGRA) #error "can't define PMCOLOR to be RGBA and BGRA" >From 334b650e843cb307397fd627814421873131f0ed Mon Sep 17 00:00:00 2001 From: Michael Karcher <deb...@mkarcher.dialup.fu-berlin.de> Date: Thu, 1 Feb 2018 00:04:36 +0100 Subject: [PATCH] Bug 1434726 - Early startup crash on Linux sparc64 in HashIIDPtrKey --- js/xpconnect/src/XPCMaps.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/js/xpconnect/src/XPCMaps.cpp b/js/xpconnect/src/XPCMaps.cpp index bb99b9f8c034..837d5d78970f 100644 --- a/js/xpconnect/src/XPCMaps.cpp +++ b/js/xpconnect/src/XPCMaps
Bug#898334: python-cogent: Does not honor "nocheck" in DEB_BUILD_OPTIONS
Source: python-cogent Severity: normal Hi! python-cogent currently does not honor it when "nocheck" is passed through DEB_BUILD_OPTIONS meaning that the testsuite is always run even though it is disabled through the build environment. Being able to disable the testsuite is an important feature for package builds that is often required when porting a package to a new architecture or cross-building it and hence python-cogent should properly honor the "nocheck" flag. In this case, it should be enough to guard the code in override_dh_auto_test with "ifeq (,$(filter nocheck, $(DEB_BUILD_OPTIONS))) .. endif". Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#897596: libsecret: Does not honor "nocheck" in DEB_BUILD_OPTIONS
Source: libsecret Version: 0.18.6-1 Severity: normal Hi! libsecret currently does not honor it when "nocheck" is passed through DEB_BUILD_OPTIONS meaning that the testsuite is always run even though it is disabled through the build environment. Being able to disable the testsuite is an important feature for package builds that is often required when porting a package to a new architecture or cross-building it and hence libsecret should properly honor the "nocheck" flag. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#897178: mozjs52: more fixes for ia64
On 05/01/2018 11:33 PM, Jeremy Bicha wrote: On Tue, May 1, 2018 at 5:07 PM, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: Meh, can't just someone go ahead and apply all this, please? Could you go ahead and prepare a merge proposal like you suggested on https://bugs.debian.org/887494 ? The ia64 changes need to be reworked first. It turns out that ia64 behaves differently for mmap() calls which is absolutely not what I would have expected. It seems that Jason's patch works better. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#897178: mozjs52: more fixes for ia64
On 05/01/2018 11:05 PM, James Clarke wrote: >> I have updated the sparc64 support patch to include "defined(__ia64__)" where >> it's still missing which seems to fix the problem for me. Attaching the >> updated sparc64 patch. > > You're still dropping the __aarch64__ from the first patch :) Meh, can't just someone go ahead and apply all this, please? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#897178: mozjs52: more fixes for ia64
On 04/29/2018 03:16 PM, Jason Duerstock wrote:
Attached please find patches to let mozjs52 build on ia64, and (mostly) pass
the test suite.
ia64 currently requires -G0 for linking, but crashes if the current
*MAINT_APPEND strings are
used. Also, the memory allocation fails because the address space randomizer
does not
take into account ia64 memory allocation.
I don't think this is the right approach.
Rather, you need to make sure the allocator gets limited in its use of higher
address space ranges like we are doing on sparc64 and arm64.
I have updated the sparc64 support patch to include "defined(__ia64__)" where
it's still missing which seems to fix the problem for me. Attaching the
updated sparc64 patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
/*
* The JS engine assumes that all allocated pointers have their high 17 bits clear,
* which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__)) || defined(__ia64__)
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
void*
mapMemoryAt(void* desired, size_t length)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
#endif
void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
int fd = -1;
off_t offset = 0;
// The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
if (region == MAP_FAILED)
return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__)) || defined(__ia64__)
const uintptr_t start = UINT64_C(0x0700);
const uintptr_t end = UINT64_C(0x8000);
const uintptr_t step = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
===
--- firefox-esr-52.2.0esr.orig/memory/jemalloc/src/include/jemalloc/internal/mb.h
+++ firefox-esr-52.2.0esr/memory/jemalloc/src/include/j
Bug#897334: openjdk-10: Please include patch to adjust MIN_FLOAT constant on powerpcspe
Source: openjdk-10
Version: 10.0.1+10-3
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpcspe
Hi!
The openjdk-10 (and 9 and 11) builds fail on powerpcspe with:
Compiling 2916 files for java.base
/bin/chmod -f ug+w
/<>/build/jdk/modules/java.base/com/sun/java/util/jar/pack/intrinsic.properties
( /usr/lib/jvm/java-9-openjdk-powerpcspe/bin/java -Xms64M -Xmx1024M
-XX:ThreadStackSize=768 -Duser.language=en -Duser.country=US -Xshare:auto
--limit-modules
java.base,jdk.zipfs,java.compiler.interim,jdk.compiler.interim,jdk.jdeps.interim,jdk.javadoc.interim
--add-modules
java.compiler.interim,jdk.compiler.interim,jdk.jdeps.interim,jdk.javadoc.interim
--module-path /<>/build/buildtools/interim_modules --add-exports
java.base/sun.reflect.annotation=jdk.compiler.interim --add-exports
java.base/jdk.internal.util.jar=jdk.jdeps.interim --add-exports
java.base/jdk.internal.misc=jdk.jdeps.interim -m
jdk.compiler.interim/com.sun.tools.javac.Main -g -source 10 -target 10
--doclint-format html5 -encoding ascii -XDignore.symbol.file=true -Xlint:all
-Werror -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*'
-XDstringConcat=inline --module-source-path
"/<>/build/support/gensrc/*:/<>/src/*/linux/classes:/<>/src/*/unix/classes:/<>/src/*/share/classes"
--module-path "" --system none -implicit:none -classpath
/<>/build/buildtools/depend -Xplugin:"depend
/<>/build/jdk/modules/java.base/_the.java.base_pubapi" -d
/<>/build/jdk/modules -h
/<>/build/support/headers.java.base.tmp
@/<>/build/jdk/modules/java.base/_the.java.base_batch.tmp >
>(/usr/bin/tee
/<>/build/jdk/modules/java.base/_the.java.base_batch.log) 2>
>(/usr/bin/tee
/<>/build/jdk/modules/java.base/_the.java.base_batch.log >&2) || (
exitcode=$? && /bin/cp
/<>/build/jdk/modules/java.base/_the.java.base_batch.log
/<>/build/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log
&& /bin/cp
/<>/build/jdk/modules/java.base/_the.java.base_batch.cmdline
/<>/build/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.cmdline
&& exit $exitcode ) ) && /bin/mv
/<>/build/jdk/modules/java.base/_the.java.base_batch.tmp
/<>/build/jdk/modules/java.base/_the.java.base_batch
compiler/java/jar running ...
/<>/src/java.base/share/classes/java/lang/Float.java:95: error:
floating point number too small
public static final float MIN_VALUE = 0x0.02P-126f; // 1.4e-45f
^
make[4]: Leaving directory '/<>/make/gensrc'
(cd /<>/make/gensrc/ && /usr/bin/make -r -R -I
/<>/make/common SPEC=/<>/build/spec.gmk
MAKE_LOG_FLAGS="" -f Gensrc-java.desktop.gmk -I/<>/make
-I/<>/make/gensrc MODULE=java.desktop )
make[4]: Entering directory '/<>/make/gensrc'
DefineNativeToolchain TOOLCHAIN_DEFAULT
This is akin to the issue that is addressed on alpha with the
alpha-float-const.diff
patch. Looking at the source code in [1], the fix for alpha just uses a
different
representation which calculates the float value instead of using a literal.
Thus,
I think we can address the issue on powerpcspe by using the same hack here for
MIN_NORMAL which can be represented as Float.intBitsToFloat(0x1).
Attaching a debdiff.
Thanks,
Adrian
> [1]
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/share/classes/java/lang/Float.java#l79
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-10-10.0.1+10/debian/patches/powerpcspe-float-const.diff
new/openjdk-10-10.0.1+10/debian/patches/powerpcspe-float-const.diff
--- old/openjdk-10-10.0.1+10/debian/patches/powerpcspe-float-const.diff
1970-01-01 01:00:00.0 +0100
+++ new/openjdk-10-10.0.1+10/debian/patches/powerpcspe-float-const.diff
2018-05-01 15:37:59.734953846 +0200
@@ -0,0 +1,11 @@
+--- a/src/java.base/share/classes/java/lang/Float.java 2018-03-13
17:46:28.0 +0100
b/src/java.base/share/classes/java/lang/Float.java 2018-05-01
15:35:55.626369726 +0200
+@@ -92,7 +92,7 @@
+ * hexadecimal floating-point literal {@code 0x0.02P-126f}
+ * and also equal to {@code Float.intBitsToFloat(0x1)}.
+ */
+-public static final float MIN_VALUE = 0x0.02P-126f; // 1.4e-45f
++public static final float MIN_VALUE = Float.intBitsToFloat(0x1);
+
+ /**
+ * Maximum exponent a finite {@code float} variable may have. It
diff -Nru old/openjdk-10-10.0.1+10/debian/rules
new/openjdk-10-10.0.1+10/debian/rules
--- old/openjdk-10-10.0.1+10/debian/rules 2018-04-21 05:09:19.0
+0200
+++ new/openj
Bug#897068: openjdk-8: Please include patch to fix Zero on ia64
Source: openjdk-8
Version: 8u162-b12-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
As promised in #897066, here's a patch to fix the Zero build
on ia64. Just copy it to debian/patches and add it to the
patch list in debian/rules.
I'm bootstrapping openjdk-8 for ia64 now.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- openjdk/hotspot/src/share/vm/runtime/os.cpp 2018-03-19 19:46:40.0
+0100
+++ openjdk/hotspot/src/share/vm/runtime/os.cpp 2018-04-27 23:22:22.321348018
+0200
@@ -1038,7 +1038,7 @@
// if C stack is walkable beyond current frame. The check for fp() is not
// necessary on Sparc, but it's harmless.
bool os::is_first_C_frame(frame* fr) {
-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
+#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
// On IA64 we have to check if the callers bsp is still valid
// (i.e. within the register stack bounds).
// Notice: this only works for threads created by the VM and only if
Bug#897066: openjdk-8: Please update zero-architectures.diff patch for ia64
Source: openjdk-8
Version: 8u162-b12-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
Please replace zero-architectures.diff with the attached, updated
version which contains the autoconf definitions for ia64.
A hotspot-ia64.diff patch which is necessary to fix Hotspot (Zero)
on ia64 will be following shortly.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
# DP: Add support for zero architectures alpha, m68k, mips*, sh4
--- a/common/autoconf/platform.m4
+++ b/common/autoconf/platform.m4
@@ -42,6 +42,12 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
VAR_CPU_BITS=32
VAR_CPU_ENDIAN=little
;;
+alpha*)
+ VAR_CPU=alpha
+ VAR_CPU_ARCH=alpha
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
arm*)
VAR_CPU=arm
VAR_CPU_ARCH=arm
@@ -60,6 +66,54 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
VAR_CPU_BITS=64
VAR_CPU_ENDIAN=little
;;
+ia64)
+ VAR_CPU=ia64
+ VAR_CPU_ARCH=ia64
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
+m68k)
+ VAR_CPU=m68k
+ VAR_CPU_ARCH=m68k
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=big
+ ;;
+mips)
+ VAR_CPU=mips
+ VAR_CPU_ARCH=mips
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=big
+ ;;
+mipsel)
+ VAR_CPU=mipsel
+ VAR_CPU_ARCH=mipsel
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=little
+ ;;
+mipsn32)
+ VAR_CPU=mipsn32
+ VAR_CPU_ARCH=mipsn32
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=big
+ ;;
+mipsn32el)
+ VAR_CPU=mipsn32el
+ VAR_CPU_ARCH=mipsn32el
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=little
+ ;;
+mips64)
+ VAR_CPU=mips64
+ VAR_CPU_ARCH=mips64
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=big
+ ;;
+mips64el)
+ VAR_CPU=mips64el
+ VAR_CPU_ARCH=mips64el
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
powerpc)
VAR_CPU=ppc
VAR_CPU_ARCH=ppc
@@ -78,6 +126,12 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
VAR_CPU_BITS=64
VAR_CPU_ENDIAN=little
;;
+sh*)
+ VAR_CPU=sh
+ VAR_CPU_ARCH=sh
+ VAR_CPU_BITS=32
+ VAR_CPU_ENDIAN=little
+ ;;
s390)
VAR_CPU=s390
VAR_CPU_ARCH=s390
@@ -377,6 +431,12 @@ AC_DEFUN([PLATFORM_SETUP_LEGACY_VARS],
# ZERO_ARCHDEF is used to enable architecture-specific code
case "${OPENJDK_TARGET_CPU}" in
+alpha*) ZERO_ARCHDEF=ALPHA ;;
+ia64) ZERO_ARCHDEF=IA64 ;;
+m68k) ZERO_ARCHDEF=M68K ;;
+mips|mipsn32|mips64) ZERO_ARCHDEF=MIPS ;;
+mipsel|mipsn32el|mips64el) ZERO_ARCHDEF=MIPSEL ;;
+sh*) ZERO_ARCHDEF=ZERO_SH ;;
ppc) ZERO_ARCHDEF=PPC32 ;;
ppc64) ZERO_ARCHDEF=PPC64 ;;
s390*) ZERO_ARCHDEF=S390 ;;
--- a/common/autoconf/toolchain.m4
+++ b/common/autoconf/toolchain.m4
@@ -1354,6 +1354,8 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_COMPILER_
*)
ZERO_ARCHFLAG="${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}"
esac
+ # use the default for the package builds
+ ZERO_ARCHFLAG=""
TOOLCHAIN_COMPILER_CHECK_ARGUMENTS([$ZERO_ARCHFLAG], [], [ZERO_ARCHFLAG=""])
AC_SUBST(ZERO_ARCHFLAG)
Bug#896903: cmake: FTBFS on sparc64 - WarnUnusedUnusedViaSet and WarnUnusedUnusedViaUnset tests failing
Source: cmake Version: 3.11.1-1 Severity: normal Tags: upstream User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! cmake 3.11.1 FTBFS on sparc64 due to the WarnUnusedUnusedViaSet and WarnUnusedUnusedViaUnset tests failing: 99% tests passed, 2 tests failed out of 488 Label Time Summary: Label1= 0.63 sec*proc (1 test) Label2= 0.63 sec*proc (1 test) Total Test time (real) = 3814.47 sec The following tests FAILED: 178 - WarnUnusedUnusedViaSet (Failed) 179 - WarnUnusedUnusedViaUnset (Failed) Errors while running CTest This has already been reported upstream [1]. Adrian > [1] https://gitlab.kitware.com/cmake/cmake/issues/17941 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults
On 04/25/2018 12:37 AM, James Clarke wrote:
>> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
>> defined(__aarch64__)
>> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
>> (defined(__NetBSD__) || defined(__linux__)))
>
> I don't think you meant to drop the __aarch64__ here (the real commit
> upstream keeps it).
>
>> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
>> defined(__aarch64__)
>> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
>> (defined(__NetBSD__) || defined(__linux__)))
>
> Ditto.
Blergh. Attaching an updated version. Thanks for spotting this.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
/*
* The JS engine assumes that all allocated pointers have their high 17 bits clear,
* which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
void*
mapMemoryAt(void* desired, size_t length)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
#endif
void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
int fd = -1;
off_t offset = 0;
// The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
if (region == MAP_FAILED)
return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
const uintptr_t start = UINT64_C(0x0700);
const uintptr_t end = UINT64_C(0x8000);
const uintptr_t step = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
===
--- firefox-esr-52.2.0esr.orig/memory/jemalloc/src/include/jemalloc/internal/mb
Bug#879589: Combined patch backported from upstream
Hi!
The attached patch was taken from Mozilla's upstream bug report 1326496
and contains the two fixes for both alpha and ia64.
Please drop the incomplete patch Alpha-architecture-is-64-bit.patch from
the package.
On ia64, we also need to lower the optimization level to make the package
build due to issues with the toolchain.
ia64 might also need more adjustments regarding the memory allocator as
it partially suffers from the same problems as arm64 and sparc64 due to
its extended address space. Thus, if mozjs segfaults on ia64, we need
to include ia64 in the list of changes in the sparc64-support.patch.
Adrian
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1326496
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Build fixes for alpha and ia64
Backported upstream build fixes for alpha and ia64,
taken from Mozilla bug 1326496.
See: https://bugzilla.mozilla.org/show_bug.cgi?id=1326496
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Bug-Debian: https://bugs.debian.org/878285
Last-Update: 2018-04-20
--- mozjs52-52.3.1.orig/python/mozbuild/mozbuild/configure/constants.py
+++ mozjs52-52.3.1/python/mozbuild/mozbuild/configure/constants.py
@@ -40,7 +40,7 @@ Kernel = EnumString.subclass(
CPU_bitness = {
'aarch64': 64,
-'Alpha': 32,
+'Alpha': 64,
'arm': 32,
'hppa': 32,
'ia64': 64,
--- mozjs52-52.3.1.orig/testing/mozbase/mozinfo/mozinfo/mozinfo.py
+++ mozjs52-52.3.1/testing/mozbase/mozinfo/mozinfo/mozinfo.py
@@ -15,7 +15,7 @@ import platform
import re
import sys
from .string_version import StringVersion
-
+from ctypes.util import find_library
# keep a copy of the os module since updating globals overrides this
_os = os
@@ -150,7 +150,7 @@ if info['os'] == 'linux':
import errno
PR_SET_SECCOMP = 22
SECCOMP_MODE_FILTER = 2
-ctypes.CDLL("libc.so.6", use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
+ctypes.CDLL(find_library("c"), use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
info['has_sandbox'] = ctypes.get_errno() == errno.EFAULT
else:
info['has_sandbox'] = True
Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults
On 01/17/2018 01:43 PM, John Paul Adrian Glaubitz wrote:
> I can whip up a patch for mozjs52 to add sparc64 support if there is
> a realistic chance for it to be merged. My m68k [3] and sh4 [4] patches for
> mozjs52 are still without any reply, for example.
Attaching said patch. I hope to get around sending a pull request on Salsa
the next days.
The patches should be applied in this order:
- sh4-support.patch (#880692)
- m68k-support.patch (#880693)
- sparc64-support.patch (this bug report)
I'll also send a clean one for alpha and ia64 (#887496).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
/*
* The JS engine assumes that all allocated pointers have their high 17 bits clear,
* which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
void*
mapMemoryAt(void* desired, size_t length)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
#endif
void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
int fd = -1;
off_t offset = 0;
// The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
if (region == MAP_FAILED)
return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
const uintptr_t start = UINT64_C(0x0700);
const uintptr_t end = UINT64_C(0x8000);
const uintptr_t step = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
===
--- firefox-esr-52.2.0esr.orig/memory/jemalloc/src/include/jemalloc/internal/mb.h
+++ firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
@@ -76,7 +76,7 @@ mb_write(void)
: "memory" /* Clobbers. */
);
}
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
JEMALLOC_INLI
Bug#895827: libopenmpi-dev: broken symlink: libpmix.so, and not installed libpmix.so.2.1.1
Package: libopenmpi-dev Version: 3.0.1-5 Followup-For: Bug #895827 User: debian-...@lists.debian.org Usertags: m68k It seems this revert broke openmpi on multiple platforms: checking if user requested external PMIx support(/usr/lib/m68k-linux-gnu/pmix)... yes checking --with-external-pmix value... not found configure: WARNING: Directory /usr/lib/m68k-linux-gnu/pmix/include not found configure: error: Cannot continue tail -v -n \+0 config.log Can you disable PMIx for the affected architectures? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895955: openjdk-10: Please backport build fixes for sparc64
Source: openjdk-10
Version: 10~46-5
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
The attached debdiff adds a patch which fixes the build
openjdk-10 on sparc64. The patch includes the two changes
from upstream:
* 8201616: Hotspot crashes on linux-sparc after 8189941
* 8201480: ISA/CPU feature detection code crashes on linux-sparc
--- openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+++ openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
@@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcont
}
inline static bool checkPollingPage(address pc, address fault, address* stub) {
- if (fault == os::get_polling_page()) {
+ if (os::is_poll_address(fault)) {
*stub = SharedRuntime::get_poll_stub(pc);
return true;
}
---
openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
+++ openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
@@ -56,7 +56,7 @@ public:
}
}
- ~CPUinfo() { os::free((void*)_string); }
+ ~CPUinfo() { free((void*)_string); }
const char* value() const { return _string; }
Please consider including the patch for the next upload.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-10-10~46/debian/patches/series
new/openjdk-10-10~46/debian/patches/series
--- old/openjdk-10-10~46/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ new/openjdk-10-10~46/debian/patches/series 2018-04-17 22:44:49.015596334
+0200
@@ -0,0 +1 @@
+sparc-fixes.diff
diff -Nru old/openjdk-10-10~46/debian/patches/sparc-fixes.diff
new/openjdk-10-10~46/debian/patches/sparc-fixes.diff
--- old/openjdk-10-10~46/debian/patches/sparc-fixes.diff1970-01-01
01:00:00.0 +0100
+++ new/openjdk-10-10~46/debian/patches/sparc-fixes.diff2018-04-17
22:46:55.344492711 +0200
@@ -0,0 +1,28 @@
+Description: Backport two fixes for linux-sparc
+ 8201616: Hotspot crashes on linux-sparc after 8189941
+ 8201480: ISA/CPU feature detection code crashes on linux-sparc
+Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
+Last-Update: 2018-04-17
+
+--- openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+@@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcont
+ }
+
+ inline static bool checkPollingPage(address pc, address fault, address* stub)
{
+- if (fault == os::get_polling_page()) {
++ if (os::is_poll_address(fault)) {
+ *stub = SharedRuntime::get_poll_stub(pc);
+ return true;
+ }
+---
openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
+@@ -56,7 +56,7 @@ public:
+ }
+ }
+
+- ~CPUinfo() { os::free((void*)_string); }
++ ~CPUinfo() { free((void*)_string); }
+
+ const char* value() const { return _string; }
+
diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules
--- old/openjdk-10-10~46/debian/rules 2018-04-15 03:06:41.0 +0200
+++ new/openjdk-10-10~46/debian/rules 2018-04-17 22:47:10.841091851 +0200
@@ -330,6 +330,7 @@
docs-build-workaround.diff \
hotspot-ia64.diff \
8198649.diff \
+ sparc-fixes.diff \
ifeq ($(derivative),Ubuntu)
COMMON_PATCHES += \
Bug#876147: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 02:21 PM, Flavien Bridault wrote: Sorry the patch is ofc meant to be applied on the raw upstream, not after debian patches being applied. I was applying it directly into the git repo so that's why I did not have any issue. If you want to keep trying it this way, I attached a rebased version of the patch that should apply well on top of other. Ok, this works: (sid_s390x-dchroot)glaubitz@zelenka:~/camp/camp-0.8.1/obj-s390x-linux-gnu$ make test Running tests... /usr/bin/ctest --force-new-ctest-process Test project /home/glaubitz/camp/camp-0.8.1/obj-s390x-linux-gnu Start 1: camptest 1/2 Test #1: camptest . Passed0.01 sec Start 2: camptest-qt 2/2 Test #2: camptest-qt .. Passed0.00 sec 100% tests passed, 0 tests failed out of 2 Total Test time (real) = 0.02 sec (sid_s390x-dchroot)glaubitz@zelenka:~/camp/camp-0.8.1/obj-s390x-linux-gnu$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#876147: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 11:58 AM, Flavien Bridault wrote: Weird, it applies well for me on the master branch of the debian repository. Try the patch attached to this email or directly this link https://patch-diff.githubusercontent.com/raw/fw4spl-org/camp/pull/2.diff Tried to apply against the current package in Debian unstable: glaubitz@zelenka:~$ md5sum fix-s390.diff 3fae8e5c44e239e74e2ef14a667126b4 fix-s390.diff glaubitz@zelenka:~$ cd camp/ glaubitz@zelenka:~/camp$ dget -u http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.dsc dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 321 100 3210 0 4346 0 --:--:-- --:--:-- --:--:-- 4397 100 2000 100 20000 0 20750 0 --:--:-- --:--:-- --:--:-- 20750 dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 327 100 3270 0 4570 0 --:--:-- --:--:-- --:--:-- 4605 100 534k 100 534k0 0 4044k 0 --:--:-- --:--:-- --:--:-- 4044k dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.debian.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 331 100 3310 0 4809 0 --:--:-- --:--:-- --:--:-- 4867 100 5272 100 52720 0 63979 0 --:--:-- --:--:-- --:--:-- 63979 dpkg-source: info: extracting camp in camp-0.8.1 dpkg-source: info: unpacking camp_0.8.1.orig.tar.gz dpkg-source: info: unpacking camp_0.8.1-2.debian.tar.xz dpkg-source: info: applying remove_licences_files.patch dpkg-source: info: applying hide_boost_from_qt4moc.patch glaubitz@zelenka:~/camp$ cd camp-0.8.1/ glaubitz@zelenka:~/camp/camp-0.8.1$ patch -p1 < ~/fix-s390x.patch patching file .gitignore patching file include/camp/qt/qtfunction.hpp patching file include/camp/qt/qthelper.hpp patching file include/camp/valuemapper.hpp Hunk #2 FAILED at 40. Hunk #3 succeeded at 96 (offset 2 lines). Hunk #4 succeeded at 126 (offset 2 lines). Hunk #5 succeeded at 139 (offset 2 lines). Hunk #6 succeeded at 156 (offset 2 lines). Hunk #7 succeeded at 183 (offset 2 lines). Hunk #8 succeeded at 205 (offset 2 lines). Hunk #9 succeeded at 234 (offset 2 lines). Hunk #10 succeeded at 250 (offset 2 lines). Hunk #11 succeeded at 279 (offset 2 lines). Hunk #12 succeeded at 326 (offset 2 lines). Hunk #13 succeeded at 345 (offset 2 lines). 1 out of 13 hunks FAILED -- saving rejects to file include/camp/valuemapper.hpp.rej patching file test/arrayproperty.hpp Hunk #2 FAILED at 32. Hunk #3 succeeded at 78 (offset 2 lines). 1 out of 3 hunks FAILED -- saving rejects to file test/arrayproperty.hpp.rej patching file test/qt/propertymapping.cpp Hunk #2 succeeded at 34 with fuzz 2 (offset 2 lines). Hunk #3 succeeded at 47 (offset 2 lines). Hunk #4 succeeded at 95 (offset 2 lines). Hunk #5 succeeded at 106 (offset 2 lines). glaubitz@zelenka:~/camp/camp-0.8.1$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#876147: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 11:16 AM, John Paul Adrian Glaubitz wrote: Meanwhile I commited a fix upstream (https://github.com/fw4spl-org/camp/pull/2) so I would just want to try it before proposing the fix in the package. I'll test that for you on s390x. That patch doesn't apply to the Debian version of camp: glaubitz@zelenka:~/camp/camp-0.8.1$ patch -p1 < ~/fix-s390x.patch patching file .gitignore patching file include/camp/qt/qtfunction.hpp patching file include/camp/qt/qthelper.hpp patching file include/camp/valuemapper.hpp Hunk #2 FAILED at 40. Hunk #3 succeeded at 96 (offset 2 lines). Hunk #4 succeeded at 126 (offset 2 lines). Hunk #5 succeeded at 139 (offset 2 lines). Hunk #6 succeeded at 156 (offset 2 lines). Hunk #7 succeeded at 183 (offset 2 lines). Hunk #8 succeeded at 205 (offset 2 lines). Hunk #9 succeeded at 234 (offset 2 lines). Hunk #10 succeeded at 250 (offset 2 lines). Hunk #11 succeeded at 279 (offset 2 lines). Hunk #12 succeeded at 326 (offset 2 lines). Hunk #13 succeeded at 345 (offset 2 lines). 1 out of 13 hunks FAILED -- saving rejects to file include/camp/valuemapper.hpp.rej patching file test/arrayproperty.hpp Hunk #2 FAILED at 32. Hunk #3 succeeded at 78 (offset 2 lines). 1 out of 3 hunks FAILED -- saving rejects to file test/arrayproperty.hpp.rej patching file test/qt/propertymapping.cpp Hunk #2 succeeded at 34 with fuzz 2 (offset 2 lines). Hunk #3 succeeded at 47 (offset 2 lines). Hunk #4 succeeded at 95 (offset 2 lines). Hunk #5 succeeded at 106 (offset 2 lines). glaubitz@zelenka:~/camp/camp-0.8.1$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#876147: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
Hello! On 04/16/2018 09:15 AM, Flavien Bridault wrote: I sent you a private email twice last week but I did not receive any answer from you so I am afraid they did not reach you. Or maybe you were just away or not available, if that's the case sorry for spaming you... I forgot to follow up on that, sorry. I have been very busy. But from the logs it's also apparent that the package builds fine - including the tests - on sparc64, so I'm not sure the sparc64 porterbox would be of any help. You should preferably get access to an s390x porterbox but I don't have any that I can provide access to. You would have to contact the correct people at Debian for that. See: https://dsa.debian.org/doc/guest-account/ Meanwhile I commited a fix upstream (https://github.com/fw4spl-org/camp/pull/2) so I would just want to try it before proposing the fix in the package. I'll test that for you on s390x. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895193: transition: openmpi
On 04/11/2018 10:53 AM, Alastair McKinstry wrote: As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a problem; it had been dropped upstream because of an unknown bug, now fixed). Oh, really, they fixed that? I already had given up hopes and therefore ignored the thread on github out of frustration. The other non-release archs were failing due to missing dependencies: in particular java support (not used by any package in stable/testing) and pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+ nodes, which is unlikely to be needed). I am working on fixing the remaining OpenJDK issues. I'm an upstream committer in the OpenJDK project, so I can commit all changes myself. So, the expected changes to mpi-defaults will no longer be needed. Yay, thanks so much for this! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895300: cargo: Please disable incremental-by-default on sparc64
Hi!
The attached patch disables incremental builds on sparc64 and resolves
the issue for me. It would be good if the patch could be applied for
the time being until we have investigated what causes the issues with
incremental builds on sparc64.
I will definitely test newer upstream versions of Rust which have received
some improvements for incremental builds and as well as report a bug
report upstream if the issue persists.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Disable incremental builds on sparc64
Incremental builds are currently unreliable on sparc64,
disable them by default for the time being.
Last-Update: 2018-04-09
--- cargo-0.25.0.orig/src/cargo/core/manifest.rs
+++ cargo-0.25.0/src/cargo/core/manifest.rs
@@ -633,6 +633,9 @@ impl Profile {
debuginfo: Some(2),
debug_assertions: true,
overflow_checks: true,
+ #[cfg(target_arch = "sparc64")]
+incremental: false,
+ #[cfg(not(target_arch = "sparc64"))]
incremental: true,
..Profile::default()
}
Bug#895297: gkrellm2-cpufreq FTCBFS: upstream makefile issues
Hi Helmut! On 04/09/2018 04:41 PM, Helmut Grohne wrote: The attached patch fixes all of these issues and makes gkrellm2-cpufreq cross build successfully. It also causes a -dbgsym package to be generated as stripping is now deferred to dh_strip. Please consider applying it. Thanks for addressing this issue. I don't know how active upstream is these days for this particular package, but I will try to forward your patch. In any case, I will apply your changes to the package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895300: cargo: Please disable incremental-by-default on sparc64
Source: cargo Version: 0.25.0-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! The change to enable incremental builds by default unfortunately currently breaks Rust builds on sparc64. I have observed this problem for building both Firefox and the Rust compiler and it looks like this [1]: Compiling cmake v0.1.29 Running `/usr/bin/rustc --crate-name cmake vendor/cmake/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on -C metadata=e1cd2a47defb4d9a -C extra-filename=-e1cd2a47defb4d9a --out-dir '/<>/rustc-1.25.0+dfsg1/build/bootstrap/debug/deps' -L 'dependency=/<>/rustc-1.25.0+dfsg1/build/bootstrap/debug/deps' --extern 'cc=/<>/rustc-1.25.0+dfsg1/build/bootstrap/debug/deps/libcc-9169eb827816c87c.rlib' --cap-lints warn -Cdebuginfo=2` error: incremental compilation: could not create session directory lock file: No such process (os error 3) error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.24.1 running on sparc64-unknown-linux-gnu note: run with `RUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'src/librustc/session/mod.rs:665: Trying to get session directory from IncrCompSession `NotInitialized`', src/librustc/session/mod.rs:1141:26 stack backtrace: 0: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 1: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 2: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 3: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 4: std::panicking::rust_panic_with_hook 5: rust_metadata_rustc_f5b4f956815e4c315eb00c57eaa07f5b 6: 7: rust_metadata_rustc_f5b4f956815e4c315eb00c57eaa07f5b 8: rustc::session::bug_fmt 9: rustc::session::Session::incr_comp_session_dir 10: rustc_incremental::persist::load::load_dep_graph 11: 12: rustc_driver::driver::compile_input 13: rustc_driver::run_compiler 14: 15: 16: __rust_maybe_catch_panic 17: 18: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 19: rust_metadata_std_e973fcbcfde4db1b7f5619ab17536071 20: error: Could not compile `build_helper`. I have not yet figured out what the problem is, but I can work-around the issue by setting CARGO_INCREMENTAL=0 in the build environment. Would it be possible to disable incremental builds on sparc64 by default until this issue has been resolved? I assume that the problem is that the incremental builds are not 100% thread-safe yet and might cause issues on SPARC servers which often have many CPUs available. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895060: openjdk-11: Please drop obsolete patch hotspot-disable-jvmtihtml.diff
Source: openjdk-11 Version: 11~7-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k Hi! The patch hotspot-disable-jvmtihtml.diff doesn't apply anymore, please remove it completely. It also seems we don't need it anymore at all, but I am checking openjdk-10 (and -11) on m68k now to see whether we need another patch. I will open another bug report for that if necessary. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#876147: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/06/2018 02:34 PM, Flavien Bridault wrote: Okay thanks a lot for your quick answer ! Maybe I misunderstood the excuses https://qa.debian.org/excuses.php?package=camp, but the build failure on s390x looks very similar at the endianess issue we have on sparc64, so this should also solves that. If not I will contact s390x folks. We can give a try non-theless. Please send me a private email with your desired username. Encrypt the mail using my GPG below (you can find in the Debian GPG keyring). Use your key that was signed by the Debian Developer you mentioned. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#876147: [Debian-med-packaging] Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
Hi Flavien! On 04/06/2018 02:24 PM, Flavien Bridault wrote: I already posted the information but it seems no one got it. My GPG key has been signed by a Debian Developer, would it be possible to gain access to the sparc64 porterbox now ? Yes, we can create an account for you on the sparc64 porterbox. camp has been removed from testing because of this bug and this prevents fw4spl from being updated, I would like to fix this asap. A package failing to build from source on sparc64 does not have any influence on testing migration. In fact, the package builds fine on sparc64 at the moment so I'm not sure a sparc64 porterbox would help you. We can still give you access to the sparc64 porterbox if the problem is big-endian-specific, but I guess access to an s390x machine would be better. Although for that you would have to contact the s390x folk. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#886886: ros-bond-core: FTBFS on m68k: timeout generating Python from MSG bond/Constants
Hi Jochen! On 04/01/2018 01:23 PM, Jochen Sprickerhof wrote: > did you have time to look into this already? Meanwhile ros-bond-core build > successfully again, so I would propose to either assign this to qemu-m68k or > close it. Feel free to close this bug. It's most likely a QEMU issue that has been fixed. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#889848: marked as done (ruby2.5: Please include upstream patch to fix FTBFS on ia64)
We currently have a broken binutils on ia64, so ruby2.5 most likely got
miscompiled.
Please ignore this crash.
Adrian
On Apr 1, 2018, at 6:11 AM, Antonio Terceiro <terce...@debian.org> wrote:
>> Date: Wed, 07 Feb 2018 22:09:23 +0100
>> From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
>> To: Debian Bug Tracking System <sub...@bugs.debian.org>
>> Subject: ruby2.5: Please include upstream patch to fix FTBFS on ia64
>> Message-ID:
>> <151803776351.18433.12367250620839726943.report...@z6.physik.fu-berlin.de>
>> X-Mailer: reportbug 7.1.8
>>
>> Source: ruby2.5
>> Version: 2.5.0-4
>> Severity: normal
>> Tags: patch
>> User: debian-i...@lists.debian.org
>> Usertags: ia64
>>
>> Hello!
>>
>> ruby2.5 currently FTBFS on ia64 with:
>>
>> gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat
>> -Werror=format-security -fPIC -D_FORTIFY_SOURCE=2 -fno-strict-overflow
>> -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -Wdate-time
>> -D_FORTIFY_SOURCE=2 -I. -I.ext/include/ia64-linux-gnu -I./include -I.
>> -I./enc/unicode/10.0.0 -o cont.o -c cont.c
>> cont.c: In function 'cont_save_machine_stack':
>> cont.c:478:7: error: 'rb_thread_t {aka struct rb_thread_struct}' has no
>> member named 'machine'
>> th->machine.register_stack_end = rb_ia64_bsp();
>> ^~
>> cont.c:502:50: error: 'rb_thread_t {aka struct rb_thread_struct}' has no
>> member named 'machine'
>> size = cont->machine.register_stack_size =
>> th->machine.register_stack_end - th->machine.register_stack_start;
>> ^~
>> cont.c:502:83: error: 'rb_thread_t {aka struct rb_thread_struct}' has no
>> member named 'machine'
>> size = cont->machine.register_stack_size =
>> th->machine.register_stack_end - th->machine.register_stack_start;
>>
>> ^~
>> cont.c:503:42: error: 'rb_thread_t {aka struct rb_thread_struct}' has no
>> member named 'machine'
>> cont->machine.register_stack_src = th->machine.register_stack_start;
>> ^~
>> Makefile:375: recipe for target 'cont.o' failed
>>
>> This has already been fixed upstream [1]. I am attaching the backported patch
>> for ruby2.5. It would be nice if it could be included in the next upload.
>
> Well, it seems that the issue is deeper than getting it to build. it segfaults
> beatifully while building documentation ... unfortunately I don't have the
> cycles to go after this, but I will happily take a tested patch (which should
> also be sent upstream, of course).
>
> Generating RDoc documentation
> ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext --
> --disable-gems "./bin/rdoc" --root "." --page-dir "./doc" --encoding=UTF-8
> --no-force-update --all --ri --op ".ext/rdoc" "."
> Parsing sources...
> 0% [ 1/871] /<>/doc/NEWS-1.8.7
> 0% [ 2/871] /<>/doc/NEWS-1.9.1
> 0% [ 3/871] /<>/doc/NEWS-1.9.2
> 0% [ 4/871] /<>/doc/NEWS-1.9.3
> 0% [ 5/871] /<>/doc/NEWS-2.0.0
> 0% [ 6/871] /<>/doc/NEWS-2.1.0
> 0% [ 7/871] /<>/doc/NEWS-2.2.0
> 0% [ 8/871] /<>/doc/NEWS-2.3.0
> 1% [ 9/871] /<>/doc/NEWS-2.4.0
> 1% [10/871] /<>/doc/contributing.rdoc
> 1% [11/871] /<>/doc/contributors.rdoc
> 1% [12/871] /<>/doc/dtrace_probes.rdoc
> 1% [13/871] /<>/doc/extension.ja.rdoc
> 1% [14/871] /<>/doc/extension.rdoc
> 1% [15/871] /<>/doc/globals.rdoc
> 1% [16/871] /<>/doc/keywords.rdoc
> 1% [17/871] /<>/doc/maintainers.rdoc
> 2% [18/871] /<>/doc/marshal.rdoc
> 2% [19/871] /<>/doc/regexp.rdoc
> 2% [20/871] /<>/doc/security.rdoc
> 2% [21/871] /<>/doc/standard_library.rdoc
> 2% [22/871] /<>/doc/syntax.rdoc
> 2% [23/871] /<>/doc/syntax/assignment.rdoc
> 2% [24/871]
> ...d/ruby2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/calling_methods.rdoc
> 2% [25/871]
> ...by2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/control_expressions.rdoc
> 2% [26/871] /<>/doc/syntax/exceptions.rdoc
> 3% [27/871] /<>/doc/syntax/literals.rdoc
> 3% [28/871] /<>/doc/syntax/methods.rdoc
> 3% [29/871] /<>/doc/syntax/miscellaneous.rdoc
> 3% [30/871]
> ...by2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/modules_and_classes.rdoc
> 3% [31/871] /<>/doc/syntax/precedence.rdoc
> 3% [32/871] /<>/doc/syntax/refinements.rdo
Bug#879589: mozjs52 FTBFS on alpha; misdetected arch bitsize, etc.
Package: src:mozjs52 Followup-For: Bug #879589 Hi! The approach to use a hardcoded list for the libc name is not ideal. We should rather use the approach I used in Firefox upstream which uses find_library to get the proper name of the C library [1]. I will now take care of mozjs52 and perform an NMU to fix it on all the architectures where it's currently FTBFS. Adrian > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1326496 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#894064: openjdk-11: Please add patch for ia64 support
Source: openjdk-11
Version: 11~5-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
The attached patch fixes OpenJDK-11 for ia64 (Zero). Please consider
applying it for the next upload.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-11-11~5/debian/patches/hotspot-ia64.diff
new/openjdk-11-11~5/debian/patches/hotspot-ia64.diff
--- old/openjdk-11-11~5/debian/patches/hotspot-ia64.diff1970-01-01
01:00:00.0 +0100
+++ new/openjdk-11-11~5/debian/patches/hotspot-ia64.diff2018-03-26
02:41:36.451934089 +0200
@@ -0,0 +1,26 @@
+--- a/src/hotspot/share/runtime/os.cpp 2018-03-05 14:18:55.0 +0100
b/src/hotspot/share/runtime/os.cpp 2018-03-26 02:26:44.607427867 +0200
+@@ -1145,7 +1145,7 @@
+ // if C stack is walkable beyond current frame. The check for fp() is not
+ // necessary on Sparc, but it's harmless.
+ bool os::is_first_C_frame(frame* fr) {
+-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
++#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
+ // On IA64 we have to check if the callers bsp is still valid
+ // (i.e. within the register stack bounds).
+ // Notice: this only works for threads created by the VM and only if
+--- a/make/autoconf/platform.m42018-03-05 14:18:55.0 +0100
b/make/autoconf/platform.m42018-03-26 02:28:39.067699053 +0200
+@@ -60,6 +60,12 @@
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
++ia64)
++ VAR_CPU=ia64
++ VAR_CPU_ARCH=ia64
++ VAR_CPU_BITS=64
++ VAR_CPU_ENDIAN=little
++ ;;
+ m68k)
+ VAR_CPU=m68k
+ VAR_CPU_ARCH=m68k
diff -Nru old/openjdk-11-11~5/debian/rules new/openjdk-11-11~5/debian/rules
--- old/openjdk-11-11~5/debian/rules2018-03-22 00:43:24.0 +0100
+++ new/openjdk-11-11~5/debian/rules2018-03-26 03:14:41.436735774 +0200
@@ -319,6 +319,7 @@
8199220.diff \
machine-flag.diff \
zero-x32.diff \
+ hotspot-ia64.diff \
# m68k-support.diff \
Bug#894062: openjdk-10: Please add patch for ia64 support
Source: openjdk-10
Version: 10~46-2
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
The attached patch fixes OpenJDK-10 for ia64 (Zero). Please consider
applying it for the next upload.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-10-10~46/debian/patches/hotspot-ia64.diff
new/openjdk-10-10~46/debian/patches/hotspot-ia64.diff
--- old/openjdk-10-10~46/debian/patches/hotspot-ia64.diff 1970-01-01
01:00:00.0 +0100
+++ new/openjdk-10-10~46/debian/patches/hotspot-ia64.diff 2018-03-26
02:41:36.451934089 +0200
@@ -0,0 +1,26 @@
+--- a/src/hotspot/share/runtime/os.cpp 2018-03-05 14:18:55.0 +0100
b/src/hotspot/share/runtime/os.cpp 2018-03-26 02:26:44.607427867 +0200
+@@ -1145,7 +1145,7 @@
+ // if C stack is walkable beyond current frame. The check for fp() is not
+ // necessary on Sparc, but it's harmless.
+ bool os::is_first_C_frame(frame* fr) {
+-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
++#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
+ // On IA64 we have to check if the callers bsp is still valid
+ // (i.e. within the register stack bounds).
+ // Notice: this only works for threads created by the VM and only if
+--- a/make/autoconf/platform.m42018-03-05 14:18:55.0 +0100
b/make/autoconf/platform.m42018-03-26 02:28:39.067699053 +0200
+@@ -60,6 +60,12 @@
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
++ia64)
++ VAR_CPU=ia64
++ VAR_CPU_ARCH=ia64
++ VAR_CPU_BITS=64
++ VAR_CPU_ENDIAN=little
++ ;;
+ m68k)
+ VAR_CPU=m68k
+ VAR_CPU_ARCH=m68k
diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules
--- old/openjdk-10-10~46/debian/rules 2018-03-15 14:31:57.0 +0100
+++ new/openjdk-10-10~46/debian/rules 2018-03-26 02:46:26.974332045 +0200
@@ -327,6 +327,7 @@
mips-sigset.diff \
disable-doclint-by-default.diff \
make-4.2-workaround.diff \
+ hotspot-ia64.diff \
ifeq ($(derivative),Ubuntu)
COMMON_PATCHES += \
Bug#894054: radeontop: New upstream version, needed for VEGA support.
Hi! On 03/26/2018 05:47 AM, Boyd Stephen Smith Jr. wrote: > I have a VEGA card and the latest radeontop from Debian does not recognize the > card. Upstream indicates that a newer version would at least partially > resolve > the issue: https://github.com/clbr/radeontop/issues/57 There is currently no newer upstream available, upstream lists 1.0 as the latest version, see [1]. I cannot upload a new upstream version before the upstream developer tags it. Please ask upstream to release a new upstream release first. Adrian > [1] https://github.com/clbr/radeontop/releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#894011: java-common: Please move ia64 to the list of Java 9 architectures
Source: java-common Version: 0.62 Severity: normal User: debian-i...@lists.debian.org Usertags: ia64 Hi! With OpenJDK9 bootstrapped for ia64, it's now possible to set it as the default JDK for ia64. Thus, please move ia64 from the list of Java 5 architectures to the list of Java 9 architectures. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#894001: openjdk-9: 9.0.4+12-2
Source: openjdk-9
Version: 9.0.4+12-2
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
The attached patch contains changes to the openjdk-9 package which
make the package build on ia64. Please apply. I will upstream the
changes as well and provide patches for the openjdk-10 and openjdk-11
packages in Debian.
I have cross-compiled openjdk-9 for ia64 with the patches applied and
just uploaded it to the Debian Ports FTP archive.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-9-9.0.4+12/debian/patches/ia64-zero.diff
new/openjdk-9-9.0.4+12/debian/patches/ia64-zero.diff
--- old/openjdk-9-9.0.4+12/debian/patches/ia64-zero.diff1970-01-01
01:00:00.0 +0100
+++ new/openjdk-9-9.0.4+12/debian/patches/ia64-zero.diff2018-03-25
09:48:18.872892026 +0200
@@ -0,0 +1,11 @@
+--- a/hotspot/src/share/vm/runtime/os.cpp 2018-01-22 16:19:02.0
+0100
b/hotspot/src/share/vm/runtime/os.cpp 2018-03-25 05:03:41.005419666
+0200
+@@ -1075,7 +1075,7 @@
+ // if C stack is walkable beyond current frame. The check for fp() is not
+ // necessary on Sparc, but it's harmless.
+ bool os::is_first_C_frame(frame* fr) {
+-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
++#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
+ // On IA64 we have to check if the callers bsp is still valid
+ // (i.e. within the register stack bounds).
+ // Notice: this only works for threads created by the VM and only if
diff -Nru old/openjdk-9-9.0.4+12/debian/patches/zero-architectures.diff
new/openjdk-9-9.0.4+12/debian/patches/zero-architectures.diff
--- old/openjdk-9-9.0.4+12/debian/patches/zero-architectures.diff
2017-02-26 19:03:10.0 +0100
+++ new/openjdk-9-9.0.4+12/debian/patches/zero-architectures.diff
2018-03-25 09:49:29.247513632 +0200
@@ -17,7 +17,7 @@
arm*)
VAR_CPU=arm
VAR_CPU_ARCH=arm
-@@ -54,6 +60,48 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
+@@ -54,6 +60,54 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
VAR_CPU_BITS=64
VAR_CPU_ENDIAN=little
;;
@@ -63,6 +63,12 @@
+ VAR_CPU_BITS=64
+ VAR_CPU_ENDIAN=little
+ ;;
++ia64)
++ VAR_CPU=ia64
++ VAR_CPU_ARCH=ia64
++ VAR_CPU_BITS=64
++ VAR_CPU_ENDIAN=little
++ ;;
powerpc)
VAR_CPU=ppc
VAR_CPU_ARCH=ppc
diff -Nru old/openjdk-9-9.0.4+12/debian/rules
new/openjdk-9-9.0.4+12/debian/rules
--- old/openjdk-9-9.0.4+12/debian/rules 2018-03-16 11:25:51.0 +0100
+++ new/openjdk-9-9.0.4+12/debian/rules 2018-03-25 10:33:54.814132453 +0200
@@ -344,6 +344,7 @@
disable-doclint-by-default.diff \
hotspot-fix-alpha-orderaccess.diff \
make-4.2-workaround.diff \
+ ia64-zero.diff \
ifeq ($(derivative),Ubuntu)
COMMON_PATCHES += \
Bug#893833: openjdk-10: Please drop obsolete patch hotspot-disable-jvmtihtml.diff
Source: openjdk-10 Version: 10~46-2 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k Hi! The patch hotspot-disable-jvmtihtml.diff doesn't apply anymore, please remove it completely. It also seems we don't need it anymore at all, but I am checking openjdk-10 (and -11) on m68k now to see whether we need another patch. I will open another bug report for that if necessary. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff new/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff --- old/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff 2017-11-19 14:58:26.0 +0100 +++ new/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff 1970-01-01 01:00:00.0 +0100 @@ -1,10 +0,0 @@ a/src/hotspot/make/gensrc/GensrcJvmti.gmk.orig 2017-05-11 14:11:42.0 +0200 -+++ b/src/hotspot/make/gensrc/GensrcJvmti.gmk 2017-06-06 16:38:26.990673621 +0200 -@@ -103,7 +103,6 @@ - -PARAM interface jvmti -PARAM trace Trace)) - $(eval $(call SetupJvmtiGeneration, jvmtiEnv.hpp, jvmtiHpp.xsl)) - $(eval $(call SetupJvmtiGeneration, jvmti.h, jvmtiH.xsl)) --$(eval $(call SetupJvmtiGeneration, jvmti.html, jvmti.xsl)) - $(eval $(call SetupJvmtiGeneration, jvmtiEnvStub.cpp, jvmtiEnv.xsl)) - - JVMTI_BC_SRCDIR := $(HOTSPOT_TOPDIR)/src/share/vm/interpreter diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules --- old/openjdk-10-10~46/debian/rules 2018-03-15 14:31:57.0 +0100 +++ new/openjdk-10-10~46/debian/rules 2018-03-23 00:50:01.171199985 +0100 @@ -365,11 +365,6 @@ alpha-float-const.diff endif -ifneq (,$(filter $(DEB_HOST_ARCH), m68k)) - COMMON_PATCHES += \ - hotspot-disable-jvmtihtml.diff -endif - ifneq (,$(filter $(DEB_HOST_ARCH), kfreebsd-amd64 kfreebsd-i386)) COMMON_PATCHES += \ kfreebsd-support-jdk.diff \
Bug#891982: xchat: Intent to file removal bug
On 03/04/2018 05:26 PM, Jeremy Bicha wrote: > 1. "in the maintainer's opinion, makes the package unsuitable for release" [1] Didn't you say there is no longer an upstream maintainer? Please note we have had similar cases with other packages where the maintainer of a forked project or the original project was attacking the fork or vice versa. This alone isn't an argument. > 2. "introduces a security hole on systems where you install the packages" [2] That's why I was specifically asking for a particular issue you are seeing with the bug. Again, the maintainer of the fork ranting alone is not a justification enough. > 3. Multiple copies of the same code base [3] There are so many other multiple copies of code in Debian (i.e. xemacs21) that this single leaf package doesn't really make a difference. > 4. Although not specified in Debian Policy, I believe the Debian > Project generally does not wish to see "unmaintainable" software in > Debian, especially if there are maintainable alternatives. I don't see how this package is unmaintainable. Do you think that Gianfranco is not up to the job to take care of a simple package like xchat? Are we now questioning the skills of each other in public? > 5. I'm definitely nitpicking here, but the new Debian maintainer did > not completely follow the Developers Reference practice for > re-introducing a package by filing an ITP and CCing debian-devel. [4] > Therefore, in my opinion, the Debian project never collectively agreed > to xchat's reintroduction to Debian. Yes, you are nitpicking. Because the Debian Project doesn't have to give their consent to let a package in the archive. That's the job of Debian's FTP masters. >> I don't think a rant posted on reddit by the author of a fork >> is justified enough to ask for a package to be removed from >> the archive. > > The author posted his opinion to his personal blog and did not > directly start the reddit discussion. Also, that author is the subject > matter expert here and I think we should give due deference to his > understanding of the security issues present in xchat for which he did > not seek CVE designations. If he is an expert, why didn't he even bother posting a single valid example where xchat is insecure and posing a risk to its users. If there are valid vulnerabilities, it shouldn't a problem to list them. >> As long as there aren't any serious policy or security issues, >> Debian usually doesn't impose any limitations on what packages >> get maintained in the archive and which not. > > Yes, I'm well aware of your position since I've read the reddit discussion. > > However, your characterization of Debian's practice is inaccurate. For > instance, I'm helping to remove hundreds of packages from Debian right > now. The packages often are maintained more or less in Debian but have > had no upstream development for years. [5] Wasn't there recently a discussion on debian-devel that was started that people were complaining about packages getting removed way too quickly? I really don't think that your reasoning is acceptable. None of the the points you mentioned above list actual problems. Both you and the maintainer of the fork fail to list any actual vulnerabilities. And, to be honest, I would find it more constructive to take care of packages like mozjs52 which have are far more important than a leaf package like xchat yet they haven't seen any fixes and uploads for months with bug reports remaining unanswered. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891982: xchat: Intent to file removal bug
Package: src:xchat Followup-For: Bug #891982 Hi Jeremy! Could you provide any references to bug reports which indicates that there are problems with the xchat package which make it unfit for release or violate against any of the points mentioned in the Debian Policy? Please note that we have other packages in Debian like xemacs21 or micropolis-activity whose upstream is long dead but where we have compotent maintainers in Debian who are actively taking care of this package. I don't think a rant posted on reddit by the author of a fork is justified enough to ask for a package to be removed from the archive. As long as there aren't any serious policy or security issues, Debian usually doesn't impose any limitations on what packages get maintained in the archive and which not. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881846: rustc: FTBFS on armel
Hi! I have managed to build rustc 1.24 natively on armel using the changes from the following bug reports: - #891022 - rustc: Please include patch to disable kernel helpers on armel - #891913 - rustc: Please add architecture matching for armel => armv5te-unknown-linux-gnu - #891961 - rustc: Please enable workaround for upstream issue 45854 on armel I'm now waiting for Ximin to upload rustc_1.24 so I can bootstrap rustc for armel, I have already installed a working compiler on abel.debian.org and harris.debian.org. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891961: rustc: Please enable workaround for upstream issue 45854 on armel
Source: rustc Version: 1.23.0+dfsg1-1 Severity: normal Hi! The debian/rules file contains a workaround for the upstream issue 45854 on armhf: # Work around armhf issue: https://github.com/rust-lang/rust/issues/45854 [ $(DEB_BUILD_ARCH) != armhf ] || sed -i -e '/^debuginfo-only-std = /d' "$@" We have the same problem on armel and hence need the workaround there as well, so the easiest way would be probably something like this: [ $(DEB_BUILD_ARCH) != armhf ] || sed -i -e '/^debuginfo-only-std = /d' "$@" [ $(DEB_BUILD_ARCH) != armel ] || sed -i -e '/^debuginfo-only-std = /d' "$@" With the patch to disable the included kernel helpers (#891902) and enabling the architecture matching (#891913) and this change, I was able to build rustc on armel natively and hence fixing #881846. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891773: Related bug #871229 (but it didn't break my system))
On 03/02/2018 02:58 PM, Diederik de Haas wrote: Still works without segfaults. Any particular info you'd like to see as well? No. But you should re-test version -3 that was just uploaded once it becomes available. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891913: rustc: Please add architecture matching for armel => armv5te-unknown-linux-gnu
Source: rustc Version: 1.23.0+dfsg1-1 Severity: normal User: debian-...@lists.debian.org Usertags: armel Hi! In order to be able to support rustc on armel, we need to add the architecture mapping for armel in debian/architecture.mk. Since armel has been recently bumped to armv5te (#882174), the architecture mapping should be armel => armv5te-unknown-linux-gnu. I haven't tried to come up with a patch yet myself but it should be a trivial change. For now, I have just replaced armhf and armv7 for a local build, but that will, of course, break the build on armhf. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891902: rustc: Please include patch to disable kernel helpers on armel
Source: rustc
Version: 1.23.0+dfsg1-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: armel
Hi!
While trying to bootstrap rustc for armel, I ran into an issue where
rustc's own kernel helpers for atomics for ARM were causing linker
issues due to the fact modern versions of gcc already include such
helper functions itself [1].
While I haven't come up with a suitable patch for upstream yet as I
need to do some research first on which targets rustc's own helpers
are still required and on which they are not, I have whipped up a
simple patch which should work-around the issue for us in Debian
and allow us to bootstrap rustc for armel.
Could you include it in the next upload, preferably 1.24?
Thanks,
Adrian
> [1] https://github.com/rust-lang/rust/issues/48625
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- rustc-1.24.0+dfsg1/src/libcompiler_builtins/build.rs.orig 2018-02-12
16:56:07.0 -0200
+++ rustc-1.24.0+dfsg1/src/libcompiler_builtins/build.rs2018-03-02
07:22:10.124164162 -0300
@@ -52,9 +52,9 @@
}
// Only emit the ARM Linux atomic emulation on pre-ARMv6 architectures.
-if llvm_target[0] == "armv4t" || llvm_target[0] == "armv5te" {
-println!("cargo:rustc-cfg=kernel_user_helpers")
-}
+// if llvm_target[0] == "armv4t" || llvm_target[0] == "armv5te" {
+// println!("cargo:rustc-cfg=kernel_user_helpers")
+// }
}
#[cfg(feature = "gen-tests")]
Bug#891773: Related bug #871229 (but it didn't break my system))
Hi!
Here's an updated patch sparc64-support.patch which should address the issue,
it contains these two patches:
> http://lists.gnu.org/archive/html/grub-devel/2018-03/msg00016.html
> http://lists.gnu.org/archive/html/grub-devel/2018-03/msg00018.html
@Martin and Diederik, could you test these updated packages?
> https://people.debian.org/~glaubitz/grub-891773/
@Colin, could you update the sparc64-support.patch to include the
two changes above? I have also attached an updated patch.
Thanks to everyone for helping to catch this regression!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 48ab5733b350bb96ae3c3b1513093f8a847be9e9 Mon Sep 17 00:00:00 2001
From: Eric Snowberg <eric.snowb...@oracle.com>
Date: Thu, 22 Feb 2018 10:03:46 +
Subject: Add support for modern sparc64 hardware
Origin: other, https://github.com/esnowberg/grub2-sparc/tree/sparc-next-v4
Bug-Debian: https://bugs.debian.org/854568
Last-Update: 2018-03-02
Patch-Name: sparc64-support.patch
---
grub-core/Makefile.core.def|1 +
grub-core/boot/sparc64/ieee1275/boot.S | 10 +
grub-core/commands/ls.c|2 +
grub-core/commands/nativedisk.c|1 +
grub-core/disk/ieee1275/obdisk.c | 1079
grub-core/disk/ieee1275/ofdisk.c | 30 +-
grub-core/kern/ieee1275/cmain.c|3 +
grub-core/kern/ieee1275/ieee1275.c | 199 +
grub-core/kern/ieee1275/init.c | 36 +-
grub-core/kern/ieee1275/openfw.c | 27 +
grub-core/kern/parser.c|1 -
grub-core/kern/sparc64/ieee1275/ieee1275.c | 53 ++
grub-core/osdep/linux/blocklist.c |5 +
grub-core/osdep/linux/ofpath.c | 194 -
include/grub/disk.h|1 +
include/grub/ieee1275/ieee1275.h | 27 +
include/grub/ieee1275/obdisk.h | 25 +
include/grub/sparc64/ieee1275/ieee1275.h |2 +
util/grub-install.c|1 +
util/ieee1275/grub-ofpathname.c|4 +-
util/setup.c | 87 ++-
21 files changed, 1733 insertions(+), 55 deletions(-)
create mode 100644 grub-core/disk/ieee1275/obdisk.c
create mode 100644 include/grub/ieee1275/obdisk.h
Index: grub2-2.02+dfsg1/grub-core/Makefile.core.def
===
--- grub2-2.02+dfsg1.orig/grub-core/Makefile.core.def
+++ grub2-2.02+dfsg1/grub-core/Makefile.core.def
@@ -270,6 +270,7 @@ kernel = {
sparc64_ieee1275 = kern/sparc64/cache.S;
sparc64_ieee1275 = kern/sparc64/dl.c;
sparc64_ieee1275 = kern/sparc64/ieee1275/ieee1275.c;
+ sparc64_ieee1275 = disk/ieee1275/obdisk.c;
arm = kern/arm/dl.c;
arm = kern/arm/dl_helper.c;
Index: grub2-2.02+dfsg1/grub-core/boot/sparc64/ieee1275/boot.S
===
--- grub2-2.02+dfsg1.orig/grub-core/boot/sparc64/ieee1275/boot.S
+++ grub2-2.02+dfsg1/grub-core/boot/sparc64/ieee1275/boot.S
@@ -69,6 +69,10 @@ prom_seek_name: .asciz "seek"
prom_read_name: .asciz "read"
prom_exit_name: .asciz "exit"
grub_name: .asciz "GRUB "
+#ifdef CDBOOT
+prom_close_name: .asciz "close"
+#endif
+
#define GRUB_NAME_LEN 5
.align 4
@@ -213,6 +217,12 @@ bootpath_known:
call prom_call_3_1_o1
#ifdef CDBOOT
LDUW_ABS(kernel_size, 0x00, %o3)
+
+ GET_ABS(prom_close_name, %o0)
+ mov 1, %g1
+ mov 0, %o5
+ call prom_call
+ mov BOOTDEV_REG, %o1
#else
mov 512, %o3
#endif
Index: grub2-2.02+dfsg1/grub-core/commands/ls.c
===
--- grub2-2.02+dfsg1.orig/grub-core/commands/ls.c
+++ grub2-2.02+dfsg1/grub-core/commands/ls.c
@@ -201,6 +201,8 @@ grub_ls_list_files (char *dirname, int l
if (grub_errno == GRUB_ERR_UNKNOWN_FS)
grub_errno = GRUB_ERR_NONE;
+ grub_device_close (dev);
+ dev = NULL;
grub_normal_print_device_info (device_name);
}
else if (fs)
Index: grub2-2.02+dfsg1/grub-core/commands/nativedisk.c
===
--- grub2-2.02+dfsg1.orig/grub-core/commands/nativedisk.c
+++ grub2-2.02+dfsg1/grub-core/commands/nativedisk.c
@@ -66,6 +66,7 @@ get_uuid (const char *name, char **uuid,
/* Firmware disks. */
case GRUB_DISK_DEVICE_BIOSDISK_ID:
case GRUB_DISK_DEVICE_OFDISK_ID:
+case GRUB_DISK_DEVICE_OBDISK_ID:
case GRUB_DISK_DEVICE_EFIDISK_ID:
case GRUB_DISK_DEVICE_NAND_ID:
case GRUB_DISK_DEVICE_ARCDISK_ID:
Index: grub2-2.02+dfsg1/grub-core/disk/ieee1275/obdisk.c
===
--- /dev/null
+++ grub2-2.02+dfsg1/grub-core/disk/ieee1
Bug#891773: [PATCH v3] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
Hi! As suggested by James Clarke earlier on this mailing list today, I have modified of_path_of_nvme such that it behaves the same way as of_path_of_scsi and just returns NULL when the call to find_obppath returns NULL. This makes much more sense than what my previous patch did as we don't want of_path_of_nvme to return anything but NULL when not run on a system not based on Open Firmware. Thanks, Adrian
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme support within ofpath) introduced a functional regression: On systems which are not based on Open Firmware but have at least one NVME device, find_obppath will return NULL and thus trying to append the disk name to of_path will result in a crash. The proper behavior of of_path_of_nvme is, however, to just return NULL in such cases, like other users of find_obppath, such as of_path_of_scsi. Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> --- grub-core/osdep/linux/ofpath.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c index 1c30e7233..61806212e 100644 --- a/grub-core/osdep/linux/ofpath.c +++ b/grub-core/osdep/linux/ofpath.c @@ -389,8 +389,11 @@ of_path_of_nvme(const char *sys_devname __attribute__((unused)), } of_path = find_obppath (sysfs_path); + + if (of_path) +strcat (of_path, disk); + free (sysfs_path); - strcat (of_path, disk); return of_path; } -- 2.16.2
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
On 03/01/2018 05:59 PM, James Clarke wrote: Whitespace issues aside, should it not be returning NULL if of_path is NULL, like the other users of find_obppath, such as of_path_of_scsi? Hmm. Good point. This should restore the behaviour from before of_path_of_nvme was added, as grub_util_devname_to_ofpath would have previously returned NULL due to the unknown type? Right. I'll wait for some comments from Daniel and Eric first though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891773: Related bug #871229 (but it didn't break my system))
On 03/01/2018 05:15 PM, Diederik de Haas wrote:
No more segfaults :-)
Alright. Attaching an updated patch for sparc64 support for Colin.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 48ab5733b350bb96ae3c3b1513093f8a847be9e9 Mon Sep 17 00:00:00 2001
From: Eric Snowberg <eric.snowb...@oracle.com>
Date: Thu, 22 Feb 2018 10:03:46 +
Subject: Add support for modern sparc64 hardware
Origin: other, https://github.com/esnowberg/grub2-sparc/tree/sparc-next-v4
Bug-Debian: https://bugs.debian.org/854568
Last-Update: 2018-03-01
Patch-Name: sparc64-support.patch
---
grub-core/Makefile.core.def|1 +
grub-core/boot/sparc64/ieee1275/boot.S | 10 +
grub-core/commands/ls.c|2 +
grub-core/commands/nativedisk.c|1 +
grub-core/disk/ieee1275/obdisk.c | 1079
grub-core/disk/ieee1275/ofdisk.c | 30 +-
grub-core/kern/ieee1275/cmain.c|3 +
grub-core/kern/ieee1275/ieee1275.c | 199 +
grub-core/kern/ieee1275/init.c | 36 +-
grub-core/kern/ieee1275/openfw.c | 27 +
grub-core/kern/parser.c|1 -
grub-core/kern/sparc64/ieee1275/ieee1275.c | 53 ++
grub-core/osdep/linux/blocklist.c |5 +
grub-core/osdep/linux/ofpath.c | 194 -
include/grub/disk.h|1 +
include/grub/ieee1275/ieee1275.h | 27 +
include/grub/ieee1275/obdisk.h | 25 +
include/grub/sparc64/ieee1275/ieee1275.h |2 +
util/grub-install.c|1 +
util/ieee1275/grub-ofpathname.c|4 +-
util/setup.c | 87 ++-
21 files changed, 1733 insertions(+), 55 deletions(-)
create mode 100644 grub-core/disk/ieee1275/obdisk.c
create mode 100644 include/grub/ieee1275/obdisk.h
Index: grub2-2.02+dfsg1/grub-core/Makefile.core.def
===
--- grub2-2.02+dfsg1.orig/grub-core/Makefile.core.def
+++ grub2-2.02+dfsg1/grub-core/Makefile.core.def
@@ -270,6 +270,7 @@ kernel = {
sparc64_ieee1275 = kern/sparc64/cache.S;
sparc64_ieee1275 = kern/sparc64/dl.c;
sparc64_ieee1275 = kern/sparc64/ieee1275/ieee1275.c;
+ sparc64_ieee1275 = disk/ieee1275/obdisk.c;
arm = kern/arm/dl.c;
arm = kern/arm/dl_helper.c;
Index: grub2-2.02+dfsg1/grub-core/boot/sparc64/ieee1275/boot.S
===
--- grub2-2.02+dfsg1.orig/grub-core/boot/sparc64/ieee1275/boot.S
+++ grub2-2.02+dfsg1/grub-core/boot/sparc64/ieee1275/boot.S
@@ -69,6 +69,10 @@ prom_seek_name: .asciz "seek"
prom_read_name: .asciz "read"
prom_exit_name: .asciz "exit"
grub_name: .asciz "GRUB "
+#ifdef CDBOOT
+prom_close_name: .asciz "close"
+#endif
+
#define GRUB_NAME_LEN 5
.align 4
@@ -213,6 +217,12 @@ bootpath_known:
call prom_call_3_1_o1
#ifdef CDBOOT
LDUW_ABS(kernel_size, 0x00, %o3)
+
+ GET_ABS(prom_close_name, %o0)
+ mov 1, %g1
+ mov 0, %o5
+ call prom_call
+ mov BOOTDEV_REG, %o1
#else
mov 512, %o3
#endif
Index: grub2-2.02+dfsg1/grub-core/commands/ls.c
===
--- grub2-2.02+dfsg1.orig/grub-core/commands/ls.c
+++ grub2-2.02+dfsg1/grub-core/commands/ls.c
@@ -201,6 +201,8 @@ grub_ls_list_files (char *dirname, int l
if (grub_errno == GRUB_ERR_UNKNOWN_FS)
grub_errno = GRUB_ERR_NONE;
+ grub_device_close (dev);
+ dev = NULL;
grub_normal_print_device_info (device_name);
}
else if (fs)
Index: grub2-2.02+dfsg1/grub-core/commands/nativedisk.c
===
--- grub2-2.02+dfsg1.orig/grub-core/commands/nativedisk.c
+++ grub2-2.02+dfsg1/grub-core/commands/nativedisk.c
@@ -66,6 +66,7 @@ get_uuid (const char *name, char **uuid,
/* Firmware disks. */
case GRUB_DISK_DEVICE_BIOSDISK_ID:
case GRUB_DISK_DEVICE_OFDISK_ID:
+case GRUB_DISK_DEVICE_OBDISK_ID:
case GRUB_DISK_DEVICE_EFIDISK_ID:
case GRUB_DISK_DEVICE_NAND_ID:
case GRUB_DISK_DEVICE_ARCDISK_ID:
Index: grub2-2.02+dfsg1/grub-core/disk/ieee1275/obdisk.c
===
--- /dev/null
+++ grub2-2.02+dfsg1/grub-core/disk/ieee1275/obdisk.c
@@ -0,0 +1,1079 @@
+/* obdisk.c - Open Boot disk access. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2017 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option)
Bug#891773: Related bug #871229 (but it didn't break my system))
On 03/01/2018 03:22 PM, Diederik de Haas wrote: So it didn't seem to have fixed the issue, but maybe some additional info. If you need other info or want me to run other (debugging) commands, let me know. Preferably with detailed instructions as I just learned today how to do the 'bt' command. I have updated the packages with the patch I just came up with: https://people.debian.org/~glaubitz/grub-891773/ Can you retry? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#891773: [PATCH v2] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
Hi! We have recently backported the upstream changes to Debian's grub2 package to support modern SPARC hardware for Debian's sparc64 port. One of the changes introduced a regression on systems with NVME devices which are not based on Open Firmware. On these systems, find_obppath returns an empty string and trying to append the disk name to that empty name results in a crash in of_path_of_nvme. Fix that by making sure of_path isn't empty and if it is, just return the disk name in of_path_of_nvme. Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891773 Thanks, Adrian
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme support within ofpath) introduced a functional regression: On systems which are not based on Open Firmware but have at least one NVME device, find_obppath will return an empty path and appending the disk name to of_path will therefore result in a crash. Thus, when of_path is empty, just return the disk name in of_path_of_nvme. Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> --- grub-core/osdep/linux/ofpath.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c index 1c30e7233..daf0f 100644 --- a/grub-core/osdep/linux/ofpath.c +++ b/grub-core/osdep/linux/ofpath.c @@ -389,8 +389,13 @@ of_path_of_nvme(const char *sys_devname __attribute__((unused)), } of_path = find_obppath (sysfs_path); + + if(of_path) +strcat (of_path, disk); + else +of_path = strdup(disk); + free (sysfs_path); - strcat (of_path, disk); return of_path; } -- 2.16.2
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme support within ofpath) introduced a functional regression: On systems where of_path is empty, i.e. non-OpenFirmware machines, grub-probe crashes in of_path_of_nvme when trying to append the disk name to an empty of_path. Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> --- grub-core/osdep/linux/ofpath.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c index 1c30e7233..daf0f 100644 --- a/grub-core/osdep/linux/ofpath.c +++ b/grub-core/osdep/linux/ofpath.c @@ -389,8 +389,13 @@ of_path_of_nvme(const char *sys_devname __attribute__((unused)), } of_path = find_obppath (sysfs_path); + + if(of_path) +strcat (of_path, disk); + else +of_path = strdup(disk); + free (sysfs_path); - strcat (of_path, disk); return of_path; } -- 2.16.2
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
We have recently backported the upstream changes to Debian's grub2 package to support modern SPARC hardware for Debian's sparc64 port. One of the changes introduced a regression on systems with NVME devices but not The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme support within ofpath) introduced a functional regression: On systems where of_path is empty, i.e. non-OpenFirmware machines, grub-probe crashes in of_path_of_nvme when trying to append the disk name to an empty of_path.
