IRC channel logs
2026-03-23.log
back to list of logs
<jab>Alicia: I am super interested in arc4random, pledge, and unveil too. Those are super cool OpenBSD ideas. <sam_>arc4random has been in glibc for years <sam_>but we also have getrandom+getentropy these days <jab>nexussfan: you mentioned that pandoc is not building on amd64... I'm pretty sure Samuel and another developer have been tracking down some haskell build failures. The email thread is Qt compilation failure... <jab>it's a super long thread. <jab>Samuel found one bug with xattr ... <jab>sam_: I know in OpenBSD you can call arc4random essentially anytime...inside a chroot, inside a library, inside your libc, inside your kernel...I believe even inside a thread...can we do that on the Hurd ? essentially call it anytime ? <jab>I just read an email thread...Sergey mentioned some issues with calling arc4random inside a chroot. one was that it was slow, and that you have to enable /dev/urandom inside the chroot. <sam_>on linux i think it can use vdso as well <nexussfan>speaking of sergey, how's hurd on aarch64 doing? <tux0r>and what's with the rumours that gentoo/hurd is a thing nowadays? because i would totally use that <sam_>we haven't advertised it yet deliberately :p <tux0r>but you already have a chatroom for it! :p <sam_>yes, just not publicised, and for people to coordinate <tux0r>i *will* buy a laptop just for that and i *will* put strange software on it just to be able to report weird bugs! <tux0r>ACTION only needs the plan 9 tools and maybe wordtsar, so... <tux0r>i vaguely remember IRC discussions from last week when everyone said "no, no, the hurd packages in gentoo that get updated rather often lately are nothing to think about". bah ;p <sam_>yes, because we're not ready to announce anything yet <sam_>but didn't say that, what I (and others) said is that it depends on how things go <tux0r>to be fair, that's where gentoo gnu/linux is as well ^^ <tux0r>in terms of maintenance, no. in terms of usability, totally <tux0r>(still happy with my two gentoo machines, thanks to your awesome support) <jab>nexussfan: AArch64 status...as far as I know, Sergey was the main driving force behind it. I don't believe that his glibc patches were merged...they were able to run Debian GNU/Hurd on a vm. The last I heard about it, to "complete" the AArch64 port to run on real hardware...might require another order of magnitude of effort. <jab>as far as I know, no one has quite yet managed to run Debian GNU/Hurd on real hardware. I think they got close to running it on a development board. One of the biggest problems is that AArch64 usually includes various cores that run at different speeds. So setting up our scheduler for that is going to be tricky. <diegonc>(or having issues with dhcp cliente hangs?) :( <jab>sneek: later tell diegonc that most hurd people use qemu. I wouldn't run on virtual box. <sneek>Welcome back diegonc, you have 1 message! <sneek>diegonc, jab says: that most hurd people use qemu. I wouldn't run on virtual box. <diegonc>well it seems I'm not most people 🤓 <diegonc>I has been running ok back in 2025 :-( <jab>do what you want, but I don't know any hurd developer that uses virtual box to run the Hurd. So you're probably not going to get much help from competent users. <diegonc>besides, it's no fun if it works 😆 <diegonc>I think I'll go back to Qemu to finish building the console client and see if I can catch the timeout waiting for retval issue <etno>The Hurd talk I proposed to JDLL 2026 got accepted 😱 There's no way to escape now <diegonc>so, I added some daemon_log calls to main of console-client. Unfortunately, the new console binary doesn't load the old current_vcs dll :/ <diegonc>but just in case I was looking at getting the debian source with apt source. however apt update complains with: <diegonc>I'm not sure why sources repositories don't work :( <diegonc>well, good thing make install worked. now I'm missing some --model argument. probably from XKB <nekobro>just sharing here if anyone might have an idea, has this occured to anyone before? <diegonc>nekobro, care to elaborate? (people here most probably won't follow a link blindly :) ) <nekobro>diegonc: apologies. the link here is a paste service, and it shows the issue. for some reason, the system seems to be crashing when i run ls /dev. <nekobro> lrwxrwxrwx 1 root root 7 Mar 23 18:41 /dev -> usr/dev <nekobro>i am unsure how to provide more info to better debug and understand this <nekobro>so was more-so curious if this is a known issue or if anyone else has ran into it; i couldnt see anything in bug-hurd <diegonc>pointing /dev to /usr/dev seems weird to me <nekobro>it is, and tbh that might be the core issue at hand here <nekobro>though; others (for gentoo hurd) havent reproduced this issue, just me! which is more strange... <sam_>it's an artifact of some initial porting, we can try without it <nekobro>yeah, i was gonna look into switching that out to see here <azeem>nekobro: so is there a symlink from /dev/ to /usr/dev on all Gentoo Hurd systems? <nekobro>currently, but this may probably end up changing here <youpi>nekobro: do you have swap space? <youpi>but possibly there's some loop in there that eats all memory <nekobro>we dont. that actually does sound plausible. i will look back into this in a bit, but as a workaround, i just create the /dev bits i needed beforehand, which at least works around MAKEDEV crashing <nexussfan>got a patch approved to port another software which is packaged in debian for hurd :D