IRC channel logs

2023-11-08.log

back to list of logs

<gnucode>plasma41: just a sec...
<gnucode> https://paste.debian.net/1297484/
<plasma41>thanks
<plasma41>What gives Quiet-Boot its name? What makes it noteworthily "Quiet"?
<gnucode>plasma41: If you mispell a boot argument, then the boot will silently hang.
<gnucode>You won't know why it stopped booting.
<gnucode>"Quiet-boot chokes on misspelled or missing boot arguments. When this happens, the Hurd bootstrap will likely hang and display nothing. That is tricky to debug."
<gnucode>If you have a better name, then let me know.
<gnucode>Quiet-Bootstrap maybe
<plasma41>So it's a name of derision?
<gnucode>sounds about right.
<gnucode>but the name is also reflective of the current bootstrap behavior.
<plasma41>Was that current behavior intentional? I certainly doesn't sound desirable.
<plasma41>s/I certainly/It certainly/
<plasma41>"Mute" or "Muzzled" sound like more applicable descriptors than just "Quiet".
<gnucode>I like Muzzled better than Mute.
<gnucode>But Muzzled is like Quiet
<plasma41>One is a forced constraint whereas the other might just describe a choice
<gnucode>Hmmm. Muzzled is longer than Quiet. To me they mean the exact same.
<Gooberpatrol66>MuteBoot rhymes
<zamfofex>Does it? I thought “mute” rhymed with “beaut”.
<Gooberpatrol66>they both end in -oot sounds
<zamfofex>I don’t think I ever heard anyone pronounce “mute” that way at all.
<gnucode>"MuteBoot" is nice, but it is not as accurate as quietBoot. Mute means no communication. Quiet means some communication.
<Gooberpatrol66>me-oot
<gnucode>MuteBoot is a good idea. :)
<zamfofex>I think “quiet” is more recognisable as a word, and is already used a lot in the context of computing. And it has the bonus of being what it has been being called already.
<gnucode>zamfofex: I agree. I think "QuietBoot", while a bit derisive is also descriptive.
<gnucode>and accurately so.
<plasma41>gnucode: How far along is Bootshell V2? Has any code been written or is it still in the proposal & discussion phase?
<zamfofex>I’d love to be able to help in some way, though probably in the time it would take me to learn enough about the Hurd’s internals, it would already be completed by others. (Though I do wish I could learn more about the Hurd!)
<gnucode>plasma41: you would have to ask solid_black (sergey)
<gnucode>I believe that he is already coding on it. damo22 has a git branch, where he simplified some early translators for sergey
<dsmith>dumboot
<dsmith>hangonsillyerrorswithnovisibleoutputboot
<gnucode>hahaha! that second suggestion was an idea of mine too!
<gnucode>oh also, I bought a Thinkpad 410 or 510...
<gnucode>I want to install the Hurd on it with a SATA HDD. Does anybody know if the installer will work?
<fury999io>
<gnu_srs1>youpi: I thought rust is supported now, but no cargo package?
<youpi>gnu_srs1: in the rust ecosystem, things take *ages* to get compiled / integrated
<youpi>s/compiled/commited/
<youpi>we have a patch against rustc 1.72, but only 1.70 is in debian so far
<youpi>integrated support will be in 1.74
<youpi>we have no idea when that will land in debian
<youpi>hopefully within not too many months
<zamfofex>Isn’t it reasonable to apply a patch for it from Debian’s side?
<youpi>zamfofex: it is
<youpi>but the patch is against 1.72, not 1.70
<youpi>and yes, it's *complex* to port from one version not another
<youpi>there are litteraly thousands of commits between two rust versions
<gnu_srs1>Tks. Seems like rust upstream does not have a stable api/abi.
<zamfofex>What option should I pass to ‘dpkg --add-architecture’ if I want to install a toolchain that runs on Linux but compiles for the Hurd?
<zamfofex>(Running it on Linux.)
<zamfofex>Hmm, seems like what I want is actually https://github.com/flavioc/cross-hurd Fair enough.
<gnucode>hello friends
<zamfofex>Hello!
<gnucode>zamfofex: what are you up to today?
<zamfofex>Hello! Interestingly enough, I just decided to start seeing if I can port the Haskell toolchain for the Hurd. 🙂 (Fairly daunting task!)
<youpi>? haskell is already ported to the hurd
<youpi>it just currently seems to have a build hickup
<youpi>since version 9.4.7
<zamfofex>Oh. It wasn’t mentioned here: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms So I assumed it wasn’t.
<zamfofex>Well, what ought I to do with this GNU cross‐toolchain I just built now, then? 😅
<youpi>well, fix the build hickup ? :)
<youpi>if you can add GNU/Hurd to the wiki page, that'd be helpful too ;)
<zamfofex>Fair enough! Would you care to clarify what’s this “build hiccough”? Or is it difficult to describe?
<youpi> https://buildd.debian.org/status/logs.php?pkg=ghc&arch=hurd-i386
<youpi>a lot of failures are due to some SIGINT issue, that's fine enough
<youpi>but starting from 9.4.7 we have something that doesn't pass, event with retrying
<youpi>Error, rule finished running but did not produce file:
<youpi> _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a
<youpi> (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0 for an example log)
<youpi>(s/SIGINT/EINTR/ above, actually )
<zamfofex>That sounds like a much less dauting task that’s still fairly useful. 🙂
<gnucode>I'm starting to think that Sergey's new bootstrap proposal should have a name for its overall design. And then a name for its mini-console.