From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- open_issues/glibc/debian.mdwn | 39 ++++++++++++++++++++++++++++++++- open_issues/glibc/t/tls-threadvar.mdwn | 40 ++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+), 1 deletion(-) (limited to 'open_issues/glibc') 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 + + uh, the i686 profiles have much more progression than i386 + it seems they don't actually run these + youpi: what do you mean with "we don't run those"? + iirc there are three build profiles done, but there are 4 + regression test files + yes, but some failing tests are not run in the three build profiles + even if they are built for all of them + not even run? which ones? + see for instance test-ifloat.out + test-ifloat is built in all profiles, but only run in the libc one + don't have a glibc built tree around atm, sorry :/ + perhaps because glibc thinks it's not useful to run it again if it + fails on i386 + you can check the logs + do you think glibc's build system is that smart? :) + all the builds are done in separate builddirs, so theorically + they should not touch each other... + yes + that's why I'm surprised + could it be they get not run in optimized/particular builds? + what about linux/kfreebsd i386? + I don't see what makes them not run + or at least be treated particularly by th eMakefile + not run on kfreebsd either + 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? + that's the vm on my machine + which kind of vm? + kvm? + y + they are working here + 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. tschwinge: yes, there were a lot other occurences of threadvars stuff in various places I'm building libc again, and will see what issue would remain + + +## IRC, freenode, #hurd, 2013-07-12 + + braunr: about the per-thread ports, there is also the mig reply + port + (stored in _HURD_THREADVAR_MIG_REPLY) + + +## IRC, freenode, #hurd, 2013-07-15 + + and with the branch youpi pushed where he removes threadvars, it + shouldn't get "too" hard + (save for the tricky bugs you may encounter) + well, that branch is not working yet + + +## IRC, OFTC, #debian-hurd, 2013-09-22 + + I'm currently tracking bugs with my threadvars changes + some of them seem fine, others, not + of course the most complex ones are the most probable culprits for + the issues I'm getting + fortunately they're after the process bootstrap + so basically that works + just a few dozen tests fail + mostly about loading .so or raising signals + dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open + shared object file: Function not implemented + after having changed errno a bit + doesn't that look odd ? :) + good, I found an issue with the sigstate + now running testsuite again, to see whether there are other issues + with it :) + s/sigstate/reply_port/ actually + + +## IRC, OFTC, #debian-hurd, 2013-09-23 + + yay, errno threadvar conversion success -- cgit v1.2.3