Re: Bug#1057717: cmake ftbfs on ppc64el (and ppc64)

[Adrian Bunk]

Version: 1.48.0-1

On Sat, Jan 13, 2024 at 03:49:17PM +0100, John Paul Adrian Glaubitz wrote:
> Control: tags -1 +patch
> 
> On Fri, 2024-01-12 at 01:31 +0100, John Paul Adrian Glaubitz wrote:
> > This has now been tracked down to the libuv upstream change that introduced 
> > support
> > for io_uring [1]. This regression is tracked now in a new issue for libuv 
> > [2].
> 
> The attached patch disables io_uring on ppc64 and ppc64el for the time being 
> until
> the upstream issue has been resolved.

This patch has been included in upstream 1.48.0, which fixed this issue.

Disabling misses out on the performance improvements by this change,
but it still works as good as before io_uring support was added.

> Adrian
>...

cu
Adrian

Re: LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)

[Adrian Bunk]

On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
> Hi,
> 
> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
> > > what about the
> > > following:
> > > - make all test failures fatal on a*64 (since upstream tests these), and
> > > - make smoketest failures fatal on all architectures (including ports)
> 
> That was implemented (+ two more important tests) in experimental. See
> https://buildd.debian.org/status/package.php?p=libreoffice
> 
> It does
> - bridgetest
> - smoketest
> - pyuno
> 
> What fails for release archs astonishingly is only mips(64)el.

It also failed on riscv64 (and powerpc), so that seems to be
a criteria that catches the known-broken builds.

>...
> This test extension to be installed is a Java extension.
> So I am running a nojava build on eller now... I don't really like disabling
> Java since this opens Pandoras box but for mips64el we probably could do
> that.

It would also hint at a MIPS problem in LibreOffice,
which might or might not be specific to Java.

AFAIK OpenJDK on MIPS does not have any known major issues.

The Zero build of OpenJDK on MIPS is of course slow,
but that's also true on armel where the build succeeded.

> Regards,
> 
> Rene

cu
Adrian

BTW: The MIPS-specific discussion should continue on debian-mips instead
 of debian-ports. 

Re: unbreaking LibreOffices tests on at least release architectures

[Adrian Bunk]

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
> 
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> > 
> > And have Format->Character in Impress crash with Bus error like on
> > mipsel? That doesn't sound too good for basic quality.
> > 
> > There is a "smoketest" but it does just basic start. open, close stuff.
> > Not even basic usage.
> 
> That said, that is the smoketest on mipsel:
>...

Assuming the smoketest currently also fails on riscv64, what about the 
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)

> Regards,
> 
> Rene

cu
Adrian

Re: unbreaking LibreOffices tests on at least release architectures

[Adrian Bunk]

On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them if I
> report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
> 
> And have Format->Character in Impress crash with Bus error like on mipsel?
> That doesn't sound too good for basic quality.
> 
> There is a "smoketest" but it does just basic start. open, close stuff. Not
> even basic usage.

Let's be realistic regarding the available options, because the one you 
want is not available.

You want every !a*64 architecture to have a porter spending time on 
fixing libreoffice.

And thinking this through, since regressions in new upstream versions
are expected to be frequent you want new upstream versions of libreoffice
blocked from testing migration by any regression on one architecture
until a porter for this architecture has fixed the regression.

A new architecture like riscv64 might have enough porters for fixing 
issues once or for some limited duration. That's it.

For each architecture you have the options:
1. declare libreoffice good enough on this architecture, or
2. don't build libreoffice on this architecture

There is no third option that architectures will provide porters fixing 
your package all the time.

There are several other packages of comparable complexity, size and 
testsuite (e.g. mozjs* or rustc). For a successful build they are using 
either just a smoketest, or a maximum number of tolerable testsuite 
failures.

> Regards,
> 
> Rene

cu
Adrian

Re: unbreaking LibreOffices tests on at least release architectures

[Adrian Bunk]

On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> I won't be of much help here unfortunately, except
> maybe testing patches, but then again there's porterboxes
>...

You are the only one who could realistically debug many of these.

E.g. on armel it says:
  Fatal exception: Signal 6
  Stack:
  /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4]
  /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534]
  /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0]
  /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c]
  /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360]
  Aborted (core dumped)

Fixing something like this would involve generating a backtrace,
and then you are likely the only person in Debian who could tell
what is actually going on there.

There are likely also build or debug tricks you know that a porter would 
not know.

Debugging something like this is only feasible with reasonable effort if 
a porter who knows the port with its caveats debugs it together with a
package maintainer who knows the internals of the package.


On Mon, Jun 19, 2023 at 12:04:45AM +0200, Kurt Roeckx wrote:
>...
> Do you think Debian doesn't have any developers/porters anymore?
>...

For porters that's actually close to being true.

There were times when porter numbers for a release architecture were 
numbers like 6 or 9.

No release architecture in bookworm had more than 2 porters.

No porters were required on amd64, the number of distinct people who are 
listed as porter for one or more of the 8 other bookworm release 
architecture is 5 DDs and 2 non-DDs.


On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any other down below and it's actually a
> new architecture anyway.
>
> Also note I am not talking about the debian-ports architectures. Those I
> forgot and I have no problems making them stay into "testsuite ran but
> results ignored" set.
>
> Right now, the only architectures where the test actually work (ignoring the
> occassional breakage on arm64 which is fixed upstream since they do
> aarch64 flatpak builds) is amd64 and arm64.
>
> With various different 32-bit, endian and whatever else breakage
> ppopping up the other architectures constantly were moved in the set
> where the testsuite was run but the results were ignored. For s390x,
> where the macros tests hangs it even was in the set where the tests even
> were not ran, since a hang then also ends up in
> "E: Build killed with signal TERM after 150 minutes of inactivity".
>
> This was sweeping under the carpet for sure, but this was needed due to
> it being a release architecture :(
>...

For such a complex package I would expect 32bit breakage in every 
release if upstream no longer tests on 32bit.

The pragmatic option would be to run only a smoketest for build success 
on architectures not tested by upstream.


cu
Adrian

Re: Bug#1018039: FTBFS on ppc64el with gcc-12

[Adrian Bunk]

On Thu, Nov 17, 2022 at 12:46:59PM +0100, John Paul Adrian Glaubitz wrote:
>...
> On 8/24/22 16:50, Frédéric Bonnard wrote:
> > powerpc-utils 1.3.9-1 fails to build atm with gcc-12.
> > I checked latest 1.3.10 and it's roughly the same.
> > I've opened an issue upstream.
> 
> Interestingly, the error due to "-Werror=maybe-uninitialized" does not show
> on the openSUSE builds, see [1]. openSUSE does not ship any patch to address
> the issue though.

openSUSE overwrites the CFLAGS set in configure.ac (including -Werror) with
  make CFLAGS="..."

> Fedora doesn't seem to have a patch to address the issue either [2].
>...

https://src.fedoraproject.org/rpms/powerpc-utils/blob/rawhide/f/powerpc-utils.spec#_72

> Adrian
>...

cu
Adrian

Re: Bug#979609: swt4-gtk segfaults on ppc64el

[Adrian Bunk]

On Tue, Jan 12, 2021 at 07:06:36PM +, Sudip Mukherjee wrote:
> I had been testing little more and I can see the same problem with
> other packages (syndie and stegosuite) which are using
> libswt-cairo-gtk-4-jni.
> So, all the three packages using libswt-cairo-gtk-4-jni triggers the
> segfault in ppc64el.

Adding debian-powerpc so that a porter can check.

> Regards
> Sudip

cu
Adrian

Re: Bug#982740: pulseaudio: FTBFS on ppc64el

[Adrian Bunk]

Control: found -1 14.1-1

On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Package: pulseaudio
> Version: 14.2-1
> Severity: serious
> 
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> which should arguably be a higher severity, but let's focus on getting
> 14.2-1 built properly.
> 
> https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
> 
> Here's where the ppc64el build fails:
> 
> 
> FAIL: cpu-volume-test
> =
> 
> Running suite(s): CPU
> 0%: Checks: 1, Failures: 1, Errors: 0
> tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> FAIL cpu-volume-test (exit status: 1)
> 
> 
> 
> It's worth noting that 14.1-1 built just fine on ppc64el, and the only
> non-debian change between 14.1 and 14.2 is this:
>...

Both versions fail for me the same way on plummer.

Adding debian-powerpc so that a porter can check.

cu
Adrian

Re: Porter roll call for Debian Bullseye

[Adrian Bunk]

On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> >  I am sorry for the later response.
> >Hi,
> > 
> >   I am an active porter for the following architectures and I intend
> >   to continue this for the lifetime of the Bullseye release (est. end
> >   of 2024):
> > 
> >   For mipsel and mips64el, I
> >   - test most packages on this architecture
> >   - run a Debian testing or unstable system on port that I use regularly
> >   - fix toolchain issues
> 
> great ;-)  gcc-cross-mipsen and gcc-10-cross-mipsen have never been in 
> testing ...
>...

This problem has now been resolved:
https://tracker.debian.org/pkg/gcc-defaults-mipsen
https://tracker.debian.org/pkg/gcc-10-cross-mipsen

cu
Adrian

Re: Porter roll call for Debian Bullseye

[Adrian Bunk]

On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> >  I am sorry for the later response.
> >Hi,
> > 
> >   I am an active porter for the following architectures and I intend
> >   to continue this for the lifetime of the Bullseye release (est. end
> >   of 2024):
> > 
> >   For mipsel and mips64el, I
> >   - test most packages on this architecture
> >   - run a Debian testing or unstable system on port that I use regularly
> >   - fix toolchain issues
> 
> great ;-)  gcc-cross-mipsen and gcc-10-cross-mipsen have never been in 
> testing ...

The main blocker for that seems to be a bug that was fixed in
gcc-10 10.2.0-20, a new source upload with the gcc-10-source
build dependency bumped to (>= 10.2.0-20~) should fix that.

binNMU won't work due to binary-all.

> >   - triage arch-specific bugs
> >   - fix arch-related bugs
> 
> any help with #972269 ?

I looked into it back then, at least for me there was nothing obvious 
why dbus-python failed and not other packages.

A few months earlier one other package had a similar problem,
but it seems rare enough that it shouldn't be a high priority
for anyone.

cu
Adrian

Re: Large reduction in portability of some KDE packages

[Adrian Bunk]

On Sat, May 30, 2020 at 02:24:16PM +0200, John Paul Adrian Glaubitz wrote:
> On 5/30/20 2:17 PM, Adrian Bunk wrote:
> > On Sat, May 30, 2020 at 01:58:02PM +0200, John Paul Adrian Glaubitz wrote:
> >> Hello!
> >>
> >> I was wondering whether there is a way around this large reduction in 
> >> portability
> >> of KDE that occurred recently [1]?
> >> ...
> > 
> > "recently" was 3 years ago, it is already this way in buster.
> 
> As far as I can see, some of the packages used to use qtwebkit not too long
> ago which is perfectly portable to all architectures.

The one you linked moved to qtwebengine 3 years ago,
and around that time a large part of KDE moved.

> > There is no way around it with reasonable effort,
> > unless Google support riscv64 in their browser.
> The way around it is to not use Google technologies because Google doesn't
> care about open source and the community unless it serves their own
> interests.

I would also personally prefer if KDE would go back to qtwebkit,
but distributions can only use whatever upstream is choosing.

KDE upstream has the right to make such choices if they think
it delivers a better KDE experience.

> Adrian

cu
Adrian

Re: Large reduction in portability of some KDE packages

[Adrian Bunk]

On Sat, May 30, 2020 at 01:58:02PM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> I was wondering whether there is a way around this large reduction in 
> portability
> of KDE that occurred recently [1]?
>...

"recently" was 3 years ago, it is already this way in buster.

There is no way around it with reasonable effort,
unless Google support riscv64 in their browser.

> Adrian

cu
Adrian

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Adrian Bunk]

On Mon, May 11, 2020 at 08:31:37AM +0200, Mathieu Malaterre wrote:
> On Sun, May 10, 2020 at 10:01 PM Paul Gevers  wrote:
>...
> > On 10-05-2020 15:25, Paul Gevers wrote:
> > > I'm running another check on "cannot allocate memory in static TLS
> > > block" now, will take a while.
> >
> > Also for this one, only vtkplotter showed up.
> 
> Did you check #951704 ? This affect python3 package using jemalloc.

I wrote earlier:

On Thu, May 07, 2020 at 01:16:15PM +0300, Adrian Bunk wrote:
>...
> #951704 looks like a similar but unrelated problem with jemalloc.
>...

My current knowledge is:

The jemalloc problem is a problem affecting all architectures, 
that will likely need a fix/workaround in jemalloc.

The libgomp problem is a problem only on arm64/ppc64/ppc64el where
upstreams seem to finally have agreed where it should be fixed (glibc).

cu
Adrian

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Adrian Bunk]

On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote:
>...
> On 07-05-2020 10:07, Adrian Bunk wrote:
> > This is a toolchain problem affecting many packages:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25051
> 
> Do you have any rough estimate how many?
>...

Other bugs I can quickly find are #930039 and #945878.

AFAIR I have seen maintainers adding workarounds for arm64+ppc64el FTBFS
caused by this bug that did not have bugs in the BTS.

#951704 looks like a similar but unrelated problem with jemalloc.

> Is there any way to predict which packages are effected,

Anything loading a plugin that is directly or indirectly linked
with libgomp might or might not have this problem.

Python C extensions are the most frequent ones.

Heavy usage of Python code with C extensions tends to be in the more
scientific areas of the archive, I'd guess many of these packages have
no users at all on ppc64el or arm64 who would report bugs (Raspbian is armhf).

python3-vtkplotter -> python3-vtk7 -> libvtk -> FFmpeg libraries
  -> libsoxr -> libgomp

> or to detect which packages are effected?

"import vtk" works, but "import vtkplotter" blows up when importing vtk.

This is similar to the two different OpenSSL versions in stretch, where 
module load order might determine whether Apache segfaults or starts.

>...
> > Is there a non-manual way to express that the autopkgtest must not run 
> > on arm64 and powerpc64el?
> 
> There is currently not even a manual way except for marking the test as
> skippable and exitting with error code 77 on unsupported architectures.
> Mind you, I don't think toolchain issues should be marked at the package
> level (but maybe you didn't mean that).

vtkplotter: flagged for removal in 6.3 days

The big hammer would be to remove the autopkgtest...

> If we can detect this failure
> mode (and similar ones in the future) we can of course generate hints
> based on this heuristics and have the failures ignored until the
> toolchain issues are fixed.

A failing arm64 or ppc64el autopkgtest log containing the string
"libgomp.so.1: cannot allocate memory in static TLS block"
is this bug.

> Paul

cu
Adrian

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Adrian Bunk]

On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote:
>...
> However, it fails on arm64. I copied some of the output at the bottom of
> this report.
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
>...
> https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtkplotter/4281870/log.gz
> 
> autopkgtest [12:57:24]: test python3: [---
> Processing test_actors.py script..
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 5, in
> 
> from .vtkIOFFMPEGPython import *
> ImportError: /lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory
> in static TLS block
>...

This is a toolchain problem affecting many packages:
https://sourceware.org/bugzilla/show_bug.cgi?id=25051

There is nothing a binary-all python module can do to fix
architecture-specific toolchain bugs.

Is there a non-manual way to express that the autopkgtest must not run 
on arm64 and powerpc64el?

cu
Adrian

Bug#856809: gcc-6 on ppc64el: internal compiler error in push_reload, at reload.c:1349

[Adrian Bunk]

Package: gcc-6
Version: 6.3.0-8
Severity: serious
Control: affects -1 src:d-itg src:gtk-gnutella

https://buildd.debian.org/status/fetch.php?pkg=gtk-gnutella=ppc64el=1.1.8-2+b1=1488642493=0

...
cc -c -I../.. -I.. -I../if/gen -pthread -I/usr/include/glib-2.0 
-I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -I/usr/include/p11-kit-1  
-DCORE_SOURCES -DCURDIR=src/core -O2 -g -pthread -pipe -W -Wall -Wformat=2 
-Wshadow  fileinfo.c
fileinfo.c: In function 'file_info_retrieve_binary':
fileinfo.c:2113:1: internal compiler error: in push_reload, at reload.c:1349
 }
 ^



https://buildd.debian.org/status/fetch.php?pkg=d-itg=ppc64el=2.8.1-r1023-3+b2=1488648471=0

...
[ CXX ] ITGSend.o <- ITGSend.cpp
ITGSend.cpp: In function 'void* flowParser(void*)':
ITGSend.cpp:1024:5: warning: this 'if' clause does not guard... 
[-Wmisleading-indentation]
 if (flows[id].l4Proto == LX_ERROR_BYTE)
 ^~
ITGSend.cpp:1029:6: note: ...this statement, but the latter is misleadingly 
indented as if it is guarded by the 'if'
  flows[id].minPayloadSize = flows[id].minPayloadSize + sizeof(int);
  ^
ITGSend.cpp: In function 'void* flowSender(void*)':
ITGSend.cpp:2641:49: warning: enumeral mismatch in conditional expression: 
'' vs '' [-Wenum-compare]
prototype = (DestHost->ai_family == AF_INET) ? IPPROTO_ICMP : 
IPPROTO_ICMPV6;
 ^
ITGSend.cpp:3608:1: internal compiler error: in push_reload, at reload.c:1349
 }
 ^

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

[Adrian Bunk]

Source: yadifa
Version: 2.2.2-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=yadifa=ppc64el=2.2.2-1=1480164499

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

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Adrian Bunk]

On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> > 
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if no other flags marks it as to be
> > >disabled) on all architectures were gcc has not enabled this by
> > >default.
> > 
> > … that. And that is just plain wrong. Either dpkg should inject
> > -specs= stuff on all architectures or on none. Differing like this
> > just invites hidden and hard to track down bugs.
> 
> As long as gcc enables PIE on a subset, there will be need to inject
> some form of specs on either subset of those arches, either on
> hardening=+pie or on hardening=-pie, pick yout poison. :(
>...

Both gcc and dpkg playing with PIE just increased the number of bugs
without bringing any benefit.

I fixed many PIE related issues in packages when the gcc change was.

And now we got a new batch of FTBFS bugs for cases where the
dpkg specs change broke packages using "hardening=+all,-pie".

Please do the following:
1. discuss with porters whether PIE is working on their architecture
2. gcc and dpkg maintainers have to agree which package enables PIE

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845082: numexpr FTBFS on ppc64el: test failures

[Adrian Bunk]

Source: numexpr
Version: 2.6.1-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=numexpr=ppc64el=2.6.1-1=1479607449

Lots of failures like:

...
==
FAIL: test_scalar0_int_aggressive_OPERATIONS_0309 (__main__.TestExpressions)
--
Traceback (most recent call last):
  File "numexpr/tests/test_numexpr.py", line 1011, in method
return func()
  File "numexpr/tests/test_numexpr.py", line 583, in method
neval, type(neval), shape(neval))
AssertionError: '3 ** (b+3)'
(test_scalar=0, dtype='int', optimization='aggressive', exact=False,
 npval=array([27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 
27,
   27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
   27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
   27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
   27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
   27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27]) ( - (100,))
 neval=array([26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 
26,
   26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
   26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
   26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
   26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
   26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26]) ( - (100,)))

==
...

Re: Bug#842513: vlc: immediate crash on launch on powerpc

[Adrian Bunk]

On Tue, Nov 08, 2016 at 03:29:43PM -0500, Lennart Sorensen wrote:
>...
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>...
> And I realized the reason it was broken is that when using -maltivec and
> -O4 (which vlc uses), you get -ftree-vectorize automatically enabled
> which means gcc starts to automatically generate vector instructions
> all over the place, which is not desired in this case.  It rather defeats
> the purpose of having a cpu feature check after all.

I do not understand this part.

-maltivec should only be set for the code that is behind the runtime 
feature check, so this code is only run on hardware that has AltiVec.

cu
Adrian

[1] 

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#842513: vlc: immediate crash on launch on powerpc

[Adrian Bunk]

On Tue, Nov 01, 2016 at 01:08:03PM -0400, Lennart Sorensen wrote:
> On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > > This doesn't looks wrong to me.
> > > 
> > > Note that depending on the software --enable-altivec can either mean
> > > - compile unconditionally for AltiVec, or
> > > - enable AltiVec parts with autodetection to only use them when the
> > >   hardware supports it
> > 
> > Well in VLC it means build with -maltivec among other things.
> > 
> > > As I already wrote, vlc contains AltiVec-specific code and autodetection 
> > > for using it only when the hardware supports it.
> > > 
> > > This should be enabled on all ppc ports, except the SPE one.
> > > 
> > > --enable-altivec also adding -maltivec elsewhere is a bug.
> > 
> > Well it certainly appears to have been done on purpose in the configure
> > script.  Maybe it is a bug.  Perhaps I should poke it a bit...
> > 
> > > And due to this bug the whole AltiVec autodetection in vlc is
> > > pretty useless.
> > 
> > Well if it has such auto detection, then yes it is.
> 
> I currently suspect:
> 
> configure.ac:
> ...
>   ])
>   VLC_RESTORE_FLAGS
>   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
> CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"  <-- this looks wrong
> AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
> are available.])
> VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> ...
> 
> I think that line should not be there since all over CPPFLAGS is used as
> part of the COMPILE variable, meaning not just CFLAGS gets -maltivec when
> needed through ALTIVEC_CFLAGS, but in fact everywhere that has CPPFLAGS
> gets it, meaning everything.

I was more suspecting the VLC_ADD_CFLAGS() would be the problem,
but since the build log says "-maltivec -maltivec" it is actually
likely that this is wrong in more than one place.

> I will try compile testing that as soon as I have the system ready.

Thanks.

> Len Sorensen

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#842513: vlc: immediate crash on launch on powerpc

[Adrian Bunk]

On Tue, Nov 01, 2016 at 09:56:45AM -0400, Lennart Sorensen wrote:
> On Mon, Oct 31, 2016 at 11:13:00PM +0200, Adrian Bunk wrote:
> > This actually looks like a bug in upstream configure.ac to me:
> > VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> > ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} 
> > ${ac_cv_c_altivec_abi}"
> > VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} 
> > ${ac_cv_c_altivec_abi}])
> > 
> > It is correct that this adds -maltivec to AltiVec-specific code,
> > and vlc has proper autodetection to run this only when AltiVec
> > is actually present.
> > 
> > The VLC_ADD_CFLAGS here look just wrong - it is not the job of 
> > configure.ac to add such flags to generic code (whatever march
> > and hardware features are present is defined through compiler
> > defaults and the CFLAGS passed by the user).
> 
> Actually what looks really wrong is that debian/rules builds ffmpeg with
> --disable-altivec and then builds vlc with --enable-altivec.

This doesn't looks wrong to me.

Note that depending on the software --enable-altivec can either mean
- compile unconditionally for AltiVec, or
- enable AltiVec parts with autodetection to only use them when the
  hardware supports it

> Since powerpc can't assume you have altivec, perhaps vlc shouldn't be
> built with it, or at least ought to have justification for why it is
> done that way.
>...

As I already wrote, vlc contains AltiVec-specific code and autodetection 
for using it only when the hardware supports it.

This should be enabled on all ppc ports, except the SPE one.

--enable-altivec also adding -maltivec elsewhere is a bug.

And due to this bug the whole AltiVec autodetection in vlc is
pretty useless.

> Len Sorensen

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#842513: vlc: immediate crash on launch on powerpc

[Adrian Bunk]

Control: retitle -1 vlc: configure.ac altivec setting broken

On Sun, Oct 30, 2016 at 11:40:50AM +, James Cowgill wrote:
>...
> On 30/10/16 00:16, Robert Ou wrote:
> > On Sat, Oct 29, 2016 at 3:43 PM, James Cowgill  wrote:
> >> Control: tags -1 help
> >> Control: severity -1 grave
> >>
> >> Hi,
> >>
> >> On 29/10/16 23:00, Robert Ou wrote:
> >>> Package: src:vlc
> >>> Version: 2.2.4-7
> >>> Severity: normal
> >>>
> >>> Dear Maintainer,
> >>>
> >>> I decided I wanted to test the performance of Debian PowerPC on my
> >>> ancient iMac, and I discovered that vlc will immediately crash with an
> >>> illegal instruction right after showing the "Privacy and Network Access
> >>> Policy" window and before showing the main window. The crashes look like
> >>> the following:
> >>>
> >>> [ 1560.952016] vlc[997]: unhandled signal 4 at 0ea48f58 nip 0ea48f58 lr 
> >>> 0ea48f4c code 30001
> >>
> >> As powerpc is a release architecture, this bug is RC.
> >>
> >> I tried running vlc on partch. It managed to get further, but then
> >> segfaulted inside QT so it's probably a separate issue. I also had to
> >> run it in xvfb so it probably gets different results.
> >>
> >> Specifically what powerpc hardware do you have? Could you run vlc within
> >> gdb to determine which instruction it SIGILLs on (try 'layout asm')?
> > 
> > I was testing on a first-generation iMac with a 333 MHz PowerPC 750
> > (G3). Running vlc under gdb shows that the crash occurs in
> > libqt4_plugin.so in QRect::adjusted. The crash occurs on a "lvx
> > v0,r10,r5" opcode, which is an Altivec opcode. The G3 however does not
> > support Altivec. Here is a backtrace and some more debug information:
> 
> This explains it. From the PowerPC FAQ:
> https://wiki.debian.org/PowerPC/FAQ#VLC_crashes_on_startup._What.27s_up_with_that.3F
> 
> "
> If VLC immediately crashes, it's probably because you're on a G3 and
> VLC was compiled with Altivec instructions. To use VLC on a G3, you
> must compile it with the configure option --disable-altivec.
> "
> 
> Having said that, I think adding something to vlc's preinst to prevent
> installation on systems without altivec would be a good idea here.
>...

This actually looks like a bug in upstream configure.ac to me:
VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])

It is correct that this adds -maltivec to AltiVec-specific code,
and vlc has proper autodetection to run this only when AltiVec
is actually present.

The VLC_ADD_CFLAGS here look just wrong - it is not the job of 
configure.ac to add such flags to generic code (whatever march
and hardware features are present is defined through compiler
defaults and the CFLAGS passed by the user).

> Thanks,
> James

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Supported Hardware ?

[Adrian Bunk]

On Tue, Oct 25, 2016 at 08:08:29PM +0200, Erik Brangs wrote:
> Hi,

Hi Erik,

> Thanks for the hints, but those machines use 64-bit processors or 32-bit 
> processors with SPE. I would need a 32-bit PPC with FPU, preferably with 
> multiple cores. The projects that I'm interested in are related to code 
> generation so the hardware details are important to me.
>...

what hardware details are actually important for you?

The differences between CPUs from Freescale and CPUs from IBM are
*much* bigger than the question whether the hardware supports 64bit
or not.

And even among CPUs from the same vendor, the difference between
in-order and out-of-order execution should be more important
for you.

> Kind regards,
> 
> Erik Brangs

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Supported Hardware ?

[Adrian Bunk]

On Tue, Oct 25, 2016 at 04:50:43PM -0400, Lennart Sorensen wrote:
> On Tue, Oct 25, 2016 at 08:32:23PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > 64bit PPCs should be compatible with 32bit user space with most operating
> > systems. So unless you specifically target kernel space and MMU code, you
> > shouldn't notice much difference.
> > 
> > But yeah, it's a problem. Not many multicore 32bit PPCs exist in the first
> > place, and even less has readily available boards with them on the market,
> 
> I am trying to think of a multicore 32 bit powerpc.  Hmm.
>...

Freescale/NXP e500mc based SoCs like P2041 or P4080.

Several of the development platforms are still available.

> Len Sorensen

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: ppc64el porter situation

[Adrian Bunk]

On Fri, Oct 21, 2016 at 01:30:13PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 11:18:39PM +0300, Adrian Bunk wrote:
> > Freescala/NXP is not even on the OpenPOWER member list - this is not the 
> > old power.org
> 
> Neither is AMCC as far as I can tell.  Doesn't mean they aren't still
> doing powerpc.

Are they developing new powerpc products?

Their latest products are also pretty ARM.

> > For their network processors Freescala/NXP is moving away from PowerPC, 
> > and their first ARM based network processors are already on the market.
> 
> That's not what they are telling their customers.  They insist they are
> very much behind both arm and powerpc.

Are you talking about new e6500 SoCs, or are you only talking about 
support for existing products?

I have no doubt they will continue to provide support for e6500 for 
several years, just like they supported SoCs with SPE cpus in their
SDK until December 2015.

They released only two e6500 based SoCs for QorIQ (T2080 and T4240),[1]
and for one of them samples of ARM replacements are already available.

These are anyway big endian, but the general situation is that there
is not much powerpc development left that does not depend on IBM.

> Len Sorensen

cu
Adrian

[1] with T2081/T4160/T4080 variants, plus two in the Qonverge platform

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: ppc64el porter situation

[Adrian Bunk]

On Thu, Oct 20, 2016 at 03:58:21PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 03:54:43PM -0400, Lennart Sorensen wrote:
> > I think Freescala/NXP might disagree.  Not sure if the e6500 core could
> > ruin ppc64el or not, but they certainly make a lot of powerpc chips.
> 
> That should have said 'run' not 'ruin'.  That would have been rather
> interesting otherwise.

Freescala/NXP is not even on the OpenPOWER member list - this is not the 
old power.org

For their network processors Freescala/NXP is moving away from PowerPC, 
and their first ARM based network processors are already on the market.

> Len Sorensen

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: ppc64el porter situation

[Adrian Bunk]

On Wed, Oct 19, 2016 at 12:06:59PM +0200, Aurelien Jarno wrote:
> Hi,

Hi Aurelien,

>...
> To me it looks like they are really skilled for that job. Do you have
> actual facts showing the contrary?

Niels said that I shouldn't hesitate to let the release team know when
I believe there is an issue they have overlooked.[1]

I do believe that there is a risk in the ppc64el port in the unlikely 
case that IBM suddenly moves away from PowerPC, and that is currently 
not mentioned in the architecture requalification table.

This is not about past work done by the ppc64el porters, this is about
a specific single point of failure that could happen in the future.

In my opinion this is a risk, and the release team should be aware
of it when making the decision regarding architectures in stretch.

I do appreciate the answers from Breno and you that addressed some
of the things I brought up.

I do expect the release team to read this discussion and take it
into consideration.

I am not involved in the decision regarding ports in stretch,
and any decision is fine with me.

> Aurelien

cu
Adrian

[1] https://lists.debian.org/debian-release/2016/10/msg00131.html

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: ppc64el porter situation

[Adrian Bunk]

On Wed, Oct 19, 2016 at 09:06:14AM -0200, Breno Leitao wrote:
> Hello Adrian,

Hi Breno,

> Let me share my view as the only DD listed as ppc64el porter.

thanks for your reply.

Just to state it explicitely in case that was not clear, I do not have 
any problem with you personally or the ppc64el port in general.

I am just saying that I see a risk for the ppc64el port in the
unlikely case that IBM makes a sudden move away from PowerPC
during the lifetime of stretch.

> On Mon, Oct 17, 2016 at 10:50:01PM +0300, Adrian Bunk wrote:
> > Is a DM enough, if the only DD gets killed by a car [2] the day after
> > the release of stretch?
> 
> The other DM is in the process of becoming a DD[1]. This might reduce
> the truck factor by half.
> 
> [1] https://nm.debian.org/person/frediz

That's good news.

> > Second, all 4 committed porters seem to be employees of IBM.
> >
> > What happens if for whatever good or bad reason IBM decides in 2018
> > or 2019 to go away from ppc64el, and all 4 committed porters get fired?
> 
> I understand your point here. ppc64el architecture is IBM's current and
> future focus. ppc64el is also planned for POWER9 and beyond. While it's
> hard to predict what future business decisions IBM may make, we believe
> the future of ppc64el and OpenPower systems looks good.
> 
> There are many other distros that support ppc64el at this moment, as
> Ubuntu, Fedora, SLES, RHEL and others coming. So, your point is not
> Debian specific, but, generic to the Linux ecossystem.

Debian is in a different situation, the porters of these distributions 
are likely employed by the company behind the distribution and not
by IBM.

> > The wording of the porter commitment is already limited to "I intend
> > to", and there is the single point of failure that one business
> > decision by IBM might reduce the number of porters immediately from 4
> > to 0.
> 
> Right, since ppc64el machines are not desktop/personal machines, it is
> harder to get porters, compared to more pervasive architectures, as amd64.
> I hope to have more DD porters in the future, as ppc64el become more
> prevalent.
> 
> lso, there are many other hardware manufactors and partners that relies
> on Linux for the Power platform[1]. In my opinion, the Power platform is
> bigger than IBM at this moment.
> 
> [1] http://openpowerfoundation.org/membership/current-members/

https://en.wikipedia.org/wiki/MeeGo#Companies_supporting_the_project

That's also an impressive list of companies, isn't it?
When the one company that mattered switched to a different platform,
the whole platform collapsed immediately.

The whole Power platform also seems to be mostly around IBM.

>...
> On the other side, if there is a requirements for being a porter that
> says that the porter might be able to fix difficult issues on kernel and
> toolchain, then it is a different story. I do not believe that this
> requirement exists.
>

It is not a requirement for every porter, but that skill is required.

Debian got burned in wheezy in the sparc port when no porter was 
available to fix a broken kernel after the release.

That was an embarrassment to the Debian stability and quality that noone 
wants to ever see again.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

ppc64el porter situation

[Adrian Bunk]

Disclaimer:
I am not a member of the release team, and I am only speaking for myself.


The architecture requalification status for stretch [1] lists the 
ppc64el porter situation as green, but there are three reasons why
the situation doesn't look that good to me.


First, official status of the porters:
- 1 DD
- 1 DM
- 2 no DD/DM

Is a DM enough, if the only DD gets killed by a car [2] the day after 
the release of stretch?


Second, all 4 committed porters seem to be employees of IBM.

What happens if for whatever good or bad reason IBM decides in 2018
or 2019 to go away from ppc64el, and all 4 committed porters get fired?

The wording of the porter commitment is already limited to "I intend to",
and there is the single point of failure that one business decision
by IBM might reduce the number of porters immediately from 4 to 0.


Third, the skills of the committed porters for post-release work.

It is extremely valuable when people are doing manual and automated 
testing and fix the usual porting issues prior to the release.

But the most important skills required post-release until end-2020 are 
quite different.

How many of the committed ppc64el porters are personally able to fix
difficult issues that require intimate knowledge of hardware, kernel
and toolchain?

Lack of redundancy in these skills was the problem of the sparc port
in wheezy when the only skilled porter left.


The s390x port is yellow in the porters row due to having only two 
porters committed.

Just looking at the numbers 4 sounds twice as good as 2, but for the 
reasons explained above I think the ppc64el porter situation is actually
worse than on s390x, and should be marked as yellow or red.


cu
Adrian

[1] https://release.debian.org/stretch/arch_qualify.html
[2] I do not wish bad to anyone, but from the Debian point of view
this is why reduncancy is required.

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> > 
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier <ni...@thykier.net> schrieb:
> > > > If I am to support powerpc as a realease architecture for Stretch, I
> > > > need to know that there are *active* porters behind it committed to
> > > > keeping it in the working.  People who would definitely catch such
> > > > issues long before the release.  People who file bugs / submit patches 
> > > > etc.
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > > a powerpc-specific build failure of mariadb in stable. The maintainer
> > > said he can't work on it, so if anyone considers himself/herself a
> > > powerpc porter, this is something to look it.
> > 
> > Can you give a hint what exactly should be looked at?
> 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159
> 
> > The bug did not make it clear that there is any problem left at all when 
> > I looked at it recently.
> > 
> > The last message was closing the bug.
> > 
> > There was a control command reopening the bug without giving any 
> > rationale, but the last control command was
> >   fixed 832931 10.0.27-1
> 
> For unstable, yes. The stable package is still broken.

Thanks.

When skimming through that the bug I thought it was fixed in 
upstream 10.0.27, and no comment in the bug indicated otherwise.

As (pretty passive) reader of debian-powerpc, I am also puzzled by the 
fact that I cannot recall #832931 ever being mentioned there.

An email to the bug and the mailing list of the port stating that there 
is a problem, and what is known about it, can be really helpful for 
getting such a bug resolved.


> > buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]
> 
> That's an artefact of how builds for suites with "overlays" (i.e. pu /
> tpu) are displayed. If one actually looks at the archive:
> 
> mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
> mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
> armhf, i386, mips, mipsel, ppc64el, s390x

Ouch.

I thought the information in the version tracking was wrong
when buildd.d.o showed green.


> Regards,
> 
> Adam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

[ adding debian-powerpc ]

On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier  schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working.  People who would definitely catch such
> > issues long before the release.  People who file bugs / submit patches etc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> a powerpc-specific build failure of mariadb in stable. The maintainer
> said he can't work on it, so if anyone considers himself/herself a
> powerpc porter, this is something to look it.

Can you give a hint what exactly should be looked at?

The bug did not make it clear that there is any problem left at all when 
I looked at it recently.

The last message was closing the bug.

There was a control command reopening the bug without giving any 
rationale, but the last control command was
  fixed 832931 10.0.27-1

buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

If there is a problem left somewhere it is well-hidden, and not visible 
immediately when looking at the bug - I thought this was already resolved.

> Cheers,
> Moritz

cu
Adrian

[1] https://buildd.debian.org/status/package.php?p=mariadb-10.0=jessie

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Architecture qualification meeting, scheduling

[Adrian Bunk]

[ fullquote adding -ports, for people not following -release or -devel ]

On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
> input from porters.
> 
> As the schedule is currently wide open, please express your availability in
> the linked Doodle poll. There are 56 slots available, mostly in the European
> evening but a handful are daytime coinciding with the Cambridge
> mini-Debconf.
> 
> Porters, please note your architecture in your response ("name (arch)").
> 
> About the format of the meeting:
> Much like the Jessie meeting, it will be held via IRC in
> oftc.net/#debian-release and will be primarily a discussion amongst the
> release team. We will evaluate each port on the most up-to-date information
> available to us, and determine if it will be a release architecture for
> Stretch. We may ask for clarification from porters who are present if there
> are points at issue, but we ask that you are read-only otherwise.
> 
> http://doodle.com/poll/362qvb89cvu43d4z

Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
information available to you, and the "candidate" line how a decision
would look like based on the current information?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#739232: O: spu-tools -- user space tools for the Cell broadband engine

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of spu-tools, Arthur Loiret arthur.loi...@gmail.com,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

More information about this package:
http://packages.qa.debian.org/spu-tools



Source: spu-tools
Section: misc
Priority: extra
Maintainer: Arthur Loiret aloi...@debian.org
Uploaders: Aurélien GÉRÔME a...@roxor.cx
Build-Depends: debhelper (= 6), quilt (= 0.40), libncurses5-dev, 
help2man
Standards-Version: 3.8.4

Package: spu-tools
Architecture: powerpc ppc64
Provides: spu-top, spu-ps
Description: user space tools for the Cell broadband engine
 The spu-tools package contains user space tools for Cell/B.E.
 Currently, it contain two tools:
 .
  - spu-top: a top-like tool to watch the SPU's on a Cell BE
System. It shows information about SPUs and running SPU contexts.
  - spu-ps: a ps-like tool, which dumps a report on the currently
running SPU contexts.


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140216203828.ga...@bunk.dyndns.info

Re: Bug#116780: util-linux: hwclock shouldn't be run

[Adrian Bunk]

On Sun, 28 Oct 2001, Tom Rini wrote:

 On Sun, Oct 28, 2001 at 08:16:50PM +0100, Adrian Bunk wrote:
  All right. Is the special casing of the PReP machines obsolete, too or
  should I keep it?

 Obsolete.

Thanks for this clarification, I'll remove the special handling for
PReP machines in the next upload of util-linux.

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400