Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
> Control: severity -1 wishlist Setting a bug which breaks multiple architectures is somewhat of an understatement. > I haven't looked at the code but it seems that this dependency is now > required in order to build qdoc, so reducing the severity to wishlist. Well, it's a documentation tool. It should just be possible to disable the documentation tool on the affected architectures. > I don't know if it's possible at all to build everything but qdoc. And the > effect of this could be many packages starting to FTBFS. Unlikely. I don't know any project that has a hard dependency on documentation. > The only way around I see is submitting patches upstream to avoid clanf > usage. Remember they need to go directly to upstream, we can't forward then > except for very small changes. Strange policy. Lots of people here take patches from the bugtracker and forward them upstream. In fact, that's what the official Debian documentation says. Either way, there are plans to make LLVM available on more targets, there are already branches working on alpha, m68k, riscv64 and more. Until then, it would be nice if Qt wouldn't have a hard dependency on it solely to build documentation. 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#904703: [Pkg-rust-maintainers] Bug#904703: rustc: Please backport another sparc64 CABI fix
On 07/26/2018 11:51 PM, John Paul Adrian Glaubitz wrote: > Rust upstream just fixed another bug in the sparc64 CABI [1] > which can result in miscompiled code. Since the patch is rather > trivial and affects sparc64 only, it would be good if we could > include it in the next upload. Forgot the reference for [1]: > https://github.com/rust-lang/rust/issues/52638 -- .''`. 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#904703: rustc: Please backport another sparc64 CABI fix
Source: rustc
Version: 1.27.2+dfsg1-1
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
Rust upstream just fixed another bug in the sparc64 CABI [1]
which can result in miscompiled code. Since the patch is rather
trivial and affects sparc64 only, it would be good if we could
include it in the next upload.
Attaching the patch from upstream.
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 051eddd9a9067dcbdccef6bfd86301453bae42ad Mon Sep 17 00:00:00 2001
From: Petr Sumbera
Date: Thu, 26 Jul 2018 03:58:00 -0700
Subject: [PATCH] sparc ABI issue - structure returning from function is
returned in 64bit registers
Fixes: #52638
---
src/librustc_target/abi/call/sparc64.rs | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/src/librustc_target/abi/call/sparc64.rs
b/src/librustc_target/abi/call/sparc64.rs
index 987f56e6f985..a58aebc2ff06 100644
--- a/src/librustc_target/abi/call/sparc64.rs
+++ b/src/librustc_target/abi/call/sparc64.rs
@@ -57,16 +57,7 @@ fn classify_ret_ty<'a, Ty, C>(cx: C, ret: &mut ArgType<'a,
Ty>)
let size = ret.layout.size;
let bits = size.bits();
if bits <= 256 {
-let unit = if bits <= 8 {
-Reg::i8()
-} else if bits <= 16 {
-Reg::i16()
-} else if bits <= 32 {
-Reg::i32()
-} else {
-Reg::i64()
-};
-
+let unit = Reg::i64();
ret.cast_to(Uniform {
unit,
total: size
Bug#904204: [Openjdk] Bug#904204: openjdk-11: Please update patch for m68k support
Hi! On 07/22/2018 11:38 AM, Matthias Klose wrote: > On 22.07.2018 01:08, John Paul Adrian Glaubitz wrote: >> On 07/21/2018 04:48 PM, John Paul Adrian Glaubitz wrote: >>> Please replace the patch with the attached version for the next upload. >> >> The patch was unfortunately incomplete, it missed the size adjustments >> for make/gensrc/GensrcX11Wrappers.gmk. Attaching an updated one. > > is jhsdb built on m68k as well? The results are in. No, jhsdb is not being built on m68k: dh_install --sourcedir=debian/tmp -XLICENSE -Xrelease dh_install: Cannot find (any matches for) "usr/lib/jvm/java-11-openjdk-m68k/bin/jhsdb" (tried in debian/tmp, debian/tmp) dh_install: openjdk-11-jdk-headless missing files: usr/lib/jvm/java-11-openjdk-m68k/bin/jhsdb dh_install: missing files, aborting make: *** [debian/rules:1220: install] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 Attaching the latest version of the m68k-support patch that has been verified to work. Please include it in the next upload and disable the installation of jhsdb 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 # HG changeset patch # User glaubitz # Date 1532184301 -7200 # Sat Jul 21 16:45:01 2018 +0200 # Node ID 418a697aef91a730b942129d5d41b6c68a871cd8 # Parent b0fcf59be3918afcaa13d1f97343968c2c467ffe JDK-NNN: Zero needs alignment fixes for linux-m68k diff -r b0fcf59be391 -r 418a697aef91 make/data/x11wrappergen/sizes-32-linux-m68k.txt --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/make/data/x11wrappergen/sizes-32-linux-m68k.txt Sat Jul 21 16:45:01 2018 +0200 @@ -0,0 +1,1017 @@ +long 4 +int 4 +short 2 +ptr 4 +Bool 4 +Atom 4 +Window 4 +XExtData.number 0 +XExtData.next 4 +XExtData.free_private 8 +XExtData.private_data 12 +XExtData 16 +XIMStringConversionCallbackStruct.position 0 +XIMStringConversionCallbackStruct.direction 2 +XIMStringConversionCallbackStruct.operation 6 +XIMStringConversionCallbackStruct.factor 8 +XIMStringConversionCallbackStruct.text 10 +XIMStringConversionCallbackStruct 14 +XkbNewKeyboardNotifyEvent.type 0 +XkbNewKeyboardNotifyEvent.serial 4 +XkbNewKeyboardNotifyEvent.send_event 8 +XkbNewKeyboardNotifyEvent.display 12 +XkbNewKeyboardNotifyEvent.time 16 +XkbNewKeyboardNotifyEvent.xkb_type 20 +XkbNewKeyboardNotifyEvent.device 24 +XkbNewKeyboardNotifyEvent.old_device 28 +XkbNewKeyboardNotifyEvent.min_key_code 32 +XkbNewKeyboardNotifyEvent.max_key_code 36 +XkbNewKeyboardNotifyEvent.old_min_key_code 40 +XkbNewKeyboardNotifyEvent.old_max_key_code 44 +XkbNewKeyboardNotifyEvent.changed 48 +XkbNewKeyboardNotifyEvent.req_major 52 +XkbNewKeyboardNotifyEvent.req_minor 53 +XkbNewKeyboardNotifyEvent 54 +XTimeCoord.time 0 +XTimeCoord.x 4 +XTimeCoord.y 6 +XTimeCoord 8 +XkbCompatMapNotifyEvent.type 0 +XkbCompatMapNotifyEvent.serial 4 +XkbCompatMapNotifyEvent.send_event 8 +XkbCompatMapNotifyEvent.display 12 +XkbCompatMapNotifyEvent.time 16 +XkbCompatMapNotifyEvent.xkb_type 20 +XkbCompatMapNotifyEvent.device 24 +XkbCompatMapNotifyEvent.changed_groups 28 +XkbCompatMapNotifyEvent.first_si 32 +XkbCompatMapNotifyEvent.num_si 36 +XkbCompatMapNotifyEvent.num_total_si 40 +XkbCompatMapNotifyEvent 44 +XIMStatusDrawCallbackStruct.type 0 +XIMStatusDrawCallbackStruct.data 4 +XIMStatusDrawCallbackStruct 8 +XKeyboardControl.key_click_percent 0 +XKeyboardControl.bell_percent 4 +XKeyboardControl.bell_pitch 8 +XKeyboardControl.bell_duration 12 +XKeyboardControl.led 16 +XKeyboardControl.led_mode 20 +XKeyboardControl.key 24 +XKeyboardControl.auto_repeat_mode 28 +XKeyboardControl 32 +XSelectionClearEvent.type 0 +XSelectionClearEvent.serial 4 +XSelectionClearEvent.send_event 8 +XSelectionClearEvent.display 12 +XSelectionClearEvent.window 16 +XSelectionClearEvent.selection 20 +XSelectionClearEvent.time 24 +XSelectionClearEvent 28 +XWindowChanges.x 0 +XWindowChanges.y 4 +XWindowChanges.width 8 +XWindowChanges.height 12 +XWindowChanges.border_width 16 +XWindowChanges.sibling 20 +XWindowChanges.stack_mode 24 +XWindowChanges 28 +XIMPreeditCaretCallbackStruct.position 0 +XIMPreeditCaretCallbackStruct.direction 4 +XIMPreeditCaretCallbackStruct.style 8 +XIMPreeditCaretCallbackStruct 12 +XOMCharSetList.charset_count 0 +XOMCharSetList.charset_list 4 +XOMCharSetList 8 +XOMFontInfo.num_font 0 +XOMFontInfo.font_struct_list 4 +XOMFontInfo.font_name_list 8 +XOMFontInfo 12 +AwtScreenData.numConfigs 0 +AwtScreenData.root 4 +AwtScreenData.whitepixel 8 +AwtScreenData.blackpixel 12 +AwtScreenData.defaultConfig 16 +AwtScreenData.configs 20 +AwtScreenData 24 +XIMHotKeyTrigger.keysym 0 +XIMHotKeyTrigger.modifier 4 +XIMHotKeyTrigger.modifier_mask 8 +XIMHotKeyTrigger 12 +XCirculateEvent.type 0 +XCirculateEvent.serial 4 +XCirculateEvent.send_event 8 +XCircul
Bug#884750: happy: stage1 build profile FTBFS
Package: src:happy Followup-For: Bug #884750 Hi! This is trivially fixed with the following patch: --- debian/rules~ 2018-04-09 21:06:48.0 +0200 +++ debian/rules2018-07-25 14:21:27.034989036 +0200 @@ -15,9 +15,6 @@ ifneq (,$(filter stage1,$(DEB_BUILD_PROFILES))) DEB_SETUP_GHC_CONFIGURE_ARGS += --with-happy=/bin/true - -cleanbuilddir/happy:: - cp -a dist/build/happy/happy-tmp/*.hs src/ endif clean:: I just ran into this problem while bootstrapping happy for risc64. If I remember correctly, src:alex has this problem 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#904585: java-common: Please bump m68k to openjdk-10
Source: java-common Version: 0.67 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k Hi! I have successfully bootstrapped openjdk-10 for m68k now [1], we can therefore now make openjdk-10 the default JDK on m68k. Please apply the attached patch to make the necessary modfications to the java-common package. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904495 -- .''`. 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 --- debian/java_defaults.mk.orig2018-06-06 13:54:21.0 +0200 +++ debian/java_defaults.mk 2018-07-25 13:30:40.008744803 +0200 @@ -6,11 +6,11 @@ java11_architectures = $(java12_architectures) java10_architectures = $(java11_architectures) \ alpha amd64 arm64 armel armhf i386 \ - ia64 mips mipsel mips64el \ + ia64 m68k mips mipsel mips64el \ powerpc ppc64 ppc64el \ riscv64 s390x sparc64 sh4 x32 java9_architectures = $(java10_architectures) \ - m68k powerpcspe + powerpcspe java8_architectures = $(java9_architectures) \ kfreebsd-amd64 kfreebsd-i386 java7_architectures = $(java8_architectures)
Bug#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev
On 07/25/2018 01:09 AM, Ximin Luo wrote: > I think the cost-benefit trade-off for rust weighs more in the "just upload > to unstable" > direction. Piuparts can be fixed to understand this situation, and unstable > users can be > educated to understand what "unstable" means. Discussions don't have to be > long. Ok, just be warned that these recurring bug reports can become annoying over time :-). -- .''`. 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#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev
On 07/25/2018 12:32 AM, Ximin Luo wrote: > The testing migration scripts prevent the temporarily-problematic packages > from reaching Debian testing Yes, but the scripts don't prevent piuparts from throwing errors and unstable users from writing invalid bug reports. Been there, done that when I was on the MATE team. > , e.g. [1] so I don't see an issue with uploading to unstable directly. > Uploading > to experimental then unstable again, causes extra unnecessary work for us. It causes a minimal extra work, yes. But it avoids these bug reports and long discussions. We have received such bug reports not just once in the MATE team but many times since many unstable users don't understand the concept of the NEW queue. Other teams like the KDE team usually take the experimental detour as well, it's common practice. 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#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev
Hi Ximin! On 07/25/2018 12:01 AM, Ximin Luo wrote: > Hi Andreas, this is not a bug, it's because FTP masters are slow with > processing the NEW queue. > > We expect similar situations for other rust packages, for the time being. > > Please don't file such bugs for the next few months whilst we get the basic > set of rust packages into Debian. If you see this situation again after 6 > months however, then that is a real bug and feel free to file one. Maintainers normally go through experimental to avoid these issues, i.e. you first upload all packages into experimental and once they have passed NEW, you re-upload them to unstable. 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#904495: openjdk-10: Please update patch for m68k support
Source: openjdk-10 Version: 10.0.2+13-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k Hi! The attached patch is an updated version of the m68k support patch for openjdk-10. I have tested the patch locally and I am currently using it to bootstrap openjdk-10 for m68k, the build is almost finished (already at the stage where it's creating the images with the built openjdk-10 binaries). Please use this patch to update the m68k support in the next upload of openjdk-10. 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 # HG changeset patch # User glaubitz # Date 1532300401 -7200 # Mon Jul 23 01:00:01 2018 +0200 # Node ID b2ac44c7cfd7380b5061eb7bb16ee8fa8376ac84 # Parent b09e56145e11874abc61ce67da7e99b1f3851a28 JDK-NNN: Zero needs alignment fixes for linux-m68k diff -r b09e56145e11 -r b2ac44c7cfd7 make/data/x11wrappergen/sizes.32-linux-m68k --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/make/data/x11wrappergen/sizes.32-linux-m68k Mon Jul 23 01:00:01 2018 +0200 @@ -0,0 +1,1017 @@ +long 4 +int4 +short 2 +ptr4 +Bool 4 +Atom 4 +Window 4 +XExtData.number0 +XExtData.next 4 +XExtData.free_private 8 +XExtData.private_data 12 +XExtData 16 +XIMStringConversionCallbackStruct.position 0 +XIMStringConversionCallbackStruct.direction2 +XIMStringConversionCallbackStruct.operation6 +XIMStringConversionCallbackStruct.factor 8 +XIMStringConversionCallbackStruct.text 10 +XIMStringConversionCallbackStruct 14 +XkbNewKeyboardNotifyEvent.type 0 +XkbNewKeyboardNotifyEvent.serial 4 +XkbNewKeyboardNotifyEvent.send_event 8 +XkbNewKeyboardNotifyEvent.display 12 +XkbNewKeyboardNotifyEvent.time 16 +XkbNewKeyboardNotifyEvent.xkb_type 20 +XkbNewKeyboardNotifyEvent.device 24 +XkbNewKeyboardNotifyEvent.old_device 28 +XkbNewKeyboardNotifyEvent.min_key_code 32 +XkbNewKeyboardNotifyEvent.max_key_code 36 +XkbNewKeyboardNotifyEvent.old_min_key_code 40 +XkbNewKeyboardNotifyEvent.old_max_key_code 44 +XkbNewKeyboardNotifyEvent.changed 48 +XkbNewKeyboardNotifyEvent.req_major52 +XkbNewKeyboardNotifyEvent.req_minor53 +XkbNewKeyboardNotifyEvent 54 +XTimeCoord.time0 +XTimeCoord.x 4 +XTimeCoord.y 6 +XTimeCoord 8 +XkbCompatMapNotifyEvent.type 0 +XkbCompatMapNotifyEvent.serial 4 +XkbCompatMapNotifyEvent.send_event 8 +XkbCompatMapNotifyEvent.display12 +XkbCompatMapNotifyEvent.time 16 +XkbCompatMapNotifyEvent.xkb_type 20 +XkbCompatMapNotifyEvent.device 24 +XkbCompatMapNotifyEvent.changed_groups 28 +XkbCompatMapNotifyEvent.first_si 32 +XkbCompatMapNotifyEvent.num_si 36 +XkbCompatMapNotifyEvent.num_total_si 40 +XkbCompatMapNotifyEvent44 +XIMStatusDrawCallbackStruct.type 0 +XIMStatusDrawCallbackStruct.data 4 +XIMStatusDrawCallbackStruct8 +XKeyboardControl.key_click_percent 0 +XKeyboardControl.bell_percent 4 +XKeyboardControl.bell_pitch8 +XKeyboardControl.bell_duration 12 +XKeyboardControl.led 16 +XKeyboardControl.led_mode 20 +XKeyboardControl.key 24 +XKeyboardControl.auto_repeat_mode 28 +XKeyboardControl 32 +XSelectionClearEvent.type 0 +XSelectionClearEvent.serial4 +XSelectionClearEvent.send_event8 +XSelectionClearEvent.display 12 +XSelectionClearEvent.window16 +XSelectionClearEvent.selection 20 +XSelectionClearEvent.time 24 +XSelectionClearEvent 28 +XWindowChanges.x 0 +XWindowChanges.y 4 +XWindowChanges.width 8 +XWindowChanges.height 12 +XWindowChanges.border_width16 +XWindowChanges.sibling 20 +XWindowChanges.stack_mode 24 +XWindowChanges 28 +XIMPreeditCaretCallbackStruct.position 0 +XIMPreeditCaretCallbackStruct.direction4 +XIMPreeditCaretCallbackStruct.style8 +XIMPreeditCaretCallbackStruct 12 +XOMCharSetList.charset_count 0 +XOMCharSetList.charset_list4 +XOMCharSetList 8 +XOMFontInfo.num_font 0 +XOMFontInfo.font_struct_list 4 +XOMFontInfo.font_name_list 8 +XOMFontInfo12 +AwtScreenData.numConfigs 0 +AwtScreenData.root 4 +AwtScreenData.whitepixel 8 +AwtScreenData.blackpixel 12 +AwtScreenData.defaultConfig16 +AwtScreenData.configs 20 +AwtScreenData 24 +XIMHotKeyTrigger.keysym0 +XIMHotKeyTrigger.modifier 4 +XIMHotKeyTrigger.modifier_mask 8 +XIMHotKeyTrigger 12 +XCirculateEvent.type 0 +XCirculateEvent.serial 4 +XCirculateEvent.send_event 8 +XCirculateEvent.display12 +XCirculateEvent.event 16 +XCirculateEvent.window 20 +XCirculateEvent.place 24 +XCirculateEvent28 +Screen.ext_data0 +Screen.display 4 +Screen.root8 +Screen.width 12 +Screen.height 16 +Screen.mwidth 20 +Screen.mheight 24 +Screen.ndepths 28 +Screen.depths 32 +Screen.root_depth
Bug#901052: freetype: Please update to 2.9.1
> On Jul 24, 2018, at 7:02 PM, Steve Langasek wrote: > > I haven't reviewed the proposed NMU diff in depth, because I stopped the > moment I saw that it was proposing to introduce new binary packages, a > change for which there was no prior bug report in the BTS. I am > disappointed that the prospective sponsors here were not similarly given > pause. To be fair, Steve, you’ve been silent for quite a long time and freetype is too important as a package to let it just hang there. And, I honestly don’t think the lack of CI should keep us from updating this package forever. It’s being updated in other distributions, so I think Debian can do so as well. Adrian
Bug#901052: freetype: Please update to 2.9.1
Hi! On 07/23/2018 02:41 PM, Hugh McMaster wrote: > Thank you for the offer to review and (potentially) sponsor my NMU of > FreeType 2. > Mattia Rizzolo has taken ownership of the RFS bug and has provided an initial > review of the NMU [1]. > > I have since updated the package on Debian Mentors to fix the issues > identified. Sounds very good. Thanks to Mattia for taking care of this! > I believe Mattia is busy until Tuesday evening, but I hope the package > can be uploaded to the NEW queue soon. No worries. I can wait until then. 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#901052: freetype: Please update to 2.9.1
Package: libfreetype6-dev Followup-For: Bug #901052 User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! I would be happy to help with the review and the sponsorship of this NMU if Steve is unable to go ahead and do it himself. I'm particularly interested in the new freetype version to fix alignment issues on sparc64 which have been fixed upstream in the newer versions [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898983 -- .''`. 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#904204: [Openjdk] Bug#904204: openjdk-11: Please update patch for m68k support
On 07/22/2018 11:38 AM, Matthias Klose wrote: > On 22.07.2018 01:08, John Paul Adrian Glaubitz wrote: >> On 07/21/2018 04:48 PM, John Paul Adrian Glaubitz wrote: >>> Please replace the patch with the attached version for the next upload. >> >> The patch was unfortunately incomplete, it missed the size adjustments >> for make/gensrc/GensrcX11Wrappers.gmk. Attaching an updated one. > > is jhsdb built on m68k as well? Most likely not. I just ran into an issue with make/gensrc/GensrcX11Wrappers.gmk, please wait a bit with this patch. You can ignore it if you want to upload 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
Bug#904204: openjdk-11: Please update patch for m68k support
On 07/21/2018 04:48 PM, John Paul Adrian Glaubitz wrote: > Please replace the patch with the attached version for the next upload. The patch was unfortunately incomplete, it missed the size adjustments for make/gensrc/GensrcX11Wrappers.gmk. Attaching an updated one. 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 1532184301 -7200 # Sat Jul 21 16:45:01 2018 +0200 # Node ID b34e9e0ef820b0b0a0eb55d97f41281fc8db2793 # Parent b0fcf59be3918afcaa13d1f97343968c2c467ffe JDK-NNN: Zero needs alignment fixes for linux-m68k diff -r b0fcf59be391 -r b34e9e0ef820 make/data/x11wrappergen/sizes-32-linux-m68k.txt --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/make/data/x11wrappergen/sizes-32-linux-m68k.txt Sat Jul 21 16:45:01 2018 +0200 @@ -0,0 +1,1017 @@ +long 4 +int 4 +short 2 +ptr 4 +Bool 4 +Atom 4 +Window 4 +XExtData.number 0 +XExtData.next 4 +XExtData.free_private 8 +XExtData.private_data 12 +XExtData 16 +XIMStringConversionCallbackStruct.position 0 +XIMStringConversionCallbackStruct.direction 2 +XIMStringConversionCallbackStruct.operation 6 +XIMStringConversionCallbackStruct.factor 8 +XIMStringConversionCallbackStruct.text 10 +XIMStringConversionCallbackStruct 14 +XkbNewKeyboardNotifyEvent.type 0 +XkbNewKeyboardNotifyEvent.serial 4 +XkbNewKeyboardNotifyEvent.send_event 8 +XkbNewKeyboardNotifyEvent.display 12 +XkbNewKeyboardNotifyEvent.time 16 +XkbNewKeyboardNotifyEvent.xkb_type 20 +XkbNewKeyboardNotifyEvent.device 24 +XkbNewKeyboardNotifyEvent.old_device 28 +XkbNewKeyboardNotifyEvent.min_key_code 32 +XkbNewKeyboardNotifyEvent.max_key_code 36 +XkbNewKeyboardNotifyEvent.old_min_key_code 40 +XkbNewKeyboardNotifyEvent.old_max_key_code 44 +XkbNewKeyboardNotifyEvent.changed 48 +XkbNewKeyboardNotifyEvent.req_major 52 +XkbNewKeyboardNotifyEvent.req_minor 53 +XkbNewKeyboardNotifyEvent 54 +XTimeCoord.time 0 +XTimeCoord.x 4 +XTimeCoord.y 6 +XTimeCoord 8 +XkbCompatMapNotifyEvent.type 0 +XkbCompatMapNotifyEvent.serial 4 +XkbCompatMapNotifyEvent.send_event 8 +XkbCompatMapNotifyEvent.display 12 +XkbCompatMapNotifyEvent.time 16 +XkbCompatMapNotifyEvent.xkb_type 20 +XkbCompatMapNotifyEvent.device 24 +XkbCompatMapNotifyEvent.changed_groups 28 +XkbCompatMapNotifyEvent.first_si 32 +XkbCompatMapNotifyEvent.num_si 36 +XkbCompatMapNotifyEvent.num_total_si 40 +XkbCompatMapNotifyEvent 44 +XIMStatusDrawCallbackStruct.type 0 +XIMStatusDrawCallbackStruct.data 4 +XIMStatusDrawCallbackStruct 8 +XKeyboardControl.key_click_percent 0 +XKeyboardControl.bell_percent 4 +XKeyboardControl.bell_pitch 8 +XKeyboardControl.bell_duration 12 +XKeyboardControl.led 16 +XKeyboardControl.led_mode 20 +XKeyboardControl.key 24 +XKeyboardControl.auto_repeat_mode 28 +XKeyboardControl 32 +XSelectionClearEvent.type 0 +XSelectionClearEvent.serial 4 +XSelectionClearEvent.send_event 8 +XSelectionClearEvent.display 12 +XSelectionClearEvent.window 16 +XSelectionClearEvent.selection 20 +XSelectionClearEvent.time 24 +XSelectionClearEvent 28 +XWindowChanges.x 0 +XWindowChanges.y 4 +XWindowChanges.width 8 +XWindowChanges.height 12 +XWindowChanges.border_width 16 +XWindowChanges.sibling 20 +XWindowChanges.stack_mode 24 +XWindowChanges 28 +XIMPreeditCaretCallbackStruct.position 0 +XIMPreeditCaretCallbackStruct.direction 4 +XIMPreeditCaretCallbackStruct.style 8 +XIMPreeditCaretCallbackStruct 12 +XOMCharSetList.charset_count 0 +XOMCharSetList.charset_list 4 +XOMCharSetList 8 +XOMFontInfo.num_font 0 +XOMFontInfo.font_struct_list 4 +XOMFontInfo.font_name_list 8 +XOMFontInfo 12 +AwtScreenData.numConfigs 0 +AwtScreenData.root 4 +AwtScreenData.whitepixel 8 +AwtScreenData.blackpixel 12 +AwtScreenData.defaultConfig 16 +AwtScreenData.configs 20 +AwtScreenData 24 +XIMHotKeyTrigger.keysym 0 +XIMHotKeyTrigger.modifier 4 +XIMHotKeyTrigger.modifier_mask 8 +XIMHotKeyTrigger 12 +XCirculateEvent.type 0 +XCirculateEvent.serial 4 +XCirculateEvent.send_event 8 +XCirculateEvent.display 12 +XCirculateEvent.event 16 +XCirculateEvent.window 20 +XCirculateEvent.place 24 +XCirculateEvent 28 +Screen.ext_data 0 +Screen.display 4 +Screen.root 8 +Screen.width 12 +Screen.height 16 +Screen.mwidth 20 +Screen.mheight 24 +Screen.ndepths 28 +Screen.depths 32 +Screen.root_depth 36 +Screen.root_visual 40 +Screen.default_gc 44 +Screen.cmap 48 +Screen.white_pixel 52 +Screen.black_pixel 56 +Screen.max_maps 60 +Screen.min_maps 64 +Screen.backing_store 68 +Screen.save_unders 72 +Screen.root_input_mask 76 +Screen 80 +XMapRequestEvent.type 0 +XMapRequestEvent.serial 4 +XMapRequestEvent.send_event 8 +XMapRequestEvent.display 12 +XMapRequestEvent.parent 16 +XMapRequestEvent.window 20 +XMapRequestEvent 24 +XIMText.length 0 +XIMText.feedback 2 +XIMText.encoding_is_wchar 6 +XIMText.string 10 +XIMText 14 +XGraphicsExposeEvent.type 0 +XGraphicsExposeEvent.serial 4 +XGraphicsE
Bug#904204: openjdk-11: Please update patch for m68k support
Source: openjdk-11
Version: 11~23-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Hello!
In order to make openjdk-11 build on m68k, the m68k-support.diff patch
needs to be updated. The current version doesn't apply anymore which
is why it was disabled in the past.
Please replace the patch with the attached version for 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
# HG changeset patch
# User glaubitz
# Date 1532184301 -7200
# Sat Jul 21 16:45:01 2018 +0200
# Node ID 7acf28c3e4edd6d66f809828f0ec4122daf8f157
# Parent b0fcf59be3918afcaa13d1f97343968c2c467ffe
JDK-NNN: Zero needs alignment fixes for linux-m68k
diff -r b0fcf59be391 -r 7acf28c3e4ed src/hotspot/share/memory/allocation.hpp
--- a/src/hotspot/share/memory/allocation.hpp Fri Jul 20 14:48:41 2018 -0700
+++ b/src/hotspot/share/memory/allocation.hpp Sat Jul 21 16:45:01 2018 +0200
@@ -209,7 +209,7 @@
void operator delete(void* p) { FreeHeap(p); }
void operator delete [] (void* p) { FreeHeap(p); }
-};
+} __attribute__ ((aligned (4)));
// Base class for objects allocated on the stack only.
// Calling new or delete will result in fatal error.
@@ -223,7 +223,7 @@
#endif
void operator delete(void* p);
void operator delete [](void* p);
-};
+} __attribute__ ((aligned (4)));
// Base class for objects stored in Metaspace.
// Calling delete will result in fatal error.
@@ -311,7 +311,7 @@
// that should be read-only by default. See symbol.hpp for an example. This
function
// is used by the templates in metaspaceClosure.hpp
static bool is_read_only_by_default() { return false; }
-};
+} __attribute__ ((aligned (4)));
// Base class for classes that constitute name spaces.
@@ -401,7 +401,7 @@
void operator delete(void* p);
void operator delete [](void* p);
-};
+} __attribute__ ((aligned (4)));
// One of the following macros must be used when allocating an array
// or object to determine whether it should reside in the C heap on in
diff -r b0fcf59be391 -r 7acf28c3e4ed src/hotspot/share/oops/constMethod.hpp
--- a/src/hotspot/share/oops/constMethod.hppFri Jul 20 14:48:41 2018 -0700
+++ b/src/hotspot/share/oops/constMethod.hppSat Jul 21 16:45:01 2018 +0200
@@ -559,6 +559,6 @@
// Verify
void verify_on(outputStream* st);
-};
+} __attribute__ ((aligned (4)));
#endif // SHARE_VM_OOPS_CONSTMETHODOOP_HPP
diff -r b0fcf59be391 -r 7acf28c3e4ed src/hotspot/share/oops/oop.hpp
--- a/src/hotspot/share/oops/oop.hppFri Jul 20 14:48:41 2018 -0700
+++ b/src/hotspot/share/oops/oop.hppSat Jul 21 16:45:01 2018 +0200
@@ -331,6 +331,6 @@
assert(has_klass_gap(), "only applicable to compressed klass pointers");
return klass_offset_in_bytes() + sizeof(narrowKlass);
}
-};
+} __attribute__ ((aligned (4)));
#endif // SHARE_VM_OOPS_OOP_HPP
diff -r b0fcf59be391 -r 7acf28c3e4ed
src/java.base/unix/native/libjli/java_md_solinux.c
--- a/src/java.base/unix/native/libjli/java_md_solinux.cFri Jul 20
14:48:41 2018 -0700
+++ b/src/java.base/unix/native/libjli/java_md_solinux.cSat Jul 21
16:45:01 2018 +0200
@@ -727,12 +727,24 @@
}
}
+struct call_continuation_args {
+ int (JNICALL *continuation)(void *);
+ void *args;
+};
+
+static void *call_continuation(void *_args)
+{
+ struct call_continuation_args *args = _args;
+ return (void *)args->continuation(args->args);
+}
+
/*
* Block current thread and continue execution in a new thread
*/
int
ContinueInNewThread0(int (JNICALL *continuation)(void *), jlong stack_size,
void * args) {
int rslt;
+struct call_continuation_args ccargs = { continuation, args };
#ifndef __solaris__
pthread_t tid;
pthread_attr_t attr;
@@ -744,7 +756,7 @@
}
pthread_attr_setguardsize(&attr, 0); // no pthread guard page on java
threads
-if (pthread_create(&tid, &attr, (void *(*)(void*))continuation,
(void*)args) == 0) {
+if (pthread_create(&tid, &attr, call_continuation, &ccargs) == 0) {
void * tmp;
pthread_join(tid, &tmp);
rslt = (int)(intptr_t)tmp;
@@ -762,7 +774,7 @@
#else /* __solaris__ */
thread_t tid;
long flags = 0;
-if (thr_create(NULL, stack_size, (void *(*)(void *))continuation, args,
flags, &tid) == 0) {
+if (thr_create(NULL, stack_size, call_continuation, &ccargs, flags, &tid)
== 0) {
void * tmp;
thr_join(tid, NULL, &tmp);
rslt = (int)(intptr_t)tmp;
Bug#904173: Replaces "uae"? Mention on wiki?
On 07/21/2018 04:57 AM, Elliott Mitchell wrote: > Perhaps the fs-uae package should be marked "Replaces: uae"? I hadn't > been aware there was a replacement for the old "uae" package until I went > searching and ran into the fs-uae package. Well, I could certainly add this in the next upload, yes. > fs-uae seems to deserve a mention on https://wiki.debian.org/Emulator I think you can just create a wiki account yourself and extend the list. 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
Blacklisting doesn’t fix the transition block. Once the package is outdated on any of the release architectures, transition is blocked. > On Jul 20, 2018, at 5:15 PM, YunQiang Su wrote: > > On Tue, 17 Jul 2018 18:10:14 +0200 John Paul Adrian Glaubitz > wrote: >> 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. > > I have asked Aurelien to blacklist rustc. > @Aurelien, oh the rustc problem is not about `make', it is about llvm. > >> >> 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 >> >> > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
Bug#903631: openjdk-11: FTBFS on several architectures: dh_install: Cannot find (any matches for) "usr/lib/jvm/java-11-openjdk-armel/bin/jhsdb"
Package: src:openjdk-11 Followup-For: Bug #903631 Hi! ia64 is affected by this bug as well: : # FIXME: the targets are not installed ... rm -rfv debian/tmp/usr/lib/jvm/java-11-openjdk-ia64/lib/jfr removed 'debian/tmp/usr/lib/jvm/java-11-openjdk-ia64/lib/jfr/profile.jfc' removed 'debian/tmp/usr/lib/jvm/java-11-openjdk-ia64/lib/jfr/default.jfc' removed directory 'debian/tmp/usr/lib/jvm/java-11-openjdk-ia64/lib/jfr' dh_install --sourcedir=debian/tmp -XLICENSE -Xrelease dh_install: Cannot find (any matches for) "usr/lib/jvm/java-11-openjdk-ia64/bin/jhsdb" (tried in debian/tmp, debian/tmp) dh_install: openjdk-11-jdk-headless missing files: usr/lib/jvm/java-11-openjdk-ia64/bin/jhsdb dh_install: missing files, aborting make: *** [debian/rules:1220: install] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 Can you fix it in 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
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 defin
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& RenderSty
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
-
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&arch=i386&ver=0.27.0%2Bdfsg.1-0.3&stamp=1527339147&raw=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
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
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, &mem, 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(&ondisk->oid, &entry->id);
+ git_oid_cpy(&ondisk.oid, &entry->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(&ondisk_ext, &ondisk, sizeof(struct entry_short));
+ ondisk_ext.flags_extended = htons(entry->flags_extended &
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 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
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 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&arch=sparc64&ver=1.0.3-1&stamp=1523838466&raw=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&arch=sparc64&ver=1.7.6-1&stamp=1523839301&raw=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
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&arch=m68k&ver=4%3A4.8.7%2Bdfsg-16&stamp=1526192657&raw=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 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.cpp @@ -23,7 +23
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 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
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/sr
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
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
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/interna
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
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
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_INLINE vo
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
+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 wrote:
>> Date: Wed, 07 Feb 2018 22:09:23 +0100
>> From: John Paul Adrian Glaubitz
>> To: Debian Bug Tracking System
>> 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/
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
