IRC.

1 files changed, 38 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