Re: request to rebuild my package libcork (FTBFS on landau, but was built OK on andi)

2016-10-22 Thread Roger Shimizu
On Thu, Oct 6, 2016 at 9:35 PM, James Clarke  wrote:
>
> Yes, that looks fine. Have you forwarded it upstream?

The upstream is not active anymore.
Like I submit your patch monthly ago [0], but no reply yet.

[0] https://github.com/redjack/libcork/issues/118

>> Do you think it's a good idea to avoid transition?
>
> If you’re doing that, I would consult other people (IRC is a good source), as 
> I
> don’t know all the subtleties about package renaming and only have [1] to go 
> on.
> However, IMO, given that you only have two reverse dependencies (namely
> src:shadowsocks-libev and src:libcorkipset), I would just do a transition and
> avoid picking up the cruft (and potential confusion), but I don’t have much
> experience of these things.

Accepted your suggestion, and now I finished the transition [1]
It's not so difficult as expected. :-)

After the transition, I applied your patch and made an experimental release [2].
Problem seems solved by confirming the buildd status [3]
sparc64 can be built normally now, and other ARCHs aren't affected
(yet, because some are waiting to start the build).

Problem seems solved, so thank you so much for your help!

[1] https://release.debian.org/transitions/html/auto-libcork.html
[2] https://github.com/rogers0/libcork/commit/54357a
[3] https://buildd.debian.org/status/logs.php?pkg=libcork=sparc64

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Re: Regression with 4.7.2 on sun4u

2016-10-22 Thread James Clarke
On Fri, Oct 21, 2016 at 09:07:26PM -0400, David Miller wrote:
> From: James Clarke 
> Date: Fri, 21 Oct 2016 22:52:45 +0100
> 
> > This indeed was the case. The attached patch fixes the problem for me,
> > generating 0x1062, which gdb can verify is sensible (of course, the
> > addresses have shifted slightly):
> 
> Please don't use attachments for patch submissions.
> 
> Patches must be inline so that they can be commented upon properly
> using simply email quoting mechanisms.
> 
> Thank you.

Ok; same patch inline:

From 27ecad347d19c613d4e85665e710f1bd6bd56117 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Fri, 21 Oct 2016 19:11:10 +0100
Subject: [PATCH] sparc: Handle negative offsets in arch_jump_label_transform

Signed-off-by: James Clarke 
---
 arch/sparc/kernel/jump_label.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..dec09ce 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -19,12 +19,20 @@ void arch_jump_label_transform(struct jump_entry *entry,
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
 
+   BUG_ON(off & 3);
+
 #ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
+   /* WDISP19 - target is . + (immed << 2) */
+   BUG_ON(off > 0xf);
+   BUG_ON(off < -0x10);
+   /* ba,pt %xcc, . + off */
+   val = 0x1068 | (((u32) off >> 2) & 0x7);
 #else
-   /* ba . + (off << 2) */
-   val = 0x1080 | ((u32) off >> 2);
+   /* WDISP22 - target is . + (immed << 2) */
+   BUG_ON(off > 0x7f);
+   BUG_ON(off < -0x80);
+   /* ba . + off */
+   val = 0x1080 | (((u32) off >> 2) & 0x3f);
 #endif
} else {
val = 0x0100;
-- 
2.9.3



signature.asc
Description: PGP signature