Bug#868021: ffcall: diff for NMU version 1.13-0+nmu1

2017-08-29 Thread Sébastien Villemot 
Dear Frédéric,

On Tue, 11 Jul 2017 11:25:11 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard 
 wrote:
> Package: src:ffcall
> Version: 1.10+cvs20100619-4
> Severity: normal
> Tags: patch pending
> 
> Dear maintainer,
> 
> I've prepared diff for a NMU for ffcall (versioned as 1.13-0+nmu1) in the
> attached patch but feel free to use the patch as you want.
> The goal was initially to fix the FTBFS impacting mlpcap on ppc64el
> https://buildd.debian.org/status/fetch.php?pkg=mlpcap=ppc64el=0.9-16=1485552538=0
> 
> config.log would show :
> configure:4214: gcc -o conftest -g -O2 
> -fdebug-prefix-map=/build/mlpcap-gmmM7n/mlpcap-0.9=. -fstack-protector-strong 
> -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro conftest.
> c -lcallback  -lpcap  >&5
> /usr/lib/gcc/powerpc64le-linux-gnu/6/../../../powerpc64le-linux-gnu/libcallback.so:
>  undefined reference to `tramp_r'
> 
> But this upload could fix other bugs as well.
> 
> Looking at ffcal upstream, I see that there a much newer version of ffcall 
> namely
> 1.13 which contains amongst other ppc64el improvements which fixed the build
> of mlpcap (tested).
> I tried to change the bare minimum of the packaging so that we have something 
> close
> to 1.10+cvs20100619-4 but still building. Here are the changes I made :
> debian/patches : I've updated fix-powerpcspe.patch, and 
> Fix_MIPS_N32_test.patch : please
>  review them.
>  I've disabled ppc64el-elfv2.patch as ppc64el support should 
>be good in 1.13.
>  I've also commented 0001-fix-callback-on-x86_64.patch as it 
>should be
>  fixed upstream : 
>https://www.bountysource.com/issues/20684153-segfault
> debian/rules :   autoreconf failed as is, so I added gnulib-m4 to aclocal 
> path and removed
>  skipping of libtoolize.
> debian/libffcall1.symbols : some symbols seem local (__*) so no need to check 
> them I
>  think. There were some new additions.
> debian/watch :   I updated the repo URL which seemed to not work anymore at 
> all (server not found)

Thanks for your patch. I am currently working on updating ffcall, based
on what you did (unless Christoph Egger is faster than me!).

However, could you please give a detailed explanation of what your
updated Fix_MIPS_N32_test.patch does? You modified several assembly
files, and this needs explaining for non-mips-specialists.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part

Bug#868021: ffcall: diff for NMU version 1.13-0+nmu1

2017-07-11 Thread Frédéric Bonnard 
Package: src:ffcall
Version: 1.10+cvs20100619-4
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared diff for a NMU for ffcall (versioned as 1.13-0+nmu1) in the
attached patch but feel free to use the patch as you want.
The goal was initially to fix the FTBFS impacting mlpcap on ppc64el
https://buildd.debian.org/status/fetch.php?pkg=mlpcap=ppc64el=0.9-16=1485552538=0

config.log would show :
configure:4214: gcc -o conftest -g -O2 
-fdebug-prefix-map=/build/mlpcap-gmmM7n/mlpcap-0.9=. -fstack-protector-strong 
-Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro conftest.
c -lcallback  -lpcap  >&5
/usr/lib/gcc/powerpc64le-linux-gnu/6/../../../powerpc64le-linux-gnu/libcallback.so:
 undefined reference to `tramp_r'

But this upload could fix other bugs as well.

Looking at ffcal upstream, I see that there a much newer version of ffcall 
namely
1.13 which contains amongst other ppc64el improvements which fixed the build
of mlpcap (tested).
I tried to change the bare minimum of the packaging so that we have something 
close
to 1.10+cvs20100619-4 but still building. Here are the changes I made :
debian/patches : I've updated fix-powerpcspe.patch, and Fix_MIPS_N32_test.patch 
: please
 review them.
 I've disabled ppc64el-elfv2.patch as ppc64el support should be 
good in 1.13.
 I've also commented 0001-fix-callback-on-x86_64.patch as it 
should be
 fixed upstream : 
https://www.bountysource.com/issues/20684153-segfault
debian/rules :   autoreconf failed as is, so I added gnulib-m4 to aclocal path 
and removed
 skipping of libtoolize.
debian/libffcall1.symbols : some symbols seem local (__*) so no need to check 
them I
 think. There were some new additions.
debian/watch :   I updated the repo URL which seemed to not work anymore at all 
(server not found)

I hope that helps, let me know if things need to be improved.

Regards.

diff -baupr ./ffcall-1.10+cvs20100619/debian/changelog 
./ffcall-1.13/debian/changelog
--- ./ffcall-1.10+cvs20100619/debian/changelog  2016-05-18 15:38:55.0 
+
+++ ./ffcall-1.13/debian/changelog  2017-07-10 13:12:33.342511211 +
@@ -1,3 +1,10 @@
+ffcall (1.13-0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+
+ -- Frédéric Bonnard   Mon, 03 Jul 2017 13:00:38 
+
+
 ffcall (1.10+cvs20100619-4) unstable; urgency=medium
 
   [ Fernando Seiti Furusato ]
diff -baupr ./ffcall-1.10+cvs20100619/debian/libffcall1.symbols 
./ffcall-1.13/debian/libffcall1.symbols
--- ./ffcall-1.10+cvs20100619/debian/libffcall1.symbols 2016-05-18 
15:38:55.0 +
+++ ./ffcall-1.13/debian/libffcall1.symbols 2017-07-10 13:16:18.175743648 
+
@@ -1,16 +1,17 @@
 libavcall.so.0 libffcall1 #MINVER#
  __builtin_avcall@Base 1.10+2.41
- __structcpy@Base 1.10+2.41
+ avcall_structcpy@Base 1.13
 libcallback.so.0 libffcall1 #MINVER#
  (arch=alpha arm powerpc armel hppa)__TR_clear_cache@Base 1.10+2.41
+ (arch=ppc64el)__TR_clear_cache@Base 1.13
  (arch=sparc)__TR_clear_cache_2@Base 1.10+2.41
- __structcpy@Base 1.10+2.41
- __va_error1@Base 1.10+2.41
- __va_error2@Base 1.10+2.41
- __va_struct_buffer@Base 1.10+2.41
- __vacall_r@Base 1.10+2.41
+ callback_structcpy@Base 1.13
  alloc_trampoline_r@Base 1.10+2.41
  free_trampoline_r@Base 1.10+2.41
+ get__vacall_r@Base 1.13
+ glthread_once_singlethreaded@Base 1.13
+ glthread_recursive_lock_init_multithreaded@Base 1.13
+ glthread_rwlock_init_for_glibc@Base 1.13
  is_trampoline_r@Base 1.10+2.41
  (arch=hppa ia64)tramp_r@Base 1.10+2.41
  trampoline_r_address@Base 1.10+2.41
Only in ./ffcall-1.10+cvs20100619/debian/patches: 
0001-fix-callback-on-x86_64.patch
diff -baupr ./ffcall-1.10+cvs20100619/debian/patches/Fix_MIPS_N32_test.patch 
./ffcall-1.13/debian/patches/Fix_MIPS_N32_test.patch
--- ./ffcall-1.10+cvs20100619/debian/patches/Fix_MIPS_N32_test.patch
2016-05-18 15:38:55.0 +
+++ ./ffcall-1.13/debian/patches/Fix_MIPS_N32_test.patch2017-07-10 
15:26:44.740188692 +
@@ -2,18 +2,79 @@ Description: Fix MIPS N32 test
 Author: James Cowgill 
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/m4/general.m4
-+++ b/m4/general.m4
-@@ -97,11 +97,8 @@ dnl We should also check for (_MIPS_SZPT
- if test $ffcall_cv_host_mips64 = yes; then
-   host_cpu_abi=mips64
- else
--dnl Strictly speaking, the MIPS ABI (-32 or -n32) is independent from the CPU
--dnl identification (-mips[12] or -mips[34]). But -n32 is commonly used 
together
--dnl with -mips3, and it's easier to test the CPU identification.
-   FFCALL_SET_CPU_ABI([MIPS with n32 ABI], ffcall_cv_host_mipsn32,
--[__mips >= 3], mipsn32, mips)
-+[defined(_ABIN32) && (_MIPS_SIM == _ABIN32)], mipsn32, mips)
- fi
- ;;
- dnl On powerpc64 systems, the C compiler may still be generating 32-bit code.