rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

6 files changed, 0 insertions, 847 deletions

diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
deleted file mode 100644
index 2ef2c474..00000000
--- a/open_issues/glibc/debian.mdwn
+++ /dev/null
@@ -1,168 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-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]]."]]"""]]
-
-
-# Open Issues
-
-`threads = yes` is set in `debian/sysdeps/linux.mk` and
-`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`.  But this
-is only read in `debian/rules` for deciding some `nscd` package issue?
-
-`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC
-configuration.
-
-Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip
-locale stuff.
-
-`--disable-compatible-utmp`?
-
-
-## IRC, freenode, #hurd, 2013-08-28
-
-    <youpi> uh, the i686 profiles have much more progression than i386
-    <youpi> it seems they don't actually run these
-    <pinotree> youpi: what do you mean with "we don't run those"?
-    <pinotree> iirc there are three build profiles done, but there are 4
-      regression test files
-    <youpi> yes, but some failing tests are not run in the three build profiles
-    <youpi> even if they are built for all of them
-    <pinotree> not even run? which ones?
-    <youpi> see for instance test-ifloat.out
-    <youpi> test-ifloat is built in all profiles, but only run in the libc one
-    <pinotree> don't have a glibc built tree around atm, sorry :/
-    <youpi> perhaps because glibc thinks it's not useful to run it again if it
-      fails on i386
-    <youpi> you can check the logs
-    <pinotree> do you think glibc's build system is that smart? :)
-    <pinotree> all the builds are done in separate builddirs, so theorically
-      they should not touch each other...
-    <youpi> yes
-    <youpi> that's why I'm surprised
-    <pinotree> could it be they get not run in optimized/particular builds?
-    <pinotree> what about linux/kfreebsd i386?
-    <youpi> I don't see what  makes them not run
-    <youpi> or at least be treated particularly by th eMakefile
-    <youpi> not run on kfreebsd either
-    <youpi> pinotree: also, most of the tests now working have been marked as
-      failing by your patches for 2.17, would it be possible to retry them on
-      the box you used at that time?
-    <pinotree> that's the vm on my machine
-    <youpi> which kind of vm?
-    <youpi> kvm?
-    <pinotree> y
-    <youpi> they are working here
-    <youpi> with kvm
-
-
-# Building
-
-Run `debian/rules patch` to apply patches (instead of having it done during the
-build).  Then you can edit files manually.
-
-Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc.
-
-If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the
-`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will
-fail.  (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for
-example.)  Why is this special handling only done for `xen`, but not for
-`i686`?
-
-> Samuel: Historically because it's done that way in linux-i386. I don't know
-> the real reason.
-
-Do `export LC_ALL=C` before building, otherwise the testsuite/make error
-messages will be different from those stored in the
-`debian/testsuite-checking/expected-results-*` files, resulting in a spurious
-build failure.
-
-Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`
-to build (or `build` instead of `build-arch` to build the arch-independent
-stuff, too).  Can interrupt with `C-c` during locale stuff or testsuite if only
-interested in the build tree.
-
-Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2
-[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the
-architecture-dependent ones.
-
-The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules
-EGLIBC_PASSES=libc' -nc -b -uc`.  `-nc` will prevent the *clean step* which
-would first try to un-patch, which may conflict if you have done any edits
-apter applying patches.
-
-If the Debian symbol versioning file is not up to date and the build of Debian
-packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the
-environment \`\`helps''; see `man dpkg-gensymbols`.
-
-
-# IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> something seems to have changed with regard to patch handling in
-      eglibc 2.17
-    <braunr> pinotree: when i add a patch to series and use dpkg-buildpackage,
-      i'm told there are local modifications and the build stops :/
-    <braunr> any idea what i'm doing wrong ?
-    <pinotree> which steps do you do?
-    <braunr> i extract the sources, copy the patch to debian/patches/hurd-i386,
-      add the appropriate line to debian/patches/series, call dch -i, then
-      dpkg-buildpackage
-    <pinotree> eglibc is a "3.0 (quilt)" format source package
-    <pinotree> this means its default patches are in a quilt-style system, and
-      they are applied on extraction
-    <braunr> ok
-    <braunr> and it can't detect new patches ?
-    <pinotree> so if you add a new patch to the global serie, you have to push
-      it manually
-    <braunr> i have to revert them all ?
-    <braunr> ok
-    <braunr> how do i do that ?
-    <pinotree> quilt push -a
-    <braunr> ok
-    <braunr> thanks
-    <pinotree> remember to do that before starting the build, since the rest
-      assumes the quilt-style patches are fully applied
-    <bddebian> No push applies them, quilt pop -a reverts them
-    <pinotree> yeah, and he has to push the new over the dpkg-applied ones
-    <bddebian> Oh, aye
-    <braunr> does quilt change series ?
-    <pinotree> no
-    <braunr> ok
-    <pinotree> i mean, some commands do that
-    <braunr> so i do everything i did, with an additional push, right ?
-    <pinotree> ok, screw me, i didn't get your question above :P
-    <braunr> does that change your answer ?
-    <pinotree> <braunr> does quilt change series ?
-    <braunr> yes
-    <pinotree> if you import or create a new patch, it changes series indeed
-    <braunr> ok
-    <pinotree> push or pop of patches does not
-    <braunr> i'm doing it wron
-    <braunr> g
-    <pinotree> btw, in a quilt patch stack you can easily import a new patch
-      using the import command
-    <pinotree> so for example you could do
-    <pinotree> apt-get source eglibc # or get it somehow else
-    <pinotree> cd eglibc-*
-    <pinotree> quilt import /location/of/my/patch
-    <pinotree> quilt push # now your patch is applied
-    <braunr> ah thanks
-    <pinotree> dpkg-buildpackage as usual
-    <braunr> that's what i was looking for
-    <bddebian> quilt new adds a new entry in series
-    <pinotree> y
-    <bddebian> or import, aye
-    <pinotree> braunr: if you want to learn quilt, a very good doc is its own,
-      eg /usr/share/doc/quilt/quilt.txt.gz
-    * bddebian has never actually used import
-    <braunr> ok
-    <pinotree> it is basically a simple stack of patches
-
-    <youpi> braunr: yes, patch handling is a bit different
-    <youpi> the arch-independant patches are applied by dpkg-source -x
-    <youpi> and the arch-dependent patches are applied during build
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
deleted file mode 100644
index 4ae9807b..00000000
--- a/open_issues/glibc/debian/experimental.mdwn
+++ /dev/null
@@ -1,338 +0,0 @@
-[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-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]]
-
-Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
-Now in unstable.
-
-
-# IRC, OFTC, #debian-hurd, 2013-03-14
-
-    <markus_w1nner> I have a strange tcp via localhost question:
-    <markus_wanner> The other side closes the connection, but I haven't read
-      all data, yet. I should still be able to read the pending data, no?
-    <markus_wanner> At least it seems to work that way on Linux, but not on
-      Hurd.
-    <markus_wanner> Got a simple repro with nc, if you're interested...
-    <youpi> markus_wanner: yes, we're interested
-    <markus_wanner> youpi: okay, here we go:
-    <markus_wanner> session 1: nc -l -p 7777 localhost
-    <markus_wanner> session 2: nc 127.0.0.1 7777
-    <markus_wanner> session 2: a <RET> b <RET> c <RET>
-    <markus_wanner> session 1: [ pause with Ctrl-Z ]
-    <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET>
-    <markus_wanner> session 2: [ quit with Ctrl-C ]
-    <markus_wanner> session 1: [ resume with 'fg' ]
-    <markus_wanner> The server on session 1 doesn't get the data sent after it
-      paused and before the client closed the connection.
-    <markus_wanner> I'm not sure if that's a valid TCP thing. However, on
-      Linux, the server still gets the data. On hurd it doesn't.
-    <markus_wanner> I'm working on a C-code test case, ATM.
-    <youpi> markus_wanner: on which box are you seeing this behavior?
-    <youpi> exodar does not have it
-    <youpi> i.e. I do get the d e f
-    <markus_wanner> a private VM (I'm not a DD)
-    <markus_wanner> ..updated to latest experimental stuff.
-    <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU
-    <youpi> ok, I can't reproduce it on my vm either
-    <youpi> maybe the C program will help
-    <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still
-      shows the issue, though).
-    <markus_wanner> I'll try to strace netcat...
-    <markus_wanner> ..Meh. strace not available on Hurd?
-    <pinotree> no, but there is rpctrace to show the various rpc
-    <markus_wanner> Cool, looks helpful.
-    <markus_wanner> Thx
-    <markus_wanner> Uh.. that introduces another error:
-    <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward:
-      Assertion `reply_type == 18' failed.
-
-[[hurd/debugging/rpctrace]].
-
-    <youpi> I'm checking on a box without ipv6 configuration
-    <youpi> maybe that's the difference between you and me
-    <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ?
-    <markus_wanner> Yup, nc.traditional.
-    <markus_wanner> Looks like that box only has IPv4 configured.
-    <markus_wanner> Something very strange is going on here. No matter how hard
-      I try, I cannot reproduce this with netcat, anymore.
-    <pinotree> not even after a reboot?
-    <markus_wanner> Woo.. here, it happened, again! This is driving me crazy!
-    <markus_wanner> Now, nc seemingly connects, but is unable to send data
-      between the two. Netcat would somehow complain, if it failed to connect,
-      no?
-    <markus_wanner> No it worked.
-    <markus_wanner> So this seems to be an intermittent issue. So far, I could
-      only ever repro it as a normal user, not as root. May be coincidental,
-      though.
-    <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent
-      manually just after that. Something with that TCP/IP stack is definitely
-      fishy.
-    <markus_wanner> Anything I can try to investigate? Or shall I simply
-      restart and see if the problem persists?
-    <youpi> maybe restart, yes
-    <youpi> did you restart since the upgrade ?
-    <markus_wanner> Yes, I restarted after that.
-    <markus_wanner> Hm.. okay, restarted. Some problem persists.
-    <markus_wanner> I currently have two netcat processes connected, the
-      listening one got some first two messages and seems stuck now.
-    <markus_wanner> With the client, I tried to send more data, but the server
-      doesn't get it, anymore.
-    <markus_wanner> Any idea on what I can do to analyze the situation?
-    <youpi> for the netcat issue, I haven't experienced this
-    <youpi> are you running in kvm or virtualbox or something else?
-    <markus_wanner> I'm currently puzzled about what "experimental" actually
-      ships.
-    <markus_wanner> On kvm.
-    <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3.
-    <markus_wanner> But packages.d.o already shows 2.17.0experimental2.
-    <youpi> experimental ships experimental versions, which you aren't supposed
-      to use
-    <youpi> unless you know what you are doing
-    <youpi> iirc 2.17 is known to be quite broken for now
-    <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then.
-    <markus_wanner> Phew, okay, successfully downgraded to unstable.
-    <markus_wanner> Hopefully monotone's test suite runs through fine, now.
-    <markus_wanner> Yup, WORKING! Looks like some experimental packages caused
-      the problem. The netcat test as well as that one failing monotone test
-      work fine, now.
-
-
-## IRC, OFTC, #debian-hurd, 2013-03-19
-
-    <tschwinge> pinotree, youpi: Is there anything from that markus_wanner
-      discussion about pfinet/netcat/signals that needs to be filed?  I guess
-      we don't know what exactly he changed so that everything workedd fine
-      eventually?  (Some experimental package(s), but which?)
-    <youpi> that was libc0.3 packages
-    <youpi> which are indeed known to break the network
-
-
-# IRC, freenode, #hurd, 2013-06-18
-
-    <braunr> root@darnassus:~# dpkg-reconfigure locales
-    <braunr> Generating locales (this might take a
-      while)... en_US.UTF-8...Segmentation fault
-    <braunr> is it known ?
-    <youpi> uh, no
-
-
-## IRC, OFTC, #debian-hurd, 2013-06-19
-
-    <pinotree> btw i saw too the segmentation fault when generating locales
-
-
-## IRC, freenode, #hurd, 2014-02-04
-
-    <bu^> hello
-    <bu^> I just updated
-    <bu^> Setting up locales (2.17-98~0) ...
-    <bu^> Generating locales (this might take a while)...
-    <bu^>   en_US.UTF-8...Segmentation fault
-    <bu^>  done
-    <gnu_srs> bu^: That's known, it still seems to work, though. If you have
-      the time please debug. I've tried but not found the solution yet:-(
-    <bu^> ok, just wanted to notify
-
-
-## IRC, freenode, #hurd, 2014-02-19
-
-    <braunr> for info, the localedef segfault has been fixed upstream
-    <braunr> or rather, upstream has been written in a way that won't trigger
-      the segfault
-    <braunr> it is caused by the locale archive code that maps the locale
-      archive file in the address space, enlarging the mapping as needed, but
-      unmaps the complete reserved size of 512M on close
-    <braunr> munmap is implemented through vm_deallocate, but it looks like the
-      latter doesn't allow deallocating unmapped regions of the address space
-    <braunr> (to be confirmed)
-    <braunr> upstream code tracks the mapping size so vm_deallocate won't whine
-    <braunr> i expect we'll have that in eglibc 2.18
-    <braunr> hm actually, posix says munmap must refer to memory obtained with
-      mmap :)
-    <braunr> (or actually, that the behaviour is undefined, which most unix
-      systems allow anyway, but not us)
-
-    <braunr> also, before i leave, i have partially traced the localedef
-      segfault
-    <youpi> ah, cool
-    <braunr> localedef maps the locale archive, and enlarges the mapping as
-      needed
-    <braunr> but munmaps the complete 512m reserved area
-    <braunr> and i strongly suspect it unmaps something it shouldn't on the
-      hurd
-    <braunr> since linux mmap has different boundaries depending on the mapping
-      use
-    <braunr> while our glibc will happily maps stacks below text
-    <braunr> the good news is that it looks fixed upstream
-    <youpi> ah :)
-    <braunr>
-      https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6
-    <braunr> see the change about close_archive
-    <braunr> i haven't tested it though
-
-
-## IRC, freenode, #hurd, 2014-02-21
-
-    <gg0> just upgraded to 2.18, locales still segfaults
-    <braunr> ok
-
-
-## IRC, freenode, #hurd, 2014-02-23
-
-    <braunr> ok, as expected, the localdef bug is because of some mmap issue
-
-[[glibc/mmap]].
-
-    <braunr> looks like our mmap doesn't like mapping files with PROT_NONE
-    <braunr> shouldn't be too hard to fix
-    <braunr> gg0: i should have a fix ready soon for localedef
-
-    <braunr> youpi: i have a patch for glibc about the localedef segfault
-    <youpi> is that the backport we talked about, or something else?
-    <braunr> something else
-    <braunr> in short
-    <braunr> mmap() PROT_NONE on files return 0
-    <youpi> ok
-    <youpi> seems like fixable indeed
-    <braunr> nothing is mapped, and the localdef code doesn't consider this an
-      error
-    <braunr> my current fix is to handle PROT_NONE like PROT_READ
-    <youpi> doesn't vm_protect allow to map something without giving read
-      right?
-    <braunr> it probably does
-    <braunr> the problem is in glibc
-    <youpi> ok
-    <braunr> when i say like PROT_READ, i mean a memory object gets a reference
-    <braunr> on the read port returned by io_map
-    <braunr> since it's not accessible anyway, it shouldn't make a difference
-    <braunr> but i preferred to have the memory object referenced anyway to
-      match what i expect is done by other systems
-
-
-## IRC, freenode, #hurd, 2014-02-24
-
-    <youpi> braunr: ah ok
-
-    <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon
-
-
-## IRC, freenode, #hurd, 2014-03-03
-
-    <youpi> braunr: did you test whether
-      https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6
-      does indeed fix locale generation?
-    <braunr> youpi: it doesn't, which is why i applied
-      http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44
-
-
-# IRC, OFTC, #debian-hurd, 2013-06-20
-
-    <youpi> damn
-    <youpi> hang at ext2fs boot
-    <youpi> static linking issue, clearly
-
-
-## IRC, freenode, #hurd, 2013-06-30
-
-    <youpi> Mmm
-    <youpi>  __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs
-    <youpi> deemed to fail....
-    <pinotree> when does that happen?
-    <youpi> at hwcap initialization
-    <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs
-      at startup
-    <youpi> and this is indeed a very good culprit :)
-    <pinotree> ah, a debian patch
-    <youpi> does anybody know a quick way to know whether one is the / ext2fs ?
-      :)
-    <pinotree> isn't the root fs given a special port?
-    <youpi> I was thinking about something like this, yes
-    <youpi> ok, boots
-    <youpi> I'll build a 8~0 that includes the fix
-    <youpi> so people can easily build the hurd package
-    <youpi> Mmm, no, the bootstrap port is also NULL for normally-started
-      processes :/
-    <youpi> I don't understand why
-    <youpi> ah, only translators get a bootstrap port :/
-    <youpi> perhaps CRDIR then
-    <youpi> (which makes a lot of sense)
-
-
-## IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ?
-    <youpi> ext2fs.static linked againt debian glibc 2.17
-    <youpi> well, as long as you don't build & use ext2fs.static with it...
-    <braunr> that's thing, i want to :)
-    <braunr> +the
-    <youpi> I'd warmly welcome a way to detect whether being the / translator
-      process btw
-    <youpi> it seems far from trivial
-
-
-# glibc 2.18 vs. GCC 4.8
-
-## IRC, freenode, #hurd, 2013-11-25
-
-    <youpi> grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an
-      unbootable system
-
-
-## IRC, freenode, #hurd, 2013-11-29
-
-    <teythoon> so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and
-      see what breaks ?
-    <teythoon> when I boot a system with that libc that is ?
-    <teythoon> I wish youpi would have been more specific, I've never built the
-      libc before...
-    <braunr> debian/rules build in the debian package
-    <braunr> ctrl-c when you see gcc invocations
-    <braunr> cd buildir; make lib others
-    <braunr> although hm
-    <braunr> what breaks is at boot time right ?
-    <teythoon> yes
-    <braunr> heh ..
-    <braunr> then dpkg-buildpackage
-    <braunr> DEB_BUILD_OPTIONS=nocheck speeds things up
-    <braunr> just answer on the mailing list and ask him
-    <braunr> he usually answers quickly
-
-
-## IRC, freenode, #hurd, 2013-12-18
-
-    <gnu_srs> teythoon: k!, any luck with eglibc-2.18?
-    <teythoon> tbh i didn't look into this after two unsuccessful attempts at
-      building the libc package
-    <teythoon> there was a post over at the libc-alpha list that sounded
-      familiar
-    <teythoon> http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html
-    <braunr> wow
-    <teythoon> ?
-    <braunr> this looks tricky
-    <braunr> and why ia64 only
-    <teythoon> indeed
-    <braunr> it's rare to see aurel32 ask such questions
-
-
-## IRC, freenode, #hurd, 2014-01-22
-
-    <youpi> btw, did anybody investigate the glibc-built-with-gcc-4.8 issue?
-    <youpi> oddly enough, a subhurd boots completely fine with it
-    <braunr> i didn't
-    <teythoon> no, sorry
-    <youpi> I was wondering whether the bogus deallocation at boot might have
-      something to do
-    <braunr> which one ?
-    <braunr> ah
-    <braunr> yes
-    <braunr> maybe
-    <youpi> quoted earlier here
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
deleted file mode 100644
index c17506d7..00000000
--- a/open_issues/glibc/mremap.mdwn
+++ /dev/null
@@ -1,70 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-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]]
-
-The Hurd does not currently support the `mremap` function.
-
-For the `MREMAP_MAYMOVE` case it is easy to work around; see
-`[binutils]/gold/mremap.c`, for example.
-
-Also see the discussion of [[glibc/mmap]].
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-01-12
-
-    <antrik> maybe it would be easiest actually to implement mremap()?...
-    <braunr> antrik: i'm nto sure
-    <braunr> antrik: implementing mremap could be relatively easy to do
-      actually
-    <braunr> antrik: IIRC, vm_map() supports overlapping
-    <antrik> braunr: yes, I think so too
-    <antrik> braunr: haven't checked, but I have a vague recollection that the
-      fundamentals are pretty much there
-
-[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
-[[I|tschwinge]] remember some discussion about this, but have not yet worked on
-locating it.  [[Talk to me|tschwinge]] if you'd like to have a look at this.
-
-
-# IRC, OFTC, #debian-hurd, 2012-06-19
-
-    <bdefreese> OK, how the heck do you get an undefined reference to mremap?
-    <youpi> simply because we don't have it
-    <pinotree> mremap exists only on linux
-    <bdefreese> It's in sys/mman.h
-    <pinotree> on linux?
-    <bdefreese> No, on GNU/Hurd
-    <bdefreese>  /usr/include/i386-gnu/sys/mman.h
-    <youpi> that's just the common file with linux
-    <youpi> containing just the prototype
-    <youpi> that doesn't mean there's an implementation behind
-    <pinotree> youpi: hm no, linux has an own version
-    <youpi> uh
-    <bdefreese> Ah, aye, I didn't look at the implementation.. :(
-    <youpi> it's then odd that it was added to the generic sys/mman.h :)
-    <bdefreese> Just another stub?
-    <pinotree> ah, only few linux archs have own versions
-    <youpi> for the macro values I guess
-    <pinotree> http://paste.debian.net/175173/ on glibc/master
-    <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from?
-    <youpi> rgrep on a linux box ;)
-    <youpi> <bits/mman.h>
-    <youpi> but that's again linuxish
-    <bdefreese> Aye but with us having that in the header it is causing some
-      code to be run which utilizes mremap.  If that wasn't defined we wouldn't
-      be calling it.
-    <youpi> ah
-    <youpi> we could try to remove it indeed
-    <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined
-      __GNU__?
-    <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself
diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn
deleted file mode 100644
index b12b7558..00000000
--- a/open_issues/glibc/octave.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc]]
-
-
-# IRC, OFTC, #debian-hurd, 2012-04-23
-
-    <pinotree> diffing the octave i386 vs hurd-i386 build logs gives
-      interesting surprises
-    <youpi>   checking whether this system has an arbitrary file name length
-      limit... no              |  checking whether this system has an arbitrary
-      file name length limit... yes
-    <youpi> ?
-    <pinotree> not only that
-    <youpi>   checking whether getcwd handles long file names properly... yes
-      |  checking whether getcwd handles long file names properly... no, but it
-      is partly worki+
-    <youpi> ?
-    <pinotree> -checking whether fdopendir works... yes
-    <pinotree> +checking whether fdopendir works... no
-    <pinotree> (- is i386, + is hurd-i386)
-    <pinotree> -checking whether getlogin_r works with small buffers... yes
-    <pinotree> +checking whether getlogin_r works with small buffers... no
-    <pinotree> -checking for working mkstemp... yes
-    <pinotree> +checking for working mkstemp... no
-    <pinotree> +checking for working nanosleep... no (mishandles large
-      arguments)
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
deleted file mode 100644
index 40d1463e..00000000
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ /dev/null
@@ -1,155 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and
-thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and
-directly use `__thread` instead.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-10-23
-
-    <tschwinge> youpi: If we want to replace threadvars with TLS, there is one
-      problem: the threadvars interface is publically exported:
-      /usr/include/hurd/threadvar.h.
-    <tschwinge> youpi: But I am somewhat inclined to say that the only user of
-      this is libthreads/libpthread.  Do you think differently?
-    <youpi> tschwinge: that's very probable
-    <youpi> so I think we can just drop it
-    <youpi> (people should use TLS anyway)
-
-[[libpthread_set_stack_size]].
-
-After this has been done, probably the whole `__libc_tsd_*` stuff can be
-dropped altogether, and `__thread` directly be used in glibc.
-
-
-# IRC, freenode, #hurd, 2012-08-07
-
-    <tschwinge> r5219: Update libpthread patch to replace threadvar with tls
-      for pthread_self
-    <tschwinge> r5224: revert r5219 too, it's not ready either
-    <youpi> as the changelog says, the __thread revertal is because it posed
-      problems
-    <youpi> and I just didn't have any time to check them while the freeze was
-      so close
-    <tschwinge> OK.  What kind of problems?  Should it be reverted upstream,
-      too?
-    <youpi> I don't remember exactly
-    <youpi> it should just be fixed
-    <youpi> we can revert it upstream, but it'd be good that we manage to
-      progress, at some point...
-    <tschwinge> Of course -- however as long as we don't know what kind of
-      problem, it is a bit difficult.  ;-)
-    <youpi> since I didn't left a note, it was most probably a mere glibc run,
-      or boot with the patched libpthread
-    <youpi> *testsuite run
-    <tschwinge> OK.
-    <tschwinge> The libpthread testsuite doesn't show any issues with that
-      patch applied, though.  But I didn'T test anything else.
-    <tschwinge> youpi: Also, you have probably seen my glibc __thread errno
-      email -- rmcgrath wanted to find some time this week to comment/help, and
-      I take it you don't have any immediate comments to that issue?
-    <youpi> I saw the mails, but didn't investigate at all
-
-[[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]].
-
-
-# IRC, freenode, #hurd, 2013-07-08
-
-    <youpi> tschwinge: apparently there were a lot of changes missing in the
-      threadvars branch I had commited long time ago
-    <youpi> I'm gathering things
-    <tschwinge> youpi: t/tls-threadvar you mean?
-    <youpi> yes
-    <youpi> tschwinge: yes, there were a lot other occurences of threadvars
-      stuff in various places
-    <youpi> I'm building libc again, and will see what issue would remain
-
-
-## IRC, freenode, #hurd, 2013-07-12
-
-    <youpi> braunr: about the per-thread ports, there is also the mig reply
-      port
-    <youpi> (stored in _HURD_THREADVAR_MIG_REPLY)
-
-
-## IRC, freenode, #hurd, 2013-07-15
-
-    <braunr> and with the branch youpi pushed where he removes threadvars, it
-      shouldn't get "too" hard
-    <braunr> (save for the tricky bugs you may encounter)
-    <youpi> well, that branch is not working yet
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-22
-
-    <youpi> I'm currently tracking bugs with my threadvars changes
-    <youpi> some of them seem fine, others, not
-    <youpi> of course the most complex ones are the most probable culprits for
-      the issues I'm getting
-    <youpi> fortunately they're after the process bootstrap
-    <youpi> so basically that works
-    <youpi> just a few dozen tests fail
-    <youpi> mostly about loading .so  or raising signals
-    <youpi> dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open
-      shared object file: Function not implemented
-    <youpi> after having changed errno a bit
-    <youpi> doesn't that look odd ? :)
-    <youpi> good, I found an issue with the sigstate
-    <youpi> now running testsuite again, to see whether there are other issues
-      with it :)
-    <youpi> s/sigstate/reply_port/ actually
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-23
-
-    <youpi> yay, errno threadvar conversion success
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-05
-
-    <gg0_> youpi: any ETA for tls?
-    <youpi> gg0_: one can't have an ETA for bugfixing
-    <gg0_> i don't call them bugs if there's something missing to implement btw
-    <youpi> no, here it's bugs
-    <youpi> the implementation is already in the glibc branches in our
-      repository
-    <youpi> it just makes some important regressions
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-07
-
-    <youpi> about tls, I've made some "progress": now I'm wondering how raise()
-      has ever been working before :)
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-15
-
-    <youpi> good, reply_port tls  is now ok
-    <youpi> last but not least, sigstate
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-21
-
-    <youpi> started testsuite with threadvars dropped completely
-    <youpi> so far so good
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-24
-
-    <youpi> ok, hurd boots with full-tls libc, no threadvars at all any more
-    <gg0> \o/
-    <gg0> good bye threadvars bugs, welcome tls ones ;)
-    <youpi> now I need to check that threads can really use another stack :)
diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn
deleted file mode 100644
index b10703fd..00000000
--- a/open_issues/glibc/t/tls.mdwn
+++ /dev/null
@@ -1,81 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-# To Do
-
-  * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel.
-
-  * Validate our implementation against
-    <https://sourceware.org/glibc/wiki/TLSandSignals>.
-
-
-# Documentation
-
-[[!taglink open_issue_documentation]]
-
-  * IRC, freenode, #hurd, 2011-11-26
-
-        <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.)
-          there is access to memory via gs: -- this will need to be changed for
-          us, right?
-        <youpi> depends on the access
-        <tschwinge>       * `optimized strcasecmp and strncasecmp for x86-32`
-          (multiarch),
-        <tschwinge>         76e3966e9efc3808a9e7ad09121c5dfc1211c20b +
-        <tschwinge>         6abf346582ba678f4850a88b4a5950593841df1d +
-        <tschwinge>         5583a0862cf94f71cbcde91c4043a20af65facca.  `gs`
-          access.
-        <youpi> +       movl    __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax
-        <youpi> that's handled by the linker fine
-        <youpi> it's only the things held in the tcb_t structure which can pose
-          problem
-        <tschwinge> tcbhead_t?
-        <tschwinge> I'm looking at this.
-        <tschwinge> So, at gs:0, there is the TCB.
-        <tschwinge> And we have the same layout as NPTL/Linux, just that we
-          don't have as much data there as they have.
-        <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard,
-          pointer_guard, gscope_flag, private_futex, __private_tm[5].
-        <tschwinge> So, if one of these is referenced (be it my name or by
-          numeric offset), this is invalid for us.
-        <tschwinge> Anything else should work equivalently.
-        <youpi> yes
-        <youpi> usually the only numeric offset being used is 0
-        <youpi> so it would simply not build
-        <tschwinge> And the other offsers are generated via tcb-offsets.sym.
-        <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not
-          used anywhere apart from elf/tst-stackguard1.c, I think).
-
-After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's
-`sysdeps/i386/stackguard-macros.h`; problem remains.
-
-        <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale;
-          -- this means that a __libc_tsd_LOCALE values will be in the TLS
-          segment, and this is what is being accessed from the assembler code
-          with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this.
-        <youpi> yes
-        <youpi> see in the nm output, the libc_tsd symbols
-        <youpi> these provide the offsets
-        <tschwinge> youpi: Thank you, I'm now understanding this part of TLS
-          much better.
-        <youpi> have you had a look at the tls.pdf from Uli ?
-        <youpi> all the gory details are there :)
-
-Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds
-`sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for
-us (at the moment), but it also shouldn't cause any harm, as this file is only
-used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail
-to build for us, as we don't have a `pointer_guard` member in
-`sysdeps/mach/hurd/tls.h:tcbhead_t`.
-
-We don't define `THREAD_SET_POINTER_GUARD`.