Tried to rebuild the 0.9.2 release with the 0.9.1 RPM spec file.
First problem: texi2pdf not found. There’s no such binary in FC4 at
this time. Eventually I think it’s going to be in the texinfo
package, but check Bugzilla since there
are a couple bugs open on it as I recall. Anyway, it turns out
texi2pdf is just texi2dvi --pdf, so just make a script to exec
texi2dvi --pdf "$@", name it texi2pdf, put it in your path, and no
more problems there.
Second problem: it keeps locking up on tests. I gave up at this point. Goes to 100%. I couldn’t even tell what test it was in. So I gave up, used the SBCL 0.9.1 RPM.
Then SBCL randomly started crashing with errors like:
internal error #29
SC: 14, Offset: 4 lispobj 0x51082ff
fatal error encountered in SBCL pid 12264:
internal error too early in init, can't recover
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd drop
into the LDB low-level debugger now. But there's no LDB in this build, so
we can't really do anything but just exit, sorry.
Turns out this is a result of kernel.randomize_va_space = 1 (that’s
/proc/sys/net/kernel/randomize_va_space) which is the default in (at
least) FC4’s kernel(s). You only get this error about 2/3 of the
time; the rest of the time SBCL seems to work. The solution is to run
SBCL like setarch i686 -R sbcl. I made a script in my path to do
this when SBCL is built. Side note: I ran setarch i686 -R rpmbuild
-ba sbcl.spec, but that didn’t make the build succeed. I didn’t try
switching off the flag system-wide.
I tried to connect to the Internet with my phone during class, since
there’s no wireless in the new building. Unfortunately I couldn’t get
it to connect in class. I already had Bluetooth configured to
connect to my v710 for
DUN, but I’ve
since had my phone flashed so it was no longer paired to my PC. When
I did something like cat I’d first have my phone
inform me of the pairing attempt and ask me for a PIN, then see things
like hcid[4851]: pin_code_request in /var/log/messages. I
couldn’t figure out how to tell the Bluetooth stack what PIN to use.
gnome-bluetooth-manager was utterly useless: scan detected my phone,
but it made like it was already detected. (Presumably some database
somewhere indeed indicated the phone was already paired, but I needed
a ‘re-pair’ option or something.)
Poking around revealed /etc/bluetooth/hcid.conf. There are two
relevant parameters, pin_helper and dbus_pin_helper. In the
default FC4 hcid.conf, pin_helper is commented out and
dbus_pin_helper is set. At some point, I also noticed hcid would
disappear after it spit out its pin_code_request. So I slapped
strace on it, and behold (edited for brevity, wrapped for readability):
send(3, "<30>Jul 7 11:32:32 hcid[4851]: pin_code_request
(sba=XX:XX:XX:XX:XX:XX, dba=XX:XX:XX:XX:XX:XX)", 95, MSG_NOSIGNAL) =
95
write(2, "4851: arguments to dbus_type_is_basic() were incorrect,
assertion "_dbus_type_is_valid (typecode) || typecode ==
DBUS_TYPE_INVALID" failed in file dbus-signature.c line 259.nThis is
normally a bug in some application using the D-BUS library.n", 242) =
242
write(2, "type unknown isn't supported yet in
dbus_message_append_args_valistn", 68) = 68
read(5,
"l311G