diff options
authorSamuel Thibault <>2009-03-27 23:29:10 +0100
committerSamuel Thibault <>2009-03-27 23:29:10 +0100
commit065f9e6711a30f93adf244fe3e4ee0f90b270395 (patch)
parent13ff89f5e4f6964cadee19083509725794cf5228 (diff)
typos, add myself to possible mentors
12 files changed, 17 insertions, 17 deletions
diff --git a/community/gsoc/project_ideas/cdparanoia.mdwn b/community/gsoc/project_ideas/cdparanoia.mdwn
index 5215d54..117dc56 100644
--- a/community/gsoc/project_ideas/cdparanoia.mdwn
+++ b/community/gsoc/project_ideas/cdparanoia.mdwn
@@ -23,7 +23,7 @@ The goal of this task is fully working cdparanoia in Debian GNU/Hurd. It will
require digging a bit into Hurd internals and ATAPI commands, but should be
quite doable without any previous knowledge about either.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Look at the implementation of the existing ioctl()s, and try to find
something that could be easily added/improved. If you don't see anything
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn
index aa4823d..a6e090e 100644
--- a/community/gsoc/project_ideas/download_backends.mdwn
+++ b/community/gsoc/project_ideas/download_backends.mdwn
@@ -10,7 +10,7 @@ is included in the section entitled
[[meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]]
-The Hurd design faciliates splitting up large applications into independent,
+The Hurd design facilitates splitting up large applications into independent,
generic components, which can be easily combined in different contexts, by
moving common functionality into separate Hurd servers (translators),
accessible trough filesystem interfaces and/or specialized RPC interfaces.
@@ -19,7 +19,7 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for
this kind of modularization: a program could simply use the download
functionality by accessing FTP, HTTP etc. translators.
-There is already an ftpfs traslator in the Hurd tree, as well as a [httpfs
+There is already an ftpfs traslator in the Hurd tree, as well as an [httpfs
translator on hurdextras](; however,
these are only suitable for very simple use cases: they just provide the actual
file contents downloaded from the URL, but no additional status information
diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn
index f91a5e6..135c19a 100644
--- a/community/gsoc/project_ideas/gnat.mdwn
+++ b/community/gsoc/project_ideas/gnat.mdwn
@@ -19,6 +19,6 @@ requires implementing some explicitely system-specific stuff in GNAT, and maybe
fixing a few other problems. Good knowledge of Ada is a must; some Hurd
knowledge will have to be aquired while working on the project.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Fix one of the problems preventing GNAT from working on the Hurd.
diff --git a/community/gsoc/project_ideas/hardware_libs.mdwn b/community/gsoc/project_ideas/hardware_libs.mdwn
index e368037..91246e3 100644
--- a/community/gsoc/project_ideas/hardware_libs.mdwn
+++ b/community/gsoc/project_ideas/hardware_libs.mdwn
@@ -15,9 +15,9 @@ libusb, libbluetooth, libraw1394 etc.
The Hurd presently doesn't support these devices. Nevertheless, all of these
programs could still be built -- and most of them would indeed be useful --
-without actual support of these hardware devices. However, as the libraries are
-presently not available for Hurd, the programs can't be easily built in Debian
-GNU/Hurd due to missing dependencies.
+without actual support of these hardware devices, kdebase for instance. However,
+as the libraries are presently not available for Hurd, the programs can't be
+easily built in Debian GNU/Hurd due to missing dependencies.
This could be avoided by providing dummy libraries, which the programs could
link against, but which wouldn't actually do any hardware access: instead, they
@@ -35,7 +35,7 @@ special previous knowledge, though some experience with build systems would be
helpful. Finishing this task will probably require learning a bit about the
hardware devices in question, and about Debian packaging.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Get one of the libraries to compile on Debian GNU/Hurd. It doesn't
need to report reasonable error codes yet -- just make it build at all for now.
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index b65ee13..9e72281 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -31,7 +31,7 @@ Some knowledge of POSIX capabilities will need to be obtained, and for the
latter part also some knowledge about the Hurd architecture. This project is
probably doable without previous experience with either, though.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually
do anything yet -- just make it build at all for now.
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
index 0391407..434e39b 100644
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -30,7 +30,7 @@ thus it's not suitable for a GSoC project...)
This task requires experience with debugging locking issues in multithreaded
-Possible mentors: ?
+Possible mentors: Samuel Thibault (youpi)
Exercise: If you could actually track down and fix one of the existing locking
errors before the end of the application process, that would be excellent. This
diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn
index a8a469a..4f84882 100644
--- a/community/gsoc/project_ideas/libgtop.mdwn
+++ b/community/gsoc/project_ideas/libgtop.mdwn
@@ -29,6 +29,6 @@ C/UNIX programming skills of course); but during the course of the project,
some knowlegde about Hurd internals will have to be obtained, along with a bit
of Debian stuff.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Fix one of the shortcomings in the existing procfs implementation.
diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn
index 73b4fa4..797cc0d 100644
--- a/community/gsoc/project_ideas/maxpath.mdwn
+++ b/community/gsoc/project_ideas/maxpath.mdwn
@@ -14,7 +14,7 @@ POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and
similar, which may be defined by the system to indicate certain limits. Many
people overlook the *may* though: Systems only should define them if they
actually have such fixed limits. The Hurd, following the GNU Coding Standards,
-tries to aviod this kind of arbitrary limits, and consequently doesn't define
+tries to avoid this kind of arbitrary limits, and consequently doesn't define
the macros.
Many programs however just assume their presence, and use them unconditionally.
@@ -38,6 +38,6 @@ significant number of packages, and make the fixes ready for inclusion in
Debian and (where possible) upstream. No Hurd-specific knowledge is needed, nor
any other special knowledge aside from general C programming skills.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Fix the PATH_MAX issues in some Debian package.
diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn
index a22540a..803f710 100644
--- a/community/gsoc/project_ideas/perl.mdwn
+++ b/community/gsoc/project_ideas/perl.mdwn
@@ -24,7 +24,7 @@ the test suite failures are about, the actual work necessary to fix these
issues is mostly C programming -- in the implementation of Perl and/or the
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Make some improvement to Perl support on the Hurd, e.g. fixing one of
the known test suite failures.
diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn
index 39c4241..26bb91c 100644
--- a/community/gsoc/project_ideas/sound.mdwn
+++ b/community/gsoc/project_ideas/sound.mdwn
@@ -31,7 +31,7 @@ to come up with an appropriate design.
Another option would be to evaluate whether a driver that is completely running
in user-space is feasible. <!-- TODO. Elaborate. -->
-Possible mentors: ?
+Possible mentors: Samuel Thibault (youpi)
Exercise: This project requires kernel (driver framework) hacking as well as
some Hurd server hacking; so the exercise should involve either of these, or
diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn
index 3499fb5..ab16dfb 100644
--- a/community/gsoc/project_ideas/xattr.mdwn
+++ b/community/gsoc/project_ideas/xattr.mdwn
@@ -41,7 +41,7 @@ with xattrs might help a bit, but shouldn't be really necessary either.
Some previous work on xattr support is available in [[GNU_Savannah_patch
5126]], and might serve as a starting point.
-Possible mentors:
+Possible mentors: Samuel Thibault (youpi)
Exercise: Implement support for different inode sizes (other than 128 bytes) in
Hurd's ext2fs.
diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn
index 0899d20..153b8bf 100644
--- a/community/gsoc/xorg_ideas.mdwn
+++ b/community/gsoc/xorg_ideas.mdwn
@@ -52,7 +52,7 @@ anything useful, but compiles fine on the Hurd.
While XFree86 was first ported to the Hurd more than a decade ago, and there
are updates now and then to make newer versions of Xorg run as well (see also
-the libpciaccess task), the support is quite rudimentary: in particualar, there
+the libpciaccess task), the support is quite rudimentary: in particular, there
is no support for switching back to the text console while X is running.
Implementing this requires creating an interface between the X server and the