RE: Feedback on building and executing si for ppc32

> 1. Building the si went okay after I manually downloaded the
> texinfo-4.3.tar.bz2 file. The entity checker produced a zero 
> length file
> because the gnu web site has now moved up to texinfo-4.5. I think the
> entity checker needs to be corrected to avoid creating empty 
> files when the
> upstream source isn't there. I didn't know it was empty until 
> several hours
> later when the build failed.

Ummm, it's supposed to.  It's got code that removes the
file if the transfer failed.  I'm not sure why that didn't
trigger (I've confirmed it before), but now I've got a
test case so I'll take a look.  Maybe there are more classes
of failure and it didn't catch this one.

> 2. Once the si was built and installed, I was unable to run lsblibchk
> within it because there was no /lib/ld.so.1 in the si. I 
> worked around this
> limitation by making a link from ld-2.2.5.so to ld.so.1.

Right.  Known issue, it's in the SF bug page.  We need to
build a lsblibchk package especially for the si.

> 3. Running lsblibchk against the si produced one failure when checking
> libncurses. The message was:
> 
> compareElfhdr: e_flags isn't expected value 0, found 8000 instead

This is a new one one on me, but I didn't perform this
test on ppc.

> 4. When I looking through the instructions for doing the 
> runtime tests it
> says perl is needed. The si does not have perl. Does the test 
> suite still
> need it, or is this just a case of outdated docs?

It's not needed to run, I think it's needed to build them
from source, though. The quick analysis script is a perl
script (tjreport) but that can easliy be run from outside
the lsbsi.

> 5. When I tried executing the runtime tests they failed right 
> away. The
> failure happened when it was trying to install the i18n locales. The
> message was "su: must be run from a terminal". Since I am 
> using chroot I
> guess this messes things up. Hopefully, this is a known 
> situation and there
> is a workaround to get things to proceed.


I haven't seen that message, but yes, there's a way to
work around this.

Make sure you've built lsbsi-test. ("make stage4").
This stuff is then dropped in the lsbsi test directory
(you can unpack the tarball or cpio over the build
lsbsi-test tree).

From the chroot, these steps should set you up
(they're somewhere on the si web pages):

# mount /proc
# inetd
# syslogd -m 0

(it's good if you've stopped the native system's
syslogd first)

The inetd serves up a telnet server, so from some
other terminal/window you can now

$ telnet localhost

log in as vsx0, and you'll look like you're on
a terminal so the complaint will go away.

You may have to disable the local host's telnetd
if one is running (SuSE doesn't turn on /anything/
by default so it probably won't be the case).

Mats