Bug#1065837: cappuccino: Please drop dependencies on python3-distutils
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
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
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
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
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()
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)
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)
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
Oh sorry about it, I will have it fixed soon.
Bug#914797: ndctl: Please apply packaging fixes from Ubuntu
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
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
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
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
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)
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
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
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&arch=ppc64el&ver=0.5.1-1&stamp=1519399908&raw=0 > - > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack&arch=ppc64el&ver=0.5.1-1&stamp=1519396907&raw=0 > - > https://buildd.debian.org/status/fetch.php?pkg=tk8.5&arch=ppc64el&ver=8.5.19-3&stamp=1519362938&raw=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
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 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
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 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
+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
+
+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
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
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
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
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
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
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
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&arch=ppc64el&ver=2.5.0%7Epreview1-1&stamp=1510662722&raw=0 >> >> FTR, the ppc64 log, which exhibits the same error, is at >> >> https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64&ver=2.5.0%7Epreview1-1&stamp=1510663941&raw=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
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)
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 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
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
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
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]
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
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)
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)
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
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
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(¤t->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&arch=ppc64el&ver=2.24-12&stamp=1497900384&raw=0
(Check for --enable-lock-elision)
Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
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
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
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
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 (Re: Bug#842831: ppc64el: Shows wrong CPU frequency/clock)
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)
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
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
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
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
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 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 -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
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
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
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 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 -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
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
> 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
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.
Package: wnpp Severity: wishlist Owner: Breno Leitao * 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
Hi Dan, On 02/07/2017 05:03 PM, Dan Williams wrote: > On Tue, Feb 7, 2017 at 10:55 AM, Breno Leitao 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
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]
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
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
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 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
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
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
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
> 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 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)
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
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)
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
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)
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)
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
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&arch=ppc64el&ver=2.2.2-1&stamp=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 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
On 11/27/2016 07:16 PM, Ghislain Vaillant wrote: > On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao 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)
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
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
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
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)
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
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)
Is anyone looking/debugging this issue?
Bug#820466: golang-github-shirou-gopsutil: diff for NMU version 2.1-2.1
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 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
+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
+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
+---
+ 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")
++ Pa
Bug#842831: ppc64el: Shows wrong CPU frequency/clock
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
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)
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 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
+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
+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
+---
+ 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)
+- PageSize = 4096 // C.sysconf(C._SC_PAGE_SIZE)
++ ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+ )
+diff --
Bug#837325: (no subject)
Thanks Andreas, I am preparing a new version for cappuccino to solve this issue.
Bug#746405: (no subject)
Closing this bug, since gnome-menus works fine on ppc64el. Thanks!
Bug#756442: (no subject)
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 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 -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
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 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
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]
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
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)
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
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 * 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
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 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
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 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 +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)
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 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 +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
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 * 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
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
> 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
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
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 * 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 Sun, 03 Jul 2016 07:12:26 -0400 Regards, Breno Leitao
Bug#823639: Bump lshw version to B.02.18
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(".", &namelist, 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
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
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.
