Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 3422 insertions, 0 deletions

diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
new file mode 100644
index 00000000..33041e71
--- /dev/null
+++ b/open_issues/glibc.mdwn
@@ -0,0 +1,3422 @@
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 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
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_glibc]]
+
+Here's what's to be done for maintaining glibc.
+
+[[!toc levels=2]]
+
+
+# [[General information|/glibc]]
+
+  * [[Versioning]]
+
+
+# [[Sources|source_repositories/glibc]]
+
+
+# [[Debian Cheat Sheet|debian]]
+
+
+# Configuration
+
+<!--
+
+git checkout reviewed
+git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -b -p -C --cc ..sourceware/master
+-i
+/^commit |^merge:|^---$|mach[^i]|hurd|linux|gs:|__assume
+
+-->
+
+Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852
+(2013-12-19) sources|source_repositories/glibc]].
+
+  * <a id=t_hurdsig-fixes>`t/hurdsig-fixes`</a>
+
+        hurdsig.c: In function '_hurd_internal_post_signal':
+        hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
+        hurdsig.c:1168:12: note: 'pending' was declared here
+
+  * <a id=t_host-independency>`t/host-independency`</a>
+
+    [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id
+    "20120525202732.GA31088@intel.com"]], commit
+    918b56067a444572f1c71b02f18255ae4540b043.  [[!GCC_PR 53183]], GCC commit
+    c05436a7e361b8040ee899266e15bea817212c37.
+
+  * <a id=t_pie-sbrk>`t/pie-sbrk`</a>
+
+    [[gcc/PIE]].
+
+  * <a id=t_sysvshm>`t/sysvshm`</a>
+
+        ../sysdeps/mach/hurd/shmat.c: In function '__shmat':
+        ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
+        ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive':
+        ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable]
+        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized]
+        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+  * <a id=t_tls>[[`t/tls`|t/tls]]</a>
+
+  * <a id=t_tls-threadvar>[[`t/tls-threadvar`|t/tls-threadvar]]</a>
+
+  * <a id=t_verify.h>`t/verify.h`</a>
+
+    People didn't like this too much.
+
+    Other examples:
+
+      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert`
+
+  * <a id=toolchain_cross-gnu>[[toolchain/cross-gnu]], without `--disable-multi-arch`</a>
+
+        i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...]
+        ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages:
+        ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined
+        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1
+        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string'
+
+    Might simply be a missing patch(es) from master.
+
+  * <a id=disable-multi-arch>`--disable-multi-arch`</a>
+
+    IRC, freenode, #hurd, 2012-11-22
+
+        <pinotree> tschwinge: is your glibc build w/ or w/o multiarch?
+        <tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch
+        <pinotree> ah, because you do cross-compilation?
+        <tschwinge> No, that's natively.
+        <tschwinge> There is also a not of what happened in cross-gnu when I
+          enabled multi-arch.
+        <tschwinge> No idea whether that's still relevant, though.
+        <pinotree> EPARSE
+        <tschwinge> s%not%note
+        <tschwinge> Better?
+        <pinotree> yes :)
+        <tschwinge> As for native builds: I guess I just didn't (want to) play
+          with it yet.
+        <pinotree> it is enabled in debian since quite some time, maybe other
+          i386/i686 patches (done for linux) help us too
+        <tschwinge> I though we first needed some CPU identification
+          infrastructe before it can really work?
+        <tschwinge> I thought [...].
+        <pinotree> as in use the i686 variant as runtime automatically? i guess
+          so
+        <tschwinge> I thought I had some notes about that, but can't currently
+          find them.
+        <tschwinge> Ah, I probably have been thinking about open_issues/ifunc
+          and open_issues/libc_variant_selection.
+
+  * <a id=buildX>--build=X</a>
+
+    `long double` test: due to `cross_compiling = maybe` wants to execute a
+    file, which fails.  Thus `--build=X` has to be set.
+
+  * <a id=check>Check what all these are:</a>
+
+        running configure fragment for sysdeps/mach/hurd
+        checking Hurd header version... ok
+        running configure fragment for sysdeps/mach
+        checking for i586-pc-gnu-mig... i586-pc-gnu-mig
+        checking for mach/mach_types.h... yes
+        checking for mach/mach_types.defs... yes
+        checking for task_t in mach/mach_types.h... task_t
+        checking for thread_t in mach/mach_types.h... thread_t
+        checking for creation_time in task_basic_info... yes
+        checking for mach/mach.defs... yes
+        checking for mach/mach4.defs... yes
+        checking for mach/clock.defs... no
+        checking for mach/clock_priv.defs... no
+        checking for mach/host_priv.defs... no
+        checking for mach/host_security.defs... no
+        checking for mach/ledger.defs... no
+        checking for mach/lock_set.defs... no
+        checking for mach/processor.defs... no
+        checking for mach/processor_set.defs... no
+        checking for mach/task.defs... no
+        checking for mach/thread_act.defs... no
+        checking for mach/vm_map.defs... no
+        checking for mach/memory_object.defs... yes
+        checking for mach/memory_object_default.defs... yes
+        checking for mach/default_pager.defs... yes
+        checking for mach/i386/mach_i386.defs... yes
+        checking for egrep... grep -E
+        checking for host_page_size in mach_host.defs... no
+        checking for mach/machine/ndr_def.h... no
+        checking for machine/ndr_def.h... no
+        checking for i386_io_perm_modify in mach_i386.defs... yes
+        checking for i386_set_gdt in mach_i386.defs... yes
+        checking whether i586-pc-gnu-mig supports the retcode keyword... yes
+
+  * <a id=stackguard>`sysdeps/i386/stackguard-macros.h`</a>
+
+    See [[t/tls|t/tls]].
+
+  * <a id=77c84aeb81808c3109665949448dba59965c391e>Verify 77c84aeb81808c3109665949448dba59965c391e against
+    `~/shared/glibc/make_TAGS.patch`.</a>
+
+  * <a id=HP_SMALL_TIMING_AVAIL>`HP_SMALL_TIMING_AVAIL` not defined anywhere.</a>
+
+  * <a id=CPUCLOCK_WHICH>Unify `CPUCLOCK_WHICH` stuff in `clock_*` files.</a>
+
+  * <a id=tests-clean>Not all tests are re-run in a `make -k tests; make tests-clean; make -k
+    tests` cycle.  For example, after `make tests-clean`:</a>
+
+        $ find ./ -name \*.out
+        ./localedata/tst-locale.out
+        ./localedata/sort-test.out
+        ./localedata/de_DE.out
+        ./localedata/en_US.out
+        ./localedata/da_DK.out
+        ./localedata/hr_HR.out
+        ./localedata/sv_SE.out
+        ./localedata/tr_TR.out
+        ./localedata/fr_FR.out
+        ./localedata/si_LK.out
+        ./localedata/tst-mbswcs.out
+        ./iconvdata/iconv-test.out
+        ./iconvdata/tst-tables.out
+        ./stdlib/isomac.out
+        ./posix/wordexp-tst.out
+        ./posix/annexc.out
+        ./posix/tst-getconf.out
+        ./elf/check-textrel.out
+        ./elf/check-execstack.out
+        ./elf/check-localplt.out
+        ./c++-types-check.out
+        ./check-local-headers.out
+        ./begin-end-check.out
+
+  * <a id=t_cpuclock>`CPUCLOCK_WHICH`, `t/cpuclock`</a>
+
+        /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime':
+        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH'
+        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH'
+        collect2: error: ld returned 1 exit status
+        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1
+        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt'
+        make[1]: *** [rt/others] Error 2
+        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc'
+        make: *** [all] Error 2
+
+  * <a id=missing>Missing Interfaces</a>
+
+    We have posted a [[Google Summer of Code project proposal|community/gsoc]]:
+
+    [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no
+    actions=yes]]
+
+    Many are missing for GNU Hurd, some of which have been announced in
+    [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others
+    typically haven't (like new flags to existing functions).  Typically,
+    porters will notice missing functionaly.  But in case you're looking for
+    something to work on, here's a bit of a commented list, otherwise go
+    looking in `/usr/include/i386-gnu/gnu/stubs.h` on a Debian GNU/Hurd system,
+    or the respective file from a fresh glibc build.
+
+    `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`,
+    `CLOCK_REALTIME_ALARM`, `O_PATH`, `O_TMPFILE`
+    (ffdd31816a67f48697ea4d6b852e58d2886d42ca),
+    `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27,
+    b1b2aaf8eb9eed301ea8f65b96844568ca017f8b,
+    521c6785e1fc94d1f501743e9a40af9e02797df3),
+    `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
+    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
+    `open_by_handle_at`,
+    `posix_openpt`, `process_vm_readv`, `process_vm_writev`,
+    `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several
+    `MAP_*`|glibc/mmap]]
+
+    Check also the content of `gnu/stubs.h`, which lists all the functions
+    marked as stub which only return `ENOSYS`.
+
+      * <a id=chflags>`chflags`</a>
+
+        Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]].
+
+        IRC, OFTC, #debian-hurd, 2012-04-27:
+
+            <Steap> Does anyone have any idea why int main(void) { return
+              chflags(); } will compile with gcc but not with g++ ? It says
+              that "chflags" was not declared in this scope.
+            <Steap> I get the same error on FreeBSD, but including sys/stat.h
+              makes it work
+            <Steap> Can't find a solution on Hurd though :/
+            <youpi> the Hurd doesn't have chflags
+            <youpi> apparently linux neither
+            <youpi> what does it do?
+            <Steap> change flags :)
+            <Steap> Are you sure the Hurd does not have chflags ? Because gcc
+              does not complain
+            <youpi> there is no chflags function in /usr/include
+            <youpi> but what flags does it change?
+            <Steap> According to the FreeBSD manpage, it can set flags such as
+              UF_NODUMP, UF_IMMUTABLE etc.
+            <youpi> Hum, there is actually a chflags() definition
+            <youpi> but no declaration
+            <youpi> so actually chflags is supported, but the declaration was
+              forgotten
+            <youpi> probably because since linux doens't have it, it has never
+              been a problem up to now
+            <youpi> so I'd say ignore the error for now, we'll add the
+              declaration
+
+      * <a id=t_tls-threadvar>[[t/tls-threadvar]]</a>
+
+      * <a id=futimesat>`futimesat`</a>
+
+        If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`.
+
+      * `futimens`
+
+        IRC, freenode, #hurd, 2014-02-09:
+
+            <youpi> it seems apt 0.9.15.1 has troubles downloading packages
+              etc., as opposed to apt 0.9.15
+            <youpi> ah, that version uses futimens unconditionally
+            <youpi> and we haven't implemented that yet
+            <azeem> did somebody file a bug for that apt-get issue?
+            <youpi> I haven't
+            <youpi> I'll commit the fix in eglibc
+            <youpi> but perhaps a bug report would be good for the kfreebsd
+              case
+
+      * <a id=bits_stat.h>`bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT`</a>
+
+      * <a id=__USE_ATFILE>`io/fcntl.h [__USE_ATFILE]`</a>
+
+        Do we support `AT_FDCWD` et al.?
+        (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.)
+
+      * <a id=t_opendirat>`t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)</a>
+
+        Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
+        14d96785125abee5e9a49a1c3037f35a581750bd.
+
+      * <a id=madvise>`madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP`</a>
+
+        [[glibc_madvise_vs_static_linking]].
+
+        IRC, OFTC, #debian-hurd, 2013-09-09:
+
+            <gg0> does hurd MADV_DONTNEED or MADV_FREE or none?
+              http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239
+            <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED
+              but i don't know what i'm talking about, so it could build with
+              JEMALLOC_PURGE_MADVISE_FREE as well
+
+        IRC, OFTC, #debian-hurd, 2013-09-10:
+
+            <youpi> gg0: it implements none, even if it defines DONTNEED (but
+              not FREE)
+
+        See also:
+
+            gnash (0.8.11~git20130903-1) unstable; urgency=low
+            
+              * Git snapshot.
+                + Embedded jemalloc copy has been replaced by system one.
+                  [...]
+                  - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream.
+
+      * <a id=msync>`msync`</a>
+
+        Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`.
+
+      * <a id=epoll>`epoll`, `sys/epoll.h`</a>
+
+        Used by [[wayland]], for example.
+
+        IRC, freenode, #hurd, 2013-08-08:
+
+            <nalaginrut> is there any possible to have kquque/epoll alike
+              things in hurd? or there is one?
+            <braunr> nalaginrut: use select/poll
+            <nalaginrut> is it possible to implement epoll?
+            <braunr> it is
+            <braunr> we don't care enough about it to do it
+            <braunr> (for now)
+            <nalaginrut> well, since I wrote a server with Guile, and it could
+              take advantage of epoll, never mind, if there's no, it'll use
+              select automatically
+            <nalaginrut> but if someday someone care about it, I'll be
+              interested on it
+            <braunr> epoll is a scalability improvement over poll
+            <braunr> the hurd being full of scalability issues, this one is
+              clearly not a priority
+            <nalaginrut> ok
+
+        IRC, freenode, #hurd, 2013-09-26:
+
+            <nalaginrut> if I want to have epoll/kqueue like things, where
+              should it dwell? kernel or some libs?
+            <braunr> libs
+            <pinotree> userland
+            <braunr> that would be a good project to work on, something i
+              intended to do (so i can help) but it requires a lot of work
+            <braunr> you basically need to add a way to explicitely install and
+              remove polling requests (instead of the currently way that
+              implicitely remove polling requests when select/poll returns)
+            <braunr> while keeping the existing way working for some time
+            <braunr> glibc implements select
+            <braunr> the hurd io interface shows the select interface
+            <braunr> servers such as pfinet/pflocal implement it
+            <braunr> glibc implements the client-side of the call
+            <nalaginrut> where's poll? since epoll just added edge-trigger in
+              poll
+            <braunr> both select and poll are implemented on top of the hurd io
+              select call (which isn't exactly select)
+            <braunr>
+              http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/hurd/io.defs
+            <braunr> this is the io interface
+            <braunr>
+              http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c
+            <braunr> this is the client side implementation
+
+        IRC, freenode, #hurd, 2014-02-14:
+
+            <desrt> also: do you know if hurd has a modern-day poll()
+              replacement? ala epoll, kqueue, iocp, port_create(), etc?
+            <pochu_> last thing I remember was that there was no epoll
+              equivalent, but that was a few years ago :)
+            <pochu_> braunr: ^
+            * desrt is about to replace gmaincontext in glib with something
+                more modern
+            * desrt really very much wants not to have to write a poll()
+                backend....
+            <desrt> it seems that absolutely every system that i care about,
+              except for hurd, has a new approach here :/
+            <desrt> even illumos has solaris-style ports
+            <azeem> desrt: I suggest you bring up the question on bug-hurd
+            <azeem> the poll() system call there to satisfy POSIX, but there
+              might be a better Hurd-specific thing you could use
+            <azeem> is there*
+            <desrt> that would be ideal
+            <desrt> i have to assume that a system that passes to many messages
+              has some other facilities :)
+            <desrt> *so many
+            <desrt> the question is if they work with fds....
+            <desrt> bug-hurd doesn't seem like a good place to ask open-ended
+              questions....
+            <azeem> it's the main development lists, it's just old GNU naming
+            <azeem> list*
+            <desrt> k.  thanks.
+            <azeem> bug-hurd@gnu.org is the address
+            * desrt goes to bug... hurd
+            <desrt> written.  thanks.
+            <braunr> desrt: the hurd has only select/poll
+            <braunr> it suffers from so many scalability issues there isn't
+              much point providing one currently
+            <braunr> we focus more on bug fixing and posix compliance right now
+            <desrt> fair answer
+            <braunr> you should want a poll-based backend
+            <braunr> it's the most portable one, and doesn't suck as much as
+              select
+            <braunr> very easy to write
+            <braunr> although, internally, our select/poll works just like a
+              bare epoll
+            <braunr> i.e. select requests are installed, the client waits for
+              one or more messages, then uninstalls the requests
+
+        IRC, freenode, #hurd, 2014-02-23:
+
+            <desrt> brings me to another question i asked here recently that
+              nobody had a great answer for: any plan to do kqueue?
+            <braunr> not for now
+            <braunr> i remember answering you about that
+            <desrt> ah.  on IRC or the list?
+            <braunr> that internally, our select/poll implementation works just
+              like epoll
+            <braunr> on irc
+            <braunr> well "just like" is a bit far from the truth
+            <desrt> well... poll() doesn't really work like epoll :p
+            <braunr> internally, it does
+            <braunr> even on linux
+            <desrt> since both of us have to do the linear scan on the list
+            <desrt> which is really the entire difference
+            <braunr> that's the user interface part
+            <braunr> i'm talking about the implementation
+            <desrt> ya -- but it's the interface that makes it unscalable
+            <braunr> i know
+            <braunr> what i mean is
+            <braunr> since the implementation already works like a more modern
+              poll
+            <braunr> we could in theory add such an interface
+            <braunr> but epoll adds some complicated detail
+            <desrt> you'll have to forgive me a bit -- i wasn't around from a
+              time that i could imagine what a non-modern poll would look like
+              inside of a kernel :)
+            <braunr> what i mean with a modern poll is a scalable poll-like
+              interface
+            <braunr> epoll being the reference
+            * desrt is not super-crazy about the epoll interface....
+            <braunr> me neither
+            <desrt> kevent() is amazing -- one syscall for everything you need
+            <braunr> i don't know kqueue enough to talk about it
+            <desrt> no need to do 100 epollctls when you have a whole batch of
+              updates to do
+            <desrt> there's two main differences
+            <desrt> first is that instead of having a bunch of separate fds for
+              things like inotify, timerfd, eventfd, signalfd, etc -- they're
+              all built in as different 'filter' types
+            <desrt> second is that instead of a separate epoll_ctl() call to
+              update the list of monitored things, the kevent() call
+              (epoll_wait() equivalent) takes two lists: one is the list of
+              updates to make and the other is the list of events to
+              return.... so you only do one syscall
+            <braunr> well, again, that's the interface
+            <braunr> internally, there still are updates and waits
+            <braunr> and on a multiserver system like the hurd, this would mean
+              one system call per update per fd
+            <braunr> and then one per wait
+            <desrt> on the implementation side, i think kqueue also has a nice
+              feature: the kernel somehow has some magic that lets it post
+              events to a userspace queue.... so if you're not making updates
+              and you do a kevent() that would not block, you don't even enter
+              the kernel
+            <braunr> ok
+            <desrt> hm.  that's an interesting point
+            <desrt> "unix" as such is just another server for you guys, right?
+            <braunr> no
+            <braunr> that's a major difference between the hurd and other
+              microkernel based systems
+            <braunr> even multiserver ones like minix
+            <braunr> we don't have a unix server
+            <braunr> we don't have a vfs server or even an "fd server"
+            <desrt> so mach knows about things like fds?
+            <braunr> no
+            <braunr> only glibc
+            <desrt> oh.  weird!
+            <braunr> yes
+            <braunr> that's the hurd's magic :)
+            <braunr> being so posix compliant despite how exotic it is
+            <desrt> this starts to feel like msvcrt :p
+            <braunr> maybe, i wouldn't know
+            <braunr> windows is a hybrid after all
+            <braunr> with multiple servers for its file system
+            <braunr> so why not
+            <braunr> anyway
+            <desrt> so windows doesn't have fds in the kernel either... the C
+              library runtime emulates them
+            <braunr> mach has something close to file descriptors
+            <desrt> which is fun when you get into dll hell -- sometimes you
+              have multiple copies of the C library runtime in the same program
+              -- and you have to take care not to use fds from one of them with
+              th o ther one
+            <braunr> yes ..
+            <braunr> that, i knew :)
+            <braunr> but back to the hurd
+            <braunr> since fds are a glibc thing here, and because "files" can
+              be implemented by multiple servers
+            <braunr> (sockets actually most of the time with select/poll)
+            <braunr> we have to make per fd requests
+            <braunr> the implementation uses the "port set" kernel abstraction
+            <desrt> right -- we could have different "fd" coming from different
+              places
+            <braunr> do you know what a mach port is ?
+            <desrt> not even a little bit
+            <braunr> hm
+            <desrt> i think it's what a plane does when it goes really fast,
+              right?
+            <braunr> let's say it's a kernel message queue
+            <braunr> no it's not a sonic boom
+            <desrt> :)
+            <braunr> ;p
+            <braunr> so
+            <braunr> ports are queues
+            <desrt> (aside: i did briefly run into mach ports recently on macos
+              where they modified their kqueue to support them...)
+            <braunr> queues of RPC requests usually
+            <desrt> (but i didn't use them or look into them at all)
+            <braunr> they can be referenced through mach port names, which are
+              integers much like file descriptors
+            <braunr> they're also used for replies but, except for weird calls
+              like select/poll, you don't need to know that :)
+            <braunr> a port set is one object containing multiple ports
+            <desrt> sounds like dbus :)
+            <braunr> the point of a port set is to provide the ability to
+              perform a single operation (wait for a message) on multiple ports
+            <desrt> sounds like an epoll fd....
+            <desrt> is the port set itself a port?
+            <braunr> so, when a client calls select, it translates the list of
+              fds into port names, creates reply ports for each of them, puts
+              them into a port set, send one select request for each, and does
+              one blocking wait on the port set
+            <braunr> no, but you can wait for a message on a port set the same
+              way you do on a port
+            <braunr> and that's all it does
+            <desrt> does that mean that you can you put a port set inside of
+              another port set?
+            <braunr> hm maybe
+            <desrt> i guess in some way that doesn't actually make sense
+            <braunr> i guess
+            <desrt> because i assume that the message you sent to each port in
+              your example is "tell me when you have some stuff"
+            <braunr> yes
+            <desrt> and you'd have to send an equivalent message to the port
+              set.... and that just doesn't make sense
+            <desrt> since it's not really a thing, per se
+            <braunr> it would
+            <braunr> insteaf of port -> port set, it would just be port -> port
+              set -> port set
+            <braunr> but we don't have any interface where an fd stands for a
+              port set
+            <braunr> what i'm trying to tell here is that
+            <braunr> considering how it's done, you can easily see that there
+              has to be non trivial communication
+            <braunr> each with the cost of a system call
+            <braunr> and not just any system call, a messaging one
+            <braunr> mach is clearly not as good as l4 when it comes to that
+            <desrt> hrmph
+            <braunr> and the fact that most pollable fds are either unix or
+              inet/inet6 sockets mean that there will be contention in the
+              socket servers anyway
+            <desrt> i've seen some of the crazy things you guys can do as a
+              result of the way mach works and way that hurd uses it, in
+              particular
+            <desrt> normal users setting up little tcp/ip universes for
+              themselves, and so on
+            <braunr> yes :)
+            <desrt> but i guess this all has a cost
+            <braunr> the cost here comes more from the implementation than the
+              added abstractions
+            <braunr> mach provides async ipc, which can partially succeed
+            <desrt> if i spin up a subhurd, it's using the same mach, right?
+            <braunr> yes
+            <desrt> that's neat
+            <braunr> we tend to call them neighbour hurds because of that
+            <braunr> i'm not sure it is
+            <desrt> it puts it half way between linux containers and outright
+              VMs
+            <desrt> because you have a new kernel.... ish...
+            <braunr> well, it is for the same reasons hypervisors are neat
+            <desrt> but the kernel exists within this construct....
+            <braunr> a new kernel ?
+            <desrt> a new hurd
+            <braunr> yes
+            <desrt> but not a new mach
+            <braunr> exactly
+            <desrt> ya -- that's very cool
+            <braunr> it's halfway between hypervisors and containers/jails
+            <braunr> what matters is that we didn't need to write much code to
+              make it work
+            <braunr> and that the design naturally guarantees strong isolation
+            <desrt> right.  that's what i'm getting at
+            <braunr> unlike containers
+            <desrt> it shows that the interaction between mach and these set of
+              crazy things collectively referred to as the hurd is really
+              proper
+            <braunr> usually
+            <braunr> sometimes i think it's not
+            <braunr> but that's another story :)
+            <desrt> don't worry -- you can fix it when you port to L4 ;)
+            <braunr> eh, no :)
+            <desrt> btw: is this fundamentally the same mach as darwin?
+            <braunr> yes
+            <desrt> so i guess there are multiple separate implementations of a
+              standard set of interfaces?
+            <braunr> ?
+            * desrt has to assume that apple wouldn't be using GNU mach, for
+                example...
+            <braunr> no it's the same code base
+            <braunr> they couldn't
+            <braunr> but only because the forks have diverged a bit
+            <desrt> ah
+            <braunr> and they probably changed a lot of things in their virtual
+              memory implementation
+            <desrt> so i guess original mach was under some BSDish type thing
+              and GNU mach forked from that and started adding GPL code?
+            <braunr> something like that
+            <desrt> makes sense
+            <braunr> we have very few "non-standard" mach interfaces
+            <braunr> but we now rely on them so we couldn't use another mach
+              either
+            <braunr> back to the select/poll stuff
+            * desrt gets a lesson tonight :)
+            <braunr> it costs, it's not scalable
+            <braunr> but
+            <braunr> we have scalability problems in our servers
+            <braunr> they're old code, they use global locks
+            <desrt> right.  this is the story i heard last time.
+            <braunr> probably from me
+            <braunr> poll works good enough for us right now
+            <braunr> we're more interested in bug fixes than scalability
+              currently
+            <desrt> the reason this negative impacts me is because now i need
+              to write a bunch more code ;p
+            <braunr> i hope this changes but we still get weird errors that
+              many applications don't expect and they react badly to those
+            <braunr> well, poll really is the posix fallback
+            <desrt> every other OS that we want to support has some sort of new
+              scalable epoll-type interface or is Windows (which needs separate
+              code anyway)
+            <desrt> a very large number of them have kqueue... linux has
+              epoll... solaris/illumos is the odd one out with this weird thing
+              that's sort of like epoll
+            <braunr> i would think you want a posix fallback for such a
+              commonly used interface
+            <braunr> hm
+            <desrt> braunr: hurd is pretty much the only one that doesn't
+              already have something better....
+            <braunr> linux can be built without epoll
+            <desrt> and the nice thing about all of these things is that every
+              single one of them gives me an fd that can be polled when any
+              event is ready
+            <braunr> i don't see why anyone would do that, but it's a compile
+              time option ;p
+            <braunr> yes ...
+            <braunr> we don't have xxxfd() :)
+            <desrt> and we want to expose that fd on our API... so people can
+              chain gmaincontext into other mainloops
+            <braunr> that's expected
+            <desrt> so for hurd this means that i will need to spin up a
+              separate thread doing poll() and communicating back to the main
+              thread when anything becomes ready
+            <desrt> i was looking forward to not having to do that :)
+            <braunr> it matches the unix "everything is a file" idea, and
+              windows concept of "events"
+            <braunr> i understand but again, it's a posix fallback
+            <braunr> you probably want it anyway
+            <desrt> probably
+            <braunr> it could help new systems trying to be posix like
+            <desrt> i honestly thought i'd get away with it, though
+            <desrt> this is true...
+            <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement
+              or fake.... "modern event polling framework" is another story...
+
+        [[clock_gettime]].
+
+            <braunr> yes, but again, we do have the underlying machinery to add
+              it
+            <desrt> i appreciate if your priorities are elsewhere ;)
+            <braunr> it's just not worth the effort right now
+            <braunr> although we do have performance and latency improvements
+              in our patch queues currently
+            <braunr> if our network stack gets replaced, it would become
+              interesting
+            <braunr> we need to improve posix compliance first
+            <braunr> make more applications not choke on unecpected errors
+            <braunr> and then we can think of improving scalability
+            <desrt> +1 vote from me for implementing monotonic time :)
+            <desrt> (and also pthread_condattr_setclock())
+            <braunr> and we probably won't implement the epoll interface ;p
+            <braunr> yes
+            <desrt> it's worth noting that there is also a semi-widely
+              available non-standard extension called
+              pthread_cond_timedwait_relative_np that you could implement
+              instead
+            <desrt> it takes a (relative) timeout instead of an absolute one --
+              we can use that if it's available
+            <braunr> desrt: why would you want relative timeouts ?
+            <desrt> braunr: if you're willing to take the calculations into
+              your own hands and you don't have another way to base it on
+              monotonic time it starts to look like a good alternative
+            <desrt> and indeed, this is the case on android and macos at least
+            <braunr> hm
+            <desrt> not great as a user-facing API of course.... due to the
+              spurious wakeup possibility and need to retry
+            <braunr> so it's non standard alternative to a monotonic clock ?
+            <desrt> no -- these systems have monotonic clocks
+            <desrt> what they lack is pthread_condattr_setclock()
+            <braunr> oh right
+            <desrt> which is documented in POSIX but labelled as 'optional'
+            <braunr> so relative is implicitely monotonic
+            <desrt> yes
+            <desrt> i imagine it would be the same 'relative' you get as the
+              timeout you pass to poll()
+            <desrt> since basing anything like this on wallclock time is
+              absolutely insane
+            <desrt> (which is exactly why we refuse to use wallclock time on
+              our timed waits)
+            <braunr> sure
+            <braunr> i'm surprised clock_monotonic is even optional in posix
+              2008
+            <braunr> but i guess that's to give some transition margin for
+              small embedded systems
+            <desrt> when you think about it, CLOCK_REALTIME really ought to
+              have been the optional feature
+            <desrt> monotonic time is so utterly basic
+            <braunr> yes
+            <braunr> and that's how it's normally implemented
+            <braunr> kernels provide a monotonic clock, and realtime is merely
+              shifted from it
+
+      * <a id=sys_eventfd.h>`sys/eventfd.h`</a>
+
+      * <a id=sys_inotify.h>`sys/inotify.h`</a>
+
+      * <a id=sys_signalfd.h>`sys/signalfd.h`</a>
+
+      * <a id=sys_timerfd.h>`sys/timerfd.h`</a>
+
+      * <a id=timespec_get>`timespec_get` (74033a2507841cf077e31221de2481ff30b43d51,
+        87f51853ce3671f4ba9a9953de1fff952c5f7e52)</a>
+
+      * <a id=waitflags.h>`waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)</a>
+
+        IRC, freenode, #hurd, 2012-04-20:
+
+            <pinotree> in glibc, we use the generic waitflags.h which, unlike
+              linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
+              WCONTINUED
+            <pinotree> should the generic bits/waitflags.h define them anyway,
+              since they are posix?
+            <youpi> well, we'd have to implement them anyway
+            <youpi> but otherwise, I'd say yes
+            <pinotree> sure, but since glibc headers should expose at least
+              everything declared by posix, i thought they should be defined
+              anyway
+            <youpi> that might bring bugs
+            <youpi> some applications might be #ifdefing them
+            <youpi> and break when they are defined but not working
+            <pinotree> i guess they would define them to 0, andd having them to
+              non-zero values shouldn't break them (since those values don't do
+              anything, so they would act as if they were 0.. or not?)
+            <youpi> no, I mean they would do something else, not define them to
+              0
+            <pinotree> like posix/tst-waitid.c, you mean?
+            <youpi> yes
+
+        See `posix/tst-waitid.out` failure below.
+
+      * <a id=getconf>`getconf` things (see below the results of `tst-getconf.out`)</a>
+
+      * <a id=getsockopt>`getsockopt`, `setsockopt`</a>
+
+        IRC, freenode, #hurd, 2013-02-14
+
+            <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows
+              e.g. in the gnulib's test-{poll,select} code.
+            <gnu_srs> Reading
+              http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might
+              be reasons _not_ to implement them, comments?
+            <pinotree> uh? they are supported on hurd
+            <gnu_srs> not  SO_REUSEPORT for setsockopt()
+            <pinotree> that isn't the same as claiming "get/setsockopt is not
+              supported on hurd"
+            <pinotree> most probably that option is not implemented by the
+              socket family you are using
+            <gnu_srs> OK, some options like  SO_REUSEPORT then, more info in
+              the link.
+            <pinotree> note also SO_REUSEPORT is not posix
+            <pinotree> and i don't see SO_REUSEPORT mentioned in the page you
+              linked
+            <gnu_srs> No, but SO_REUSEADDR
+
+        IRC, freenode, #hurd, 2013-02-23
+
+            <gnu_srs> as an example, the poll test code from gnulib fails due
+              to that problem (and I've told you before)
+            <pinotree> gnu_srs: what's the actual failure?
+            <pinotree> can you provide a minimal test case showing the issue?
+            <gnu_srs> pinotree: A smaller test program:
+              http://paste.debian.net/237495/
+            <pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket
+              works...
+            <pinotree> and it seems it was a bug in the gnulib tests, see
+              http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4
+            <gnu_srs> pinotree: You are right, still the code I pasted pass on
+              Linux, not on Hurd.
+            <pinotree> so?
+            <pinotree> the code is wrong
+            <pinotree> you cannot change what bind does after you have called
+              it
+            * pinotree → out
+            <gnu_srs> so linux is buggy?
+            <braunr> no, linux is more permissive
+            <braunr> (at least, on this matter)
+
+      * <a id=getcontext>`getcontext`/`makecontext`/`setcontext`/`swapcontext`</a>
+
+        Support for these functions within the Hurd threadvar environment has
+        been added, but for multi-threaded applications ([[libpthread]]), it is
+        a bit clunky: as a practical requirement, a thread's stack size always
+        has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be
+        naturally aligned.  The idea is still to [[get rid of Hurd threadvars
+        and replace them with TLS|t/tls-threadvar]].
+
+        Aside from [[gccgo]], the following packages might make use of these
+        functions, searching on <http://codesearch.debian.net/> for
+        `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49,
+        chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel,
+        libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim,
+        and more.
+
+        IRC, OFTC, #debian-hurd, 2013-09-08:
+
+            <pinotree> oh, and even ruby2.0 suffers because of fixed-stack
+              threads
+            <youpi> yes, we definitely need to finish fixing it
+            <youpi> my current work is in our glibc repo, youpi/tls-threadvar
+            <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000
+              is not usable with threadvars
+            <pinotree> all 8 failing tests with that
+            <youpi> maybe we can hand-disable the use of contexts in ruby for
+              now?
+            <pinotree> gg0: ↑ :)
+            <gg0> after the pseudo-patch i RFCed, i don't deserve to say
+              anything else about that :)
+            <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as
+              above :)
+            <gg0> eh maybe i'd just be able to hand-disable failing
+              thread-related _tests_ :)
+            <gg0> i'm still hoping some real developer picks and actually fixes
+              it, seems it's not enough interesting though
+            <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it
+            <gg0> afaiu youpi is working on threadvars-tls migration, which
+              would mean fixing them all. i just meant fixing ruby, which would
+              mean having puppet btw
+            <youpi> gg0: "actually fixing" means fixing threadvars-tls
+              migration
+            <youpi> "just fixing" ruby can be done by simply disabling context
+              use in ruby
+
+        IRC, OFTC, #debian-hurd, 2013-09-10:
+
+            <gg0> this one fixes make test by disabling context and giving more
+              time to timing related tests http://paste.debian.net/plain/37977/
+            <gg0> make test-all is another story
+            <youpi> gg0: AIUI, the sleep part should get fixed by the next
+              glibc upload, which will include the getclk patch
+            <youpi> but the disabling context part could be good to submit to
+              the debian ruby package, mentioning that this is a workaround for
+              now
+            <gg0> unfortunately still not enough, test-all still fails
+            <youpi> does it make the package not build?
+            <gg0> test-all is the second part of what we call tests
+            <gg0> they build and package (they produce all ruby packages),
+              after that they run debian/run-test-suites.bash which is make
+              test + make test-all
+            <gg0> well after or during the build doesn't matter, it's their
+              testsuite
+            <gg0> ok just failed:
+            <gg0> TestBug4409#test_bug4409 = Illegal instruction
+            <gg0> make: *** [yes-test-all] Error 132
+            <gg0> what to do with Illegal instruction?
+            <gg0> just found 2 words that make everybody shut up :p
+            <pinotree> same as above: debug it
+            <teythoon> gg0: have you confirmed that this is reproducible? I've
+              once had a process die with SIGILL and it was not and I figured
+              it might have been a (qemu?) glitch
+            <gg0> seems i'm running tests which are disabled on _all_ archs,
+              better so
+            <gg0> well, this should be reproducible. i just got it on a qemu, i
+              could try to reproduce it on real hardware but as just said, i
+              was testing tests disabled by maintainer so completely useless
+            <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm
+              as well, I meant did you get this twice in a row?
+            <gg0> to be honest i got another illegal instruction months ago but
+              don't recall doing what
+            <gg0> nope not twice, i've commented it out. then run the remaining
+              and then found out i should not have done what i was doing
+            <gg0> but i could try to reproduce it
+            <gg0> ok now i recall i got it another one few hours ago on real
+              hardware, from logs:
+            <gg0> TestIO#test_copy_stream_socket = Illegal instruction
+            <gg0> teythoon: on real hardware though
+            <gg0> and this is the one i should debug once it finishes, still
+              running
+
+        IRC, freenode, #hurd, 2013-09-11:
+
+            <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind:
+              Assertion `! __spin_lock_locked (&ss->critical_section_lock)'
+              failed.
+            <gg0_> and
+            <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51:
+              __pthread_thread_halt: Unexpected error: (ipc/send) invalid
+              destination port.
+            <tschwinge> gg0_: Which libpthread source are these?  Stock Debian
+              package?
+            <gg0_> tschwinge: everything debian, ruby rebuilt with
+              http://paste.debian.net/plain/38519/ which should disable
+              *context
+
+        IRC, OFTC, #debian-hurd, 2013-09-11:
+
+            <gg0_> wrt ruby, i'd propose a patch that disables *context and
+              comments out failed tests (a dozen). most of them are timing
+              related, don't always fail
+            <gg0_> if they failed gracefully, we could leave them enabled and
+              just ignoring testsuite result, but most of them block testsuite
+              run when fail
+            <gg0_> anyone against? any better idea (and intention to implement
+              it? :p)?
+            <gg0_> youpi: is disabling some tests acceptable? ^
+            <youpi> it'd be good to at least know what is failing
+            <youpi> so as to know what impact hiding these failures will have
+            <youpi> remember that hiding bugs usually means getting bitten by
+              them even harder later :)
+            <gg0_> many of them use pipes
+            <gg0_> here the final list, see commented out ones
+              http://paste.debian.net/plain/38426
+            <gg0_> and as said some don't always fails
+            <gg0_> test_copy_stream_socket uses a socket
+            <youpi> note that we can still at least build packages with notest
+            <youpi> at least to get the binaries uploaded
+            <youpi> disabling *context should however really be done
+            <youpi> and the pipe issues are concerning
+            <youpi> I don't remember other pipe issues
+            <youpi> so maybe it's a but in the ruby bindings
+            <gg0_> i just remember they didn't die, then something unknown
+              fixed it
+            <youpi> I see something frightening in io.c
+            <youpi> #if BSD_STDIO
+            <youpi>          preserving_errno(fseeko(f, lseek(fileno(f),
+              (off_t)0, SEEK_CUR), SEEK_SET));
+            <youpi> #endif
+            <youpi> this looks very much like a workaround for an odd thing in
+              BSD
+            <youpi> it happens that that gets enabled on hurd too, since
+              __MACH__ is defined
+            <youpi> you could try to drop these three lines, just to see
+            <youpi> this is very probably very worth investigating, at any rate
+            <youpi> even just test_gets_limit_extra_arg is a very simple test,
+              that I fail to see why it should ever fail on hurd-i386
+            <youpi> starting debugging it would be a matter of putting printfs
+              in io.c, to check what gets called, with what parameters, etc.
+            <youpi> just a matter of taking the time to do it, it's not very
+              complex
+            <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here
+            <youpi> yes, 1.8
+            <gg0_> 1.9.3.448
+            <gg0_> landed to sid few days ago
+            <youpi> ah, I have 1.87
+            <youpi> +.
+            <gg0_> my favourites are TestIO#test_copy_stream_socket and
+              TestIO#test_cross_thread_close_fd -> Illegal instruction
+            <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal
+              instruction, sometimes ruby1.9.1:
+              ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion
+              `! __spin_lock_locked (&ss->critical_section_lock)' failed.
+
+        [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]?
+
+            <gg0_> trying to debug illegal instruction
+              http://paste.debian.net/plain/38585/
+            <gg0_> (yes, i'm not even good at gdbing)
+            <gg0_> any hint?
+            <gg0_> oh found out there's an intree .gdbinit, that might
+              complicate things
+
+        IRC, OFTC, #debian-hurd, 2013-09-13:
+
+            <gg0_> where should it be implemented MAP_STACK? plus, is it worth
+              doing it considering migration to tls, wouldn't it be useless?
+            <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions
+              frequency from daily to weekly basis
+
+        IRC, OFTC, #debian-hurd, 2013-09-14:
+
+            <gg0_> say i managed to mmap 0x200000-aligned memory
+            <gg0_> now i get almost the same failed tests i get disabling
+              *context
+            <gg0_> that would mean they don't depend on threading
+
+        IRC, freenode, #hurd, 2013-09-16:
+
+            <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53:
+              _longjmp_unwind: Assertion `! __spin_lock_locked
+              (&ss->critical_section_lock)' failed.
+            <gg0> by running ruby testsuite, especially during test_read* tests
+              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972
+            <gg0> read/write operations with pipes
+            <braunr> gg0: that's weird
+            <braunr> gg0: debian glibc ?
+            <gg0> braunr: yep, debian 2.17-92
+            <gg0> sometimes assertion above, sometimes tests in question get
+              stuck reading
+            <gg0> it would be nice reproducing it w/o ruby
+            <gg0> probably massive io on pipes could do the job
+            <gg0> also more nice finding someone who finds it interesting to
+              fix :p
+            <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no
+              *context
+            <gg0> pipe function in tests above creates one thread for write,
+              one for read
+              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
+            <tschwinge> gg0: About the jmp-unwind assertion failure: is it be
+              chance this issue:
+              <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>?
+              I didn't look in detail.
+            <braunr> tschwinge: that's what i thought too about the assertion,
+              which is why i find it strange
+            <gg0> asserting it's not locked then locking it doesn't exclude
+              race conditions
+
+        IRC, OFTC, #debian-hurd, 2013-09-17:
+
+            <gg0> youpi: i guess no one saw it anymore since
+              tg-thread-cancel.diff patch
+            <gg0> it =
+              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
+            <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though
+            <gg0> another assertion to remove?
+            <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we
+              hold no lock at all at the assertion point
+            <youpi> in jmp-unwind.c, we do hold a lock
+            <youpi> and the assertion might be actually true because all other
+              threads are supposed to hold the first lock before taking the
+              other one
+            <youpi> you could check for that in other places
+            <youpi> and maybe it's the other place which wouldhave to be fixed
+            <youpi> also look for documentation which would say that
+
+        IRC, freenode, #hurd, 2013-09-17:
+
+            <braunr_> gg0: is that what we do ??
+            <gg0> braunr: well, i was looking at
+              http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff
+            <gg0> which afaics fixes
+              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
+            <gg0> the one i get now is
+              http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53
+            <gg0> 09:12 < youpi> gg0: it's not exactly the same: in
+              hurd_thread_cancel we hold no lock at all at the assertion point
+            <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock
+            <gg0> 09:13 < youpi> and the assertion might be actually true
+              because all other threads are supposed to hold the first lock
+              before taking the other one
+            <braunr> gg0: that assertion is normal
+            <braunr> it says there is a deadlock
+            <braunr> ss->critical_section_lock must be taken before ss->lock
+            <gg0> you mean ss->lock before ss->critical_section_lock
+            <braunr> no
+            <gg0> ah ok got it
+            <braunr> that's a bug
+            <braunr> longjmp
+            <braunr> ugh
+            <braunr> you could make a pass through the various uses of those
+              locks and check what the intended locking protocol should be
+            <braunr> i inferred ss->critical_section_lock before ss->lock from
+              hurd_thread_cancel
+            <braunr> this might be wrong too but considering this function is
+              used a lot, i doubt it
+            <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where
+              lock is before critical_section_lock)
+            <gg0> could we get useful info from gdb'ing the assertion?
+            <tschwinge> gg0: Only if you first get an understanding why it is
+              happening, what you expect to happen instead/why it shall not
+              happen/etc.  Then you can perhaps use GDB to verify that.
+            <gg0> i can offer an irc interface if anyone is interested, it's
+              ready, just to attach :)
+            <gg0> this is the test
+              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937
+            <gg0> pipe function creates two threads
+              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
+            <gg0> Attaching to pid 15552
+            <gg0> [New Thread 15552.1]
+            <gg0> [New Thread 15552.2]
+            <gg0> (gdb) 
+
+        IRC, freenode, #hurd, 2013-09-21:
+
+            <youpi> gg0: it seems the assert (! __spin_lock_locked
+              (&ss->critical_section_lock)); is bogus
+            <youpi> but it'd be good to catch a call trace
+            <youpi> well, it may not be bogus, in case that lock is only ever
+              taken by the thread itself
+            <youpi> in that case, inside longjmp_unwind we're not supposed to
+              have it already
+            <youpi> ok, that's what we had tried to discuss with Roland
+            <youpi> it can happen when playing with thread cancelation
+            <braunr> youpi: the assertion isn't exactly bogus
+            <braunr> the lock ordering is
+            <youpi> braunr: which one are you talking about?
+            <youpi> the one in hurd_thread_cancel looks really wrong
+            <youpi> and some parts of the code keep the critical section lock
+              without ss->lock held, so I don't see how lock ordering can help
+
+        IRC, OFTC, #debian-hurd, 2013-09-22:
+
+            <gg0> how much does this patch suck on a scale from 1 to 10?
+              http://paste.debian.net/plain/44810/
+            <youpi> well, the stack allocation issue will go away once I get
+              the threadvars away
+            <youpi> I'm working on it right now
+            <youpi> about the lib paths, it makes sense to add the gnu case,
+              but i386-gnu shouldn't be put in the path
+            <gg0> that's great
+            <gg0> so seems the wrong moment for what i've already done
+              ie. asking terceiro what he thinks about patch above :/
+            <gg0> any distro-independent way to get libc.so and libm.so path?
+            <gg0> ruby as last resource takes them from "ldd ruby"
+            <pinotree> gg0: should work fine then
+            <gg0> well it does. but gnu doesn't have a case so it hits default
+              which is broken
+              http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb
+            <gg0> btw even linux and kfreebsd with debian multipath have broken
+              cases but they don't hit default and get fixed by ldd later
+            <pinotree> why it is broken? are arguments passed to that script?
+            <gg0> i'm not sure about what propose. a broken case so it doesn't
+              hit default like linux and kfbsd
+            <gg0> yes they are :/
+            <pinotree> and which ones are? who executes that script and which
+              arguments does it pass to it?
+            <gg0> other ruby scripts which have nothing to do with libc/libm
+            <pinotree> well, if they pass arguments which should be the paths
+              to libc and libm, they must be getting such paths, aren't they?
+            <gg0> they don't. arguments are other ruby scripts, don't know why,
+              maybe something else broken before
+            <gg0> but that would mean that before there's a smarter path
+              detection way, i doubt
+            <pinotree> then add the case for hurd, but setting both libc and
+              libm as nil
+            <pinotree> so they will be fetched again
+            <gg0> yep and would really ugly
+            <gg0> +be
+            <gg0> "please commit this one which wrongly sets paths."
+            <gg0> an alternative would be removing default case
+            <gg0> or pointing it out by proposing ldd in hurd case might make
+              them review the whole detection
+            <gg0> by setting correct paths like in patch above it wouldn't
+              break a possible hurd-amd64, it would work due to ldd
+            <youpi> gg0: that's why I said the patch is fine, but without the
+              i386-gnu part of the path
+            <youpi> just like it happens to be on linux & kfreebsd
+            <gg0> i might take ldconfig -p output
+            <gg0> to make it uselessly correct from start
+            <gg0> http://bugs.ruby-lang.org/issues/8937
+            <pinotree> note thar ruby 1.8 is EOL
+            <pinotree> *that
+            <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby
+              1.8: ruby-trunk, and write like "this bug can be reproduced in
+              Ruby 1.8 as well." --
+            <gg0> i suspect this one won't be the only one i'll file. unless
+              upcoming youpi's tls and braunr's thread destruction patches fix
+              all ruby tests
+            <pinotree> did you check ruby2.0 too, btw?
+            <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of
+              testsuite is not enabled, probably terceiro will enable it soon
+            <gg0> by applying my patch above we'd completely fix current
+              ruby2.0 build (yes because tests are not completely enabled)
+            <pinotree> what you run those extra tests?
+            <gg0>
+              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash
+            <gg0> make test + make test-all
+            <gg0> (test-all is 2nd part)
+            <gg0> many are problematic. i didn't finish yet to suppress them
+              one-by-one. one i suppress, another one pops up
+            <gg0> either get stuck or well known assertion
+            <pinotree> check those that get stuck :)
+            <gg0> which kind of check?
+            <pinotree> "check" as in "debug"
+            <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to
+              be working, at least at trasferring files from master
+            <gg0> don't know about any advanced usage
+            <pinotree> ruby 1.8 is going to die soon, so testing things against
+              it is not totally useful
+            <gg0> so you assume 1.8 is less broken than 1.9/2.0, right?
+            <pinotree> no
+            <gg0> i just can see it's been built without tests itself too
+            <pinotree> erm no
+            <gg0> well ok, if i can be wrong, i'll be wrong
+            <gg0> i say that after a quick check time ago, might be wrong
+            <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last
+              build log
+            <gg0> ah from pkg-kde-tools
+            <gg0> i hate kde :)
+            <pinotree> no?
+            <gg0> no what?
+            <pinotree> devscripts: /usr/bin/getbuildlog
+            <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs
+            <pinotree> which is not what i said
+            <gg0> wait that's what apt-file found
+            <gg0> maybe i should update it
+            <gg0> is it so recent?
+            <pinotree> no
+            <pinotree> i just added an 's' more at the end of the command, but
+              typing getbu<tab> could have been helpful anyway...
+            <gg0> yeah just got it
+            <gg0> my fault not to have tried to run it before looking for it
+            <pinotree> and btw, i don't see what hating kde has to do with
+              tools developed by qt/kde debian packagers
+            <gg0> j/k i simply don't use kde, never used and apt-file search
+              told me it was from pkg-kde-tools
+            <gg0> btw build log says "make test" fails, doesn't even start. and
+              its failure doesn't block the build
+            <pinotree> exactly
+            <gg0> s/make test/make test-all/
+            <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's
+              missing in packaging
+
+        IRC, freenode, #hurd, 2013-09-22:
+
+            <braunr> youpi: i mean the lock order where the assertion occurs is
+              reserved compared to the one in hurd_thread_cancel
+            <braunr> (and the one in hurd_thread_cancel is the same used in
+              hurd condition-related functions)
+            <youpi> "reserved" ?
+            <braunr> reversed
+            <braunr> :)
+            <youpi> by "the assertion occurs", you mean gg0's spot?
+            <braunr> yes
+            <youpi> well , the assertion also happens in hurd_thread_cancel
+            <braunr> it does oO
+            <braunr> i didn't see that
+            <youpi> but otherwise yes, it's completely bogus that we have both
+              locking in different orders
+            <youpi> could you submit the fix for jmp-unwind.c to upstream?
+            <braunr> what fix ?
+            <youpi> reversing the lock order
+            <braunr> ah, simply that
+            <youpi> (well, provided that hurd_thread_cancel is right)
+            <braunr> that's what i suggested to gg0
+            <braunr> to check where those locks are held and determine the
+              right order
+
+        IRC, OFTC, #debian-hurd, 2013-09-28:
+
+            <gg0_> now we'd just need tls
+            <gg0_> http://bugs.ruby-lang.org/issues/8937
+            <gg0_> well, it would pass makecheck at least. makecheckall would
+              keep hanging on threads/pipes tests i guess, unless tls/thread
+              destruction patches fix them
+
+        IRC, OFTC, #debian-hurd, 2013-10-05:
+
+            <youpi> so what is missing for ruby2.0, only disabling use of
+              context for now, no?
+            <pinotree> i'm not tracking it closely, gg0_ is
+            <gg0_> maybe terceiro would accept a patch which only disables
+              *context, "maybe" because he rightly said changes must go
+              upstream
+            <gg0_> anyway with or without *context, many many tests in
+              makecheckall fail by making it hang, first with and without
+              assertion you removed, now they all simply hang
+            <gg0_> youpi: what do we want to do? if you're about finishing tls
+              migration (as i thought a couple of weeks ago), i won't propose
+              anything upstream. otherwise i could but that will have to be
+              reverted upstream once you finish
+            <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only
+              makecheck which succeeds on hurd (w/o context)
+            <gg0_> if anyone wants to give it a try:
+              http://paste.debian.net/plain/51089
+            <gg0_> first hunk makes makecheck (not makecheckall) succeed and
+              has been upstreamed, not packaged yet
+            <pinotree> what about makecheckall for ruby2.0?
+            <gg0_> 16:58 < gg0_> anyway with or without *context, many many
+              tests in makecheckall fail by making it hang, first with and
+              without assertion you  removed, now they all simply hang
+            <pinotree> i for a moment thought it as for 1.9.1, ok
+            <pinotree> these hangs should be debugged, yes
+            <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i
+              started suppressing tests onebyone on 2.0 as well and as happened
+              on 1.9, i gave up cause there were too many
+            <gg0_> yep a smart mind could start debugging them, starting from
+              patch above pasted by a lazy one owner
+            <gg0_> one problem is that one can't reproduce them by isolate
+              them, they don't fail. start makecheckall then wait for one fail
+            <gg0_> now after my stupid report, someone like pinotree could take
+              it over, play with it for half an hour/an hour (which equals to
+              half a gg0's year/a gg0's year
+            <gg0_> )
+            <gg0_> and fix them all
+
+            <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about
+              finishing tls migration (as i thought a couple of weeks ago), i
+              won't propose  anything upstream. otherwise i could but that will
+              have to be reverted upstream once you finish
+            <youpi> gg0_: I don't really know what to answer
+            <youpi> that's why I didn't answer :)
+            <gg0_> youpi: well then we could upstream context disable and keep
+              it disabled even if you fix tls. ruby won't be as fast as it
+              would be with context but i don't think anyone will complain
+              about that. then once packaged, if terceiro doesn't enable
+              makecheckall, we will have ruby2.0 in main
+            <youpi> that can be a plan yes
+            <gg0_> btw reverting it upstream should not be a problem eventually
+            <youpi> sure, the thing is remembering to do it
+            <gg0_> filed http://bugs.ruby-lang.org/issues/8990
+            <gg0_> please don't fix tls too soon :)
+            <gg0_> s/makecheck/maketest/g
+
+        IRC, OFTC, #debian-hurd, 2013-10-08:
+
+            <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990
+
+            <gg0> bt full of an attached stuck ruby test
+              http://paste.debian.net/plain/53788/
+            <gg0> anything useful?
+            <youpi> uh, is that really all?
+            <youpi> there's not much interesting unfortunately
+            <youpi> did you run thread apply all bt full ?
+            <youpi> (not just bt full)
+            <gg0> no just bt full
+            <gg0> http://paste.debian.net/plain/53790/
+            <gg0> wait, there's a child
+            <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/
+            <gg0> restarted testsuite
+            <gg0> isn't it interesting that failed tests fail only if testsuite
+              runs from beginning, whereas if run singularly, they succeed?
+            <gg0> as it got out of whatever resources
+            <gg0> youpi: http://paste.debian.net/plain/53798/
+            <youpi> the interesting part is actually right at the top
+            <youpi> it's indeed stuck in the critical section spinlock
+            <youpi> question being what is keeping it
+            <youpi> iirc I had already checked in the whole glibc code that all
+              paths which lock  critical_section_lock actually release it in
+              all cases, but maybe I have missed some
+            <youpi> (I did find some missing paths, which I fixed)
+            <gg0> i guess the same check you and braunr talk about in
+              discussion just before this anchor
+              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg
+            <youpi> yes, but the issue we were discussing there is not what
+              happens here
+            <youpi> we would see another thread stuck in the other way roudn,
+              otherwise
+            <gg0> no way to get what is locking?
+            <youpi> no, that's not recorded
+            <gg0> and what about writing it somewhere right after getting the
+              lock?
+            <youpi> one will have to do that in all spots taking that lock
+            <youpi> but yes, that's the usual approach
+            <gg0> i would give it try but eglibc rebuild takes too much time,
+              that conflicts with my laziness
+            <gg0> i read even making locks timed would help
+
+        IRC, OFTC, #debian-hurd, 2013-10-09:
+
+            <gg0> so correct order would be:
+            <gg0> __spin_lock (&ss->lock); // locks sigstate
+            <gg0> __spin_lock (&ss->critical_section_lock);
+            <gg0> [do critical stuff]
+            <gg0> __spin_unlock (&ss->critical_section_lock);
+            <gg0> __spin_unlock (&ss->lock);  // unlocks sigstate
+            <gg0> ?
+
+            <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is
+              waiting) https://bugs.ruby-lang.org/issues/9000
+            <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot,
+              it'll build fine on hurd (unless you introduce maketestall as in
+              1.9, that would make it get stuck like 1.9)
+            <gg0> 21:48 < terceiro> gg0: nice
+            <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as
+              I can
+            <gg0> 21:52 < gg0> no problem. you might break my "conditional
+              satisfaction" by adding maketestall. better if you do that on
+              next+1 upload so we'll have at least one 2.0 built :)
+
+            <gg0> would it be a problem granting me access to a porter box to
+              rebuild eglibc+ruby2.0?
+            <gg0> i'm already doing it on another vm but host often loses power
+            <pinotree> you cannot install random stuff on a porterbox though
+            <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess
+            <gg0> (already accessed to porter machines in the past, account
+              lele, mips iirc)
+            <gg0> ldap should remember that
+            <gg0> don't want to disturb anyone else work btw. if it's not a
+              problem, nice. otherwise no problem
+            <pinotree> please send a request to admin@exodar.debian.net so it
+              is not forgotten
+            <gg0> following this one would be too "official"?
+              http://dsa.debian.org/doc/guest-account/
+            <pinotree> hurd is not a release architecture, so hurd machines are
+              not managed by DSA
+            <gg0> ok
+            <pinotree> the general procedure outlines is ok though, just need
+              to be sent to the address above
+            <gg0> sent
+            <gg0> (1st signed mail with mutt, in the worst case i've attached
+              passphrase :))
+            <youpi> gg0: could you send me an ssh key?
+            <pinotree> no alioth account?
+            <youpi> yes, but EPERM
+            <gg0> youpi: sent to youpi@
+            <youpi> youpi@ ?
+            <gg0> (... which doesn't exist :/)
+            <gg0> sthibault@
+            <youpi> please test gg0-guest@exodar.debian.net ?
+            <youpi> (I'd rather not adduser the ldap name, who knows what might
+              happen when you get your DD account)
+            <gg0> i'm in. thanks
+            <youpi> you're welcome
+            <gg0> ldap users need to be adduser'ed?
+            <youpi> I'm not getting your ldap user account from ud-replicate,
+              at least
+            <gg0> (btw i never planned to apply nm, i'd be honoured but i
+              simply think not to deserve it)
+            <youpi> never say never ;)
+            <gg0> bah i like failing. that would be a success. i can't :)
+            <gg0> gg0-guest@exodar:~$ dchroot   
+            <gg0> E: Access not authorised
+            <gg0> I: You do not have permission to access the schroot service.
+            <gg0> I: This failure will be reported.
+            <youpi> ah, right, iirc I need to add you somewhere
+            <youpi> gg0: please retry?
+            <gg0> works
+            <youpi> good
+            <gg0> are there already eglibc+ruby2.0 build-deps?
+            <youpi> yes
+            <gg0> oh that means i should do something myself now :)
+            <youpi> yep, that had to happen at some point :)
+            <gg0> my laziness thanks: "at some point" is better than "now" :)
+
+        IRC, freenode, #hurd, 2013-10-10:
+
+            <gg0> ok just reproduced the
+              former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits
+            <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads
+              ?
+            <gg0> no idea
+            <gg0> braunr: days ago you and youpi talked about locking order
+              (just before this anchor
+              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg)
+            <braunr> oh right
+            <gg0> <youpi> could you submit the fix for jmp-unwind.c to
+              upstream?
+            <braunr> it didn't made it in the todo list
+            <gg0> so correct order is in hurd_thread_cancel, right?
+            <braunr> sorry about that
+            <braunr> we need to make a pass to make sure it is
+            <gg0> that means locking first ss->critical_section_lock _then_
+              ss->lock
+            <gg0> correct?
+            <braunr> but considering how critical hurd_thread_cancel is, i
+              expect so
+
+            <gg0> i get the same deadlock by swapping locks
+            <gg0> braunr: youpi: fyi ^
+            <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and
+              destroy threads ?
+            <gg0> how could i check it?
+            <braunr> gg0: ps -eflw
+            <youpi> gg0: that's not surprising, since in the b acktrace you
+              posted there isn't another thread locked in the other order
+            <youpi> so it's really that somehow the thread is already in
+              critical sesction
+            <braunr> youpi: you mean there is ?
+            <braunr> ah, it's not the same bug
+            <youpi> no, in what he posted, no other thread is stuck 
+            <youpi> so it's not a locking order
+            <youpi> just that the critical section is actually busy
+            <gg0> youpi: ack
+            <gg0> braunr: what's the other bug? ext2fs one?
+            <braunr> gg0: idk
+            <gg0> braunr: thanks. doesn't show threads (found -T for that) but
+              at least doesn't limit columns number if piped (thanks to -w)
+            <braunr> it does
+            <braunr> there is a TH column
+            <gg0> ok thread count. -T gives more info
+
+        IRC, freenode, #hurd, 2013-10-24:
+
+            <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw
+            <gg0> youpi: without d-ports patches? surprise me :)
+            <youpi> gg0: plain main archive source
+            <gg0> you did it. surprised
+            <gg0> ah ok you just pushed your tls. great!
+            <braunr> tls will fix a lot of things
+
+        IRC, OFTC, #debian-hurd, 2013-11-03:
+
+            <youpi> gg0: 
+            <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped
+              [ruby-core:28924]
+            <youpi> FAIL 1/949 tests failed
+            <youpi> with the to-be-uploaded glibc
+            <gg0> why does it coredump?
+            <gg0> that's the test i had workarounded by increasing sleep from 1
+              to 3 but i don't recall it coredump'ed
+            <gg0> *recall if
+            <gg0> "sleep 1" at bootstraptest/test_fork.rb:33
+            <youpi> how can I run the test alone?
+
+        IRC, OFTC, #debian-hurd, 2013-11-04:
+
+            <youpi> gg0: ^
+            <gg0> it should not take much
+            <gg0> run $ make OPTS=-v test
+            <gg0> found out how to minimize
+            <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi
+            <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common
+              ./tool/runruby.rb --extout=.ext  -- --disable-gems
+              "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v
+            <gg0> youpi: that should work
+            <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or
+              directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
+              -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0  bootstraptest.tmp.rb
+              [ruby-dev:32404]
+            <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
+            <youpi> well it's ruby1.9.1 indeed :)
+            <youpi> ok, got core
+            <gg0> replace 2.0 with 1.9, check what you have in rootdir
+            <gg0> k
+            <youpi> Mmm, no, there's no core file
+            <gg0> does stupidly increasing sleep time work?
+            <youpi> nope
+            <gg0> without *context it runs "make test" fine. real problems come
+              later with "make test-all"
+            <gg0> wrt test_fork, is correspondence between signals correct? i
+              recall i read something about USR1 not implemented
+            <youpi> USR1 is implemented, it's SIGRT which is not implemented
+            <gg0> my next wild guess is that that has something to do with
+              atfork, whatever that means
+            <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1
+              itself, the second traps USR1 in getting current time. in the
+              meanwhile parent sleeps for 2 secs
+
+        IRC, OFTC, #debian-hurd, 2013-11-07:
+
+            <gg0> ruby2.0 just built on unstable
+
+        IRC, OFTC, #debian-hurd, 2013-11-09:
+
+            <gg0> youpi: just found out a more "official" way to run one test
+              only
+              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD
+            <gg0> btw still getting coredumps?
+
+        IRC, OFTC, #debian-hurd, 2013-11-13:
+
+            <gg0> wrt the other test test_fork i suppose you made it not to
+              segfault anymore, it simply does fail
+            <youpi> I haven't taken any particular care
+            <youpi> didn't have any time to deal with it
+
+        IRC, OFTC, #debian-hurd, 2013-11-14:
+
+            <gg0> btw patches to disable *context have been backported to 1.9
+              as well so next 1.9 point release should have *context disabled
+            <gg0> as 2.0 have
+            <gg0> *has
+            <gg0> i guess you'd like to get them reverted now
+            <gg0> youpi: ^
+            <youpi> after testing that *context work, yes
+
+      * `sigaltstack`
+
+        IRC, freenode, #hurd, 2013-10-09:
+
+            <gnu_srs1> Hi, is sigaltstack() really supported, even if it is
+              defined as well as SA_ONSTACK?
+            <braunr> probably not
+            <braunr> well,
+            <braunr> i don't know actually, mistaking with something else
+            <braunr> it may be supported
+            <pinotree> iirc no
+            <gnu_srs1> pinotree: are you sure?
+            <pinotree> this is what i remember
+            <pinotree> if you want to be sure that $foo works, just do the
+              usual way: test it yourself
+            <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack
+              really work? -- NO
+            <pinotree> well TODO is old and there were signal-related patches
+              by jk in the meanwhile, although i don't think they would have
+              changed this lack
+            <pinotree> in any case, test it
+            <gnu_srs1> anybody fluent in assembly? Looks like this code
+              destroys the stack: http://paste.debian.net/54331/
+            <braunr> gnu_srs1: why would it ?
+            <braunr> it does something special with the stack pointer but it
+              just looks like it aligns it to 16 bytes, maybe because of sse2
+              restrictions (recent gcc align the stack already anyway)
+            <gnu_srs1> Well, in that case it is the called function:
+              http://paste.debian.net/54341/
+            <braunr> how do you know there is a problem with the stack in the
+              first place ?
+            <gnu_srs1> tracing up to here, everything is OK. then esp and ebp
+              are destroyed.
+            <gnu_srs1> and single stepping goes backward until it segfaults
+            <braunr> "destroyed" ?
+            <gnu_srs1> zero if I remember correctly now. the x86 version built
+              for is i586, should that be changed to i486?
+            <braunr> this shouldn't change anything
+            <braunr> and they shouldn't get to 0
+            <braunr> use gdb to determine exactly which instruction resets the
+              stack pointer
+            <gnu_srs1> how to step into the assembly part? using 's' steps
+              through the function since no line information:
+            <gnu_srs1> Single stepping until exit from function
+              wine_call_on_stack,
+            <gnu_srs1> which has no line number information.
+            <braunr> gnu_srs1: use break on the address
+            <gnu_srs1> how do i get the address of where the assembly starts?
+
+      * <a id=recvmmsg>`recvmmsg`/`sendmmsg` (`t/sendmmsg`)</a>
+
+        From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]],
+        Roland McGrath: *They are generally useful interfaces and there is
+        nothing intrinsically Linuxoid about them.  At least when not given a
+        timeout, they could be implemented in terms of sendmsg/recvmsg.  So
+        perhaps we ought to have a sysdeps/posix implementation that the Hurd
+        would use instead of stubs (and folks can consider adding new RPCs).
+        Then perhaps the Linux fallback case should be that instead of stubs,
+        too.*
+
+      * <a id=SOCK_CLOEXEC>`SOCK_CLOEXEC`</a>
+
+        IRC, freenode, #hurd, 2013-09-02:
+
+            <gnu_srs1> Do we support  accept4  with the SOCK_CLOEXEC flag?
+            <gnu_srs1> According to the code in  sysdeps/mach/hurd/accept4.c
+              that case is not covered 
+            <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??))
+            <pinotree> gnu_srs1: we do
+            <pinotree> but only for accept4, not for socket and socketpair
+            <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in
+              __libc_accept4()
+            <pinotree> gnu_srs1: no, you need SOCK_*
+            <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and
+              it uses O_* for flags ?
+            <pinotree>   flags = sock_to_o_flags (flags);
+            <pinotree> tried checking it?
+            <gnu_srs1> Aha, tks:-D
+            <pinotree> and you don't need an explicit case of O_CLOEXEC, since
+              it is handled in other ways
+
+        [[!message-id "1378154151.21738.15.camel@G3620.my.own.domain"]].
+
+        IRC, freenode, #hurd, 2013-09-03:
+
+            <gnu_srs> any ideas about the SOCK_CLOEXEC issue?
+            <pinotree> didn't i tell already about it?
+            <gnu_srs> I did not find any hurd related code in tschwinges
+              branches.
+            <pinotree> you didn't check deep then...
+            <gnu_srs> so why does socket/socketpair not return ENOSYS then?
+            <pinotree> why should it, since they are implemented?
+            <braunr> ...
+            <gnu_srs> for socket/socketpair?
+            <braunr> gnu_srs: enosys means no system call
+            <gnu_srs> s/ENOSYS/EINVAL/
+            <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info
+            <gnu_srs> and tschwinges reply
+            <pinotree> which is what i knew already?
+            <gnu_srs> pinotree: please reply on the mailing list on the EINVAL
+              vs EPROTOTYPE issue to clarify things
+            <pinotree> gnu_srs:
+              https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html
+            <pinotree> gnu_srs: things were clear already...
+            <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c
+              returns EPROTOTYPE not changed by the __socket wrapper in eglibc
+            <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends
+              are NOT posix?
+            <gnu_srs> since socket/socketpair does not return EINVAL the dbus
+              code has to be patched then?
+            <pinotree> pflocal should never ever get such flags mixed to the
+              protocol, so any invalid value of protocol correctly returns
+              EPROTOTYPE
+            <gnu_srs> this is the question I need answered: Which way to go?
+            <pinotree> all of them
+            <gnu_srs> ?
+            <pinotree> - applications should not assume that because you have
+              accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK
+              (flags for it) are usable to socket and socketpair
+            <pinotree> - glibc should (as the idea of my patch) handle
+              implementations providing SOCK_* but not supporting them for
+              socket/socketpair
+            <pinotree> - finally the hurd part of glibc could implement them
+            <gnu_srs> to conclude: should I send a bug report for dbus then?
+            <gnu_srs> pinotree: yes or no?
+            <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream*
+              report (not a debian one)
+
+        IRC, freenode, #hurd, 2013-09-06:
+
+            <gnu_srs> I've found another error code issue, now in  glib2.0 (and
+              dbus). Are you really sure the error code 
+            <gnu_srs> for protocol of pflocal/pf.c should be
+              EPROTONOSUPPORT. The code expects EINVAL for a protocol with
+            <gnu_srs>  SOCK_CLOEXEC, which is a flag. Maybe pf.c should add
+              this case and return EINVAL instead of 
+            <gnu_srs> submitting bug reports upstream. Yes, I know this is not
+              POSIX, but it is defined for Hurd too, 
+            <gnu_srs> currently only supported for accept4, not socket or
+              socketpair. 
+            <pinotree> gnu_srs: no, and i explained already why it is wrong
+              this way
+            <pinotree> pflocal shouldn't even get such flags
+            <pinotree> (pflocal or any other server implementing socket_create)
+            <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such
+              flags
+            <gnu_srs> then the glibc wrapper code is missing to catch this
+              flag:(
+            <gnu_srs> youpi: ?
+            <pinotree> gnu_srs: because, as told many times, socket and
+              socketpair do not support such flags
+            <pinotree> given they don't do, they filter nothing
+            <pinotree> and no, you need to file bugs upstream, since having
+              SOCK_* and accept4 does not imply at all that socket and
+              socketpair support them
+
+        IRC, freenode, #hurd, 2013-09-07:
+
+            <gnu_srs> A correction from yesterdays discussion:
+              s/EPROTONOSUPPORT/EPROTOTYPE
+
+        IRC, freenode, #hurd, 2013-09-10:
+
+            <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case
+              needs a patch too (more working tests),
+            <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if
+              you have the time, otherwise I'll do it.
+            <pinotree> gnu_srs: which is what i wrote in my bug report...
+            <gnu_srs> Yes you wrote that, but the patch is not updated yet?
+            <pinotree> it refers to a different socket access, recently added,
+              which is not used by default
+            <gnu_srs> I got two more tests running when adding that patch:-/
+            <pinotree> tests of what?
+            <gnu_srs>  run-test.sh and run-test-systemserver.sh:P
+            <pinotree> tests of what?
+            <pinotree> i don't have the universal knowledge of the files in all
+              the sources
+            <gnu_srs> dbus-1.6.14/test/name-test/*
+
+        [[!message-id "523A3D6C.2030200@gmx.de"]].
+
+        IRC, OFTC, #debian-hurd, 2013-09-19:
+
+            <pinotree> tschwinge: ehm, regarding the SOCK_* patches for
+              socket/socketpair, didn't we talk about them when i worked on
+              eglibc 2.17?
+
+      * `mlock`, `munlock`, `mlockall`, `munlockall`
+
+        IRC, freenode, #hurd, 2014-01-09:
+
+            <gnu_srs> Hi, is mlock, mlockall et al implemented?
+            <braunr> i doubt it
+            <braunr> mlock could be, but mlockall only partially
+
+      * [[glibc_IOCTLs]]
+
+      * Support for `$ORIGIN` in the dynamic linker, `ld.so`
+
+        IRC, freenode, #hurd, 2014-02-23:
+
+            <sjamaan>
+              https://www.gnu.org/software/hurd/user/jkoenig/java/report.html
+              says $ORIGIN patches have been added to Hurd.  Have those hit the
+              mainline codebase?
+
+        [[user/jkoenig/java]], [[user/jkoenig/java/report]].
+
+            <sjamaan> It doesn't seem to work here, but perhaps I'm missing
+              something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM
+              image)
+            <sjamaan> objdump -x says the value of RPATH is $ORIGIN
+            <sjamaan> But it doesn't load a library I placed in the same dir as
+              the binary
+            <braunr> sjamaan: i'm not sure
+            <braunr> sjamaan: what are you trying to do ?
+
+        IRC, freenode, #hurd, 2014-02-24:
+
+            <sjamaan> braunr: I am working on a release of the CHICKEN Scheme
+              compiler. Its test suite is currently failing on the stand-alone
+              deployment tests.  Either it should work and use $ORIGIN, or the
+              test should be disabled, saying Hurd is not supported for
+              stand-alone deployment-directories
+            <sjamaan> braunr: The basic idea is to be able to create "appdirs"
+              like on OS X or PC-BSD, containing all the dependencies a program
+              needs, which can then simply be untarred
+            <braunr> sjamaan: ok so you do need $ORIGIN
+            <sjamaan> yeah
+            <sjamaan> iiuc, so does Java.  Does Java work on Hurd?
+            <braunr> we had packages at the time jkoenig worked on it
+            <braunr> integration of patches may have been incomplete, i wasn't
+              there at the time and i'm not sure
+            <sjamaan> So it's safest to claim it's unsupported, for now?
+            <braunr> yes
+            <sjamaan> Thank you, I'll do that and revisit it later
+
+      * `mig_reply_setup`
+
+        IRC, freenode, #hurd, 2014-02-24:
+
+            <teythoon> braunr: neither hurd, gnu mach or glibc provides
+              mig_reply_setup
+            <teythoon> i want to provide this function, where should i put it ?
+            <teythoon> i found some mach source that put it in libmach afaic
+            <teythoon>
+              ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c
+            <braunr> teythoon: what does it do ?
+            <teythoon> braunr: not much, it just initializes the reply message
+            <teythoon> libports does this as well, in the
+              ports_manage_port_operations* functions
+            <braunr> teythoon: is it a new function you're adding ?
+            <teythoon> braunr: yes
+            <teythoon> braunr: glibc has a declaration for it, but no
+              implementation
+            <braunr> teythoon: i think it should be in glibc
+            <braunr> maybe in mach/
+
+      * [[POSIX file record locking|file_locking]]
+
+      * <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
+
+      * <a name="posix_timers">POSIX Timers</a>
+
+        `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and
+        so on.
+
+    For specific packages:
+
+      * <a id=octave>[[octave]]</a>
+
+  * <a id=t_cleanup_kernel-features.h>Create `t/cleanup_kernel-features.h`.</a>
+
+  * <a id=Secure_file_descriptor_handling>[[Secure_file_descriptor_handling]].</a>
+
+  * <a id=sendfile>In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of
+    `-DHAVE_SENDFILE` -- but we do have `sendfile`, too.</a>
+
+    Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile`
+    works.
+
+  * <a id=pthreadoverwrite>`/usr/include/pthread.h` overwrite issue</a>
+
+    `make`, after editing `nss/nss_db/db-initgroups.c`:
+
+        [...]
+        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv'
+        make  subdir=nss -C nss ..=../ others
+        make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
+        /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
+        /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
+        make[2]: *** [/usr/include/pthread.h] Error 1
+        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
+        make[1]: *** [nss/others] Error 2
+        make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker'
+        make: *** [all] Error 2
+
+    See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]].  Passing
+    `install_root=/INVALID` to `make`/`make check` is a cheap cure.  For `make
+    install`, prepending an additional slash to `install_root` (that is,
+    `install_root=//[...]`) is enough to obfuscate the Makefile rules.
+
+  * <a id=syslog.c>`sysdeps/unix/sysv/linux/syslog.c`</a>
+
+  * <a id=fsync>`fsync` on a pipe</a>
+
+    IRC, freenode, #hurd, 2012-08-21:
+
+        <braunr> pinotree: i think gnu_srs spotted a conformance problem in
+          glibc
+        <pinotree> (only one?)
+        <braunr> pinotree: namely, fsync on a pipe (which is actually a
+          socketpair) doesn't return EINVAL when the "operation not supported"
+          error is returned as a "bad request message ID"
+        <braunr> pinotree: what do you think of this case ?
+        <pinotree> i'm far from an expert on such stuff, but seems a proper E*
+          should be returned
+        <braunr> (there also is a problem in clisp falling in an infinite loop
+          when trying to handle this, since it uses fsync inside the error
+          handling code, eww, but we don't care :p)
+        <braunr> basically, here is what clisp does
+        <braunr> if fsync fails, and the error isn't EINVAL, let's report the
+          error
+        <braunr> and reporting the error in turn writes something on the
+          output/error stream, which in turn calls fsync again
+        <pinotree> smart
+        <braunr> after the stack is exhausted, clisp happily crashes
+        <braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our
+          mig specific error
+        <braunr> if that's the problem (which i strongly suspect), the solution
+          will be to add an error conversion for fsync so that it returns
+          EINVAL
+        <braunr> if pinotree is willing to do that, he'll be the only one
+          suffering from the dangers of sending stuff to the glibc maintainers
+          :p
+        <pinotree> that shouldn't be an issue i think, there are other glibc
+          hurd implementations that do such checks
+        <gnu_srs> does fsync return EINVAL for other OSes?
+        <braunr>        EROFS, EINVAL
+        <braunr>               fd is bound to a special file which does not
+          support synchronization.
+        <braunr> obviously, pipes and sockets don't
+        <pinotree>
+          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html
+        <braunr> so yes, other OSes do just that
+        <pinotree> now that you speak about it, it could be the failure that
+          the gnulib fsync+fdatasync testcase have when being run with `make
+          check` (although not when running as ./test-foo)
+        <braunr> hm we may not need change glibc
+        <braunr> clisp has a part where it defines a macro IS_EINVAL which is
+          system specific
+        <braunr> (but we should change it in glibc for conformance anyway)
+        <braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) ||
+          defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA
+          ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
+        <pinotree> i'd rather add nothing to clisp
+        <braunr> let's see what posix says
+        <braunr> EINVAL
+        <braunr> so right, we should simply convert it in glibc
+        <gnu_srs> man fsync mentions EINVAL
+        <braunr> man pages aren't posix, even if they are usually close
+        <gnu_srs> aha
+        <pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other
+          parts do) will b enough
+        <pinotree> *be
+        <braunr> gnu_srs: there, it finished correctly even when piped
+        <gnu_srs> I saw that, congrats!
+        <braunr> clisp is quite tricky to debug
+        <braunr> i never had to deal with a program that installs break points
+          and handles segfaults itself in order to implement growing stacks :p
+        <braunr> i suppose most interpreters do that
+        <gnu_srs> So the permanent change will be in glibc, not clisp?
+        <braunr> yes
+
+    IRC, freenode, #hurd, 2012-08-24:
+
+        <gnu_srs1> pinotree: The changes needed for fsync.c is at
+          http://paste.debian.net/185379/ if you want to try it out (confirmed
+          with rbraun)
+        <youpi> I agree with the patch, posix indeed documents einval as the
+          "proper"  error value
+        <pinotree> there's fdatasync too
+        <pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID
+        <braunr> pinotree: i assume that if you're telling us, it's because
+          they have different values
+        <pinotree> braunr: tbh i never seen the E version, and everywhere in
+          glibc the non-E version is used
+        <gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is
+          defined
+        <pinotree> look in gnumach/include/mach/mig_errors.h
+        <pinotree> (as the comment in errno.h say)
+        <gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors
+          from <mach/mig_errors.h>.  */ and then the EMIG_ stuff?
+        <gnu_srs1> Which one is used when building libc?
+        <gnu_srs1> Answer: At least in fsync.c errno.h is used: #include
+          <errno.h>
+        <gnu_srs1> Yes, fdatasync.c should be patched too.
+        <gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. 
+        <gnu_srs1> /usr/include/i386-gnu/bits/errno.h:     /* Errors from
+          <mach/mig_errors.h>.  */
+        <gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h>
+
+    IRC, freenode, #hurd, 2012-09-02:
+
+        <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably
+          should be translated to EINVAL, if that's what POSIX says. it does
+          *not* sound right to translate MIG_BAD_ID though. the server should
+          explicitly return EOPNOTSUPP, and that's what the default trivfs stub
+          does. if you actually do see MIG_BAD_ID, there must be some other
+          bug...
+        <braunr> antrik: right, pflocal doesn't call the trivfs stub for socket
+          objects
+        <braunr> trivfs_demuxer is only called by the pflocal node demuxer, for
+          socket objects it's another call, and i don't think it's the right
+          thing to call trivfs_demuxer there either
+        <pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know
+          what the underlying server actually implements
+        <pinotree> (imho)
+        <braunr> for me, a bad id is the same as a not supported operation
+        <pinotree> ditto
+        <pinotree> from fsync's POV, both the results are the same anyway, ie
+          that the server does not support a file_sync operation
+        <antrik> no, a bad ID means the server doesn't implement the protocol
+          (or not properly at least)
+        <antrik> it's usually a bug IMHO
+        <antrik> there is a reason we have EOPNOTSUPP for operations that are
+          part of a protocol but not implemented by a particular server
+        <pinotree> antrik: even if it could be the case, there's no reason to
+          make fsync fail anyway
+        <antrik> pinotree: I think there is. it indicates a bug, which should
+          not be hidden
+        <pinotree> well, patches welcome then...
+        <antrik> thing is, if sock objects are actually not supposed to
+          implement the file interface, glibc shouldn't even *try* to call
+          fsync on them
+        <pinotree> how?
+        <pinotree> i mean, can you check whether the file interface is not
+          implemented, without doing a roundtrip^
+        <pinotree> ?
+        <antrik> well, the sock objects are not files, i.e. they were *not*
+          obtained by file_name_lookup(), but rather a specific call. so glibc
+          actually *knows* that they are not files.
+        <braunr> antrik: this way of thinking means we need an "fd" protocol
+        <braunr> so that objects accessed through a file descriptor implement
+          all fd calls
+        <antrik> now I wonder though whether there are conceivable use cases
+          where it would make sense for objects obtained through the socket
+          call to optionally implement the file interface...
+        <antrik> which could actually make sense, if libc lets through other
+          file calls as well (which I guess it does, if the sock ports are
+          wrapped in normal fd structures?)
+        <braunr> antrik: they are
+        <braunr> and i'd personally be in favor of such an fd protocol, even if
+          it means implementing stubs for many useless calls
+        <braunr> but the way things are now suggest a bad id really means an
+          operation is simply not supported
+        <antrik> the question in this case is whether we should make the file
+          protocol mandatory for anything that can end up in an FD; or whether
+          we should keep it optional, and add the MIG_BAD_ID calls to *all* FD
+          operations
+        <antrik> (there is no reason for fsync to be special in this regard)
+        <braunr> yes
+        <antrik> braunr: BTW, I'm rather undecided whether the right approach
+          is a) requiring an FD interface collection, b) always checking
+          MIG_BAD_ID, or perhaps c) think about introducing a mechanism to
+          explicitly query supported interfaces...
+
+    IRC, freenode, #hurd, 2012-09-03:
+
+        <braunr> antrik: querying interfaces sounds like an additional penalty
+          on performance
+        <antrik> braunr: the query usually has to be done only once. in fact it
+          could be integrated into the name lookup...
+        <braunr> antrik: once for every object
+        <braunr> antrik: yes, along with the lookup would be a nice thing
+
+    [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]].
+
+  * <a id=t_no-hp-timing>`t/no-hp-timing`</a>
+
+    IRC, freenode, #hurd, 2012-11-16
+
+        <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing,
+          couldn't that file be just replaced by #include
+          <sysdeps/generic/hp-timing.h>?
+
+  * <a id=flockfile>`flockfile`/`ftrylockfile`/`funlockfile`</a>
+
+    IRC, freenode, #hurd, 2012-11-16
+
+        <pinotree> youpi: uhm, in glibc we use
+          stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg
+          the nptl versions, which do lock/trylock/unlock); do you know more
+          about them?
+        <youpi> pinotree: ouch
+        <youpi> no, I don't know
+        <youpi> well, I do know what they're supposed to do
+        <pinotree> i'm trying fillig them, let's see
+        <youpi> but not why we don't have them
+        <youpi> (except that libpthread is "recent")
+        <youpi> yet another reason to build libpthread in glibc, btw
+        <youpi> oh, but we do provide lockfile in libpthread, don't we ?
+        <youpi> pinotree: yes, and libc has weak variants, so the libpthread
+          will take over
+        <pinotree> youpi: sure, but that in stuff linking to pthreads
+        <pinotree> if you do a simple application doing eg main() { fopen +
+          fwrite + fclose }, you get no locking
+        <youpi> so?
+        <youpi> if you don't have threads, you don't need locks :)
+        <pinotree> ... unless there is some indirect recursion
+        <youpi> ?
+        <pinotree> basically, i was debugging why glibc tests with mtrace() and
+          ending with muntrace() would die (while tests without muntrace call
+          wouldn't)
+        <youpi> well, I still don't see what a lock will bring
+        <pinotree> if you look at the muntrace implementation (in
+          malloc/mtrace.c), basically fclose can trigger a malloc hook (because
+          of the free for the FILE*)
+        <youpi> either you have threads, and it's need, or you don't, and it's
+          a nop
+        <youpi> yes, and ?
+        <braunr> does the signal thread count ?
+        <youpi> again, in linux, when you don't have threads, the lock is a nop
+        <youpi> does the signal thread use IO ?
+        <braunr> that's the question :)
+        <braunr> i hope not
+        <youpi> IIRC the signal thread just manages signals, and doesn't
+          execute the handler itself
+        <braunr> sure
+        <braunr> i was more thinking about debug stuff
+        <youpi> can't hurt to add them anyway, but let me still doubt that it'd
+          fix muntrace, I don't see why it would, unless you have threads
+        <pinotree> that's what i'm going next
+        <pinotree> pardon, it seems i got confused a bit
+        <pinotree> it'd look like a genuine muntrace bug (muntrace → fclose →
+          free hook → lock lock → fprint (since the FILE is still set) → malloc
+          → malloc hook → lock lock → spin)
+        <pinotree> at least i got some light over the flockfile stuff, thanks
+          ;)
+        <pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base
+          implementation, while doing real locks on hurd in any case, and on
+          linux only if nptl is loaded, it seems
+        <pinotree> that would explain why on linux you get no deadlock
+        <youpi> unless using nptl, that is?
+        <pinotree> hm no, even with pthread it works
+        <pinotree> but hey, at least the affected glibc test now passes
+        <pinotree> will maybe try to do investigation on why it works on linux
+          tomorrow
+
+    [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]].
+
+    In context of [[libpthread]].
+
+    IRC, freenode, #hurd, 2013-01-21
+
+        <braunr> ah, found something interesting
+        <braunr> tschwinge: there seems to be a race on our file descriptors
+        <braunr> the content written by one thread seems to be retained
+          somewhere and another thread writing data to the file descriptor will
+          resend what the first already did
+        <braunr> it could be a FILE race instead of fd one though
+        <braunr> yes, it's not at the fd level, it's above
+        <braunr> so good news, seems like the low level message/signalling code
+          isn't faulty here
+        <braunr> all right, simple explanation: our IO_lockfile functions are
+          no-ops
+        <pinotree> braunr: i found that out days ago, and samuel said they were
+          okay
+        <braunr> well, they're not no-ops in libpthreads
+        <braunr> so i suppose they replace the default libc stubs, yes
+        <pinotree> so the issue happens in cthreads-using apps?
+        <braunr> no
+        <braunr> we don't have cthreads apps any more
+        <braunr> and aiui, libpthreads provides cthreads compatibility calls to
+          libc, so everything is actually using pthreads
+        <braunr> more buffer management debugging needed :/
+        <pinotree> hm, so how can it be that there's a multithread app with no
+          libpthread-provided file locking?
+        <braunr> ?
+        <braunr> file locking looks fine
+        <braunr> hm, the recursive locking might be wrong though
+        <braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define
+          __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0))
+        <braunr> nop, looks fine too
+        <braunr> indeed, without stream buffering, the problem seems to go away
+        <braunr> pinotree: it really looks like the stub IO_flockfile is used
+        <braunr> i'll try to make sure it's the root of the problem
+        <pinotree> braunr: you earlier said that there's some race with
+          different threads, no?
+        <braunr> yes
+        <braunr> either a race or an error in the iostream management code
+        <braunr> but i highly doubt the latter
+        <pinotree> if the stub locks are used, then libpthread is not
+          loaded... so which different threads are running?
+        <braunr> that's the thing
+        <braunr> the libpthread versions should be used
+        <pinotree> so the application is linked to pthread?
+        <braunr> yes
+        <pinotree> i see, that was the detail i was missing earlier
+        <braunr> the common code looks fine, but i can see wrong values even
+          there
+        <braunr> e.g. when vfprintf calls write, the buffer is already wrong
+        <braunr> i've made similar tests on linux sid, and it behaves as it
+          should
+        <pinotree> hm
+        <braunr> i even used load to "slow down" my test program so that
+          preemption is much more likely to happen
+        <pinotree> note we have slightly different behaviour in glibc's libio,
+          ie different memory allocation ways (mmap on linux, malloc for us)
+        <braunr> the problem gets systematic on the hurd while it never occurs
+          on linux
+        <braunr> that shouldn't matter either
+        <pinotree> ok
+        <braunr> but i'll make sure it doesn't anyway
+        <braunr> this mach_print system call is proving very handy :)
+        <braunr> and also, with load, unbuffered output is always correct too
+        <pinotree> braunr: you could try the following hack
+          http://paste.debian.net/227106/
+        <braunr> what does it do ?
+        <pinotree> (yes, ugly as f**k)
+        <braunr> does it force libio to use mmap ?
+        <braunr> or rather, enable ?
+        <pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use
+          mmap (like on linux) instead of malloc
+
+  * <a id=t_pagesize>`t/pagesize`.</a>
+
+        <braunr> yes, the stub is used instead of the libpthreads code
+        <braunr> tschwinge: ^
+        <braunr> i'll override those to check that it fixes the problem
+        <braunr> hm, not that easy actually
+        <pinotree> copy their files from libpthreads to sysdeps/mach/hurd
+        <pinotree> hm right, in libpthread they are not that split as in glibc
+        <braunr> let's check symbol declaration to understand why the stubs
+          aren't overriden by ld
+        <braunr> _IO_vfprintf correctly calls @plt versions
+        <braunr> i don't know enough about dynamic linking to see what causes
+          the problem :/
+        <braunr> youpi: it seems our stdio functions use the stub IO_flockfile
+          functions
+        <youpi> really? I thought we were going through cthreads-compat.c
+        <braunr> yes really
+        <braunr> i don't know why, but that's the origin of the "duplicated"
+          messages issue
+        <braunr> messages aren't duplicated, there is a race that makes on
+          thread reuse the content of the stream buffer
+        <braunr> one*
+        <youpi> k, quite bad
+        <braunr> at least we know where the problem comes from now
+        <braunr> youpi: what would be the most likely reason why weak symbols
+          in libc wouldn't be overriden by global ones from libpthread ?
+        <youpi> being loaded after libc
+        <braunr> i tried preloading it
+        <braunr> i'll compare with what is done on wheezy
+        <youpi> you have the local-dl-dynamic-weak.diff patch, right?
+        <braunr> (on squeeze, the _IO_flockfile function in libc seems to do
+          real work unlike our noop stub)
+        <braunr> it's the debian package, i have all patches provided there
+        <braunr> indeed, on linux, libc provides valid IO_flock functions
+        <braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile,
+          _IO_flockfile)
+        <braunr> that's how ntpl exports it
+        <braunr> nptl*
+        <pinotree> imho we should restructure libpthread to be more close to
+          nptl
+        <braunr> i wish i knew what it involves
+        <pinotree> file structing for sources and tests, for example
+        <braunr> well yes obviously :)
+        <braunr> i've just found a patch that does exactly that for linuxthreads
+        <pinotree> that = fix the file locking?
+        <braunr> in addition to linuxthreads/lockfile.c (which we also
+          equivalently provide), there is
+          linuxthreads/sysdeps/pthread/flockfile.c
+        <braunr> no, restructiring
+        <braunr> restructuring*
+        <braunr> i still have only a very limited idea of how the glibc sources
+          are organized
+        <pinotree> the latter is used as source file when compiling flockfile.c
+          in stdio-common
+        <braunr> shouldn't we provide one too ?
+        <pinotree> that would mean it would be compiled as part of libc proper,
+          not libpthread
+        <braunr> yes
+        <braunr> that's what both linuxthreads and nptl seem to do
+        <braunr> and the code is strictly the same, i.e. a call to the internal
+          _IO_lock_xxx functions
+        <youpi> I guess that's for the hot-dlopen case
+        <youpi> you need to have locks properly taken at dlopen time
+        <braunr> youpi: do you mean adding an flockfile.c file to our sysdeps
+          will only solve the problem by side effect ?
+        <braunr> and that the real problem is that the libpthread versions
+          aren't used ?
+        <youpi>  yes
+        <braunr> ok
+        <braunr> youpi: could it simply be a versioning issue ?
+        <youpi> could be
+        <braunr> it seems so
+        <braunr> i've rebuilt with the flockfile functions versioned to 2.2.6
+          (same as in libc) and the cthreads_compat functions are now used
+        <braunr> and the problem doesn't occur any more with my test code
+        <braunr> :)
+        <youpi> could you post a patch?
+        <braunr> i need a few info before
+        <youpi> it'd be good to check which such functions are hooked
+        <braunr> i suppose the version for functions declared in libpthreads
+          shouldn't change, right ?
+        <youpi> yes
+        <braunr> ok
+        <youpi> they didn't have a vresion before
+        <braunr> shall i commit directly ?
+        <youpi> so it should be fine
+        <braunr> well, they did
+        <braunr> 2.12
+        <youpi> yes, but please tell me when it's done
+        <braunr> sure
+        <youpi> so I can commit that to debian's eglibc
+        <youpi> I mean, before we integrated libpthread build into glibc
+        <youpi> so they never had any version before 2.12
+        <braunr> ok
+        <youpi> basically we need to check the symbols which are both in
+          libpthread and referenced in libc
+        <youpi> to make sure they have the same version in the reference
+        <braunr> ok
+        <youpi> only weak references need to be checked, others would have
+          produced a runtime error
+        <braunr> youpi: done
+        <braunr> arg, the version i mention in the comment is wrong
+        <braunr> i suppose people understand nonetheless
+        <youpi> probably, yes
+        <braunr> ah, i can now appreciate the headache this bug hunting gave me
+          these last days :)
+
+    IRC, freenode, #hurd, 2013-01-22
+
+        <youpi> braunr: commited to debian glibc
+        <youpi> btw, it's normal that the program doesn't terminate, right?
+        <youpi> (i.e. it's the original bug you were chasing)
+        <braunr> youpi: about your earlier question (yesterday) about my test
+          code, it's expected to block, which is the problem i was initially
+          working on
+        <youpi> ok, so all god
+        <youpi> +o
+
+  * <a id=t_pagesize2>`t/pagesize`</a>
+
+    IRC, freenode, #hurd, 2012-11-16
+
+        <pinotree> tschwinge: somehow related to your t/pagesize branch: due to
+          the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h
+          switches the allocation modes from mmap to malloc
+
+    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].
+
+    IRC, freenode, #hurd, 2013-01-21
+
+        <braunr> why is it a hack ?
+        <pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE
+          like that
+        <braunr> ah
+        <pinotree> there's a mail from roland, replying to thomas about this
+          issue, that this use of EXEC_PAGESIZE to enable mmap or not is just
+          wrong
+        <braunr> ok
+        <pinotree> (the above is
+          http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net )
+        <braunr> thanks
+        <pinotree> (just added the reference to that in the wiki)
+        <braunr> pinotree: btw, what's wrong with using malloc instead of mmap
+          in libio ?
+        <pinotree> braunr: i'm still not totally sure, most probably it should
+          be slightly slower currently
+        <braunr> locking contention ?
+        <braunr> pinotree:
+          http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html
+        <braunr> pinotree: it looks to me there is now no valid reason not to
+          use malloc
+        <braunr> the best argument for mmap is that libio requires zeroed
+          memory, but as the OP says, zeroing a page is usually more expensive
+          than a small calloc (even on kernel that keep a list of zeroed pages
+          for quick allocations, frequent mmaps() often make this list empty)
+        <pinotree> braunr: mmap allocations in libio are rounded to the page
+          size
+        <braunr> well they have to
+
+  * <a id=LD_DEBUG>`LD_DEBUG`</a>
+
+    IRC, freenode, #hurd, 2012-11-22
+
+        <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and
+          then sigsegv
+        <tschwinge> Yeah, that's known for years...  :-D
+        <tschwinge> Probably not too difficult to resolve, though.
+
+  * IRC, OFTC, #debian-hurd, 2013-08-16:
+
+        <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls
+          malloc, boom
+
+  * <a id=conformtest>`conformtest`</a>
+
+    IRC, OFTC, #debian-hurd, 2013-09-22:
+
+        <youpi> btw, I noticed that glibc has a head conformance test which we
+          happily fail quite a bit :)
+        <youpi> it's not so awful, we don't have twice as many failures as
+          linux, but not so far
+        <pinotree> youpi: do you mean "header" for "head", right?
+        <youpi> err, where ? :)
+        <pinotree> <youpi> btw, I noticed that glibc has a head conformance
+          test which we happily fail quite a bit :)
+        <youpi> ah, yes
+        <pinotree> noticed that too
+        <youpi> I had a quick look at the POSIX part, some things are probably
+          not too hard to change (e.g. exposing pthread_kill in signal.h)
+        <youpi> others will by quite hard to fix (short type instead of int
+          type for some flock structure field)
+        <youpi> s/by/be/
+
+  * `truncate`/`ftruncate`
+
+    Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603,
+    glibc still to be done?
+
+    IRC, freenode, #hurd, 2013-10-01:
+
+        <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
+          this one?
+        <pinotree> iirc you constantly get that when building ustr
+        <braunr> is ustr a package ?
+        <pinotree> yes
+        <pinotree> iirc the ustr tests are mostly disk-intensive
+
+    IRC, freenode, #hurd, 2013-10-02:
+
+        <braunr> i've traced the problem up to truncate
+        <braunr> which gets a negative size
+        <braunr> shouldn't take long to find out where it comes from now
+        <pinotree> it seems our truncate doesn't handle negative values well though
+        <braunr>        EINVAL The argument length is negative or larger than the
+          maximum file size.
+        <braunr> i still have to see whether it comes from the user (unlikely) or
+          if it's an internal inconsistency
+        <braunr> i suspect some code wrongly handles vm_map failures
+        <braunr> leading to that inconsistency
+        <braunr> pinotree: looks like glibc doesn't check for length >= 0
+        <pinotree> yeah
+        <braunr> servers should do it nonetheless
+        <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
+        <braunr> it appears a client does the truncate
+        <braunr> i'd say both
+        <braunr> can you take the glibc part ? :)
+        <pinotree> i was going to do the hurd part... :p
+        <pinotree> ok, i'll pick libc
+        <braunr> well i'm doing it already
+        <braunr> i want to write a test case first
+        <braunr> to make sure that's the problem
+        <pinotree> already on the hurd part, you mean?
+        <braunr> yes
+        <pinotree> ok
+        <braunr> ok looks like it
+        <braunr> i can't reproduce the assertion but it does make ext2fs freeze
+        <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c
+        <pinotree> merci
+        <braunr> pinotree: ustr builds
+        <pinotree> wow
+        <braunr> the client code (ustr) seems to perform a ftruncate with size
+          ((size_t)-1) whereas lengths are signed ..
+        <braunr> i'll check other libraries and send a patch soon
+
+    IRC, freenode, #hurd, 2013-10-03:
+
+        <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
+          when truncating files
+        <braunr> this allows building the ustr package without making ext2fs choke
+          on an assertion
+        <braunr> pinotree is preparing a patch for glibc
+        <braunr> see truncate/ftruncate
+        <braunr> with an off_t size parameter, which can be negative
+        <braunr>        EINVAL The argument length is negative or larger than the
+          maximum file size.
+        <braunr> hurd servers were not conforming to that before my change
+
+  * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE`
+
+      * <https://sourceware.org/glibc/wiki/PointerEncryption>
+
+      * See also [[t/tls|t/tls]].
+
+      * b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 `ARM: Add pointer encryption
+        support.` may help to find all the places that need to be touched when
+        adding support.
+
+  * <a id=baselinechanges>Verify baseline changes, if we need any follow-up changes:</a>
+
+      * a11ec63713ea3903c482dc907a108be404191a02
+      * 7e2b0c8562b35155820f87b5ff02a8b6850344cc
+      * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9
+      * 5a2a1d75043138e696222ced4560de2fb90b8024
+      * 5ae958d74180e2572d198bd7872c86f391de6da7
+      * 5b08ac571ff8e94fe96511a532f0d20997de5f52
+      * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26
+      * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf
+      * 63c4ed22b5048c8701d8806026c23cc95f0df756
+      * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c
+      * e35fcef8b739ed24e083ff8a3078ac14e101cf67
+      * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba
+      * 8a492a675e566dc1e666df0a86cbf541442cb179
+      * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef
+      * c86434ccb576a3ce35b5a74f72b9f03bd45b522a
+      * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53
+      * 15bac72bac03faeb3b725b1d208c62160f0c3ad7
+      * c08fb0d7bba4015078406b28d3906ccc5fda9d5a
+      * 10b3bedcb03386cc280113f552479793e4bac35f
+      * 754f7da38b0904b4b989d3500cc8dd5be625cf6a
+      * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d
+      * 962dba7828cf251a9025ccb43bc6effa30379b72
+      * 3162f12e58c3a848db883916843b332b9f8c9d39
+      * 1c06ba3100847da6bd1f2e011dc24fa8debd9615
+      * 84b9230c404aed4fd3a7bb3d045ca367043dde8c
+      * 090555538d4347a52807ba9f08cf20ed13206afe
+      * 817328eea788c746131cf151b64fd250200da333
+      * c3758feebf7c8786231465da664743c6f0ec79cc
+      * 1ac7a2c7b448c851eb8976fcc290a906a4075203
+      * c21cc9bcb38a87ff638d1099ca871d94a2192b31
+      * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde
+      * b8b4863d78bf26b39918fc753b03ed98ef262903
+      * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1
+      * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in
+        `sysdeps/mach/hurd/dl-sysdep.c`
+      * 0e516e0e14f2f9783a21cd1727bc53776341f857
+      * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc
+      * cf7c9078a5acdbb435498ace92cd81009637a971
+      * db753e2cfb2051ebf20dc089f87c5b1297cc2cff
+      * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good.
+      * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b
+      * 451f001b50870604e1f2daef12f04f9f460d3997 +
+        a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484.  `nptl/Versions
+        [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`.  We don't even
+        define it yet.  Also see
+        [[glibc___libc_alloca_cutoff_should_be_lowered]].
+      * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34
+      * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca
+      * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f
+      * 68dc949774cb651d53541df4abdc60327f7e096b
+      * 70181fddf1467996bea393d13294ffe76b8a0853
+      * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca
+      * 32465c3ea007065acd8ca8199f130cdf4068130d
+      * 18ba70a559c52719fd94a713cc380514d9d19125
+      * 620a05296fe3380b7441ba7720e8b25c48a8c28c
+      * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in
+        TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c`
+        hunk?
+      * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 +
+        1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix
+        pathconf(_PC_BUF_SIZE).`
+      * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.`
+      * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 +
+        6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long
+        paths`
+      * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler
+        call in spawn implementation`
+      * 3b85df27870a47ed1db84e948e37a5a50a178a92 +
+        f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf
+      * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid
+        timeouts in emulated pselect`
+      * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`;
+        strndupa?
+      * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative
+        error numbers in strerror_r`.  Change needed for
+        `sysdeps/mach/_strerror.c`?
+      * 7ea72f99966a65a56aedba817ee2413ff9b1f23c +
+        adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer
+        in XPG strerror function`.  Change needed for
+        `sysdeps/mach/xpg-strerror.c`?
+      * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss ([[debugging]],
+        [[profiling]]).  Does it work?
+      * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 +
+        80e2212d8e59933a1641f029ebd360526ff0e074 +
+        4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code
+        used for raise()`.  Also for `bits/siginfo.h`?
+      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work?
+        Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`,
+        `/proc/[PID]/mem` ([[!tag open_issue_hurd]],
+        [[hurd/translator/procfs]]).
+      * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`.
+        Watch what happens.
+      * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`.  Watch
+        what happens.  Native build: apparently OK.
+      * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) +
+        1b74661a6b93a892ecb1c717dedeedba5c2a976c +
+        fd5e21c75d8e9221d766f4bc922a237265514ec2.  Watch what happens.  Native
+        build: `use-default-link = no`.
+      * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`),
+        4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in
+        {,f}pathconf`).  What about stuff like that for us?
+      * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with
+        AC_CHECK_TOOL`).  Aren't there more in other configure.in and Makefile
+        files?
+      * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in
+        cancellation initialization`).  Is this needed in other places, too?
+      * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64
+        bytes`).  Probably we have hidden somewhere such a constant, too (in
+        libpthread).
+      * d96de9634a334af16c0ac711074c15ac1762b23c +
+        ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn*
+        only in compat mode`).  Change looks good, but what about
+        `SPAWN_XFLAGS_TRY_SHELL` for us?
+      * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features
+        mandatory and simplify the code.`).  Generally looks good.
+          * `locale/global-locale.c`: Apparently, no one is using
+            `_HURD_THREADVAR_LOCALE`.  But it is exported via
+            `hurd/threadvar.h`.
+          * `mach/devstream.c`: reversed.  Fixed in
+            `t/repair-mach_devstream.c`.
+          * `malloc/arena.c`: should be OK.
+      * `Remove support for !USE___THREAD`.
+        d063d164335938d557460bebaa7cfe388157b627 (generally looks good;
+        `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) +
+        (de82006d43e198fd162807c9adc720c7ebd728a3 +
+        037e9fe21c92216ef7032ea2796781ec27ca182a) +
+        995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) +
+        bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok).
+      * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all
+        kinds of unused configuration options and dead code.`).  `NO_STARTER`
+        changes (should be OK).
+      * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify
+        malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237,
+        [[!sourceware_PR 11929]].  Is this all kosher for us?  See
+        [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].
+      * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls
+        option, TLS support is required`).
+      * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in
+        __cmsg_nxthdr`).  Probably just a C++ thing and not relevant for us;
+        see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]].
+      * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7.  Kosher with
+        respect to our [[glibc/mmap]] peculiarities?
+      * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`,
+        aa78043a4aafe5db1a1a76d544a833b63b4c5f5c +
+        49a43d80ec5c97cf6136b1ee2687414773b2d5aa +
+        3871f58f065dac3917eb18220a479e9591769c8c +
+        9beb2334930db81ceada5aa6051fe5ac0554db32 +
+        0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 +
+        edc5984d4d18296d7aa3d8f4ed8f7336a743170e +
+        57769839788e2c62b68d9dfbf4b35052321278ba.
+        <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>.
+      * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 +
+        4efeffc1d583597e4f52985b9747269e47b754e2 +
+        d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror
+        `bits/siginfo.h` changes.
+      * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe,
+        [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for
+        us?
+      * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 --
+        probably should do similar changes, also to the generic file.
+      * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id
+        "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]]
+        02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same
+        for the generic version as used by GNU Hurd.
+      * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4,
+        [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what
+        about other architectures?
+      * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to
+        adapt for (conditional?) Sun RPC reversion (if that was the original
+        cause for the patch)?
+      * [low] `Add __fsword_t and use it in bits/statfs.h`,
+        3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id
+        "20120517134700.GA19046@intel.com"]] -- only updates one copy of
+        `bits/statfs.h`; update the others, too, for consistency.
+      * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove
+        `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`?
+      * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4,
+        b80af2f40631871cf53a5e39d08d5d5516473b96,
+        04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK?
+      * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement
+        POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit
+        using that one (with `sysdeps/mach/nanosleep.c`) instead of
+        `sysdeps/mach/sleep.c`?
+      * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd,
+        2012-11-20, pinotree: »tschwinge: i agree on your comments on
+        ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's
+        sleep.c is buggy (not considers interruption, extra time() (= RPC)
+        call)«.
+      * ba384f6ed9275f3966505f2375b56d169e3dc588,
+        0409959c86f6840510851a851a1588677a2e537b,
+        e57b0c6100e63bfd816ae59339452eafc81f1d3a `C++11 thread_local
+        destructors support`.  Anything needed to be done in our [[libpthread]]
+        and configured for us in [[GCC]]?  Probably need to replicate the
+        `nptl/pthread_create.c` change, and fix
+        `stdlib/Makefile`:`$(objpfx)tst-tls-atexit`.
+
+            +++ include/link.h
+            @@ -302,6 +302,9 @@ struct link_map
+            +    /* Number of thread_local objects constructed by this DSO.  */
+            +    size_t l_tls_dtor_count;
+            
+            +++ include/stdlib.h
+            @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d);
+            +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg,
+            +                                    void *d);
+            +extern void __call_tls_dtors (void);
+            +libc_hidden_proto (__call_tls_dtors);
+            
+            +++ nptl/pthread_create.c
+            @@ -311,6 +311,9 @@ start_thread (void *arg)
+             [after the thread function returns]
+            +  /* Call destructors for the thread_local TLS variables.  */
+            +  __call_tls_dtors ();
+            
+            +++ stdlib/Makefile
+            +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \
+            +                        $(common-objpfx)dlfcn/libdl.so
+            
+            +++ stdlib/cxa_thread_atexit_impl.c
+            
+            +++ stdlib/exit.c
+             __run_exit_handlers (int status, struct exit_function_list **listp,
+                                 bool run_list_atexit)
+             {
+            +  /* First, call the TLS destructors.  */
+            +  __call_tls_dtors ();
+
+            +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth
+            +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit   [...]/tschwinge/Roger_Whittaker.build/nptl/lib
+            +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory
+            +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1
+            +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par
+            +tst-tls-atexit-lib.c: In function 'do_foo':
+            +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration]
+      * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX
+        libc_fatal code.` -- is `backtrace_and_maps` specific to Linux?
+
+        IRC, freenode, #hurd, 2014-02-06:
+
+            <braunr> why wouldn't glibc double free detection code also print
+              the backtrace on hurd ?
+            <youpi> I don't see any reason why
+            <youpi> except missing telling glibc that it's essentially like on
+              linux
+
+      * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if
+        available, as fallback for AT_PHDR.` -- once we require Binutils 2.23,
+        can we simplify [[glibc's process startup|glibc/process]]
+        (initialization of `_dl_phdr` and `_dl_phnum`)?  As these are only used
+        for `[!SHARED]`, can we completely remove them (that is, the `phdr` and
+        `phdrsz` members) from `hurd_startup_data`, and simplify
+        [[hurd/interface/exec_startup_get_info]], or do we still require these
+        for the `[SHARED]` case?
+      * fab7ce3f5b4060bf62659e8b58529de4156b5a2f `Link extra-libs consistently
+        with libc and ld.so.`  Alright for us?  Probably have to adjust
+        [libpthread]/Makefile.
+      * b8c61b4b1d6afb69190169764c1b141f4659e48b `Remove trailing whitespace
+        from mach/*.sub.`  Update `mach/Makefile`: generated
+        `mach/errsystems.c` is no longer checked in as of
+        66e3dda448406399136e6f144a1b46679d5b2613.  Rule had been disabled in
+        421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in
+        8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed.
+      * [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 `New API to set default
+        thread attributes`.  Implement in libpthread ([[!taglink
+        open_issue_libpthread]])?
+      * [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 `CVE-2013-2207, BZ
+        #15755: Disable pt_chown. -- [[!message-id
+        "51E8D4C1.9000705@redhat.com"]]; do we need it (`--enable-pt_chown`)?
+	cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0.
+      * 91ce40854d0b7f865cf5024ef95a8026b76096f3 `CVE-2013-4237, BZ #14699:
+        Buffer overflow in readdir_r` -- [[!message-id
+        "519220C7.6050705@redhat.com"]]; do we need corresponding changes to
+        Hurd sysdep files?
+      * 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee `Flesh out 4.4 bits/socket.h
+        with SOCK_CLOEXEC, SOCK_NONBLOCK.`,
+        e041fb8b6557882b6710a655a97bbf3541b56b54 `Replace generic bits/socket.h
+        with 4.4 file.` -- `sysdeps/mach/hurd/bits/socket.h` differs from the
+        generic `bits/socket.h` now only in the values of
+        [[`SOCK_CLOEXEC`|secure_file_descriptor_handling]] and
+        `SOCK_NONBLOCK`.  If possible (no conflicts), would it make sense to
+        transition to the latter file, continuing to accept the former values
+        as deprecated for some time?
+      * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler
+        optimization` -- have to revert, see [[!sourceware_PR 15605]].  For
+        analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49.
+      * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions
+        for Linux and glibc` -- alright for us?
+      * c61b4d41c9647a54a329aa021341c0eb032b793e `POINTER_CHK_GUARD` -- see
+        [[t/tls|t/tls]].
+      * 5f855e3598a576c35e54623a13b256f3e87fcd4d `Fix erroneous (and circular)
+        implied pattern rule for linkobj/libc.so.` -- alright for us?
+      * [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] `Add fork hooks
+        for pthread_atfork` -- is that from a topic branch that can then be
+        annihilated?  Verify emails.  Verify no further changes in topic
+        branch.
+      * [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd `Fix build on hurd` --
+        is that from a topic branch that can then be annihilated?  Verify
+        emails.  Verify no further changes in topic branch.
+      * 69a17d9d245dc3551792e95e1823cc2d877592f3 `Patch [1/4] async-signal safe
+        TLS.` -- do we also need an implementation of this?  (Not yet called
+        from anywhere?)
+      * *baseline*
+
+
+## Update
+
+`baseline`, `t/regenerate_configure` (could now be removed),
+`t/master_backports`, `t/eglibc_backports`, `t/host-independency`,
+`tschwinge/Roger_Whittaker`
+
+
+# Build
+
+Here's a log of a glibc build run; this is from our [[Git repository's
+f57644d0bdfc1ebe2201a677a33af27e09a5bab6 (2013-12-20;
+64a17f1adde4715bb6607f64decd73b2df9e6852 (2013-12-19))
+plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted,
+`id:"87zjnvn688.fsf@kepler.schwinge.homeip.net"`,
+`id:"87ioujn0eq.fsf@kepler.schwinge.homeip.net"`,
+1226676cd6f6f4451e6e6b75b8fbd9a35c949e8e reverted,
+56798c444bc584c118b69a3506c4050b34edc35f reverted,
+`id:"878uvfmwvs.fsf@kepler.schwinge.homeip.net"`
+sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
+
+    $ export LC_ALL=C
+    $ ../Roger_Whittaker/configure --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build
+    [...]
+    $ make install_root=/INVALID 2>&1 | tee log_build_
+    [...]
+
+This takes up around 600 MiB, and needs roughly X min on kepler.SCHWINGE and
+105 min on coulomb.SCHWINGE.
+
+<!--
+
+    $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
+
+-->
+
+
+## Analysis
+
+    $ toolchain/logs/process glibc build fetch coulomb.SCHWINGE
+
+TODO.
+
+  * baseline
+    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
+    (or probably Samuel's mmap backport) introduces:
+
+        ../sysdeps/mach/hurd/mmap.c: In function '__mmap':
+        ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default]
+        ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default]
+        ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default]
+        ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default]
+
+  * baseline
+    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
+    introduces:
+
+        nscd_gethst_r.c: In function '__nscd_get_nl_timestamp':
+        nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration]
+
+    This was already present before:
+
+        nscd_gethst_r.c: In function 'nscd_gethst_r':
+        nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
+
+  * baseline
+    2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032
+    introduces:
+
+        tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
+
+  * baseline
+    fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a
+    introduces
+
+        +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.
+        +tst-printf-round.c: In function 'do_test':
+        +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+        +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+        +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+        +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+
+         gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
+        +In file included from test-wcschr.c:2:0:
+        +../string/test-strchr.c: In function 'check1':
+        +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default]
+        +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *'
+        +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default]
+        +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default]
+        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
+        +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default]
+        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
+
+
+# Install
+
+TODO.
+
+    $ make install_root="$PWD".install install 2>&1 | tee log_install
+    [...]
+
+This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16
+min on coulomb.SCHWINGE.
+
+
+## Analysis
+
+    $ toolchain/logs/process glibc install fetch coulomb.SCHWINGE
+
+TODO.
+
+
+# Testsuite
+
+    $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
+    [...]
+
+This needs roughly X min on kepler.SCHWINGE and 130 min on coulomb.SCHWINGE.
+
+Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out
+of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't
+our most critical issue to solve.
+`elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run.
+
+
+## Analysis
+
+    $ toolchain/logs/process glibc test fetch coulomb.SCHWINGE
+
+Failures, mostly in order of appearance:
+
+  * `check-abi`, `check-abi-libmachuser`, `check-abi-libhurduser`,
+    `check-abi-libBrokenLocale`, `check-abi-libm`, `check-abi-libdl`,
+    `check-abi-libcrypt`, `check-abi-libresolv`, `check-abi-librt`,
+    `check-abi-libnsl`, `check-abi-libutil`, `check-abi-libc`, `check-abi-ld`,
+    `c++-types.data`
+
+    Reference files are missing.
+
+  * `math/test-float.out`, `math/test-double.out`
+
+    A handful of ULP failures.
+
+  * `math/test-ldouble`, `math/test-ildoubl`, `math/test-ifloat`,
+    `math/test-idouble`
+
+    SIGSEGV.  Or SIGILL.
+
+  * `stdlib/tst-secure-getenv.out`
+
+        open (/proc/self/exe): No such file or directory
+
+    Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]].
+
+  * `stdlib/tst-strtod-round.out`
+
+        strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
+        strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
+
+  * `stdio-common/bug22.out`
+
+        Timed out: killed the child process
+
+    Known problem.
+
+  * `libio/tst-atime.out`, `dirent/tst-fdopendir.out`
+
+    [[!message-id "201305102256.56636.toscano.pino@tiscali.it"]].
+
+    `libio/tst-atime.out`:
+
+        atime has not changed
+
+    Due to `ext2fs --no-atime`.
+
+      * IRC, OFTC, #debian-hurd, 2013-05-08
+
+            <youpi> bah, tst-atime failure :)
+            <pinotree> do you have its output?
+            <youpi> well it's very simple
+            <youpi> I have the noatime option on / :)
+            <pinotree> oh
+            <youpi> fortunately fsysopts works :)
+            <pinotree> the test checks whether ST_NOATIME is in the mount
+              options, maybe it would be a good idea to provide it
+            <youpi> yes
+            <pinotree> unfortunately it isn't in posix, so i'm not sure whether
+              adding it to the general bits/statvfs.h would be welcome
+            <pinotree> or whether we should fork it, like it is done for linux 
+            <pinotree> oh no, we fork it already
+            <pinotree> \o/
+
+    `dirent/tst-fdopendir.out`:
+
+        directory atime changed
+
+    Due to `ext2fs --atime` (default).
+
+  * `libio/tst-fopenloc.check`, `posix/bug-regex31-mem`,
+    `posix/tst-fnmatch-mem`, `misc/tst-error1-mem`
+
+        Memory not freed:
+        -----------------
+           Address     Size     Caller
+        0x0807e268   0x8000  at 0x10c71c4
+
+    Caused by different memory allocation way in libio, see
+    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]
+
+  * `dlfcn/bug-atexit3.out`
+
+    Originally:
+
+        dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory
+
+    See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]].
+    Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6
+    /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`.
+    This is a bug in the glibc test harness.  Should probably use some
+    `configure` magic akin to the `fixincludes` stuff (`gcc-4.4
+    -print-file-name=libstdc++.so.6`, etc.).
+
+    Even if that that is being worked around, the tests nowadays
+    ([[packaging_libpthread]]) fail with:
+
+        dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
+
+  * `dlfcn/tststatic.out`, `dlfcn/tststatic2.out`, `dlfcn/tststatic3.out`,
+    `dlfcn/tststatic4.out`, `dlfcn/tststatic5.out`
+
+    SIGSEGV.
+
+    `LD_LIBRARY_PATH` doesn't contain the `mach` and `hurd` directories; yet
+    the test shouldn't just SIGSEGV.
+
+  * `dirent/opendir-tst1.out`, `dirent/tst-fdopendir2.out`
+
+    `dirent/opendir-tst1.out`:
+
+        `opendir' succeeded on a FIFO???
+
+    `dirent/tst-fdopendir2.out`:
+
+        fdopendir with normal file descriptor did not fail
+
+    `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a
+    directory.
+
+  * `posix/tst-waitid.out`
+
+    Intermittent.
+
+        SIGCHLD for stopped status 0
+        SIGCHLD for stopped pid -1
+        SIGCHLD for killed code 1
+        SIGCHLD for killed status 0
+        SIGCHLD for killed pid -1
+
+  * `posix/bug-glob2.out`
+
+    Intermittent.
+
+        Timed out: killed the child process
+
+  * `posix/annexc.out`
+
+    Failure ignored by the glibc testsuite.
+
+  * `posix/tst-getconf.out`
+
+    Ends with:
+
+        getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument
+
+    It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`,
+    `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`,
+    `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`.
+
+    `_CS_GNU_LIBPTHREAD_VERSION` is provided by libpthread when compiled as
+    add-on.
+
+  * `posix/tst-vfork3-mem`
+
+        + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+        + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+        + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+        - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc
+        - 0x0804c960 Free 87 was never alloc'd 0x115672f
+        - 0x0804c9b8 Free 88 was never alloc'd 0x1156737
+        
+        Memory not freed:
+        -----------------
+           Address     Size     Caller
+        0x0804cfa8     0x73  at 0x10df0c8
+        0x00000008        0  at 0x10df0c8
+
+    Perhps because we implement `vfork` in terms of `fork` (`posix/vfork.c`)?
+
+  * `posix/tst-pathconf.out`
+
+        pathconf on directory failed: (os/kern) successful
+
+  * `io/test-lfs.out`
+
+        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument
+
+  * `io/tst-futimesat.out`
+
+        file created
+        futimesat failed
+
+    `futimesat` is a stub.
+
+  * `misc/tst-pselect.o`
+
+        tst-pselect.c: In function 'do_test':
+        tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function)
+
+  * `gmon/tst-sprofil.out`
+
+        Floating point exception
+
+  * `nss//libnss_test1.so`
+
+        [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r':
+        [...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock'
+        [...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock'
+
+  * `rt/tst-shm.out`
+
+        read file outside of SHMDIR directory: (os/kern) successful
+
+  * `rt/tst-timer.out`
+
+    No message.
+
+  * `rt/tst-timer2.o`
+
+        tst-timer2.c: In function 'do_test':
+        tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function)
+
+  * `rt/tst-aio2`, `rt/tst-aio3`, `rt/tst-aio9`, `rt/tst-aio10`,
+    `rt/tst-mqueue3`, `rt/tst-mqueue5.o`, `rt/tst-mqueue6`, `rt/tst-mqueue8`,
+    `rt/tst-timer3`, `rt/tst-timer4.o`, `rt/tst-timer5.o`,
+    `rt/tst-cputimer1.o`, `rt/tst-cputimer2.o`, `rt/tst-cputimer3.o`,
+    `elf/tst-thrlock`
+
+        [...]/rt/tst-aio2.o: In function `do_test':
+        [...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init'
+        [...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait'
+        [...]/rt/tst-aio2.o: In function `thrfct':
+        [...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait'
+
+        tst-mqueue5.c: In function 'rtmin_handler':
+        tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function)
+
+        [...]/rt/tst-mqueue6.o: In function `do_test':
+        [...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init'
+        [...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize'
+        [...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize'
+        [...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy'
+        [...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize'
+        [...]/rt/tst-mqueue6.o: In function `fct':
+        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self'
+        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np'
+        [...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize'
+        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
+        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
+
+        [...]/elf/tst-thrlock.o: In function `do_test':
+        [...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create'
+        [...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join'
+
+  * `rt/tst-aio8.out`
+
+        r = -1, e = 1073741902 (Function not implemented)
+
+    Should work with [[!message-id
+    "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread.
+
+  * `debug/tst-chk1.out`
+
+    Intermittent.  Timeout.  Unknown.
+
+  * `debug/tst-chk2.out`, `debug/tst-chk3.out`, `debug/tst-lfschk2.out`,
+    `debug/tst-lfschk3.out`
+
+    Unknown.
+
+  * `debug/tst-chk4.out`, `debug/tst-chk5.out`, `debug/tst-chk6.out`,
+    `debug/tst-lfschk4.out`, `debug/tst-lfschk5.out`, `debug/tst-lfschk6.out`
+
+        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
+        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1)
+
+  * `debug/tst-longjmp_chk2.out`
+
+    SIGSEGV.
+
+        not on alternate stack
+         in signal handler
+         on alternate stack
+         out of signal handler
+         on alternate stack
+
+    It says *alternate stack*.
+
+  * `inet/tst-ether_line.o`
+
+        tst-ether_line.c: In function 'do_test':
+        tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function)
+
+    Will either need a `hurd/netinet/if_ether.h` that includes
+    `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`?
+    See also [[!sourceware_PR 11142]].
+
+  * `login/tst-grantpt.out`
+
+        posix_openpt(O_RDWR) failed
+        errno 1073741902 (Function not implemented)
+
+    `posix_openpt` is a stub.
+
+        grantpt(): expected: return = -1, errno = 1073741846
+                   got: return = -1, errno = -303
+
+    `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd`
+    does not refer to a PTY master.
+
+  * `elf/tst-auxv.out`
+
+    SIGSEGV.
+
+  * `elf/tst-stackguard1-static.out`, `elf/tst-stackguard1.out`
+
+        differences 0 defaults 0
+        stack guard canaries are not randomized enough
+        nor equal to the default canary value
+
+    Sometimes times out.
+
+  * `elf/tst-ptrguard1-static.o`, `elf/tst-ptrguard1.o`
+
+        In file included from tst-ptrguard1-static.c:1:0:
+        tst-ptrguard1.c: In function 'con':
+        tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard'
+        tst-ptrguard1.c: In function 'do_test':
+        tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard'
+        tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard'
+
+    See [[t/tls|t/tls]].
+
+  * `elf/tst-tls9-static.out`
+
+    SIGSEGV.
+
+  * `elf/tst-dlmopen1.out`
+
+    SIGSEGV.
+
+  * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out`
+
+    SIGKILL.
+
+  * `elf/tst-null-argv.out`
+
+        Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed!
+
+  * `elf/check-textrel.out`
+
+        $BUILDDIR/libc.so.dyn: *** text relocations used
+
+  * `elf/check-execstack.out`
+
+        $BUILDDIR/libc.so.phdr: *** executable stack signaled
+
+  * `elf/check-localplt.out`
+
+    Around 500 or so `Extra PLT reference`.
+
+  * `check-local-headers.out`
+
+    A lot.  Including `/usr/include/device/*.h`, `/usr/include/mach/*.h`,
+    `/usr/include/hurd/*.h`.
+
+  * `debug/tst-longjmp_chk2.out`, `debug/tst-longjmp_chk3.out`,
+    `debug/tst-longjmp_chk4.out`, `debug/tst-longjmp_chk5.out`,
+    `debug/tst-backtrace2.out`, `debug/tst-backtrace3.out`,
+    `debug/tst-backtrace4.out`, `debug/tst-backtrace5.out`
+    `debug/tst-backtrace6.out`
+
+    All say: `Obtained backtrace with 0 functions`.
+
+Earlier failures; no longer seen:
+
+  * `test-assert-perr.out`
+
+    Fails intermittently.  Unknown.
+
+  * `test-multiarch.out`
+
+    Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]]
+    providing the `flags` line.
+
+  * `elf/tst-array*`
+
+    No longer fail with GCC 4.7.
+    [[!message-id "50950082.1070906@df1tl.local.here"]].
+
+  * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`,
+    `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`,
+    `grp/tst_fgetgrent`,
+    `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf`
+
+        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory
+
+    Looking into `localedata/bug-setlocale1.c`, it is clear what it going on:
+    only the root of the build directory is added for `--library-path`, but
+    none of the other directories that are additionally used.  This is a bug in
+    the glibc test harness.  Hacked around by `ln -s mach/libmachuser.so.1
+    hurd/libhurduser.so.0.3 ./`.  Hopefully the other instances are similar.
+
+  * `assert/test-assert.out`
+
+    Fails sometimes...
+
+  * `math/test-fenv.out`
+
+    Used to fail (is listed in Debian eglibc-2.13-21's
+    `expected-results-i486-gnu-libc`), but something between
+    22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and
+    005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely
+    Jérémie's signaling work.
+
+  * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d,
+    [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]])
+
+        Unused direct dependencies:
+                /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2
+
+    As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes --
+    correct?
+
+  * `stdlib/bug-getcontext.out`
+
+        getcontext failed, errno: 1073741902.
+
+    Fixed, implemented in `t/context_functions`.
+
+  * `resource/bug-ulimit1.out`
+
+        Result of ulimit (UL_SETFSIZE, 10000): 0
+        Result of ulimit(UL_GETFSIZE): 10000
+
+    Buggy `sysdeps/unix/bsd/ulimit.c` return values.
+
+    Fixed, [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]].
+
+Compared to Debian:
+
+    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test  > log_test.filtered
+    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered