diff options
Diffstat (limited to 'open_issues/glibc/debian.mdwn')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 39 |
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 |