Re: manipulating FPU rounding modes on alpha

2007-09-11 Thread Joachim Reichel
Hi,

>> this is exactly the same result that I get on Uwe's EV56 without and
>> with math_emu. I'm not in the position to discuss whether math_emu
>> should be a module or built in.
> 
> Using which kernel?

linux-image-2.6.21-2-alpha-generic 2.6.21-6

> Here is my /proc/cpuinfo in case you want to compare against the other
> EV56 that supposedly worked fine without math_emu:

This seems to be a misunderstanding. If the module is loaded, everything
is fine; if it is not loaded, I get the same errors as you. So the other
EV56 behaves exactly like your machine.

Joachim

P.S.: Please CC: me on replies.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: manipulating FPU rounding modes on alpha

2007-09-11 Thread Lennart Sorensen
On Tue, Sep 11, 2007 at 08:43:44AM +0200, Joachim Reichel wrote:
> This seems to be a misunderstanding. If the module is loaded, everything
> is fine; if it is not loaded, I get the same errors as you. So the other
> EV56 behaves exactly like your machine.

Well that makes sense then.  Well hopefully as soon as the kernel
packaging bug is fixed then the problem will go away.  In the mean time
EV6 and higher machines are OK, and any machine running an SMP kernel
is OK too (since they have math_emu built in).  The cgal package is fine
and is just unfortunately affected by a bug in the kernel package.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: manipulating FPU rounding modes on alpha

2007-09-11 Thread Joachim Reichel
Hi,

>> This seems to be a misunderstanding. If the module is loaded, everything
>> is fine; if it is not loaded, I get the same errors as you. So the other
>> EV56 behaves exactly like your machine.
> 
> Well that makes sense then.  Well hopefully as soon as the kernel
> packaging bug is fixed then the problem will go away.  In the mean time
> EV6 and higher machines are OK, and any machine running an SMP kernel
> is OK too (since they have math_emu built in).  The cgal package is fine
> and is just unfortunately affected by a bug in the kernel package.

Your analysis regarding EV6 and above is not correct. The package fails
on EV56 and below without math_emu for obvious reasons. According to
www.buildd.net, the buildd ds10 is an EV6. On this machine the package
fails with an error slightly different from EV56 without math_emu. The
reasons for the error on ds10 is still unknown, in particular, whether
it is caused by a bug in the package itself.

Regards,
  Joachim

P.S.: Please CC: me on replies.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Request assistance with monotone package on alpha, hppa, mipsel, powerpc, s390

2007-09-11 Thread Helge Kreutzmann
Hello Zack,
On Mon, Sep 03, 2007 at 06:59:28PM -0700, Zack Weinberg wrote:
> in unstable, we decided to run the program's testsuite during the
> build.  This found failures on many architectures - a mixed blessing,

Well, in the end this is positive, of course.

> This message is going out to all the porter lists for which the
> monotone package presently FTBFS because of testsuite failures.  I am
> not a DD (the package is being sponsored by Ludovic Brenta) so I do
> not have access to any of the Debian porting hosts, nor do I have
> other access to any of your architectures.

Sorry, I cannot grant to access to an alpha, but maybe someone on this
list can.

> I would therefore greatly appreciate assistance with these bugs.  If
> you have time to debug the thing yourself and send patches to
> [EMAIL PROTECTED], that is of course the most helpful thing
> you could do.  Failing that, the next most helpful possibility is if
> you are willing to grant me access (unprivileged only is fine) to a
> machine under your control, and install monotone's build-dependencies
> on that machine.  If you can't do that either, at the least we might
> have a chance of guessing what the problem is if you built the package
> to the point where it fails (using a method that does not destroy the
> build tree when the build fails), then tar up the tester_dir/
> directory and the "mtn" binary and send them to me.

First, I see several "cast from pointer to integer of different size",
I think these are the low hanging portability fixes to catch:
sqlite/func.c: In function 'trimFunc':
sqlite/func.c:891: warning: cast from pointer to integer of different size
sqlite/func.c: In function 'sqlite3RegisterBuiltinFunctions':
sqlite/func.c:1382: warning: cast to pointer from integer of different size
sqlite/func.c:1401: warning: cast to pointer from integer of different size

sqlite/table.c: In function 'sqlite3_get_table':
sqlite/table.c:148: warning: cast to pointer from integer of different size
sqlite/table.c: In function 'sqlite3_free_table':
sqlite/table.c:193: warning: cast from pointer to integer of different size

sqlite/vdbemem.c: In function 'sqlite3ValueText':
sqlite/vdbemem.c:857: warning: cast from pointer to integer of different size

sqlite/vtab.c: In function 'sqlite3VtabRollback':
sqlite/vtab.c:587: warning: cast from pointer to integer of different size
sqlite/vtab.c: In function 'sqlite3VtabCommit':
sqlite/vtab.c:596: warning: cast from pointer to integer of different size

For the tests:
echo '#!/bin/sh' > run_tester_tests ; \
echo 'PATH=.:$PATH' >> run_tester_tests ; \
echo 'exec ./tester ./tester-testsuite.lua "$@"' >> run_tester_tests ; 
\chmod 755 run_tester_tests
echo '#!/bin/sh' > run_lua_tests ; \
echo 'PATH=.:$PATH' >> run_lua_tests ; \
echo 'exec ./tester ./testsuite.lua "$@"' >> run_lua_tests ; \
chmod 755 run_lua_tests
Running unit tests...
basic_io:binary_transparency  ok
charset:idna_encoding ok
charset:utf8_validation   ok
commands:command_complete_command ok
commands:command_find_command ok
commands:complete_command ok
commands:make_command_id  ok
crypto:calculate_identok
cset:basic_csets  ok
cset:cset_written /bin/sh: line 4: 15213 
Segmentation fault  AUTOTEST_PATH="." ${dir}$tst
FAIL: unit_tests
Running tests...
  1 isolated-1ok
  2 isolated-2ok
  3 cleanup-1 ok
  4 cleanup-2 ok
  5 remove-unwriteableok

Of 5 tests run:
5 succeeded
0 failed
0 had expected failures
0 succeeded unexpectedly
0 were skipped
PASS: run_tester_tests
/bin/sh: line 4: 15224 Segmentation fault  AUTOTEST_PATH="." ${dir}$tst
FAIL: run_lua_tests
==
2 of 3 tests failed
Please report to [EMAIL PROTECTED]
==
make[4]: *** [check-TESTS] Error 1

If I run the tests manually, I get the following results (abbreviated, 
I cannot get the output captured (the ordinary > foo 2>&1 does not
work):

run_tester_tests:
Running tests...
  1 isolated-1ok
  2 isolated-2ok
  3 cleanup-1 ok
  4 cleanup-2 ok
  5 remove-unwriteableok

Of 5 tests run:
5 succeeded
0 failed
0 had expected failures
0 succeeded unexpectedly
0 were skipped

./tester ./tester-testsuite.lua
Running tests...
  1 isolated-1ok
  2 isolated-2