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 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) (limited to 'open_issues/glibc/debian.mdwn') 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 -- cgit v1.2.3