2011-08. A dependency loop in Debian GNU/Hurd currently leads to: Could not perform immediate configuration on 'perl'. Easy workaround:
# apt-get install perl perl-base -o APT::Immediate-Configure=false
Resolve issues uncovered by Perl's test suite, and enable Hurd-specific features.
There is a FOSS Factory bounty (p264) on this task.
Bugs in perl
There is a bug in perl's putenv which makes it interact badly with fakeroot-tcp and fakeroot-sysv (not fakeroot-hurd), this shows up as this
*** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***
See http://rt.perl.org/rt3/Ticket/Display.html?id=91452 for details
A workaround is to do this before building packages calling perl inside fakeroot:
export FAKEROOTUID=0 FAKEROOTEUID=0 FAKEROOTSUID=0 FAKEROOTFUID=0 FAKEROOTGID=0 FAKEROOTEGID=0 FAKEROOTSGID=0 FAKEROOTFGID=0
Part I
First, make the language functional, have its test suite pass without errors.
Original GSoC Task Description
Perl and Python are available on the Hurd, but there are still test suite failures. These could be caused by problems in the system-specific implementation bits of Perl/Python, and/or shortcomings in the actual system functionality which Perl/Python depends on.
The student applying for this project can pick either Perl or Python, whichever he is more comfortable with. (Perl is higher priority though; and there are more failures too.)
The goal then is to fix all of the problems with the chosen language if possible, or at least some of them. Some issues might require digging quite deep into Hurd internals, while others are probably easy to fix.
Note that while some Perl/Python knowledge is probably necessary to understand what the test suite failures are about, the actual work necessary to fix these issues is mostly C programming -- in the implementation of Perl/Python and/or the Hurd.
Possible mentors: Samuel Thibault (youpi)
Exercise: Take a stab at one of the testsuite failures,
and write a minimal testcase exposing the underlying problem.
Actually fixing it would be a bonus of course --
but as it's hard to predict which issues will be easy and which will be tricky,
we will already be satisfied if the student makes a good effort.
(We hope to see some discussion of the problems in this case though 
)
IRC, OFTC, #debian-hurd, 2011-11-08
<Dom> pinotree: so, with your three fixes applied to 5.14.2, there are
still 9 tests failing. They don't seem to be regressions in perl, since
they also fail when I build 5.14.0 (even though the buildd managed it).
<Dom> What do you suggest as the way forward?
<Dom> (incidentally I'm trying on strauss's sid chroot to see how that
compares)
<pinotree> Dom: samuel makes buildds build perl with nocheck (otherwise
we'd have no perl at all)
<pinotree> which tests still fail?
<Dom> ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t
../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t
../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t
op/sigdispatch.t
<Dom> buildds> I see
<pinotree> ah ok, those that are failing for me even with my patches
<Dom> I hadn't spotted that the builds were done with nocheck.
<Dom> (but only sometimes...)
<Dom> Explains a lot
<pinotree> syslog is kind of non-working on hurd, and syslog.t succeeds in
buildds (as opposted to crash the machine...) because there's no /var/log
in chroots
<pinotree> libc.t appears to succeed too in buildds
* Dom notices how little memory strauss has, and cancels the build, now
that he *knows* that running out of memory caused the crahses
<pinotree> iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because
of trobules we have with posix signals
<pinotree> socketpair.t is kind of curious, it seems to block on
socketpair()...
* Dom wonders if a wiki page tracking this would be worthwhile
<pinotree> stack.t fails because we cannot set a different size for pthread
stacks, yet (similar failing test cases are also in the python test
suite)
<Dom> if there are problems which aren't going to get resolved any time
soon, it may be worth a few SKIPs conditional on architecture, depending
on how serious the issue is
<Dom> then we'd get better visibility of other/new issues
<Dom> (problems which aren't bugs in perl, that is)
<pinotree> understandable, yes
<pinotree> i think nobody digged much deeper in the failing ones yet, to
actually classify them as due to glibc/hurd/mach
<pinotree> (eg unlike the pipe behaviour in sysconf.t i reported)
2011-11-26
<pinotree> cool, my recvfrom() fix also makes the perl test recv.t pass
Part II
Next, Hurd-specific features can be added. Add an interface to the language/environment for being able to do RPC calls, in order to program translators natively in Perl.
Original GSoC Task Description
The main idea of the Hurd design is giving users the ability to easily modify/extend the system's functionality (extensible system). This is done by creating filesystem translators and other kinds of Hurd servers.
However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to really be able to reap the advantages of the Hurd architecture.
Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular high-level language, that helps quickly creating simple programs, are highly welcome.
Several approaches are possible when creating such bindings. One way is simply to provide wrappers to all the available C libraries (libtrivfs, libnetfs etc.). While this is easy (it requires relatively little consideration), it may not be the optimal solution. It is preferable to hook in at a lower level, thus being able to create interfaces that are specially adapted to make good use of the features available in the respective language.
These more specialized bindings could hook in at some of the lower level library interfaces (libports, glibc, etc.); use the MIG-provided RPC stubs directly; or even create native stubs directly from the interface definitions. The lisp bindings created by Flavio Cruz as his 2008 GSoC project mostly use the latter approach, and can serve as a good example. In his 2011 GSoC project, Jérémie Koenig designed and began implementing an object-oriented interface; see his Java status page for details.
The task is to create easy to use Hurd bindings for a language of the student's choice, and some example servers to prove that it works well in practice. This project will require gaining a very good understanding of the various Hurd interfaces. Skills in designing nice programming interfaces are a must.
Anatoly A. Kazantsev has started working on Python bindings last year -- if Python is your language of choice, you probably should take his work and complete it.
There was also some previous work on Perl bindings, which might serve as a reference if you want to work on Perl.
Possible mentors: Anatoly A. Kazantsev (anatoly) for Python
Discussion
Java
IRC, freenode, #hurd, 2013-12-19
<antrik_> teythoon_: I don't think wrapping libtrivfs etc. for guile
bindings is really desirable... for the lisp bindings, we agreed that
it's better to hook in at a lower level, and build more lispish
abstractions
<antrik> trivfs is a C framework; it probably doesn't map very well to
other languages -- especially non-imperative ones...
<antrik> (it is arguable whether trivfs is really a good abstraction even
for C... but that's another discussion :-) )
<antrik> ArneBab: same for Python bindings. when I suggested ignoring
libtrivfs etc., working around the pthread problem was just a side effect
-- the real goal has always been nicer abstraction
<anatoly> antrik: agree with you
<anatoly> antrik: about nicer abstractions
<teythoon_> antrik: I agree too, but wrapping libtrivfs is much easier
<teythoon_> otherwise, one needs to reimplement lots of stuff to get some
basic functionality
<teythoon_> like a mig that emits your language
<braunr> i agree with antrik too
<braunr> yes, the best would be mig handling multiple languages
<antrik> teythoon_: not exactly. for dynamic languages, code generation is
silly. just handle the marshalling on the fly. that's what the Lisp
bindings are doing (AFAIK)
<teythoon> antrik: ok, but you'd still need to parse the rpc definitions,
no?
<antrik> teythoon: yeah, you still need to parse the .defs -- unless we add
reflection to RPC interfaces...
<antrik> err, I mean introspection