summaryrefslogtreecommitdiff
path: root/open_issues/glibc
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2013-09-25 21:45:38 +0200
committerThomas Schwinge <tschwinge@gnu.org>2013-09-25 21:45:38 +0200
commiteccdd13dd3c812b8f0b3d046ef9d8738df00562a (patch)
treee6c585035d2e869e26a0d3a93efa51810543d40e /open_issues/glibc
parent9933cec0a18ae2a3d752f269d1bb12c19f51199d (diff)
IRC.
Diffstat (limited to 'open_issues/glibc')
-rw-r--r--open_issues/glibc/debian.mdwn39
-rw-r--r--open_issues/glibc/t/tls-threadvar.mdwn40
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