IRC.

2 files changed, 198 insertions, 2 deletions

diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index 8991d4c0..33ef8f3a 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -15,6 +16,8 @@ Things to consider doing when bumping the glibc SONAME.
 There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
 Remove this alias when we bump the libc soname.`
 
+[[!toc]]
+
 
 # IRC, freenode, #hurd, 2012-12-14
 
@@ -33,3 +36,42 @@ In context of [[packaging_libpthread]]/[[libpthread]].
 
 [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
 "4BFA500A.7030502@gmail.com"]].
+
+
+# `time_t` -- Unix Epoch vs. 2038
+
+## IRC, freenode, #hurd, 2013-12-12
+
+    <azeem> because it gets discussed in #debian-devel for the Linux i386
+      architecture right now: what's the deal with hurd-i386 and the 32bit
+      epoch overflow in 2038?
+    <braunr> what do you mean ?
+    <azeem> braunr: http://lwn.net/Articles/563285/
+    <braunr> ok but what do you mean ?
+    <braunr> i don't think there is anything special with the hurd about that
+    <azeem> well, time_t is 64bit on amd64 AIUI
+    <braunr> it's a signed long
+    <azeem> so maybe the Hurd guys were clever from the start
+    <azeem> k, k
+    <braunr> our big advantage is that we can afford to break things a little
+      without too much trouble
+    <braunr> in a system at work, we use unsigned 32-bit words
+    <braunr> which overflows in 2106
+    <braunr> and we already include funny comments that predict our successors,
+      if any, will probably fail to deal with the problem until short before
+      the overflow :>
+    <azeem> luckily, no nuclear reactors are running the Hurd sofar
+    <braunr> i wonder how the problem will be dealt with though
+    <braunr> ah, openbsd decided to break their abi
+    <azeem> yeah
+    <braunr> that's probably the simplest solution
+    <azeem> "just recompile"
+    <braunr> and they can afford it too
+    <azeem> yeah
+    <braunr> good to see people actually worry about it
+    <azeem> I guess people are getting worried about where Linux embedded is
+      being put into
+    <braunr> they're right about that
+    <azeem> "Please, don't fix the 2038 year issue. I also want to have some
+      job security :)"
+    <braunr> haha
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
index 5168479d..273f02fd 100644
--- a/open_issues/glibc/debian/experimental.mdwn
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -130,6 +130,101 @@ Now in unstable.
     <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, OFTC, #debian-hurd, 2013-06-20
 
     <youpi> damn
@@ -173,3 +268,62 @@ Now in unstable.
     <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