On 2019-07-26 16:59, John Paul Adrian Glaubitz wrote:
Hello Drew!
On 7/26/19 3:03 AM, Drew Parsons wrote:
hypre occasionally times out during tests, causing FTBFS. Typically it
will
pass if tried again. Please give back hypre 2.16.0-2 to attempt builds
again
on hurd-i386 m68k sh4.
Your
hypre occasionally times out during tests, causing FTBFS. Typically it
will pass if tried again. Please give back hypre 2.16.0-2 to attempt
builds again on hurd-i386 m68k sh4.
gb hypre_2.16.0-2 . hurd-i386 m68k sh4
Thanks,
Drew
On Wed, 2017-08-09 at 08:07 -0400, John Paul Adrian Glaubitz wrote:
> On 08/09/2017 01:17 AM, Drew Parsons wrote:
> > > I can run the testsuite manually if you like.
> >
> > That would be handy, especially to know if the tests have in fact
> > been
> > built.
On Wed, 2017-08-09 at 08:07 -0400, John Paul Adrian Glaubitz wrote:
> On 08/09/2017 01:17 AM, Drew Parsons wrote:
> > > I can run the testsuite manually if you like.
> >
> > That would be handy, especially to know if the tests have in fact
> > been
> > built.
On Tue, 2017-08-08 at 23:49 -0400, John Paul Adrian Glaubitz wrote:
> On 08/08/2017 02:30 AM, Drew Parsons wrote:
> > scalapack 2.0.2 is in experimental. It appears to build well
> > enough on
> > m68k [1], but something is going wrong with the test executables.
> &
scalapack 2.0.2 is in experimental. It appears to build well enough on
m68k [1], but something is going wrong with the test executables.
dh_auto_test isn't running any tests (the executables are in build-
openmpi/TESTING, and elsewhere in .../BLACS, .../PBLAS, build-mpich).
dh_install reports:
mpich has been consistently failing to build on sh4.
The error occurs when linking the static library with the message:
/usr/bin/ld: MPIUI_Thread: TLS definition in
lib/.libs/libmpich.a(lib_libmpich_la-mpiu_thread.o) section .tbss mismatches
non-TLS reference in lib/.libs/libmpich.a(lib_libmpich
On Tue, 2006-09-26 at 07:14 -0500, Stephen R Marenka wrote:
> On Mon, Sep 25, 2006 at 11:38:55AM +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 24 Sep 2006, Drew Parsons wrote:
> >
> > > The build fails [1] on what appears to be a toolchain bug, outsi
On Mon, 2006-09-25 at 11:38 +0200, Roman Zippel wrote:
> Hi,
>
> On Sun, 24 Sep 2006, Drew Parsons wrote:
>
> > The build fails [1] on what appears to be a toolchain bug, outside of
> > xserver-xorg-input-evdev. Namely, we get:
> >
> > gcc -DHAVE_CONFIG_H
I've applied Geert's inotify codes to xserver-xorg-input-evdev, that
seems to be fine as far as it goes.
The build fails [1] on what appears to be a toolchain bug, outside of
xserver-xorg-input-evdev. Namely, we get:
gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall -Wall -g -O2
-DXFree86Server -DI
On Sun, 2006-09-24 at 14:18 +1000, Drew Parsons wrote:
> I've applied Geert's inotify codes to xserver-xorg-input-evdev, that
> seems to be fine as far as it goes.
>
> The build fails [1] on what appears to be a toolchain bug, outside of
> xserver-xorg-input-evdev.
Geert wrote:
> Both my 2.95.2 and 3.2 cross compilers define __mc68000__, but not __m68k__.
OK I'll patch with __mc68000__ then.
Drew
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, 2006-09-18 at 16:49 +0200, Frans Pop wrote:
> On Monday 18 September 2006 14:48, Drew Parsons wrote:
> > Could you tell me what the m68k flag is defined as, in the #if
> > defined( ) sense as in
>
> Surprise, surprise. It is (taken from kbd-chooser in d-i):
> #if
On Mon, 2006-09-18 at 10:35 +0200, Geert Uytterhoeven wrote:
> According to
> http://linux-m68k-cvs.ubb.ca/c/cvsweb/linux/include/asm-m68k/unistd.h:
>
> | #define __NR_inotify_init 284
> | #define __NR_inotify_add_watch 285
> | #define __NR_inotify_rm_watch 286
>
Could you tell me
On Mon, 2006-09-18 at 10:35 +0200, Geert Uytterhoeven wrote:
> On Mon, 18 Sep 2006, Drew Parsons wrote:
> > xserver-xorg-input-evdev 1.1.2 currently fails to build on m68k (cf.
> > http://buildd.debian.org/fetch.php?&pkg=xserver-xorg-input-evdev&ver=1%
> > 3A1.1.2-1&am
xserver-xorg-input-evdev 1.1.2 currently fails to build on m68k (cf.
http://buildd.debian.org/fetch.php?&pkg=xserver-xorg-input-evdev&ver=1%
3A1.1.2-1&arch=m68k&stamp=1151064364&file=log&as=raw)
This is because a new file inotify-syscalls.h has been added which
defines syscalls for each specific a
Is there a problem with the clock on the m68k buildd?
I uploaded gworldclock 1.4.2 yesterday, and the m68k buildd reports:
make[3]: Warning: File `rendezvous.c' has modification time 1.6e+04 s in
the future
...
make[3]: warning: Clock skew detected. Your build may be incomplete.
No other arch
Dear m68k porters,
gworldclock has failed to build on m68k. The build log is at
http://buildd.debian.org/fetch.php?&pkg=gworldclock&ver=1.2-2&arch=m68k&stamp=1064829242&file=log&as=raw
The failure happens while handling I18N through some Japanese po files,
though no helpful error messages are gi
Dear m68k porters,
I've uploaded a new version of gworldclock (v1.1).
It fails to build on m68k, the build log is at
http://buildd.debian.org/build.php?&pkg=gworldclock&ver=1.1-1&arch=m68k&file=log
The build log says:
gcc -g -O2 -o gworldclock main.o misc.o resize.o sync.o timer.o zones.o
-
19 matches
Mail list logo
