Merge branch 'master' of braunbox:~hurd-web/hurd-web

5 files changed, 224 insertions, 4 deletions

diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index ceb5ea21..f864469d 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc open_issue_libpthread]]
 
+Things to consider doing when bumping the glibc SONAME.
+
 
 # IRC, freenode, #hurd, 2012-12-14
 
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index 331632f3..2ef2c474 100644
--- a/open_issues/glibc/debian.mdwn
+++ b/open_issues/glibc/debian.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -24,6 +24,43 @@ 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
@@ -62,3 +99,70 @@ 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
index 8d117e99..5168479d 100644
--- a/open_issues/glibc/debian/experimental.mdwn
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -11,6 +11,7 @@ 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
@@ -113,3 +114,62 @@ Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
       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, 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
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index 105a07c7..7ce36f41 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -64,3 +64,55 @@ dropped altogether, and `__thread` directly be used in glibc.
     <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
diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn
index 68db2cc1..a92a21fb 100644
--- a/open_issues/glibc/t/tls.mdwn
+++ b/open_issues/glibc/t/tls.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!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
@@ -14,7 +15,8 @@ License|/fdl]]."]]"""]]
 
   * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel.
 
-  * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed.
+  * Validate our implementation against
+    <https://sourceware.org/glibc/wiki/TLSandSignals>.
 
 
 # Documentation