Merge branch 'master' of git.savannah.gnu.org:/srv/git/hurd/web

27 files changed, 571 insertions, 64 deletions

diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn
index efd29841..81a0740b 100644
--- a/community/gsoc.mdwn
+++ b/community/gsoc.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -15,6 +15,12 @@ We're in!  The GNU Hurd project is again participating in the [Google Summer of
 Code](http://www.google-melange.com/) under the [GNU
 umbrella](http://www.gnu.org/software/soc-projects/).
 
+As of Monday, 2013-04-22 it's the *student application period*.  This will last
+until [Friday,
+2013-05-03](http://www.google-melange.com/gsoc/events/google/gsoc2013), which
+is plenty of time for preparing and discussing your applications -- but please
+don't wait to the last minute!
+
 <!--
 
 This year's *student application period* is over.  Thanks for sending in your
@@ -22,6 +28,8 @@ applications!  We're now reviewing and discussing these, so please pay
 attention to any questions posted on your proposal's page.  The Google site's
 notification system should be sending out emails, too.
 
+-->
+
 As we only have finite resources (meaning that we won't be able to accept all
 GNU Hurd applications even if we wanted to), we will eventually need to make a
 choice about whom to select.  For this, it is a very good idea to be in contact
@@ -48,7 +56,11 @@ how to do `X`, can someone please help me?*  And, as we're not working next to
 each other in a conventional office or university setup, we'll need to
 establish and get used to different communication channels.
 
-[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2011).  As
+[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013).
+
+<!--
+
+As
 boring as it is, but the next step is waiting: we will have to wait for Google
 to announce the number of slots that the whole GNU project gets, and we'll be
 discussing with our GNU peers about how to split these up among all the GNU
@@ -57,26 +69,6 @@ subprojects.
 -->
 
 
-Applications for 2012 are closed.
-
-# Accepted projects
-
-## Disk I/O Performance Tuning
-
-by Maksym Planeta
-
-See the project's
-[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002).
-
-## Virtualization Using Hurd Mechanisms
-
-by Pierre Thierry
-
-See the project's
-[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001)
-and [[complete proposal|gsoc/2012/virt/proposal]].
-
-
 # Possible projects
 
 We have a list of [[project_ideas]], and students are likewise encouraged to
@@ -105,6 +97,6 @@ if you aren't a student anyway.
 In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU
 project, getting one slot each year.  In the following year, we successfully
 participated on our own, instead of as a suborganization of the GNU project.
-Read about our five students' success on the [[2008]] page.  The next two year,
-we participated under the GNU umbrella with one slot in [[2009]], three in
-[[2010]], and one again in [[2011]].
+Read about our five students' success on the [[2008]] page.  In the next years,
+we again participated under the GNU umbrella with one slot in [[2009]], three
+in [[2010]], one in [[2011]], and two in [[2012]].
diff --git a/community/gsoc/2012.mdwn b/community/gsoc/2012.mdwn
new file mode 100644
index 00000000..3bb6dd7e
--- /dev/null
+++ b/community/gsoc/2012.mdwn
@@ -0,0 +1,32 @@
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 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 GNU Hurd project has again been participating in the [Google Summer of
+Code](http://www.google-melange.com/) under the [GNU
+umbrella](http://www.gnu.org/software/soc-projects/).
+
+
+# Accepted projects
+
+## Disk I/O Performance Tuning
+
+by Maksym Planeta
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002).
+
+## Virtualization Using Hurd Mechanisms
+
+by Pierre Thierry
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001)
+and [[complete proposal|virt/proposal]].
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 10270612..8d4c609b 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -75,7 +75,9 @@ before the end of the application process, with our help -- contact us, and we
 will assist you as well as we can.
 
 See also the list of [Hurd-related X.Org project
-ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting).
+ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting), and [Debian GNU/Hurd
+Debianish
+initialization](http://wiki.debian.org/SummerOfCode2013/Projects#Debian_GNU.2FHurd_Debianish_initialization).
 
 <!-- Olaf, wouldn't it make sense to put the following tasks next to each
 other: language_bindings, gnat, gccgo, perl_python.  -->
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn
index a60a8038..694effca 100644
--- a/community/gsoc/project_ideas/mtab.mdwn
+++ b/community/gsoc/project_ideas/mtab.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2013 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]]."]]"""]]
 
 [[!meta title="mtab"]]
 
@@ -72,3 +73,89 @@ Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
 Exercise: Make some improvement to any of the existing Hurd translators.
 Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often
 quite rudimentary, and it shouldn't be hard to find something to improve.
+
+
+# Related Discussion
+
+## IRC, freenode, #hurd, 2013-04-17
+
+    <kuldeepdhaka> thinking how to get the listing. traversing would be
+      ineffecient,   trying to come up with something better
+    <braunr> what listing ?
+    <braunr> and traversing what ?
+    <kuldeepdhaka> mtab
+    <braunr> well i assumed so
+    <braunr> be more precise please
+    <kuldeepdhaka> when the translator is done initalized      <translation
+      info> are written to /etc/mtab      <translation info> will be provided
+      by the translator, and when some one want to read the info just read it
+      this way if their is some credentials like ftp sites pass username can be
+      masked by the translator
+    <kuldeepdhaka> if some trans dont want to list them, no need to write to
+      file    | while unmounting (sorry i couldnt find the right word) , it
+      will pass the mount node address | <translation info> will have special
+      structure to remove/add mounts example "a /mount-to /mount-from" = add
+      , "r /mount-to" = remove    here "/mount-to" will be unique for every
+      mount
+    <kuldeepdhaka> this have a draw back , we would have to trust trans for the
+      listed data  | also "/mount-to" + "/mount-from" could be used a
+      combination for making sure that other trans unable remove others trans
+      mount data
+    <kuldeepdhaka> sorry but "also "/mount-to" + "/mount-from" could be used a
+      combination for making sure that other trans unable remove others trans
+      mount data"  this is a bad idea if we had to print the whole thing
+    <kuldeepdhaka> braunr, whats ur opinion?
+    <pinotree> you don't need a mtab to "unmount" things on hurd
+    <braunr> kuldeepdhaka: hum, have you read the project idea ?
+    <braunr>
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/
+    <braunr> A more promising approach is to have mtab exported by a special
+      translator, which gathers the necessary information on demand. This could
+      work by traversing the tree of translators, asking each one for mount
+      points attached to it.
+    <kuldeepdhaka> pinotree, not to unmount, i mean is to remove the
+      <translation data>
+    <braunr> for a first implementation, i'd suggest a recursive traversal of
+      root-owned translators
+    <kuldeepdhaka> braunr, hum, but it did stated it as inefficient
+    <braunr> where ?
+    <kuldeepdhaka> para 5 , line 3
+    <kuldeepdhaka> and line 6
+    <braunr> no
+    <braunr> traversing "all" nodes would be inefficient
+    <braunr> translators which host the nodes of other translators could
+      maintain a simple list of active translators
+    <braunr> ext2fs, e.g. (if that's not already the case) could keep the list
+      of the translators it started
+    <braunr> we can already see that list with pstree for example
+    <braunr> but this new list would only retain those relevant for mtab
+    <braunr> i.e. root-owned ones
+    <pinotree> i would not limit to those though
+    <braunr> and then filter on their type (e.g. file system ones)
+    <braunr> pinotree: why ?
+    <pinotree> this way you could have proper per-user /proc/$pid/mounts info
+    <braunr> we could also very easily have a denial of service
+    <kuldeepdhaka> but how will the mount point and source point will be
+      listed?
+    <braunr> they're returned by the translator
+    <kuldeepdhaka> k
+    <braunr> you ask /, it returns its store and its options, and asks its
+      children recursively 
+    <braunr> a /home translator would return its store and its options
+    <braunr> etc..
+    <braunr> each translator would build the complete path before returning it
+    <braunr> sort of, it's very basic
+    <braunr> but that would be a very hurdish way to do it
+    <kuldeepdhaka> shall /etc/mtab should be made seek-able and what should be
+      the filesize?  content are generated on demand so, it could arise problem
+      (fsize:0 , seek-able:no), ur opinions?
+    <braunr> kuldeepdhaka: it should have all the properties of a regular file
+    <braunr> the filesize would be determined after it's generated
+    <braunr> being empty doesn't imply it's not seekable
+    <kuldeepdhaka> content is generated on demand so, could cause problem while
+      seeking and filesize, shall i still program as regular file?
+    <kuldeepdhaka> in two different read, it could generate different content,
+      though same seek pos is used...
+    <braunr> what ?
+    <braunr> the content is generated on open
+    <kuldeepdhaka> ooh, ok
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index a89b40b1..20faed5e 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -137,6 +137,13 @@ small backend stores, like floppy devices.
     <youpi> ah, there is the same parameter on diskfs_start_disk_pager
 
 
+##### IRC, freenode, #hurd, 2013-04-23
+
+    <braunr> and i'm working again on the ext2fs large store patch
+    <braunr> i finished separating the libpager interface change from the rest,
+      as Thomas suggested, so a new version should be ready soon
+
+
 #### `EXT2FS_DEBUG`
 
 ##### IRC, freenode, #hurd, 2013-03-04
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 3232e0cc..9bcf62ef 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -30,6 +30,8 @@ implementation.
 
 # Reimplementation, [[!GNU_Savannah_task 5469]]
 
+## [[community/gsoc/project_ideas/tcp_ip_stack]]
+
 ## IRC, freenode, #hurd, 2013-04-03
 
 [[!tag open_issue_hurd]]
diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn
index 00e4a012..ee9f059a 100644
--- a/microkernel/mach/rpc/discussion.mdwn
+++ b/microkernel/mach/rpc/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -10,8 +10,12 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation]]
 
+[[!toc]]
 
-# IRC, freenode, #hurd, 2011-06-11
+
+# Mach initiating RPCs to userspace tasks
+
+## IRC, freenode, #hurd, 2011-06-11
 
     <antrik> I don't think we have a precendence case of Mach initiating RPCs
       to userspace tasks
@@ -115,3 +119,32 @@ License|/fdl]]."]]"""]]
     <braunr> right, i really need to read about mig again
     <antrik> it's pretty normal for a translator to both implement and use an
       interface
+
+
+# `MACH_SEND_INTERRUPT`/`MACH_RCV_INTERRUPT`
+
+[[!tag open_issue_glibc open_issue_gnumach]]
+
+
+## IRC, freenode, #hurd, 2013-03-22
+
+    <braunr> i'm also testing glibc packages on darnassus with a patch that
+      removes the MACH_{SEND,RCV}_INTERRUPT options from mach_msg calls to
+      avoid taking the slow path because of them
+    <braunr> if i got it right, almost every mach_msg call doesn't use any of
+      these options, except for select
+    <braunr> it could slightly improve that, i'm not sure
+    <youpi> but don't we need that to get EINTR ?
+    <braunr> the options are purely userspace
+    <braunr> i'll upload the patch
+    <braunr>
+      http://www.sceen.net/~rbraun/0001-Mask-options-implemented-by-the-userspace-side-of-ma.patch
+    <youpi> ah, ok, you mean userspace already implements what we need
+
+
+## IRC, freenode, #hurd, 2013-04-23
+
+    <braunr> i couldn't measure any difference with the glibc patch that
+      removes the mach_msg interrupt related flags
+    <braunr> which isn't very surprising as it only concerns select as far as i
+      can tell
diff --git a/news/2013-04-23.mdwn b/news/2013-04-23.mdwn
new file mode 100644
index 00000000..e5730917
--- /dev/null
+++ b/news/2013-04-23.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2013 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="2013-04-23 11:00 UTC"]]
+
+The **Google Summer of Code 2013** is on!  If you're a student, consider
+applying for a GNU Hurd project -- details to be found on our
+*[[community/GSoC]] page*.
diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn
index 8ed69345..f1811b27 100644
--- a/open_issues/address_space_memory_mapping_entries.mdwn
+++ b/open_issues/address_space_memory_mapping_entries.mdwn
@@ -18,4 +18,5 @@ IRC, freenode, #hurd, 2011-05-07
     <braunr> a bare linked list
     <braunr> which makes faults and page cache lookups even slower
 
-A red-black tree was added to VM maps to speed up lookups.
+A [[red-black tree|gnumach_vm_map_red-black_trees]] was added to VM maps to
+speed up lookups.
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 757ebbe9..5d36d3d1 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -33,14 +33,14 @@ though, as explained below.
 <!--
 
 git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..sourceware/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
 -i
-/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:
+/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5
-(2013-02-08) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 5c3ec1ded654250e0ac27df79998b32b2403e81f
+(2013-04-29) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -126,7 +126,7 @@ Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5
 
 Here's a log of a binutils build run; this is from our [[Git
 repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch,
-commit 944a6010b676b9f80f0a16c65183102b187822c5 (2013-02-08), run on
+commit 5c3ec1ded654250e0ac27df79998b32b2403e81f (2013-04-29), run on
 kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -140,8 +140,8 @@ harmonized.  Debian GCC (which is used in binutils' testsuite) likes to pass
 `--sysroot=/` to `ld`, so we need to configure binutils with support for
 sysroots.
 
-This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and
-42 min on coulomb.SCHWINGE.
+This takes up around 950 MiB, and needs roughly 13 min on kepler.SCHWINGE and
+45 min on coulomb.SCHWINGE.
 
 <!--
 
@@ -165,6 +165,12 @@ formats, and more emulation vectors.
 
     Missing [[IFUNC]] support on GNU/Hurd.
 
+  * 944a6010b676b9f80f0a16c65183102b187822c5..a5e5fda5f96d5b881a354bd8666fdbb1496ee8da:
+
+         gcc-4.6 -c -DHAVE_CONFIG_H -g -O2  -I. -I../../Paul_Desmond/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../Paul_Desmond/libiberty/hashtab.c -o hashtab.o
+        +../../Paul_Desmond/libiberty/hashtab.c: In function 'hash_pointer':
+        +../../Paul_Desmond/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default]
+
 
 # Install
 
@@ -187,7 +193,7 @@ min on coulomb.SCHWINGE.
     $ make -k check 2>&1 | tee log_test
     [...]
 
-This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.
+This needs roughly 6 min on kepler.SCHWINGE and 45 min on coulomb.SCHWINGE.
 
 
 ## Analysis
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 5ba6b418..98454d45 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -15,7 +15,7 @@ License|/fdl]]."]]"""]]
 Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
 
 It could be a mere matter of extending the
-[[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]:
+[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]:
 add it to
 `mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
 make `clock_gettime` use it.
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index f0f7cae0..65d84886 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -394,7 +394,7 @@ After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
     <youpi> so ZhengDa preferred to make jiffies a macro which calls a function
       which reads the mapped time
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <youpi> however, that break any use of the work "jiffies", e.g. structure
       members & such
diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn
index e9fbf0f1..fb94cb83 100644
--- a/open_issues/gccgo.mdwn
+++ b/open_issues/gccgo.mdwn
@@ -38,6 +38,61 @@ been working on this, has some (unpublished) patches, and this is currently
 blocked on [[`getcontext`/`setcontext`|open_issues/glibc/t/tls-threadvar]].
 
 
+## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
+
+In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
+f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
+
+The check in `libgo/configure.ac` *whether setcontext clobbers TLS variables*
+is invalid on GNU Hurd.
+
+The `*context` functions are used in `libgo/runtime/go-signal.c` and
+`libgo/runtime/proc.c`.
+
+`__splitstack_getcontext`, `__splitstack_setcontext`,
+`__splitstack_makecontext`, `__splitstack_resetcontext`,
+`__splitstack_block_signals_context` are to be provided by libgcc.  However, in
+said libgo runtime files, they're used only `#ifdef USING_SPLIT_STACK`.
+[[I|ŧschwinge]] would assume that before we can enable split stacks, first
+[[open_issues/glibc/t/tls-threadvar]] needs to be fixed.
+
+In `libgo/runtime/proc.c`:`runtime_gogo`, `setcontext` is used to *switch
+context to a different goroutine*.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_mcall`, which *save[s] context and call[s]
+fn passing g as a parameter*, `getcontext` and `setcontext` are used; this is
+only called from `libgo/runtime/proc.c`:`runtime_gosched`.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_tracebackothers`, `getcontext` is used to
+*switch context to the goroutine*.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_mstart`, which is *called to start an M*,
+`getcontext` is used.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_entersyscall`, which is called when *the
+goroutine g is about to enter a system call*, `getcontext` is used to *save the
+registers in the g structure so that any pointers held in registers will be
+seen by the garbage collector*.  Should be fine.
+
+In `libgo/runtime/proc.c`:`__go_go`, `getcontext` and `makecontext` are used.
+TODO.
+
+In `libgo/runtime/thread.c`:`runtime_minit`, which is *[c]alled to initialize a
+new m (including the bootstrap m)*, `ss.ss_sp` is set to a new stack retrieved
+via `libgo/runtime/proc.c:runtime_malg`, which *allocate[s] a new g, with a
+stack [...]*, and then `sigaltstack` is called.  TODO.
+
+    libgo/runtime/go-signal.c:  /* We are now running on the stack registered via sigaltstack.
+    libgo/runtime/go-signal.c:     and sigaltstack when the program starts.)  */
+    
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp = vsp;
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp += vspsize;
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_size = vspsize;
+
+Also, in `libgo/runtime/proc.c`:`runtime_newm`, `pthread_attr_setstacksize` is
+used, which we also can't support yet, for the same reason.
+
+
 ---
 
 
diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn
index 6b9cd135..eddc2fdc 100644
--- a/open_issues/gdb.mdwn
+++ b/open_issues/gdb.mdwn
@@ -27,14 +27,14 @@ Here's what's to be done for maintaining GNU GDB.
 <!--
 
 git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..sourceware/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
 -i
-/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:|gnu-nat|i386gnu
+/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b
-(2013-03-13) sources|source_repositories/gdb]].
+Last reviewed up to the [[Git mirror's 6330ab576e18fb97912839fc116c7babb5fd8c70
+(2013-04-28) sources|source_repositories/gdb]].
 
   * Globally
 
@@ -71,7 +71,7 @@ Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b
 
 Here's a log of a GDB build run; this is from our [[Git
 repository|source_repositories/gdb]]'s `tschwinge/Ferry_Tagscherer` branch,
-commit 6b25dae901ddedb3f330803542d3eac73cdcae4b (2013-03-13), run on
+commit 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28), run on
 kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -194,6 +194,12 @@ formats and more emulation vectors.
         +                 from ../../Ferry_Tagscherer/gdb/gnu-nat.c:56:
         +../../Ferry_Tagscherer/gdb/value.h:729:22: note: expected 'const char **' but argument is of type 'char **'
 
+  * 6b25dae901ddedb3f330803542d3eac73cdcae4b..6330ab576e18fb97912839fc116c7babb5fd8c70:
+
+         gcc-4.7 -c -DHAVE_CONFIG_H -g -O2  -I. -I../../Ferry_Tagscherer/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../Ferry_Tagscherer/libiberty/hashtab.c -o hashtab.o
+        +../../Ferry_Tagscherer/libiberty/hashtab.c: In function 'hash_pointer':
+        +../../Ferry_Tagscherer/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default]
+
 
 # Install
 
@@ -363,4 +369,15 @@ GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown
 
         *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all"
 
+  * `gdb.arch/i386-float.exp: info float`
+
+        Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.arch/i386-float.exp ...
+        PASS: gdb.arch/i386-float.exp: first stepi
+        FAIL: gdb.arch/i386-float.exp: info float
+        PASS: gdb.arch/i386-float.exp: second stepi
+        PASS: gdb.arch/i386-float.exp: info float
+
+    Only fails for GNU/Hurd: the floating point stack initially is not
+    all-zeroes, which is expected, and which it is on GNU/Linux.
+
 TODO.
diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn
index 8f1b7b48..b9114b69 100644
--- a/open_issues/gdb_attach.mdwn
+++ b/open_issues/gdb_attach.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -54,3 +54,30 @@ License|/fdl]]."]]"""]]
       process
     <tschwinge> That is supposed to work.
     <tschwinge> If the permission match.
+
+
+# `gdb --pid [PID]`
+
+That is, not explicitly specifying an `executable-file`.
+
+
+## IRC, OFTC, debian-hurd, 2013-04-15
+
+    <paravoid> I don't seem to be able to run gdb
+    <paravoid> that happened on the buildd and happens on exodar too
+    <paravoid> #0  0x010c07cc in ?? ()
+    <paravoid> #1  0x010c1078 in ?? ()
+    <paravoid> #2  0x0109eabf in ?? ()
+    <paravoid> [...]
+    <paravoid> Backtrace stopped: previous frame inner to this frame (corrupt
+      stack?)
+    <paravoid> that's pid 24235 on exodar
+    <paravoid> I did gdb -p 24235 and then bt
+    <paravoid> just the output above
+    <youpi> I don't know about gdb -p
+    <youpi> I usually run gdb
+      /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin
+      24235
+    <paravoid> okay, that indeed works 
+    <youpi> I guess the support for finding out the binary automatically wasn't
+      done yet on hurd
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index a8892876..ceb5ea21 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.mdwn
@@ -25,4 +25,6 @@ In context of [[packaging_libpthread]]/[[libpthread]].
       the exec server IIRC...
     <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
       reminding!
-    <tschwinge> pochu: Won't happen today or tomorrow, but "sometime".
+
+[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
+"4BFA500A.7030502@gmail.com"]].
diff --git a/open_issues/gnat.mdwn b/open_issues/gnat.mdwn
index 0f404b8a..84e8f60b 100644
--- a/open_issues/gnat.mdwn
+++ b/open_issues/gnat.mdwn
@@ -103,6 +103,55 @@ know if the port has yet seen any real-world usage, such as using it for any
 bigger Ada code bases, or any Ada testsuites.
 
 
+## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
+
+In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
+f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
+
+    gcc/ada/init.c:  sigaltstack (&stack, NULL);
+    gcc/ada/init.c:      sigaltstack (&stack, NULL);
+    gcc/ada/init.c:  sigaltstack (&stack, NULL);
+    gcc/ada/s-osinte-aix.ads:   function sigaltstack
+    gcc/ada/s-osinte-aix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-android.ads:   function sigaltstack
+    gcc/ada/s-osinte-android.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-darwin.ads:   function sigaltstack
+    gcc/ada/s-osinte-darwin.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-freebsd.ads:   function sigaltstack
+    gcc/ada/s-osinte-freebsd.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-hpux.ads:   function sigaltstack
+    gcc/ada/s-osinte-hpux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:   function sigaltstack
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-linux.ads:   function sigaltstack
+    gcc/ada/s-osinte-linux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-rtems.adb:   -- sigaltstack --
+    gcc/ada/s-osinte-rtems.adb:   function sigaltstack
+    gcc/ada/s-osinte-rtems.adb:   end sigaltstack;
+    gcc/ada/s-osinte-rtems.ads:   function sigaltstack
+    gcc/ada/s-osinte-solaris-posix.ads:   function sigaltstack
+    gcc/ada/s-osinte-solaris-posix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-taprop-linux.adb:            Result := sigaltstack (Stack'Access, null);
+    gcc/ada/s-taprop-posix.adb:            Result := sigaltstack (Stack'Access, null);
+    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/init.c:      stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/s-osinte-aix.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-android.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-darwin.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-darwin.ads:      uc_stack    : stack_t;          --  Stack Used By This Context
+    gcc/ada/s-osinte-freebsd.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-hpux.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-linux.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-rtems.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-solaris-posix.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-solaris.ads:      ss_sp        : System.Address;
+    gcc/ada/s-osinte-solaris.ads:      uc_stack     : record_type_2;
+    gcc/ada/s-taprop-linux.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
+    gcc/ada/s-taprop-posix.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
+
+
 ---
 
 
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index 46454207..60ec7357 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -832,6 +832,8 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> it could also be used to drop the overloaded (and probably over
       imbalanced) page cache hash table
 
+[[gnumach_vm_map_red-black_trees]].
+
 
 # IRC, freenode, #hurd, 2011-05-03
 
@@ -2227,3 +2229,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> (i mean, when i made my tests, it looked like there were few
       kernel map entries, but i may have missed corner cases that could cause
       more of them to be needed)
+
+
+# IRC, freenode, #hurd, 2013-04-18
+
+    <braunr> oh nice, i've found a big scalability issue with my slab allocator
+    <braunr> it shouldn't affect gnumach much though
+
+
+## IRC, freenode, #hurd, 2013-04-19
+
+    <ArneBab> braunr: is it fixable?
+    <braunr> yes
+    <braunr> well, i'll do it in x15 for a start
+    <braunr> again, i don't think gnumach is much affected
+    <braunr> it's a scalability issue
+    <braunr> when millions of objects are in use
+    <braunr> gnumach rarely has more than a few hundred thousands
+    <braunr> it's also related to heavy multithreading/smp
+    <braunr> and by multithreading, i also mean preemption
+    <braunr> gnumach isn't preemptible and uniprocessor
+    <braunr> if the resulting diff is clean enough, i'll push it to gnumach
+      though :)
+
+
+### IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> ArneBab_: i fixed the scalability problems btw
+
+
+## IRC, freenode, #hurd, 2013-04-20
+
+    <braunr> well, there is also a locking error in the slab allocator,
+      although not a problem for a non preemptible kernel like gnumach
+    <braunr> non preemptible / uniprocessor
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
index 37ee548b..9f732fbe 100644
--- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -26,7 +26,7 @@ License|/fdl]]."]]"""]]
     <pinotree> this way we could add inside hurdtime.c the mapped time stuff
       too
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <pinotree> most probably a noobish question, but why does rt link to
       pthread?
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
index 1418bea1..e8160528 100644
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -13,7 +13,8 @@ failed"]]
 
 [[!tag open_issue_libpthread]]
 
-IRC, OFTC, #debian-hurd, 2011-10-21:
+
+# IRC, OFTC, #debian-hurd, 2011-10-21
 
     [Python testsuite]
     <pinotree> [169/340/1] test_logging
@@ -22,7 +23,8 @@ IRC, OFTC, #debian-hurd, 2011-10-21:
       __pthread_enqueue: Assertion `thread->prevp == 0' failed.
     <pinotree> sigh
 
-IRC, freenode, #hurd, 2011-10-21:
+
+## IRC, freenode, #hurd, 2011-10-21
 
     <pinotree> am i missing anything, or in libpthread the __pthread_threads
       list does not ever has elements removed from it?
@@ -33,7 +35,8 @@ IRC, freenode, #hurd, 2011-10-21:
     <pinotree> maybe reusing the same next+prevp pointers in the __pthread
       struct for more than one list at the same time isn't a good idea...
 
-2011-10-23:
+
+## IRC, freenode, #hurd, 2011-10-23
 
     <youpi> pinotree: I don't understand the relation between thread->prevp !=
       0 and the __pthread_threads list
@@ -50,3 +53,37 @@ IRC, freenode, #hurd, 2011-10-21:
     <pinotree> yeah
     <pinotree> apparently prevp/next are used for lists of held
       waitcond/mutex/rwlock and free threads
+
+
+# IRC, freenode, #hurd, 2013-03-20
+
+    <braunr> aw
+    <braunr> i hit the ext2fs.static: ./pthread/pt-internal.h:122:
+      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+    <braunr> assertion
+    <braunr> looks like there is a deadlock on assert
+    <braunr> which might explain why i never saw progress when i tested that in
+      the past
+
+
+## IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> damn, there still bugs in libpthread
+    <braunr> (about prevp not being null when it should i mean)
+    <pinotree> braunr: found another trigger for that?
+    <braunr> no
+    <braunr> it's so random i wonder if it's not a completely unrelated
+      corruption
+    <braunr> pinotree: also, i'm having more of these issues with my custom
+      hurd packages that let threads exit after some time from managing ports
+    <braunr> (i removed the libports_stability patch)
+    <braunr> i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png
+
+[The assertion failure.]
+
+
+## IRC, freenode, #hurd, 2013-04-23
+
+    <braunr> removing the libports_stability patch exposed bugs in libpthread,
+      triggering assertions when queueing/dequeue threads from a queue (but i
+      don't know which one / in which function)
diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn
index af0efa9d..48f1acf5 100644
--- a/open_issues/libpthread_cancellation_points.mdwn
+++ b/open_issues/libpthread_cancellation_points.mdwn
@@ -39,3 +39,101 @@ type to asynchronous permits this testcase to terminate. We do have the
 pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are
 not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in
 the mig msg call either.
+
+
+# Provenance
+
+## IRC, OFTC, #debian-hurd, 2013-04-15
+
+    <paravoid> so, let me say a few things about the bug in the first place
+    <paravoid> the package builds and runs a test suite
+    <paravoid> the second test in the test suite blocks forever
+    <paravoid> a blocked pthread_join is what I see
+    <paravoid> I'm unsure why
+    <paravoid> have you seen anything like it before?
+    <youpi> whenever the thread doesn't actually terminate, sure
+    <youpi> what is the thread usually blocked on when you cancel it?
+    <paravoid> this is a hurd-specific issue
+    <paravoid> works on all other arches
+    <youpi> could be just that all other archs have more relaxed behavior
+    <youpi> thus the question of what exactly is supposed to be happening
+    <youpi> apparently it is inside a select?
+    <youpi> it seems select is not cancellable here
+    <pinotree> wasn't the patch you sent?
+    <youpi> no, my patch was about signals
+    <youpi> not cancellation
+    <pinotree> k
+    <youpi> (even if that could be related, of course)
+    <paravoid> how did you see that?
+    <paravoid> what's the equivalent of strace?
+    <youpi> thread 3 is inside _hurd_select
+    <paravoid> thread 1 is blocked on join
+    <paravoid> but the code is
+    <paravoid>     if(gdmaps->reload_thread_spawned) {
+    <paravoid>         pthread_cancel(gdmaps->reload_tid);
+    <paravoid>         pthread_join(gdmaps->reload_tid, NULL);
+    <paravoid>     }
+    <paravoid> so cancel should have killed the thread
+    <youpi> cancelling a thread is a complex matter
+    <youpi> there are cancellation points
+    <youpi> e.g. a thread performing while(1); can't be cancelled
+    <paravoid> thread 3 is just a libev event loop
+    <youpi> yes, "just" calling poll, the most complex system call of unix :)
+    <youpi> paravoid: anyway, don't look for a bug in your program, it's most
+      likely a bug in glibc, thanks for the report
+    <paravoid> I think it all boils down to a problem cancelling a thread in
+      poll()
+    <youpi> yes
+    <youpi> paravoid: ok, actually with the latest libc it does work
+    <paravoid> oh?
+    <youpi> where latest = not uploaded yet :/
+    <paravoid> did you test this on exodar?
+    <youpi> pinotree: that's the libpthread_cancellation.diff I guess
+    <paravoid> because I commented out the join :)
+    <youpi> paravoid:  in the root, yes
+    <youpi> well, I tried my own program
+    <paravoid> oh, okay
+    <youpi> which is indeed hanging inside select (or just read) in the chroot
+    <youpi> but not in the root
+    <pinotree> ah, richard's patch
+    <paravoid> url?
+    <youpi> I've installed the build-dep in the root, if you want to try
+    <paravoid> strange that root is newer than the chroot :)
+    <youpi> paravoid: it's the usual eglibc debian source
+    <paravoid> tried in root, still fails
+    <youpi> could you keep the process running?
+    <paravoid> done
+    <youpi> Mmm, but the thread running gdmaps_reload_thread never set the
+      cancel type to async?
+    <youpi> that said I guess read and select are supposed to be cancellation
+      points
+    <youpi> thus cancel_deferred should be working, but they are not
+    <youpi> it seems it's cancellation points which have just not been
+      implemented
+    <youpi> (they happen to be one of the most obscure things in posix)
+
+
+## IRC, freenode, #hurd, 2013-04-15
+
+    <youpi> but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED
+    <youpi> how calls like read() or select() are supposed to test
+      cancellation?
+    <pinotree> iirc there are the LIBC_CANCEL_* macros in glibc
+    <pinotree> eg sysdeps/unix/sysv/linux/pread.c
+    <youpi> yes
+    <youpi> but in our libpthredaD?
+    <pinotree> could it be we lack the libpthread → glibc bridge of
+      cancellation stuff?
+    <youpi> we do have pthread_setcancelstate/type forwards
+    <youpi> but it seems the default LIBC_CANCEL_ASYNC is void
+    <pinotree> i mean, so when you cancel a thread, you can get that cancel
+      status in libc proper, just like it seems done with LIBC_CANCEL_* macros
+      and nptl
+    <youpi> as I said, the bridge is there
+    <youpi> we're just not using it in glibc
+    <youpi> I'm writing an open_issues page
+
+
+### IRC, freenode, #hurd, 2013-04-16
+
+    <braunr> youpi: yes, we said some time ago that it was lacking
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 768dca93..cd39328f 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -1324,7 +1324,7 @@ License|/fdl]]."]]"""]]
       device_map() -- but IIRC the only one that does (besides mem of course)
       is maptime -- which is not a real driver either...
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <braunr> oh btw, i didn't know you had a blog :)
     <antrik> well, it would be possible to replace the device interface by
diff --git a/open_issues/vdso.mdwn b/open_issues/vdso.mdwn
index 2b2d2805..76c43aa8 100644
--- a/open_issues/vdso.mdwn
+++ b/open_issues/vdso.mdwn
@@ -35,7 +35,7 @@ Having vDSO code might be useful for:
 
   * `mach_*_self`: `mach_host_self`, `mach_task_self`, `mach_thread_self`?
 
-  * [[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]
+  * [[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]
 
     Every application can then use that via the regular
     `gettimeofday`/`clock_gettime` and similar calls instead of using the
diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn
index 268f177b..36e04ab1 100644
--- a/public_hurd_boxen.mdwn
+++ b/public_hurd_boxen.mdwn
@@ -12,8 +12,9 @@ License|/fdl]]."]]"""]]
 [[!tag stable_URL]]
 
 There are GNU/Hurd boxes that we're offering shell accounts on.  These are
-generally available for everyone interested in [[contributing]], or just having
-a look at a GNU/Hurd system.
+generally available for people interested in [[contributing]], and who have
+already shown some level of involvement in the project. If you simply want to
+try the Hurd, the easiest way is running it in a virtual machine.
 
 An alternative to online shell access may be using a [[QEMU
 image|hurd/running/qemu]].
diff --git a/sidebar.mdwn b/sidebar.mdwn
index e8b69a93..5e019293 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -11,6 +11,14 @@ License|/fdl]]."]]"""]]
 
 Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd!
 
+[[!template id=highlight text="""**Breaking News**
+
+---
+
+The **Google Summer of Code 2013** is on!  If you're a student, consider
+applying for a GNU Hurd project -- details to be found on our
+*[[community/GSoC]] page*."""]]
+
 ---
 
   * **[[Home|/index]]**
diff --git a/toolchain/logs b/toolchain/logs
-Subproject 17ecfe30c4c1cb2c5833bc58f0ec355ec38b107
+Subproject a264dc206a1ebd541f01d3f3c496a80b3b8d978
diff --git a/user/musial.mdwn b/user/musial.mdwn
index 09992930..dd92024c 100644
--- a/user/musial.mdwn
+++ b/user/musial.mdwn
@@ -10,7 +10,7 @@ License|/fdl]]."]]"""]]
 
 ~musial (Robert Musial) - Cleveland, OH
 
-http://t-n.us/.musial/
+http://nyumbu.org/.musial/
 
 email: musial@gnu.org