Bug#806720: ITP: libvecpf -- Vector Printf Library

2015-11-30 Thread TFAUCK 
Package: wnpp
Version: N/A ; reported 2015-11-30
Severity: extra

* Package name : libvecpf
Version : 1.0.0
Upstream Author :  Breno Leitao 
* URL : https://github.com/Libvecpf/libvecpf
* License : LGPL
Description : Vector Printf Library
This library extends ISO C printf so that it may print out vector data
types.  The description of the extensions are in the AltiVec Technology
Programming Interface Manual.


__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#819091: clblas: Enable altivec on ppc64el

2016-04-26 Thread TFAUCK 
Hello,

By default powerpc64 P8 system provides -maltivec gcc option preventing
compilation - a patch is disabling that option with the -mno-altivec flag.
In order to authorize that -maltivec flag to allow use of vector
optimisation, two issues must be considered
- vector name is a reserved keyword and can't be part of a struct.
Commit a7e1d4c934e29d2861d95c2ee955707353b59db3 is renaming "vector" to
"Vector".
- in defbool.h, the bool definition must be replaced with a non vector
one due to a a C++ issue. Commit
ef1b194971d9e4ea1043e668940c83ee60eebc2d ensures the altivec definitions
are correct.
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/
From a7e1d4c934e29d2861d95c2ee955707353b59db3 Mon Sep 17 00:00:00 2001
From: Thierry Fauck 
Date: Mon, 25 Apr 2016 09:04:37 -0400
Subject: [PATCH 1/2] vector is a gcc special word When using -maltivec option
 with gcc, vector is a special word and struct fields named vector are
 mis-understood. This patch just change vector name to Vector.

	modified:   src/library/blas/functor/functor_xscal.cc
	modified:   src/library/blas/generic/solution_seq_make.c
	modified:   src/library/blas/gens/asum.cpp
	modified:   src/library/blas/gens/axpy_reg.cpp
	modified:   src/library/blas/gens/copy_reg.cpp
	modified:   src/library/blas/gens/dot.cpp
	modified:   src/library/blas/gens/gbmv.cpp
	modified:   src/library/blas/gens/gemv.c
	modified:   src/library/blas/gens/ger_lds.cpp
	modified:   src/library/blas/gens/her2_lds.cpp
	modified:   src/library/blas/gens/her_lds.cpp
	modified:   src/library/blas/gens/iamax.cpp
	modified:   src/library/blas/gens/nrm2.cpp
	modified:   src/library/blas/gens/rotm_reg.cpp
	modified:   src/library/blas/gens/scal_reg.cpp
	modified:   src/library/blas/gens/swap_reg.cpp
	modified:   src/library/blas/gens/symv.c
	modified:   src/library/blas/gens/syr2_lds.cpp
	modified:   src/library/blas/gens/syr_lds.cpp
	modified:   src/library/blas/gens/trmv_reg.cpp
	modified:   src/library/blas/gens/trsv_gemv.cpp
	modified:   src/library/blas/gens/trsv_trtri.cpp
	modified:   src/library/blas/include/clblas-internal.h
	modified:   src/library/blas/ixamax.c
	modified:   src/library/blas/xasum.c
	modified:   src/library/blas/xaxpy.c
	modified:   src/library/blas/xcopy.c
	modified:   src/library/blas/xdot.c
	modified:   src/library/blas/xgbmv.c
	modified:   src/library/blas/xgemv.c
	modified:   src/library/blas/xger.c
	modified:   src/library/blas/xhemv.c
	modified:   src/library/blas/xher.c
	modified:   src/library/blas/xher2.c
	modified:   src/library/blas/xhpmv.c
	modified:   src/library/blas/xnrm2.c
	modified:   src/library/blas/xrot.c
	modified:   src/library/blas/xrotm.c
	modified:   src/library/blas/xscal.c
	modified:   src/library/blas/xshbmv.c
	modified:   src/library/blas/xspmv.c
	modified:   src/library/blas/xswap.c
	modified:   src/library/blas/xsymv.c
	modified:   src/library/blas/xsyr.c
	modified:   src/library/blas/xsyr2.c
	modified:   src/library/blas/xtbmv.c
	modified:   src/library/blas/xtbsv.c
	modified:   src/library/blas/xtrmv.c
	modified:   src/library/blas/xtrsv.c
---
 src/library/blas/functor/functor_xscal.cc|  2 +-
 src/library/blas/generic/solution_seq_make.c |  4 +--
 src/library/blas/gens/asum.cpp   |  6 ++--
 src/library/blas/gens/axpy_reg.cpp   |  8 ++---
 src/library/blas/gens/copy_reg.cpp   |  8 ++---
 src/library/blas/gens/dot.cpp|  8 ++---
 src/library/blas/gens/gbmv.cpp   |  4 +--
 src/library/blas/gens/gemv.c | 10 +++
 src/library/blas/gens/ger_lds.cpp|  4 +--
 src/library/blas/gens/her2_lds.cpp   |  4 +--
 src/library/blas/gens/her_lds.cpp|  2 +-
 src/library/blas/gens/iamax.cpp  |  6 ++--
 src/library/blas/gens/nrm2.cpp   |  6 ++--
 src/library/blas/gens/rotm_reg.cpp   |  8 ++---
 src/library/blas/gens/scal_reg.cpp   |  4 +--
 src/library/blas/gens/swap_reg.cpp   |  8 ++---
 src/library/blas/gens/symv.c | 10 +++
 src/library/blas/gens/syr2_lds.cpp   |  4 +--
 src/library/blas/gens/syr_lds.cpp|  2 +-
 src/library/blas/gens/trmv_reg.cpp   |  4 +--
 src/library/blas/gens/trsv_gemv.cpp  |  2 +-
 src/library/blas/gens/trsv_trtri.cpp |  2 +-
 src/library/blas/include/clblas-internal.h   |  2 +-
 src/library/blas/ixamax.c|  2 +-
 src/library/blas/xasum.c |  2 +-
 src/library/blas/xaxpy.c |  4 +--
 src/library/blas/xcopy.c |  4 +--
 src/library/blas/xdot.c  |  4 +--
 src/library/blas/xgbmv.c |  4 +--
 src/library/blas/xgemv.c |  4 +--
 src/library/blas/xger.c  |  4 +--

Bug#819091: [PATCH 3/3] lblas: Enable altivec on ppc64el

2016-05-02 Thread TFAUCK 
Hello,
Here is a patch to correct some occurences of vector name when using
-maltivec on ppc64le.

Best regards,
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/
>From 88a94492ad818f7a34975002e6179d87b0348d82 Mon Sep 17 00:00:00 2001
From: Thierry Fauck 
Date: Mon, 2 May 2016 07:08:07 -0400
Subject: [PATCH 3/3] altivec vector field name

Missing vector field names changes when gcc -maltivec enabled for ppc64le

	modified:   src/library/tools/ktest/config.cpp
	modified:   src/library/tools/ktest/steps/gemv.cpp
	modified:   src/library/tools/ktest/steps/symv.cpp
---
 src/library/tools/ktest/config.cpp |  4 ++--
 src/library/tools/ktest/steps/gemv.cpp | 12 ++--
 src/library/tools/ktest/steps/symv.cpp | 12 ++--
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/library/tools/ktest/config.cpp b/src/library/tools/ktest/config.cpp
index 3098e36..8b20128 100644
--- a/src/library/tools/ktest/config.cpp
+++ b/src/library/tools/ktest/config.cpp
@@ -489,13 +489,13 @@ Config::setLDC(size_t ldc)
 void
 Config::setIncX(int incx)
 {
-kargs_.ldb.vector = incx;
+kargs_.ldb.Vector = incx;
 }
 
 void
 Config::setIncY(int incy)
 {
-kargs_.ldc.vector = incy;
+kargs_.ldc.Vector = incy;
 }
 
 void
diff --git a/src/library/tools/ktest/steps/gemv.cpp b/src/library/tools/ktest/steps/gemv.cpp
index c11e3ae..19327ce 100644
--- a/src/library/tools/ktest/steps/gemv.cpp
+++ b/src/library/tools/ktest/steps/gemv.cpp
@@ -45,8 +45,8 @@ GemvStep::declareVars(Step *masterStep)
 args.N = addConst("N", "cl_uint", kargs().N);
 
 args.lda = addConst("lda", "cl_uint", kargs().lda.matrix);
-args.ldb = addConst("incx", "cl_int", kargs().ldb.vector);
-args.ldc = addConst("incy", "cl_int", kargs().ldc.vector);
+args.ldb = addConst("incx", "cl_int", kargs().ldb.Vector);
+args.ldc = addConst("incy", "cl_int", kargs().ldc.Vector);
 
 args.offA = addConst("offA", "cl_uint", kargs().offA);
 args.offBX = addConst("offX", "cl_uint", kargs().offBX);
@@ -128,11 +128,11 @@ GemvStep::fixLD()
 args.lda.matrix = args.N;
 }
 
-if (args.ldb.vector == 0) {
-args.ldb.vector = 1;
+if (args.ldb.Vector == 0) {
+args.ldb.Vector = 1;
 }
-if (args.ldc.vector == 0) {
-args.ldc.vector = 1;
+if (args.ldc.Vector == 0) {
+args.ldc.Vector = 1;
 }
 /*
  * store original height of the matrix A
diff --git a/src/library/tools/ktest/steps/symv.cpp b/src/library/tools/ktest/steps/symv.cpp
index bfe2230..4e24e95 100644
--- a/src/library/tools/ktest/steps/symv.cpp
+++ b/src/library/tools/ktest/steps/symv.cpp
@@ -45,8 +45,8 @@ SymvStep::declareVars(Step *masterStep)
 args.K = args.N;
 
 args.lda = addConst("lda", "cl_uint", kargs().lda.matrix);
-args.ldb = addConst("incx", "cl_int", kargs().ldb.vector);
-args.ldc = addConst("incy", "cl_int", kargs().ldc.vector);
+args.ldb = addConst("incx", "cl_int", kargs().ldb.Vector);
+args.ldc = addConst("incy", "cl_int", kargs().ldc.Vector);
 
 args.offsetN = addConst("offsetN", "cl_uint", kargs().offsetN);
 
@@ -108,11 +108,11 @@ SymvStep::fixLD()
 args.lda.matrix = args.N;
 }
 
-if (args.ldb.vector == 0) {
-args.ldb.vector = 1;
+if (args.ldb.Vector == 0) {
+args.ldb.Vector = 1;
 }
-if (args.ldc.vector == 0) {
-args.ldc.vector = 1;
+if (args.ldc.Vector == 0) {
+args.ldc.Vector = 1;
 }
 args.K = args.N; //store original N
 
-- 
2.7.0

Bug#833139: ATLAS Package upgrade to 3.10.3

2016-08-01 Thread TFAUCK 
Package: Atlas

Version: 3.10.3

Tags: Upgrade

--

Hello,

Since the folling announce has been made, it sounds good to plan for the
package upgrade.

Thanks


ATLAS 3.10.3 should be noticeably faster than 3.10.2 on modern hardware,
but the 3.11 series is almost always much faster on such systems.  While
I was able to backport support for modern architectures, and even
provide some reasonable kernels for modern ISA extensions, the 3.11
series allows for much larger block factors and improved storage formats
that are required to get decent performance many modern machines
(including all AVX-enabled Intel chips).  So, if you can use it, 3.11 is
still the best for modern machines by a long way.

I had hoped to have ATLAS 4.0 out by now, but various setbacks have
delayed the release, necessitating 3.10.3, since 3.10.2 was not
installing well on modern machines.

3.10.3 fixes these three bugs:
http://math-atlas.sourceforge.net/errata3.10.2.html#herkNaN
http://math-atlas.sourceforge.net/errata3.10.2.html#syr2kNaN
http://math-atlas.sourceforge.net/errata3.10.2.html#rotmg

I have tested 3.10.3 to work on the following OSes:
   1. Linux
   2. Windows64 (cygwin64 builds now work!)
   3. AIX
   4. OS X

For OSes 2-4, see special sections in the install guide for additional help:
http://math-atlas.sourceforge.net/atlas_install/node53.html
Hopefully other OSes (eg., Windows32, Solaris) still work from 3.10.2
testing.

Also note that clang can now be used to build ATLAS by adding:
--force-clang=/path/to/clang
to your configure line.  For the open version of clang, performance
still tends to lag gcc, but is strongly improved from last release.
Apple's clang appears to be substantially faster, but I may be mistaken.


New architecture support available in 3.10.3 includes:
1. ARM32: a7, a9, a15 (auto-detect of SOFT/HARD ABI)
2. ARM64: xgene1, a53, a57
3. Intel: Corei3 & Corei4 (skylake)
4. IBM: Z series, POWER8 (including little/big endian)

Support for modern vector extensions in atlas_simd.h:
1. Intel AVX2
2. IBM VSX & Z-series VX
3. ARM64 Advanced SIMD
4. ARM32 NEON (only if -Si ieee 0 flag is thrown)

Regards,
Clint

ATLAS 3.10.3 released 07/28/16, highlights of changes from 3.10.2
* Updated F77 L1BLAS testers to those used LAPACK3.6.1
* Fixed bug in rotmg revealed by LAPACK3.6.1 testers
* Fixed bug in hprk/sprk that could cause NaN propogation in
HERK/SYRK due
  to reading uninitialized memory in BETA=0 case
* Fixed bug in threaded SYR2K/HER2K that could cause NaN propogation due
  to reading uninitialized memory
* Extended matrix/vector norm functions to detect NaNs
* Extended configure:
  + --force-clang=/path/to/clang : will use clang for all C compilers,
even goodgcc (assumes gcc flag & inline-assembly compatibility)
  + --cripple-atlas-performance: install despite failing throttle check
  + Can now use arch string rather than enum # for -A arg
  + --force-tids now affects ATLrun.sh as well as threaded build
  + ARM32 autodetects SOFTFP/HARDFP ABI
* backport of config & archdefs for:
  + POWER[7,8]le, IBMz[10,13,19], Corei[3,4], ARM[7,9,15,17],
ARM64[xgene,a53,a57]
  + archdefs for NEON ARMa[7,15]
  + config support for IBM Z[9,196,12]
* backport & extension of atlas_simd.h & atlas_cplxsimd.h
  + New SIMD kernels for: VSX, VXZ, AVX2, AdvancedSIMD, NEON
* Fixed mflop test of PrintMMLine, that sometimes failed to print
  valid mflop due to negative values from prior runs
* Removed ATL_dmm6x1x60_sse2_32.c from z index files (not valid cplx
kern)
* Forced MinGW comps to be ignored unless -Si nocygwin 1 is set
* Added support for WOW64 detection & basic use, numerous changes to
make
  work on cygwin64
* Fixed uninit nM in s[1,2]nxtune.c's RecDoubleNX

-- 
**
** R. Clint Whaley, PhD * Assoc Prof, LSU * www.csc.lsu.edu/~whaley **
**
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#744752: ltrace: diff for NMU version 0.7.3-6.1

2017-01-28 Thread tfauck 


Dear maintainer,

I've updated the NMU for ltrace (versioned as 0.7.3-6.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

This update minimise the changes as specified in the NMUDIFF guide.
It includes only the changes needed to add the ppc64el arch support.

Regards.
diff -Nru ltrace-0.7.3/debian/changelog ltrace-0.7.3/debian/changelog
--- ltrace-0.7.3/debian/changelog   2016-09-21 13:15:35.0 +0200
+++ ltrace-0.7.3/debian/changelog   2017-01-28 13:25:31.0 +0100
@@ -1,3 +1,12 @@
+ltrace (0.7.3-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Closes: #744752
+  * Support for arch ppc64el and mandatory updates
+d/control add ppc64le arch
+
+ -- Thierry Fauck   Wed, 15 Dec 2016 13:15:35 +0200
+
 ltrace (0.7.3-6) unstable; urgency=medium
 
   * Fixed compilation error in amd64: readdir_r is deprecated (closes: #837011)
diff -Nru ltrace-0.7.3/debian/control ltrace-0.7.3/debian/control
--- ltrace-0.7.3/debian/control 2016-09-21 13:15:35.0 +0200
+++ ltrace-0.7.3/debian/control 2017-01-28 13:24:10.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: cdbs (>= 0.4.23-1.1), debhelper (>= 7), autotools-dev, 
libiberty-dev, libelf-dev, libselinux1-dev
 
 Package: ltrace
-Architecture: alpha amd64 arm armeb armel armhf ia64 i386 mips mipsel powerpc 
powerpcspe ppc64 s390 s390x sparc
+Architecture: alpha amd64 arm armeb armel armhf ia64 i386 mips mipsel powerpc 
powerpcspe ppc64 ppc64el s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Tracks runtime library calls in dynamically linked programs
  ltrace is a debugging program which runs a specified command until it
diff -Nru ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch 
ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
--- ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
1970-01-01 01:00:00.0 +0100
+++ ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
2016-12-04 23:23:05.0 +0100
@@ -0,0 +1,57 @@
+From 5c37171a18bddfbc716d4f3da8b008a844eea4f7 Mon Sep 17 00:00:00 2001
+From: Petr Machata 
+Date: Tue, 5 Feb 2013 01:52:37 +0100
+Subject: Add elf_can_read_next
+
+---
+ ltrace-elf.c |   10 +-
+ ltrace-elf.h |3 +++
+ 2 files changed, 8 insertions(+), 5 deletions(-)
+
+Index: b/ltrace-elf.c
+===
+--- a/ltrace-elf.c
 b/ltrace-elf.c
+@@ -202,23 +202,23 @@ elf_get_section_named(struct ltelf *lte,
+ _p, );
+ }
+ 
+-static int
+-need_data(Elf_Data *data, GElf_Xword offset, GElf_Xword size)
++int
++elf_can_read_next(Elf_Data *data, GElf_Xword offset, GElf_Xword size)
+ {
+   assert(data != NULL);
+   if (data->d_size < size || offset > data->d_size - size) {
+   debug(1, "Not enough data to read %"PRId64"-byte value"
+ " at offset %"PRId64".", size, offset);
+-  return -1;
++  return 0;
+   }
+-  return 0;
++  return 1;
+ }
+ 
+ #define DEF_READER(NAME, SIZE)
\
+   int \
+   NAME(Elf_Data *data, GElf_Xword offset, uint##SIZE##_t *retp)   \
+   {   \
+-  if (need_data(data, offset, SIZE / 8) < 0)  \
++  if (!elf_can_read_next(data, offset, SIZE / 8)) \
+   return -1;  \
+   \
+   if (data->d_buf == NULL) /* NODATA section */ { \
+Index: b/ltrace-elf.h
+===
+--- a/ltrace-elf.h
 b/ltrace-elf.h
+@@ -116,6 +116,9 @@ int elf_read_next_u16(Elf_Data *data, GE
+ int elf_read_next_u32(Elf_Data *data, GElf_Xword *offset, uint32_t *retp);
+ int elf_read_next_u64(Elf_Data *data, GElf_Xword *offset, uint64_t *retp);
+ 
++/* Return whether there's AMOUNT more bytes after OFFSET in DATA.  */
++int elf_can_read_next(Elf_Data *data, GElf_Xword offset, GElf_Xword amount);
++
+ #if __WORDSIZE == 32
+ #define PRI_ELF_ADDR  PRIx32
+ #define GELF_ADDR_CAST(x) (void *)(uint32_t)(x)
diff -Nru ltrace-0.7.3/debian/patches/add_elf_each_symbol_7a29f9e7.patch 
ltrace-0.7.3/debian/patches/add_elf_each_symbol_7a29f9e7.patch
--- ltrace-0.7.3/debian/patches/add_elf_each_symbol_7a29f9e7.patch  
1970-01-01 01:00:00.0 +0100
+++ ltrace-0.7.3/debian/patches/add_elf_each_symbol_7a29f9e7.patch  
2016-12-04 23:23:05.0 +0100
@@ -0,0 +1,111 @@
+From 7a29f9e7a2bd5849886519eb82e9c043d24c6a40 Mon Sep 17 00:00:00 2001
+From: Petr Machata 
+Date: Mon, 14 Oct 2013 20:04:09 +0200
+Subject: Add elf_each_symbol
+
+---
+

Bug#744752: ltrace: diff for NMU version 0.7.3-6.1

2017-01-27 Thread tfauck 


Dear maintainer,

This is an update to my previous nmudiff where I removed patches related to arm 
arch.
Hope that answer the bug#744752 content.

Regards.
diff -Nru ltrace-0.7.3/debian/changelog ltrace-0.7.3/debian/changelog
--- ltrace-0.7.3/debian/changelog   2016-09-21 13:15:35.0 +0200
+++ ltrace-0.7.3/debian/changelog   2017-01-27 12:42:02.0 +0100
@@ -1,3 +1,16 @@
+ltrace (0.7.3-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Closes: #744752
+  * Support for arch ppc64el and mandatory updates
+d/control add ppc64le and update debhelper versions
+d/compat update version
+d/watch: add file
+d/lintian-overrides: hardening, spelling-error-in-manpage,
+  no-upstream-changelog, copyright-refers-to-symlink-license
+
+ -- Thierry Fauck   Wed, 15 Dec 2016 13:15:35 +0200
+
 ltrace (0.7.3-6) unstable; urgency=medium
 
   * Fixed compilation error in amd64: readdir_r is deprecated (closes: #837011)
diff -Nru ltrace-0.7.3/debian/compat ltrace-0.7.3/debian/compat
--- ltrace-0.7.3/debian/compat  2012-11-10 13:43:48.0 +0100
+++ ltrace-0.7.3/debian/compat  2016-12-15 19:34:46.0 +0100
@@ -1 +1 @@
-5
+10
diff -Nru ltrace-0.7.3/debian/control ltrace-0.7.3/debian/control
--- ltrace-0.7.3/debian/control 2016-09-21 13:15:35.0 +0200
+++ ltrace-0.7.3/debian/control 2016-12-15 19:38:17.0 +0100
@@ -3,10 +3,11 @@
 Priority: optional
 Maintainer: Juan Cespedes 
 Standards-Version: 3.9.8
-Build-Depends: cdbs (>= 0.4.23-1.1), debhelper (>= 7), autotools-dev, 
libiberty-dev, libelf-dev, libselinux1-dev
+Build-Depends: cdbs (>= 0.4.23-1.1), debhelper (>= 9), autotools-dev, 
libiberty-dev, libelf-dev, libselinux1-dev
+Homepage: https://www.ltrace.org
 
 Package: ltrace
-Architecture: alpha amd64 arm armeb armel armhf ia64 i386 mips mipsel powerpc 
powerpcspe ppc64 s390 s390x sparc
+Architecture: alpha amd64 arm armeb armel armhf ia64 i386 mips mipsel powerpc 
powerpcspe ppc64 ppc64el s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Tracks runtime library calls in dynamically linked programs
  ltrace is a debugging program which runs a specified command until it
diff -Nru ltrace-0.7.3/debian/copyright ltrace-0.7.3/debian/copyright
--- ltrace-0.7.3/debian/copyright   2015-07-03 17:20:13.0 +0200
+++ ltrace-0.7.3/debian/copyright   2017-01-05 09:58:40.0 +0100
@@ -1,4 +1,4 @@
-This is the Debian GNU/Linux's prepackaged version of the
+i-This is the Debian GNU/Linux's prepackaged version of the
 Dynamic Library Tracer ``ltrace''.
 
 It was downloaded from http://www.ltrace.org/
@@ -37,3 +37,4 @@
 or on the World Wide Web at `http://www.gnu.org/copyleft/gpl.html'.
 You can also obtain it by writing to the Free Software Foundation,
 Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+
diff -Nru ltrace-0.7.3/debian/lintian-overrides 
ltrace-0.7.3/debian/lintian-overrides
--- ltrace-0.7.3/debian/lintian-overrides   1970-01-01 01:00:00.0 
+0100
+++ ltrace-0.7.3/debian/lintian-overrides   2016-12-15 19:55:30.0 
+0100
@@ -0,0 +1,3 @@
+# ltrace: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
+ltrace: no-upstream-changelog
+ltrace: spelling-error-in-manpage usr/share/man/man1/ltrace.1.gz recieved 
received
diff -Nru ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch 
ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
--- ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
1970-01-01 01:00:00.0 +0100
+++ ltrace-0.7.3/debian/patches/add_elf_can_read_next_5c37171a.patch
2016-12-04 23:23:05.0 +0100
@@ -0,0 +1,57 @@
+From 5c37171a18bddfbc716d4f3da8b008a844eea4f7 Mon Sep 17 00:00:00 2001
+From: Petr Machata 
+Date: Tue, 5 Feb 2013 01:52:37 +0100
+Subject: Add elf_can_read_next
+
+---
+ ltrace-elf.c |   10 +-
+ ltrace-elf.h |3 +++
+ 2 files changed, 8 insertions(+), 5 deletions(-)
+
+Index: b/ltrace-elf.c
+===
+--- a/ltrace-elf.c
 b/ltrace-elf.c
+@@ -202,23 +202,23 @@ elf_get_section_named(struct ltelf *lte,
+ _p, );
+ }
+ 
+-static int
+-need_data(Elf_Data *data, GElf_Xword offset, GElf_Xword size)
++int
++elf_can_read_next(Elf_Data *data, GElf_Xword offset, GElf_Xword size)
+ {
+   assert(data != NULL);
+   if (data->d_size < size || offset > data->d_size - size) {
+   debug(1, "Not enough data to read %"PRId64"-byte value"
+ " at offset %"PRId64".", size, offset);
+-  return -1;
++  return 0;
+   }
+-  return 0;
++  return 1;
+ }
+ 
+ #define DEF_READER(NAME, SIZE)
\
+   int \
+   NAME(Elf_Data *data, GElf_Xword offset, uint##SIZE##_t

Bug#848316: [pkg-go] Bug#848316: etcd: I saw that A new upstream version is available: 3.0.15 - Is this possible to upgrade ?

2017-01-19 Thread TFAUCK 
On Sat, 14 Jan 2017 17:54:30 +1100 Dmitry Smirnov <only...@debian.org>
wrote:
> On Friday, 13 January 2017 1:57:33 PM AEDT TFAUCK wrote:
> > So what do we do for that issue ?
> 
> Hopefully fix it eventually by updating "etcd" package...
> 
> 
> > who's going to decide if there is a
> > need for new package or just and upgrade ?
> 
> That would be me... :)
> The matter is quite simple: if my understanding is correct, upstream no 
> longer support Etcd v2... The question is only who is going to update the 
> package and when.
> 
> Why do you think we need two packages and who is going to maintain 'em?
> 
> -- 
> All the best,
>  Dmitry Smirnov.

Hello,
I have checked and definitely etcd 2 package is no longer supported.
Migration to etcd 3 (and even etcd 3.1) is what must be done.
As making the package upgrade and supporting it, I am not too sure -
Initially I thought that maintainers of etcd 2.0 which are also
maintainers for packages relative to go were going to do it, but I may
be wrong there.
I can work with the package upgrade and submit the debdiff if that's the
idea ?

Thanks
Regards
Thierry

-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#848316: [pkg-go] Bug#848316: Bug#848316: etcd: I saw that A new upstream version is available: 3.0.15 - Is this possible to upgrade ?

2017-03-02 Thread TFAUCK 
On Wed, 8 Feb 2017 10:47:56 + "Potter, Tim" <timothy.pot...@hpe.com>
wrote:
> On 21 Jan 2017, at 2:10 PM, Dmitry Smirnov <only...@debian.org> wrote:
> > 
> > On Thursday, 19 January 2017 10:41:23 AM AEDT TFAUCK wrote:
> >> Initially I thought that maintainers of etcd 2.0 which are also
> >> maintainers for packages relative to go were going to do it, but I may
> >> be wrong there.
> > 
> > I'm not sure what are you trying to say...
> > Maintainers (upstream developers) of Etcd are not maintainers of Debian
> > package...
> > 
> > 
> >> I can work with the package upgrade and submit the debdiff if that's the
> >> idea ?
> > 
> > Whatever you can do to help is welcome. I suggest to start working on
> > dependency packages -- that's where usual >90% of effort will be spent...
> 
> I suddenly have a need for etcd3 and have done a quick run through building
> the dependencies.  There are only a half dozen new ones and they all
> build without very much tweaking.
> 
> I think an upgrade of grpclog is required and then it should be good.  Will
> keep working on it tomorrow.
> 
> 
> Tim.
Hello,
Have you bin able to go through it ? or is that delayed until someone
works on it ?
thx
Thierry
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#847923: RFS:ltrace/0.7.3-6.1

2016-12-12 Thread TFAUCK 
Package: sponsorship-requests
Severity: normal

 Dear mentors,

 I am looking for a sponsor for the package "ltrace".
 This is a packaging update :

 paflib (0.7.3-6.1) unstable; urgency=medium

 

This is a package update to support ppc64le arch.

Since there is no real release update, it contains patches as well as
packaging updates to fit debian current packaging rues.


  Package name: ltrace
  Version : 0.7.3-6.1
  Maintainer: Juan Cespedes 
  Homepage: http://ltrace.alioth.debian.org
  Section: utils

 To access further information about this package, please visit the
following URL:

 https://mentors.debian.net/package/ltrace


 Alternatively, one can download the package with dget using this command:

   dget -x
https://mentors.debian.net/debian/pool/main/l/ltrace/ltrace_0.7.3-6.1.dsc

 More information about ltrace can be obtained from
http://ltrace.alioth.debian.org



 Regards,
  Thierry Fauck


-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#836844: eigen3: autopkgtests fail on ppc64el - solution

2016-12-06 Thread TFAUCK 
Hello,
I found the missing information in POWER ISA

/To use a multiply-add to perform an IEEE or Java//
//compliant multiply, the addend must be -0.0. This//
//is necessary to insure that the sign of a zero result//
//will be correct when the product is -0.0 (+0.0 + -0.0//
//t +0.0, and -0.0 + -0.0t -0.0). When the sign of a//
//resulting 0.0 is not important, then +0.0 can be//
//used as an addend which may, in some cases,//
//avoid the need for a second register to hold a -0.0//
//in addition to the integer 0/floating-point +0.0 that//
//may already be available./

so the example shows it:

$ cat t2.c
#include "stdio.h"
#include "altivec.h"
int main() {
vector float X={ -1, 0, 0, 0 };
vector float Y={ -1, -1, -1, -2 };
vector float Z, V;
*vector float p4f_ZERO={ 0, 0, 0, 0 };**
**vector float p4f_mZERO={ -0.0, -0.0, -0.0, -0.0 };*
Z = vec_madd(X, Y, p4f_ZERO);
V = vec_madd(X, Y, p4f_mZERO);
printf("%f %f %f %f \n",Z[0], Z[1], Z[2], Z[3]);
printf("%f %f %f %f \n",V[0], V[1], V[2], V[3]);
vector float U;
U= X * Y ;
printf("%f %f %f %f \n",U[0], U[1], U[2], U[3]);
return(0);
}

$ gcc t2.c
debian@vm18:~$ ./a.out
1.00 0.00 0.00 0.00
*1.00 -0.00 -0.00 -0.00 *
1.00 -0.00 -0.00 -0.00

So the vector p4f_ZERO must be modified with a signed value of -0.0 in
order to have that function to work.

-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#848316: [pkg-go] Bug#848316: etcd: I saw that A new upstream version is available: 3.0.15 - Is this possible to upgrade ?

2017-01-13 Thread TFAUCK 
On Fri, 06 Jan 2017 11:50:53 +1100 Dmitry Smirnov 
wrote:
> On Wednesday, 4 January 2017 12:03:44 AM AEDT Potter, Tim wrote:
> > Hi there.  I've currently got someone working on a etcd3 package - still
> > tossing up whether to create a new binary package and keep etcd as
> > implicitly version 2 only.  That's what I'm leaning to at the moment.
> 
> I think we should just upgrade etcd v2 --> v3 without making any new 
> packages.
> 
> -- 
> All the best,
>  Dmitry Smirnov.
> 
> ---
> 
> The belief in a supernatural source of evil is not necessary; men alone
> are quite capable of every wickedness.
> -- Joseph Conrad
So what do we do for that issue ? who's going to decide if there is a
need for new package or just and upgrade ?

All the best
Thierry
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#836844: eigen3: autopkgtests fail on ppc64el

2016-12-02 Thread TFAUCK 
On Thu, 1 Dec 2016 16:15:50 +0100 Roger  wrote:
> On Sun, 13 Nov 2016 18:04:28 +0200 Graham Inggs  wrote:
> > Control: reopen -1
> > 
> > I've just checked eigen3 3.3.0-1 on plummer.debian.org, and it still outputs
> > 
> > forceMatrix*axisMatrix: -1  0  0
> >  0 -2  0
> >  0  0 -3
> > 
> > 
> I have checked with current dev. tree and problem remains
> I have tried compiler g++-4.9 and g++-5 and g++-6 and all are providing
> same error on ppc64le
> On x86_64 using g++-5 there is no error.
> 
> 
Digging through the code, I found the difference
src/Core/functors/BinaryFunctors.h:89
{ return internal::pmul(a,b); }

on x86_64 it calls at line 192
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))  _mm_mul_ps (__m128 __A, __m128 __B)
  │{
return (__m128) ((__v4sf)__A *
(__v4sf)__B);
}


when on ppc64le pmul() calls
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/PacketMath.h:361
return vec_madd(a,b, p4f_ZERO);

so I suspect there is something there


-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#836844: fixed in eigen3 3.3.1-2

2017-01-03 Thread TFAUCK 
Sounds working fine  - thanks
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#806720: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

2017-01-04 Thread TFAUCK 
Agree on frediz taking ownership of that bugs
Thanks

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#836382: Fwd: RFS:paflib/0.3.0-1

2016-09-02 Thread TFAUCK POP 

Package: sponsorship-requests
Severity: normal


Dear mentors, Gianfranco,

 I am looking for a sponsor for the package "paflib".
 This is a packaging update :

 paflib (0.3.0-1) unstable; urgency=medium

   * New upstream release

  -- Thierry Fauck  Fri, 02 Sep 2016 11:23:02 +0200


  Package name: paflib
  Version : 0.3.0-1
  Upstream Author : Carlos Eduardo Seo 
  URL : http://github.com/paflib/paflib/
  License : GPL-2+, mit
  Section : libs

 To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/paflib


 Alternatively, one can download the package with dget using this command:

   dget -x 
https://mentors.debian.net/debian/pool/main/p/paflib/paflib_0.3.0-1.dsc


 More information about paflib can be obtained from 
http://github.com/paflib/paflib/



 Regards,
  Thierry Fauck


--

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/