GNOME partly working
Michael Banck
I finally managed to get GNOME 2.8 starting up mostly fine today. It
took quite some time to get all the packages built (I did that mostly
some months ago) and figure out the issues, the latter was mostly done
by Neal.
A screenshot is here:
http://people.debian.org/~mbanck/media/hurd-gnome.png
The packages are at
deb http://people.debian.org/~mbanck/hurd-gnome/ ./
The caveats:
1. gamin doesn not work (and FAM is not ported), so there is no
automatic file update for gnome-vfs. Volunteers are needed to figure
out why gamin does not work (when I built gnome-vfs against it, it made
the whole box freeze). There were some test suite failures, so this
would probably the best way to start.
2. orbit2<->gconf2 is flakey. Neal Walfield's pflocal patch (along with
a smaller patch he sent to libc-alpha today) should make orbit work fine
(the test suite passes now), but we have not tested this yet in action.
As an work-around, one can force orbit to use TCP/IP by putting
'ORBIIOPIPv4=1' into ~/.orbitrc. Thanks to Barry for figuring that out.
3. There is a pretty severe issue with pthread_attr_setstacksize()
from libgthread resulting in nautilus to abort. I hacked around that
in glib for now, Neal might be able to look into that later on.
4. A lot of GNOME packages seem to link with --as-needed these days, so
you might have to export LD_PRELOAD=/lib/libpthread.so.0.3 until
Roland's glibc patch is committed/in the Debian package.
5. Several minor issues like PATH_MAX stuff; and Build-Depends on things
we don't have (sound libraries, gstreamer, etc.). For the latter, we'll
have to figure these out together with the Debian GNOME team. For the
former, we should file bugs upstream.
6. Most applications are not yet built, not even all the ones from
gnome-core. 'apt-get install gnome-applets gnome-control-center
gnome-icon-theme gnome-panel gnome-session metacity nautilus
scrollkeeper' (along with the above APT source) should get you started.
7. I probably forgot something.
In summary, I hope we will be able to get a fully working GNOME
system[1] (not only for Debian, but for anybody building the upstream
sources) by the time 2.12 releases. Maybe we can get some of the bigger
issues patched in the 2.10.x releases. In any case, we should be able
to get GNOME working in Debian once sarge is released and 2.10 moves to
unstable.
enjoy,
Michael
--
[1] Of course, these days GNOME is using advanced kernel features like
D-Bus, HAL etc. and also Gstreamer, so we are lacking behind
feature-wise. Maybe we can get as far as Solaris mid-term at least.
--
To UNSUBSCRIBE, email to debian-hu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Neal H. Walfield
Michael Banck wrote:
> 3. There is a pretty severe issue with pthread_attr_setstacksize()
> from libgthread resulting in nautilus to abort. I hacked around that
> in glib for now, Neal might be able to look into that later on.
Our current libpthread doesn't support floating stacks. To get at the
thread specific data (TSD), we look at the base of the stack. To find
the base of the stack, we take the current stack point and bitwise and
it with ~(2MB - 1). This mode of operation makes supporting user
stacks very difficult as we have no mechanism to express these
constraints to the user.
Currently, pthread_attr_setstacksize is essentially a stub (if the
caller specifies 2MB it succeeds all other values return EINVAL).
glib thinks that since it is present (it checks for it using autoconf,
apparently), it must work. Arguably, we are not not POSIX compliant:
The pthread_attr_setstacksize() function shall fail if:
[EINVAL]
The value of stacksize is less than {PTHREAD_STACK_MIN} or
exceeds a system-imposed limit.
Thus for our implementation PTHREAD_STACK_MIN would be 2MB and the
system imposed limit would be 2MB. (As a side note that we don't
currently define PTHREAD_STACK_MIN as it is supposed to be defined by
<limits.h> and that is provided by glibc and not something we can
easily change. We could just define it in <pthread.h>, however, we
still have the problem that the respective sysconf parameter is
undefined. Since user stacks are not really supported anyway, there
is no real use in providing this.)
Since glib just ignores the stack size parameter if
pthread_attr_setstacksize is not found, it should just ignore any
failure.
I spooke with Michael about this issue offline and he is filing a bug
upstream.
Thanks,
Neal