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

[Breno Leitao]

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

That is OK. Thanks for your contribution.

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

[Breno Leitao]

Hi Sergei,

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

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

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

Thanks for working on it,
Breno

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

[Breno Leitao]

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

Dear maintainer,

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

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

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

  checking whether to build shared libraries... no

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

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

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


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

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

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

[Breno Leitao]

Hi,

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

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

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

This is already fixed and in the stable tree already:

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

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

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

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

[Breno Leitao]

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

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

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

[Breno Leitao]

Some new discover I did today:

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

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

This is the type of the pointer corruption I see:

>From 0x7fff8970 to 0x7fff88000970.

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

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

[Breno Leitao]

hi Ryan,

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

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

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

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

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

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

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

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

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

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

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

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

[Breno Leitao]

hi Ryan,

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

Nice work!

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

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

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

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

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

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

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

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

[Breno Leitao]

Hey Adrian,

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

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

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

 ...

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

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


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

That said, I understand that there are two bugs:

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

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

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

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

[Breno Leitao]

Ryan,

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

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

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

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

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

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

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

---

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

ldap_msgfree( res );

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

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

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

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

[Breno Leitao]

Hi Ryan,

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

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

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

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

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

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

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

Thanks,
Breno

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

[Breno Leitao]

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

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

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

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

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

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

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

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

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

jsvc suggests no packages.

-- no debconf information

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

[Breno Leitao]

Hi Martin,

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

How will it show up in Stretch?

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

Thank you,
Breno

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

[Breno Leitao]

Hi Adrian,

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

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

Take a look at debian/rules that says:

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

Bug#845082: (no subject)

[Breno Leitao]

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

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

Should we create a Debian patch also?

Bug#845082: numexpr FTBFS on ppc64el: test failures

[Breno Leitao]

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

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

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

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

Anyway, we are looking at this problem.

Bug#844323: fixed in ghc 8.0.1-13

[Breno Leitao]

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

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

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


Thanks!

Bug#844323: (no subject)

[Breno Leitao]

reassign ghc

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

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

Bug#844323: FTBFS on ppc64el

[Breno Leitao]

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


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

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

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


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

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

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

Bug#837325: (no subject)

[Breno Leitao]

Thanks Andreas,

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

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

[Breno Leitao]

Control: tags 811789 + patch

Dear maintainer,

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

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


signature.asc
Description: PGP signature

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

[Breno Leitao]

Control: tags 811621 + patch

Dear maintainer,

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

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


signature.asc
Description: PGP signature

Bug#811621: (no subject)

[Breno Leitao]

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


signature.asc
Description: PGP signature

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

[Breno Leitao]

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

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

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

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

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

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

[Breno Leitao]

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

Just got the patch accepted by upstream maintainer also.

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

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

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

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

[Breno Leitao]

Hello Steve,

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

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

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

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

Thanks,
Breno

Bug#824166: texlive-bin: FTBFS due to luajit issues

[Breno Leitao]

On Fri, 13 May 2016 10:56:25 +0200 (CEST) Thorsten Glaser  
wrote:
> With https://buildd.debian.org/status/package.php?p=luajit
> showing the architectures the stand-alone luajit is not
> available for 

In fact we have a ppc64el patch for luajit port, but the upstream
maintainer does not commit or even comment about our patches, so, it
does get accepted.

https://github.com/LuaJIT/LuaJIT/pull/54

We also asked the Debian luajit maintainer (Enrico) to get the patch accepted in
Debian, until we have any position on upstream.

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

Bug#804736: libwfut: FTBFS: sigc++/object_slot.h: No such file or directory

[Breno Leitao]

I just tried to build it on ppc64el and it fails with the same mistake.

The patch attached solves this problem.

Bug#804736: libwfut: FTBFS: sigc++/object_slot.h: No such file or directory

[Breno Leitao]

On 11/26/2015 01:32 PM, James Cowgill wrote:
>> The patch attached solves this problem.
> 
> You didn't attach a patch :)
Duh! Yes, my patch was similar to yours.

Bug#784278: powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH

[Breno Leitao]

Source: linux
Version: 3.16.7-ckt9-3~deb8u1
Severity: critical
Tags: security patch
Justification: breaks the whole system

We should cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), otherwise we can be lost in a infinite loop when using a
ppc64el machine. :-(

I am attaching the fix that I tested adding it to the following directory, and
adding it to the debian/patch/series.
debian/patches/bugfix/ppc64el/powerpc-perf-Cap-64bits-userspace-backtraces.patch

Other than that, the patch submission could be seen at:
https://patchwork.ozlabs.org/patch/460955/

Thanks
Breno

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.16.0-4-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)
From patchwork Mon Apr 13 21:51:03 2015
From: Anton Blanchard an...@samba.org
Subject: powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
To: linuxppc-...@lists.ozlabs.org
Date: Tue, 14 Apr 2015 07:51:03 +1000

We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), but we forgot to do the same for 64bit backtraces.

Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard an...@samba.org
---
 arch/powerpc/perf/callchain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 2396dda..ead5535 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -243,7 +243,7 @@ static void perf_callchain_user_64(struct perf_callchain_entry *entry,
 	sp = regs-gpr[1];
 	perf_callchain_store(entry, next_ip);
 
-	for (;;) {
+	while (entry-nr  PERF_MAX_STACK_DEPTH) {
 		fp = (unsigned long __user *) sp;
 		if (!valid_user_sp(sp, 1) || read_user_stack_64(fp, next_sp))
 			return;

Bug#766631: FTBFS ppc64el: Remove deprecated SVID_SOURCE

[Breno Leitao]

Package: turnserver
Version: 0.7.3-2
Severity: critical
Tags: patch

At the moment, turnserver doesn't build on ppc64el platform with the following
error:

In file included from tls_peer.c:72:0:
/usr/include/netinet/tcp.h:89:11: error: duplicate member 'th_off'
  u_int8_t th_off:4;  /* data offset */
   ^
/usr/include/netinet/tcp.h:90:11: error: duplicate member 'th_x2'
  u_int8_t th_x2:4;  /* (unused) */

https://buildd.debian.org/status/fetch.php?pkg=turnserverarch=ppc64elver=0.7.3-2stamp=1410498176

That is because both path of the following are being executed:

 # if __BYTE_ORDER == __BIG_ENDIAN
 u_int8_t th_off:4;  /* data offset */
 u_int8_t th_x2:4;   /* (unused) */
 # endif
 # if __BYTE_ORDER == __LITTLE_ENDIAN
 u_int8_t th_x2:4;   /* (unused) */
 u_int8_t th_off:4;  /* data offset */
 # endif

This is because SVID_SOURCE is being used, and it is deprecated. The proper way
is to use _DEFAULT_SOURCE, which fixes the problem above.

Thanks
Breno
--- turnserver-0.7.3.orig/src/Makefile.am
+++ turnserver-0.7.3/src/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = -std=c99 -Wall -Wextra -Werror -Wstrict-prototypes -Wredundant-decls -Wshadow -pedantic -fno-strict-aliasing -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -O2 -D_SVID_SOURCE
+AM_CFLAGS = -std=c99 -Wall -Wextra -Werror -Wstrict-prototypes -Wredundant-decls -Wshadow -pedantic -fno-strict-aliasing -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -O2 -D_DEFAULT_SOURCE
 
 if ENABLE_DEBUG_BUILD
 AM_CFLAGS += -g 
--- turnserver-0.7.3.orig/src/Makefile.in
+++ turnserver-0.7.3/src/Makefile.in
@@ -288,7 +288,7 @@ top_srcdir = @top_srcdir@
 AM_CFLAGS = -std=c99 -Wall -Wextra -Werror -Wstrict-prototypes \
 	-Wredundant-decls -Wshadow -pedantic -fno-strict-aliasing \
 	-D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -O2 \
-	-D_SVID_SOURCE $(am__append_1) $(am__append_2)
+	-D_DEFAULT_SOURCE $(am__append_1) $(am__append_2)
 INCLUDE = -I.
 noinst_HEADERS = turnserver.h \
  turn.h \

Bug#761556: (no subject)

[Breno Leitao]

This error is also blocking ppc64el bootstrap, because it fails to compile as
described above.

The ppc64el build log could be found at:

https://buildd.debian.org/status/fetch.php?pkg=pg-reorgarch=ppc64elver=1.1.9-2stamp=1410770668


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765092: closed by Antonio Terceiro terce...@debian.org (Bug#765092: fixed in ruby-ffi 1.9.6debian-2)

[Breno Leitao]

Thank you, now ruby-ffi compiled fine on ppc64el as shown in the
following build log:

https://buildd.debian.org/status/fetch.php?pkg=ruby-ffiarch=ppc64elver=1.9.6debian-2stamp=1413238408


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745969: (no subject)

[Breno Leitao]

I was also able to build it according to the suggested patch. It builds
fine on ppc64el also:

dpkg-deb: building package `guile-1.8' in 
`../guile-1.8_1.8.8+1-9_ppc64el.deb'.
dpkg-deb: building package `guile-1.8-doc' in 
`../guile-1.8-doc_1.8.8+1-9_all.deb'.
dpkg-deb: building package `guile-1.8-libs' in 
`../guile-1.8-libs_1.8.8+1-9_ppc64el.deb'.
dpkg-deb: building package `guile-1.8-dev' in 
`../guile-1.8-dev_1.8.8+1-9_ppc64el.deb'.
 dpkg-genchanges  ../guile-1.8_1.8.8+1-9_ppc64el.changes
dpkg-genchanges: not including original source code in upload
 dpkg-source --after-build guile-1.8-1.8.8+1
dpkg-buildpackage: binary and diff upload (original source NOT included)

I am attaching the patch, as suggested by Sergey.

Thank you,
Breno
--- guile-1.8-1.8.8+1.orig/libguile/c-tokenize.lex
+++ guile-1.8-1.8.8+1/libguile/c-tokenize.lex
@@ -24,20 +24,6 @@ INTQUAL		(l|L|ll|LL|lL|Ll|u|U)
an error for that. */
 #define YY_NO_INPUT
 
-int yylex(void);
-
-int yyget_lineno (void);
-FILE *yyget_in (void);
-FILE *yyget_out (void);
-int yyget_leng (void);
-char *yyget_text (void);
-void yyset_lineno (int line_number);
-void yyset_in (FILE * in_str);
-void yyset_out (FILE * out_str);
-int yyget_debug (void);
-void yyset_debug (int  bdebug);
-int yylex_destroy (void);
- 
 int filter_snarfage = 0;
 int print = 1; 
 

Bug#765092: Add support for ppc64el platform

[Breno Leitao]

Package: ruby-ffi
Version: 1.9.6debian-1
Severity: serious
Tags: patch
Justification: fails to build from source

Hi,

The package ruby-ffi package fails to build on ppc64el due to two things:

 - A bug that consider ppc64 as powerpc (32 bits)
 - The platform was not added into the packages. 

So, I was able to create a fix to both, and now ruby-ffi builds fine on
ppc64el, fixing the problem described in 1) and using debian/README.porting to
generate the types for the new platform.

Thank you,
Breno
--- /dev/null
+++ ruby-ffi-1.9.6debian/lib/ffi/platform/powerpc64-linux/types.conf
@@ -0,0 +1,104 @@
+rbx.platform.typedef.__u_char = uchar
+rbx.platform.typedef.__u_short = ushort
+rbx.platform.typedef.__u_int = uint
+rbx.platform.typedef.__u_long = ulong
+rbx.platform.typedef.__int8_t = char
+rbx.platform.typedef.__uint8_t = uchar
+rbx.platform.typedef.__int16_t = short
+rbx.platform.typedef.__uint16_t = ushort
+rbx.platform.typedef.__int32_t = int
+rbx.platform.typedef.__uint32_t = uint
+rbx.platform.typedef.__int64_t = long
+rbx.platform.typedef.__uint64_t = ulong
+rbx.platform.typedef.__quad_t = long
+rbx.platform.typedef.__u_quad_t = ulong
+rbx.platform.typedef.__dev_t = ulong
+rbx.platform.typedef.__uid_t = uint
+rbx.platform.typedef.__gid_t = uint
+rbx.platform.typedef.__ino_t = ulong
+rbx.platform.typedef.__ino64_t = ulong
+rbx.platform.typedef.__mode_t = uint
+rbx.platform.typedef.__nlink_t = ulong
+rbx.platform.typedef.__off_t = long
+rbx.platform.typedef.__off64_t = long
+rbx.platform.typedef.__pid_t = int
+rbx.platform.typedef.__clock_t = long
+rbx.platform.typedef.__rlim_t = ulong
+rbx.platform.typedef.__rlim64_t = ulong
+rbx.platform.typedef.__id_t = uint
+rbx.platform.typedef.__time_t = long
+rbx.platform.typedef.__useconds_t = uint
+rbx.platform.typedef.__suseconds_t = long
+rbx.platform.typedef.__daddr_t = int
+rbx.platform.typedef.__key_t = int
+rbx.platform.typedef.__clockid_t = int
+rbx.platform.typedef.__timer_t = pointer
+rbx.platform.typedef.__blksize_t = long
+rbx.platform.typedef.__blkcnt_t = long
+rbx.platform.typedef.__blkcnt64_t = long
+rbx.platform.typedef.__fsblkcnt_t = ulong
+rbx.platform.typedef.__fsblkcnt64_t = ulong
+rbx.platform.typedef.__fsfilcnt_t = ulong
+rbx.platform.typedef.__fsfilcnt64_t = ulong
+rbx.platform.typedef.__fsword_t = long
+rbx.platform.typedef.__ssize_t = long
+rbx.platform.typedef.__syscall_slong_t = long
+rbx.platform.typedef.__syscall_ulong_t = ulong
+rbx.platform.typedef.__loff_t = long
+rbx.platform.typedef.*__qaddr_t = long
+rbx.platform.typedef.*__caddr_t = char
+rbx.platform.typedef.__intptr_t = long
+rbx.platform.typedef.__socklen_t = uint
+rbx.platform.typedef.u_char = uchar
+rbx.platform.typedef.u_short = ushort
+rbx.platform.typedef.u_int = uint
+rbx.platform.typedef.u_long = ulong
+rbx.platform.typedef.quad_t = long
+rbx.platform.typedef.u_quad_t = ulong
+rbx.platform.typedef.loff_t = long
+rbx.platform.typedef.ino_t = ulong
+rbx.platform.typedef.dev_t = ulong
+rbx.platform.typedef.gid_t = uint
+rbx.platform.typedef.mode_t = uint
+rbx.platform.typedef.nlink_t = ulong
+rbx.platform.typedef.uid_t = uint
+rbx.platform.typedef.off_t = long
+rbx.platform.typedef.pid_t = int
+rbx.platform.typedef.id_t = uint
+rbx.platform.typedef.ssize_t = long
+rbx.platform.typedef.daddr_t = int
+rbx.platform.typedef.key_t = int
+rbx.platform.typedef.clock_t = long
+rbx.platform.typedef.time_t = long
+rbx.platform.typedef.clockid_t = int
+rbx.platform.typedef.timer_t = pointer
+rbx.platform.typedef.size_t = ulong
+rbx.platform.typedef.ulong = ulong
+rbx.platform.typedef.ushort = ushort
+rbx.platform.typedef.uint = uint
+rbx.platform.typedef.int8_t = char
+rbx.platform.typedef.int16_t = short
+rbx.platform.typedef.int32_t = int
+rbx.platform.typedef.int64_t = long_long
+rbx.platform.typedef.u_int8_t = uchar
+rbx.platform.typedef.u_int16_t = ushort
+rbx.platform.typedef.u_int32_t = uint
+rbx.platform.typedef.u_int64_t = ulong_long
+rbx.platform.typedef.register_t = long
+rbx.platform.typedef.__sig_atomic_t = int
+rbx.platform.typedef.suseconds_t = long
+rbx.platform.typedef.__fd_mask = long
+rbx.platform.typedef.fd_mask = long
+rbx.platform.typedef.blksize_t = long
+rbx.platform.typedef.blkcnt_t = long
+rbx.platform.typedef.fsblkcnt_t = ulong
+rbx.platform.typedef.fsfilcnt_t = ulong
+rbx.platform.typedef.pthread_t = ulong
+rbx.platform.typedef.pthread_key_t = uint
+rbx.platform.typedef.pthread_once_t = int
+rbx.platform.typedef.socklen_t = uint
+rbx.platform.typedef.sa_family_t = ushort
+rbx.platform.typedef.rlim_t = ulong
+rbx.platform.typedef.__rlimit_resource_t = int
+rbx.platform.typedef.__rusage_who_t = int
+rbx.platform.typedef.__priority_which_t = int
--- ruby-ffi-1.9.6debian.orig/lib/ffi/platform.rb
+++ ruby-ffi-1.9.6debian/lib/ffi/platform.rb
@@ -59,6 +59,8 @@ module FFI
   x86_64
 when /i?86|x86|i86pc/
   i386
+when /ppc64|powerpc64/
+  powerpc64
 when /ppc|powerpc/
   powerpc
 else

Bug#764353: libhdf4: FTBFS on s390x and ppc64el: test failures

[Breno Leitao]

On Tue, 7 Oct 2014 20:12:32 +0200 Johan Van de Wauw johan.vandew...@gmail.com 
wrote:
 I'm aware of the issues.
 I've asked for porter access to see if I can fix these problems.
For what arch? For ppc64el, we have the machine pastel that is available as a
porterbox.

Let me know if you are having access to it.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732424: (no subject)

[Breno Leitao]

This is also affecting ppc64el, as shown:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/gstreamer0.10_0.10.36-1.2_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741785: (no subject)

[Breno Leitao]

I saw the same problem on ppc64el:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/seed_3.8.1-1_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735755: (no subject)

[Breno Leitao]

FWIW, this bug is also found during ppc64el bootstrap.

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/wmcoincoin_2.5.1e-1_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747557: (no subject)

[Breno Leitao]

hi Adrian-Ken,

On 07/24/2014 06:25 PM, Adrian-Ken Rueegsegger wrote:
 On 07/24/2014 10:25 PM, Breno Leitao wrote:
 this is a bug that is impacting ppc64el bootstrap also.
 
 Thanks for reporting.
 
 My recomendantion is to keep just a build-depend on gnat, unless you have 
 strict
 dependency of version 4.6, which is not the case in 90% of the packages that
 depends on version 4.6
 
 I will try to transition the package away from gnat-4.6 over the next
 few days and upload it as soon as I find a sponsor.
Great. That works. thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749806: (no subject)

[Breno Leitao]

hi Reto,

On 07/24/2014 06:20 PM, Reto Buerki wrote:
 On 07/24/2014 10:21 PM, Breno Leitao wrote:
 This is a bug that is impacting ppc64el bootstrap also.

 My recomendantion is to keep just a build-depend on gnat, unless you have 
 strict
 dependency of version 4.6, which is not the case in 90% of the packages that
 depends on version 4.6
 
 Your recommendation violates the Debian policy for Ada, section 4,
 second rule.
That is right, sorry about it. Can you help me to understand how to proceed 
then?

I understand that there are two cases here, for general packages that depends 
on gnat.

a) The package that depends on gnat version 4.6 specifically.
b) A package that depend on gnat, but not necessarily from version 4.6, it can
build and run on later gnat  version, as 4.9.


Based on these two cases, what is the case for pcscada?

I understand that the a case should always depend on gnat-4.6, and if the
architecture doesn't contain that specific version, then the package will never 
be
compiled for that architeceture.

Also, how to handle the b case, if it is depending on version 4.6 right now? 
They
should be upgraded to depend on a more recent version every time there is a gnat
release?


Thank you,
Breno


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749806: (no subject)

[Breno Leitao]

This is a bug that is impacting ppc64el bootstrap also.

My recomendantion is to keep just a build-depend on gnat, unless you have strict
dependency of version 4.6, which is not the case in 90% of the packages that
depends on version 4.6


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747557: (no subject)

[Breno Leitao]

this is a bug that is impacting ppc64el bootstrap also.

My recomendantion is to keep just a build-depend on gnat, unless you have strict
dependency of version 4.6, which is not the case in 90% of the packages that
depends on version 4.6


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728634: (no subject)

[Breno Leitao]

On 07/22/2014 07:01 PM, gregor herrmann wrote:
 On Tue, 22 Jul 2014 18:14:12 -0300, Breno Leitao wrote:
 
 I face the same problem during ppc64el bootstrap and gregor's patch solve 
 the problem.
 Gregor, do you mind making a NMU for it?
 
 Uploaded to DELAYED/2; after a short test (I remembered that I had an
 unused samba daemon around :)).
Great. Thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741804: (no subject)

[Breno Leitao]

FWIW, we also hit the same problem on ppc64el bootstrapping.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706185: (no subject)

[Breno Leitao]

Hi,

This is the third version of the patch, addressing some concerns by Helmut. The
changelog compared to the version two is:

 - Created a entry in the changelog
 - Fixes the patch directory, so, now you can apply with patch using -p1 instead
of -p2.

Thanks
Breno
Index: libpam-ldap-184/debian/changelog
===
--- libpam-ldap-184.orig/debian/changelog
+++ libpam-ldap-184/debian/changelog
@@ -1,3 +1,11 @@
+libpam-ldap (184-8.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not remove config files when removing the package from one architecture
+in a multiarch environemnt.  Closes: 706185
+
+ -- Breno Leitao bren...@br.ibm.com  Tue, 22 Jul 2014 14:31:57 +
+
 libpam-ldap (184-8.6) unstable; urgency=low
 
   * Non-maintainer upload.
Index: libpam-ldap-184/debian/libpam-ldap.postrm
===
--- libpam-ldap-184.orig/debian/libpam-ldap.postrm
+++ libpam-ldap-184/debian/libpam-ldap.postrm
@@ -7,7 +7,8 @@ PASSWDFILE=/etc/pam_ldap.secret
 
 action=$1
 
-if [ $action = purge ]; then
+if [ $action = purge ]  \
+[ $(dpkg-query --show libpam-ldap 2 /dev/null | wc -l) = 1 ]; then
rm -f $CONFFILE $PASSWDFILE
 fi
 
Index: libpam-ldap-184/debian/libpam-ldap.prerm
===
--- libpam-ldap-184.orig/debian/libpam-ldap.prerm
+++ libpam-ldap-184/debian/libpam-ldap.prerm
@@ -2,7 +2,8 @@
 
 set -e
 
-if [ $1 = remove ]; then
+if [ $1 = remove ]  \
+[ $(dpkg-query --show libpam-ldap 2 /dev/null | wc -l) = 1 ]; then
pam-auth-update --package --remove ldap
 fi
 

Bug#728634: (no subject)

[Breno Leitao]

Hi,

I face the same problem during ppc64el bootstrap and gregor's patch solve the 
problem.

Gregor, do you mind making a NMU for it?

Thanks
Breno


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706185: your mail

[Breno Leitao]

Hi Helmut,

On 07/18/2014 03:52 PM, Helmut Grohne wrote:
 While your patch moves a lot of files, it does not address the
 underlying problem. The libpam-ldap package still creates the very same
 configuration files using its postinst script and it still removes them
 in postrm.
Right. As I explained to you, I was planning to create a config-only package, 
and
a different package for the binaries, which doesn't seem to be the best 
solution,
as you already explained.

So, since these /etc/pam_ldap.conf is not a conffile, I am creating a patch that
just removes the file if there is no further package (libpam_ldap) installed in
the system (as from a different arch), thus, olving the problem here specified, 
as
it doesn't remove the /etc/pam_ldap.conf files if there are further packages
installed in the system.

I didn't touch the postinst packages because it is already configured to not
override an already installed configuration file.

The scripts becomes very short, and I am attaching as a RFC.

Thank you,
Breno

Index: libpam-ldap/libpam-ldap-184/debian/libpam-ldap.postrm
===
--- libpam-ldap.orig/libpam-ldap-184/debian/libpam-ldap.postrm
+++ libpam-ldap/libpam-ldap-184/debian/libpam-ldap.postrm
@@ -7,7 +7,8 @@ PASSWDFILE=/etc/pam_ldap.secret
 
 action=$1
 
-if [ $action = purge ]; then
+if [ $action = purge ]  \
+[ $(dpkg-query --show libpam-ldap 2 /dev/null | wc -l) = 1 ]; then
rm -f $CONFFILE $PASSWDFILE
 fi
 
Index: libpam-ldap/libpam-ldap-184/debian/libpam-ldap.prerm
===
--- libpam-ldap.orig/libpam-ldap-184/debian/libpam-ldap.prerm
+++ libpam-ldap/libpam-ldap-184/debian/libpam-ldap.prerm
@@ -2,7 +2,8 @@
 
 set -e
 
-if [ $1 = remove ]; then
+if [ $1 = remove ]  \
+[ $(dpkg-query --show libpam-ldap 2 /dev/null | wc -l) = 1 ]; then
pam-auth-update --package --remove ldap
 fi
 

Bug#706185: (no subject)

[Breno Leitao]

Hi,

I played a little bit with this bug, and I find one possible solution is to have
those common config files in a -common package that becomes arch=all. Thus, they
would not be replaced or removed in the scenario reported by Andreas.

In this case, package src:libpam-ldap would generate two binary packages
libpam-ldap and libpam-ldap-common, with the following files:

# dpkg -c libpam-ldap_184-8.6_ppc64el.deb   | awk '{print $6}'
./
./etc/
./usr/
./usr/share/
./usr/share/doc/
./usr/share/doc/libpam-ldap/
./usr/share/doc/libpam-ldap/AUTHORS
./usr/share/doc/libpam-ldap/changelog.gz
./usr/share/doc/libpam-ldap/copyright
./usr/share/doc/libpam-ldap/buildinfo_ppc64el.gz
./usr/share/doc/libpam-ldap/README.gz
./usr/share/doc/libpam-ldap/README.Debian
./usr/share/doc/libpam-ldap/changelog.Debian.gz
./usr/share/libpam-ldap/
./lib/
./lib/powerpc64le-linux-gnu/
./lib/powerpc64le-linux-gnu/security/
./lib/powerpc64le-linux-gnu/security/pam_ldap.so

and

# dpkg -c libpam-ldap-common_184-8.6_all.deb  | awk '{print $6}'
./
./usr/
./usr/share/
./usr/share/man/
./usr/share/man/man5/
./usr/share/man/man5/pam_ldap.conf.5.gz
./usr/share/pam-configs/
./usr/share/pam-configs/ldap
./usr/share/doc/
./usr/share/doc/libpam-ldap-common/
./usr/share/doc/libpam-ldap-common/AUTHORS
./usr/share/doc/libpam-ldap-common/changelog.gz
./usr/share/doc/libpam-ldap-common/copyright
./usr/share/doc/libpam-ldap-common/buildinfo_all.gz
./usr/share/doc/libpam-ldap-common/README.gz
./usr/share/doc/libpam-ldap-common/changelog.Debian.gz
./usr/share/doc/libpam-ldap/
./usr/share/doc/libpam-ldap/ldapns.schema
./usr/share/doc/libpam-ldap/LDAP-Permissions.txt
./usr/share/doc/libpam-ldap/examples/
./usr/share/doc/libpam-ldap/examples/pam.conf
./usr/share/doc/libpam-ldap/examples/pam.d/
./usr/share/doc/libpam-ldap/examples/pam.d/ssh
./usr/share/doc/libpam-ldap/examples/pam.d/shutdown
./usr/share/doc/libpam-ldap/examples/pam.d/samba
./usr/share/doc/libpam-ldap/examples/pam.d/gdm
./usr/share/doc/libpam-ldap/examples/pam.d/su
./usr/share/doc/libpam-ldap/examples/pam.d/reboot
./usr/share/doc/libpam-ldap/examples/pam.d/xserver
./usr/share/doc/libpam-ldap/examples/pam.d/halt
./usr/share/doc/libpam-ldap/examples/pam.d/rsh
./usr/share/doc/libpam-ldap/examples/pam.d/rexec
./usr/share/doc/libpam-ldap/examples/pam.d/passwd
./usr/share/doc/libpam-ldap/examples/pam.d/mcserv
./usr/share/doc/libpam-ldap/examples/pam.d/xscreensaver
./usr/share/doc/libpam-ldap/examples/pam.d/xdm
./usr/share/doc/libpam-ldap/examples/pam.d/imap
./usr/share/doc/libpam-ldap/examples/pam.d/login
./usr/share/doc/libpam-ldap/examples/pam.d/other
./usr/share/doc/libpam-ldap/examples/pam.d/linuxconf
./usr/share/doc/libpam-ldap/examples/pam.d/chfn
./usr/share/doc/libpam-ldap/examples/pam.d/xlock
./usr/share/doc/libpam-ldap/examples/pam.d/pop
./usr/share/doc/libpam-ldap/examples/pam.d/rlogin
./usr/share/doc/libpam-ldap/examples/pam.d/chsh
./usr/share/doc/libpam-ldap/examples/pam.d/vlock
./usr/share/doc/libpam-ldap/examples/pam.d/poweroff
./usr/share/doc/libpam-ldap/examples/pam.d/ftp
./usr/share/doc/libpam-ldap/examples/pam.d/kde
./usr/share/doc/libpam-ldap/examples/pam.d/linuxconf-pair
./usr/share/doc/libpam-ldap/examples/pam.d/ppp
./usr/share/doc/libpam-ldap/examples/chfn
./usr/share/doc/libpam-ldap/examples/chsh
./usr/share/libpam-ldap/
./usr/share/libpam-ldap/ldap.conf

I created a patch to do it, and I would love to hear feedback about it.

Thank you,
Breno

Index: libpam-ldap-184/debian/control
===
--- libpam-ldap-184.orig/debian/control
+++ libpam-ldap-184/debian/control
@@ -8,10 +8,20 @@ Build-Depends: cdbs (= 0.4.93~), quilt,
 Package: libpam-ldap
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}, libpam-runtime (= 1.0.1-6), libpam0g (= 1.1.3-2)
+Depends: ${shlibs:Depends}, ${misc:Depends}, libpam-runtime (= 1.0.1-6), libpam0g (= 1.1.3-2), libpam-ldap-common (= ${binary:Version})
 Suggests: libnss-ldapd | libnss-ldap 
 Description: Pluggable Authentication Module for LDAP
  This package provides an interface between an LDAP server and the PAM
  user authentication system. Using it along with libnss-ldapd or libnss-ldap
  allows LDAP to entirely replace other lookup methods (such as NIS or
+ flat-file) for system account tables.
+
+Package: libpam-ldap-common
+Architecture: all
+Depends:
+Suggests:

Bug#750133: (no subject)

[Breno Leitao]

I am still facing the same issue on package 2.0.0-5, which is suppose 
to contain the fix. 

I tested on ppc64el, take a look at the problem, which seems to be the same.

The following tests FAILED:
  1 - INTEGRATION_audio (Timeout)
  3 - INTEGRATION_cfm_damping_implicit_spring_damper (Timeout)
  5 - INTEGRATION_fixed_joint_reduction (Timeout)
  7 - INTEGRATION_joint_axis_frame (Timeout)
  9 - INTEGRATION_provide_feedback (Timeout)
 11 - PERFORMANCE_parser_urdf (Timeout)
 13 - UNIT_SDF_TEST (Timeout)
 15 - UNIT_Console_TEST (Timeout)
 19 - UNIT_parser_urdf_TEST (Timeout)
Errors while running CTest
make[2]: *** [test] Error 8
make[2]: Leaving directory `/«PKGBUILDDIR»/obj-powerpc64le-linux-gnu'
dh_auto_test: make -j1 test ARGS+=-j1 returned exit code 2
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Full build log could be found at:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/sdformat_2.0.0-5_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738430: (no subject)

[Breno Leitao]

I am facing the same problem during ppc64el bootstrap.
The build log could be found at:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/idzebra_2.0.44-3.1_ppc64el.build

I would really appreciate if this get fixed. 

Thank you,
Breno


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713671: (no subject)

[Breno Leitao]

I see the same problem during ppc64el bootstrap. I would appreciate
if the patch gets accepted:

The build log for ppc64el could be found at:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/hotkeys_0.5.7.4-0.3_ppc64el.build

Thank you,
Breno


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750331: (no subject)

[Breno Leitao]

The same bug was hit during the compilation on ppc64el and the 
full log could be seen at:

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/setools_3.3.8-3_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718068: (no subject)

[Breno Leitao]

Found the same problem on ppc64el

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/csh_20110502-2_ppc64el.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724218: (no subject)

[Breno Leitao]

I am facing the exact same problem during ppc64el bootstrap, as shown:

Makefile:9: config.mk: No such file or directory
Makefile:10: /subdir.mk: No such file or directory
make[1]: Entering directory `/«PKGBUILDDIR»'
make[1]: *** No rule to make target `/subdir.mk'.  Stop.
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_clean: make -j1 distclean returned exit code 2
make: *** [clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit 
status 2


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713672: (no subject)

[Breno Leitao]

Hi,

This bugs is avoiding xca to be compiled in ppc64el platform. If you could 
accept
the attached patch,the ppc64el team would appreciate.

Thank you,
Breno


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735832: (no subject)

[Breno Leitao]

Hi,

We are facing the same problem reported by this bug on ppc64el bootstrap.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733355: (no subject)

[Breno Leitao]

We are finding the same problem during ppc64el bootstrap.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747786: (no subject)

[Breno Leitao]

I also found the same problem during ppc64el bootstrap and hideki's patch fix 
the
problem.

Please, consider applying it to the libwfut source.

Thank you


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718062: (no subject)

[Breno Leitao]

I see the same problem when bootstrap ppc64el.

http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/libnfo_1.0.1-1_ppc64el-20140502-0056.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749058: liboping: Regression: new version (1.6.2-5) FTBFS

[Breno Leitao]

Package: liboping
Version: 1.6.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

With the recent change on liboping, it is not able to be build anymore.  I
tested the build on the ppc64el and amd64 architectures, and both show the same
problem:


src/Makefile.am:50: `pkgconfig_DATA' is used but `pkgconfigdir' is undefined
autoreconf: automake failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
make[1]: *** [override_dh_autoreconf] Error 2
make[1]: Leaving directory `/home/brenohl/source/liboping-1.6.2'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


I believe that it happened due to the last change. Version 1.6.2-4 builds fine
on both architectures.

Thank you,
Breno


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

Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710635: (no subject)

[Breno Leitao]

I just reproduced this bug on the ppc64el buildd. This is exact some error:

/usr/bin/ld: cannot find -lz

http://deb1.ltc.br.ibm.com/wanna-buildd-upstream/logs/pynac_0.2.6-1_ppc64el-20140510-0908.build


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org