IRC channel logs

<gnucode>good morning you beautiful hurd people!

<gnucode>well that was fast! X locked up on my just now. And Ctrl-Alt-Del did not kill X.

<gnucode>Any pointers on how I can try to figure out why X seems to be locking up?

<gnucode>on me* just now

<gnucode>sorry I keep logging out.

<gnucode>X seemed like it was going to lock up on me again and so I killed it real quickly

<azert>gnucode: strange, it’s the same code that is rock stable on Linux. If you could guess it was locking up, does it means that something is slowly leaking some resources?

<azert>memory for instance? you can check if it is X or it is the network server

<gnucode>azert top reports that I still have 767 free...

<gnucode>but There could be some leaking happening...unfortunately I have to get going.

<gnucode>thanks

<nikolar>btw is guix hurd in any way officially supported by hurd the project, like debian/hurd

<youpi>what do you mean by "officially" ?

<youpi>I mean, the Linux kernel doesn't care about which distributions use it :)

<nikolar>true, but i thought since hurd is much smaller, it would be more involved into downstream projects

<youpi>but still, I wonder what you mean

<youpi>I mean, I cannot fork myself to get more time :)

<youpi>I cannot magically learn how guix work etc.

<nikolar>fair enough

<nikolar>i was just wondering if there was any hurd involvment into guix, that's all

<youpi>please define "hurd involvment" :)

<nikolar>well if i have to define it, then it's probably nothing in significant capacity :)

<Gooberpatrol66>guix supports hurd, but i guess not the other way around

<Gooberpatrol66>you can download/build images

<nikolar>yup got it

<youpi>ACTION still wondering what the other way around could mean

<youpi>as in: there is nothing debian-specific in the upstream hurd sources etc. for instance

<nikolar>well i read somewhere that "the hurd guys maintain the unofficial debian/hurd distro"

<youpi>well, no

<nikolar>yeah i get that no

<nikolar>now

<youpi>there's essentially one debian maintainers that maintains it

<youpi>it happens that he is also a hurd maintainer, but that's essentially unrelated

<youpi>I was debian maintainer before being a hurd maintainer :)

<nikolar>fair enough :)

<nikolar>thanks

<janneke>the latest release of guix doesn't build on the hurd yet

<Gooberpatrol66>this is just my impression, but guix hurd tends to be less up to date than debian hurd, and it seemed like part of that was due to ambiguity between hurd upstream and hurd debian

<janneke>current master might, so after guix' next release

<Gooberpatrol66>like the upstream source wouldn't work and people would have to hunt down debian patches

<Gooberpatrol66>correct me if i'm wrong though

<janneke>you might be able to do `apt install guix' on debian hurd :)

<nikolar>heh

<youpi>Gooberpatrol66: before I was hurd maintainer, I had to queue patches in debian to get things working yes

<youpi>that has flushed a lot

<youpi>I believe upstream source can just work

<youpi>there are some debian-specific patches in the debian package to accomodate for the way debian works, but that's usual business

<youpi>there are some unfinished patches such as the initrd support, waiting for somebody to finish the work

<youpi>we really needed it in debian for the debian installer, that's why a half-baked implementation ended up there

<nikolar>well if it works well enough for the installer, what's missing

<youpi>to be sane

<youpi>as in: avoid allocating memory twice

<nikolar>kek fair enough

<youpi>and such things that you *dont* want to put under the carpet

<janneke>nikolar: for glibc-2.37, guix has two hurd-specific glibc patches

<janneke>we haven't gotten round to update to glibc 2.38 yeet

<nikolar>janneke: wait arent you in #guix too

<nikolar>lol

<janneke>nikolar: also, there hasn't been much if any "hunting"

<azert>janneke: you mentioned guix latest doesn’t build on Hurd yet, what is the issue?

<nikolar>hunting?

<janneke>ah, that was Gooberpatrol66

<janneke>sorry

<nikolar>ah right, got it

<janneke>the #hurd people have been very helpful fixing difficult as well as silly self-inflicted problems that we had

<nikolar>makes sense

<janneke>i like to think that all of us working on #hurd or #guix try to minimize their mental load and focus on their core tasks at hand

<janneke>and contribute there where they are most effective, or have the most fun :)

<nikolar>yup fair enough :)

<nikolar>honestly when i joined thins channel, i expected it to be a ghose town

<nikolar>that's what #haiku is like

<nikolar>i am pleasantly surprised :)

<janneke>it isn't always this busy, it comes in waves ;)

<nikolar>yeah makes sense

<nikolar>but still

<janneke>azert: mostly dependencies that didn't build, also guix's build system and some guix checks that fail

<janneke>guix does build for hurd on current master, but that's pretty fresh and there hasn't been a release yet

<nikolar>are those the guix system problems, as in if you install guix on top of debian, do you avoid most of those

<azert>ah cool so if it is just unreleased it’s just software in development

<janneke>nikolar: that hasn't been attepmted yet, afaik

<nikolar>guix on debian/hurd?

<janneke>yes

<nikolar>well there's a first time for everything :)

<nikolar>is it in repos even

<nikolar>well one problem with guix hurd image is that fs only has about 150mb free

<Gooberpatrol66>nikolar: you can probably generate a bigger one with guix system image (or maybe use resize2fs)

<nikolar>i am actually trying out the 'childhurd' thing now

<nikolar>a vm in a vm

<Gooberpatrol66>ah

<nikolar>if it works, it's really neat actually

<Gooberpatrol66>it says hurd-vm-service takes a disk-size argument

<nikolar>yup

<Gooberpatrol66>doesn't work tho?

<nikolar>still building

<nikolar>GNU childhurd 0.9 GNU-Mach 1.8/Hurd-0.9 i686-AT386 GNU

IRC channel logs

2023-09-06.log