17 files changed, 341 insertions, 87 deletions
diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn
new file mode 100644
index 00000000..f887d826
--- /dev/null
+++ b/hurd/console/discussion.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2012 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_documentation]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-09-24
+
+    <allesa> hello, I'm trying to get familiar with the Hurd and would like to
+      change the keyboard layout in use. It seems all the information I can
+      find (relating to console-driver-xkb) is out of date, with the latest
+      info relating to it being that this package should not be used anymore…
+    <allesa> does anyone know how changing keyboard layouts currently works?
+    <allesa> ah, never mind. I assume it doesn't currently work:
+      http://www.gnu.org/software/hurd/hurd/console.htmlq
+    <allesa> *http://www.gnu.org/software/hurd/hurd/console.html
+    <youpi> it does actually work
+    <youpi> simply dpkg-reconfigure keyboard-configuration
+    <youpi> and reboot
+    <youpi> (see http://www.debian.org/ports/hurd/hurd-install
+    <youpi> )
+    <allesa> mhm, I got that far — but selecting my layout gave me no joy, even
+      after restart. Seem to be stuck with the layout chosen during
+      installation (d-i). Just to check I'm using the right version — still on
+      the installer isos from 15 July?
+    <allesa> wait… progress is being made — slowly and subtly… 
+    <allesa> Ok, so the XKBLAYOUT is changing as you described, but XKBVARIANT
+      seems to be ignored. Could this be right?
+    <youpi> yes, the hurd console only supports keymaps
+    <youpi> (currently)
+    <allesa> Ah OK, thanks for your help on this. I imagine this is not
+      something that just requires simple repetitive work, but some actual
+      hacking?
+    <allesa> to fix that is…
+    <youpi> some hacking yes
diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn
index 48fd017c..ec19e90b 100644
--- a/hurd/documentation.mdwn
+++ b/hurd/documentation.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-2009, 2011 Free Software Foundation, Inc."]]
+2009, 2011, 2012 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
@@ -44,6 +44,8 @@ is included in the section entitled
 
 # Development
 
+  * [[RPC]]: our usage of *Remote Procedure Call*s.
+
   * *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*.
 
   * The *[[Hurd_Hacking_Guide]]*, an introduction to GNU&nbsp;Hurd and Mach
diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn
index b27bb9df..8560fd44 100644
--- a/hurd/libstore/nbd_store.mdwn
+++ b/hurd/libstore/nbd_store.mdwn
@@ -30,3 +30,8 @@ Perhaps the protocol was extended?
 
 
 ## [BlackHole](http://vanheusden.com/java/BlackHole/)
+
+
+# Open Issues
+
+  * [[!GNU_Savannah_task 5722]]
diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn
index 8b1a97e6..c8d819d4 100644
--- a/hurd/libthreads.mdwn
+++ b/hurd/libthreads.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 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,10 +13,14 @@ License|/fdl]]."]]"""]]
 
 # Internals
 
+## Threading Model
+
+libthreads has a 1:1 threading model.
+
 
 ## Threads' Death
 
-C threads death doesn't actually free the thread's stack (and maybe not the
+A thread's death doesn't actually free the thread's stack (and maybe not the
 associated Mach ports either).  That's because there's no way to free the stack
 after the thread dies (because the thread of control is gone); the stack needs
 to be freed by something else, and there's nothing convenient to do it.  There
@@ -26,3 +30,5 @@ However, it isn't really a leak, because the unfreed resources do get used for
 the next thread.  So the issue is that the shrinkage of resource consumption
 never happens, but it doesn't grow without bounds; it just stays at the maximum
 even if the current number of threads is lower.
+
+The same issue exists in [[libpthread]].
diff --git a/hurd/rpc.mdwn b/hurd/rpc.mdwn
new file mode 100644
index 00000000..f4ddaab5
--- /dev/null
+++ b/hurd/rpc.mdwn
@@ -0,0 +1,121 @@
+[[!meta copyright="Copyright © 2012 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]]."]]"""]]
+
+[[Remote procedure call|/rpc]]s are the basis for about everything in the Hurd.
+They're based on the [[Mach RPC mechanism (`mach_msg` system
+call)|microkernel/mach/rpc]].  An RPC is made against a [[Mach
+port|microkernel/mach/port]], which is the gateway to the [[translator]] that
+will serve the RPC.  Let's explore the case of `open`ing a file, and advancing
+(`lseek`) ten bytes into it.  The user program will be something like:
+
+    #include <fcntl.h>
+
+    int main(void) {
+      int fd = open("test.txt", O_RDONLY);
+      lseek(fd, 10, SEEK_CUR);
+    }
+
+Both `open` and `lseek` are functions provided by [[glibc]], which translates
+these into the appropriate remote procedure calls.
+
+`open` first has to find its way to the actual translator serving that file,
+but for a file on the root filesystem, what happens boils down to calling the
+`dir_lookup` function against the root filesystem.  This is an RPC from the
+[[`fs` interface (see `fs.defs`)|interface/fs]].  The implementation of this
+function is thus actually generated during the glibc build in
+`RPC_dir_lookup.c`, based on the `fs.defs` file, using
+[[microkernel/mach/MIG]].  This generated function essentially [[encodes the
+parameters into a data buffer|idl]], and makes a `mach_msg` system call to send
+the buffer to the root filesystem port, with the `dir_lookup` RPC ID.
+
+The root filesystem, for instance [[translator/ext2fs]], was sitting in its
+main service loop (`libdiskfs/init-first.c:master_thread_function`), which
+calls `ports_manage_port_operations_multithread`, which essentially simply
+keeps making `mach_msg` system calls to receive [[microkernel/mach/message]]s,
+and calls the demultiplexer on it, here the `diskfs_demuxer`.  This
+demultiplexer calls the demultiplexers for the various interfaces supported by
+ext2fs.  These demuxers are generated using MIG during the Hurd build.  For
+instance, the `fs` interface demultiplexer for [[diskfs|libdiskfs]],
+`diskfs_fs_server`, is in `libdiskfs/fsServer.c`.  It simply checks whether the
+RPC ID is an `fs` interface ID, and if so uses the `diskfs_fs_server_routines`
+array for calling the appropriate function corresponding to the RPC ID.  Here
+it's `_Xdir_lookup` which thus gets called.  This one decodes the parameters
+from the message data buffer, and calls `diskfs_S_dir_lookup`.
+
+`diskfs_S_dir_lookup` in the ext2fs translator does stuff to check that the
+file exists, etc. and eventually creates a new port, which will represent the
+open file, and a structure to keep information about it.  It returns this new
+port to its caller, `_Xdir_lookup`, which puts it into the reply message data
+buffer and returns.  `ports_manage_port_operations_multithread` then calls
+`mach_msg` to send that port to the user program.
+
+The `mach_msg` call in the user program thus returns, returning the port,
+decoded by `dir_lookup`.  glibc adds a new slot to its
+[[glibc/file_descriptor]] table, and records the port in it.
+
+`lseek` is simpler.  The glibc implementation simply calls the `__io_seek`
+function against the port of the file descriptor.  This is an RPC from the
+[[`io` interface (see io.defs)|interface/io]].  As explained above, the
+implementation is thus in `RPC_io_seek.c`, it encodes parameters and makes a
+`mach_msg` system call to the port of the file descriptor with the `io_seek`
+RPC ID.
+
+In the root filesystem, it's now the demultiplexer for the `io` interface,
+`diskfs_io_server`, which will recognize the RPC ID, and call `_Xio_seek`,
+which retrieves the data structure for the port, and calls `diskfs_S_io_seek`.
+The latter simply modifies ext2fs' internal data structure to account for the
+file position change, and returns the new position.  `_Xio_seek` encodes the
+position into the reply message, which is sent back by
+`ports_manage_port_operations_multithread` through `mach_msg`.
+
+The `mach_msg` call in the user program thus returns the new offset, decoded by
+`__io_seek`.  `lseek` can then return it to the user application.
+
+
+When hacking, one usually does *not* have to keep all that in mind.  All one
+needs to remember (or look up) is that when the application program calls
+`open`, the glibc implementation actually calls `dir_lookup`, which triggers a
+call to `diskfs_S_dir_lookup` in the ext2fs translator.  When the application
+program calls `lseek`, the glibc implementation calls `__io_seek`, which
+triggers a call to `diskfs_S_io_seek` in the ext2fs translator.  And so on...
+
+
+# Questions and Answers
+
+## How do I know whether a function is an RPC or not?
+
+Simply `grep` the function name (without leading underscores) in the
+`/usr/include/hurd/*.defs` files.
+
+
+## Why is it a libdiskfs function that get called?
+
+Because the filesystem serving the file, ext2fs, is [[libdiskfs]]-based (see
+`HURDLIBS = diskfs` in `ext2fs/Makefile`).  Other translators are
+[[libnetfs]]-based or [[libtrivfs]]-based.  `grep` for RPC names in those
+according to what your translator is based on.
+
+
+## How do I know which translator the RPC gets into?
+
+Check the type of file whose port the RPC was made on. Most files are handled
+by the translator which is mounted where the files are opened. Some special
+files are handled by particular translators:
+
+  * `PF_LOCAL`/`PF_UNIX` sockets are served by [[translator/pflocal]], see
+    [[hurd/networking]];
+  * `PF_INET`/`PF_INET6` sockets are served by [[translator/pfinet]], see
+    [[hurd/networking]];
+  * named sockets (also known as FIFOs) are served by [[translator/fifo]].
+
+
+# See Also
+
+  * [[hurd/debugging/rpctrace]]
diff --git a/hurd/running.mdwn b/hurd/running.mdwn
index a96a78c4..41855433 100644
--- a/hurd/running.mdwn
+++ b/hurd/running.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 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
@@ -17,6 +17,7 @@ There are several different ways to run a GNU/Hurd system:
 * [[microkernel/mach/gnumach/ports/Xen]] - In Xen
 * [[Live_CD]]
 * [[QEMU]] - In QEMU
+* [[chroots|chroot]] need a couple of tricks to work properly.
 * [[VirtualBox]] - In VirtualBox
 * [[vmware]] (**non-free!**)
 
diff --git a/hurd/running/chroot.mdwn b/hurd/running/chroot.mdwn
new file mode 100644
index 00000000..29b00a8f
--- /dev/null
+++ b/hurd/running/chroot.mdwn
@@ -0,0 +1,54 @@
+[[!meta copyright="Copyright © 2012 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]]."]]"""]]
+
+This documents the currently-needed tricks to successfully build a
+[[glibc/chroot]] in GNU/Hurd.
+
+# Preparation
+
+For proper translator startup, the chroot storage needs to be handled by a
+separate translator, for instance:
+
+    # dd [...] < /dev/zero > storage
+    # mke2fs storage
+    # settrans -c chroot /hurd/ext2fs $PWD/storage
+
+# Unpack
+
+Debootstrap should be able to build the content:
+
+    # debootstrap sid chroot
+
+# Tricks
+
+One current issue to know about chroots is that since passive translators (e.g.
+`/servers/socket/1`) are started by the root translator, which is not aware
+of the chrooting, these passive translators are started non-chrooted, leading to
+a few issues.
+[[!tag open_issue_hurd]]
+
+## Sockets
+
+Since the passive [[translator/pflocal]] translator will not be chrooted, local
+socket creation
+will actually happen in the root filesystem. To make things work correctly the
+programs inside the chroot need to be able to access them:
+
+    # settrans chroot/servers/socket/1 /hurd/firmlink /servers/socket/1
+    # settrans chroot/tmp /hurd/firmlink /tmp
+    # settrans -c chroot/var/lib/dbus /hurd/firmlink /var/lib/dbus
+
+## Network
+
+Unless using a separate IP for the chroot, it is preferrable to share the
+[[translator/pfinet]] translator:
+
+    # settrans chroot/servers/socket/2 /hurd/firmlink /servers/socket/2
+    # settrans chroot/servers/socket/26 /hurd/firmlink /servers/socket/26
diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn
index 36c37281..72ea70a9 100644
--- a/hurd/running/debian/after_install.mdwn
+++ b/hurd/running/debian/after_install.mdwn
@@ -1,35 +1,7 @@
 First steps after installation.
 
-So you have managed to get past the first `native-install` runs in single-user
-mode?
-
-Time to get to work.
-
-[[!toc]]
-
-
-### Get Networking Running
-
-[[Network]].
-
-Check if your NIC was detected by GNU Mach:
-
-    # devprobe eth0
-
-`devprobe` (run as user *root*) will print `eth0` on successful detection.  If
-it doesn't, your NIC was not detected correctly.  You can then try to do the
-following (also as user *root*) for getting details:
-
-    # cat /dev/klog > ~/klog
-    [Wait a second, then press `Ctrl-C'.]
-
-Now examine the `~/klog` file.
-
-If the NIC was detected:
-
-    # settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.3 -g 192.168.1.1 -m 255.255.255.0
-
-Or read about how to configure [[DHCP]].
+See <http://www.debian.org/ports/hurd/hurd-install> for configuration bits and
+tips and tricks.
 
 
 # Setup GRUB
@@ -41,45 +13,5 @@ you.  See [[GRUB]]'s page for this.
 
 # Setup `apt-get`
 
-Sometimes getting `apt-get` to work is not straightforward.  Good mirrors to
-put in `/etc/apt/sources.list` are:
-
-    deb http://ftp.debian.org/debian unstable main contrib
-    deb-src http://ftp.debian.org/debian unstable main contrib
-    deb http://ftp.debian-ports.org/debian unreleased main
-    deb-src http://ftp.debian-ports.org/debian unreleased main
-
-`apt-get` update a couple of times if some file fails to download.
-
-If when doing your first `apt-get`, `dpkg` complains of missing programs, get root in a login shell (`su -`).
-
 Installing packages without having a network connection is described
 [[Distrib/DebianAptOffline]].
-
-# [[translator/Random]]
-
-You often need `scp` and `ssh`.  There is now a `random-egd` package available which uses
-a random translator by Ryan Hunter and the entropy gathering daemon as entropy source.
-
-See [[Translator/random]] for more information.
-
-# [[Console]]
-
-The latest Hurd package in Debian, plus the `native-install` script, creates
-all necessary device nodes and other magic.  You just need to edit
-`/etc/default/hurd-console` to tune the parameters and tell it to start at
-bootup.
-
-You can also call the Hurd console manually with the proper arguments:
-
-    console -d vga -d pc_kbd --repeat=kbd -d pc_mouse --repeat=mouse \
-            -d generic_speaker -c /dev/vcs
-
-
-# [[Hurd/DebianXorg]]
-
-You first must have setup the virtual console.  See above.
-
-# What about package XYZ?
-
-See if you can find a useful tip in [[package_troubleshooting]].
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
index 8d351aae..afa46799 100644
--- a/hurd/running/debian/dhcp.mdwn
+++ b/hurd/running/debian/dhcp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 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,16 +10,16 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_porting]]
 
-In order to use DHCP, you need to install the `ifup` and `isc-dhcp-client`
-packages, and manually create the following two symbolic links:
+In order to use DHCP, you need to install the `ifupdown` and `isc-dhcp-client`
+packages, and manually create the following symbolic link:
 
-    # ln -s ../rcS.d/S06ifupdown-clean ../rcS.d/S11networking /etc/rc.boot/
+    # ln -s ../rcS.d/S10networking /etc/rc.boot/
 
-During execution at boot time, the `S11networking` script will emit some error
+During execution at boot time, the `S10networking` script will emit some error
 messages while trying to configure the loopback interface.  These are not
 fatal.
 
-Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot
+Debian GNU/Hurd doesn't currently execute Debian standard `/etc/rcS.d/*` boot
 scripts, but has its own `/libexec/rc` script -- which integrates scripts from
 `/etc/rc.boot/` instead.
 
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index 512ea602..3648c7d6 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -105,6 +105,16 @@ If your machine supports hardware acceleration, you should really use the kvm va
 
 to the command line, see below, if you are running Linux kernels 2.6.37 or 2.6.38 else IRQs may hang sooner or later. The kvm irq problems will be solved in kernel 2.6.39. 
 
+IRC, freenode, #hurd, 2012-08-29:
+
+    <braunr> youpi: do you remember which linux versions require the
+      -no-kvm-irqchip option ?
+    <braunr> your page indicates 2.6.37-38, but i'm seeing weird things on
+      2.6.32
+    <braunr> looks like a good thing to use that option all the time actually
+    <gnu_srs> seems like kvm -h says: -no-kvm-irqchip and man kvm says:
+      -machine kernel_irqchip=off
+
 /!\ Note that there are known performance issues with KVM on Linux 2.6.39
 kernels, compared to 2.6.32: [[!debbug 634149]].  We're preparing on a change
 on our side to work around this.
diff --git a/hurd/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn
index c9ec4d34..74f1c8f5 100644
--- a/hurd/settrans/discussion.mdwn
+++ b/hurd/settrans/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 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
@@ -16,3 +16,24 @@ License|/fdl]]."]]"""]]
     <antrik> ugh... I just realized why settrans -a without -f doesn't
       generally work on filesystem translators
     <antrik> obviously, it needs -R too!
+
+
+# IRC, freenode, #hurd, 2012-08-17
+
+    <antrik> youpi: no, only the -g is redundant; i.e. -ga is the same as -a
+    <antrik> (actually, not redundant, but rather simply meaningless in this
+      case)
+    <antrik> -g tells what to do with an active translator *when a passive one
+      is changed*
+    <antrik> if no passive one is changed, it does nothing
+    <antrik> (and I realized that after using the Hurd for only 6 years or so
+      ;-) )
+    <braunr> it's not obvious
+    <antrik> braunr: indeed. it's not obvious at all from the --help output :-(
+    <antrik> not sure though how to make it clearer
+    <braunr> the idea isn't obvious
+    <braunr> perhaps telling that "setting a passive translator" also applies
+      to removing it, i.e. setting it to none
+    <antrik> braunr: well, the fact that a translator is unset by setting it to
+      nothing is unclear in general, not only for passive translator. I agree
+      that pointing this out should make things much more clear in general...
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index dd67a4c2..e6545b27 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -110,3 +110,9 @@ possibility that they would want to try the Hurd again in the future.
 > 
 > [But] unlike a few years back [...] the system is stable enough under
 > load nowadays [...].
+
+### GNUStep on GNU Hurd, 2009-02-15
+
+Riccardo Mottola Bergamo shows screenshots of the GNUStep browser 
+[Vespuzzi running on Hurd](http://multixden.blogspot.com/2009/02/browser-on-hurd.html). 
+
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 460194f9..13a1d9ec 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -89,6 +89,20 @@ small backend stores, like floppy devices.
     <youpi> which can be quite probable
 
 
+## Sync Interval
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2012-10-08
+
+    <braunr> btw, how about we increase our ext2 sync interval to 30 seconds,
+      like others do ?
+    <braunr> not really because others do it that way, but because it severely
+      breaks performance on the hurd
+    <braunr> and 30 seems like a reasonable amount (better than 5 at least)
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/nfs.mdwn b/hurd/translator/nfs.mdwn
index bf24370a..81372204 100644
--- a/hurd/translator/nfs.mdwn
+++ b/hurd/translator/nfs.mdwn
@@ -10,6 +10,11 @@ License|/fdl]]."]]"""]]
 
 Translator acting as a NFS client.
 
+Only NFSv2/v3 is currentl supported.
+
+[[!tag open_issue_hurd]]There are a few unmerged changes on a former GSoC
+project's topic-branch.
+
 
 # See Also
 
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 5afee0c6..d30cc850 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
 
 [[Stefan_Siegl|stesie]] has added IPv6 support to the pfinet [[translator]].
 This was [Savannah task #5470](http://savannah.gnu.org/task/?5470).
@@ -55,3 +55,18 @@ Quite the same, but with static IPv6 address assignment:
 # Missing Functionality
 
 Amongst other things, support for [[IOCTL]]s is missing.
+
+
+## IRC, freenode, #hurd, 2012-12-10
+
+[[!tag open_issue_hurd]]
+
+    <braunr> looks like pfinet -G option doesn't work
+    <braunr> if someone is interested in fixing this (it concerns static IPv6
+      routing)
+    <braunr> youpi: have you ever successfully used pfinet with global
+      statically configured ipv6 addresses ?
+    <youpi> never tried
+    <braunr> ok
+    <braunr> i'd like to set this up on my VMs but it looks bugged :/
+    <braunr> i can't manage to set correctly set the gateway
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 2acca39c..e71ea02b 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -279,7 +279,7 @@ Needed by glibc's `pldd` tool (commit
 
 # `/proc/[PID]/maps`
 
-[[!tag GNU_Savannah_bug 32770]]
+[[!GNU_Savannah_bug 32770]]
 
 
 ## IRC, OFTC, #debian-hurd, 2012-06-20
@@ -317,3 +317,23 @@ Needed by glibc's `pldd` tool (commit
 
     * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
         on "internal" (but exported) glibc functions
+
+
+# "Unusual" PIDs
+
+Not actually related to procfs, but here seems to be a convenient place for
+filing these:
+
+
+## IRC, freenode, #hurd, 2012-08-10
+
+    <braunr> too bad the proc server has pid 0
+    <braunr> top & co won't show it
+
+
+## IRC, OFTC, #debian-hurd, 2012-09-18
+
+    <pinotree> youpi: did you see
+      https://enc.com.au/2012/09/careful-with-pids/'
+    <pinotree> ?
+    <youpi> nope
diff --git a/hurd/translator/random.mdwn b/hurd/translator/random.mdwn
index afb76953..9fc975f2 100644
--- a/hurd/translator/random.mdwn
+++ b/hurd/translator/random.mdwn
@@ -31,7 +31,7 @@ but they are not yet in the default installation.
     the internals.
 
 * [Entropy Gathering Daemon](http://egd.sourceforge.net/).
-  * [request for packaging](http://bugs.debian.org/145498).
+  * [[!debbug desc="request for packaging" 145498]].
 
 * [OSKit Entropy
   Patch](http://lists.gnu.org/archive/html/bug-hurd/2003-01/msg00000.html) from