[Splashy-devel] problems to be fixed before release and status
summary
Luis M
lemsx1 at gmail.com
Mon Mar 27 18:36:14 UTC 2006
Hello all,
These are a list of known problems that need to be fixed before release (0.1.8):
* ensure that progressbar timing is correct (boot/shutdown). Shutdown
seems to be working fine for me (Jacobo?)
* ensure that nothing is holding splashy-init at boot. When splashy is
launched from initramfs it is -HUP'ed correctly by splashy-init (or so
it seems), we need to be sure that Splashy is not waiting for input
holding the boot process (perhaps something I introduced yesterday
with bootlogd code) (ALL)
* figure out a way to read console text. we were using a code to read
/dev/vcs1, but this has several draw backs (this device holds a buffer
of what's displayed on tty1. if the boot messages are being sent to
tty2, for instance, we won't see them -- this is the case in Ubuntu.
this buffer has no new lines, so, it needs to be parsed and
padded/formatted correctly for the size of the textbox area). I
believe that bootlogd does the right thing to detect which console it
should be reading from, but the code is buggy as it only works well
for vanilla Debian distributions (Sarge in particular) (ALL)
* remove all commands from splashy-init that are in /usr/bin! pgrep is
the first one that needs to be replaced. If pgrep is a small piece of
software, perhaps we can write a replacement in C and include it with
splashy: splashy_pgrep. (ALL)
* ensure that we are printing to the textbox area correctly. right now
we seem to be blit()'ing more than we should. I'll experiment more on
this subject, but if somebody has an idea of how to approach, be my
guest and submit a patch against our current svn code base.
Outside of that, everything else seems to be working perfectly well:
* splashy fades out when exiting from ESC or "exit" (via fifo)
* F2 toggles the text area
* text area scrolls messages in a fair way (there is no real scroll
bars, it simply wipes clean and writes from line 1)
* the autoverboseonerror works and the error image from the current
theme gets displayed along with the textarea showing the messages as
they scroll from the console (though it needs a bit of fixing to make
it work on other Linux/Unix)
* splashy works from initramfs
* a lot more small improvements that escape my mind at this moment but
can be read from the changelog.
Known bugs (that we might not be able to fix for this release)
* splashy is 936K compiled statically (as Pat said: this is because
libdirectfb itself is a beast). We might have to take a look into
directfb lite to fix this
* splashy perhaps only works with Linux-based systems only. we depend
on *_unlocked(), VT_*, openpty() and other GNU only functions (libc6
implementation from glibc). I tried to keep #define for __linux__ on
our source files. We will need to test how does this work on
Solaris/FreeBSD and other BSD's or mach-based systems (MacOS X,
Darwin, etc...)
* themes.xml files need a validator (W3C schema prefered). This should
be part of splashy_config. I might write a .xsd soon and use a Perl
script to validate the themes.xml files for all the themes we provide
in Splashy (splashy-themes debian package)
* splashy sources need to be splitted and only 1 theme included (the
default theme) in the source distribution. This will make packaging
splashy for Debian a bit harder, but hey, Splashy is NOT a debian-only
system. After all, RPM is the only lsb-compliant package system and we
do include a .spec file
* .rpm packages for Fedora Core 5/4 should be generated (and tested).
On fedora splashy conflicts with RedHat's own rhgb system. So we
should handle it the same way that Splashy conflicts with usplash on
Ubuntu. The RPM should provide userspace-bootsplash the same way it
does in Debian (not sure if this is possible).
* We need to pay especial attention to splashy_config and make sure it
generates themes correctly (without crashing) and then write a nice,
easy to use, GUI for it. Glade2 should be the best way to do this as
this will only be a front-end for it. Though I'm not against using
Perl/Python/Ruby front-ends for it either. For as long as it works and
no other dependencies are introduced to the package.
I believe that summarizes all what's going on with Splashy. We need as
much help as we can get, especially to help us identify pitfals on
disparate distributions (debian-based or not).
Keep the patches (and documentation/bug reports) coming!
--
----)(-----
Luis Mondesi
System Administrator
Kiskeyix.org
"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb
No .doc: http://www.gnu.org/philosophy/no-word-attachments.es.html
More information about the Splashy-devel
mailing list