How is sbcl boottrapped?
You are aware that sbcl on FC4 man startup correctly or not...?
It is guaranteed to startup only with setarch -R.

Here's the bootstrap options in the specfile (lightly tested):

## define to be one of the following
# use our own/local bootstrap?
%define bootstrap_sbcl_local 1
#define bootstrap_sbcl sbcl
#define bootstrap_clisp clisp

Wasn't aware of the startup issues on fc4 (had only lightly tested on fc3 and
rhel4 so far).

Spec Name or Url: http://apt.kde-redhat.org/apt/fedora/SPECS/sbcl-0.9.4-1.spec
SRPM Name or Url:
http://apt.kde-redhat.org/apt/fedora/all/SRPMS/stable/sbcl-0.9.4-1.src.rpm

I cannot download
http://apt.kde-redhat.org/apt/fedora/all/SRPMS/stable/sbcl-0.9.4-1.src.rpm
(object not found)

My bad for posting before I actually put the files in place.  Should be good now.

This should be SRPMS.stable, not SRPMS/stable.

SRPM Name or Url:
http://apt.kde-redhat.org/apt/fedora/all/SRPMS.stable/sbcl-0.9.4-1.src.rpm

* The spec file should be named sbcl.spec
* Shouldn't the src rpm contain bootstrapping binaries for all architectures?
  AFAIK src rpms are not architecture dependent.
* You may request a ppc binary from upstream, so that all fedora platforms
  are supported.
* Requires(post): /sbin/install-info
  Requires(preun): /sbin/install-info
* setarch -R is required on FC4 to start sbcl, you might create a script
  /usr/bin/sbcl that calls a renamed /usr/bin/sbcl.bin with setarch.
  Better yet, communicate with upstream to investigate the problem.
* Have you tried clisp to bootstrap sbcl? I did not succeed. If you do, the
  binaries are not necessary.

specfile names will certainly be fixed when imported to svn.

> setarch -R is required on FC4 to start sbcl,

I figured if it was *built* with that option, then the resulting binary would
inherit that behavior.  Turns out you're right.

> Shouldn't the src rpm contain bootstrapping binaries for all architectures?
> AFAIK src rpms are not architecture dependent.

Hmm, good point, probably.

> Have you tried clisp to bootstrap sbcl? I did not succeed. If you do, the
> binaries are not necessary.

Tried, it failed.

Where is %{?fedora} defined?

%{fedora} is defined by the Extras buildsystem.  It's set to 3 on Fedora Core 3,
4 on Fedora Core 4.

But %{fedora} is not defined in fc4's rpmbuild, i.e., the src rpm may not build
correctly for a user.

output of rpmlint:
W: sbcl devel-file-in-non-devel-package /usr/lib/sbcl/sb-bsd-sockets/alien/undefs.c
W: sbcl devel-file-in-non-devel-package /usr/lib/sbcl/sb-bsd-sockets/foo.c
W: sbcl devel-file-in-non-devel-package
/usr/lib/sbcl/sb-bsd-sockets/alien/get-h-errno.c
E: sbcl script-without-shellbang /usr/lib/sbcl/sb-bsd-sockets/alien/get-h-errno.c

Are these files necessary?
At least chmod 644 get-h-errno.c

E: sbcl info-dir-file /usr/share/info/dir

this must be removed

W: sbcl devel-file-in-non-devel-package /usr/lib/sbcl/sb-posix/alien/stat-macros.c
W: sbcl devel-file-in-non-devel-package
/usr/lib/sbcl/sb-posix/alien/waitpid-macros.c
W: sbcl devel-file-in-non-devel-package /usr/lib/sbcl/sb-posix/foo.c

Are these necessary?

> But %{fedora} is not defined in fc4's rpmbuild, i.e., the src rpm may not build
> correctly for a user.

True, and eventually the default case could to make it work for end-users, but
don't forget that the primary target here is the Fedora Extras buildsystem.

> W: sbcl devel-file-in-non-devel-package 
> /usr/lib/sbcl/sb-posix/alien/stat-macros.c
> Are these necessary?

Dunno, probably not, just packaging what upstream does.

%changelog
* Mon Aug 29 2005 Rex Dieter <rexdieter[AT]users.sf.net> 0.9.4-2
- rm -f /usr/share/info/dir
- fix perms on packaged .c files
- include all bootstrap binaries
- Requires(post,preun): /sbin/install-info
- sbcl.sh app-wrapper (when using setarch)

Spec Name or Url: http://apt.kde-redhat.org/apt/fedora/SPECS/sbcl-0.9.4-2.spec
SRPM Name or Url:
http://apt.kde-redhat.org/apt/fedora/all/SRPMS.stable/sbcl-0.9.4-2.src.rpm

0.9.4-2 builds fine in mock (fc-4).
There is a little error in the sbcl shell script:
Instead of:
SBCL_SETARCH=setarch i386 -R
it must be:
SBCL_SETARCH="setarch i386 -R"

There is a ppc binary for sbcl 0.8.15 on sbcl.sf.net.
Maybe this can be used to bootstrap 0.9.4 on ppc.
Unfortunately I have no means to try this out.

How did you build the src rpm in order to include all binaries?
There are still conditional for including sources.

> How did you build the src rpm in order to include all binaries?
> There are still conditional for including sources.

The conditional tells it which src to use, but all bootstraps are
unconditionally included:

# local Bootstrap binaries
Source10:
http://dl.sourceforge.net/sourceforge/sbcl/sbcl-%{version}-x86-linux-binary.tar.bz2
%ifarch %{ix86}
%define bootstrap_src -a 10
%endif
Source11:
http://dl.sourceforge.net/sourceforge/sbcl/sbcl-%{version}-x86-64-linux-binary.tar.bz2
%ifarch %{x86_64}
%define bootstrap_src -a 11
%endif

* Tue Aug 30 2005 Rex Dieter <rexdieter[AT]users.sf.net> 0.9.4-3
- patch to avoid need to use setarch/app-wrapper
- fix app-wrapper (quote SBCL_SETARCH)
- include ppc bootstrap (oldish 0.8.15, untested)

Spec Name or Url: http://apt.kde-redhat.org/apt/fedora/SPECS/sbcl-0.9.4-3.spec
SRPM Name or Url:
http://apt.kde-redhat.org/apt/fedora/all/SRPMS.stable/sbcl-0.9.4-3.src.rpm

I'm fairly certain the old ppc binary won't work to bootstrap.  I'll request
upstream to provide an updated ppc binary.

The build of sbcl-0.9.4-3.src.rpm fails, because of %check.
run-tests.sh needs to be run within setarch.
The patch you added essentially does the same thing as
a wrapper script, but relies on /proc being present. However
this doesn't seem to when building with mock.

%changelog
* Tue Aug 30 2005 Rex Dieter <rexdieter[AT]users.sf.net> 0.9.4-4
- safer NO_ADDR_RANDOMIZE patch
- use %%{?setarch} in %%check too
               
Spec Name or Url: http://apt.kde-redhat.org/apt/fedora/SPECS/sbcl-0.9.4-4.spec
SRPM Name or Url:
http://apt.kde-redhat.org/apt/fedora/all/SRPMS.stable/sbcl-0.9.4-4.src.rpm

> Source10:
http://dl.sourceforge.net/sourceforge/sbcl/sbcl-%{version}-x86-linux-binary.tar.bz2
> Source11:
http://dl.sourceforge.net/sourceforge/sbcl/sbcl-%{version}-x86-64-linux-binary.tar.bz2

Upstream doesn't necessarily make binaries for all architectures for
all releases. I suspect it would be better to hardcode a specific
version here. The intent is that building SBCL always requires only a
reasonably compliant Common Lisp implementation, so there's no need to use the
latest release as the host compiler.

> ## Is sb-thread really limited to these archs only?  Don't think so, removing
limitation, for now. --Rex 
> #ifarch %{ix86} %{x86_64}
> sed -i -e "s|; :sb-thread|:sb-thread|" base-target-features.lisp-expr
> #endif

It's limited to just x86 and x86-64.

>Upstream doesn't necessarily make binaries for all architectures for
>all releases. I suspect it would be better to hardcode a specific
>version here.

Plan is to eventually use native (Fedora Extras) bootstraps, and drop those bits
altogether.

(In reply to comment #24)
> Plan is to eventually use native (Fedora Extras) bootstraps, and drop those bits
> altogether.
This might work for updated packages on a given platform, but for every new
platform (fc5, fc6, ...), bootstrapping is needed again.

I think you can import the package. You can use the build system to try to build
a ppc version. If this does work without much problems, you can include it,
otherwise create a bug report about this and assign it to yourself.

Imported into cvs, but now the build(s) are failing.  On FC4(and
rawhide/FC5)/i386, the build hangs late in the build process:
...
//testing for consistency of first and second GENESIS passes
//header files match between first and second GENESIS -- good

real    28m7.484s
user    26m47.750s
sys     0m35.730s
//entering make-target-2.sh
//doing warm init
... hang ...

  I had successfully built sbcl not too long ago, so I'm guessing some recent
update (kernel or glibc?) changed things. ??

The build (seems to) succeed on x86_64, but it fails some 'make check' tests:
http://buildsys.fedoraproject.org/logs//development/994-sbcl-0.9.4-9.fc5/

Arg.

I have observed your heroic efforts fighting the build system :-)
I checked out the cvs and made "make i386" and "make mockbuild".
The first builds without errors and results in an rpm.
The second builds in a mock chroot environment and fails.
I get a long list of errors ("Help! 11 nested errors.
SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.")
I don't know what goes wrong. However in the mock environment
there may be stronger ulimits or other conditions that do not
apply in a normal environment.
The gcc and glibc versions used are the same for both environment,
so this can't be the problem.
Maybe you ask for help on fedora-extras list.

I've gotten it to build reliably for me on FC4, at least.  (-:

Gérard, the latest ADDR_NO_RANDOMIZE patch sbcl is building with atm is using
argv[0] instead of relying upon /proc/self/exe.  Do you see anything
wrong/dangerous in this approach?

Woo hoo!  Time to go dance a jig.
-------------
 1047 (sbcl): Build on target development succeeded.
     Build logs may be found at
http://buildsys.fedoraproject.org/logs//development/1047-sbcl-0.9.4-13.fc5/
-------------

Should we close the bug now?  (I'll get FC-3/FC-4 targets built as soon as the
branches get made in cvs) 

(In reply to comment #29)
> Gérard, the latest ADDR_NO_RANDOMIZE patch sbcl is building with atm is using
> argv[0] instead of relying upon /proc/self/exe.  Do you see anything
> wrong/dangerous in this approach?
GCL uses the same approach, so it's probably ok. I hope that memory management
for these LISP compilers while sometime adapted to work without this hack,
but I am sceptical.
Try to build maxima with GCL and SBCL. If the hack doesn't cause any problems
it seems good enough.

Yep, maxima (5.9.1.9) builds with all lisps: clisp, gcl, sbcl, cmucl. 

What was the problem that caused the build to fail?

To what failed build are you referring? 
AFAIK, sbcl built fine (on fc5/devel), and I've been able to build the (newer)
maxima with sbcl on fc4.

I meant the one mentioned in comment #27.
BTW, what about fc3 and fc4?

Fixed FC4+ per comment #29, my local FC-3 builds are flaky (mostly not working),
but that's probably due to a lack of setarch -R there.

sbcl-0.9.4-15.fc4 build succeeded (omitting pcc).

The randomize patch of sbcl-0.9.4-15.fc4 doesn't seem to work in the
released build:
WARNING: Couldn't re-execute SBCL with the proper personality flags.  Trying to
continue anyway.

A previous build that I did myself in mock worked flawlessly.
I will reopen this bug now, maybe we create a new one to resolve this issue.

I wonder how sbcl passed the 'make check' (which is quite thorough) section of
the specfile if the build is bad. (??).

Somehow the patch is simply ineffectual and sbcl reverts to the previous
behaviour, i.e., sometimes it works, sometimes it doesn't. I think, it
was simply luck that made sbcl succeed the build :-(

For the record, my FC3 builds (comment #36) were flaky for the same reason you
described... it complained about being unable to set personality.  Perhaps using
argv[0] in the exec call *is* unreliable, and we should stick to trying to use
/proc/self/exe instead.  I'll see about whipping up a replacement patch to do
one of the following:
1.  Use /proc/self/exe, if it exists, else use argv[0]
2.  Try to use argv[0], and if the personality re-exec fails, fall back to
trying /proc/self/exe instead.

Yes, argv[0] *is* the problem:
It is set to "sbcl", however execve requires a full path, i.e., "/usr/bin/sbcl".
So either usr /proc/self/exe as before as you suggested, or create a script
that calls, e.g., /usr/lib/sbcl/bin/sbcl or something similar.
The argv[0] patch works with gcl, because gcl is a script that calls
/usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl, whose argv[0] is of course
a full path.

OK, should be all sorted out in sbcl-0.9.4-17

Package Change Request
======================
Package Name: sbcl
New Branches: el6
Owners: green
InitialCC: rdieter

(In reply to comment #44)
> Package Change Request
> ======================
> Package Name: sbcl
> New Branches: el6
> Owners: green
> InitialCC: rdieter

Oops. Ignore this.  Need coffee before I type.