IRC.

22 files changed, 1875 insertions, 24 deletions

diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
index d3e17dc9..d67dbe20 100644
--- a/community/gsoc/project_ideas/object_lookups.mdwn
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -539,3 +539,93 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]].
     <teythoon> right, for dup and friends
     <braunr> and the radix tree is a data structure that can cope decently with
       not too sparsed distributions
+
+
+## IRC, freenode, #hurd, 2014-02-27
+
+    <braunr> teythoon: ah, just saw the commit that will make our network
+      faster :)
+    <teythoon> network ?
+    <braunr> eh no, it's about ioctls actually
+    <braunr> :)
+    <braunr> i read a bit too quickly
+    <teythoon> one more small step towards fixing all receiver lookups in the
+      hurd...
+    <teythoon> i did not anticipate how much the hurd has to be changed first
+      in order to make use of the protected payloads
+    <braunr> that was my main reason not to do it actually :/
+    <braunr> but you're almost finished with it, aren't you ?
+    <teythoon> not sure tbh
+    <teythoon> i believe the fsys stuff was the largest chunk
+
+
+## IRC, freenode, #hurd, 2014-03-02
+
+    <teythoon> youpi: i cleaned up most of the receiver lookups in hurd by now
+    <teythoon> but there are some tricky cases left
+    <teythoon> 1/ the pager stuff
+    <teythoon> the mig declarations are in gnumach, and do not have the
+      necessary intran declarations that we can mutate
+    <teythoon> 2/ some uses of mach_port_t instead of some_type_t in the hurd
+      rpc definitions
+    <teythoon> (e.g. fsys_forward)
+    <teythoon> for 1/, i'd like to extend the definitions in gnumach
+    <teythoon> i'm not so sure what to do for the second case
+    <teythoon> we could introduce some types for each case
+    <teythoon> or, we do not touch the definitions
+    <teythoon> my protected payload prototype allows us to map payloads back to
+      port names for the functions that want a name
+    <teythoon> i did this by redefining the mach_port_t type for mig that uses
+      the payload to port-name intran function
+    <teythoon> mig allows type redefinitions, but emits a warning message
+    <teythoon> though i consider that a useful feature, it allows one to refine
+      a type
+
+
+## IRC, freenode, #hurd, 2014-03-04
+
+    <teythoon> braunr: i fixed the object lookups in libpager yesterday, a
+      pretty mechanic change
+    <braunr> teythoon: can't be bad :)
+    <teythoon> amusingly, the resulting packages boot about half way through
+      o_O
+    <braunr> teythoon: ?
+    <teythoon> it hangs while cleaning left-over files from /tmp
+    <braunr> ugh, libpager ..
+    <teythoon> yes
+    <teythoon> tricky pager stuff is tricky ?
+    <braunr> tricky buggy pager stuff is tricky and buggy
+    <teythoon> ^^
+    <braunr> let's assume you made things faster, increasing the likelihood of
+      deadlocks ..
+    <braunr> we had a patch once for a libpager deadlock
+    <teythoon> well, i'm not yet at the point where things might get faster
+    <braunr> see 901c61a1d25e7c8963e51012760a82730eda1910
+    <braunr> the same problem exists elsewhere i think, you might have hit it
+    <teythoon> i'm still just moving the object lookups from the server
+      functions to the mig translation functions
+    <braunr> hm
+    <teythoon> but yes, i might have influenced the timing, not sure
+    <braunr> shouldn't cost too much to add some prints
+    <braunr> iirc, the other potential deadlock is in libpager/pager-attr.c
+    <braunr> when memory_object_change_attributes is called
+    <braunr> (which loops back into libpager when the kernel sends data back
+    <braunr> )
+    <braunr> tricky ..
+    <teythoon> i'll try that when i get home
+
+    <braunr> aren't you almost done ?
+    <teythoon> not sure tbh
+    <braunr> :(
+    <braunr> althouhg libpager would be really great
+    <teythoon> and mach-defpager
+    <braunr> since this is actually one of the biggest points of contention
+    <teythoon> i'll do that next, and return to libpager later
+    <braunr> ok
+    <teythoon> for both i needed to change some rpc type definitions in gnu
+      mach
+    <braunr> skipping lookups in libpager would make it harder to suffer
+      writeback thread storms
+    <teythoon> so i want to make sure that these changes are fine so that i can
+      propose them
+    <braunr> ok
diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn
index d80efe37..dcbea144 100644
--- a/community/gsoc/project_ideas/package_manager.mdwn
+++ b/community/gsoc/project_ideas/package_manager.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 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="Hurdish Package Manager for the GNU System"]]
 
@@ -37,7 +38,7 @@ came about.  There are no global databases of any kind.  (Some things might
 require caching for better performance, but this must happen transparently.)
 
 The core of this approach is formed by [[hurd/translator/stowfs]].
-[Guix](http://www.gnu.org/software/guix), GNU's package manager,
+[[GNU Guix|hurd/running/nix#guix]], GNU's package manager,
 installs each package in its own directory.  Each user has a
 *profile*, which is the union of some of these packages.  On
 GNU/Linux, this union is implemented as a symlink tree; on GNU/Hurd,
@@ -46,7 +47,8 @@ Unix directory structure from all the files in the individual package
 directories.  This handles the lowest level of package
 management.
 
-The goal of this task is to exploit Hurd features in GNU Guix.
+The goal of this task is to exploit Hurd features in [[GNU
+Guix|hurd/running/nix#guix]].
 
 Possible mentors: Ludovic Courtès, Ben Asselstine (bing)
 
diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn
index 13cc6cd1..0c51bdc1 100644
--- a/community/gsoc/project_ideas/unionfs_boot.mdwn
+++ b/community/gsoc/project_ideas/unionfs_boot.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 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="Allow Using unionfs Early at Boot"]]
 
@@ -19,7 +20,8 @@ software packages, GNU/Linux distributions usually come with a package manager,
 which keeps track of all files upon installation/removal in some kind of
 central database.
 
-An alternative approach is the one implemented by GNU Stow and GNU Guix: each package is
+An alternative approach is the one implemented by [[GNU Stow and GNU
+Guix|package_manager]]: each package is
 actually installed in a private directory tree.  The actual standard directory
 structure is then created by collecting the individual files from all the
 packages, and presenting them in the common `/bin`, `/lib`, etc. locations.
diff --git a/contributing.mdwn b/contributing.mdwn
index 08c11041..485bdd47 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -97,7 +97,8 @@ part:1:file:/home/samy/tmp/foo`). This would be libnetfs-based.
 [[GSoC proposal|community/gsoc/project_ideas/valgrind ]] about this, but the
 basic port could be small.
 * Add `/proc/$pid/maps`. `vminfo` already has this kind of information, it's a  matter of making procfs do the same. [[!GNU_Savannah_bug 32770]]
-* Move the mount/umount logic from `utils/{,u}mount.c` into [[hurd/libshouldbeinlibc]].
+* Move the [[mount/umount|open_issues/glibc#mount]] logic from
+`utils/{,u}mount.c` into [[glibc]].
 * Fix [[`/proc/self`|hurd/translator/procfs/jkoenig/discussion#self]].
 Look at `[glibc]/hurd/lookup-retry.c` for how [`FS_RETRY_MAGICAL`
 lookups|hurd/interface/dir_lookup]] work.
diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn
index 332fc03b..c6212da8 100644
--- a/hurd/running/nix.mdwn
+++ b/hurd/running/nix.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 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
@@ -8,7 +9,12 @@ 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="Nix-based GNU/Hurd System"]]
+[[!meta title="Nix-based GNU/Hurd System, Guix"]]
+
+[[!toc]]
+
+
+# Nix
 
 <http://www.nixos.org/>
 
@@ -25,7 +31,7 @@ Nix, and because of that, it uses per-package installation directories under
 `/nix/store`.
 
 
-# IRC, freenode, #hurd, 2013-02-04
+## IRC, freenode, #hurd, 2013-02-04
 
     <braunr> is it possible to use nix ?
     <braunr> or nixos
@@ -39,3 +45,458 @@ Nix, and because of that, it uses per-package installation directories under
     <civodul> (my favorite)
     <civodul> i've been willing to unbreak it, but now i rather invest time in
       Guix
+
+
+# <a href="guix">Guix</a>
+
+## <http://www.gnu.org/software/guix/>
+
+## IRC, freenode, #hurd, 2014-02-13
+
+    <phant0mas> is debian hurd the only way to use hurd?
+    <braunr> maybe
+    <braunr> there is arch hurd but i haven't heard from them in some time
+    <braunr> building from source is difficult
+    <phant0mas> what is the problem with building from source?
+    <braunr> no automated build system, except for debian
+    <braunr> each project has its own build system
+    <braunr> but there is no tool to take care of the global procedure
+      (i.e. build in the correct order, with the correct options, paths and
+      patches, etc...)
+    <youpi> well, there is, it's called Debian :)
+    <braunr> 00:17 < braunr> no automated build system, except for debian
+    <phant0mas> how far away is it  from building a gnu system with let's say
+      guix as a package manager?
+    <phant0mas> and hurd as the kernel?
+    <braunr> i don't know
+    <youpi> phant0mas: there are already proofs of concepts
+    <phant0mas> youpi: any more info about the proofs of concepts?
+    <youpi> phant0mas: ask civodul
+    <youpi> apparently he's not here atm, though
+    <phant0mas> I will ask him at guix channel
+
+
+## IRC, freenode, #hurd, 2014-02-14
+
+    <phant0mas> can I ask a question about configuring gnu mach from source?
+    <taylanub> phant0mas: IRC etiquette: don't ask to ask, just ask, it saves
+      time.  People often leave IRC open for long durations but don't always
+      check it, if you just leave your question in the channel someone might
+      come back and see it at any time (even hours later).
+    <phant0mas> when I try to configure gnumach with 
+    <phant0mas> CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld
+      -melf_i386' ./configure --prefix= --host=i686-unknown-linux-gnu
+    <phant0mas> on a 64 bit system
+    <phant0mas> I get the error 
+    <phant0mas> checking for i686-unknown-linux-gnu-gcc... gcc -m32
+    <phant0mas> checking whether the C compiler works... no
+    <phant0mas> configure: error: in `/home/manolis/Downloads/gnumach-1.4':
+    <phant0mas> configure: error: C compiler cannot create executables
+    <phant0mas> but if I remove the -m32 from CC='gcc -m32' the error
+      disappears
+    <phant0mas> what is the problem?
+    <braunr> what do you think there is a problem ?
+    <braunr> i don't think -m32 should be part of CPP/CC, but rather CPPFLAGS
+    <braunr> also, i don't think you need it since the target is well defined
+    <phant0mas> I am following exaclty the instruction from here
+      http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html
+    <braunr> hm that's weird
+    <braunr> phant0mas: what does gcc -v says and what's your host system ?
+    <phant0mas> Using built-in specs.
+    <phant0mas> COLLECT_GCC=gcc
+    <phant0mas>
+      COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
+    <phant0mas> Target: x86_64-unknown-linux-gnu
+    <phant0mas> Configured with: /build/gcc/src/gcc-4.8-20131219/configure
+      --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
+      --mandir=/usr/share/man --infodir=/usr/share/info
+      --with-bugurl=https://bugs.archlinux.org/
+      --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
+      --enable-threads=posix --with-system-zlib --enable-__cxa_atexit
+      --disable-libunwind-exceptions --enable-clocale=gnu
+      --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-
+    <phant0mas> object --enable-linker-build-id --enable-cloog-backend=isl
+      --disable-cloog-version-check --enable-lto --enable-plugin
+      --enable-install-libiberty --with-linker-hash-style=gnu
+      --disable-multilib --disable-werror --enable-checking=release
+    <phant0mas> Thread model: posix
+    <phant0mas> gcc version 4.8.2 20131219 (prerelease) (GCC) 
+    <braunr> check config.log for the actual error message then
+    <phant0mas> http://pastebin.com/raw.php?i=eQ75qafX 
+    <phant0mas> if you want to have a look as well
+    <braunr> install gcc-multilib maybe
+    <braunr> or lib32gcc1
+    <sjbalaji> Installing gcc-multilib solves it.
+    <phant0mas> braunr: it works like a charm now
+    <braunr> phant0mas: good
+
+
+## IRC, freenode, #hurd, 2014-02-18
+
+    <phant0mas> why mig has no make target, and the executable gets generated
+      from the ./configure?
+    <phant0mas> I mean shouldn't make be the one building mig?
+
+
+## IRC, freenode, #hurd, 2014-02-19
+
+    <phant0mas> mig binary shouldn't be built by make? why is it built at the
+      end of the configure command?
+    <braunr> no idea
+    <phant0mas> http://pastebin.com/raw.php?i=2HVni53Y
+    <braunr> "creating mig" you mean ?
+    <phant0mas> loot at the end of the config output
+    <phant0mas> config.status: creating mig <--
+    <phant0mas> the binary
+    <phant0mas> and then when you call make
+    <phant0mas> it says no target
+    <braunr> weird
+    <phant0mas> normally binaries are built from make
+    <braunr> what system are you building on ?
+    <phant0mas> on Arch Linux x86_64 with gcc version 4.8.2
+    <phant0mas> I am using the flag i686-pc-gnu to crossbuild it for 32 bit
+    <phant0mas> I am using the tar file from here
+      http://ftp.gnu.org.ua/gnu/mig/
+    <phant0mas> version 1.4
+    <braunr> tar file ?
+    <braunr> ok, i guess it's fine
+    <phant0mas> so source from the tar file builds mig through configure?
+    <braunr> again, i don't know
+    <braunr> i never build mig myself
+    <braunr> but it does look weird
+    <braunr> look at the debian package maybe
+    <braunr> who knows, maybe you'll find a patch with some explanation
+    <phant0mas> okay then,going over that way right away
+    <phant0mas> thnx braunr
+    <teythoon> phant0mas: mig is a shell script wrapper
+    <phant0mas> so it's not a binary....
+    <teythoon> no
+
+
+## IRC, freenode, #hurd, 2014-02-21
+
+    <phant0mas> do I need some minimal set of drivers to build gnumach?
+    <phant0mas> because I get this error
+      ../linux/src/drivers/scsi/BusLogic.c:53:24: fatal error: FlashPoint.c: No
+      such file or directory
+    <phant0mas> when running make
+    <teythoon> i thought we fixed that
+    <teythoon> are your sources up to date ?
+    <phant0mas> I am using the tar ball
+    <phant0mas> cause I am trying to package it for guix
+    <teythoon> what tarball ?
+    <braunr> 1.4
+    <phant0mas> yes
+    <braunr> phant0mas: just don't build scsi drivers
+    <phant0mas> 1.4
+    <phant0mas> worked
+    <teythoon> why do we keep the driver if it doesn't even build ?
+    <gg0> on debian it builds with --disable-net-group --disable-pcmcia-group
+      --disable-wireless-group
+
+
+## IRC, freenode, #hurd, 2014-02-23
+
+    <phant0mas> why when I configure gnumach like this CPP='gcc -m32 -E -x c
+      -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --prefix=
+      --host=i686-unknown-linux-gnu it builds just fine but when I try to
+      configure it with ./configure --prefix= --host=i686-unknown-linux-gnu
+      CFLAGS='-m32' CPPFLAGS='-m32 -E -x c -undef -ansi' LDFLAGS='-melf_i386'  
+    <phant0mas> I am building it on a 64 bit machine
+    <phant0mas> when setting env vars before configuring everythings works like
+      a charm
+    <phant0mas> but if I pass them as flags to the configure ,it won't
+
+
+## IRC, freenode, #hurd, 2014-02-25
+
+    <phant0mas> what version of mae do I need in order to compile glibc for
+      hurd?
+    <phant0mas> make*
+    <azeem> phant0mas: did you have issues with a particular version?
+    <azeem> I believe GNU make is required, though
+    <phant0mas> I am using gnu make 4.0 and I get the error 
+    <phant0mas> These critical programs are missing or too old: make
+    <phant0mas> checking version of gmake... 4.0, bad
+    <azeem> phant0mas: that sounds bogus
+    <azeem> can you pastebin the relevant part of the config.log or so?
+    <phant0mas> of course one sec
+    <phant0mas> http://pastebin.com/raw.php?i=4CHZJi4W
+    <phant0mas> azeem_: any news about the problem I have with glibc?
+    <azeem_> phant0mas: sorry - got distracted - I suggest you post this to
+      bug-hurd or so
+    <azeem_> though it could well be Hurd-independent, then checking glibc
+      master and possibly filing a report there might be better
+    <azeem_> phant0mas: or in case you speak autoconf, check the conf check for
+      the make version
+
+
+## IRC, freenode, #hurd, 2014-02-26
+
+    <tschwinge> ph4nt0mas: Which glibc sources, and how are you
+      configuring/building?
+    <phant0mas> tschwinge: I am trying to crossbuild it from a linux 64 bit
+      machine with gnu make 4.0 and gcc 4.8.2 
+    <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/
+      --target=i686-pc-gnu
+    <phant0mas> wrong config
+    <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/
+      --with-headers=/home/manolis/gnu/include/ --host=i686-pc-gnu
+    <phant0mas> I am using the last one
+    <phant0mas> it says gnu make is too old
+    <phant0mas> this time I tried with glibc from the hurd git repo
+    <phant0mas> baseline branch
+    <phant0mas> should I build an older toolchain just for it?
+    <tschwinge> phant0mas: If you'd like to experiment with this, then please
+      use the tschwinge/Roger_Whittaker branch.  However, that one might still
+      be missing the glibc upstream change to allow GNU Make 4.0 and greater,
+      commit 28d708c44bc47b56f6551ff285f78edcf61c208a, so cherry-pick that one
+      (assuming there are no additional patches needed for GNU Make 4.0).
+    <phant0mas> okay going to  do that right away
+    <phant0mas> thnx :-)
+    <tschwinge> phant0mas: You have seen
+      http://www.gnu.org/software/hurd/toolchain/cross-gnu.html -- but beware
+      this may be out of date somewhat.
+    <phant0mas> tschwinge: I worked around that problem as you told me
+    <phant0mas> but it seems I forgot to build hurd 
+    <phant0mas> so I got the tarball
+    <phant0mas> but I am getting this error
+    <phant0mas> No rule to make target 'lowlevellock.h', needed by 'timefmt.o'.
+      Stop.
+    <phant0mas> after I manage to make all of this work I will write an up to
+      date guide on how to build the hurd  system
+    <phant0mas> for future reference
+
+
+## IRC, freenode, #hurd, 2014-02-27
+
+    <ph4n70m4s> when trying to build gnumach microkernelin a 32 bit enviroment
+      it builds just fine
+    <ph4n70m4s> but when i try to crossbuild it from a 64 bit machine, even
+      though i am using --target=i686-gnu --host=i686-gnu  to crossbuild it I
+      am just getting the error i386/i386/i386asm.symc:116:1: warning: asm
+      operand 0 probably doesn't match constraints [enabled by default]
+    <ph4n70m4s>  __asm ("\n\
+    <ph4n70m4s>  ^
+    <ph4n70m4s> i386/i386/i386asm.symc:116:1: error: impossible constraint in
+      'asm'
+    <ph4n70m4s> http://pastebin.com/raw.php?i=emag63N4 
+    <ph4n70m4s> the config.log
+    <ph4n70m4s> and the build output if anyone want to have a look
+    <ph4n70m4s> http://pastebin.com/raw.php?i=jAZPnybB
+    <ph4n70m4s> wants*
+    <ph4n70m4s> I am building through guix so you may see some strange paths 
+    <tschwinge> ph4n70m4s: Nice, Guix!  :-)
+    <tschwinge> ph4n70m4s: Does that help?  CC=gcc\ -m32
+    <tschwinge> Because:
+    <tschwinge> configure:3574: gcc -v >&5
+    <tschwinge> Using built-in specs.
+    <tschwinge> COLLECT_GCC=gcc
+    <tschwinge>
+      COLLECT_LTO_WRAPPER=/nix/store/7awbhk5hdkd4lqj4wsj6lm6h84630jhm-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
+    <tschwinge> Target: x86_64-unknown-linux-gnu
+    <teythoon> guix looks nice
+    <tschwinge> ph4n70m4s: Also you don't need --target with GNU Mach -- it
+      doesn'T target any architecture, that is, doesn'T create code or similar.
+    <tschwinge> Alternative to -m32, as you're specying --host=i686-gnu, you
+      could have (that is, you'd need) a i686-gnu-gcc (that internally defaults
+      to -m32 then).
+    <tschwinge> ph4n70m4s: Are you generally working on GNU Hurd support for
+      Guix, or just trying to build GNU Mach?
+    <ph4n70m4s> I am working on porting gnu guix to gnu hurd
+    <ph4n70m4s> so I need to port hurd to it
+    <ph4n70m4s> bootstrap it
+    <ph4n70m4s> and the make guix work on hurd
+    <ph4n70m4s> :-)
+    <teythoon> very cool :)
+    <tschwinge> \o/
+    <ph4n70m4s> then*
+    <ph4n70m4s> and If I manage to do all that we will be able to make a qemu
+      image 
+    <ph4n70m4s> with hurd -guix
+    <tschwinge> Yep, and then I'll be happy.  :-)
+    <ph4n70m4s> :-)
+    <tschwinge> For then we'll be easily able to change some detail in, say,
+      glibc, rebuild the whole system, and see whether it still works.
+    <ph4n70m4s> exaclty
+    <tschwinge> Of course, that doesn't strictly need Guix, but it's one way to
+      achieve this goal.
+    <tschwinge> For the initial cross compiler toolchain, I suggest you look at
+      my cross-gnu script (link provided yesterady) -- the gist of it should
+      all still be valid.
+    <ph4n70m4s> I do 
+    <tschwinge> For example, you don't actually need to build GNU Mach
+      initially, but just need to install the headers/defs files
+      (install-data).
+    <tschwinge> Perfect.
+    <ph4n70m4s> I have already done that, installing gnu mach headers was the
+      easy part
+    <ph4n70m4s> it's already on guix
+    <tschwinge> \o/
+    <tschwinge> Should really clone Git repository.  And subscribe to the
+      mailing list, and all that.
+    <ph4n70m4s> I have already done that
+    <ph4n70m4s> I am actually following hurd from last year
+    <tschwinge> Yeah, I was talking about me.  ;-)
+    <ph4n70m4s> aaaa
+    <ph4n70m4s> :P
+    <tschwinge> ph4n70m4s: Are you doing this as a Google Summer of Code
+      project?
+    <ph4n70m4s> I suggested the idea for the page
+    <ph4n70m4s> to ludovic
+    <ph4n70m4s> and he agreed
+    <tschwinge> :-)
+    <tschwinge> Good guy.
+    <tschwinge> Both of you.  ;-)
+    <ph4n70m4s> trying my best to help :-)
+    <ph4n70m4s> tschwinge: so to build glibc I only need mach and hurd headers 
+    <ph4n70m4s> right?
+    <braunr> yes
+
+
+## IRC, freenode, #hurd, 2014-02-28
+
+    <phant0mas> tschwinge: In your cross-gnu script while configuring hurd you
+      pass--disable-profile 
+    <phant0mas>  --without-parted . Why do we need to pass these flags to it?
+    <teythoon> well, --disable-profile turns off profiling afaiui
+    <teythoon> you should keep it
+    <teythoon> --without-parted is not needed if you have libparted
+    <phant0mas> ok
+
+
+## IRC, freenode, #hurd, 2014-03-01
+
+    <phant0mas> The hurd tarball has as a dependency autoconf
+    <phant0mas> normally it shouldn't, right?
+    <azeem> phant0mas: you mean there's no configure script?
+    <phant0mas> no no, for some reason the configure script states as
+      dependency autoconf which it shouldn't as it is a tarball
+    <azeem> phant0mas: how does it state that?
+    <phant0mas> you already have the configure script in it
+    <azeem> you get an error running it saying autoconf is required?
+    <phant0mas> yes
+    <azeem> hrm
+    <phant0mas> actually it gives an error for autoconf and git
+    <phant0mas> but if you have autoconf ,it forgets about git
+
+
+## IRC, freenode, #hurd, 2014-03-02
+
+    <phant0mas> youpi: civodul told me you are the one to ask about libpthread 
+    <phant0mas> how should I handle Hurd's libpthread in order to build it,with
+      the rest of the hurd system?
+    <phant0mas> anything I should be extra carefull?
+    <phant0mas> I am building it from the tarball
+    <youpi> phant0mas: nothing I can think of
+
+
+## IRC, freenode, #hurd, 2014-03-03
+
+    <phant0mas> youpi: what does libpthread do when we do "make
+      install-data-local-headers" ?
+    <phant0mas> Does it patch the mach headers in the prefix folder?
+    <phant0mas> tschwinge: why do we need this flag passed to configure at
+      libpthread "ac_cv_lib_ihash_hurd_ihash_create"?  
+    <youpi> phant0mas: I don't remember such detajils of the build system
+    <phant0mas> I am studying the cross-gnu script from tschwinge
+    <phant0mas> and if I try to call configure without that flag I am getting
+      the error  
+    <phant0mas> configure: error: need libihash
+    <tschwinge> Well, there's this comment: # `$TARGET-gcc' doesn't work yet
+      (to satisfy the Autoconf checks), but [...]
+    <tschwinge> At this point we're only intested in the header files, so that
+      was the "path of least resistance".
+    <phant0mas> so we are only interested in the headers of libpthread?
+    <phant0mas> do I need to pass as --prefix the folder which the include
+      folder with the mach headers are installed?
+    <tschwinge> I wonder whether it'd be better for you to directly include
+      libpthread in glibc, as Debian is doing -- probably yes.
+
+[[open_issues/packaging_libpthread]].
+
+    <phant0mas> maybe it would be much simpler that way
+    <phant0mas> let me check the debian package
+    <braunr> i'd consider it mandatory, since libpthread can't work correctly
+      now if it's not part of glibc
+    <tschwinge> Ack.
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <teythoon> braunr: did i understand it correctly that our libpthread needs
+      libihash ?
+    <teythoon> if so, won't that be a problem for phant0mas bootstrapping
+      efforts ?
+    <braunr> apparently, they're used only for thread-specific data
+    <braunr> which could now be implemented on top of TLS
+    <braunr> although i'm not sure
+    <braunr> but to answer, yes, it depends on libihash
+    <braunr> why would it be a problem ?
+    <teythoon> b/c it then forms a dependency loop
+    <braunr> which one ?
+    <teythoon> hurd->libc (which includes libpthread, thus)->hurd
+    <braunr> isn't that already the case ?
+    <teythoon> yes
+    <braunr> what's the problem then ?
+    <braunr> actually, it's not a dependency loop
+    <teythoon> y not ?
+    <braunr> hurd and libc depend on each other headers
+    <teythoon> ah, right
+    <braunr> actually, hurd-libs depend on libc headers
+    <braunr> hurd executables do depend on libc
+    <braunr> it's a bit tedious to bootstrap but not much more than the
+      three-step build required for linux already
+    <phant0mas> actually for that libihash if I pass the flag
+      "ac_cv_lib_ihash_hurd_ihash_create=yes" at configure it stops asking for
+      it
+
+    <phant0mas> when glibc's configure says "configure: running configure
+      fragment for add-on libpthread"
+    <phant0mas> does it mean it runs configure inside the folder of libpthread?
+    <youpi> I guess so
+    <phant0mas> yeh because I am getting the error configure: error: cannot
+      find sources (include/pthread/pthread.h) in .. or ..
+    <phant0mas> which I should not as I am passing
+    <phant0mas> the path to that folder
+    <phant0mas> it's an error from libpthread configure
+
+
+## IRC, freenode, #glibc, 2014-03-05
+
+    <phant0mas> when we pass to the configure script of glibc the flag
+      --enable-add-ons=something what it the process followed for that addon?
+      How does it build it?
+    <phant0mas> what is*
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <phant0mas> ../configure --without-cvs --build=i686-pc-gnu
+      --host=i686-pc-gnu --target=i686-pc-gnu --prefix="/home/manolis/gnu/"
+      --with-headers="/home/manolis/gnu/include/" --disable-profile
+      --disable-multi-arch --enable-add-ons=libpthread
+    <phant0mas> trying to configuring glibc with libpthreads as addon I get
+      this
+    <phant0mas> configure: running configure fragment for add-on libpthread
+    <phant0mas> configure: WARNING: you should use --build, --host, --target
+    <phant0mas> configure: WARNING: you should use --build, --host, --target
+    <phant0mas> configure: error: cannot find sources
+      (include/pthread/pthread.h) in .. or ..
+    <phant0mas> without libpthread it moves on
+    <phant0mas> in the include folder it should find al the headers it needs
+    <phant0mas> maybe it's a problem that I installed the headers from the
+      tarballs
+    <phant0mas> while glibc is from the git repo
+    <phant0mas> if I remove libpthread
+    <phant0mas> I get the error configure: error: Hurd headers not installed or
+      too old
+    <phant0mas> I really think I should reinstall the headers using the source
+      from the repo the headers 
+    <phant0mas> the headers from the tar ball are okay
+    <phant0mas> when I pass this flag to "--enable-add-ons=libpthread" to glibc
+      configure how can I pass flags for the libpthread configure that it's
+      called while configuring? 
+    <teythoon> phant0mas: you could look at what the debian package does
+    <phant0mas> ok
+    <braunr> phant0mas: check debian glibc for all the patches
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 89593436..c3c43f43 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -3046,3 +3046,141 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a?
     <braunr> teythoon: ok
     <braunr> teythoon: i let you fix that :p
     <teythoon> braunr: sure ;)
+
+
+## <a name="chroot">`chroot`</a>
+
+### IRC, OFTC, #debian-hurd, 2014-03-05
+
+In context of [[open_issues/nightly_builds_deb_packages]].
+
+    <gg0> installer gets stuck running os-prober, seems because
+      /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it
+      gets stuck reading it
+    <gg0> there are two proc translators: one /proc, one /target/proc
+    <gg0> anything known that could have broken /target one?
+    <gg0> anything else to check?
+    <gg0> what's unusual is that cat'ing /proc takes few seconds before giving
+      output. does initrd slow down things?
+    <gg0> */proc/mounts
+    <gg0> what does "Resource lost" mean? i get it since the beginning of
+      install
+
+
+### IRC, freenode, #hurd, 2014-03-05
+
+    <gg0> debian installer mounts installation disk under /target then probably
+      it debootstraps on it
+    <gg0> we have 2 procfs: one outside, one inside /target
+    <gg0> outside it works fine, inside cat'ing /proc/mounts it gives Resource
+      lost the first time. the second one it gets stuck
+    <gg0> oh there's only one /hurd/mtab though. inside one might have bought
+      the farm, correct?
+    <braunr> ?
+    <gg0> two /proc/mounts means you have to have two mtab translators afaiu
+    <gg0> i can't reproduce on a clean chroot
+    <teythoon> gg0: two mtab instances should be fine
+    <teythoon> also, the one under /target should only list translators "under
+    <teythoon> "under" /target
+    <gg0> teythoon: yeah i restart the dead one but at first access i get
+      "Resource lost" again and mtab dies
+    <teythoon> hm
+    <gg0> wait
+    <gg0> "Resource lost" means mtab is not running
+    <teythoon> are you sure ?
+    <teythoon> the mtab translator queries other translators
+    <teythoon> that can lead to the delay you described
+    <teythoon> and severe enough errors are handed back to the client, e.g. if
+      mtab itself gets resource lost on the very first translator it queries
+    <gg0> i'd like to clean up chroot proc and mtab stuff but settrans -fg gets
+      stuck
+    <gg0> or it gives
+    <gg0> settrans: /proc/mounts: Computer bought the farm
+    <gg0> settrans: /proc/mounts: Operation not supported
+    <teythoon> gg0: try settrans --recursive ...
+    <teythoon> then again, i never used this and it should work without, no ?
+    <gg0> same behavior
+    <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts
+    <gg0> settrans: sid-chroot/proc/mounts: Computer bought the farm
+    <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts
+    <gg0> settrans: sid-chroot/proc/mounts: Operation not supported
+    <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts
+    <teythoon> hm
+    <gg0> (last got stuck)
+    <teythoon> eh, i thought of settrans --recursive -fg sid-chroot
+    <gg0> i doesn't work. it gives no output but showtrans shows translators
+      didn't go away
+    <teythoon> showtrans shows passive translator records
+    <gg0> ah
+    <teythoon> better use fsysopts to query the active one
+    <gg0> both still active, even with fsysopts
+    <teythoon> hm
+    <teythoon> i recently improved the mtab translator, but that change has not
+      made its way into debian yet
+    * gg0 adding hurd-ci
+
+[[open_issues/nightly_builds_deb_packages]].
+
+    <gg0> btw Resource lost/mtab dying i can't reproduce on hurd01 seems
+      breaking debian installer
+    <gg0> teythoon: dist-upgraded hurd-ci, it behaves pretty same way besides
+      settrans -fg sid-chroot/proc/mounts gives "Operation not supported" right
+      away, without "Computer..farm" first
+    <gg0> following attempts it simply gets stuck
+    <braunr> time to quickdraw gdb :p
+    <gg0> teythoon: i think easy to reproduce, just need to debootstrap
+    <gg0> anything stronger than -fg?
+    <teythoon> kill
+    <gg0> well mtab has been already manually killed
+    <gg0> i could kill procfs too
+    <teythoon> yes, but then it seems to me that the translator linking in
+      netfs is buggy
+    <braunr> kill -KILL :p
+    <teythoon> :D
+    <teythoon> aka double kill
+    <gg0> ok by killing chroot procfs then accessing sid-chroot/proc/mounts
+      makes both restarting
+    <teythoon> ok, even more likely to be a netfs issue then
+    <teythoon> which is to be expected
+    <teythoon> afaik procfs is the first netfs based translator to support
+      passive translator records
+    <braunr> it is
+    <gg0> did the same on debian installer machine: both restarted, cat
+      /target/proc/mounts -> Resource lost
+    <gg0> and mtab died
+    <gg0> Computer wanted to buy the farm but it was out of resources
+
+
+### IRC, OFTC, #debian-hurd, 2014-03-05
+
+    <gg0> btw problem is cat /target/proc/mounts gives Resource lost, what
+      package could cause that?
+    <gg0> and mtab dies
+    <youpi> Resource lost often means the same as Computer bought the farm:
+      some translator has died somehow
+    <youpi> or dropped something
+    <gg0> procfs+mtab outside /target work well. inside mtab crashes
+    <gg0> http://postimg.org/image/vgz541z81/
+    <gg0> tbh i unmounted a couple, they are not all fs mounted by install, a
+      couple missing
+    <gg0> could any of them cause mtab crash?
+    <youpi> see ldd /hurd/mtab
+    <youpi> it only uses hurd libraries and pthread
+    <gg0> hurd libs and pthread _outside_ chroot, right?
+    <youpi> in principle it's the outside /hurd/mtab which gets triggered
+    <youpi> since the /target ext2fs doesn't know people use it chrooted
+    <youpi> do you have two processes?
+    <youpi> (mtab processes I mean)
+    <gg0> yes two mtabs children of their two procfs
+    <youpi> k
+    <youpi> and does setting up an mtab translator by hand gets the same?
+    <gg0> to restart mtab i have to kill its father procfs
+    <youpi> tell that to teythoon, not me, he implemented the thing :)
+    <gg0> then first access to /proc/mounts should make procfs and mtab restart
+    <gg0> yeah there's already been some troubleshooting on #hurd
+    <teythoon> youpi: i suspect some bugs in netfs translator linking
+    <teythoon> procfs is the first netfs based translator to make use of
+      passive translators
+    <gg0> you can see dead mtab and os-prober trying to grep /proc/mounts
+      http://postimg.org/image/z4fm981p7/
+    <gg0> well, there can't be problems on /target if there's not /target yet
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index 4d261627..3ddb95de 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -3226,3 +3226,31 @@ In context of [[hurd/libports]], *Open Issues*, *IRC, freenode, #hurd,
     <braunr> i don't intend the hurd to run on top of it
     <braunr> the reason it's a rewrite is to fix a whole bunch of major issues
       in one go
+
+
+## IRC, freenode, #hurd, 2014-03-03
+
+    <nalaginrut> braunr:  x15 can be compiled successfully, is it possible to
+      run it on Hurd now?
+    <braunr> nalaginrut: it will never be
+    <braunr> x15 isn't a drop in mach replacement
+    <braunr> for now it's stalled until i have more free time :/
+    <braunr> i need to rewrite virtual memory, and then implement ipc
+    <nalaginrut> oh, it's planed for standalone one?
+    <braunr> it's planned for a hurd clone
+    <nalaginrut> sounds bigger plan than I thought ;-)
+    <braunr> it is but not that much actually
+    <braunr> it's just i have really little free time currently ..
+    <braunr> and i chose to spend it on the hurd instead
+    <braunr> it's easier to fix bugs when you have little time, than think and
+      write big and difficult features like an smp scalable VM system
+    <nalaginrut> yes, I understand
+    <nalaginrut> it take huge time to think and design
+    <nalaginrut> and relative easier to fix the current one
+    <braunr> well, the whole thing is thought already
+    <braunr> what's hard is taking care of the details
+    <nalaginrut> well, you're so self-confident, to my experiences, even if all
+      the designs are in my mind, issues may make me change the original design
+      a lot ;-)
+    <nalaginrut> alright, I saw the key line, everything exists, just assemble
+      it
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
index 2b65956a..20c2cd44 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2011, 2014 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -19,7 +19,7 @@ and could perhaps be incorporated into that page.
 
 # SATA
 
-IRC, freenode, +hurd, 2011-07-24
+## IRC, freenode, #hurd, 2011-07-24
 
     <braunr> youpi: concerning the ide compatibility problem, it seems some
       bioses provide several modes
@@ -31,3 +31,22 @@ IRC, freenode, +hurd, 2011-07-24
       possibly with other IRQs
     <youpi> i.e. you need a PCI driver to handle that
     <braunr> ok
+
+
+# IRC, freenode, #hurd, 2014-03-02
+
+    <teythoon> i bought a new mainboard for my hurd box
+    <teythoon> a ga-e350n
+    <teythoon> everything looks fine, grub loads gnumach, and, (afaict) it
+      starts it, but i see no single line printed by gnumach
+    <teythoon> the thing is, that this is the second board of this kind that i
+      bought
+    <teythoon> and on the first one, gnumach did work just fine
+    <teythoon> i tried it with a live cd, the same cd worked on the first
+      board, but does not on the second
+    <teythoon> also, i'm kind of surprised to see nothing at all from gnumach
+    <teythoon> i mean, it's loaded by grub
+    <youpi> teythoon: you could try to put *(char*)0xb8000 = 'X' starting from
+      c_boot_entry
+    <youpi> just to see at least something
+    <teythoon> i'll try, thanks :)
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 33635b80..932e11a6 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -1327,3 +1327,22 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
     <teythoon> load it from grub instead of /hurd/ext2fs.static
     <teythoon> look at the grub config for how this is done
     <teythoon> let me know if it worked ;)
+
+
+# IRC, freenode, #hurd, 2014-03-04
+
+    <bwright> Can I run a single instance of hurd on multiple computers
+    <bwright> With them acting as different servers?
+    <braunr> no
+    <bwright> Like the fs server on one pc etc.
+    <bwright> Which os could I do this with?
+    <bwright> I assumed Mach RPC would support that.
+    <braunr> it can
+    <braunr> but we don't use it that way
+    <braunr> plan9 is probably better suited to what you want
+    <braunr> inferno too
+    <braunr> maybe dragonflybsd
+    <bwright> Yep.
+    <bwright> irAwesome.
+    <bwright> Plan9 is exactly it.
+    <braunr> enjoy
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index baa21bbb..407a104c 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -338,3 +338,11 @@ In context of [[select]].
       anyway :)
     <desrt> (although it will soon...)
     <braunr> nice
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <desrt> braunr: bit of a warning: i released the glib that depends on
+      working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it
+      will be landing in debian within the next days
+    <braunr> desrt: ok
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 9d8bf509..e7083557 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -614,6 +614,16 @@ In context of [[libpthread]].
     <braunr> primitives*
 
 
+## IRC, freenode, #hurd, 2014-03-08
+
+    <gg0> what to do if network freezes?
+    <teythoon> gg0: depends on what caused the freeze
+    <teythoon> gg0: you could try to kill the netdde process
+    <gg0> it's just apt-get'ing, download phase
+    <braunr> yess kill netdde
+    <braunr> there are known deadlocks in netdde
+
+
 # IRC, freenode, #hurd, 2012-08-18
 
     <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 4dad229f..ad7b3c72 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1855,6 +1855,45 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852
             <braunr> teythoon: i think it should be in glibc
             <braunr> maybe in mach/
 
+      * POSIX record locking
+
+        IRC, freenode, #hurd, 2014-02-27:
+
+            <azeem_> tschwinge: schould POSIX record locking be on
+              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing
+              as well. or is that strictly a Hurd thing? (I don't remember)
+            <tschwinge> azeem_: Neither do I :-), but I'll have a look later
+              on.
+
+      * <a name="execve_relative_paths">`execve` with relative paths</a>
+
+        [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
+        "4BFA500A.7030502@gmail.com"]].
+
+        IRC, freenode, #hurd, 2014-03-05:
+
+            <teythoon> youpi: what about the exec_filename patch series? [...]
+            <youpi> Roland was disagreeing with it
+
+      * <a name="mount">`mount`/`umount`</a>
+
+        IRC, freenode, #hurd, 2014-03-01:
+
+            <gnu_srs1> Hi, how to handle packages depending on mount.h, et al?
+              On Hurd mount/umount is supplied by hurd is not in libc?
+            <azeem> gnu_srs1: mount or mount.h?
+            <gnu_srs1> mount.h et al
+            <gnu_srs1> man 2 mount
+            <azeem> what is the question then?
+            <gnu_srs1> some packages expect the mount 2 functionality
+              available, not by the external command mount/umonut
+            <gnu_srs1> umount*
+            <gnu_srs1> azeem: one example is fuse
+            <teythoon> gnu_srs1: that is correct
+            <teythoon> gnu_srs1: i put a small hacks entry in the list about
+              moving the mount/umount functionality from our utilities to the
+              libc
+
     For specific packages:
 
       * <a id=octave>[[octave]]</a>
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
index 273f02fd..4ae9807b 100644
--- a/open_issues/glibc/debian/experimental.mdwn
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -225,6 +225,15 @@ Now in unstable.
     <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon
 
 
+## IRC, freenode, #hurd, 2014-03-03
+
+    <youpi> braunr: did you test whether
+      https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6
+      does indeed fix locale generation?
+    <braunr> youpi: it doesn't, which is why i applied
+      http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44
+
+
 # IRC, OFTC, #debian-hurd, 2013-06-20
 
     <youpi> damn
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index d5c0272c..a66202c8 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -561,6 +561,23 @@ Tom Van Cutsem, 2009.
     <teythoon> ^^
 
 
+### IRC, freenode, #hurd, 2014-03-02
+
+    <youpi> braunr: what is the status of the thread storm issue? do you have
+      pending code changes for this?
+    <youpi> I was wondering whether to make ext2fs use adaptative locks,
+      i.e. spin a bit and then block
+    <youpi> I don't remember whether anybody already did something like that
+    <braunr> youpi: no i don't
+    <braunr> youpi: i attempted switch from spin locks to mutexes once but it
+      doesn't solve the problem
+    <braunr> switching*
+    <gg0> found another storm maker:
+    <gg0> $ dpkg-reconfigure gnome-accessibility-themes
+    <gg0> aka update-icon-caches /usr/share/icons/HighContrast
+    <youpi> braunr: ok
+
+
 ## Alternative approaches:
 
   * <http://www.concurrencykit.org/>
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
index da7bdc7d..fc9c2f18 100644
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ b/open_issues/nightly_builds_deb_packages.mdwn
@@ -108,3 +108,853 @@ See also [[nightly_builds]].
     <pere> I would like to see something like <URL:
       http://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_lxde/lastBuild/
       > for hurd.
+
+
+## IRC, OFTC, #debian-hurd, 2014-02-26
+
+    * gg0 setting up jenkins, almost time to give up
+    <pere> gg0: why do you set up jenkins?
+    <gg0> because i want to fail at doing all things, not just something ;)
+    <gg0> oops seems my setup just sent emails to jenkins+debian-qa
+      holger@layer-acht.org :/
+    <pere> #debian-qa will understand. :)
+
+
+## IRC, OFTC, #debian-hurd, 2014-02-27
+
+    <gg0> almost managed to multiboot
+    <gg0> it gets stuck at "start ext2fs.static"
+    <gg0> any idea?
+    <teythoon_> multiboot what ?
+    <pere> gg0: that sound like the race blocking boot some times.
+    <teythoon_> no
+    <teythoon_> that'd print more
+    <gg0> teythoon: booting hurd with qemu without grub
+    <teythoon> oh cool
+    <teythoon> can you paste your qemu arguments somewhere ?
+    <azeem> probably ext2fs.static got passed a wrong commandline?
+    <gg0> they are the grub ones but gnumach needs to be uncompressed
+    <gg0> otherwise qemu complains saying linux kernel is too old
+    <teythoon> yes, i got past that one
+    <teythoon> but my qemu keeps crashing
+    <teythoon> can you please paste the command you used ?
+    <gg0> "qemu: linux kernel too old to load a ram disk"
+    <gg0> well, my fun level would really decrease :)
+    <azeem> if you pasted the commands you used?
+    <youpi> gg0: if it talks about "linux", it's not actually using multiboot
+    <gg0> azeem: yep :)
+    <gg0> youpi: i think it just can't distinguish, btw bt uncompressing it, it
+      boots
+    <youpi> gg0: well, "any idea?" means you are requesting help
+    <youpi> but without pasting the line, we can't divine what can be going
+      wrong
+    <youpi> gg0: well, if it can't see that gnumach *can* handle multiboot
+      modules, qemu is very broken
+    <gg0> modules are all loaded, multiboot options seems working well
+    <gg0> ie. -initrd "file1 arg=foo,file2"
+    <azeem> arg=foo?
+    <teythoon> fwiw, i tried http://paste.debian.net/84408/
+        kvm -m 256 \
+        -kernel gnumach \
+        -append 'gnumach root=device:hd0s1' \
+        -initrd "0.master/hurd/ext2fs.static ext2fs \
+                        --multiboot-command-line='\${kernel-command-line}' \
+                        --host-priv-port='\${host-port}' \
+                        --device-master-port='\${device-port}' \
+                        --exec-server-task='\${exec-task}' -T typed device:hd0s1 \
+                        '\$(task-create)' '\$(task-resume)',\
+        0.master/lib/ld.so.1 exec /hurd/exec '\$(exec-task=task-create)'" \
+        -drive 'file=/media/pool/hurd-tests/image.qcow2,cache=writeback' -snapshot
+    <gg0> http://postimg.org/image/esywbywh9/
+    <gg0> azeem: pasted from man qemu
+    <gg0> here screenshot ^
+    <teythoon> is this the stock debian ext2fs.static ?
+    <azeem> gg0: are the ext2fs.static arguments cutoff at
+      "-exec-server-[...]"?
+    <gg0> teythoon: yes, everything from last CD image
+    <teythoon> which you copied to the host ?
+    <gg0> azeem: as you can see just below --exec-server-task=3
+    <gg0> teythoon: loop mounted, like jenkins does
+    <teythoon> ok
+    <teythoon> the early hurd bootstrap code is very delicate
+    <teythoon> and often, the bootstrap just hangs with no indication why
+    <teythoon> we won't even notice the rootfs or the exec server crashing for
+      example
+    <gg0> replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths with yours:
+    <gg0> --kernel gnumach --initrd "initrd.gz initrd
+      \$(ramdisk-create),ext2fs.static ext2fs
+      --multiboot-command-line=\${kernel-command-line}
+      --host-priv-port=\${host-port} --device-master-port=\${device-port}
+      --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
+      \$(task-create) \$(task-resume),ld.so.1 exec /hurd/exec
+      \$(exec-task=task-create)"
+    <teythoon> you are missing the kernel command line, no?
+    <gg0> teythoon: afaiu it takes it at runtime from itself if any
+    <gg0> if anyone passes --append
+    <gg0> in pasted screenshot i pass desktop=lxde
+    <gg0> need to pass something like gunzip:device:rd0? on cd image it doesn't
+      pass anything
+    <youpi> no, it's already passed to ext2fs in the multiboot command line
+    <gg0> ok
+    <gg0> -T typed
+    <teythoon> i do not see any significant difference between your arguments
+      and mine
+    <teythoon> for me, kvm/qemu still crashes
+    <teythoon> % kvm --version
+    <teythoon> QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian),
+      Copyright (c) 2003-2008 Fabrice Bellard
+    <gg0> teythoon: i don't have any "'" :) and too many gnumach, one in append
+      too
+    <teythoon> yes
+    <teythoon> but that shouldn't cause kvm to crash
+    <gg0> oh
+    <gg0> here QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3)
+    <gg0> jessie on amd64
+    <gg0> seems quite older
+    <teythoon> indeed
+    <gg0> wheezy vs current jessie
+    <teythoon> yes
+    <gg0> teythoon: qemu 1.7.0 is on wheezy-backports
+    <gg0> anyone tried to reproduce it?
+
+
+## IRC, freenode, #hurd, 2014-02-27
+
+    <gg0> options to boot hurd with qemu multiboot:
+    <gg0> 17:54 < gg0> replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths
+      with yours:
+    <gg0> 17:54 < gg0> --kernel gnumach --initrd "initrd.gz initrd
+      \$(ramdisk-create),ext2fs.static ext2fs
+      --multiboot-command-line=\${kernel-command-line}
+      --host-priv-port=\${host-port} --device-master-port=\${device-port}
+      --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
+      \$(task-create) \$(task-resume),ld.so.1 exec /hurd/exec
+      \$(exec-task=task-create)"
+    <gg0> gnumach needs to be uncompressed
+    <gg0> this gets stuck at "start ext2fs.static:"
+    <teythoon> indeed, same for me
+    <braunr> i strongly suspect qemu multiboot support to be incomplete
+    <braunr> i couldn't make it work well enough with x15 either
+    <gg0> if gnumach is compressed, "qemu: linux kernel too old to load a ram
+      disk"
+    <braunr> i think that's a grub specific feature
+
+
+## IRC, freenode, #hurd, 2014-02-28
+
+    <gg0> start ext2fs.static2: ext2fs: device:rd0: panic: get_hypermetadata:
+      bad magic number 0xd7f0 (should be 0xef53)
+    <gg0> \o/ it boots
+    <teythoon> gg0: what was wrong ?
+    <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz
+      \$(ramdisk-create),/path/to/ext2fs.static
+      --multiboot-command-line=\${kernel-command-line}
+      --host-priv-port=\${host-port} --device-master-port=\${device-port}
+      --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
+      \$(task-create) \$(task-resume),/path/to/ld.so.1 /hurd/exec
+      \$(exec-task=task-create)"
+    <teythoon> gg0: uh, using absolute paths fixes this ?
+    <gg0> teythoon: not necessary, just to be clearer
+    <gg0> solved by removing initrd between initrd.gz and ramdisk-create, and
+      ext2fs between ext2fs.static and multiboot-command-line
+    <gg0> also exec between ld.so.1 and /hurd/exec
+    <teythoon> gg0: oh, i see
+
+
+## IRC, OFTC, #debian-hurd, 2014-02-28
+
+    <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz
+      \$(ramdisk-create),/path/to/ext2fs.static
+      --multiboot-command-line=\${kernel-command-line}
+      --host-priv-port=\${host-port} --device-master-port=\${device-port}
+      --exec-server-task=\${exec-task} -T typed gunzip:device:rd0
+      \$(task-create) \$(task-resume),/path/to/ld.so.1 /hurd/exec
+      \$(exec-task=task-create)"
+    <gg0> multiboot works
+    <pere> cool.
+    <pere> gg0: are you able to feed the installer one of the preseed files at
+      <URL: http://jenkins.debian.net/d-i-preseed-cfgs/ >?
+    <gg0> though jenking translates double quotes, need to escape the world
+    <pere> debian_sid_daily_lxde_preseed.cfg seem like a good candiate. :)
+    <gg0> pere: i'm working on that, stuck at working around that mandatory
+      double quote
+    <gg0> *initrd double quote
+    <youpi> gg0: could you paste your command line on the hurd wiki?
+    <gg0> ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot
+    <gg0> let's provide a preseed
+    <gg0> shouldn't there be some info/debug consoles from tty 2 to 4?
+    <youpi> there should be
+    <gg0> maybe i can't send alt+NUM from vlc
+    <youpi> ah, yes
+    <youpi> you need to use the menu for that
+    <youpi> press f8
+    <gg0> great
+    <gg0> (found out C+A+{1,2,3} give interesting monitor,serial,parallel
+      consoles btw)
+    <gg0> not much options on menu
+    <gg0> just clipboard management, quit, full screen, send ctrl-alt-del, send
+      F8
+    * gg0 takes "great" back
+    <gg0> i guess it depends on vnc implementation
+    <gg0> don't ask me how i found out one can switch console with
+      ... left/right arrow keys
+    <youpi> without alt pressed?
+    <gg0> without alt pressed
+    <youpi> I've already seen that with qemu, when focusing into/out from the
+      qemu window by using alt
+    <youpi> somehow the alt state gets stuck
+    <gg0> so you mean if i close viewer then reattach it, it doesn't happen
+      anymore? let's see
+    <gg0> you're right
+    <gg0> though yes alt+left/right switches consoles
+    <youpi> the last is expected :)
+    <gg0> it says kbd-udeb doesn't exist so it falls back to
+      hurd-debian-ports-udeb
+    <youpi> that's not a problem
+    <gg0> no partman-auto?
+    <youpi> it should be working
+    <gg0> i meant if it was installed but yes it gets it along with others
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-01
+
+    <gg0> partman-auto would need to be patched to be able to discover
+      available disks
+    <gg0> worked around by forcing /dev/hd1, jenkins creates disk with index=1
+    <gg0> stuck at installation-report installed. seems it can't manage to
+      umount(then remount) /cdrom gracefully
+    <gg0> or better it gets stuck at apt-cdrom ident
+    <gg0> something like https://bugs.debian.org/598457
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-02
+
+    <gg0> teythoon: curiosity, correct qemu multiboot options still make old
+      qemu crashing?
+    <teythoon> gg0: no idea, i'll try it later
+
+    <gg0> youpi: any chance to have monthly/weekly (daily would be too much i
+      guess) isos/images? can i help somehow?
+    <youpi> I am wondering why having that
+    <youpi> since we have up-to-date mirrors
+    <gg0> i'd say to install with latest installer/gnumach/hurd/eglibc 
+    <youpi> so that means also rebuilding the d-i image
+    <gg0> and in general to not have to manually produce them
+    <pere> youpi: the point is to automatically test the current images using
+      jenkins.debian.net, I believe.  for that to work, current images need to
+      exist. :)
+    <gg0> not only. i think saving youpi's time is also important
+    <youpi> gg0: it doesn't really take me much time to generate images
+    <youpi> it's about a few command lines to start, and then work on something
+      else :)
+    <gg0> well though it still requires manual intervention which is not
+      scheduled and also error prone btw
+    <youpi> gg0: I guess the most important help you could provide would be to
+      actually track when the autobuild breaks :)
+    <gg0> what pros keeping it manual? i don't think disk space saving
+    <youpi> it's not really a question of manual, but the frequency
+    <youpi> I prefer to test manually before uploading something on my
+      somehow-official directory on people, anyway
+    <youpi> but that doesn't mean we can't have weekly builds somewhere else
+      indeed
+    <youpi> it's just that for tests it's good to have several images backlog,
+      but then it takes disk
+    <gg0> well we could keeping "official" ones + say 6 monthly and say 4
+      weekly
+    * gg0 randomizes retention
+    <gg0> -ing
+    <teythoon> gg0: check out my hurdtest program
+    <teythoon> it updates qemu images automatically, and runs a test suite,
+      creates snapshots
+    <gg0> youpi: you'd just take actually care of official ones
+    <teythoon> and it can zero-fill the disk images to compact them for
+      publication
+    <youpi> gg0: and have a cron for the others
+    <youpi> on mirror.ftp-master
+    <gg0> nice, we already have a disk image generator then
+    <teythoon> i shall clean it up and merge stuff that i have changed locally
+    <teythoon> i covered it in my early blog posts
+    <teythoon> i use it extensively to test the packages from hurd-ci
+    <gg0> great. so usually at this point /me can't do anything so good work!
+      lol
+    <youpi> crontabs are in place, scheduled on monday mornings
+    <youpi> I have already completed a run, can be seen in weekly-0
+    <gg0> great!
+    <gg0> assuming it will work forever without maintenance, how many minutes
+      you'll save per month? :)
+    <youpi> I don't think that'll save me time per month
+    <youpi> since it's just an additional thing
+    <gg0> youpi: so weekly-0 will always be the latest weekly (same about
+      monthly) ?
+    <youpi> yes
+    <gg0> how about adding -YYYYMMDD after -1 CD/DVD/NETINST number?
+    <youpi> that'd mean more scripting
+    <gg0> just to distinguish them
+    <youpi> we already have timestamps from the server
+    <gg0> unfortunately i can't script myself, i can suggest though :)
+    <gg0> or scripts are available somewhere?
+    <gg0> so current/ should be a link to weekly-0?
+    <youpi> on mirror.ftp-master.debian.org, but I guess you don't have access
+      to it
+    <youpi> no
+    <youpi> definitely no
+    <youpi> the point of current/ is to have something tested
+    <gg0> ok
+    <youpi> while weekly/monthly are most probably to get broken
+    <youpi> so let's not point people at that
+    <gg0> same story about diskimage? how do you generate them?
+    <gg0> how about teythoon's way?
+    <youpi> I do it by hand at the moment, but scripts would be welcome indeed
+    <youpi> http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.txt
+    <gg0> ok now stuck at grub install
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-03
+
+    <gg0> i probably should force /dev/hd0 as i did for /dev/hd0s1 as root
+      device
+    <gg0> if it's possible
+    <youpi> what do you mean by forcing /dev/hd0s1 as root device ?
+    <youpi> you shouldn't have to do that
+    <youpi> my fear is that these additional images will mostly just bring
+      additionnal reports
+    <gg0> i had to specify it in preseed
+    <youpi> which won't really decrease the amount of work
+    <gg0> as partman-auto/disk
+    <gg0> it can recognize available disks
+    <gg0> that's also because it can't list root partitions on rescue mode
+    <youpi> well, all I can say without having (again) to spend time on it, is
+      that you're not supposed to have to do that
+    <youpi> why are you using rescue mode?
+    <youpi> if it can't list root partitions, then of course partman can't work
+    <gg0> well, rescue mode should work
+    <youpi> if you delve into non-tested parts of d-i, you'll surely encounter
+      bugs
+    <youpi> well, less "should" than plain "d-i"
+    <youpi> in that I've never really tested it
+    <youpi> so don't be surprised that some bugs remain
+    <gg0> no problem
+    <youpi> but again, we don't really need  more bug reports
+    <youpi> but rather bug fixing
+    <youpi> we already have enough to fix, no need to delve into advanced
+      things
+    <gg0> sure, i'm just trying to make it work with all its limitations
+    <gg0> it autopartition the disk well, it can't just make one choose among
+      disks because it can't probe and list them
+    <youpi> then fix the probe & list
+    <gg0> i'd like doing it, i'm better at working around for now though :)
+    <gg0> one blocker is mount/umount stuff
+
+[[glibc#mount]].
+
+    <youpi> well, you'll have to get into fixing bugs for real someday
+    <youpi> otherwise this is just adding to TODO lists
+    <youpi> what mount/umount stuff?
+    <gg0> (took a quick look at partconf)
+    <gg0> non-existent mount.h for instance
+    <gg0> do we have replacements?
+    <youpi> not that I know of
+    <gg0> 21:53 < teythoon> gnu_srs1: i put a small hacks entry in the list
+      about moving the mount/umount functionality from our utilities to the
+      libc
+    <youpi> ok
+    <gg0> another thing i'd really like to see would be a physical shutdown,
+      halt-hurd which actually poweroffs the system
+    <gg0> how to switch to sysvinit by default? next sysvinit upload?
+    <youpi> physical shutdown means implementing APM or ACPI
+    <gg0> have to teach jenkins it can shut it down :/
+    <youpi> I'm extremely far from having the will for this
+    <youpi> switching to sysvinit by default is a matter of saying that we want
+      to do it
+    <youpi> I already asked for this on the list without answer IIRC 
+    <gg0> i can't find anything
+    <youpi> anyway, just propose on the list
+    <gg0> d-i grub-installer/bootdev string /dev/hd0 - here it is
+    <gg0> next run should not need any interaction, though it needs 20 mins to
+      understand it has to destroy it and run won't be successful :/
+    <gg0> due to missing acpi/apm
+    <gg0> first graphical automated install http://postimg.org/image/vgagj06q7/
+    <gg0> it seems 720x400
+    <gg0> though jenkins passes video=vesa:ywrap,mtrr vga=788
+    <gg0> by reconnecting it switched to 800x600
+      http://postimg.org/image/h32qjykrx/
+    <gg0> but seems stuck now and i can't even switch from graphical to
+      consoles
+    <gg0> unusually stuck at scanning cdrom
+    <gg0> i'll check text install to see if it gets stuck there too
+    <gg0> text install switches from 720x400 to 640x400
+    <gg0> i confirm it gets stuck on scanning cdrom, i guess because of this
+      one https://bugs.debian.org/728153 which already broke load-install-cd i
+      already had to workaround
+    <pere> gg0: are you in contact with h01ger to update jenkins.debian.net
+      with your cool installation code?
+    <gg0> pere: still trying to have something working
+    <gg0> plus with new weekly cd, apt-cdrom bug makes install getting stuck at
+      first Scanning cdrom:
+    <gg0> 03:44 < gg0> i confirm it gets stuck on scanning cdrom, i guess
+      because of this one https://bugs.debian.org/728153 which already broke
+      load-install-cd i already had to workaround
+    <youpi> do we really need the CD-1 image in weekly builds?
+    <gg0> just netinst?
+    <youpi> yes
+    <gg0> well, i don't know debian installer well. what's the difference
+      between CD and NETINST besides that CD has more packages user doesn't
+      need to download?
+    <gg0> has CD anything not in NETINST which is worth to continously test?
+      (talking about jenkins)
+    <youpi> that's only it, yes
+    <gg0> btw new ACPI on hurd consists of serial console to file + looping
+      grep "In tight loop: hit ctl-alt-del to reboot" && kill qemu
+    <gg0> anything better?
+    <gg0> filed http://bugs.debian.org/740673
+    <gg0> without a patch just to express my great laziness :p
+    <youpi> well, I'm afraid nobody in the debian-boot team will attempt
+      anything at this
+    <youpi> is it reproducible on linux?
+    <gg0> nope
+    <gg0> my guess is that's due to udev, need a deeper check btw
+    <gg0> i mean non-udev cases like hurd maybe are not handled well
+    <youpi> maybe try on kfreebsd then?
+    <gg0> just guessing
+    * gg0 trying on kfreebsd
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-04
+
+    <gg0> hurd install started getting stuck running os-prober, final grub
+      install phase
+    <gg0> youpi: yes i confirm it affects kfreebsd too
+    <youpi> then please say so in the bug
+    <youpi> otherwise most probably but me in the debian-boot team will care
+    <youpi> +nobody
+    <gg0> that might get more attention from d-boot team?
+    <gg0> ok
+    <youpi> also Cc debian-bsd@
+    <youpi> they will care
+    <youpi> and tell about the hint as being the non-udev case
+    <youpi> too much information or ideas is never a bad thing :)
+    <gg0> done
+    <gg0> (now i know notfound does remove found versions instead of adding
+      notfound versions)
+    <gg0> crazy things. to unblock os-prober i had to settrans -fg
+      /target/media/./cdrom0
+    <gg0> it was mounting /dev/hd0s1 ...
+    <gg0> i suspect apt-cdrom is to blame again
+    <gg0> ok now jenkins just managed to start the installed system
+    <gg0> and it's configured to make vncdo testing it
+    <gg0> i'd need a graphical-working cd with old-apt to continue
+    <gg0> let's try to install old apt on weekly-0
+    <gg0> "cdrom drive contains a cd which cannot be used for installation"
+    <gg0> i think a sort of non-authenticated anymore
+    <gg0> ehm.. http://paste.debian.net/plain/85224/
+    <pere> gg0: nice. :)
+    <gg0> with apt 0.9.15.1 which should be good
+    <gg0> pere: it did mount /dev/hd0s1 under /media/cdrom0
+    <gg0> 0.9.15.5, correctly i think, asks to insert it cdrom. but finally
+      both mount /dev/hd0s1 instead of /dev/hd2
+    <gg0> -it
+    <gg0> cause they both can't detect where cdrom is i guess
+
+
+## IRC, freenode, #hurd, 2014-03-04
+
+    <gg0> we could talk about apt-cdrom https://bugs.debian.org/740673
+    <gg0> how should system recognize cdrom device?
+    <gg0> there's no /dev/cdrom link to actual cdrom device
+    <gg0>  /dev/cd[01] are scsi devices if i'm not wrong
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-05
+
+    <gg0> installer gets stuck running os-prober, seems because
+      /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it
+      gets stuck reading it
+
+[[hurd/translator/mtab/discussion#chroot]].
+
+    <gg0> youpi: could you publish script to rebuild CDs you scheduled? with
+      last official CD (20140212) mtab on /target dies and that seems getting
+      os-prober stuck. last (and only) weekly has recent apt-cdrom so it gets
+      stuck wrongly asking to change cdrom
+    <youpi> see the readme file
+    <youpi> err, you say it's the 0212 build which fails?
+    <youpi> I had tested that before uploading
+    <youpi> so the issue comes form the installed packages, not from the CD
+      udebs
+    <youpi> did you test with no network mirror?
+    <gg0> no i didn't. should it find all packages it needs from cd?
+    <youpi> sure, that's what netinst and dvd-1 are, as opposed to netboot
+    <gg0> lxde desktop probably not
+    <youpi> indeed
+    <youpi> though with the dvd in principle it should
+    <youpi> (if all deps were avaijlable at image build time)
+    <youpi> gg0: btw if you haven't noticed, there's a daily too
+    <gg0> youpi: till apt-cdrom is not fixed, they all will be broken, stuck at
+      "Scanning cdrom"
+    <youpi> gg0: did you try to bisect which git change produces the apt-cdrom
+      bug?
+    <gg0> youpi: all in bug in question
+    <gg0> youpi: https://bugs.debian.org/740673
+    <youpi> is there the precise git commit id in the bug log?
+    <gg0>
+      http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=commitdiff;h=62dcbf84c4aee8cb01e40c594d4c7f3a23b64836
+    <youpi> well, don't tell that to just me, but the bug report...
+    <gg0> bug report says "See <bug>" where bug is
+      https://bugs.debian.org/728153
+    <youpi> gg0: bug report doesn't say it was *tested* that it is that changes
+      which broke things
+    <gg0> i don't think we could get it reverted just because it breaks hurd
+      (+kfreebsd to check) debian installer
+    <youpi> of course, but that's at least where developers can have a look at
+    <gg0> well ok i could have been more clear
+    <youpi> it's *WAY* better than having no idea where to have a look at
+    <youpi> gg0: btw, that's why the README file advises not to use a network
+      mirror, to avoid such kind of issues
+    <youpi> you can't expect sid not to be not-broken :)
+    <gg0> one gets Resource lost even when install is just started, no packages
+      from any mirror
+    <gg0> https://bugs.debian.org/740673#19
+
+    * gg0 installing without mirrors, without desktop, without lxde
+    <gg0> same problem
+    <gg0> so problem has nothing to do with installing from mirrors
+    <youpi> what's odd is that I don't get this issue at all with the 20140212
+      upload at least
+    <youpi> kvm -cdrom debian-7.0-hurd-i386-NETINST-1.iso -drive
+      file=blip,cache=unsafe -m 1G
+    <youpi> no more, no less
+    <gg0> it must depend on preseed and/or kernel append options
+    <youpi> possibly
+    <gg0> oh wait here qemu multiboot
+    <youpi> that shouldn't have any impact
+    <youpi> did you leave the command line somewhere on the wiki so I can try
+      with it, just to be sure?
+    <gg0>
+      http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot
+    <gg0> 5€ on qemu multiboot as the culprit
+    <gg0> you should also see it sometimes double-mounts /dev/hd0s1 under
+      /target and /target/./media/cdrom(!)
+    <gg0> but that's due to new apt it in-targets (= installs under /target)
+    <youpi> gg0: rather use the gnumach, ld.so and ext2fs.static from the ISO
+      image you are booting
+    <youpi> especially for ld.so, which has to be the same as the libc
+      installed in the initrd
+    <youpi> ah, you're getting the initrd there too
+    <youpi> well, really use the same as the ISO
+    <gg0> i already do
+    <youpi> ah, ok, so the wiki example is just with current
+    <youpi> but the wiki example doesn't use -cdrom to provide the ISO ?
+    <gg0> no it doesn't even mention you could also use a cdrom
+    <gg0> it just shows how to use qemu multiboot options
+    <youpi> it seems one have to avoid any blanks in the multiboot option
+    <youpi> notably before file names
+    <gg0> well, actually it works but it's rather incomplete
+    <youpi> well, it shows how to boot the installer
+    <youpi> not how to boot an installed system
+    <gg0> removed spaces, added <other_qemu_options> option
+    <gg0> here qemu binary is qemu-system-x86_64 instead of qemu-kvm and it
+      crashes without --enable-kvm
+    <gg0> qemu: fatal: Trying to execute code outside RAM or ROM at
+      0x000000010010001e
+    <youpi> rather use qemu-system-i386
+    <gg0> i was just complaining i wrote qemu-kvm on wiki but i did never
+      actually run that command as is
+    <gg0> ouch right, -i386 doesn't require enable-kvm
+    <gg0> (i'll never know why)
+    <youpi> -x86_64 is buggued
+    <youpi> 0x000000010010001e should have been truncated to 0x0010001e since
+      it's 32bit mode
+    <gg0> i see
+    <gg0> any luck reproducing mtab issue?
+    <youpi> still not
+
+[[hurd/translator/mtab/discussion#chroot]].
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-06
+
+    <youpi>  http://paste.debian.net/85535/
+    <youpi> no issue
+    <youpi> (no network mirror)
+    <gg0> full install till grub-installer?
+    <youpi> yes
+    <youpi> and reboot
+    <gg0> -append 'auto=true mirror/suite=sid console=com0 priority=critical
+      locale=en_US keymap=us
+      url=http://10.0.2.1//d-i-preseed-cfgs/debian_sid_daily_hurd_lxde_preseed.cfg
+      video=vesa:ywrap,mtrr vga=788 -- quiet'
+    <gg0> i should provide preseed too
+    <youpi> well, of course
+    <youpi> always provide as much information as possible
+    <youpi> so there's also your preseed file
+    <gg0> not much different from
+      http://jenkins.debian.net/d-i-preseed-cfgs/debian_sid_daily_lxde_preseed.cfg
+    <gg0> but you need to force a couple of things + ugly workaround for broken
+      apt-cdrom ident
+    <youpi> well, I didn't even know that jenkins had that pressed file
+    <youpi> well, here apt-cdrom is not needed
+    <youpi> +hacks
+    <youpi> since that's the old image we're checking
+    <gg0> well ok, given you take everything from cd only, yes
+    <gg0> here no mirror, no desktop, no lxde
+      http://paste.debian.net/plain/85538/
+    <gg0> i'm trying this one too
+    <gg0> main difference seems to be i usually use CD-1, not NETINST
+    <gg0> had to add -net nic,vlan=0 -net
+      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
+    <gg0> here target mtab is already crashed
+    <gg0> because some package already tried to read /target/proc/mounts
+    <gg0> youpi: reproduced there?
+    <gg0> .o(well, maybe he's been sleeping for ~50 mins)
+    <youpi> nope, I'm working on upgrading servers
+    <youpi> I'm sorry, but your testcase is not really easy to reproduce :)
+    <gg0> do you have apache on your host? just put preseed in the root, vm
+      will take it
+    <gg0> full command line is what you pasted + -net nic,vlan=0 -net
+      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
+    <gg0> what else? when it starts debstrapping, open a console and check
+      procfs and mtab processes
+    <gg0> err, what you paster + -append i pasted + -net nic,vlan=0 -net
+      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
+    <gg0> *pasted
+    <gg0> which is http://paste.debian.net/plain/85554/
+    <gg0> surely keyboard layout doesn't help, here at least
+    * gg0 tries to reproduce without preseed
+    <gg0> i can't reproduce it
+    <gg0> it doesn't crash
+    * gg0 enabling all options but preseed
+    <gg0> need to wait 31% of Installing base system to have the second procfs
+    <gg0> ok got Resource lost even without preseed
+    <gg0> youpi: you can reproduce it by adding -append console=com0 to what
+      you pasted. that breaks grub-installer, it gets stuck at 66%, while runs
+      os-prober
+    <youpi> ah
+    <gg0> how can that affect /target/proc/mounts?
+    <youpi> no idea
+    <gg0> couldn't daily be here? http://d-i.debian.org/daily-images/
+    <youpi> if I knew how to push files there, sure
+    <gg0> asking on #debian-boot would be a starting point i guess
+    <youpi> probably
+    <gg0> me asking on behalf of youpi would not a good one i think, given
+      whatever will the answer i can't do anything
+    <gg0> +be
+    <youpi> you can still trasmit me
+    <youpi> never understimate the little time you can save other people by
+      doing some bits of work
+    <gg0> well, i would not even have to repaste lines here given you joined
+      there too
+    <gg0> never understimate what "help with laziness" means :)
+    <youpi> not necessarily repasting, but at least highlighting me
+    <youpi> so I know where to read in the #d-b logs
+    <gg0> there are no isos there, i'm missing something
+    <youpi> there are no daily isos
+    <youpi> only weekly isos
+    <gg0> so seems i have to reask initial question with this url
+      http://cdimage.debian.org/cdimage/weekly-builds/
+    <gg0> oh wait they are from testing, that's why no hurd ones
+    <gg0> i guess they could be here though
+      http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/
+    * gg0 asking on #debian-cd
+    * gg0 would ignore non-DD gg0 asking whatever
+    <youpi> people don't really ask themselves who is a DD and who is not
+    <youpi> as long as you provide information in your question, it'll get
+      answered
+    <gg0> teythoon: interested in reproducing mtab-dying-under-chroot?
+    <gg0> oh just realized it's not only under a chroot, chroot is on another
+      disk. might that make the difference?
+    <gg0> i didn't try to reproduce it by creating a chroot on a different
+      disk, which is what installer does
+    * gg0 wonders if it would have been better filing a bug against
+        cdimage.debian.org
+    <gg0> if no one fixes console=com0 thing, i have to think about a new acpi
+    <gg0> ok managed to workaround apt bug in installer, i can graphically
+      install last weekly
+    <gg0> no console=com0 means no vm shutdown though
+    <pere> gg0: wow.  impressed!
+    <gg0> patching CI to make CI workaround bugs CI spots is not so good
+    <gg0> any idea about another shutdown trick without console=com0 till
+      teythoon or youpi fix it?
+    <pere> nope
+    <gg0> current one: vm writes serial console to file and host loops grepping
+      "In tight loop: hit ctl-alt-del to reboot"
+    <gg0> -watchdog might be an alternative
+    <gg0> if there are watchdog agents that can run on hurd
+    <gg0> "watchdog" for instance doesn't build on hurd
+    <pere> it need kernel support
+    * gg0 testing -add-fd
+
+
+## IRC, freenode, #hurd, 2014-03-07
+
+    <gg0> teythoon: just mounted an additional fs, it's mounted but not present
+      in proc/mounts
+    <braunr> gg0: how did you mount it ?
+    <gg0> i was under /root, sid-chroot is the mountpoint. i did mount /dev/hd3
+      sid-chroot (relative path)
+    <braunr> does fsysopts confirm a new translator is running on sid-chroot ?
+    <gg0> i shut down vm, working on another one by mounting the same disk
+      which hosts a debchroot
+    <gg0> i'm trying to reproduce the mtab-dying-on-chroot issue i get with
+      debian installer
+    <gg0> at the end, os-prober gets stuck by reading /target/proc/mounts
+      (target is the installed system)
+    <gg0> to be precise it gets stuck at second access. at first it gives
+      Resource lost
+    <gg0> didn't manage to reproduce so far
+    <gg0> environment is pretty the same: booting with qemu multiboot
+      http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot
+    <gg0> so root on initrd + chroot on real disk 
+    <gg0> what's weird is that issue vanishes by removing console=com0 from
+      -append options
+
+
+### IRC, freenode, #hurd, 2014-03-08
+
+    <gg0> os-prober doesn't get stuck anymore and grub can install
+    <gg0> my guess is that without console=com0 /target/proc/mounts is just
+      accessed once
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-08
+
+    <gg0> youpi: from #debian-cd http://paste.debian.net/plainh/559f669b
+    <gg0> any quick way to recreate initrd?
+    <teythoon> gg0: i'm working on that
+    <gg0> teythoon: that what?
+    <teythoon> gg0: there is genext2fs, i have some patches that allows one to
+      create nodes with passive translator records
+    <gg0> recreating initrd?
+    <teythoon> yes
+    <teythoon> in the meantime, you can mount the existing initrd and modify it
+    <gg0> well i'm following this one to rebuild whole cd then take an updated
+      initrd to test with your repo
+    <gg0> http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i
+    <gg0> probably too much work to get that
+    <gg0> copying current /hurd to new initrd would be enough?
+    <youpi> just copy the precise translator you need
+    <youpi> also, no need to rebuild the whole cd just to replace the initrd
+    <youpi> simply copy the content of an existing is
+    <youpi> iso
+    <youpi> replace the initrd.gz there
+    <youpi> and then use grub-mkrescue to rebuild the ios
+    <youpi> development would be horrible if you had to rebuild everything from
+      zero everytime
+    <youpi> first thing to do when developping is first take the time to find
+      ways to work efficiently
+    <gg0> i'd want to try multiboot with teythoon's gnumach/hurd but boot gets
+      stuck with old initrd
+    <youpi> unfortunately I had to apply some patches
+    <youpi> first in d-i because isc-dhcp doens't work -> use the debian-ports
+      version
+    <gg0> so i could simply copying whole /hurd dir to new initrd
+    <gg0> -ing
+    <youpi> then in d-i to automatically enable the debian-ports mirror
+    <youpi> and last in the debian-cd to include debian-ports-archive-keyring
+    <youpi> you'd also need to copy the libs
+    <gg0> anything missing here?
+      http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i
+    <gg0> libc0.3 on initrd is still 2.17
+    <gg0> mini.iso doesn't like any mirror
+    <gg0> "mirror does not support the specified release"
+    <gg0> something wrong/missing in my rebuilt
+    <gg0> youpi: anything wrong in http://paste.debian.net/plain/86258 ?
+    <gg0> i have/had problems with name resolution
+    <youpi> gg0: the patch makes sense for -bsd too, Cc them too
+    <gg0> i was wondering how many hunks in your patches are upstreamable
+    <youpi> normally it's zero
+    <gg0>
+      http://people.debian.org/~sthibault/hurd-i386/installer/patch-debootstrap
+    <gg0> why "release" instead on "main" by default? sid is never released
+    <youpi> only because my mirror directory is hacked one
+    <youpi> that merges debian.org, debian-ports.org, and my repo
+    <youpi> and I don't rebuild Release files, just Packages files
+    <gg0> i keep getting gpgv: BAD signature from "Debian Archive Automatic
+      Signing Key (7.0/Wheezy) <ftpmaster@debian.org>
+    <gg0> just before creating debootstrap chroot
+    <gg0> i applied hunk #2 only, installed modified debootstrap and put debs
+      under localdebs/
+    <gg0> trying a different mirror
+    <youpi> I don't know what issue you are encountering
+    <youpi> but again, it's way simpler and faster to just patch existing
+      images, rather than rebuilding them from zero
+    <gg0> ok just read i'd need a local mirror to build isos
+    <gg0> better using netinst and proxy cache
+
+
+## IRC, freenode, #hurd, 2014-03-09
+
+    <gg0> http://postimg.org/image/oca8ormaj/
+    <gg0> with teythoon's repo too ^
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-09
+
+    <gg0> ok i'm out of tests, i get Resource lost with teythoon's gnumach/hurd
+      packages in initrd too
+    <gg0> http://postimg.org/image/oca8ormaj/
+    <gg0> thread storms, dead locks, resource lost
+    <gg0> i find assonance
+
+
+## IRC, freenode, #hurd, 2014-03-09
+
+    <teythoon> gg0: strange
+    <gg0> teythoon: shouldn't there be a patch which shows pid instead of task?
+    <gg0> 20:43 < teythoon> task /hurd/procfs(19) <EF><BF><BD>O<EF><BF><BD>
+      deallocating an invalid port 1049744, most probably a bug.
+    <teythoon> there is
+    <teythoon> i placed the functionality in proc first, but the wiki suggested
+      to put it in the exec server instead
+    <teythoon> i did that, it has the advantage, that the argv vector is easily
+      accessible
+    <teythoon> so i can also include the program name
+    <teythoon> but there are two programs, that are not started using the exec
+      server
+    <teythoon> the root filesystem and the exec server itself
+    <teythoon> so for these two processes, the approach does not work
+    <gg0> i see. so here we got two which could come from
+      ext2fs.static(initrd), exec(initrd) and ext2fs(chroot)
+      http://postimg.org/image/e3qyafd0b/ right?
+    <gg0> i also noticed that once mtab dies, by killing its procfs parent,
+      they both restart, but /target/proc is not in /proc/mounts anymore
+    <youpi> teythoon: for those we could use the first word of the module
+      command line
+    <gg0> restart doesn't means that by accessing /target/proc/mounts again it
+      works btw, it'll give Resource lost again
+    <teythoon> youpi: indeed
+    <teythoon> gg0: no, the ext2fs for /target will be started by the exec
+      server
+    <gg0> ok two invalid ports one from ext2fs.static and one exec then
+    <teythoon> gg0: what makes you attribute one to the exec server ?
+    <teythoon> i'm pretty sure that there is a bug in libfshelp, it's easily
+      triggered by killing an translator like procfs
+    <teythoon> i must have introduced it with the translator list work i've
+      done for the mtab translator
+    <gg0> teythoon: a totally wrong task-is-a-process reasoning probably
+    <gg0> just mounted another procfs which seems to work
+    <gg0> http://postimg.org/image/q6w9xzo2j/
+      http://postimg.org/image/cr998jfkr/
+    <teythoon> gg0: the mtab translators in your screenshots are oldish, what's
+      the point exactly ?
+    <teythoon> gg0: also, all tasks are processes. task is a mach concept,
+      whereas process is a posix concept implemented by hurds proc server. it
+      creates a process object for every mach task.
+    <gg0> my guess was that given we got two messages with different taskid:
+    <gg0> 16:01 < gg0> ok two invalid ports one from ext2fs.static and one exec
+      then
+    <gg0> screenshot is this one http://postimg.org/image/e3qyafd0b/
+    <gg0> btw what do you mean by oldish. except first one 01:18 < gg0>
+      http://postimg.org/image/oca8ormaj/ the only with current debian
+      packages, remaining are done with your latest packages
+    <gg0> in all cases i boot using qemu multiboot
+    <gg0> root@hurd01:~# cat /proc/version 
+    <gg0> Linux version 2.6.1 (GNU 0.5 GNU-Mach 1.4-486-dbg/Hurd-0.5
+      i686-AT386)
+    <gg0> it wouldn't be bad customizing version somehow, last commit id for
+      instance
+    <gg0> or build date
+    <gg0> user01@jessie01 ~$ cat /proc/version 
+    <gg0> Linux version 3.11-2-686-pae (debian-kernel@lists.debian.org) (gcc
+      version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04)
+    <gg0> user01@jessie01 ~$ uname -v
+    <gg0> #1 SMP Debian 3.11.10-1 (2013-12-04)
diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
index 3dab6d4c..64b245f2 100644
--- a/open_issues/performance.mdwn
+++ b/open_issues/performance.mdwn
@@ -239,3 +239,22 @@ call|/glibc/fork]]'s case.
     <braunr> teythoon: pahole is a very handy tool :)
     <teythoon> yes
     <teythoon> i especially like how general it is
+
+
+# Measurement
+
+## coulomb
+
+### [[!message-id "87wqghouoc.fsf@schwinge.name"]]
+
+## IRC, freenode, #hurd, 2014-02-27
+
+    <braunr> tschwinge: about your concern with regard to performance
+      measurements, you could run kvm with hugetlbfs and cpuset
+    <braunr> on a machine that provides nested page tables, this makes the
+      virtualization overhead as small as it could be considering the
+      implementatoin
+    <braunr> hugetlbs reduces the overhead of page faults, and also implies
+      locked memory while cpuset isolates the vm from global scheduling
+    <braunr> hugetlbfs*
+    <tschwinge> Thanks, will look into that.
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 711f7691..59f22187 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -3064,3 +3064,13 @@ License|/fdl]]."]]"""]]
       mach-defpager)
     <braunr> rebase it, send it as a patch on bug-hurd, it should be
       straightforward and short
+
+
+## IRC, freenode, #hurd, 2014-03-04
+
+    <teythoon> btw, has mcsim worked on vectorized i/o ? there was someting you
+      wanted to integrate
+    <teythoon> not sure what
+    <braunr> clustered pageins
+    <braunr> but he seems busy
+    <teythoon> oh, pageins
diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn
index c3dd4e26..46cc1c1c 100644
--- a/open_issues/ti-rpc_then_nfs.mdwn
+++ b/open_issues/ti-rpc_then_nfs.mdwn
@@ -103,3 +103,30 @@ re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]].
 
     <pere> failing rpcinfo -p on hurd reported as <URL:
       http://bugs.debian.org/739674 >.  Anyone got a clue how to debug it?
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-03
+
+    <pere> I was just tipped by sesse that the hurd fix for libtirpc probably
+      caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >.
+      Have not had time to check it out more closely.
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-04
+
+    <youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could
+      break Linux' libtirpc
+    <youpi> AIUI, the patch has zero effect on non-hurd builds
+    <youpi> oh wait
+    <youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined
+      in config.h.in
+    <pere> youpi: I am quite sure I did add the required dh_autoreconf call.
+      did you see a build log where it was missing?
+    <youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped
+    <youpi> and I don't have any further idea
+    <youpi> pere: maybe it's the autoreconf itself which broke something?
+    <pere> could be.  not quite sure how to find out.
+    <gnu_srs> pere: what about running autoreconf on the previous (working
+      version)?
+    <pere> gnu_srs: sound like a good idea.  perhaps a good idea to just
+      disable the two patches as a start.
diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn
index 1987b6ca..18fb588e 100644
--- a/open_issues/versioning.mdwn
+++ b/open_issues/versioning.mdwn
@@ -66,11 +66,8 @@ In context of [[packaging_libpthread]]/[[libpthread]].
       could be the perfect moment to fix the /dev/fd/N problem without adding
       new RPCs, though we'd probably have to break backwards-compatibility in
       the exec server IIRC...
-    <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
-      reminding!
 
-[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
-"4BFA500A.7030502@gmail.com"]].
+[[glibc#execve_relative_paths]].
 
 
 ### `time_t` -- Unix Epoch vs. 2038
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index 8901e1c3..88a18a93 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -24,6 +24,8 @@ License|/fdl]]."]]"""]]
     <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
       but apparently not fixed in that case, for some reason
 
+[[glibc#execve_relative_paths]].
+
 
 ## IRC, freenode, #hurd, 2013-08-26
 
@@ -36,6 +38,9 @@ License|/fdl]]."]]"""]]
     < youpi> yes
     < youpi> pinotree's exec_file_name is supposed to fix that, but for some
       reason it doesn't work here
+
+[[glibc#execve_relative_paths]].
+
     < pinotree> it was pochu's, not mine
     < youpi> ah, right
     < teythoon> ah I see, I was wondering about that
@@ -73,6 +78,9 @@ License|/fdl]]."]]"""]]
     <teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd
     <teythoon> but I'm not sure how to fix this
     <teythoon> first of all, Emilios file_exec_file_name patch set works fine
+
+[[glibc#execve_relative_paths]].
+
     <teythoon> but not with fakeroot
     <teythoon>
       http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300
@@ -1293,3 +1301,26 @@ License|/fdl]]."]]"""]]
     <braunr> teythoon: was it a big package ?
     <teythoon> half of the hurd package
     <braunr> that's not a port right overflow then
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <teythoon> youpi: what about the exec_filename patch series? even though
+      fakeroot still has some issues (has it?), i consider it worthy for
+      inclusion
+
+[[glibc#execve_relative_paths]].
+
+    <youpi> Roland was disagreeing with it
+    <youpi> iirc the fakeroot issue was solved
+    <teythoon> braunr: ^
+    <braunr> fakeroot goot a lot more robust than it used to be
+    <braunr> but i haven't checked that it actually behaves exactly like the
+      library for corner cases
+    <braunr> there are minor differences
+    <braunr> also, it seems to trigger concurrency bugs in ext2fs
+    <braunr> e.g. git reporting that files either "already exist" or "can't be
+      found"
+    <braunr> it happens (rarely) when directly using ext2
+    <braunr> and more often through fakeroot
+    <braunr> i didn't take the time to investigate
diff --git a/public_hurd_boxen/installation/darnassus.mdwn b/public_hurd_boxen/installation/darnassus.mdwn
index 8cb8f619..6424df71 100644
--- a/public_hurd_boxen/installation/darnassus.mdwn
+++ b/public_hurd_boxen/installation/darnassus.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2013, 2014 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
@@ -239,3 +239,77 @@ The goal is that robots rather index the official pages,
     <tschwinge> braunr: gitweb installed, hurd-web URLs fixed
       (s%bddebian%darnassus), also some more ikiwiki-related Perl pacakges
       installed (openID login, for example).
+
+
+## IRC, freenode, #hurd, 2014-02-28
+
+    <gg0> braunr: "no_identity_server: Could not determine ID provider from
+      URL." trying to login to wiki with google account
+    <braunr> ?
+    <braunr> gg0: for the first question: how do you get that error ?
+    <gg0> "trying to login to wiki with google account"
+    <braunr> why tell me ?
+    <gg0> darnassus wiki
+    <braunr> tschwinge is the wiki administrator
+    <gg0> on darnassus too? oh didn't know
+    <braunr> the wiki on darnassus is the real wiki
+    <braunr> the gnu.org one is a mirror that merges additions from savannah
+    <braunr> it's not exactly that, gnu.org is a static version
+    <braunr> trying to edit pages there redirects to darnassus
+    <braunr> gg0: don't you want an account on darnassus so that you can
+      directly edit source files ?
+    <gg0> braunr: i like Preview button, my review-myself process takes hours
+      :)
+    <braunr> it's a lot quicker to rebuild ikiwiki content and inspect static
+      files locally you know ;p
+    <gg0> yeah for instance because by "Save page" it doesn't actually save it
+    <teythoon> hm, worked for me just the other day
+    <gg0> Edit says page knows new changes but they are not online. shouldn't
+      they get online right away after Save page?
+    <braunr> on darnassus, yes
+    <braunr> check http://darnassus.sceen.net/gitweb/hurd-web.git/
+    <braunr> doesn't look like anything was committed
+    <braunr> so i'd say there is a bug
+    <gg0> plus openid login one
+    <tschwinge> I'll have a look.  I already fixed a similar situation a few
+      weeks ago.
+    <tschwinge> No idea what's happening there.
+    <tschwinge> gg0: I assume these are your changes:
+    <tschwinge> --- a/hurd/running/qemu.mdwn
+    <tschwinge> +++ b/hurd/running/qemu.mdwn
+    <tschwinge> @@ -366,6 +366,23 @@ Once you have logged in as `root` run the
+      `pfinet` translator with values that a
+    <tschwinge>  That should do it! Do not forget to edit/update
+      `/etc/resolv.conf` to get DNS working.
+    <tschwinge> +# QEMU Multiboot
+    <tschwinge> [...]
+    <tschwinge> gg0: Correct?
+    <gg0> tschwinge: they are
+    <tschwinge> gg0: Am I right assuming that when you tried to do your commit
+      in the web interface, you did not specify a commit message?
+    <gg0> tschwinge: correct. i didn't.
+    <tschwinge> OK, then I think I know (and fixed) what was going on there.
+    <tschwinge> gg0: Can you please retry that now?  Also, try to log in again
+      using OpenID.
+    <gg0> google button keeps saying "no_identity_server: Could not determine
+      ID provider from URL."
+    <gg0> Save page works now. it also commits to git
+    <cluck> gg0: i don't know what you're doing exactly but you might want to
+      double check your dns is working as expected (some anecdotal evidence
+      implies some dns servers around the word might be having issues)
+    <braunr> since the dns servers is on the sceen.net host machine which i
+      administer, and i have been very careful about its configuration, it
+      seems unlikely
+    <braunr> server*
+    <braunr> i don't see anything special in the logs
+    <braunr> something at the client side might be involved though
+    <cluck> braunr: as i said, i don't know what he's doing
+    <cluck> braunr: fwiw the cases that caught my attention are apparently
+      isp's dns servers
+
+
+### IRC, freenode, #hurd, 2014-03-01
+
+    <tschwinge> braunr, gg0: OpenID logins should again be working (no idea
+      when exactly it broke).  I needed to uninstall the
+      liblwpx-paranoidagent-perl package.
diff --git a/user/pochu.mdwn b/user/pochu.mdwn
index 18e90de3..545dbfed 100644
--- a/user/pochu.mdwn
+++ b/user/pochu.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2014 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
@@ -83,7 +83,7 @@ fixing them.
 
 ### May 19 - May 26
 * Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps)
-* Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review.
+* Worked on bug [[!GNU_Savannah_bug 28934]]. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review.
 * Requested GNU libc copyright papers to the FSF again since they didn't arrive the first time.
 
 ### May 12 - May 19
@@ -95,7 +95,7 @@ fixing them.
 ### May 5 - May 12
 * Read http://www.gnu.org/software/hurd/hurd-paper.html
 * Improved the linkat() patch
-* Fixed the issues mentioned in bug 28934, but after doing so I realized
+* Fixed the issues mentioned in bug [[!GNU_Savannah_bug 28934]], but after doing so I realized
   that wouldn't work well. The only good solution is to pass file_name
   from execve() to the exec server, so we need new RPCs.
 
@@ -105,7 +105,7 @@ fixing them.
 
 ### Before April 28
 * Investigated the glib's gtester problem and tracked it down:
-  [bug 28934](https://savannah.gnu.org/bugs/?28934). Prepared a patch
+  [[!GNU_Savannah_bug 28934]]. Prepared a patch
   but it's not good.
 * [glib's garray test timeouts on Hurd](https://bugzilla.gnome.org/show_bug.cgi?id=568760).
   The tests passes if the timeout is increased. The current upstream timeout