IRC.

2 files changed, 78 insertions, 1 deletions

diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index 9886ec98..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
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index 609d866b..7ce36f41 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -76,3 +76,43 @@ dropped altogether, and `__thread` directly be used in glibc.
     <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