Merge branch 'master' of flubber:~hurd-web/hurd-web

21 files changed, 1063 insertions, 365 deletions

diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 875b462f..1346203d 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -31,6 +31,10 @@ 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.
 
+David Hedberg applied for this project in 2010,
+and though he didn't go through with it,
+he fleshed out many [[libcap/details]].
+
 Possible mentors: Samuel Thibault (youpi)
 
 Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
new file mode 100644
index 00000000..aa27a84e
--- /dev/null
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -0,0 +1,766 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Details on implementing libcap"]]
+
+
+This is the proposal submitted by David Hedberg for GSoC 2010 (who opted
+to go with another mentoring organization), adapted from an initial
+proposal and several amendments into a single document, but the idea
+is to further adapt it to a more neutral design document over time.
+
+
+# The proposal
+
+### Quick description of POSIX capabilities
+
+The original suggestion can be found [[here|libcap]].
+POSIX capabilities never actually entered the POSIX standard but was
+left as a draft.  Linux has nevertheless implemented this draft, and
+there are reasons for doing the same in the Hurd - a more fine grained
+control of rights leading to increased security being one of them.
+
+POSIX capabilities are give on a per-process basis, and basically allows
+splitting up those rights usually granted to root into smaller and more
+specific rights.  Examples of capabilities are CAP_CHOWN and CAP_KILL,
+overriding certain restrictions on chown and allowing the process to
+kill processes with different UID's, respectively.
+
+Each process is given three sets with capabilities: the Permitted set
+(P), the Effective set (E) and the Inheritable set (I).  The effective
+set contains the capabilities that are currently active.  The permitted
+set contains the capabilities that the process has the right to use.
+The inheritable set contains the capabilities that can be inherited
+by children to the process.  A process can drop capabilities from its
+permitted set, but not set them.  The effective set and the inheritable
+set can be changed freely as long as they stay subsets of the permitted
+set.
+
+Capabilities can also be set on executables.  When executed, the resulting
+process is given the capabilities both as defined by the parent process
+and by the capabilities set on the file (formula below), resulting in
+what might be explained as a fine-grained setuid.  Implementing this
+requires support for *xattr* or similar.
+
+Some applications that are currently using capabilities are samba, ntp,
+vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot.
+
+
+### A quick description of capabilities in Linux
+
+Each process has a three bit fields representing each of the three
+sets (P, E and I).  Each bit field is currently built up of two (32
+bit) integers to be able to hold the 33 currently defined capabilities
+(see linux/capability.h).  Each process further has a bounding set which
+bounds the permitted set.  Two syscalls handles the setting and getting
+of capabilities; *capset* and *capget*.  Some related functionality
+can also be controlled by calling *prctl*: the right to read/drop the
+bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether
+or not the process should keep its capabilities when a change is made
+to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS).  User space
+applications are expected(recommended?) to use libcap to take advantage
+of the functionality provided.  Some applications also use libcap-ng
+which is "intended to make programming with POSIX capabilities much
+easier than  the traditional libcap library".  Most applications seem
+to be using the original libcap, however.
+
+
+## Implementing libcap
+
+The exercise for this assignment was to get the libcap used in
+Linux to compile under the Hurd.  This was accomplished using the
+latest git version of libcap from (..), corresponding to libcap
+2.19.  The changes were simple and amounted to simply removing the
+dependency on some Linux-specific headers and creating stubs for
+capset, capget and prctl described above.  This suggests that porting
+this library to the Hurd once the proper functionality is in place
+could be relatively simple.  The patch is available
+[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth").
+One could also consider implementing the three missing functions in the
+Hurd (or Hurd glibc) which would allow the usage of the Linux libcap
+without modifications.  As the Linux libcap maintainer might or might
+not be interested in making libcap multi platform, this approach might
+be preferable.
+
+
+## Implementing POSIX capabilities in the Hurd
+
+As I am still reading up on how things fit together in the Hurd this is
+very likely to contain some misunderstandings and be at least partly off
+the mark.  I intend to have grasped this by the time I start working on
+it however, if I were to be given the chance.  Below are two possible
+approaches as I have understood them after some reading and discussions
+on #hurd@freenode.
+
+
+### The basics, Approach 1: Special UID's
+
+Let each capability be represented by a specific UID.  One could imagine
+reserving a range of the possible uid_t's for this purpose.  The euids
+vector in the authhandle struct could perhaps hold the effective set while
+the auids vector could hold the permitted set as these seem to roughly
+correspond to eachother in intent.  This leaves the Inheritable set.
+One solution could be to store the inheritable set in the agids vector,
+but that does not seem to be a very natural nor nice solution.  One could
+extend the authhandle struct with an additional vector, but one would then
+need to also extend the auth interface with RPC's to be able to modify
+and access it.  Another possibility is to store all the capabilities
+in the same idvec and use separate defines for the the different sets
+(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD).  This does not seem like a
+good solution.
+
+Storing each capability in its own uid_t might also arguably be somewhat
+wasteful, although this is probably of secondary concern (if at all).
+One could also imagine that legacy applications might be confused,
+although I am not sure I can see any obvious problems.  What happens
+when a process have only capability id's?
+
+
+### The basics, Approach 2: Extend the auth interface
+
+This approach would expand the auth interface and extend
+the auth server with another set of RPC's for capabilities
+(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and
+*auth_server_authenticate*), mirroring those currently declared for id's.
+This would obviously require changes to more parts of the Hurd for
+processes to be able to take advantage of capabilities, but as the logic
+behind handling capabilities and that behind handling user id's might
+not be completely comparable, this might make for a cleaner solution.
+It would also remove the problem of having to sensibly map all the
+three capability sets onto semantically differing sets of user/group
+ids, something that might be even more important if we were to also
+implement something like the bounding sets used in Linux or perhaps
+other related functionality.  We are also not limited to having to store
+the capabilities as id vectors, although doing so would perhaps still
+make sense.
+
+
+### The individual capabilities
+
+Implementing the individual capabilities will probably have to be thought
+of on a case-by-case basis.  Taking chown (in *libdiskfs*) as an example,
+the exact approach would differ slightly depending on how the approach
+taken to implement capabilities.  If the first approach were to be taken,
+the UID's (and thus the capabilities) of the caller would already be
+available to the function through the *iouser* struct contained in the
+*protid* struct given as the first argument.  Implementing capabilities
+would then simply be a matter of checking for the special UID's.  If the
+second approach were to be taken, one would need to perhaps expand the
+iouser struct to contain information about the capabilities.
+
+Just like Linux has defined many Linux-specific capabilities - some of
+which could certainly be useful also applied to the Hurd - one could
+also imagine extending the POSIX capability system also for Hurd specific
+purposes.
+
+
+## Some applications using capabilities
+
+#### Samba 3
+
+Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities.
+Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files
+from being deleted.  Can also use a couple of IRIX specific capabilities
+(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific
+ones if running on IRIX.
+
+
+#### ntpd
+
+Checks if capabilities are supported, more precisely if CAP_SYS_TIME,
+CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are
+supported.  If they are supported, it uses prctl with PR_SET_KEEPCAPS
+to keep privileges across setuid() and then drops root.  After done with
+CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except
+CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE.
+
+
+#### vsftpd
+
+Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process"
+security model (typically disabled by default).
+
+
+#### proftpd-basic
+
+Provides support for capabilities from mod_cap.  Uses CAP_USE_CHOWN,
+CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE.
+Distribution contains README.capabilities with some explanations.
+Also ships with their own libcap for some reason, based on libcap 1.10.
+
+
+#### dovecot
+
+Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID,
+CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops
+the rest.
+
+
+#### bind9
+
+Reasons for each capability are clearly noted in comments in update.c
+in linux_initialprivs() and linux_minprivs().  initialprivs drops all
+capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT,
+CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN.  minprivs only
+sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
+
+
+#### pulseaudio
+
+Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it
+(anymore?).  Seems to use libcap to drop caps, however.
+
+
+#### pinentry
+
+Checks if CAP_IPC_LOCK is available and "uses it" to gain only the
+ability to lock memory when needed.
+
+
+#### zsh
+
+Comes with a module "caps" which contains "[b]uiltins for manipulating
+POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the
+"cap" builtin, which makes it possible to change the shell's process
+capability sets.  This might be useful for testing.
+
+
+#### inetutils (ping,traceroute)
+
+Does not use capabilities explicitly, but is nevertheless a useful
+example of how file capabilities could be used.  ping and traceroute
+are currently installed suid root since they need to be able to open
+raw sockets.  With file capabilities, this could be accomplished by
+instead setting the capability CAP_NET_RAW on the two executables,
+thus giving the utilities almost only the specific rights they need.
+
+
+## The capabilities
+
+The above might give some hint as to what capabilities should be
+prioritized.  One assumption I have made is that the goal of this project
+is to implement, as far as possible, the same functionality as what is
+present in Linux.  No effort has (so far) been made to look into possible
+applications specific to the Hurd.
+
+A few of the above mentioned applications also explicitly uses
+PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should
+be passed on to children.  This means that the implementation in the
+Hurd should take this into account.
+
+I have below done a preliminary classification of the capabilities
+as defined in Linux capability.h into four "classes": Network, File
+management, "glibc -> mach" and Other.  There are also some capabilities
+that either depend on functionality not implemented or are too Linux
+specific.  I have not described each capability in detail as looking
+at the comments in capability.h and reading in capabilities(7) are
+better sources.
+
+
+### The Networking Class
+
+These would mostly affect pfinet.  The general picture seem to be that
+pfinet currently uses a boolean (int) isroot in struct sock_user to keep
+track of the credentials of the caller.  This would need to be expanded
+somehow to keep track of the separate capabilities.
+
+CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024  
+CAP_NET_RAW: Allow use of RAW and PACKET sockets.  
+CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast"  
+CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related
+administration.  
+
+
+### The Files Management Class
+
+The description of CAP_CHOWN in the original proposal should apply to
+(most of?) these.  That is, modify the iouser struct.  At least libdiskfs
+should be modified, but the same or similar modifications might need to
+be made to several servers (libnetfs..? The actual servers implementing
+the filesystem?)
+
+CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs"  
+CAP_FOWNER: allow chmod, utime, ..  for files not owned.  
+CAP_FSETID: Don't clear setuid/setgid when a file is modified.  
+CAP_DAC_OVERRIDE and  
+CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission
+checks.  ( hurdexec.c, file-access.c, ..  ? )  
+CAP_MKNOD: allows usage of "the privileged aspects of mknod()".  Does this
+one make sense in the Hurd?  
+
+
+### The (glibc -> gnumach) Class
+
+These seem to be implemented in glibc by direct calls to gnumach.
+If they should be implemented, maybe a proxy in the Hurd is needed?
+
+CAP_SYS_TIME: manipulate the system clock, set real-time clock.  
+CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl  
+CAP_KILL: No permission checks for killing processes  
+CAP_SYS_NICE: setpriority/getpriority for arbitrary processes.  
+
+
+### The Rest Class
+
+CAP_SYS_CHROOT: Allows usage of chroot().  
+It's either really simple (not needed in the case of the Hurd) or really
+difficult.  Needs some figuring out.  One of the calls that should be
+high-priority.  
+CAP_SYS_ADMIN: General administration rights.  Seemingly sprinkled out
+into just about everything.  Quick grep through the Linux sources gives
+440 hits in .c-files.  
+CAP_SYS_BOOT: Allow use of reboot().  
+glibc calls init:startup_reboot..    
+CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket
+credentials passing"  
+CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials
+passing"  
+CAP_SYS_TTY_CONFIG: vhangup, some other places.  vhangup() is a stub in
+the Hurd, but maybe the console server is otherwise affected?  
+CAP_SYS_RESOURCE: Override various limits.  (quota, reserved space etc.
+on ext2, interrupt frequencies, consoles,...).  According to "The Critique"
+mach performs no resource accounting so some of these might be moot to
+implement, while others still apply.  
+CAP_SYS_RAWIO Allow raw input/output.  Sprinkled in many places,
+device drivers among others.  Many of these will probably be difficult
+to implement.  
+CAP_SETPCAP: This one has (or had?) two different usages in Linux:
+If file capabilities are not supported it gives the right to grant
+or remove capabilities from the permitted set of arbitrary processes.
+If file capabilities are supported, it allows for removing capabilities
+from the bounding set of the current process.  As the Hurd implementation
+won't have file capabilities initially it might make sense to implement
+this if possible.  If bounding sets are implemented this should probably
+be the way provided to modify them.  
+
+
+### Unimplementable
+
+*(At this point in time, as far as I can determine)*
+
+CAP_LINUX_IMMUTABLE: depends on chattr etc. working.  
+CAP_SETFCAP: depends on xattr's  
+CAP_SYS_PACCT: acct() missing in the Hurd.  
+CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN,
+CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE  
+
+
+## Priority when implementing
+
+The two most used capabilities as unscientifically judged from
+the selection of applications above are CAP_NET_BIND_SERVICE and
+CAP_CHOWN, suggesting that implementing the "network class" and the
+"file management" class of capabilities as classified above might be a
+good start.  These also, to me, seem to be easier classes to implement.
+CAP_NET_ADMIN might need some extra work.
+
+Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am
+not completely clear on how these should be handled.
+
+Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL
+and CAP_SYS_NICE might be a good choice to tackle if possible. This
+might, if I have understood things correctly, involve writing a proxy
+Hurd server for these calls in mach.
+
+CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit
+of "everything" (ADMIN being the worse one), meaning that experience
+and infrastructure gained from implementing the previous capabilities
+might come in handy. CAP_SYS_RAWIO might be difficult; it can be found
+inside many drivers in the Linux source.
+
+
+## Additional general details
+
+[This article](http://www.ibm.com/developerworks/library/l-posixcap.html)
+contains a good general description of how capabilities in Linux
+works.  As there will be no file capabilities in the Hurd initially,
+an approach emulating the behavior Linux exhibits when SECURE_NOROOT
+and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start.
+This is called the "root-user-is-privileged" model in the article,
+and somewhat simplified it means that processes started by root, or
+setuid-root, is given all capabilities no matter what capabilities the
+parent might or might not hold at the time of execution.  Quoting verbatim
+from the article:
+
+> * When SECURE_NOROOT is not set, then when a process executes a file,
+>  the new capability sets may be calculated as though the file had some
+>  file capability sets set fully populated.  In particular:
+>
+>  * The file inheritable and permitted sets will be full on if the
+>    process's real or effective uid is 0 (root) or the file is setuid
+>    root.
+>
+>  * The file effective set will be full on if the process's effective
+>    uid is root or the file is setuid root.
+>
+>
+> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches
+>   its real or effective uids to or from 0, capability sets are further
+>   shifted around:
+>
+>   * If a process switches its effective uid from 0 to non-0, then its
+>     effective capability set is cleared.
+>
+>   * If a process switches its real, effective, or saved uids from at
+>     least one being 0 to all being non-zero, then both the permitted
+>     and effective capabilities are cleared.
+>
+>   * If a process sets its effective uid from non-zero to 0, then the
+>     effective capabilities are set equal to the permitted capabilities.
+
+The capabilities of the resulting process are determined by the following
+formulas, again taken from the article, with p for Process and f for file:
+
+> pI' = pI  
+> pP' = fP | (fI & pI)  
+> pE' = pP' & fE  
+
+The security under the above described model, being what at least some
+of the applications I listed in my last comment employs, is basically
+the following (also detailed somewhat in the same article):
+
+* Execute process as root (or setuid) to gain all capabilities.
+
+* Use the prctl system call to enable keepcaps for the process
+  (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process).
+  keepcaps should be off by default.
+
+* setuid to a non-root user, and by doing so losing the possibility to
+  regain capabilities by simply starting a new process.
+
+* Drop all the capabilities except those few actually needed.
+
+
+## Infrastructure details - Special UIDs approach
+
+The auth server must somehow keep track of three sets of capabilities.
+I suggest keeping these three sets in three additional idvec's in the
+authhandle struct, and will for the purpose of this description name
+these pcaps (permitted), ecaps (effective) and icaps (inheritable).
+This will simplify keeping track of the internal logic somewhat.
+In addition to this, there is a need to keep track of the "keepcaps" flag
+as described above.  I suggest representing this with an int keepcaps
+in the same struct.
+
+1. Expand authhandle struct with three additional idvecs and one integer.
+Fix static functions handling the struct, such as destroy_authhandle.
+
+2. Implement the necessary logic in auth_makeauth to handle capabilities.
+
+Problems:  
+Assume that all capabilities are mapped onto uids, given names on the form
+uid_<capability>, for example uid_cap_net_raw.  Assume that the presence
+of an uid in euids suggest that the capability is in the effective set
+of the process, that the presence of this uid in auids suggests that it
+is in the permitted set of the process, and that the presence of this
+uid in aguids suggest that it is in the inheritable set of the process.
+That they are internally stored in separate idvec's can be ignored as
+an implementation detail.
+
+* The UID's have as it is different meanings depending on where in the
+  array they are positioned, and certain clients seem to rely on this.
+  The first UID in euids is the effective uid, and the first and second
+  UIDs in auids are the real and saved UIDS respectively.  At least
+  some users of makeauth would need to made aware of capabilities,
+  for example setuid in glibc.
+
+* Setting/getting the keepcaps-flag is also a bit of a problem.  To avoid
+  changing the auth interface yet another special UID could be used
+  for this purpose, although that seems to be really stretching it.
+  The cleaner solution would probably be to expand the interface with
+  something along the lines of auth_setkeepcaps/auth_getkeepcaps.
+  This interface would only be used by prctl.
+
+Another problem with this approach is that it seems a bit difficult
+to oversee the affects that using other RPC's like fsys_getroot and
+io_restrict_auth might have on capabilities.
+
+
+## Infrastructure details - "extend-interfaces" approach
+
+This approach has started to seem like the better way to me, as the
+usage of capabilities becomes more explicit through the entire "chain",
+perhaps making it somewhat more easy to understand all the interactions.
+
+I suggest something like the following new interface methods:
+
+***
+
+
+### The auth interface
+
+	routine auth_getauth_caps (
+		handle: auth_t;
+		out euids: idarray_t;
+		out auids: idarray_t;
+		out egids: idarray_t;
+		out agids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t);
+
+	routine auth_makeauth_caps (
+		handle: auth_t;
+		other_handles: portarray_t;
+		euids: idarray_t;
+		auids: idarray_t;
+		egids: idarray_t;
+		agids: idarray_t;
+		ecaps: idarray_t;
+		pcaps: idarray_t;
+		icaps: idarray_t;
+		flags: int;   /* keepcaps.. ? */
+		out newhandle: mach_port_make_send_t);
+
+	routine auth_server_authenticate_caps (
+		handle: auth_t;
+		sreplyport reply: mach_port_poly_t;
+		rendezvous: mach_port_send_t;
+		newport: mach_port_poly_t;
+		out euids: idarray_t;
+		out auids: idarray_t;
+		out egids: idarray_t;
+		out agids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t);
+
+
+### The io interface
+
+	routine io_restrict_auth_caps (
+		io_object: io_t;
+		RPT
+		out new_object: mach_port_send_t;
+		uids: idarray_t SCP;
+		gids: idarray_t SCP;
+		ecaps: idarray_t SCP);
+
+
+### The fsys interface
+
+	routine fsys_getroot_caps (
+		fsys: fsys_t;
+		RPT
+	#ifdef  FSYS_GETROOT_UREPLY
+		ureplyport ureply: mig_reply_port_t;
+	#endif
+		dotdot_node: mach_port_send_t;
+		gen_uids: idarray_t;
+		gen_gids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t;
+		flags: int;
+		out do_retry: retry_type;
+		out retry_name: string_t;
+		out file: mach_port_send_t);
+
+***
+
+These are meant to be able to replace the old methods with
+capability-aware methods, instead of merely complementing them.
+The replacing work could then be made a more gradual process.  Steps:
+
+* Extend authhandle with the same data members as in the UID-case.
+
+* Implement new _caps-functions according to described interface
+  extensions above, refactor code a bit to share common uid-handling
+  logic.  Both makeauth's should drop all capabilities if switching from
+  uid 0 without having keepcaps.  For example, keepcaps should be unset
+  by default.
+
+* Fix glibc.  Extend hurd_id_data in hurd/id.h to store capabilities,
+  switch to capability aware functions where necessary.
+
+* io-reauthenticate.  Fix implementations to use
+  auth_server_authenticate_caps instead.  For this we also need somewhere
+  to save the caps, so it ties in with for example the extension of
+  iouser as mentioned in the details.
+
+* fsys_getroot.  Implement fsys_getroot_caps in libdiskfs, trans,
+  libtreefs, libtrivs, libnetfs.  Fix users of function in libdiskfs,
+  libfshelp, settrans, libtreefs, clookup.
+
+* io_restrict_auth.  Implement io_restrict_auth_caps in libdiskfs,
+  libtreefs, libtrivfs, libnetfs, boot.  Fix users in utils(symlink,
+  firmlink), libtrivs, term, clookup
+
+Among the problems might be that there are a lot of arguments that
+needs to be passed around, and that it seems somewhat ugly to end up
+with function names referencing caps in particular.
+
+Below some more about the specific capabilities.  This should in large
+be common to the two approaches above.
+
+
+## Actually handing out the capabilities to process
+
+This seems like a good job for the file_exec route in the fs interface.
+Quoting from the comments above the definition in fs.defs: "*Necessary
+initialization, including authentication changes associated with set[ug]id
+execution must be handled by the filesystem*".  The capability-granting
+functionality should to be added in at least the implementations in
+libdiskfs and libnetfs as far as I can determine, and should be "easy
+enough" once the infrastructure for implementing the file-related
+capabilities (CAP_CHOWN etc.) are in place.  This also seem to make
+sense considering the future possibility for file capabilities.
+
+
+## Some implementation details of individual capabilities.
+
+### Net-related capabilities.
+
+This turned out to be a bit less work than I had thought, as the
+imported Linux code already seem to contain all the necessary checks.
+What remains to do to implement all of these capabilities is mostly a
+matter of putting some infrastructure in place.
+
+* In struct sock_user (pfinet.h), change isroot for idvec
+  caps.  Alternatively, add idvec caps.
+
+* Change the function make_sock_user in socket.c to take an idvec caps
+  as a parameter and properly set the given caps to the corresponding
+  idvec in sock_user.
+
+* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth,
+  S_socket_create, S_socket_accept.  This should be doable with the
+  current infrastructure.  For example, S_socket_create currently
+  sets isroot in the new sock_user from the corresponding member in
+  the trivfs_protid struct.  This does not present a problem however,
+  as the latter struct also provides access to an iouser (iohelp.h)
+  from which the needed uids of the user should be available.
+
+* Fix up parts of source from Linux, modify task_struct add idvec,
+  modify prepare_current to take the caps idvec instead of isroot.
+  Re-implement the existing function capable(int cap) to actually check
+  for the capability passed as an argument instead of just return isroot.
+
+* Change a few isroot's at 3 other places in the code to check for
+  capabilities.  Since these places all have access to isroot and thus by
+  implication the sock_user, they also have access to the new capability
+  information; no restructuring necessary.
+
+
+### File-related capabilities
+
+While there are a lot of servers in the Hurd, I am not sure all of these
+capabilities actually make sense to implement in all of them.
+
+
+#### CAP_CHOWN
+
+Implementing this in libdiskfs should take care of it where it makes
+sense.  Servers using libdiskfs uses iouser from libiohelp to hold
+user credentials.  As noted above, this struct is already capable of
+holding our capabilities as uid's or is otherwise extended to contain
+the necessary idvecs if using the second general approach.  Adding a
+check along the lines of *idvec_contains(uid_cap_chown)* in function
+diskfs_S_file_chown (file-chown.c) should be all that's needed.
+
+In libnetfs, netfs_attempt_chown is declared as a function that the
+server using the library must implement.  Any checks for chown rights
+are however most likely performed on the server side, suggesting that
+there is nothing we can do here to implement CAP_CHOWN.  Even if we do
+need to add something, an iouser containing the necessary information
+to implement the checks in a manner analogous to that in libdiskfs seems
+to be passed to each important function.
+
+
+#### CAP_DAC_*
+
+These might actually make sense to implement in more servers, and the
+logic seems somewhat involved. Need to add the necessary checks to
+at least file_check_access, file_exec in libdiskfs.  file_exec also in
+libnetfs, probably.  Possibly changes also in other places.
+
+The main difficulties overall seem to lie in getting the infrastructure
+properly in place rather than implementing most of the individual
+capabilities, and I have updated the schedule a bit in an attempt to
+reflect this.
+
+
+## Schedule updating
+
+The more I look into this the less time it seems likely to take to
+do the work.  Below is my best estimation at the moment, and I have
+basically adjusted everything to what I think is more likely estimations.
+If this is correct I would be more or less around midterm.  I haven't
+gone completely to the individual level as that doesn't seem to make
+sense, but what is clustered together are either related capabilities
+or a collection of capabilities classified roughly with regards to how
+much I know about the area and how many different rights they control.
+It's not my intention to "slack off" or anything, so if this estimation
+were to be correct I could perhaps take a look at the xattrs-patch,
+or spend the rest of my time fixing PATH_MAX-issues.  Then again, maybe
+there is some great difficulty hidden somewhere.
+
+
+#### Some justifications:
+
+Dummy libcap, more or less done.  
+*1 day* (making sure it "fails gracefully" shouldn't really take longer than this)
+
+Application for testing, the beginnings of a fairly extensive "test suit" on Linux.  
+*2 days*
+
+Basic infrastructure.  
+*5 days*, depends on the chosen approach, but it is probably wise to
+reserve at least a bunch of days for this.
+
+Implementations of prctl/capset/capget in libshouldbeinlibc,
+or a port of libcap to the Hurd in any other way.  
+*5 days*
+
+CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN  
+*4 days*, as noted above this should be easy, but it might uncover bugs
+in the newly implemented infrastructure for example.
+
+CAP_CHOWN,CAP_FOWNER,CAP_FSETID  
+*2 days*, I think these only needs to be done in libdiskfs
+
+CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH  
+*4 days*, these might need changes to various servers
+
+CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL
+CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT  
+*2 weeks*, these are varied and I'm not that sure exactly how each should
+be tackled so some research is needed.
+
+CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG  
+*4 days*
+
+CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO  
+*2 weeks*, these too are pretty varied and some might need some individual
+researching
+
+CAP_SETPCAP  
+*1 day*
+
+
+## Schedule
+
+24/5 Start coding  
+25/5 Dummy libcap ready for use.  
+27/5 The beginnings of a "test suite", written on Linux.  
+ 1/6 Basic infrastructure in place  
+ 6/6 Dummy libcap extended with real functionality to make use of
+     implemented capability and infrastructure, or the Hurd adapted for
+     compatibility with Linux libcap.  
+10/6 The "network class" of capabilities implemented.  
+12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID  
+16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH  
+30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE,
+     CAP_SYS_CHROOT, CAP_SYS_BOOT  
+ 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG  
+12/7 "Mentors and students can begin submitting mid-term evaluations"  
+16/7 GSoC Mid-term evaluations deadline.  
+18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO  
+19/7 CAP_SETPCAP
diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
index 735c8bbb..331336ac 100644
--- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn
+++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
@@ -34,7 +34,7 @@ make such a split later on feasible.
 
 This is [[!GNU_Savannah_task 5469]].
 
-Possible mentors: ?
+Possible mentors: zhengda
 
 Exercise: You could try making some improvement to the existing pfinet
 implementation; or you could work towards running some existing userspace
diff --git a/hurd.mdwn b/hurd.mdwn
index 24bd97f7..e1bb861d 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-2009 Free Software Foundation, Inc."]]
+2009, 2010 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -88,6 +88,7 @@ in the *unstable* branch of the Debian archive.
 * RPC [[Interface]]s
 * Libraries
   * [[libpager]]
+  * [[libports]]
   * [[libstore]]
   * [[libchannel]]
   * [[libhello_example]] -- Hurd library example
diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn
index c5dddfb6..d5beade9 100644
--- a/hurd/building/cross-compiling.mdwn
+++ b/hurd/building/cross-compiling.mdwn
@@ -21,10 +21,14 @@ Find it in the [[source repositories/incubator]], *cross-gnu* branch.
 
 Read through it.  Understand it.  Only then use it by following the next steps.
 
-/!\ Be made aware that -- while it is of course possible to build a working
-cross-compiler -- this is not trivial to do.  You'll have to patch source
-packages.  See the following list about needed patches, which have not yet been
-installed in the upstream repositories.
+
+## Status
+
+/!\ Please note that these cross toolchains does not yet encompass all of the
+functionality that native toolchains provide.  For example, there is only
+support for C and C++ so far, but not for other languages.  A bunch of fixes /
+enhancements of [[glibc]] are missing.  We're working towards minimizing these
+differences, as well as towards pushing all patches upstream.
 
 
 ### Supported Versions of Source Packages
@@ -34,138 +38,95 @@ guarantee is given.  Always the preferred version is listed first.
 
   * `src/binutils`: [[GNU_Binutils|binutils]]
 
-      * CVS `binutils-2_19-branch`
-
-            $ mkdir binutils-2_19-branch
-            $ cd binutils-2_19-branch
-            $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩
-              co -r binutils-2_19-branch binutils
-
-        The sources are rooted in `binutils-2_19-branch/src/`.  Also use these
-        commands for updating, instead of the usual `cvs update`.
-
-      * The 2.19 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should
-        also be fine.
-
-      * CVS `binutils-2_18-branch`
+      * CVS `binutils-2_20-branch`
 
-            $ mkdir binutils-2_18-branch
-            $ cd binutils-2_18-branch
+            $ mkdir binutils-2_20-branch
+            $ cd binutils-2_20-branch/
             $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩
-              co -r binutils-2_18-branch binutils
+                co -r binutils-2_20-branch binutils
 
-        The sources are rooted in `binutils-2_18-branch/src/`.  Also use these
+        The sources are rooted in `binutils-2_20-branch/src/`.  Also use the above
         commands for updating, instead of the usual `cvs update`.
 
-      * The 2.18 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should
-        also be fine, as should be all other recent releases.
+      * Release of the 2.20 series from <ftp://ftp.gnu.org/gnu/binutils/>
+        should also be fine.
 
   * `src/gcc`: [[GNU_Compiler_Collection|gcc]]
 
-      * SVN `gcc-4_1-branch`
+      * SVN `gcc-4_5-branch`
 
-            $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch
-
-        Prepare:
+            $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch
 
-            $ ( cd gcc-4_1-branch/ && contrib/gcc_update --touch )
+        Patches:
 
-      * Releases of the 4.1 series from <ftp://ftp.gnu.org/gnu/gcc/> should
-        also be fine.
-
-      * SVN `gcc-4_2-branch`
-
-            $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch
-
-          * Patches:
-            <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html>
+          * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html>
 
         Prepare:
 
-            $ ( cd gcc-4_2-branch/ && contrib/gcc_update --touch )
+            $ ( cd gcc-4_5-branch/ && contrib/gcc_update --touch )
 
-      * Releases of the 4.2 series from <ftp://ftp.gnu.org/gnu/gcc/> should
-        also be fine, but need the same set of patches as the `gcc-4_2-branch`
-        needs.
+      * SVN `gcc-4_4-branch`
 
-      * SVN `gcc-4_3-branch`
+            $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch
 
-            $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch
+        Patches:
 
-          * Patches:
-            <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html>
+          * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html>
 
         Prepare:
 
-            $ ( cd gcc-4_3-branch/ && contrib/gcc_update --touch )
-
-      * Releases of the 4.3 series from <ftp://ftp.gnu.org/gnu/gcc/> should
-        also be fine, but need the same set of patches as the `gcc-4_3-branch`
-        needs.
-
-      * SVN `trunk` -- upcoming 4.4 series
+            $ ( cd gcc-4_4-branch/ && contrib/gcc_update --touch )
 
-            $ svn co svn://gcc.gnu.org/svn/gcc/trunk
-
-        Prepare:
-
-            $ ( cd trunk/ && contrib/gcc_update --touch )
+      * Releases of the 4.5 and 4.4 series from <ftp://ftp.gnu.org/gnu/gcc/>
+        should also be fine, but need the same set of patches as the
+        `gcc-4_5-branch` needs.
 
   * `src/gnumach`: [[GNU_Mach|microkernel/mach/gnumach]]
 
-      * CVS `gnumach-1-branch`
+      * Git `master` branch
 
-            $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd ↩
-              co -r gnumach-1-branch gnumach
-            $ mv gnumach gnumach-1-branch
+            $ git clone ↩
+                git://git.sv.gnu.org/hurd/gnumach.git gnumach
 
         Prepare:
 
-            $ ( cd gnumach-1-branch/ && autoreconf -vfi )
+            $ ( cd gnumach/ && autoreconf -vi )
 
   * `src/mig`: [[microkernel/mach/mig/GNU_MIG]]
 
-      * CVS `HEAD`
+      * Git `master` branch
 
-            $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig
+            $ git clone ↩
+                git://git.sv.gnu.org/hurd/mig.git mig
 
         Prepare:
 
-            $ ( cd mig/ && autoreconf -vfi )
+            $ ( cd mig/ && autoreconf -vi )
 
   * `src/hurd`: [[GNU_Hurd|hurd]]
 
-      * CVS `HEAD`
+      * Git `master` branch
 
-            $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd
+            $ git clone ↩
+                git://git.sv.gnu.org/hurd/hurd.git hurd
 
-  * `src/glibc`: [[GNU_C_Library|glibc]]
-
-      * CVS `glibc-2_7-branch`
+  * `src/libpthread`: [[libpthread]]
 
-            $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩
-              co -r glibc-2_7-branch glibc
-            $ mv libc glibc-2_7-branch
+      * Git `tschwinge/Peter_Herbolzheimer` branch
 
-          * Patches:
-            <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00030.html>
+            $ git clone --no-checkout ↩
+                git://git.sv.gnu.org/hurd/libpthread.git libpthread
+            $ cd libpthread/
+            $ git checkout origin/tschwinge/Peter_Herbolzheimer
 
-      * Recent releases of the 2.7 series from <ftp://ftp.gnu.org/gnu/glibc/>
-        should also be fine, but need the same set of patches as the
-        `glibc-2_7-branch` needs.
-
-<!--
-
-      * CVS `HEAD`
-
-            $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩
-              co glibc
-            $ mv libc glibc-HEAD
+  * `src/glibc`: [[GNU_C_Library|glibc]]
 
-          * TODO.
-            <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00026.html>
+      * Git `tschwinge/Roger_Whittaker` branch
 
--->
+            $ git clone --no-checkout ↩
+                git://git.sv.gnu.org/hurd/glibc.git glibc
+            $ cd glibc/
+            $ git checkout origin/tschwinge/Roger_Whittaker
 
 <!--
 
@@ -206,7 +167,7 @@ the following.
 The system you're running the script on (the *build* system) needs to have a
 basic compiling environment installed, i.e., a C compiler with the basic
 libraries and `make`.  You might also need `flex` and `bison`.  For building
-recent version of GCC (e.g., the upcoming 4.3, which is not yet supported)
+recent version of GCC (4.3 onwards)
 you'll need to have development packages of GMP and MPFR installed.
 
 
@@ -235,29 +196,13 @@ flow by.  In the end you should see a message: *[...]/cross-gnu: Everything
 should be in place now.*
 
 
-### Makefile
-
-A [[Makefile]] has been written to automate the above steps.  You will require
-an Internet connection and atleast 1.5 GiB of hard-disk space.  Just run...
-
-    make
-
-... to build the toolchain.  To clean up, use...
-
-    make clean
-
-
 ### Staying Up-To-Date
 
 You can re-run `cross-gnu` to rebuild the parts of the sources that have
 changed since the last run.  This will save a lot of time compared to starting
 from scratch again.  Also, it is especially useful if you aren't working with
-unpacked tarballs, but on CVS's branches or want to quickly get a new tool
-chain with patches you applied to the source trees.  However: do *not* use this
+unpacked tarballs, but on CVS's / SVN's / Git's branches or want to quickly get
+a new toolchain
+with patches you applied to the source trees.  However: do *not* use this
 technique when doing major changes to the source trees, like switching from GCC
-4.0 to GCC 4.1.
-
-
-# References
-
-* <http://lists.gnu.org/archive/html/bug-hurd/2004-09/msg00030.html>
+4.4 to GCC 4.5.
diff --git a/hurd/building/cross-compiling/Makefile b/hurd/building/cross-compiling/Makefile
deleted file mode 100644
index 7a6a9524..00000000
--- a/hurd/building/cross-compiling/Makefile
+++ /dev/null
@@ -1,168 +0,0 @@
-# "HurdToolchainMakefile" - a Makefile for setting up Hurd toolchain builds
-
-# Copyright (C) 2007 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2, or (at your option) any later
-# version.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-# 
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-# Written by Shakthi Kannan <shakthi.kannan@qvantel.com>.
-
-
-## Variables
-TOPDIR=.
-DOWNLOADS=${TOPDIR}/downloads
-ROOT=${TOPDIR}/root
-SRC=${ROOT}/src
-GLIBC_DIR=${SRC}/glibc
-PATCH0_DIR=patch0
-PATCH1_DIR=patch1
-
-## Patches
-PATCH1 = 0003-2007-09-13-H.J.-Lu-hongjiu.lu-intel.com.patch \
-	0005-Hurd-specific-kernel-features.h.patch \
-	0007-2007-10-05-version-of-stat.patch.patch \
-	0008-r2425-of-debian-patches-hurd-i386-local-atomic-no-mu.patch \
-	0010-r2425-of-debian-patches-hurd-i386-local-gscope.diff.patch \
-	0012-r2425-of-debian-patches-hurd-i386-local-no-strerror_.patch \
-	0013-r2626-of-debian-patches-hurd-i386-local-tls-support.patch \
-	0014-r2591-of-debian-patches-hurd-i386-local-tls.diff.patch \
-	0015-r2630-of-debian-patches-hurd-i386-submitted-libc_onc.patch \
-	0016-Include-stdint.h.patch \
-	0017-r2598-of-debian-patches-any-local-stdio-lock.diff.patch \
-	0018-r2650-of-debian-patches-hurd-i386-submitted-strtoul.patch \
-	0019-2007-11-12-Aurelien-Jarno-aurelien-aurel32.net-Tho.patch \
-	0020-r2656-of-debian-patches-any-submitted-sched_h.diff.patch \
-	0022-2007-11-18-Roland-McGrath-roland-frob.com.patch
-
-PATCH0 = 0009-2007-07-22-version-of-init-first.c_vs._GCC_4.1.patch.patch \
-	0011-2007-02-08-version-of-resolv_res_send.c.patch.patch
-
-all: create_dir get_sources apply_glibc_patches build_all
-
-## Create directories
-create_dir:
-	cd ${TOPDIR}
-	mkdir ${DOWNLOADS}
-	mkdir -p ${SRC}
-
-get_sources: get_cross_gnu get_binutils get_gcc get_gnumach get_mig get_hurd get_glibc
-
-get_cross_gnu:
-	@ echo "  ___ _ __ ___  ___ ___        __ _ _ __  _   _ "
-	@ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |"
-	@ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |"
-	@ echo " \___|_|  \___/|___/___/      \__, |_| |_|\__,_|"
-	@ echo "                              |___/             "
-	cd ${DOWNLOADS}; \
-	wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu
-	@ echo "  ___ _ __ ___  ___ ___        __ _ _ __  _   _        ___ _ ____   __" 
-	@ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |_____ / _ \ '_ \ \ / /"
-	@ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |_____|  __/ | | \ V / " 
-	@ echo " \___|_|  \___/|___/___/      \__, |_| |_|\__,_|      \___|_| |_|\_/  " 
-	@ echo "                              |___/                                   " 
-	cd ${DOWNLOADS}; \
-	wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu-env; \
-	chmod +x cross-gnu; \
-	chmod +x cross-gnu-env
-
-get_binutils:
-	@ echo " _     _             _   _ _     "
-	@ echo "| |__ (_)_ __  _   _| |_(_) |___ "
-	@ echo "| '_ \| | '_ \| | | | __| | / __|"
-	@ echo "| |_) | | | | | |_| | |_| | \__ \\"
-	@ echo "|_.__/|_|_| |_|\__,_|\__|_|_|___/"
-	cd ${SRC}; \
-	cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src co -r binutils-2_18-branch binutils; \
-	mv src binutils
-
-get_gcc:
-	@ echo "  __ _  ___ ___ "
-	@ echo " / _\` |/ __/ __|"
-	@ echo "| (_| | (_| (__ "
-	@ echo " \__, |\___\___|"
-	@ echo " |___/          "
-	cd ${SRC}; \
-	svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch; \
-	mv gcc-4_1-branch gcc; \
-	( cd gcc/ && contrib/gcc_update --touch )
-
-get_gnumach:
-	@ echo "                                        _     "
-	@ echo "  __ _ _ __  _   _ _ __ ___   __ _  ___| |__  "
-	@ echo " / _\` | '_ \| | | | '_ \` _ \ / _\` |/ __| '_ \ "
-	@ echo "| (_| | | | | |_| | | | | | | (_| | (__| | | |"
-	@ echo " \__, |_| |_|\__,_|_| |_| |_|\__,_|\___|_| |_|"
-	@ echo " |___/                                        "
-	cd ${SRC}; \
-	cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach; \
-	( cd gnumach/ && autoreconf -vfi )
-
-get_mig:
-	@ echo "           _       "
-	@ echo " _ __ ___ (_) __ _ "
-	@ echo "| '_ \` _ \| |/ _\` |"
-	@ echo "| | | | | | | (_| |"
-	@ echo "|_| |_| |_|_|\__, |"
-	@ echo "             |___/ "
-	cd ${SRC}; \
-	cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig; \
-	( cd mig/ && autoreconf -vfi )
-
-get_hurd:
-	@ echo " _                   _ "
-	@ echo "| |__  _   _ _ __ __| |"
-	@ echo "| '_ \| | | | '__/ _\` |"
-	@ echo "| | | | |_| | | | (_| |"
-	@ echo "|_| |_|\__,_|_|  \__,_|"
-	cd ${SRC}; \
-	cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd
-
-get_glibc:
-	@ echo "       _ _ _          "
-	@ echo "  __ _| (_) |__   ___ "
-	@ echo " / _\` | | | '_ \ / __|"
-	@ echo "| (_| | | | |_) | (__ "
-	@ echo " \__, |_|_|_.__/ \___|"
-	@ echo " |___/                "
-	cd ${SRC}; \
-	cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc co -r glibc-2_7-branch glibc; \
-	mv libc glibc
-	mkdir ${GLIBC_DIR}/${PATCH0_DIR}
-	mkdir ${GLIBC_DIR}/${PATCH1_DIR}
-
-get_patch0: $(PATCH0)
-
-get_patch1: $(PATCH1)
-
-$(PATCH1):
-	wget -r -np -nd -P ${GLIBC_DIR}/${PATCH1_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@ 
-	cd ${GLIBC_DIR}; \
-	patch -p1 < ${PATCH1_DIR}/$@
-
-$(PATCH0): 
-	wget -r -np -nd -P ${GLIBC_DIR}/${PATCH0_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@
-	cd ${GLIBC_DIR}; \
-	patch -p0 < ${PATCH0_DIR}/$@
-
-apply_glibc_patches: get_patch0 get_patch1
-
-build_all:
-	ROOT=${TOPDIR}/root ; \
-	export PATH="$(PATH):$(DOWNLOADS)" ; \
-	echo $$PATH ; \
-	. ${DOWNLOADS}/cross-gnu-env ; \
-	${DOWNLOADS}/cross-gnu
-
-clean:
-	rm -rf downloads root *~
diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn
new file mode 100644
index 00000000..f9aa518f
--- /dev/null
+++ b/hurd/libports.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+*libports* is a convenience library for easier handling of [[Mach
+ports|microkernel/mach/port]].  It is documented in the [[Reference_Manual]].
+
+*libports* is not (at least, not for now) a generalization / abstraction of
+Mach ports to the functionality the Hurd needs, that is, it is not meant to
+provide an interface independently of the underlying [[microkernel]].
diff --git a/hurd/logo.mdwn b/hurd/logo.mdwn
index aae80561..467e6ba8 100644
--- a/hurd/logo.mdwn
+++ b/hurd/logo.mdwn
@@ -1,25 +1,11 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with no Invariant
 Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
-The famous *Hurd Boxes* logo is available at
-<http://www.gnu.org/graphics/hurd_mf.html>.
-
-
-On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]]
-converted these four boxes from the [original METAFONT
-sources](http://www.gnu.org/graphics/hurd.mf) to
-[[hand-written_SVG_code|boxes-redrawn.svg]].
-
-[[!img boxes-redrawn.png]]
-
-
-This symbol is also being used as a favicon for this web site.
-
-[[!img /favicon.ico]]
+[[!meta redir=/logo]]
diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn
index 74c1ac8b..e58a2058 100644
--- a/hurd/running/gnu/universal_package_manager.mdwn
+++ b/hurd/running/gnu/universal_package_manager.mdwn
@@ -20,10 +20,10 @@ Basically all package management schemes follow similar approach, it will have a
 
 There can be both aproaches
 
-   * Re-implement rpm, dpkg... to recognise stow as backend instead of its own  data store. In that case we will have to re implement, apt-rpm, yum ... 
-   * Implement a translator which reads stow and show it as an rpm data store  for yum, deb data store for apt-get ...
+   * Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re-implement, apt-rpm, yum ... 
+   * Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ...
 
-One goal is obviously choice of packaging and hence availability of more  packages. Also this gives maintainers a chioce to continue builing packages  for GNU in the format they are already familiar with. The second goal is to  demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface).
+One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a choice to continue building packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface).
 
 ## Why?
 
@@ -40,7 +40,7 @@ With the increased flexibility in implementing filesystems as per the requiremen
 
 ## How?
 
-   * Installtion of a package is just drag the pacakage (be it a tgz, rpm, deb or an exe) and drop it to the package manager.
+   * Installation of a package is just drag the package (be it a tgz, rpm, deb or an exe) and drop it to the package manager.
 
       * apt-cache search vim --> ls -al /packages/meta/ |grep vim
       * apt-get install vim --> install vim 
@@ -77,12 +77,12 @@ just writing the new translator.
 
 ## Initial idea 
 
-A bit complex than the earlier scheme but it is more exciting and we can look at this schem seriously once we have the simple scheme working.
+A bit more complex than the earlier scheme but it is more exciting and we can look at this scheme seriously once we have the simple scheme working.
 
 All packages are installed at
 `/packages/binary/<packagename>/<packageversion>`.
 
-For eaxmple  vim 6.4 version can be installed from source like
+For example vim 6.4 version can be installed from source like
 
     # cd vim64
     # ./configure --prefix=/packages/binary/vim/6.4
@@ -99,7 +99,7 @@ Now if you have another vim version, say 7.0  then just follow the steps
     # make
     # make install
 
-You have 2 versions of vim and how can you sepcify which one is the current version? You can symlink the current version to select the version you would like to see as default
+You have 2 versions of vim and how can you specify which one is the current version? You can symlink the current version to select the version you would like to see as default
 
     # ln -s /packages/binary/vim/7.0 /packages/vim/current
 
@@ -141,7 +141,7 @@ v. Add your name below and give a shout in the list.
 
 Add your comments here
 
-## Interesting?
+## Interested?
 
 To join the project just list your name below.
 
diff --git a/ikiwiki.setup b/ikiwiki.setup
index 108078f5..c98d04b6 100644
--- a/ikiwiki.setup
+++ b/ikiwiki.setup
@@ -38,8 +38,9 @@ IkiWiki::Setup::Standard->import({
 	# users who are wiki admins
 	adminuser => [qw{tschwinge}],
 	# users who are banned from the wiki
-	banned_users => [qw{AlbertF bernhart ColetCris
-			    http://calvinyoung.myopenid.com/}],
+	banned_users => [qw{AlbertF bernhart ColetCris flamberian
+			    http://calvinyoung.myopenid.com/
+			    http://hilarybunton.myopenid.com/}],
 	# where the source of the wiki is located
 	srcdir => $srcdir,
 	# where to build the wiki
diff --git a/index.mdwn b/index.mdwn
index fa7a3af1..694bd3cd 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -25,18 +25,12 @@ kernels (such as Linux).
 for the GNU operating system, which is viable for everyday use, 
 and gives users and programs as much control over their 
 computing environment as possible.
-<em>[[Our mission explained|community/weblogs/antrik/hurd-mission-statement]].</em></p>
+<em>[[Our_mission_explained|community/weblogs/antrik/hurd-mission-statement]].</em></p>
 </div>
 </div>
 
 ---
 
-[[!template id=note text="""**Breaking News**
-
-The *[[Google Summer of Code|community/gsoc]]* is on!  If you're a student,
-consider applying for a GNU/Hurd project."""]]
-
-
 [[!toc]]
 
 
@@ -73,8 +67,9 @@ To help the Hurd you can for example (from high level stuff to the inner core)
 * Work on the [[Hurd_on_Mach|contributing#hurd_on_mach]], or
 * Help to port the Hurd [[to_a_modern_microkernel|contributing#hurd_on_modern_microkernel]].
 
-Read about ways to contribute [[in_more_detail|contributing]].
+See our [[source_repositories]] for the source code.
 
+Read about ways to contribute [[in_more_detail|contributing]].
 
 ## Getting Help
 
diff --git a/irc.mdwn b/irc.mdwn
index 14340bb2..036ce361 100644
--- a/irc.mdwn
+++ b/irc.mdwn
@@ -53,7 +53,7 @@ to always greet the channel when you enter and before leave.
 Starting in early 2008, there have been regular IRC meetings held between the
 (now former) [[community/GSoC]] students and their mentors.  These continue to
 take place even that the [[Google_Summer_of_Code_2008|community/gsoc/2008]] is
-over, and still take place, currently **every Wednesday at 11:00 UTC in the `#hurd`
+over, and still take place, currently **every Wednesday at 10:00 UTC in the `#hurd`
 channel**.  Of course, the meetings are not only for (former) GSoC students and
 mentors, but open to any interested party.  So, everyone, take your chance to
 chat with GNU Hurd developers!
diff --git a/logo.mdwn b/logo.mdwn
new file mode 100644
index 00000000..aae80561
--- /dev/null
+++ b/logo.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+The famous *Hurd Boxes* logo is available at
+<http://www.gnu.org/graphics/hurd_mf.html>.
+
+
+On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]]
+converted these four boxes from the [original METAFONT
+sources](http://www.gnu.org/graphics/hurd.mf) to
+[[hand-written_SVG_code|boxes-redrawn.svg]].
+
+[[!img boxes-redrawn.png]]
+
+
+This symbol is also being used as a favicon for this web site.
+
+[[!img /favicon.ico]]
diff --git a/hurd/logo/boxes-redrawn.png b/logo/boxes-redrawn.png
index fd26a87e..fd26a87e 100644
--- a/hurd/logo/boxes-redrawn.png
+++ b/logo/boxes-redrawn.png
diff --git a/hurd/logo/boxes-redrawn.svg b/logo/boxes-redrawn.svg
index c0a7e460..c0a7e460 100644
--- a/hurd/logo/boxes-redrawn.svg
+++ b/logo/boxes-redrawn.svg
diff --git a/news/2010-03-31.mdwn b/news/2010-03-31.mdwn
new file mode 100644
index 00000000..c3c424d1
--- /dev/null
+++ b/news/2010-03-31.mdwn
@@ -0,0 +1,48 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta date="2010-04-01 07:55 UTC"]]
+
+A month of the Hurd: some more *bug squashing* and *Google Summer of Code 2010*.
+[[!if test="included()" then="""[[!toggle id=full_news
+text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
+else="[[!paste id=full_news]]"]]
+
+[[!cut id="full_news" text="""
+
+> This month saw bugs dying as they met hackers like [Jérémie,
+> Samuel](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00027.html), or
+> [Zheng,
+> Thomas](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00051.html), or
+> [Jakub](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00071.html)
+> (keeping it to a few ones which were discussed on the [[bug-hurd mailing
+> list|mailing_lists/bug-hurd]]).
+
+> Olaf, Thomas and Fredrik
+> [wrote](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00022.html) and
+> submitted our [[community/gsoc/organization_application]] for the Google
+> Summer of Code 2010.  However, Google is [asking most GNU projects to work
+> under the GNU project
+> umbrella](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00125.html),
+> so we aren't listed as an organization on our own, but instead will again
+> participate as a subproject of GNU.
+
+> Anyway, this organizational detail is not at all important for interested
+> students; you can apply for any of the ideas that are listed on our
+> [[community/gsoc/project_ideas]] page (or come up with your own ideas, of
+> course!) via the [GNU project GSoC
+> page](http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gnuproject). If
+> you apply, please also include the information we're asking for on our
+> [[community/gsoc/student_application_form]].  Don't hesitate to
+> [[contact_us]] beforehand, if there are any questions.  We're looking forward
+> to seeing your applications, please send them in [before
+> 2010-04-09](http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline)!
+
+"""]]
diff --git a/open_issues/gcc/c++.mdwn b/open_issues/gcc/c++.mdwn
deleted file mode 100644
index cab4c1f1..00000000
--- a/open_issues/gcc/c++.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!tag open_issue_porting open_issue_gcc fixed_in_debian]]
-
-Modify the [[hurd/building/cross-compiling]] shell script to configure GCC for
-building GCC with C++ support when building its second (i.e., final) version.
-
-Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the
-resulting binaries would also work), but linking fails with GCC SVN trunk:
-
-    $ $TARGET-g++ -Wall a.cc -lpthread
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2'
-    /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2'
-    collect2: ld returned 1 exit status
-
-Whether this defect report also applies to a natively-build GCC from SVN trunk
-has not yet been checked.
-
-[[Thomas_Schwinge|tschwinge]] suspects the problem to be a configuration issue
-of a GCC helper library, whose configuration setup has changed after GCC 4.3.
-
-The need for `-lpthread` is another story.  See the Debian glibc patches
-repository for details.
diff --git a/open_issues/glibc_testsuite.mdwn b/open_issues/glibc_testsuite.mdwn
new file mode 100644
index 00000000..4cceb241
--- /dev/null
+++ b/open_issues/glibc_testsuite.mdwn
@@ -0,0 +1,105 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_glibc]]
+
+`configure --without-cvs --prefix= --disable-profile --build=i486-gnu
+--host=i486-gnu`
+
+`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to
+c9fd33ef070def49c078c94f8d9bc9f8a8e267f7.
+
+Configured with `--prefix=/usr` instead of `--prefix=`.
+
+Resolved failures:
+
+  * localedata/tst_mblen.out
+  * localedata/tst_mbrlen.out
+  * localedata/tst_mbrtowc.out
+  * localedata/tst_mbsrtowcs.out
+  * localedata/tst_mbstowcs.out
+  * localedata/tst_mbtowc.out
+  * localedata/tst_swscanf.out
+  * localedata/tst_wcrtomb.out
+  * localedata/tst_wcsrtombs.out
+  * localedata/tst_wcstombs.out
+  * localedata/tst_wctob.out
+  * localedata/tst_wctomb.out
+  * localedata/bug-iconv-trans.out
+  * localedata/tst-wctype.out
+  * math/test-float.out
+  * math/test-double.out
+  * posix/tst-vfork3-mem
+  * io/tst-mkdirat.out
+
+New:
+
+  * A lot of `error while loading shared libraries: libmachuser.so.1: cannot
+    open shared object file: No such file or directory`.  Is it perhaps picking
+    that library up from `$prefix/lib/`?
+
+    New failures; likely due to that:
+
+      * iconvdata/iconv-test.out
+      * iconvdata/tst-tables.out
+      * malloc/tst-mtrace.out
+      * grp/tst_fgetgrent.out
+      * posix/globtest.out
+      * posix/wordexp-tst.out
+      * io/ftwtest.out
+      * elf/tst-pathopt.out
+
+    Changed failures; likely due to that:
+
+      * debug/tst-chk4.out / debug/tst-chk5.out
+
+            -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
+            +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory
+
+---
+
+Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting.
+
+---
+
+Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting.
+
+New failures:
+
+  * posix/bug-glob3.out (SEGFAULT; but also on Linux)
+  * wctype/bug-wctypeh.o (compile error; but also on Linux)
+
+Other things noticed:
+
+  * Running `make -k check` for the second time:
+
+        -i486-gnu-gcc tst-timer2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2     -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I.  -D_LIBC_REENTRANT -include ../include/libc-symbols.h   -DNOT_IN_libc=1    -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o
+        -tst-timer2.c: In function ‘do_test’:
+        -tst-timer2.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function)
+        -tst-timer2.c:33: error: (Each undeclared identifier is reported only once
+        -tst-timer2.c:33: error: for each function it appears in.)
+        -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o] Error 1
+        +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
+        +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
+        +make[2]: *** [/usr/include/pthread.h] Error 1
+
+        -i486-gnu-gcc tst-thrlock.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2     -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I.  -D_LIBC_REENTRANT -include ../include/libc-symbols.h   -DNOT_IN_libc=1    -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o
+        -i486-gnu-gcc -nostdlib -nostartfiles -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock  -Wl,-dynamic-linker=/usr/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crt1.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crti.o `i486-gnu-gcc  --print-file-name=crtbegin.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn/libdl.so.2  -Wl,-rpath-link=/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/math:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nss:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nis:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/resolv:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/crypt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc.so.0.3 /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed `i486-gnu-gcc  --print-file-name=crtend.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crtn.o
+        -/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o: In function `do_test':
+        -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:38: undefined reference to `pthread_create'
+        -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:48: undefined reference to `pthread_join'
+        -collect2: ld returned 1 exit status
+        -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock] Error 1
+        +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
+        +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
+        +make[2]: *** [/usr/include/pthread.h] Error 1
+
+  * Not all tests are re-run in a `make -k tests; make tests-clean; make -k
+    tests` cycle.
diff --git a/public_hurd_boxen/installation/snubber.mdwn b/public_hurd_boxen/installation/snubber.mdwn
index f9542a9f..dbbade9f 100644
--- a/public_hurd_boxen/installation/snubber.mdwn
+++ b/public_hurd_boxen/installation/snubber.mdwn
@@ -30,6 +30,24 @@ License|/fdl]]."]]"""]]
     $ mkdir tmp/backup && chmod 0733 tmp/backup
 
 
+# `/var/www/robots.txt`
+
+This file used to contain:
+
+    User-agent: *
+    Disallow: /gitweb/
+    Disallow: /cgi-bin/
+
+... which I've now changed to:
+
+    User-agent: *
+    Disallow: /
+
+The goal is that robots rather index the official pages,
+<http://www.gnu.org/software/hurd/>, instead of the staging area on
+<http://www.bddebian.com:8888/~hurd-web/>.
+
+
 # Restore Backup
 
 ## `/etc/apache2/mods-enabled/`
diff --git a/sidebar.mdwn b/sidebar.mdwn
index 7d71cd28..159104fc 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -9,8 +9,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
-Welcome to...  [[!img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU
-Hurd!
+Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd!
 
   * **[[Home|/index]]**
   * **[[Community]]**
diff --git a/user/flaviocruz.mdwn b/user/flaviocruz.mdwn
index f3a67afd..c4d3db69 100644
--- a/user/flaviocruz.mdwn
+++ b/user/flaviocruz.mdwn
@@ -14,9 +14,7 @@ Email: flaviocruz at gmail dot com
 
 Some [Hurd stuff](http://opensvn.csie.org/leic/hurd/)
 
-And code: [cl-hurd](http://freehg.org/u/flavioc/cl-hurd/)
-
-hg clone [http://freehg.org/u/flavioc/cl-hurd/](http://freehg.org/u/flavioc/cl-hurd/)
+And code: [cl-hurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=clisp)
 
 ## Summer session