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 5215d541..117dc56e 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 aa4823de..a6e090eb 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](http://www.nongnu.org/hurdextras/#httpfs); 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 f91a5e61..135c19aa 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 e3680378..91246e3b 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 b65ee13c..9e722815 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 03914078..434e39ba 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
 applications.
 
-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 a8a469a2..4f848820 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 73b4fa46..797cc0dc 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 a22540a8..803f710e 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
 Hurd.
 
-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 39c4241a..26bb91cb 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 3499fb5f..ab16dfbb 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 0899d20c..153b8bf6 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