Bug#1065837: cappuccino: Please drop dependencies on python3-distutils

[Breno Leitao]

Hello Emmanuel,


On Wed, Jul 10, 2024 at 09:20:45PM -0300, Emmanuel Arias wrote:
> Dear maintainer,
> 
> I'm going to upload a NMU to fix this RC bug. I'm going to upload in
> DELAYED/3-days. I attached the patch that I applied.
> 
> If you have any objections or would you like to make the changes
> yourself please let me know.

Thank you so much for the upload. I am good with it!

Bug#1061688: rtl8821: WARNING: CPU: 37 PID: 1366 at drivers/iommu/dma-iommu.c:1091 iommu_dma_unmap_page+0x7d/0x90

[Breno Leitao]

Hello Salvatore,

On Mon, Jan 29, 2024 at 07:04:38PM +0100, Salvatore Bonaccorso wrote:
> Can you check if this happens as well with 6.7.1-1~exp1 in
> experimental?

Sure. I wil install the experimental kernel and see if it reproduces.
I didn't find an easy way to reproduce it, but, I can install a kernel
and uses until it crashes (or not).

Let's see.
> 
> As I understand this is a regression from 6.6.11-1 to 6.6.13-1, any
> chance you could bisect the upstream versions between 6.6.11 and
> 6.6.13 to identify the culprit?

Right. I am always in upstream and I have never seen this before. Maybe
it is luck, or a proper regression.

Let me test experimental and see if this reproduces. I will keep this
bug updated.

Thank you!

Bug#1008564: Assumes /usr/games/polygen is in $PATH; not true for root

[Breno Leitao]

On Mon, Sep 18, 2023 at 06:07:54PM +0100, William de Abreu Pinho wrote:
> I am completely new to maintenance and this is my first attempt to submit a 
> patch.
> 
> Please find attached the proposed changes, I hope these will suffice.

Thanks for the fix. As we had discussed in person, please attach the
.debdiff and I will ship a new package with this fix.

Thanks for your contribution to Debian.

Bug#1023962: pastebinit: pastebint does not work because it calls split() on a None object

[Breno Leitao]

Package: pastebinit
Version: 1.6-1
Severity: important
X-Debbugs-Cc: lei...@debian.org

Dear Maintainer,

I am not able to use `pastebinit` because it calls the .split() function
on a None object. Resulting in the following error:

$ pastebinit
Traceback (most recent call last):
  File "/usr/bin//pastebinit", line 67, in 
'XDG_CONFIG_DIRS').split(':'))) + ['/etc', '/usr/local/etc',
AttributeError: 'NoneType' object has no attribute 'split'


Thank you!
Breno

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-rc3+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pastebinit depends on:
ii  python3 3.10.6-2
ii  python3-distro  1.8.0-1

pastebinit recommends no packages.

pastebinit suggests no packages.

-- no debconf information

Bug#999145: cappuccino: diff for NMU version 0.5.1-10.1

[Breno Leitao]

On Wed, Nov 02, 2022 at 05:45:26PM -0300, Marcos Talau wrote:
> Control: tags 999145 + patch
> Control: tags 999145 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for cappuccino (versioned as 0.5.1-10.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

That is OK. Thanks for your contribution.

Bug#1023537: bpftrace/libbpf: SIGSEGV at btf_find_by_name_kind()

[Breno Leitao]

Package: bpftrace
Version: 0.16.0-1
Severity: normal
X-Debbugs-Cc: lei...@debian.org

Dear Maintainer,

bpftrace is segfault on everycommand when running on 6.0 kernel:

$ sudo gdb /usr/bin/bpftrace


(gdb) r -l
Starting program: /usr/bin/bpftrace -l
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
btf__type_cnt (btf=btf@entry=0x0) at ./src/btf.c:448
448 ./src/btf.c: No such file or directory.
(gdb) bt
#0  btf__type_cnt (btf=btf@entry=0x0) at ./src/btf.c:448
#1  0x77f59f48 in btf_find_by_name_kind (btf=0x0, start_id=1, 
type_name=0x7fffb360 "sched_fork", kind=12) at ./src/btf.c:721
#2  0x55617b46 in ?? ()
#3  0x5561821d in ?? ()
#4  0x5565f57f in ?? ()
#5  0x55661941 in ?? ()
#6  0x5569896f in ?? ()
#7  0x55699488 in ?? ()
#8  0x55604835 in ?? ()
#9  0x5559d376 in ?? ()
#10 0x7fffef44618a in __libc_start_call_main 
(main=main@entry=0x5559c010, argc=argc@entry=2, 
argv=argv@entry=0x7fffe538)
at ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7fffef446245 in __libc_start_main_impl (main=0x5559c010, 
argc=2, argv=0x7fffe538, init=, fini=, 
rtld_fini=, stack_end=0x7fffe528) at 
../csu/libc-start.c:381
#12 0x555ddd21 in ?? ()

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bpftrace depends on:
ii  libbpf0   1:0.8.0-1
ii  libbpfcc  0.24.0+ds-1+b1
ii  libc6 2.36-4
ii  libclang1-14  1:14.0.6-3
ii  libdw10.187-4
ii  libgcc-s1 12.2.0-9
ii  libllvm14 1:14.0.6-3
ii  libstdc++612.2.0-9

bpftrace recommends no packages.

bpftrace suggests no packages.

-- no debconf information

Bug#1010791: (no subject)

[Breno Leitao]

Package was finally uploaded to debian, and it is showing up in the
ftpmaster NEW queue now

https://ftp-master.debian.org/new.html

The next step is waiting for the ftpmaster to review the package for 
final inclusion in the debian archive.


Then, If everything is OK, I _think_ I will need to re-upload the 
package in the source format (dpkg-buildpackage -S), so it can go to 
stable, and we are good!


Thanks for you work, Salim!
Happy hacking!

Bug#1010791: (no subject)

[Breno Leitao]

Thanks for packaging this tool Michel. I gave it a try and this tool is
quite useful.

I've looked at the packaging and script, and they are sane. I will be
sponsoring this package.

Bug#970637: /var/lib/dpkg/info/nvme-cli.postinst: 11: uuidgen: not found

[Breno Leitao]

Oh sorry about it, I will have it fixed soon.

Bug#914797: ndctl: Please apply packaging fixes from Ubuntu

[Breno Leitao]

HI Jeremy,

On 11/27/18 10:46 AM, Jeremy Bicha wrote:
> Would you be ok with me NMUing these changes?

Sure, please go ahead and NMU, as you have been doing already.

Thanks for the support here.
Breno

Bug#907697: fortunes-br: Inconsistent use of accents in fortunes-br

[Breno Leitao]

On Fri, 31 Aug 2018 11:46:03 -0300 Rafael Vargas  wrote:
> Package: fortunes-br
> Version: 20160820
> Severity: minor
> 
> Dear Maintainer,
> 
> Throughout the entire fortune file, several phrases uses some accents
> (mainly the tilde) but don't use the other accents needed to be
> grammatically correct.
> 
> I could offer myself to correct the file, but I couldn't find the latest
> sources in order to send a patch.
> 
> Thanks in advance for your time.

Hi Rafael,

I would love your help here. I do not think we have the sources somewhere, if
you want to import it and fix the accents, I can import and start using your
repo as the upstream version.

Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

[Breno Leitao]

On Fri, 04 May 2018 23:22:15 +0300 Sergei Golovan  wrote:

> I would like to upload the tclreadline package to stretch. The package
> currently in stable misses a shared library for the ppc64el architecture,
> as indicated in [1]. I'm attaching the package diff for review. It's
> tested using he ppc64el QEMU installation, and it builds fine now.

I also tested on a real ppc64el machine and this debdiff fixes the problem.

Thanks Sergei!

Bug#897429: [Pkg-tcltk-devel] Bug#897429: ppc64el: Shared Object not available in the platform

[Breno Leitao]

Hi Sergei,

On Wed, May 02, 2018 at 06:25:55PM +, Sergei Golovan wrote:
> Hi Bruno,
> 
> If you have access to the ppc64el hardware, could you test the fix (I've
> attached a diff, which is to be applied to the 2.1.0-15 sources)? If it's
> okay, I'll ask the release team about a stable update.

Yes, I was able to test it and it is working as expected:

➜  dpkg -c tcl-tclreadline_2.1.0-15+deb9u1_ppc64el.deb | grep so
-rw-r--r-- root/root 67664 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/libtclreadline-2.1.0.so
lrwxrwxrwx root/root 0 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/libtclreadline.so -> libtclreadline-2.1.0.so

Thanks for working on it,
Breno

Bug#897429: ppc64el: Shared Object not available in the platform

[Breno Leitao]

Source: tclreadline
Version: 2.1.0-15
Severity: critical
Tags: patch

Dear maintainer,

I just found that this package is not generating the shared object for
ppc64el platform, as showed below:

  dpkg -c tcl-tclreadline_2.1.0-15_ppc64el.deb | grep lib/powerpc64le-linux-gnu
  drwxr-xr-x root/root 0 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/
  -rw-r--r-- root/root 25340 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/libtclreadline.a

Looking at the 'configure' process, I see the failure on detecting if
the shared object should be built. This is the build log line and
explains the problem.

  checking whether to build shared libraries... no

I checked against unstable/buster version (2.3) and this problem does
not happen anymore. So, this fix will only need to make Stretch.

The real cause of this problem is realted to the following exemption of
powerpc, which might be removed.

   case "$host_cpu" in
powerpc*) dynamic_linker=no ;
*) dynamic_linker='Linux ld.so' ;;


With the patch above, I can see the shared objects being generated:

  dpkg -c tcl-tclreadline_2.1.0-15+deb9u1_ppc64el.deb  | grep \.so
  -rw-r--r-- root/root 67664 2018-05-02 10:05 
./usr/lib/powerpc64le-linux-gnu/libtclreadline-2.1.0.so
  lrwxrwxrwx root/root 0 2018-05-02 10:05 
./usr/lib/powerpc64le-linux-gnu/libtclreadline.so -> libtclreadline-2.1.0.so

Bug#894221: (no subject)

[Breno Leitao]

Hello David,

In fact, I was not able to reproduce this bug on my machine, even on the same
version you reported the problem:

# /usr/sbin/nvme list --output-format=json

# echo $?
0

#/usr/sbin/nvme --version
nvme version 1.0

# ndctl  dpkg -l | grep nvme-cli
ii  nvme-cli1.0-3
   ppc64el  userspace tooling to control NVMe drives


Are you able to reproduce this issue on the upstream nvme-cli?

Bug#894221: nvme-cli: Got SIGSEGV when using --output-format=json with nvme list

[Breno Leitao]

Hi David,

On Tue, 27 Mar 2018 15:30:07 +0200 David Guyot
 wrote:

> While conducting trials using the nvme command, I noticed that the list
> argument produces SIGSEGV when used with --output-format=json, but not
> with --output-format=normal nor if this option is not specified: 
> 
> root@Alioth ~ {⌗0/⬓54}[0]꩜# nvme list --output-format=json
>   
> fish: 'nvme list --output-format=json' terminated by signal SIGSEGV
> (Erreur de frontière d'adresse)

Thanks. I found that this is already fixed on unstable branch, but it is
broken on older version.

I will find the commit that fixed it and cherry pick it back to version 1.0

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Breno Leitao]

Hi,

On 02/23/2018 03:52 PM, Aurelien Jarno wrote:

> DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> Debian POWER8 machines running ppc64el. While they boot correctly, then
> programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> no_rfi_flush to the command line does not change anything. Looking more
> in details, things looks scarying as some code actually get wrongly
> executed. Here are some build logs examples:
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> 
> While in the above case the packages fail to build from source, I guess
> there are also some cases of undetected corruptions.
> 
> I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> issue.

I talked to the powerpc maintainer about this problem, and in fact this is a 
knew
problem, since the 4.4 patches were 'backported' to 4.9 without success.

This is already fixed and in the stable tree already:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/arch/powerpc?h=linux-4.9.y

I understand that the commit ids are:
 * 3146a32b39cd78722869bca6e839b3c59155e012
 * efe8bc07c47fff196bbc0822e249a27ae0574d24
 * ec0084d082137b73460303b39f4089970a213ad7

But I suppose that Debian will do a full merge with the stable tree, then, I 
expect
that the next release will just work.

Bug#889895: disable building this package for Power architectures

[Breno Leitao]

Package: cpufrequtils
Version: 008-1
Severity: important
Tags: patch

Currently cpufrequtils does not work for Power architectures, including
powerpc, ppc64 and ppc64el.

Disabling the binary generation to avoid users to install it instead of
the official package (Linux-power), thus, causing unnecessary conflicts.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.14.0master+ (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cpufrequtils depends on:
ii  debconf [debconf-2.0]  1.5.64
ii  libc6  2.26-4
ii  libcpufreq0008-1
ii  lsb-base   9.20170808

cpufrequtils recommends no packages.

cpufrequtils suggests no packages.

-- debconf information excluded
diff -Nru cpufrequtils-008/debian/changelog cpufrequtils-008/debian/changelog
--- cpufrequtils-008/debian/changelog   2012-05-06 02:43:59.0 -0400
+++ cpufrequtils-008/debian/changelog   2018-02-08 07:34:37.0 -0500
@@ -1,3 +1,10 @@
+cpufrequtils (008-1.1) UNRELEASED; urgency=medium
+
+  * Remove the package binary package for Power architecture, since Power CPU
+family uses linux-cpupower to handle the machine Power management unit.
+
+ -- Breno Leitao <lei...@debian.org>  Thu, 08 Feb 2018 07:34:37 -0500
+
 cpufrequtils (008-1) unstable; urgency=low
 
   * Package the last available upstream vesion of cpufrequtils. Anything
diff -Nru cpufrequtils-008/debian/control cpufrequtils-008/debian/control
--- cpufrequtils-008/debian/control 2012-05-06 02:43:59.0 -0400
+++ cpufrequtils-008/debian/control 2018-02-08 07:34:37.0 -0500
@@ -7,7 +7,7 @@
 Homepage: http://kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
 
 Package: cpufrequtils
-Architecture: any
+Architecture: alpha amd64 arm64 armel armhf hppa hurd i386 ia64 kbsd64 kbsd32 
m68k mips mips64el mipsel s390x sh4 sparc64 x32
 Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 3.0)
 Description: utilities to deal with the cpufreq Linux kernel feature
  This package contains two utilities for inspecting and setting the

Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

This is a debdiff that fixes the problem. This is basically a cherry pick of
the patch that I got accepted upstream.


diff --git a/debian/changelog b/debian/changelog
index e8cc49ce..8af9b584 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ruby2.5 (2.5.0~preview1-1.1) UNRELEASED; urgency=medium
+
+  * Fixed FTBFS on ppc64el (Closes: 881772).
+
+ -- Breno Leitao <lei...@debian.org>  Tue, 05 Dec 2017 06:46:16 -0500
+
 ruby2.5 (2.5.0~preview1-1) unstable; urgency=medium
 
   [ Antonio Terceiro ]
diff --git a/debian/patches/0006-Fix-FTBFS-on-ppc64el.patch 
b/debian/patches/0006-Fix-FTBFS-on-ppc64el.patch
new file mode 100644
index ..90b06212
--- /dev/null
+++ b/debian/patches/0006-Fix-FTBFS-on-ppc64el.patch
@@ -0,0 +1,49 @@
+From b2047f79cce41695b3a3f84d88afd1b586680f29 Mon Sep 17 00:00:00 2001
+From: hsbt <hsbt@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>
+Date: Tue, 5 Dec 2017 01:10:13 +
+Subject: [PATCH] vm_core.h: Increase the Fiber stack size on powerpc64
+
+Currently the Fiber stack size is small for powerpc64 and it causes
+test/ruby/test_backtrace.rb test to break, since it is using a 8kb stack
+size.
+
+It breaks on powerpc64 due to the fact that a frame in the stack is
+usually 50% bigger on powerpc64 compared to Intel, due to some
+considerations:
+
+ * The powerpc64 minimum frame is 2x bigger than on Intel
+ * Powerpc has more registers that might be saved in the frame compared
+   to Intel.
+
+I ran the same ruby test that is failing on both Intel and Powerpc, and
+each Fiber frame is ~50% bigger on powerpc64 for every single lambda
+function, thus, we need to increase the stack size on powerpc64 to
+accomodate the same tests/applications.
+
+This fixes bug#13757.
+
+Signed-off-by: Breno Leitao <lei...@debian.org>
+
+git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61020 
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+---
+ vm_core.h | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/vm_core.h b/vm_core.h
+index 73b552edd30f..b25c68125c5e 100644
+--- a/vm_core.h
 b/vm_core.h
+@@ -585,8 +585,12 @@ typedef struct rb_vm_struct {
+ 
+ #define RUBY_VM_FIBER_VM_STACK_SIZE   (  16 * 1024 * sizeof(VALUE)) 
/*   64 KB or  128 KB */
+ #define RUBY_VM_FIBER_VM_STACK_SIZE_MIN   (   2 * 1024 * sizeof(VALUE)) 
/*8 KB or   16 KB */
+-#define RUBY_VM_FIBER_MACHINE_STACK_SIZE  (  64 * 1024 * sizeof(VALUE)) 
/*  256 KB or  512 KB */
++#define RUBY_VM_FIBER_MACHINE_STACK_SIZE  (  64 * 1024 * sizeof(VALUE)) 
/*  256 KB or  512 KB */ 
++#if defined(__powerpc64__)
++#define RUBY_VM_FIBER_MACHINE_STACK_SIZE_MIN  (  32 * 1024 * sizeof(VALUE)) 
/*   128 KB or  256 KB */
++#else
+ #define RUBY_VM_FIBER_MACHINE_STACK_SIZE_MIN  (  16 * 1024 * sizeof(VALUE)) 
/*   64 KB or  128 KB */
++#endif
+ 
+ /* optimize insn */
+ #define INTEGER_REDEFINED_OP_FLAG (1 << 0)
diff --git a/debian/patches/series b/debian/patches/series
index 96e4a00c..c83b68eb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
 0003-Mark-Gemspec-reproducible-change-fixing-784225-too.patch
 0004-Make-gemspecs-reproducible.patch
 0005-Exclude-tests-that-fail-on-Debian-builds.patch
+0006-Fix-FTBFS-on-ppc64el.patch

Bug#881772: Re: Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

Good new on this bug.

Yesterday I fixed this problem and created an PR[1] for the Ruby project.
Today the PR was finally accepted by the Ruby maintainer and now we have this 
problem
finally fixed uptream.

The fix on upstream branch is commit-id f79cce41695b3a3f84d88afd1b586680f29 [2]

I will now create a debdiff with this cherry-pick

[1] https://github.com/ruby/ruby/pull/1768
[2] https://github.com/ruby/ruby/commit/b2047f79cce41695b3a3f84d88afd1b586680f29

Bug#881772: Re: Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

Some additional info to this bug.

I found that Ruby was not finding the proper top of the stack to do the math
and check how big the stack is.

I just fixed it and create the following Pull request:

https://github.com/ruby/ruby/pull/1767/commits/ff74937bcd50127e1e6b4879fa3c76d83efa5e65

This still does *not* fix this problem, but this reduce it slightly. I am still 
working
to find the final solution.

Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

This is the minimum testcase that reproduces the problem:

-- lambda.rb --
 max = 20
 rec = lambda{|n|

   if n > 0
   rec[n-1]
   end
 }

 #rec[max]
 Fiber.new{
   rec[max]
 }.resume

That you should call with:
 # ./miniruby tool/runruby.rb  lambda.rb

Some further findings:

 * The problem is not reproducible if we use functions recursion instead of
lambda recursion.

 * The problem does not happen if we run the recursion outside of a Fiber.

Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

Hello,

On 11/15/2017 02:32 PM, Antonio Terceiro wrote:
>> Could you please take a look?

I had a chance to take a look at this issue and I found that this regression 
was caused by
the following commit id, and reverting it would allow the test to pass again.


 commit c4e2cf466448f4283fd3f8a17a73f5fa9b745fe1
 Author: normal <normal@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>
 Date:   Thu Jun 8 20:58:03 2017 +

 tool/runruby.rb: test with smallest possible machine stack

 Lets ensure none of our C functions use too much stack space and
 fix all excessive stack usage before releasing the next version.
 Reducing C stack usage should reduce conservative GC scanning
 time and improve performance.

 If there are platform-dependent test failures; excessive stack
 usage should be fixed; rather than increasing minimum values or
 removing these envs from testing.


This commit seems to be interim to guarantee that nothing is quite broken.

Looking further at the issue, I think that the stack alignment is wrong for 
ppc64el. ppc64el
uses 64k page size, so, if align the stack into the page, we do not see this 
issue, as the
following patch fixes the issue.


 commit aa11d386528bbeb0f138962b3073b01319e85678
 Author: Breno Leitao <lei...@debian.org)
 Date:   Mon Nov 27 10:47:00 2017 -0500

 stack: align to 64kb

 This is a workaround for ppc64el which uses 64kb page size. This align
 the stack to the page size. It shouldn't have issues with amd64, but I
 am not the expert.

 Signed-off-by: Breno Leitao <lei...@debian.org>

 diff --git a/vm_core.h b/vm_core.h
 index 41663fd43e..71f5ee5ba2 100644
 --- a/vm_core.h
 +++ b/vm_core.h
 @@ -576,7 +576,7 @@ typedef struct rb_vm_struct {
 
  /* default values */
 
 -#define RUBY_VM_SIZE_ALIGN 4096
 +#define RUBY_VM_SIZE_ALIGN 4096 * 16
 
  #define RUBY_VM_THREAD_VM_STACK_SIZE  ( 128 * 1024 * sizeof(VALUE))  
/*  512 KB or 1024 KB */
  #define RUBY_VM_THREAD_VM_STACK_SIZE_MIN  (   2 * 1024 * sizeof(VALUE))  
/*8 KB or   16 KB */


I will now get in touch with the Ruby community to see their opinion about it.
I will keep this bug updated.

Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Breno Leitao]

Hi Terceiro,

On 11/15/2017 02:32 PM, Antonio Terceiro wrote:
> Hi,
> 
> On Tue, Nov 14, 2017 at 06:16:22PM -0500, Aaron M. Ucko wrote:
>> Source: ruby2.5
>> Version: 2.5.0~preview1-1
>> Severity: important
>> Tags: upstream
>> Justification: fails to build from source
>> User: debian-powe...@lists.debian.org
>> Usertags: ppc64 ppc64el
>>
>> Builds of ruby2.5 for ppc64el and the non-release architecture ppc64
>> have been failing per the below excerpt from
>>
>> https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=ppc64el=2.5.0%7Epreview1-1=1510662722=0
>>
>> FTR, the ppc64 log, which exhibits the same error, is at
>>
>> https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=ppc64=2.5.0%7Epreview1-1=1510663941=0
>>
>> Could you please take a look?
> 
> Thanks for reporting.
> 
>> Thanks!
>>
>>   1) Error:
>> TestBacktrace#test_caller_lev:
>> SystemStackError: stack level too deep
>> /<>/test/ruby/test_backtrace.rb:96:in `times'
>> /<>/test/ruby/test_backtrace.rb:96:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:92:in `times'
>> /<>/test/ruby/test_backtrace.rb:92:in `block in 
>> test_caller_lev'
>> /<>/test/ruby/test_backtrace.rb:106:in `block in 
>> test_caller_lev'
>>
>> Finished tests in 517.516592s, 33.1661 tests/s, 4326.2574 assertions/s.
>> 17164 tests, 2238910 assertions, 0 failures, 1 errors, 85 skips
>>
>> ruby -v: ruby 2.5.0dev (2017-10-10) [powerpc64le-linux-gnu]
>> uncommon.mk:691: recipe for target 'yes-test-almost' failed
> 
> Dear POWER porters, would you be able to help with this?

Sorry for not looking at it yet. Unfortunately we will not be able to see it
this week, but I hope to start look at it next week.

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Breno Leitao]

Hi Dan,

> Hi Breno,
>
> That link has gone dead, can you repost the package?

The package is now on the NEW queue.

https://ftp-master.debian.org/new/ndctl_58.2-1.html

Are we able to get it from there?
Let me know if not, and I can re-upload to mentors.

Bug#878071: (no subject)

[Breno Leitao]

diff -Nru glibc-2.24/debian/changelog glibc-2.24/debian/changelog
--- glibc-2.24/debian/changelog 2017-08-26 05:09:24.0 -0400
+++ glibc-2.24/debian/changelog 2017-10-09 08:37:50.0 -0400
@@ -1,3 +1,9 @@
+glibc (2.24-18) unstable; urgency=medium
+
+  * Disable lock elision on ppc64el. Closes: #878071.
+
+ -- Breno Leitao <lei...@debian.org>  Mon, 09 Oct 2017 08:37:50 -0400
+
 glibc (2.24-17) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru glibc-2.24/debian/sysdeps/ppc64el.mk 
glibc-2.24/debian/sysdeps/ppc64el.mk
--- glibc-2.24/debian/sysdeps/ppc64el.mk2017-06-19 11:36:06.0 
-0400
+++ glibc-2.24/debian/sysdeps/ppc64el.mk2017-10-09 08:37:32.0 
-0400
@@ -1,5 +1,5 @@
 # configuration options for all flavours
-extra_config_options = --enable-multi-arch --enable-lock-elision 
--with-cpu=power8
+extra_config_options = --enable-multi-arch --with-cpu=power8
 
 # main library
 libc_rtlddir = /lib64

Bug#878071: ppc64el: Disable lock elision

[Breno Leitao]

Package: glibc-source
Version: 2.24-18
Severity: normal
Tags: patch

Dear glibc maintainers,

I think it is a good idea to disable lock elision on glibc for ppc64el
on 'sid' for now.  The motivation for this change is basically two:

1) There are some Hardware Transactional Memory[1] changes on POWER9 and that I 
would prefer to not
trust at this moment for such an important package. 

2) There are some hard to debug bugs that is being affected by this
feature[2], so, disabling it until we address all these bugs.

We should re-enable this feature once the two concerns above be addressed.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-October/164319.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122

Thank you,
Breno

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.14.0-rc2+ (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

glibc-source depends on no packages.

Versions of packages glibc-source recommends:
ii  xz-utils  5.2.2-1.3

glibc-source suggests no packages.

-- no debconf information

Bug#876667: RFS: pragha/1.3.3-1

[Breno Leitao]

Hello Gabriel,

On Tue, Sep 26, 2017 at 09:05:58PM +0200, Lukas Schwaighofer wrote:
> Hi Gabriel,
> 
> it seems you are getting the knack of it quickly :) .  I don't have
> any additional feedback.  I hope you're able to find a sponsor soon.

I am just doing a final review for the sponsor, and I found something
that annoys every developer, it seems that pragha does not re-builds
after an initial build.

It builds fine for the very first time, but if you try to re-build, the
directory stays dirty and does not allow the package to be rebuilt:

This is what I tried:

$ get -x
https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-1.dsc

$ cd pragha-1.3.3 

$ debuild ; debuild

You are going to see something like:

dpkg-source: error: cannot represent change to po/bg.gmo: binary file 
contents changed
dpkg-source: error: add po/bg.gmo in debian/source/include-binaries if 
you want to store the modified binary in the debian tarball

This means that your clean rules is not cleaning everything that was
generated during the build process.

Thank you and sorry for the delay,
Breno

Bug#876667: RFS: pragha/1.3.3-1

[Breno Leitao]

Hi Gabriel,

On 09/26/2017 04:05 PM, Lukas Schwaighofer wrote:

Hi Gabriel,

it seems you are getting the knack of it quickly :) .  I don't have
any additional feedback.  I hope you're able to find a sponsor soon.


I also re-reviewed the package, and it seems OK for me, although I must 
admit I do not have a lot of experience with Multimedia packages.


If no one else has any objection, I will go ahead in the next days and 
sponsor it.


Thank you,
Breno

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Breno Leitao]

On Sat, 9 Sep 2017 20:20:03 -0300 Roberto Oliveira
> > In that case please override this warning and write a comment describing
> > the reason.
> Fixed.
> 
> > libopagent1 should be Section: libs.
> Fixed.

Thanks Roberto.

wRar, do you still any concern about this package?

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Although lack of recent updates, we are still working on this problem.

Barry (on CC) is allocated to work on this issue and should have updates soon.

Bug#869237: (no subject)

[Breno Leitao]

Operf was part of Debian once and then it got removed.

Are you planning to be the maintainer for this package?

Bug#864532: (no subject)

[Breno Leitao]

Hello Hon,

I reviewed the package, and after the fixes we discussed and the legal
conversation[1], I think this package is ready to go to the NEW queue.

Thanks for your contribution to Debian.

[1] https://lists.debian.org/debian-legal/2017/07/msg00022.html


signature.asc
Description: PGP signature

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Some new discover I did today:

1) On function do_random(), the 'values' pointer is being corrupted after the
rand() syscall - In the failure case. If I remove the rand() function, I do
not see corruption.

2) If I get the original 'values' pointer, save it and check it later, it is
corrupted also. This guarantee that the there is no one else changing the
pointer. So, I suspect that this value is being corrupted during the context
switch or vsx unavailable tm (which is being called also).

This is the type of the pointer corruption I see:

>From 0x7fff8970 to 0x7fff88000970.

Since the array pointer changes, the 'r' value will point to r + the
corruption displacement.

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

hi Ryan,

On 07/11/2017 02:58 AM, Ryan Tandy wrote:
> Today I built Linux 4.12 from upstream source and the test program still
> crashes. I was looking at your fixes to initialize load_{fp,tm,vec} as well
> as someone else fixing the CONFIG_ALIVEC typo but none of those have helped.

Right, I tested it with the pending patches for HTM and the bug is still
there, so, I doubt is has been fixed already.

> I did confirm on this kernel that reverting 613036d9 still stops it from
> crashing. Tomorrow I will try to narrow it down to a specific change. There
> are only 4 hunks after all (the addition of msr_tm_active cannot be reverted
> as there are more calls to it now).

In fact I just did it and I found that the following patch fixes the
problem.  I am not able to understand why yet. Working on it right now.

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 9f3e2c932dcc..21bcb3b19758 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -231,7 +231,7 @@ void enable_kernel_fp(void)
 EXPORT_SYMBOL(enable_kernel_fp);
 
 static int restore_fp(struct task_struct *tsk) {
-   if (tsk->thread.load_fp || msr_tm_active(tsk->thread.regs->msr)) {
+   if (tsk->thread.load_fp) {
load_fp_state(>thread.fp_state);
current->thread.load_fp++;
return 1;

> It turns out it is _not_ compiler dependent. The test program compiled in a
> jessie chroot succeeds in that chroot and then crashes if I run the same
> binary in a stretch chroot. This also means I was wrong about the m{t,f}vsrd
> instructions being related, as gcc-4.9 doesn't emit them (for this particular
> program, at least).

I  understand that glibc might have VSX instructions, so, even if your
application is not using VSX instructions, it might be required
depending on the glibc version you are using, although the problem seems
to be on the float point (FP) side.

> objdump -d libpthread.so.0 output apparently lists some tbegin/tend
> instructions, but I suppose those could be selected at runtime?

Correct. I checked and Debian is enabling HTM[1] to do lock
ellision. It is not a option that you can change on runtime, we would
need to reconfigure/recompile glibc if we want to disable it.  There is
currently an effort to use glibc tunnables to enable/disable lock
elision at runtime, but this is still under development.

Out of curiosity, how did you bisect the kernel to find that commit-id?
Did you do it automatically?

[1] 
https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64el=2.24-12=1497900384=0
 (Check for --enable-lock-elision)

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

hi Ryan,

On Sun, Jul 09, 2017 at 08:56:59AM -0700, Ryan Tandy wrote:
> There seems to be a regression on powerpc64 (both endians) that can corrupt
> the vector-scalar registers (VSRs) in a threaded program.
> 
> I believe the bad commit is this one:
> 
> 4.9.0: 
> https://github.com/torvalds/linux/commit/dc16b553c949e81f37555777dc7bab66d78285a7
> 4.8.6: 
> https://github.com/linux-stable/linux-stable/commit/613036d9e91990f2043130ff8f78fd770432b3de

Nice work!

> My program is not using transactional memory itself, but I don't know what
> libc/libpthread might do internally.

That is interesting. I also found a bug last week related to hardware
transactional memory, and it corrupts vector-scalar register 0 (vs0)
when using hardware transactional memory. In our case, every exception
would cause a wrong reclaim (grab the register values from the
checkpointed area), which will affect later, the recheckpoint (put the
stacked registers into the checkpointed area). This is specific for
hardware transactional memory.

The full description of the bug and a possible patch should be found at:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-July/160117.html

> 4.8.7-1 is the first Debian kernel where I observe the crash. I rebuilt that
> package with the above commit reverted and it went away.

Anyway, this is what I am going to investigate now:

1) If glibc's pthread method is using hardware transactional memory by
default.  I remember that upstream enabled it once and then disabled by
default.

2) Investigate this commit ID and check for a possible corruption
depending on the result above.

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Hey Adrian,

On Thu, Jul 06, 2017 at 10:44:21PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Breno!
> 
> On 07/06/2017 09:31 PM, Breno Leitao wrote:
> > I think I found the real case of the problem here. There is an array
> > being allocated, and initialized until 'i'.
> > 
> > Later, we use a random number 'r' to access this array, and it will fail
> > if 'r' is bigger than 'i', since any value bigger than 'i' will not be
> > initialized. It might fail harder if 'r' is being allocated than 'nvalues', 
> > but
> > I didn't get this scenario during my debugs.
> 
> Interesting bug. I wonder how this bug is only triggering on ppc*. Is that
> code that is run on these targets only?

In fact, doing further debugs I understand that the problem is somewhere
else, and what I am seeing is just a consequence of a prior error that was not
prior handled. This is the test case:

 for ( i = 0, e = ldap_first_entry( ld, res ); e != NULL; i++, e = 
ldap_next_entry( ld, e ) )
 {
 values[ i ] = ldap_get_dn( ld, e );
 }
 values[ i ] = NULL;

 ...

 for ( i = 0; i < innerloop; i++ ) {
 int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0);

 do_read( ld, values[ r ],
 srchattrs, noattrs, nobind, 1, maxretries,
 delay, force, chaserefs, idx );
 }


In ppc64el case, ldap_first_entry() is returning NULL, thus values[], other
than values[0], but the code will contain garbage and we will interate over it
later.

That said, I understand that there are two bugs:

1) we shouldn't iterate over values[] if it is bogus.
2) ldap_first_entry() shouldn't return NULL (real problem)

So, answering your question. My patch *didn't* fix the real issue (2), but the
consequence of it. That explains why we do not see this on other systems.

Anyway, I am still investigating the real problem here, and Howard, from
OpenLdap, is kindly helping.

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Ryan,

> Nice. I was able to reproduce it and debug it further. The problem seems
> to be related to a invalid branch/jump, the the next address is not
> memory mapped, thus the segfault. The new address is completely random,
> and definitely is wrong. 

I think I found the real case of the problem here. There is an array
being allocated, and initialized until 'i'.

Later, we use a random number 'r' to access this array, and it will fail
if 'r' is bigger than 'i', since any value bigger than 'i' will not be
initialized. It might fail harder if 'r' is being allocated than 'nvalues', but
I didn't get this scenario during my debugs.

That is how I see the array and how we are trying to access it:

0 invalues  RAND_MAX
|-|---|--|
| initialized |   mapped  | unmapped |
|-|---|--|

I understand that forcing the values to be smaller than 'i' is what we want.

This is a patch I've created to fix this problem. The problem seems to happen
upstream also. If this patch is OK for you , I will create a pull request
to send this fix upstream.

---

diff --git a/tests/progs/slapd-mtread.c b/tests/progs/slapd-mtread.c
index c9c872918..15316b360 100644
--- a/tests/progs/slapd-mtread.c
+++ b/tests/progs/slapd-mtread.c
@@ -635,7 +635,7 @@ do_random( LDAP *ld,
int i = 0, do_retry = maxretries;
char*attrs[ 2 ];
int rc = LDAP_SUCCESS;
-   int nvalues = 0;
+   int maxnvalue, nvalues = 0;
char**values = NULL;
LDAPMessage *res = NULL, *e = NULL;
charthrstr[BUFSIZ];
@@ -668,6 +668,7 @@ do_random( LDAP *ld,
values[ i ] = ldap_get_dn( ld, e );
}
values[ i ] = NULL;
+   maxnvalue = i;

ldap_msgfree( res );

@@ -680,6 +681,7 @@ do_random( LDAP *ld,

for ( i = 0; i < innerloop; i++ ) {
int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0);
+   r %= maxnvalue;

do_read( ld, values[ r ],
srchattrs, noattrs, nobind, 1, maxretries,

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Hi Ryan,

On Mon, Jul 03, 2017 at 03:39:35PM -0700, Ryan Tandy wrote:
> Hi debian-powerpc,
>
> Would a ppc64(el) porter be able to help me look at #866122? I have
> requested a porterbox account but it's not gone through yet, and I am unable
> to reproduce the issue at all in a qemu VM.

You can also request a VM on the minicloud at
http://openpower.ic.unicamp.br/minicloud/ if you wish. They are usually
quick on creating accounts.

> The openldap test suite is failing on ppc64 and ppc64el in stretch and
> unstable: the slapd-mtread helper program segfaults (exit 139) in a certain
> test case.
>
> It looks like the builds tend to succeed on jessie's kernel and fail on
> stretch's kernel:

In fact, this problem seems to reproduce once in a while, thus, I would
not trust that it might be related to the kernel/gcc combination at this
very beginning. I am suspecting that it might be related to the amount
of threads created and the order, but I do not have a conclusion yet.
Still investigating.

>  apt-get build-dep openldap
>  apt-get source openldap
>  cd openldap-*/
>  DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -T build
>  cd debian/build/tests
>  ./run -b bdb test060-mt-hot

Nice. I was able to reproduce it and debug it further. The problem seems
to be related to a invalid branch/jump, the the next address is not
memory mapped, thus the segfault. The new address is completely random,
and definitely is wrong. The link register (LR), which is register that
shows the return of the branch (similar to call() on amd64) is always
constant when ALSR is disabled. Other than that, I also saw a stack
corruption, which caused the backtrace to be completely bogus.

Anyway, myself and a colleague are still investigating this problem. I will keep
you informed of the progress of this issue.

Thanks,
Breno

Bug#842831: closed by Robert Luberda <rob...@debian.org> (Re: Bug#842831: ppc64el: Shows wrong CPU frequency/clock)

[Breno Leitao]

On Sat, Apr 15, 2017 at 10:00:06AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sysstat package:

Thank you!

Bug#856809: (no subject)

[Breno Leitao]

There is an upstream fix for this problem, targeting both gcc trunk and GCC-6:

On GCC-6 branch it is id 246509


r246509 | meissner | 2017-03-27 16:35:35 -0300 (Mon, 27 Mar 2017) | 42 lines

[gcc]
2017-03-27  Michael Meissner  

Back port from trunk
2017-03-27  Michael Meissner  

PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Combine bswap
HImode and SImode with zero extend to DImode to one insn.
(bswap2_extenddi): Likewise.
(bswapsi2_extenddi): Likewise.
(bswaphi2_extendsi): Likewise.
(bswaphi2): Combine bswap HImode and SImode into one insn.
Separate memory insns from swapping register.
(bswapsi2): Likewise.
(bswap2): Likewise.
(bswaphi2_internal): Delete, no longer used.
(bswapsi2_internal): Likewise.
(bswap2_load): Split bswap HImode/SImode into separate load,
store, and gpr<-gpr swap insns.
(bswap2_store): Likewise.
(bswaphi2_reg): Register only splitter, combine with the splitter.
(bswaphi2 splitter): Likewise.
(bswapsi2_reg): Likewise.
(bswapsi2 splitter): Likewise.
(bswapdi2): If we have the LDBRX and STDBRX instructions, split
the insns into load, store, and register/register insns.
(bswapdi2_ldbrx): Likewise.
(bswapdi2_load): Likewise.
(bswapdi2_store): Likewise.
(bswapdi2_reg): Likewise.

Bug#853580: nvme-cli: ftbfs with GCC-7

[Breno Leitao]

Hello doko,

I tried to reproduce this problem, but, I just see a warning other than
an error:

I am building the package on 'unstable' using debuild:

  cc -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D__CHECK_ENDIAN__ -g -O2 
-fdebug-prefix-map=/home/breno/source/nvme-cli-1.1=.  -fstack-protector-strong 
-Wformat -Werror=format-security -std=gnu99 -DNVME_VERSION='"1.1"' nvme.c -o 
nvme argconfig.o suffix.o parser.o nvme-print.o nvme-ioctl.o nvme-lightnvm.o 
fabrics.o json.o plugin.o intel-nvme.o lnvm-nvme.o memblaze-nvme.o 
nvme-models.o -Wl,-z,relro -Wl,-z,now

  nvme.c: In function ‘list’:
  nvme.c:849:35: warning: ‘%s’ directive output may be truncated writing
  up to 255 bytes into a region of size 251 [-Wformat-truncation=]
 snprintf(path, sizeof(path), "%s%s", dev, devices[i]->d_name);
^~

I am using GCC version 7.0.1, as shown:

  ➜  nvme-cli-1.1 cc --version
  cc (Debian 7-20170302-1) 7.0.1 20170302 (experimental) [trunk revision 245832]
  Copyright (C) 2017 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.

Bug#857078: ppc64el: Package is segfaulting

[Breno Leitao]

Control: tags -1 patch

An update on this bug. Rich was able to create a patch that fixes this problem.

http://www.openwall.com/lists/musl/2017/03/08/2

Can we cherry pick it once it gets accept upstream?
diff --git a/arch/powerpc64/reloc.h b/arch/powerpc64/reloc.h
index e1bad00..faf70ac 100644
--- a/arch/powerpc64/reloc.h
+++ b/arch/powerpc64/reloc.h
@@ -27,6 +27,6 @@
 	"	bl 1f \n" \
 	"	.long " #sym "-. \n" \
 	"1:	mflr %1 \n" \
-	"	lwz %0, 0(%1) \n" \
+	"	lwa %0, 0(%1) \n" \
 	"	add %0, %0, %1 \n" \
 	: "=r"(*(fp)), "=r"((long){0}) : : "memory", "lr" )

Bug#857078: ppc64el: Package is segfaulting

[Breno Leitao]

Package: musl
Version: 1.1.16-2
Severity: normal
Tags: upstream

Musl package on Debian on ppc64le is broken.

When running any software with it, it segfaults. Doing a little bit of
debugging I found that libc.so is broken.

I got the upstream code, and found that the problme is also
reproducible.

I found that the problem only happen when compiling with -O2 and -O3. If
I compile musl with -O1 or -O0, the problm does not happen.

This is the bt of the code that crashes:

(gdb) bt
#0  0x000148b84dc0 in ?? ()
#1  0x48bdb8dc in _dlstart_c (sp=0x3fffc33294b0, dynv=) 
at ldso/dlstart.c:147
#2  0x48bdebe0 in _dlstart ()

(gdb) up
#1  0x48bdb8dc in _dlstart_c (sp=0x3fffc33294b0, dynv=) 
at ldso/dlstart.c:147
147 dls2((void *)base, sp);

$ gcc --version
gcc (Debian 6.3.0-5) 6.3.0 20170124

My suggestion would be to use -O1 at this moment for ppc64el. I can
create the patch if you wish.

Upstream bug: http://www.openwall.com/lists/musl/2017/03/07/2


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: ppc64el (ppc64le)
Foreign Architectures: powerpc

Kernel: Linux 4.8.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#856665: jessie-pu: package commons-daemon/1.0.15-6

[Breno Leitao]

Hi Adam,

On Fri, Mar 03, 2017 at 05:41:51PM +, Adam D. Barratt wrote:
> On 2017-03-03 17:29, Breno Leitao wrote:
> >Package jsvc (commons-daemon) contains a patch enabling ppc64el on
> >version 1.0.15-6 (currently on Jessie), but it does not work. A new
> >patch required to add functional support for commons-daemon on ppc64el.
> >
> >This patch is already commited on upstream as in Stretch.
> >
> >You can find more information about this bug at #856560.
> >
> >Let me know if I can update a fixed package in stable.
> 
> We'd need to see a source debdiff for the proposed (and tested) package
> first, please.

Sure. This is the debdiff I have. I tested it and it solves the problem
on ppc64el, and it does not seem cause any regression on amd64.
diff -Nru commons-daemon-1.0.15/debian/changelog 
commons-daemon-1.0.15/debian/changelog
--- commons-daemon-1.0.15/debian/changelog  2014-11-11 10:01:45.0 
-0500
+++ commons-daemon-1.0.15/debian/changelog  2017-03-03 13:47:51.0 
-0500
@@ -1,3 +1,11 @@
+commons-daemon (1.0.15-6+deb8u1) jessie; urgency=medium
+
+  * Team upload.
+  * This package is broken on Jessie, showing "Cannot find any VM in Java
+Home". Fixing it. (Closes: #856560)
+
+ -- Breno Leitao <lei...@debian.org>  Fri, 03 Mar 2017 13:47:51 -0500
+
 commons-daemon (1.0.15-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru commons-daemon-1.0.15/debian/patches/ppc64el.diff 
commons-daemon-1.0.15/debian/patches/ppc64el.diff
--- commons-daemon-1.0.15/debian/patches/ppc64el.diff   2014-11-11 
10:01:45.0 -0500
+++ commons-daemon-1.0.15/debian/patches/ppc64el.diff   2017-03-03 
13:34:37.0 -0500
@@ -1,7 +1,7 @@
 Description: Add ppc64el support
 Author: Colin Watson <cjwat...@ubuntu.com>
-Forwarded: https://issues.apache.org/jira/browse/DAEMON-326
-Last-Update: 2014-11-06
+Forwarded: https://issues.apache.org/jira/browse/DAEMON-358
+Last-Update: 2017-03-02
 
 Index: b/src/native/unix/configure
 ===
@@ -12,9 +12,9 @@
  HOST_CPU=aarch64
  ;;
 +  powerpc64le)
-+CFLAGS="$CFLAGS -DCPU=\\\"powerpc64le\\\""
-+supported_os="powerpc64le"
-+HOST_CPU=powerpc64le
++CFLAGS="$CFLAGS -DCPU=\\\"ppc64le\\\""
++supported_os="ppc64le"
++HOST_CPU=ppc64le
 +;;
*)
  echo "$as_me:$LINENO: result: failed" >&5
@@ -28,9 +28,9 @@
  HOST_CPU=aarch64
  ;;
 +  powerpc64le)
-+CFLAGS="$CFLAGS -DCPU=\\\"powerpc64le\\\""
-+supported_os="powerpc64le"
-+HOST_CPU=powerpc64le
++CFLAGS="$CFLAGS -DCPU=\\\"ppc64le\\\""
++supported_os="ppc64le"
++HOST_CPU=ppc64le
 +;;
*)
  AC_MSG_RESULT([failed])


pgpo1GLhts7v8.pgp
Description: PGP signature

Bug#856665: jessie-pu: package commons-daemon/1.0.15-6

[Breno Leitao]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Dear Release team,

Package jsvc (commons-daemon) contains a patch enabling ppc64el on
version 1.0.15-6 (currently on Jessie), but it does not work. A new
patch required to add functional support for commons-daemon on ppc64el.

This patch is already commited on upstream as in Stretch.

You can find more information about this bug at #856560.

Let me know if I can update a fixed package in stable.

Thank you,
Breno

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: ppc64el (ppc64le)
Foreign Architectures: powerpc

Kernel: Linux 4.8.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#855377: genwqe-user: FTBFS on 32-bit arches

[Breno Leitao]

Hi Aaron,

On Fri, 17 Feb 2017 09:48:32 -0500 "Aaron M. Ucko"  wrote:
> For the record, the (immediate) problem is that the gzseek64 and
> gzoffset64 wrappers in software.c specify the wrong return type
> (z_off_t rather than the correct z_off64_t, which is equivalent only
> on 64-bit systems):

That is correct. I was able to fix it following your suggestion. Another
issue appeared after this one was fixed, and it is fixed now. It seems
that genwqe is now building on 32 bits arches.

I have a pull request at
https://github.com/ibm-genwqe/genwqe-user/pull/142


signature.asc
Description: PGP signature

Bug#856560: ppc64el: "Cannot find any VM in Java Home" issue

[Breno Leitao]

Hello,

This is a debdiff that fixes this problem on Power.

Thanks

diff -Nru commons-daemon-1.0.15/debian/changelog 
commons-daemon-1.0.15/debian/changelog
--- commons-daemon-1.0.15/debian/changelog  2017-01-04 18:56:59.0 
-0500
+++ commons-daemon-1.0.15/debian/changelog  2017-03-02 07:51:51.0 
-0500
@@ -1,3 +1,9 @@
+commons-daemon (1.0.15-7.1) unstable; urgency=medium
+
+  * Fixes "Cannot find any VM in Java Home" on ppc64el (Closes: #856560)
+
+ -- Breno Leitao <lei...@debian.org>  Thu, 02 Mar 2017 07:51:51 -0500
+
 commons-daemon (1.0.15-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru commons-daemon-1.0.15/debian/patches/ppc64el.diff 
commons-daemon-1.0.15/debian/patches/ppc64el.diff
--- commons-daemon-1.0.15/debian/patches/ppc64el.diff   2017-01-04 
18:56:59.0 -0500
+++ commons-daemon-1.0.15/debian/patches/ppc64el.diff   2017-03-02 
07:50:01.0 -0500
@@ -1,7 +1,7 @@
 Description: Add ppc64el support
 Author: Colin Watson <cjwat...@ubuntu.com>
-Forwarded: https://issues.apache.org/jira/browse/DAEMON-326
-Last-Update: 2014-11-06
+Forwarded: https://issues.apache.org/jira/browse/DAEMON-358
+Last-Update: 2017-03-02
 
 Index: b/src/native/unix/configure
 ===
@@ -12,9 +12,9 @@
  HOST_CPU=aarch64
  ;;
 +  powerpc64le)
-+CFLAGS="$CFLAGS -DCPU=\\\"powerpc64le\\\""
-+supported_os="powerpc64le"
-+HOST_CPU=powerpc64le
++CFLAGS="$CFLAGS -DCPU=\\\"ppc64le\\\""
++supported_os="ppc64le"
++HOST_CPU=ppc64le
 +;;
*)
  echo "$as_me:$LINENO: result: failed" >&5
@@ -28,9 +28,9 @@
  HOST_CPU=aarch64
  ;;
 +  powerpc64le)
-+CFLAGS="$CFLAGS -DCPU=\\\"powerpc64le\\\""
-+supported_os="powerpc64le"
-+HOST_CPU=powerpc64le
++CFLAGS="$CFLAGS -DCPU=\\\"ppc64le\\\""
++supported_os="ppc64le"
++HOST_CPU=ppc64le
 +;;
*)
  AC_MSG_RESULT([failed])

Bug#856560: ppc64el: "Cannot find any VM in Java Home" issue

[Breno Leitao]

Package: jsvc
Version: 1.0.15-7
Severity: serious
Tags: patch

Hello, package jsvc does not work on ppc64el right now.

On ppc64 and ppc64le archs jsvc looks for jvm.cfg and JVM shared objects
in the wrong path. Be it used with IBM Java or OpenJDK (where the
problem was first encountered), there is no dir called power64 or
power64le. Instead ppc64 and ppc64le are used. In doing so, it fails
with "Cannot find any VM in Java Home"

I am attaching a patch that fix this issue, as fixed upstream:

https://issues.apache.org/jira/browse/DAEMON-358

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: ppc64el (ppc64le)
Foreign Architectures: powerpc

Kernel: Linux 4.8.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jsvc depends on:
ii  libc6   2.24-9
ii  libcommons-daemon-java  1.0.15-7

Versions of packages jsvc recommends:
ii  default-jre-headless [java2-runtime-headless]2:1.8-58
ii  openjdk-8-jre-headless [java2-runtime-headless]  8u121-b13-3

jsvc suggests no packages.

-- no debconf information

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Breno Leitao]

> I can work on it if Nish is not planning to submit his package to Debian.

I just created the package and it is at mentors.

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

Any review is appreciated. If no problems are found, I am willing to upload it.

Bug#853755: Bug#852811: fixed in systemd 232-16

[Breno Leitao]

Hi Martin,

On Thu, 09 Feb 2017 17:34:33 + Martin Pitt  wrote:
> Source: systemd
> Source-Version: 232-16

How will it show up in Stretch?

Are you going to move systemd to 232-16 or backport the patch to stretch 232-15?

Thank you,
Breno

Bug#855061: ITP: ndctl -- ndctl is a utility for managing the "libnvdimm" kernel subsystem.

[Breno Leitao]

Package: wnpp
Severity: wishlist
Owner: Breno Leitao <lei...@debian.org>

* Package name: ndctl
  Version : v55
  Upstream Author : Dan Williams
* URL : https://github.com/pmem/ndctl
* License : GPL
  Programming Lang: C
  Description : ndctl is a utility for managing the "libnvdimm" kernel 
subsystem.

ndctl is a utility for managing the "libnvdimm" kernel subsystem.

This includes provisioning capacity (namespaces) and enumerating,
enabling and disabling the devices associated with an NVDIMM bus.

There is RFS already opened:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829257

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Breno Leitao]

Hi Dan,

On 02/07/2017 05:03 PM, Dan Williams wrote:
> On Tue, Feb 7, 2017 at 10:55 AM, Breno Leitao <bren...@br.ibm.com> wrote:
>> Is there anyone working on packaging ndctl? If not, I have interest in
>> working on it.
>>
> 
> No, I don't think there is.
> 
> Nish had put together a snap package here:

It seem that the package is not a snap, but a proper 'debianized' package.

> https://launchpad.net/~nacc/+archive/ubuntu/nvdimm
> 
> ...but I don't think he's working on a Debian package. I'd love to see
> it integrated, let me know if I can help.

I can work on it if Nish is not planning to submit his package to Debian.

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Breno Leitao]

Is there anyone working on packaging ndctl? If not, I have interest in
working on it.

Bug#841185: closing RFS: genwqe-user/4.0.18-1 [ITP #826774]

[Breno Leitao]

Hi Fernando,

On Tue, 31 Jan 2017 22:44:49 -0200 Fernando Seiti Furusato
 wrote:
> I fixed some problems with the package, that is why I reopened this RFS.

This packages sounds in a good shape for me. If no one has objection to it, I
would like to sponsor it to be included in contrib archive.

Bug#853888: bpfcc not building on ppc64el and aarch64

[Breno Leitao]

Source: bpfcc
Version: 0.2.0
Severity: normal

Currently bpfcc does not build on ppc64el (and aaarch64) due to missing
luajit package.

The luajit upstream situation for the new architecture is not clear
, so, Debian have a luajit package in the experimental archive that
contains the ppc64el patch (still not accepted upstream).

I am planning on how to enable it for ppc64el, Can we depend on 
experimental package for ppc64el? If not, can we depend on lua instead
of luajit?

Thank you,
Breno

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: ppc64el (ppc64le)
Foreign Architectures: powerpc

Kernel: Linux 4.8.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#851686: Please enable ppc64el to build

[Breno Leitao]

Package: musl
Version: 1.1.16-1
Severity: normal
Tags: patch

Currently musl has ppc64el binaries disabled, although the code is
there.

This bug is to enable ppc64el. The trick thing is to use 64-bits long
double, mainly because 128-bits double uses non-IEEE standard which
breaks "configure".

I am attaching the patch that does this job.

Thank you,
Breno

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: ppc64el (ppc64le)
Foreign Architectures: powerpc

Kernel: Linux 4.8.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru musl-1.1.16/debian/changelog musl-1.1.16/debian/changelog
--- musl-1.1.16/debian/changelog	2017-01-03 16:38:49.0 -0500
+++ musl-1.1.16/debian/changelog	2017-01-17 11:45:02.0 -0500
@@ -1,3 +1,10 @@
+musl (1.1.16-1.1) UNRELEASED; urgency=medium
+
+  * Enable musl to build on ppc64el. In order to do it, using type "long
+double" as "double".
+
+ -- Breno Leitao <lei...@debian.org>  Tue, 17 Jan 2017 11:45:02 -0500
+
 musl (1.1.16-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru musl-1.1.16/debian/control musl-1.1.16/debian/control
--- musl-1.1.16/debian/control	2017-01-03 16:27:08.0 -0500
+++ musl-1.1.16/debian/control	2017-01-17 11:34:49.0 -0500
@@ -9,7 +9,7 @@
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/musl.git
 
 Package: musl
-Architecture: arm64 musl-linux-arm64 armel armhf musl-linux-armhf i386 musl-linux-i386 amd64 musl-linux-amd64 mips musl-linux-mips mipsel musl-linux-mipsel mips64el musl-linux-mips64el s390x musl-linux-s390x sh4 musl-linux-sh4
+Architecture: arm64 musl-linux-arm64 armel armhf musl-linux-armhf i386 musl-linux-i386 amd64 musl-linux-amd64 mips musl-linux-mips mipsel musl-linux-mipsel mips64el musl-linux-mips64el s390x musl-linux-s390x sh4 musl-linux-sh4 ppc64el
 Multi-Arch: same
 Depends: ${misc:Depends}
 Description: standard C library
@@ -21,7 +21,7 @@
 
 Package: musl-dev
 Section: libdevel
-Architecture: arm64 musl-linux-arm64 armel armhf musl-linux-armhf i386 musl-linux-i386 amd64 musl-linux-amd64 mips musl-linux-mips mipsel musl-linux-mipsel mips64el musl-linux-mips64el s390x musl-linux-s390x sh4 musl-linux-sh4
+Architecture: arm64 musl-linux-arm64 armel armhf musl-linux-armhf i386 musl-linux-i386 amd64 musl-linux-amd64 mips musl-linux-mips mipsel musl-linux-mipsel mips64el musl-linux-mips64el s390x musl-linux-s390x sh4 musl-linux-sh4 ppc64el
 Provides: ${libc-dev:Provides}
 Depends: ${misc:Depends}, musl (= ${binary:Version}), ${linux-libc-dev:Depends}
 Recommends: ${linux-musl-dev:Recommends}
diff -Nru musl-1.1.16/debian/rules musl-1.1.16/debian/rules
--- musl-1.1.16/debian/rules	2017-01-03 15:59:58.0 -0500
+++ musl-1.1.16/debian/rules	2017-01-17 11:43:36.0 -0500
@@ -25,6 +25,11 @@
   MUSL_ARCH=i386
   MUSL_TRIPLE=i386-linux-musl
 endif
+
+ifneq (,$(findstring ppc64el,$(DEB_HOST_ARCH)))
+  CFLAGS += -mlong-double-64
+endif
+
 export MUSL_ARCH
 export MUSL_TRIPLE
 

Bug#728955: libatomic-ops: diff for NMU version 7.4.2-1.2

[Breno Leitao]

Hi Adrian,

On 01/04/2017 08:50 AM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> The current version 7.4.4-3 of libatomic-ops builds fine on all architectures 
> [1].
> Can we close this or am I missing something?

I understand that they are building because the tests are being bypassed as
an workaround.

Take a look at debian/rules that says:

  ifeq (,$(findstring $(DEB_BUILD_ARCH), powerpc ppc64 ppc64el armel))
DEB_MAKE_CHECK_TARGET := check
  endif

Bug#824573: [Pkg-hhvm-team] Bug#824573: hhvm: Enable hhvm to be built on ppc64el

[Breno Leitao]

Hello Faidon,

On 12/17/2016 10:54 PM, Faidon Liambotis wrote:
> severity 824573 wishlist
> thanks
> 
> Hi Breno,
> 
> On Tue, May 17, 2016 at 01:12:12PM -0400, Breno Leitao wrote:
>> HHVM is being ported to ppc64el arch[1], and at the moment, 100% of the 1041
>> test runs fine on the platform.
>>
>> HHVM, as current version 3.12, is able to run in interpreted mode (JIT
>> disabled)[2], so, I think we should go ahead and enable it to be built on 
>> ppc64el.
>> I will working to have it enabled completely in the ppc64el platform.
>>
>> The following patch just enable the built on ppc64el.
> 
> Thanks for your bug report and patch, appreciated -- and very sorry for
> the late response.
> 
> It's good to know that HHVM works on ppc64el these days -- I've seen
> work happening on the upstream git as well, so that's definitely great
> to hear! :) It looks like upstream is working on arm64 as well, so that
> may be an option for us as well.
> 
> Unfortunately, the package will currently FTBFS if I apply your patch:
> we build-depend on ocaml-native-compilers and that's only available for
> ppc64el in experimental at the moment (ppc64el was added in 4.03.0-2).
> 
> Regardless, I tried building the newly-uploaded (but generally old as an
> upstream release) HHVM 3.12.11 package as-is in an experimental chroot
> on the ppc64el porterbox (plummer.debian.org) and while it built fine,
> the resulting binary immediately segfaults, even with no arguments
> and/or with -m interp.
> 
> The backtrace shows:
> 
> Program received signal SIGSEGV, Segmentation fault.
> (gdb) bt full
> #0  HPHP::jit::(anonymous namespace)::memory_effects_impl (inst=...) at
> ./hphp/runtime/vm/jit/memory-effects.cpp:1066
> No locals.
> Backtrace stopped: Cannot access memory at address 0x4a90
> 
> Do you know if this is a known issue, fixed in newer upstream releases?
> Any clues on what this may be?

I think Rogério or Gustavo fixed this bug upstream and may have some clues
about it.

By the way, do you plan to upgrade to a newer version? I know that version
3.12 was still missing some fixes. Newer versions should be on pair with x86.

Bug#844403: src:nfft: FTBFS on ppc64el

[Breno Leitao]

Hi Ghis,

On 12/14/2016 09:30 AM, Ghislain Vaillant wrote:
> Thanks for your contribution. Let me know if a long-term solution comes up
> later.

Sure. I closed the bug on the changelog, but, you can keep it open to track
the final and long term solution.

Bug#844403: src:nfft: FTBFS on ppc64el

[Breno Leitao]

> Sure.  Since the problem is only related to long double, you can bypass
> either all the tests on ppc64el, or, disable long double on ppc64el and keep
> the tests. Either way it should work.

In fact, I came up with a better solution. Just disable the tests for long on
ppc64el.

Let me know if it works for you.

Thank you,
Breno
diff -Nru nfft-3.3.2/debian/changelog nfft-3.3.2/debian/changelog
--- nfft-3.3.2/debian/changelog 2016-10-31 05:00:52.0 -0400
+++ nfft-3.3.2/debian/changelog 2016-12-09 16:12:51.0 -0500
@@ -1,3 +1,11 @@
+nfft (3.3.2-1.1) UNRELEASED; urgency=medium
+
+  * Avoid running tests with long double on ppc64el due to failing tests
+(Closes: #844403)
+  * Add build-dependency for latex.
+
+ -- Breno Leitao <lei...@debian.org>  Fri, 09 Dec 2016 16:12:51 -0500
+
 nfft (3.3.2-1) unstable; urgency=medium
 
   * New upstream version 3.3.2
diff -Nru nfft-3.3.2/debian/control nfft-3.3.2/debian/control
--- nfft-3.3.2/debian/control   2016-10-31 05:00:52.0 -0400
+++ nfft-3.3.2/debian/control   2016-12-09 16:12:51.0 -0500
@@ -8,7 +8,8 @@
libcunit1-dev,
libfftw3-dev,
libncurses5-dev,
-   pkg-config
+   pkg-config,
+   texlive
 Build-Depends-Indep: doxygen
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/nfft.git
diff -Nru nfft-3.3.2/debian/rules nfft-3.3.2/debian/rules
--- nfft-3.3.2/debian/rules 2016-10-31 05:00:52.0 -0400
+++ nfft-3.3.2/debian/rules 2016-12-09 16:12:51.0 -0500
@@ -7,6 +7,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+export DEB_HOST_ARCH = $(shell dpkg-architecture -q DEB_HOST_ARCH)
 
 # Available precisions.
 PRECISIONS = single double
@@ -57,7 +58,13 @@
dh_auto_build --builddirectory=build-double -- doc
 
 override_dh_auto_test-arch:
-   for p in $(PRECISIONS) ; do \
+   # Not running test for long double on ppc64el
+   if [ "$(DEB_HOST_ARCH)" = "ppc64el" ] ; then  \
+   PRECISIONS_TEST="single double" ;\
+   else \
+   PRECISIONS_TEST="$(PRECISIONS)" ;\
+   fi ;\
+   for p in $$PRECISIONS_TEST; do \
dh_auto_test --builddirectory=build-$$p ; \
done
 

Bug#847105: (no subject)

[Breno Leitao]

Hello Lucio,

Thanks for submitting the package to Debian, but I still see major lintian
errors on the package you submit.

Please address, at least, error and warnings lintian erros. These are
important before asking for sponsorship.

Closing the pedantic bugs is a plus. :-)

Also, it seems to be generating a key during the build? Why do you need a key
generated during the build?

It seems also that the package is not built using dpkg-buildpackage, but
being build with debuild. That is weird, and I didn't investigated why.
Enabling it to build with dpkg-buildpackage is also crucial.

This is the problem I am having:

  rm -f en_US.gmo && /usr/bin/msgfmt -c --statistics --verbose -o en_US.gmo
 en_US.po
  pt_BR.po: 1 translated message.
  zh_CN.po: 1 translated message.
  zh_CN.po: 1 translated message.
  mv: cannot stat 't-zh_CN.gmo': No such file or directory
  Makefile:128: recipe for target 'zh_CN.gmo' failed

Weird enough, this file t-zh_CN.gmo does not exists, neither any reference
for it.

PS: Please keep this RFS opened, and we will track the package progress by
this RFS.

Thank you,
Breno

Bug#844403: src:nfft: FTBFS on ppc64el

[Breno Leitao]

Hello Ghislain,

On 12/09/2016 07:01 AM, Ghislain Vaillant wrote:
> I might eventually just bypass testing for ppc64el to let the package
> transition to testing, unless you think you are gonna have a fix ready very
> soon. With the transition window extended to 10 days and the soft-freeze
> deadline happening, I cannot wait for very much longer.

Sure.  Since the problem is only related to long double, you can bypass
either all the tests on ppc64el, or, disable long double on ppc64el and keep
the tests. Either way it should work.

> Please keep me up-to-date, and thanks for investigating.

Sure. things are a bit confused with long double on ppc64el, as for example
the following bug, so, I suspect we are facing something similar:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576

Bug#847101: (no subject)

[Breno Leitao]

Hi Lucio,

Thanks for contributing to Debian.

Unfortunately I was not able to build this package, since it is failing when
building:


 Makefile:129: recipe for target 'de_DE.gmo' failed
 make[4]: *** [de_DE.gmo] Error 1
 make[4]: *** Waiting for unfinished jobs
 rm -f fr_FR.gmo && /usr/bin/msgfmt -c --statistics --verbose -o fr_FR.gmo
fr_FR.po
 ko_KR.po: 362 translated messages, 243 untranslated messages.
 rm -f es_ES.gmo && /usr/bin/msgfmt -c --statistics --verbose -o es_ES.gmo
es_ES.po
 ko_KR.po: 362 translated messages, 243 untranslated messages.
 it_IT.po: 362 translated messages, 243 untranslated messages.
 fr_FR.po: 362 translated messages, 243 untranslated messages.
 es_ES.po: 362 translated messages, 243 untranslated messages.
 ru_RU.po: 362 translated messages, 243 untranslated messages.
 make[5]: Leaving directory '/home/breno/kimchi/kimchi-2.3.0/po'
 touch stamp-po
 make[4]: Leaving directory '/home/breno/kimchi/kimchi-2.3.0/po'
 Makefile:632: recipe for target 'all-recursive' failed
 make[3]: *** [all-recursive] Error 1
 make[3]: Leaving directory '/home/breno/kimchi/kimchi-2.3.0'
 Makefile:450: recipe for target 'all' failed
 make[2]: *** [all] Error 2
 make[2]: Leaving directory '/home/breno/kimchi/kimchi-2.3.0'
 dh_auto_build: make -j8 returned exit code 2
 debian/rules:24: recipe for target 'override_dh_auto_build' failed
 make[1]: *** [override_dh_auto_build] Error 2
 make[1]: Leaving directory '/home/breno/kimchi/kimchi-2.3.0'
 debian/rules:7: recipe for target 'build' failed
 make: *** [build] Error 2
 dpkg-buildpackage: error: debian/rules build gave error exit status 2


When running it again, it seems to be changing the source code, as I shows:

 dpkg-source: info: local changes detected, the modified files are:
  kimchi-2.3.0/ui/css/kimchi.css

Please keep fix the clean process also, so, you can re-run the build process
sequentially.

Bug#847102: RFS: ginger/2.3.0-1 - HTML5-based host management tool

[Breno Leitao]

Hello Lucio,

Thanks for contributing to Debian. I found some issues with this package:

1) There are some lintian errors. Please fix them.

2) The package is not able to be rebuild, i.e, the clean process does not
seem to be clear.

These are the problems I am facing when I run two times a dpkg-buildpackage:

 dpkg-source -b ginger-2.3.0
 dpkg-source: info: using source format '3.0 (quilt)'
 dpkg-source: info: building ginger using existing ./ginger_2.3.0.orig.tar.gz 
 dpkg-source: error: cannot represent change to mo/it_IT/LC_MESSAGES /ginger.mo:
 dpkg-source: error:   new version is symlink to ../../../po/it_IT.gmo
 dpkg-source: error:   old version is nonexistent
 dpkg-source: error: cannot represent change to mo/zh_CN/LC_MESSAGES/ginger.mo:

Please make sure that your clean process is running fine, otherwise, the package
could not be rebuild.

Bug#847108: (no subject)

[Breno Leitao]

Hello Lucio,

Thanks for contributing to Debian. I just run lintian on this package, and it
seems to contain one error and one warning:

 E: ginger-base source: missing-build-dependency-for-dh-addon python2 =>
python:any | python-all:any | python-dev:any | python-all-dev:any

 W: ginger-base source: ancient-standards-version 3.9.6 (current is 3.9.8)

Bug#845082: (no subject)

[Breno Leitao]

We just created a pull request to have this fixed upstream.

https://github.com/pydata/numexpr/pull/235

Should we create a Debian patch also?

Bug#845751: yadifa FTBFS on ppc64el: internal compiler error: in push_reload, at reload.c:1349

[Breno Leitao]

Hello,

On 11/26/2016 10:57 AM, Adrian Bunk wrote:
> Source: yadifa
> Version: 2.2.2-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=yadifa=ppc64el=2.2.2-1=1480164499
> 
> ...
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include/dnscore -Wdate-time 
> -D_FORTIFY_SOURCE=2 -DNDEBUG -g -DDNSCORE_BUILD -D_THREAD_SAFE -D_REENTRANT 
> -D_FILE_OFFSET_BITS=64 -I/«PKGBUILDDIR»/lib/dnscore 
> -I/«PKGBUILDDIR»/lib/dnscore/include -fno-ident -ansi -pedantic -Wall 
> -Wno-unknown-pragmas -Werror=missing-field-initializers -std=gnu99 
> -mtune=native -DUSES_GCC -DPREFIX=\"/usr\" -DSYSCONFDIR=\"/etc\" 
> -DLOCALSTATEDIR=\"/var\" -DDATAROOTDIR=\"/usr/share\" 
> -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" 
> -DLOGDIR=\"/var/log/yadifa\" -DTCLDIR=\"\" -DNDEBUG -O3 -g -DCMR -c 
> src/message_print_format_dig.c -o src/message_print_format_dig.o
> src/message_print_format_dig.c: In function 'message_print_format_dig_buffer':
> src/message_print_format_dig.c:304:1: internal compiler error: in 
> push_reload, at reload.c:1349
>  }
>  ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/ccy8l7aF.out file, please attach this to 
> your bugreport.

This is a known issue on GCC as you can see at:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543

I just created a patch to fix this FTBFS on Debian. It is attached to this 
email.

diff -Nru yadifa-2.2.2/debian/changelog yadifa-2.2.2/debian/changelog
--- yadifa-2.2.2/debian/changelog	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/changelog	2016-11-28 15:12:29.0 -0500
@@ -1,3 +1,9 @@
+yadifa (2.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Avoid compiling with O3 on ppc64el due to a known bug
+
+ -- Breno Leitao <breno.lei...@gmail.com>  Mon, 28 Nov 2016 15:12:29 -0500
+
 yadifa (2.2.2-1) unstable; urgency=medium
 
   * New upstream version 2.2.2 (Closes: #828612)
diff -Nru yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch
--- yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	1969-12-31 19:00:00.0 -0500
+++ yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	2016-11-28 15:12:29.0 -0500
@@ -0,0 +1,27 @@
+--- a/m4/eurid.m4	2016-11-08 05:56:43.140600104 -0500
 b/m4/eurid.m4	2016-11-28 15:01:27.0 -0500
+@@ -298,6 +298,9 @@ case "$(uname -m)" in
+ 		CPU_UNKNOWN=0
+ 		cpu_intel_compatible=1
+ 		;;
++	ppc64le)
++		cpu_power_compatible=1
++		;;
+ 	*)
+ 		;;
+ esac
+@@ -625,7 +628,13 @@ then
+ 			CCOPTIMISATIONFLAGS=-O3
+ 		fi
+ 	fi
+-
++ 
++	dnl Move to O2 due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
++	if [[ $cpu_power_compatible -eq 1 ]]
++	then
++	CCOPTIMISATIONFLAGS=-O2
++	fi
++	
+ AM_CONDITIONAL([USES_ICC], [false])
+ AM_CONDITIONAL([USES_GCC], [true])
+ AM_CONDITIONAL([USES_CLANG], [false])
diff -Nru yadifa-2.2.2/debian/patches/series yadifa-2.2.2/debian/patches/series
--- yadifa-2.2.2/debian/patches/series	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/patches/series	2016-11-28 15:12:20.0 -0500
@@ -5,3 +5,4 @@
 fix-yadifad-spelling.patch
 fix-yadifarc-manpage.patch
 do-not-use-or-define-the-compile-date.patch
+fix-ppc64el_ftbfs.patch

Bug#844403: src:nfft: FTBFS on ppc64el

[Breno Leitao]

On 11/27/2016 07:16 PM, Ghislain Vaillant wrote:
> On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao <bren...@br.ibm.com> wrote:
>> I am looking at this issue, and the first test set is checkall.
>>
>> If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run
>> it isolated, I see no errors, as showed:
>>
>>   $ ./checkall 2>&1 | grep -i fail
>>   $
>>
>> Looking all tests I see "-> OK". Anyway, I am continue to debug what is the
>> problem here.
> 
> It could be a lucky shot. Have you tried running them multiple times?

Yes, and it works, but it fails when running in multi thread mode. Anyway, I
am able to reproduce the problem here.


> If you look carefully at the log you will find that some tests have an
> unrealistically low tolerance value (in the order of 1E-322), which make them
> succeed when the difference is exactly 0 and fail otherwise.

That is interesting, Float precision might be a platform characterstic,
mainly if using long double, or, quad float precision.

Anyway, I will go deeper in the code to understand the problem here.

Bug#844403: (no subject)

[Breno Leitao]

I am looking at this issue, and the first test set is checkall.

If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run
it isolated, I see no errors, as showed:

  $ ./checkall 2>&1 | grep -i fail
  $

Looking all tests I see "-> OK". Anyway, I am continue to debug what is the
problem here.

Bug#845082: numexpr FTBFS on ppc64el: test failures

[Breno Leitao]

On 11/20/2016 07:41 AM, Adrian Bunk wrote:
> 
> Lots of failures like:
> 

Yes. I just tried it here, and more than 40 tests failed.

It is usually off by 1, and I am wondering if we are being bite by a similar
issue I found on OpenJDK, where there are math inconsistency when using
optimization higher than O1.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386

Anyway, we are looking at this problem.

Bug#820466: [pkg-go] Bug#820466: golang-github-shirou-gopsutil: diff for NMU version 2.1-2.1

[Breno Leitao]

Hello Martín,

On 11/15/2016 10:21 AM, Martín Ferrari wrote:
> Hi Breno,
> 
> Thanks for the patch!
> 
> I was going to merge all this and reupload after merging the new
> upstream release, but I have noticed these patches are already in upstream.
> 
> So, does it make sense to merge this instead of just upgrading?

I would say that upgrading this package to the latest release much easier. I
saw that there is a new release, version v2.16.10, that contains my patch.
That would be ideal.


> And one question about the patches: when you say "all currently
> supported architectures" does this include gccgo? Or would that patch
> break it?

Hmm, this is a patch I just cherry picked from upstream. Thomas created it.
I understand that ClockTicks is not defined by architecture anymore, but
defined on Linux for all archs (process_linux.go).

Bug#844323: fixed in ghc 8.0.1-13

[Breno Leitao]

I just tested haskell-zeromq4-haskell build with a patched GHC and it
worked fine, so, I understand also that the problem is fixed.

I just installed the packages also, and they seem to be working properly:

dpkg -l | grep zeromq
ii  libghc-zeromq4-haskell-dev   0.6.5-5
   ppc64el  bindings to ZeroMQ 4.x
ii  libghc-zeromq4-haskell-doc   0.6.5-5
   all  bindings to ZeroMQ 4.x; documentation
ii  libghc-zeromq4-haskell-prof  0.6.5-5
   ppc64el  bindings to ZeroMQ 4.x; profiling libraries


Thanks!

Bug#844323: (no subject)

[Breno Leitao]

reassign ghc

After some further debug, I found this is, in fact, a ghc bug and it was
fixed in version 8.0.2, as showed in:

https://ghc.haskell.org/trac/ghc/ticket/12621

Bug#844323: FTBFS on ppc64el

[Breno Leitao]

Source: haskell-zeromq4-haskell
Version: 0.6.5
Severity: serious
Justification: fails to build from source (but built successfully in the past)


The package haskell-zeromq4-haskell is failing to build on ppc64el port
due to the following error:

  [1 of 6] Compiling System.ZMQ4.Internal.Base (
  dist/build/System/ZMQ4/Internal/Base.hs,
  dist/build/System/ZMQ4/Internal/Base.o )
  /tmp/ghc7817_0/ghc_6.s: Assembler messages:
  
  /tmp/ghc7817_0/ghc_6.s:14471:0: error:
   Error: operand out of domain (2 is not a multiple of 4)
  
This is being caused by a wrong assembly code at ghc_6.s

The faulty instruction is:
   
   lwa 29, 2(3)
  
This is a not valid assembly code, because DS filed (2 argument), should
be a word offset. Since a word is 32 bits, it should be multiple of 4.
In this case, it is trying to load an un-aligned word.


I am still trying to discover why this illegal instruction was
generated.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.7.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#844008: (no subject)

[Breno Leitao]

Is anyone looking/debugging this issue?

Bug#820466: golang-github-shirou-gopsutil: diff for NMU version 2.1-2.1

[Breno Leitao]

Control: tags 820466 + patch
Control: tags 820466 + pending

Dear maintainer,

I've prepared an NMU for golang-github-shirou-gopsutil (versioned as 2.1-2.1) 
and
uploaded it to DELAYED/10. Please feel free to tell me if I should delay it 
longer.

Regards.
diff -Nru golang-github-shirou-gopsutil-2.1/debian/changelog 
golang-github-shirou-gopsutil-2.1/debian/changelog
--- golang-github-shirou-gopsutil-2.1/debian/changelog  2016-07-14 
03:23:30.0 -0400
+++ golang-github-shirou-gopsutil-2.1/debian/changelog  2016-11-03 
08:57:27.0 -0400
@@ -1,3 +1,12 @@
+golang-github-shirou-gopsutil (2.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Breno Leitao ]
+  * Fix FTBFS and add support for ppc64el. (Closes: #820466)
+
+ -- Fernando Seiti Furusato <ferse...@linux.vnet.ibm.com>  Thu, 03 Nov 2016 
10:57:27 -0200
+
 golang-github-shirou-gopsutil (2.1-2) unstable; urgency=medium
 
   * Extend "01-Disable_failing_tests.patch" to disable failing
diff -Nru 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch
 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch
--- 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch
 1969-12-31 19:00:00.0 -0500
+++ 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch
 2016-11-03 08:34:51.0 -0400
@@ -0,0 +1,47 @@
+From 286927a039eb369b9ef12a0578df7bd4bdf91a12 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <breno.lei...@gmail.com>
+Date: Mon, 24 Oct 2016 14:00:37 -0400
+Subject: [PATCH] Improve CPU identification for POWER processors
+
+Currently gopsutils fails to indentify the POWER processors family,
+returning an almost empty Info() structure.
+
+This patch improves the POWER identification without changing what is
+available for x86.
+---
+ cpu/cpu_linux.go | 18 +++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+diff --git a/cpu/cpu_linux.go b/cpu/cpu_linux.go
+index 3537b2d..1979ebc 100644
+--- a/cpu/cpu_linux.go
 b/cpu/cpu_linux.go
+@@ -144,10 +144,22 @@ func Info() ([]InfoStat, error) {
+   c.Family = value
+   case "model":
+   c.Model = value
+-  case "model name":
++  case "model name", "cpu":
+   c.ModelName = value
+-  case "stepping":
+-  t, err := strconv.ParseInt(value, 10, 64)
++  if strings.Contains(value, "POWER8") ||
++ strings.Contains(value, "POWER7") {
++  c.Model = strings.Split(value, " ")[0]
++  c.Family = "POWER"
++  c.VendorID = "IBM"
++  }
++  case "stepping", "revision":
++  val := value
++
++  if key == "revision" {
++  val = strings.Split(value, ".")[0]
++  }
++
++  t, err := strconv.ParseInt(val, 10, 64)
+   if err != nil {
+   return ret, err
+   }
+-- 
+2.9.3
+
diff -Nru 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch
 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch
--- 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch
   1969-12-31 19:00:00.0 -0500
+++ 
golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch
   2016-11-03 08:34:51.0 -0400
@@ -0,0 +1,86 @@
+From eb4a57117f5b734246226c9b6d6b1f9edca2e4f2 Mon Sep 17 00:00:00 2001
+From: Thomas Hipp <th...@suse.de>
+Date: Fri, 16 Sep 2016 09:04:52 +0200
+Subject: [PATCH] process: determine page sizes via function
+
+Instead of hard-coding the page size for linux systems, use Go's
+`Getpagesize` function.
+
+This resolves #258.
+
+Signed-off-by: Thomas Hipp <th...@suse.de>
+---
+ process/process_linux.go   | 5 -
+ process/process_linux_386.go   | 3 +--
+ process/process_linux_amd64.go | 3 +--
+ process/process_linux_arm.go   | 3 +--
+ process/process_linux_arm64.go | 3 +--
+ 5 files changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/process/process_linux.go b/process/process_linux.go
+index 158cb04..9eb4f44 100644
+--- a/process/process_linux.go
 b/process/process_linux.go
+@@ -20,7 +20,10 @@ import (
+   "github.com/shirou/gopsutil/net"
+ )
+ 
+-var ErrorNoChildren = errors.New("process does not have children")
++var (

Bug#842831: ppc64el: Shows wrong CPU frequency/clock

[Breno Leitao]

Package: sysstat
Version: 11.4.1-1
Severity: normal
Tags: patch

Currently sysstat does not parse /proc/cpuinfo properly on ppc64el
platform, showing:

$  sar -m CPU 1 10  
Linux 4.7.0-1-powerpc64le (testing) 11/01/2016  _ppc64le_
(8 CPU)

11:40:10 AM CPU   MHz
11:40:11 AM all  0.00
^C
Average:all  0.00


I just fixed this patch upstream, with the following commit:

https://github.com/sysstat/sysstat/commit/93662b1dbe3eed926d67d418cd4996ede9686679

I can make a NMU if you wish,

Thanks,
Breno

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.7.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sysstat depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-3
ii  libsensors41:3.4.0-3
ii  lsb-base   9.20160629
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2

Versions of packages sysstat recommends:
ii  cron [cron-daemon]  3.0pl1-128

Versions of packages sysstat suggests:
pn  isag  

Bug#835360: rkt: FTBFS on several architectures

[Breno Leitao]

Hello Andreas,

On Tue, 25 Oct 2016 13:25:18 +0200 Andreas Henriksson  wrote:
> As already mentioned the offending ppc64el binaries was removed.

I just fixed created a debdiff to fix golang-github-shirou-gopsutil.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820466

I hope to have the debdiff accepted soon, so, we can re-enable ppc64el.

Bug#820466: (no subject)

[Breno Leitao]

tags 820466 patch

Hello,

I finally came up with a debdiff that fixes this issue and enable
golang-github-shirou-gopsutil to build fine on ppc64el arch.

I cherry picked 3 patches from upstream (1 of those I neeeded to create), and
now the tests are all passing on ppc64el.

Let me know if you want me to NMU it.

Thanks,
Breno
diff -Nru golang-github-shirou-gopsutil-2.1/debian/changelog golang-github-shirou-gopsutil-2.1/debian/changelog
--- golang-github-shirou-gopsutil-2.1/debian/changelog	2016-07-14 03:23:30.0 -0400
+++ golang-github-shirou-gopsutil-2.1/debian/changelog	2016-10-26 08:25:56.0 -0400
@@ -1,3 +1,9 @@
+golang-github-shirou-gopsutil (2.1-3) UNRELEASED; urgency=medium
+
+  * Fix FTBFS and add support for ppc64el. (Closes: #820466)
+
+ -- Breno Leitao <breno.lei...@gmail.com>  Wed, 26 Oct 2016 08:25:56 -0400
+
 golang-github-shirou-gopsutil (2.1-2) unstable; urgency=medium
 
   * Extend "01-Disable_failing_tests.patch" to disable failing
diff -Nru golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch
--- golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch	1969-12-31 19:00:00.0 -0500
+++ golang-github-shirou-gopsutil-2.1/debian/patches/0001-Improve-CPU-identification-for-POWER-processors.patch	2016-10-26 08:19:08.0 -0400
@@ -0,0 +1,47 @@
+From 286927a039eb369b9ef12a0578df7bd4bdf91a12 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <breno.lei...@gmail.com>
+Date: Mon, 24 Oct 2016 14:00:37 -0400
+Subject: [PATCH] Improve CPU identification for POWER processors
+
+Currently gopsutils fails to indentify the POWER processors family,
+returning an almost empty Info() structure.
+
+This patch improves the POWER identification without changing what is
+available for x86.
+---
+ cpu/cpu_linux.go | 18 +++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+diff --git a/cpu/cpu_linux.go b/cpu/cpu_linux.go
+index 3537b2d..1979ebc 100644
+--- a/cpu/cpu_linux.go
 b/cpu/cpu_linux.go
+@@ -144,10 +144,22 @@ func Info() ([]InfoStat, error) {
+ 			c.Family = value
+ 		case "model":
+ 			c.Model = value
+-		case "model name":
++		case "model name", "cpu":
+ 			c.ModelName = value
+-		case "stepping":
+-			t, err := strconv.ParseInt(value, 10, 64)
++			if strings.Contains(value, "POWER8") ||
++			   strings.Contains(value, "POWER7") {
++c.Model = strings.Split(value, " ")[0]
++c.Family = "POWER"
++c.VendorID = "IBM"
++			}
++		case "stepping", "revision":
++			val := value
++
++			if key == "revision" {
++val = strings.Split(value, ".")[0]
++			}
++
++			t, err := strconv.ParseInt(val, 10, 64)
+ 			if err != nil {
+ return ret, err
+ 			}
+-- 
+2.9.3
+
diff -Nru golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch
--- golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch	1969-12-31 19:00:00.0 -0500
+++ golang-github-shirou-gopsutil-2.1/debian/patches/0001-process-determine-page-sizes-via-function.patch	2016-10-26 08:13:17.0 -0400
@@ -0,0 +1,86 @@
+From eb4a57117f5b734246226c9b6d6b1f9edca2e4f2 Mon Sep 17 00:00:00 2001
+From: Thomas Hipp <th...@suse.de>
+Date: Fri, 16 Sep 2016 09:04:52 +0200
+Subject: [PATCH] process: determine page sizes via function
+
+Instead of hard-coding the page size for linux systems, use Go's
+`Getpagesize` function.
+
+This resolves #258.
+
+Signed-off-by: Thomas Hipp <th...@suse.de>
+---
+ process/process_linux.go   | 5 -
+ process/process_linux_386.go   | 3 +--
+ process/process_linux_amd64.go | 3 +--
+ process/process_linux_arm.go   | 3 +--
+ process/process_linux_arm64.go | 3 +--
+ 5 files changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/process/process_linux.go b/process/process_linux.go
+index 158cb04..9eb4f44 100644
+--- a/process/process_linux.go
 b/process/process_linux.go
+@@ -20,7 +20,10 @@ import (
+ 	"github.com/shirou/gopsutil/net"
+ )
+ 
+-var ErrorNoChildren = errors.New("process does not have children")
++var (
++	ErrorNoChildren = errors.New("process does not have children")
++	PageSize= uint64(os.Getpagesize())
++)
+ 
+ const (
+ 	PrioProcess = 0 // linux/resource.h
+diff --git a/process/process_linux_386.go b/process/process_linux_386.go
+index 541b854..c4df213 100644
+--- a/process/process_linux_386.go
 b/process/process_linux_386.go
+@@ -4,6 +4,5 @@
+ package process
+ 
+ const (
+-	ClockTicks = 100  // C.sysconf(C._SC_CLK_TCK)
+-	Page

Bug#837325: (no subject)

[Breno Leitao]

Thanks Andreas,

I am preparing a new version for cappuccino to solve this issue.

Bug#746405: (no subject)

[Breno Leitao]

Closing this bug, since gnome-menus works fine on ppc64el.

Thanks!

Bug#756442: (no subject)

[Breno Leitao]

Control: tags 756442 + pending

Dear maintainer,

I've prepared an NMU for tablix2 (versioned as 0.3.5-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u tablix2-0.3.5/debian/changelog tablix2-0.3.5/debian/changelog
--- tablix2-0.3.5/debian/changelog
+++ tablix2-0.3.5/debian/changelog
@@ -1,3 +1,10 @@
+tablix2 (0.3.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on ppc64el and arm64. (Closes: #756442)
+
+ -- Breno Leitao <lei...@debian.org>  Mon, 05 Sep 2016 15:48:40 -0400
+
 tablix2 (0.3.5-3) unstable; urgency=medium
 
   * maintenance and cleanup spin:
diff -u tablix2-0.3.5/debian/control tablix2-0.3.5/debian/control
--- tablix2-0.3.5/debian/control
+++ tablix2-0.3.5/debian/control
@@ -2,7 +2,7 @@
 Section: misc
 Priority: extra
 Maintainer: Robert Lemmen <rober...@semistable.com>
-Build-Depends: debhelper (>= 7.0.0), pvm-dev, libxml2-dev
+Build-Depends: debhelper (>= 7.0.0), pvm-dev, libxml2-dev, dh-autoreconf
 Homepage: http://www.tablix.org
 Standards-Version: 3.9.8
 
diff -u tablix2-0.3.5/debian/rules tablix2-0.3.5/debian/rules
--- tablix2-0.3.5/debian/rules
+++ tablix2-0.3.5/debian/rules
@@ -8,6 +8,7 @@
 
 config.status: configure
 	dh_testdir
+	dh_autoreconf
 	./configure CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" --prefix=/usr --mandir=/usr/share/man --with-pvm3 --enable-conv --enable-more-teachers --enable-tunable
 
 build: build-stamp
@@ -20,6 +21,7 @@
 clean:
 	dh_testdir
 	dh_testroot
+	dh_autoreconf_clean
 	rm -f build-stamp 
 	rm -f examples/modules/*.so
 	[ ! -f Makefile ] || $(MAKE) distclean

Bug#836405: skiboot: Enable external binaries to be made available

[Breno Leitao]

Hello,

I just created a debdiff that should solve this issue.

Please let me know how does it sound.

Thank you,
Breno
diff -Nru skiboot-5.2.4/debian/changelog skiboot-5.2.4/debian/changelog
--- skiboot-5.2.4/debian/changelog  2016-07-18 09:55:47.0 -0400
+++ skiboot-5.2.4/debian/changelog  2016-09-02 14:08:34.0 -0400
@@ -1,3 +1,9 @@
+skiboot (5.2.4-2.1) UNRELEASED; urgency=medium
+
+  * Build and distribute external binaries. (Closes: #836405)
+
+ -- Breno Leitao <lei...@debian.org>  Fri, 02 Sep 2016 14:08:34 -0400
+
 skiboot (5.2.4-2) unstable; urgency=medium
 
   * Forced no-pie for Ubuntu 16.10 as previous change was not enough : in 16.10
diff -Nru skiboot-5.2.4/debian/opal-utils.install 
skiboot-5.2.4/debian/opal-utils.install
--- skiboot-5.2.4/debian/opal-utils.install 2015-09-01 12:36:32.0 
-0400
+++ skiboot-5.2.4/debian/opal-utils.install 2016-09-02 14:08:34.0 
-0400
@@ -1 +1,4 @@
 usr/sbin/opal-gard
+usr/sbin/pflash
+usr/sbin/getscom
+usr/sbin/putscom
diff -Nru skiboot-5.2.4/debian/rules skiboot-5.2.4/debian/rules
--- skiboot-5.2.4/debian/rules  2016-07-18 09:52:32.0 -0400
+++ skiboot-5.2.4/debian/rules  2016-09-02 14:08:34.0 -0400
@@ -19,14 +19,21 @@
 override_dh_auto_build:
OPAL_PRD_VERSION=opal-prd-$(UPSTREAM_VERSION) make V=1 -C 
external/opal-prd/
GARD_VERSION=gard-$(UPSTREAM_VERSION) make V=1 -C external/gard/
+   PFLASH_VERSION=pflash-$(UPSTREAM_VERSION) make V=1 -C external/pflash
+   make V=1 -C external/xscom-utils
 
 override_dh_auto_install:
make -C external/opal-prd/ prefix=/usr DESTDIR=../../debian/tmp/ install
make -C external/gard/ prefix=/usr DESTDIR=../../debian/tmp/ install
+   make -C external/pflash/ prefix=/usr DESTDIR=../../debian/tmp/ install
+   cp external/xscom-utils/getscom debian/tmp/usr/sbin
+   cp external/xscom-utils/putscom debian/tmp/usr/sbin
 
 override_dh_auto_clean:
make -C external/opal-prd/ clean
make -C external/gard/ clean
+   make -C external/pflash/ distclean
+   make -C external/xscom-utils distclean
rm -f external/opal-prd/ccan \
external/opal-prd/.version \
external/opal-prd/version.c \
@@ -36,5 +43,6 @@
external/gard/common \
external/gard/ccan \
external/gard/make_version.sh \
-   external/gard/libflash
+   external/gard/libflash \
+   external/pflash/version.c
dh_auto_clean

Bug#836405: skiboot: Enable external binaries to be made available

[Breno Leitao]

Source: skiboot
Version: 5.2.4-2
Severity: important

Hello maintainer,

There are some external binaries that are not being built today, and we
would like to build them, as make them available. They are:

 * getscom
 * pflash
 * putscom

I also undertstand that it should be included in opal-utils.

Thank you,
Breno

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.4.0-1-powerpc64le (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#835253: RFS: steghide/0.5.1-11 [QA]

[Breno Leitao]

Hello Fernando,

On Tue, Aug 23, 2016 at 04:20:47PM -0400, Fernando Seiti Furusato wrote:
>   Changes since the last upload:
>   
>   * QA upload.
> 
>   [ Aurelien Jarno ]
>   * debian/rules: added dh_autotools-dev_updateconfig and
> dh_autotools-dev_restoreconfig to fix FTBFS on new architectures
> such as arm64 and ppc64el. Closes: #759453

Thanks for contributing to Debian. Your changes seem fine to me, and I
am willing to sponsor it, but I would like to ask you something else.

During my tests with your submission, I found that the package currently
depends on libtool binary, but it does not build-depends on libtool-bin,
which causes the build to fail (FTBFS). I opened a bug to track it under
Bug#835378. Check it for more details.

Also, I understand that your fix also closes the Bug#535842.  What do
you think?

Thank you,
Breno


signature.asc
Description: PGP signature

Bug#835378: Package needs libtool binaries but do not depend on libtool-bin

[Breno Leitao]

Package: steghide
Version: 0.5.1-10
Severity: important

Currently this package does not build on a clean environemnt because it
depends on libtool binary, but does not mark libtool-bin as Build-dependent.
This causes the following FTBFS:

  libtool --mode=link g++  -O2 -Wall   -o steghide  Arg.o Arguments.o 
AssertionFailed.o AuFile.o AuSampleValues.o DFSAPHeuristic.o BFSAPHeuristic.o 
BinaryIO.o BitString.o BmpFile.o BmpPaletteSampleValue.o BmpRGBSampleValue.o 
BmpSampleValue.o WKSConstructionHeuristic.o DMDConstructionHeuristic.o 
CvrStgFile.o Edge.o EdgeIterator.o EmbData.o Embedder.o EncryptionAlgorithm.o 
EncryptionMode.o Extractor.o Graph.o JpegFile.o JpegSampleValue.o MCryptPP.o 
MHashKeyGen.o MHashPP.o Matching.o MatchingAlgorithm.o ProgressOutput.o 
PseudoRandomSource.o RGBTriple.o RandomSource.o SampleValue.o 
SampleValueAdjacencyList.o Selector.o Session.o SteghideError.o Terminal.o 
Utils.o Vertex.o WavChunk.o WavChunkHeader.o WavChunkUnused.o WavFile.o 
WavFormatChunk.o WavPCMSampleValue.o error.o main.o msg.o 
SMDConstructionHeuristic.o  -ljpeg -lmcrypt -lmhash -lz 
  /bin/bash: libtool: command not found
  

Bug#834849: (no subject)

[Breno Leitao]

Package: cappuccino
Version: 0.5.1-2.3
Severity: normal

Currently cappuccino does not run properly on a default Debian system
because it expects that polygen (which is a game) is on the PATH, which
is not true.

In that way, the software complains as following:

sh: 1: polygen: not found
sh: 1: polygen: not found

Since this package is orphaned, I am planning to take it and fix this
(and other) problems.

Bug#832064: RFS: meanwhile/1.0.2-9

[Breno Leitao]

Package: sponsorship-requests
Severity: normal

Dear mentors,

 I am looking for a sponsor for a QA upload:

* Package name: meanwhile
  Version : 1.0.2-9
  Upstream Author : Christopher O'Brien <si...@preoccupied.net>
* URL : http://meanwhile.sf.net
* License : LGPL
  Section : net

 It builds those binary packages:

libmeanwhile-dev - development package for libmeanwhile1
libmeanwhile1 - open implementation of the Lotus Sametime Community Client 
protoc

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

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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/m/meanwhile/meanwhile_1.0.2-9.dsc

Changes since the last upload:

  * Fix a login issue due to code optimization.  Closes: #764494 

Regards,
Breno Leitao


signature.asc
Description: PGP signature

Bug#811789: zvbi: diff for NMU version 0.2.35-10.1

[Breno Leitao]

Control: tags 811789 + patch

Dear maintainer,

I've prepared an NMU for zvbi (versioned as 0.2.35-10.1). The diff
is attached to this message.

Regards.
diff -Nru zvbi-0.2.35/debian/changelog zvbi-0.2.35/debian/changelog
--- zvbi-0.2.35/debian/changelog	2015-11-28 21:08:40.0 -0500
+++ zvbi-0.2.35/debian/changelog	2016-07-17 20:47:46.0 -0400
@@ -1,3 +1,13 @@
+zvbi (0.2.35-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC 6. The test code is using values that overflow the
+ variable types. I just replaced the values with a saner value
+ (double checked that it didn't change when compiling with GCC5 and
+ GCC6 with this fix). (Closes: #811789)
+
+ -- Breno Leitao <bren...@br.ibm.com>  Sun, 17 Jul 2016 18:02:37 -0400
+
 zvbi (0.2.35-10) unstable; urgency=medium
 
   * Migrations:
diff -Nru zvbi-0.2.35/debian/patches/09_FTBFS_gcc6.patch zvbi-0.2.35/debian/patches/09_FTBFS_gcc6.patch
--- zvbi-0.2.35/debian/patches/09_FTBFS_gcc6.patch	1969-12-31 19:00:00.0 -0500
+++ zvbi-0.2.35/debian/patches/09_FTBFS_gcc6.patch	2016-07-17 20:47:31.0 -0400
@@ -0,0 +1,29 @@
+--- zvbi-0.2.35.orig/test/test-dvb_mux.cc
 zvbi-0.2.35/test/test-dvb_mux.cc
+@@ -137,7 +137,7 @@ is_good_service			(vbi_service_set	servi
+ static const vbi_service_set
+ all_services [] = {
+ 	0,
+-	-1,
++	UINT_MAX,
+ 	VBI_SLICED_2xCAPTION_525,
+ 	VBI_SLICED_CAPTION_525,
+ 	VBI_SLICED_CAPTION_525_F1,
+@@ -1279,7 +1279,7 @@ test_multiplex_sliced_service_checks
+ 
+ 	/* Verify the service filter. */
+ 
+-	if (-1u == service
++	if (UINT_MAX == service
+ 	|| (VBI_SLICED_TELETEXT_B_625
+ 		== (VBI_SLICED_TELETEXT_B_625 & service))) {
+ 		assert_multiplex_sliced (buffer, buffer_size,
+@@ -3237,7 +3237,7 @@ static void
+ test_dvb_mux_cor_pts (void)
+ {
+ 	static const int64_t ptss [] = {
+-		0x8000ll, -1, 0, 0x7FFFll,
++		0, -1, 0, 0x7FFFll,
+ 	};
+ 	DVBPESMuxTest mx;
+ 	unsigned int i;
diff -Nru zvbi-0.2.35/debian/patches/series zvbi-0.2.35/debian/patches/series
--- zvbi-0.2.35/debian/patches/series	2015-11-28 20:50:05.0 -0500
+++ zvbi-0.2.35/debian/patches/series	2016-07-17 20:47:39.0 -0400
@@ -5,3 +5,4 @@
 06_sizeof_FTBFS.patch
 07_fix-spelling-in-binaries.patch
 08_fix-manpage.patch
+09_FTBFS_gcc6.patch


signature.asc
Description: PGP signature

Bug#811621: critterding: diff for NMU version 1.0-beta12.1-1.3

[Breno Leitao]

Control: tags 811621 + patch

Dear maintainer,

I've prepared an NMU for critterding (versioned as 1.0-beta12.1-1.3). The diff
is attached to this message.

Regards.
diff -Nru critterding-1.0-beta12.1/debian/changelog critterding-1.0-beta12.1/debian/changelog
--- critterding-1.0-beta12.1/debian/changelog	2012-05-13 10:38:30.0 -0400
+++ critterding-1.0-beta12.1/debian/changelog	2016-07-17 17:11:02.0 -0400
@@ -1,3 +1,10 @@
+critterding (1.0-beta12.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixing FTBFS on GCC 6. (Closes: 811621)
+
+ -- Breno Leitao <bren...@br.ibm.com>  Sun, 17 Jul 2016 16:46:12 -0400
+
 critterding (1.0-beta12.1-1.2) unstable; urgency=low
 
   [ Cyril Brulebois ]
diff -Nru critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch
--- critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch	1969-12-31 19:00:00.0 -0500
+++ critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch	2016-07-17 16:45:28.0 -0400
@@ -0,0 +1,20 @@
+Description: Fix FTBFS with GCC6
+ Currently, Brainz() tries to assign a bool value to a pointer, which
+breaks in GCC6. This patch simply fixes this issue, and it was fixed on
+any other assignment for Outputs[X].output, but not for this loop
+specifically.
+ 
+Author: Breno Leitao <bren...@br.ibm.com>
+Bug-Debian: https://bugs.debian.org/811621
+
+--- critterding-1.0-beta12.1.orig/src/brainz/brainz.cpp
 critterding-1.0-beta12.1/src/brainz/brainz.cpp
+@@ -137,7 +137,7 @@ Brainz::Brainz()
+ 	
+ 		// clear Motor Outputs
+ 		for ( unsigned int i=0; i < numberOfOutputs; i++ )
+-			Outputs[i].output = false;
++			*Outputs[i].output = false;
+ 	
+ 		// clear Neurons
+ 		for ( unsigned int i=0; i < totalNeurons; i++ )
diff -Nru critterding-1.0-beta12.1/debian/patches/series critterding-1.0-beta12.1/debian/patches/series
--- critterding-1.0-beta12.1/debian/patches/series	2012-05-13 10:38:23.0 -0400
+++ critterding-1.0-beta12.1/debian/patches/series	2016-07-17 16:45:42.0 -0400
@@ -2,3 +2,4 @@
 10uninitialized_constant
 11const_cast
 20fix_ftbfs_gcc_4.7
+21FTBFS_gcc6.patch


signature.asc
Description: PGP signature

Bug#811621: (no subject)

[Breno Leitao]

This is the debdiff that contains the patch above. It is a preparation
for a possible NMU.
diff -Nru critterding-1.0-beta12.1/debian/changelog 
critterding-1.0-beta12.1/debian/changelog
--- critterding-1.0-beta12.1/debian/changelog   2012-05-13 10:38:30.0 
-0400
+++ critterding-1.0-beta12.1/debian/changelog   2016-07-17 17:11:02.0 
-0400
@@ -1,3 +1,10 @@
+critterding (1.0-beta12.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixing FTBFS on GCC 6. (Closes: 811621)
+
+ -- Breno Leitao <bren...@br.ibm.com>  Sun, 17 Jul 2016 16:46:12 -0400
+
 critterding (1.0-beta12.1-1.2) unstable; urgency=low
 
   [ Cyril Brulebois ]
diff -Nru critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch 
critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch
--- critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch  1969-12-31 
19:00:00.0 -0500
+++ critterding-1.0-beta12.1/debian/patches/21FTBFS_gcc6.patch  2016-07-17 
16:45:28.0 -0400
@@ -0,0 +1,20 @@
+Description: Fix FTBFS with GCC6
+ Currently, Brainz() tries to assign a bool value to a pointer, which
+breaks in GCC6. This patch simply fixes this issue, and it was fixed on
+any other assignment for Outputs[X].output, but not for this loop
+specifically.
+ 
+Author: Breno Leitao <bren...@br.ibm.com>
+Bug-Debian: https://bugs.debian.org/811621
+
+--- critterding-1.0-beta12.1.orig/src/brainz/brainz.cpp
 critterding-1.0-beta12.1/src/brainz/brainz.cpp
+@@ -137,7 +137,7 @@ Brainz::Brainz()
+   
+   // clear Motor Outputs
+   for ( unsigned int i=0; i < numberOfOutputs; i++ )
+-  Outputs[i].output = false;
++  *Outputs[i].output = false;
+   
+   // clear Neurons
+   for ( unsigned int i=0; i < totalNeurons; i++ )
diff -Nru critterding-1.0-beta12.1/debian/patches/series 
critterding-1.0-beta12.1/debian/patches/series
--- critterding-1.0-beta12.1/debian/patches/series  2012-05-13 
10:38:23.0 -0400
+++ critterding-1.0-beta12.1/debian/patches/series  2016-07-17 
16:45:42.0 -0400
@@ -2,3 +2,4 @@
 10uninitialized_constant
 11const_cast
 20fix_ftbfs_gcc_4.7
+21FTBFS_gcc6.patch


signature.asc
Description: PGP signature

Bug#831627: RFS: nvme-cli/0.8-2

[Breno Leitao]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "nvme-cli"

* Package name: nvme-cli
  Version : 0.2-1
  Upstream Author : Keith Busch <keith.bu...@intel.com>
* URL : https://github.com/linux-nvme/nvme-cli
* License : GPL-2
  Section : admin

It builds those binary packages:

  nvme-cli   - userspace tooling to control NVMe drives

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

https://mentors.debian.net/package/nvme-cli


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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nvme-cli/nvme-cli_0.8-2.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

 * Add a patch to enable nvme-cli to compile on 32 bits system (Thanks Steve
   Langasek) (Closes: #830521)

Regards,
Breno Leitao


signature.asc
Description: PGP signature

Bug#811621: FTBFS with GCC 6: cannot convert x to y

[Breno Leitao]

I am looking at this problem, and I understand that the following patch fixes
this problem:

--- critterding-1.0-beta12.1.orig/src/brainz/brainz.cpp
+++ critterding-1.0-beta12.1/src/brainz/brainz.cpp
@@ -137,7 +137,7 @@ Brainz::Brainz()

// clear Motor Outputs
for ( unsigned int i=0; i < numberOfOutputs; i++ )
-   Outputs[i].output = false;
+   *Outputs[i].output = false;

// clear Neurons
for ( unsigned int i=0; i < totalNeurons; i++ )

I might be able to send a NMU to mentors with this (and some others) fixes.

Bug#830521: nvme-cli: Fix regression in nvme-cli 32-bit compatibility

[Breno Leitao]

> Please consider
> applying this patch in Debian as well, and forward upstream as necessary.

Just got the patch accepted by upstream maintainer also.

 
https://github.com/linux-nvme/nvme-cli/commit/90f00efdd89866b5f4f389c0b0a7ca4305c76303

The other two off-the-tree patches were also accepted now.

 
https://github.com/linux-nvme/nvme-cli/commit/90f00efdd89866b5f4f389c0b0a7ca4305c76303
 
https://github.com/linux-nvme/nvme-cli/commit/e49f9a46589cdf7b56bc47ac609a99d648d80ae1

Bug#830521: nvme-cli: Fix regression in nvme-cli 32-bit compatibility

[Breno Leitao]

Hello Steve,

On 07/08/2016 06:49 PM, Steve Langasek wrote:
> I've applied the attached patch in Ubuntu to address this.  Please consider
> applying this patch in Debian as well, and forward upstream as necessary.

Thanks for fixing it. I just created a new package version with this fix.

The new package is at mentors right now, and I will ask Gianfranco if he
could sponsor this new version.

  https://mentors.debian.net/package/nvme-cli

Thanks,
Breno

Bug#829700: RFS: nvme-cli/0.8-1

[Breno Leitao]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nvme-cli"

* Package name: nvme-cli
  Version : 0.8-1
  Upstream Author : Keith Busch <keith.bu...@intel.com>
* URL : https://github.com/linux-nvme/nvme-cli/
* License : GPL
  Section : admin

It builds those binary packages:

  nvme-cli   - userspace tooling to control NVMe drives

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

https://mentors.debian.net/package/nvme-cli


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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nvme-cli/nvme-cli_0.8-1.dsc


More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

   nvme-cli (0.8-1) unstable; urgency=medium

* New upstream release

   -- Breno Leitao <bren...@br.ibm.com>  Sun, 03 Jul 2016 07:12:26 -0400

Regards,
Breno Leitao

Bug#823639: Bump lshw version to B.02.18

[Breno Leitao]

I would like to ask the same thing, since this there are some patches that 
improves ppc64el arch.


These are the important patches that made 2.18 version, and are important for 
ppc64el:


 * 2ede65360abc62cb0cef72d67fa456d69d5516f4
 * 954c051dbb8580b8b22f2fb32dbefd724fe491a2
 * e5f15ae459fbe880efbf20e25252e7310af363ab

There is also a missing patch that improves device tree reading, but it is 
still not accepted upstream. Not sure if you would accept it.
>From 2c38e1c6a9dd4e35685be5ba7f64e51fd0e31c1a Mon Sep 17 00:00:00 2001
From: Jeremy Kerr 
Date: Mon, 8 Jun 2015 12:35:00 +0800
Subject: [PATCH] lshw: Parse OPAL firmware properties from the device
tree

OPAL-firmware-based Power machines expose a firmware device tree node in
/ibm,opal, containing version information and available interfaces.

This change adds a function to parse information about OPAL firmware and
add it to lshw's machine information. With a current OpenPower machine,
we get something like this:

 *-firmware
  product: OPAL firmware
  physical id: 1
  version: skiboot-5.0.2
  capabilities: opal-v2 opal-v3 prd ipmi

Signed-off-by: Jeremy Kerr 
---
 src/core/device-tree.cc | 59
+
 1 file changed, 59 insertions(+)

diff --git a/src/core/device-tree.cc b/src/core/device-tree.cc
index 8908fd1..73a98a9 100644
--- a/src/core/device-tree.cc
+++ b/src/core/device-tree.cc
@@ -168,6 +168,64 @@ static void scan_devtree_bootrom(hwNode & core)
   }
 }
 
+static void scan_devtree_opal_firmware(hwNode & core)
+{
+  vector < string >::iterator it;
+  vector < string > compat;
+  struct dirent **namelist;
+  int i, n;
+
+  if (!exists(DEVICETREE "/ibm,opal"))
+return;
+
+  hwNode opal("firmware", hw::memory);
+
+  opal.setProduct("OPAL firmware");
+  if (exists(DEVICETREE "/ibm,opal/firmware/version"))
+opal.setVersion(get_string(DEVICETREE
"/ibm,opal/firmware/version"));
+
+  compat = get_strings(DEVICETREE "/ibm,opal/compatible");
+
+  for (it = compat.begin(); it != compat.end(); ++it) {
+if (matches(*it, "^ibm,opal-v2"))
+  opal.addCapability("opal-v2");
+if (matches(*it, "^ibm,opal-v3"))
+  opal.addCapability("opal-v3");
+  }
+
+  /* collect compatible strings from firmware sub-nodes */
+  compat.clear();
+  pushd(DEVICETREE "/ibm,opal");
+  n = scandir(".", , selectdir, alphasort);
+  popd();
+  for (i = 0; i < n; i++) {
+string path = string(DEVICETREE "/ibm,opal/")
++ string(namelist[i]->d_name)
++ string("/compatible");
+
+vector < string > tmp = get_strings(path);
+compat.insert(compat.end(), tmp.begin(), tmp.end());
+
+free(namelist[i]);
+  }
+
+  if (n >= 0)
+free(namelist);
+
+  /* check our collected compatible strings for known capabilities */
+  for (it = compat.begin(); it != compat.end(); ++it) {
+
+if (*it == "ibm,opal-prd")
+  opal.addCapability("prd");
+
+if (*it == "ibm,opal-ipmi")
+  opal.addCapability("ipmi");
+  }
+
+  opal.claim();
+  core.addChild(opal);
+}
+
 
 static string cpubusinfo(int cpu)
 {
@@ -696,6 +754,7 @@ bool scan_device_tree(hwNode & n)
   scan_devtree_root(*core);
   scan_devtree_memory_powernv(*core);
   scan_devtree_cpu(*core);
+  scan_devtree_opal_firmware(*core);
   n.addCapability("powernv", "Non-virtualized");
   n.addCapability("opal", "OPAL firmware");
 }
-- 
1.9.1

Bug#785065: vdso32 fails to built on ppc64el

[Breno Leitao]

Ben,

On Tue, 26 May 2015 01:58:09 +0100 Ben Hutchings  wrote:

Thanks for restoring support for 32-bit code generation.  I recognise
it's not something you really want to support, so I'm leaving the kernel
bug open but changing the title/severity accordingly.


This was fixed upstream starting at kernel version 4.2. The commit that solved 
this problem is:



  commit e0d0059169945c8ee16790d2e7244cea397dfd56
  Author: Michael Ellerman 
  Date:   Mon May 11 20:01:02 2015 +1000

  powerpc/vdso: Disable building the 32-bit VDSO on little endian


I backported it to the Jessie kernel, and it is almost straigh-forward. If you 
wish, I can attach it here.


Anyway, this problem will *not* happen on Stretch version.

Bug#825483: Lowering severity

[Breno Leitao]

On Sun, 12 Jun 2016 23:58:57 +0200 Jordi Mallach  wrote:

> Upstream is aware of this build failure, and porter help would be welcome.
Right. I will add it to my queue. since it is !ppc64el and the package is more
focused on desktop (instead of server), it will have a low priority.