IRC channel logs

<gnucode>ok. I'm glad to know that I had it wrong.

<nexussfan>youpi, does src:mesa still need libdrm-dev build-dependency on hurd-any?

<nexussfan>Is there a way to get dladdr on hurd?

<nexussfan>Nevermind

<gnucode>it would be cool if the hurd had wireguard...

<gnucode>it is a bit weird that I am saying that...seeing as I've never actually used wireguard.

<nexussfan>Working on compiling ClassiCube for Hurd

<nexussfan>It's running

<nexussfan>Waiting for the assets to download....

<nexussfan>Working

<gnucode>what's classicube ? another game ?

<nexussfan> https://github.com/ClassiCube/ClassiCube

<nexussfan>PR for hurd support https://github.com/ClassiCube/ClassiCube/pull/1517

<gnucode>geez a game that is written almost entirely in C. That's impressive!

<nexussfan>It is 100% C

<gnucode>I should try to write a hurd translator again. The last time I tried...I got pretty much no where. :)

<nexussfan>what would it do?

<gnucode>well the last one that I wanted to do was a caesar cipher...then sergey went and wrote it.

<gnucode>so I don't know. something just for the learning experience.

<nexussfan>Yeah

<nexussfan>ACTION is helping a friend get hurd running in a vm to do some development

<gnucode>if you find anything cool to document let me know:

<gnucode> https://hurdos.com/wiki/contributing/developer-workflows.html

<nexussfan>Note to self: xorg kbd needs `/etc/default/keyboard`

<nexussfan>Aka installing console-setup

<nexussfan>Wait not sure about that second part

<janneke>new guix blog post: https://guix.gnu.org/en/blog/2026/the-64-bit-hurd/

<azeem>janneke: what are childhurds, is that a guix-specific thing?

<azeem>ah looks like, neat

<janneke>azeem: we coined `childhurd' in guix as a hurd running in a [qemu] vm on a foreign host, eg linux

<azeem>ah ok

<janneke>as configuring a `childhurd' on a guix system in its easiest form is only a one-liner, we thought a new term, next to subhurd, was needed

<rrq>is guix a package manager? or is it an OS?

<rrq>(wrong place to ask I guess)

<janneke>rrq: guix system is an os, based around the guix package manager, which can be used on any (foreign) operating system

<janneke>guix [system] is a `cousin` of nix[os]; functional package management

<janneke>rrq: [replying a bit late after replying in #guix] as long as one is not taking over the channel with off-topic messages, that's quite okay, no worries!

<rrq>ta

<Pellescours>my problem is that I don’t know how to debug it

<gnucode>grrr, netsurf is not not starting reliably.

<Pellescours>I think gdb is broken with threads, I can’t break my `func`. I get a SIGILL

<gnucode>janneke: I'm reading your hurd blog post (very well written by the way). But you should probably tweak the "Example usage:" section of RumpNET. The commands should read

<gnucode>sudo settrans -fgapc /dev/rumpnet /hurd/rumpnet

<gnucode>sudo settrans -fgapc /dev/wm0 /hurd/devnode -M /devrumpnet wm0

<gnucode>sudo settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/wm0

<gnucode># Now you should add in replace /dev/eth0 in /etc/network/interfaces to /dev/wm0

<gnucode>sudo ifup /dev/wm0

<gnucode>if you check on the darnasses wiki it might already be fixed like I've just described.

<gnucode>#New you should replace /dev/eth0 in /etc/network/interfaces to /dev/wm0

<gnucode>janneke: you may also wish to tell people that they can flash a working qemu image directly to disk. This is the easiest way (in my opinion) to install Debian GNU/Hurd: https://hurdos.com/wiki/hurd/running/flash_qemu_img.html

<janneke>gnucode: thanks! and hmm, we've got no /etc/network/interfaces in guix; and we don't imperatively edit things

<janneke>not sure what the declarative way to define this is?

<gnucode>doesn't guix have a etc-service that lets you create arbitrary files on /etc ?

<janneke>so this all may need some work...

<janneke>gnucode: the flashing to disk seems like a nice feature for debian, but for a declarative os like guix there should be no need to do something like that?

<gnucode>totally fine. It's your blog post. Your decision. I have always struggled installing the Hurd. it's not the easiest process. Flashing a working image made things sooo easy for me personally.

<gnucode>and I do think guix has the right policy of only providing substitutes, if the packages pass the test suites by the way.

<janneke>gnucode: thanks for the hint and it's good to know, i'm just not sure where to add this? with guix, you install using guix system init config.scm /dev/the-device

<gnucode>I'm actually typing this to you from a T420. I downloaded debian hurd image, tweaked the image a bit in qemu (installed packages, set up my user, tweaked emacs), then flashed the image to disk, then increased the ext2 filesystem....then I rebooted the T420 in the Hurd. It's been smooth sailing ever since.

<janneke>if you use the same config.scm you used for the vm, you'll get the same on your device

<janneke>i found https://darnassus.sceen.net/~hurd-web/hurd/rump/rumpnet/

<gnucode>I would have linked to it directly...but netsurf is not working for me at the moment...I'm stick using eww for now. :)

<janneke>but am puzzled as to what to do about `/etc/network/interfaces'; of course you can add a "service" that writes that file, but thas seems an ugly hack, so yeah -- someone would need to look into this

<janneke>gnucode: np!

<janneke>/etc/network/interfaces seems to be a debian/ifup-ifdown thing, this prolly has to be designed/supported/implemented for guix; oh well :)

<youpi>you'd probably want to just follow the guix way

<youpi>just like it's down on guix/linux

<janneke>yes

<gnucode>janneke: well...suppose that you wanted to install the Hurd on a T420...At the moment the *best* way I know how to do it is to flash the image directly to disk. Because by default the linux drivers on /dev/eth0 do not work, only /dev/rumpnet works. So the CD installer image will only install a "bare bones" Debian Hurd. Then after I have booted and set up rumpnet, then I can download additional packages.

<gnucode>Alternatively, if I flash a working image to disk...I can set up /dev/rumpnet in qemu. But to your point...I'm not sure where you would link to it on the blog post. You might have to link to my site hurd wiki mirror if you wanted to share it. anyway, your call.

<janneke>gnucode: right; yes when i installed guix/hurd on a thinkpad x60, i just used guix system init config.scm /mnt/hurd from guix/linux

<janneke>that's the very same thing as the installer would do, btw

<janneke>so i'd like that to work, but yeah, we'd need to figure-out rumpnet initialization for sure

<gnucode>oh. That's a smart way to do it!

<gnucode>that's weird. I was able to start netsurf via running "gdb netsurf"...odd.

<Pellescours>ahh so frustrating, I don’t know how to debug my test with gdb not working correctly (put a breakpoint on a thread do not work)

<gnucode>Pellescours: what is it that you are working on ? Have you tried flame thrower debugging ? Point a flamethrower at your computer and pull the trigger.

<janneke>gnucode: i've added a footnote about /dev/wm0 with a link to the faq; ty!

<etno>I had sent a patch to netsurf following their instructions to solve PATH_MAX. It never got reviewed.

<Pellescours>gnucode: I found a bug with threads (from git testsuite). I was able to simplify it https://pastebin.com/BkZScbcU

<Pellescours>basically I have the program output having less line printed than what expected (9 * 9 so 81). The root issue is probably in libc, but if I start it, put a breakpoint in `func` and run it, I end up with a SIGILL

<gnucode>sounds super annoying. Have you posted that source code bit to the mailing list ?

<Pellescours>not yet, only in this channel

<gnucode>I feel like we should have a Hurd test suite with all of these various C programs that misbehave.

<gnucode>also webpaste.el is freaking awesome!

<gnucode>I can paste to pastebin's from emacs!

<Pellescours>I agree, a testsuite would be really helpful

<gnucode>I guess we have make check...should be possible to add.

<bjc>hurd needs ^T like the bsds so i can tell whether or not it's doing anything =)

<gnucode>what is ^T ?

<bjc>on the bsds it sends SIGINFO, which will cause the program/kernel (depending on who catches it) to spit out info on what's currently running

<bjc>it's outrageously useful

<nexussfan>Oh didn't know hurd also has that

<bjc>it doesnt. it would be great to have though

<nexussfan>Oh

<youpi>? IIRC it does

<bjc>^T doesn't do anything for me

<nexussfan>console, tty, or xterm?

<bjc>console

<youpi>the mach console is very limited

<youpi>I wouldn't be surprised that it has limited support

<bjc>kill -INFO $$ only spits out got a SIGINFO

<youpi>the term translator on top of it might help, but not necessarily completely

<youpi>so better test on the hurd console

<bjc>i can currently only log in on the console =)

<nexussfan>Yeah hurd ttys are much better than mach console

<bjc>oh wait, might be ttys

<bjc>how can i tell? i'm getting the gnu graphic

<bjc>but i think that'll work on the ttys

<nexussfan>Is it `console` or `tty1`

<nexussfan>GNU graphic should show up on all console types iirc

<bjc>lemme try this on debian

<bjc>no luck, but i'm also logged in on a tty. is there a shortcut for console?

<nexussfan>afaik ALT+CTRL+BACKSPACE

<bjc>not working for me in qemu

<youpi>you can use echo $TERM

<youpi>to know what term you have

<youpi>or just "tty"

<bjc>sure, but that's not the device

<youpi>?

<bjc>$TERM is your terminal type, like vt102 or whatever

<youpi>yes

<youpi>and on the hurd and mach consoles, you have different values

<bjc>its independent of what device you're using for io, like /dev/tty1

<bjc>oh, ok

<bjc>TERM is hurd

<bjc>i'm trying to do a settrans on /dev/tty2 to make it a console but i guess that's unlikely to work

<youpi>so it's the hurd console

<bjc>it's the hurd console type on /dev/tty1, yes

<bjc>and ^T doesn't seem to do anything

<youpi>TODO:*** SIGINFO handler?

<youpi>tasks: * Useful response to SIGINFO.

<youpi>term/munge.c: send_signal (SIGINFO);

<youpi>so term does apparently have some support for it

<bjc>ok i guess that answers that =)

<youpi>possibly it's not plugged somewhere

<youpi>but it really is there

<youpi>contribution welcome on investigating it

<bjc>yeah, the output is 'got a SIGINFO'

<youpi>possibly it's stupidly getty which doesn't know that it should set VSTATUS

<bjc>so i guess it's just a stub

<youpi>the output of what?

<bjc>kill -INFO $$

<bjc>or really any pid

<youpi>so in a shell?

<bjc>yep

<youpi>but then there is indeed nothing to shiow there

<youpi>do it while dd or such

<youpi>otherwise sure there's nothing to print

<bjc>if i do a kill -INFO from another login i get nothing on the tty where the process is running

<bjc>i am running 'cat /dev/zero > /dev/null'

<youpi>does cat have a SIGINFO handler?

<bjc>no idea

<bjc>the bsds have it caught at the kernel if the process doesn't catch it

<youpi>e.g. dd does show me info on ^T through ssh

<youpi>so the support really is there

<bjc>dd does work

<youpi>but then of course if your program doesn't handle it, well sure it's not supported

<youpi>ok then what does bsd say in such a case?

<bjc>it tells you what syscall its in

<bjc>plus uptime and date

<bjc>probably not so useful on mach

<youpi>not just not useful, but not feasible

<youpi>since it's not mach that implements siginfo

<youpi>but glibc can do such a thing

<youpi>contribution welcome, it's in glibc/hurd/siginfo.c

<bjc>👍

<youpi>note: your "^T doesn't do anything for me" was extremely misleading. You should have said from the start that it was really printing "got a SIGINFO"

<bjc>it didn't do that at first

<youpi>because that makes a very ample difference as in whether it's supported at all or not

<bjc>that was only with the kill command

<bjc>^T by itself did nothing

<bjc>that was also with cat, not dd, which did work

<youpi>in my test it does

<bjc>when running cat?

<youpi>again, saying that it would work in dd is a very useful information

<youpi>yes

<youpi>root@hurd:~# cat

<youpi>got a SIGINFO

<youpi>both on mach and hurd consoles

<bjc>yeah, i don't see that on /dev/tty*

<youpi>well, I do

<bjc>so not so misleading, but different behavior

<youpi>the thing is: we expect people to investigate before saying something doesn't work

<youpi>otherwise we spend time doing the exact same investigation that you could have done

<youpi>thus consuming some of our time, which cannot be spent on something else

<bjc>i'm trying not to be rude here, but how was i supposed to investigate this past executing a long-running command and hitting ^T?

<youpi>sorry for being grumpy, but I have an ample backlog of mails to process...

<bjc>i don't know what i don't know

<bjc>there's no reason to suspect dd is different from cat

<youpi>that's the whole point of SIGINFO

<bjc>there's no reason to suspect that tty* is different from console

<youpi>for applications to be able to report their progress

<bjc>i did due diligence, to the best of my ability, before i said anything

<youpi>the fact that the bsd kernel also reports something is really a bsd invention

<youpi>in my tests, tty* is really exactly the same as the console

<bjc>i know! i never said otherwise. i said it'd be useful to have it

<bjc>but it is not for me. i'm trying not to waste anyone's time

<youpi>I just mentioned it might be different because I suggested it might be

<bjc>look man, i did my best

<youpi>well, I'm not really sure of this

<youpi>sorry for putting it bluntly

<bjc>fine, but right now you're just saying "works on my machine"

<bjc>so

<youpi>but coming with " hurd needs ^T like the bsds"

<youpi>looks like very assertive

<youpi>as in "it doesn't work, make it work"

<bjc>that's how you're reading it, it can also be read as "this'd be great to have because it's a great feature"

<youpi>./5

<youpi>I'm sorry, but not

<youpi>"need" != "should"

<youpi>man, am I so upset

<youpi>I'll just stop reading irc

<youpi>and really concentrate on mails

<bjc>good idea

<youpi>maybe one thing you don't realize is that we see *many* people come and say "hurd needs to do foobar", and then leave without contributing anything

<bjc>you know, i get that

<youpi>so, yes, at some point I am losing patience

<bjc>what i don't get is the accusation that i'm not testing anything and just wasting people's time because i'm lazy or something

<gnucode>we do value your continued contributions to the Hurd youpi. The Hurd wouldn't exist without you. Probably would have died many years ago. :(

<bjc>that wasn't fair, and that should be avoided, because it is very, very rude

<gnucode>bjc: I struggle with the same thing. There's plenty of times when I say, "can ya'll help me with this thing", when the documentation, google search, or 5 minutes of testing would have given me the answer. Try not to take it personally.

<bjc>oh my god

<gnucode>And Samuel (youpi), as far as I know, in the main committer to the Hurd git repo. He has to review, code contributions, wiki edits, debian packages not building, various hurd new comers emails, etc. He's also a full time professor. He gives 100% of his free time to the Hurd. We are very lucky to have him around.

<youpi>gnucode: that wasn't really the way

<gnucode>just trying to releive the tension.

<youpi>to be fair with bjc, SIGINFO is a really not-known feature, since linux doesn't support it

<youpi>so google will be of little help about it

<gnucode>I should add it to my list of things to add to the wiki.

<nexussfan>got classicube with multiplayer running on hurd :D

<nexussfan>solid 3 fps

<nexussfan>actually not solid 3 fps it's usually 0.3-3fps

<gnucode>hahaha!

<gnucode>totally playable!

<gnucode>when I was reading about classicube ... it seemed that it depends on non free media files. Is that true ?

<nexussfan>Doesn't *depend*

<nexussfan>It gets assets from the official minecraft game

<nexussfan>But iirc you can use a free version

<nexussfan>gnucode: https://youtu.be/WLhm_e2NniQ

<gnucode>I'd prefer whatever game uses the non-proprietary media files. :)

<nexussfan>ClassiCube lets you use whatever assets you want

<nexussfan>You don't need to use the minecraft ones

<gnucode>have you played classicube before on Linux ?

<nexussfan>Nah

<nexussfan>One of my friends plays classicube

<nexussfan>and i noticed it was extremely portable so I decided to make it run on hurd

<nexussfan>there's softgpu support if you don't have opengl :D

<gnucode>that's pretty cool.

<gnucode>wow, samuel beat me to the siginfo wiki contribution. That was fast.

<janneke>the ^T feature looks cool, now we "need" :) a contribution

<Alicia>is that the one that sends sigusr1?

<youpi>siginfo

<gnu_srs1>working with the test suite for burp I found out that acl_set_file fails at setxattr( (const char *path, const char *name, const void *value,...) which is in glibc for Hurd.

<gnu_srs1>In that call name has to be gnu.author or gnu.translator. Which arguments are valid for value? Played a little with listxattr, see code in listxattr(2).

<gnu_srs1>touch /tmp/foo; ./test_listxattr /tmp/foo;: gnu.author, but setfattr -n gnu.author -v chocolate /tmp/foo; fails: setfattr: /tmp/foo: Invalid argument.

<youpi>see glibc/hurd/xattr.c about the limited xattr support for now

<gnu_srs1>setfattr -n gnu.author -v 1000 /tmp/foo works: ./test_listxattr /tmp/foo: gnu.author: 1000

<gnu_srs1>Maybe one could patch the help output to setfattr etc to be usable for Hurd?

IRC channel logs

2026-03-01.log