IRC channel logs


back to list of logs

<gnucode>oh I figured it out.
<gnucode>does anyone use i3 on the Hurd? I feel like that would be pretty lightweight.
<biblio>gnucode: core-i3 from intel ?
<youpi>the window-manager I guess
<gnucode>yeah the window manager. :)
<gnucode>well i'm about to try playing with haunt on the Hurd. Installing guile 3.0 now. I didn't even know that the Hurd supported guile 3.0e
<gnucode>it is entirely possible that it doesn't and i will figure that out when I try to install it. We'll see.
<youpi1>IIRC the testsuite passes, or at least mostly
<gnucode>youpi1: that's super awesome! I'm actually working on a blog post write now for via the Hurd and Emacs. It's pretty awesome that I can write my blog on the Hurd!
<ArneBab>gnucode: that soungs great!
<youpi1>> 1 of 36 tests failed
<youpi1>yes, just one failure
<gnucode>geez. That's pretty awesome! just out of curiosity...what is the failure?
<jpoiret>so, it's me again working on the Guix port of Hurd. We're still unable to boot after upgrading everything to commits around last september (to get it to build with gcc 11)
<jpoiret>we can't seem to exec mach-defpager. If I fork + exec, tracing the new task gives me a bunch of "no memory is assigned to address 0x______", and exec'ing the early userspace guile process directly gives me a process that is stuck on a kernel page fault trap
<jpoiret>I'm wondering how I could go about debugging this any further
<jpoiret>janneke: have you figured out anything else? I'm pretty stumped tbh, I have no experience debugging these kinds of things
<janneke>jpoiret: no
<janneke>without putting much thought and debugging into it, we could resort to bisecting hurd versions/binaries
<jpoiret>I'm a bit scared that the more in-depth changes to the build process I made may have caused it
<janneke>that seems unlikely, but is possible, of course
<jpoiret>right. That's pretty expensive computationally though, esp. if gnumach has to be moved around. I can try with just Hurd first
<janneke>so, reverting the hurd tarball versions to what they were, while keeping your changes, would be a useful bisect
<janneke>otoh, someone who *really* knows about hurd debugging, kdb, strace etc, might just debug what's going on
<janneke>glancing through the hurd changelog / patch summaries could also help
<jpoiret>that's mostly what I've been doing, esp. related to the exec server
<jpoiret>ah, the main problem is that the old Hurd version we were using doesn't build anymore with gcc-11
<janneke>jpoiret: just list gcc-7 in native-inputs
<apteryx>this won't work for cross-builds though (guix bug)