IRC channel logs

2026-02-04.log

back to list of logs

<youpi>sobkas: there is no need to set -b and -I if you already set -o hurd
<sobkas>cmake tests are running and 'watch sync' didn't hang, there is something strange while using /dev/wd1s1(rumpdisk) directly by ext2fs translator?
<sobkas>I normally get system hanged and I'm forced to force restart
<Gooberpatrol66>I just learned the guix installer supports hurd as an option now
<nexussfan>It does?
<Gooberpatrol66>says so here https://guix.gnu.org/en/blog/2026/gnu-guix-1.5.0-released/
<nexussfan>Oh nice
<sobkas>14G to build cmake package
<nexussfan>sounds about right
<nexussfan>autotools ftw again?
<sobkas>That strange storeio workaround apparently works
<sobkas>youpi: my mesa patch apparently got stuck, I wonder what can be done...
<damo22>sobkas: according to the MR, the last comment you made was asking them what to do
<damo22>but you pushed again after that, so perhaps add a comment saying its ready for another review?
<nexussfan>Is there something like `sys/prctl.h` but for HURD?
<nexussfan>I'm trying to compile something and it says "sys/prctl.h: No such file or directory"
<nexussfan>Nevermind, fixed it
<azert>sobkas: for my experience if someone in power offers a review and then disappears, it means that the point raised in that review has not been addressed
<azert>but it might as well be that he is on vacation, or the company stopped paying him, or had an incident, or has something else to work on
<azeem>youpi: btw, I also rebuilt glibc with Mike's patch that you just committed as there seemd to be a possiblity it was related to the Postgres hang, but it did not fix it
<azeem>or at least not fully, I feel like it triggers less often now but not really sure, it certainly still happens
<youpi>it's not really related
<youpi>I have a patch for the hang, but it causes some bug in a test
<youpi>it's probably just revealing another bug, I'll investigate before pushing
<azeem>the video for youpi's FOSDEM talk now works, apparently they had some encoding issues and had to re-encode everything: https://fosdem.org/2026/schedule/event/7FZXHF-updates_on_gnuhurd_progress_rump_drivers_64bit_smp_software_bootstrapping/
<damo22>great talk!
<Phodius>hi
<jab>hi Phodius
<Phodius>what the current status of the graphics stack in gnu-hurd? does it only work with a basic framebuffer console?
<jab>Phodius: it's not so great. I believe some people are working on getting mesa working via software rendering.
<jab>The Hurd does not currently have any graphic card drivers.
<jab>So any graphics on the Hurd runs on the CPU.
<Phodius>whoa! even CPU mesa would be a plus, im downloading Hurd just now
<Phodius>say it had graphics driver and say it had wayland would it stop compositors from crashing? when the gpu crashes or would that still crash the system...
<Phodius>i ported WLRoots to WSL/windows so im genuinely interested....
<Phodius>would the gpu driver be in userland if it had one?
<damo22>yes
<nikolar>most of the gpu driver on linux is in the userland already
<Phodius>yeah most of but not all
<nikolar>well, you need to talk to the gpu somehow
<nikolar>which is basically all the kernel bits are doing, just, more or less, passing the userspace's commands through
<Phodius>hurd would take it a step further and it would be completely be in userland
<Phodius>ok heres an idea then, create a Hurd translator that exposes /dev/dri/card0 and implements enough DRM/KMS ioctls for Wayland compositors to work, but backs everything with software rendering to the Mach framebuffer.
<Phodius>almost finished downloading GNU HURD
<damo22>Phodius: that is what i had planned
<damo22>we need to implement kms and drm from scratch though
<Phodius>hmmmm sounds difficult
<damo22>or port it from linux
<damo22>if drm/kms is implemented, it will be accelerated buffers not framebuffer
<Phodius>Linux DRM drivers are tightly coupled to Linux internals
<damo22>probably yes
<damo22>but all memory kzalloc can just be replaced with calloc
<damo22>etc
<damo22>when drm requests accelerated buffers, the memory can be accessed on the gpu
<damo22>we have pci access
<damo22>one of the problems is that virtual addresses are passed in the ioctl
<damo22>but these dont work cross process
<damo22>so one solution suggested was to implement some of the calls inside glibc
<damo22>Phodius: be aware the mesa patches are not merged upstream and software rendering doesnt quite work yet
<damo22>but they will be soon
<Phodius>im just going to be installing just now, where are the mesa patches which repo?
<damo22> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39277