IRC channel logs

<jab>anybody have a guess how large a qemu hurd image should be if you want to install i3 on it?

<jab>now that I have the hurd installed via qemu, I need to get it to boot via rumpdisk.

<jab>Then I can try flashing that to a image to a laptop.

<nexussfan>not sure how qemu works with rumpdisk, but thinkpads work well with it

<damo22>i dont think any hurd rootfs needs to be bigger than 10G

<damo22>if you put other data on a separate partition

<jab>sounds good.

<jab>nexussfan: really? why wouldn't rumpdisk work with qemu ?

<damo22>rumpdisk was developed on qemu

<jab>sorry, you said "not sure how qemu work with rumpdisk" not that it didn't work.

<jab>damo22: is there a particular qemu invocation that you need to run rumpdisk ?

<jab>I guess I'm going to try to follow the guide that I wrote to try to use rumpdisk:

<jab> https://darnassus.sceen.net/~hurd-web/hurd/rump/rumpdisk/

<damo22>it should all be configured already in debian

<nexussfan>yeah

<jab>ok.

<damo22>just pass noide

<jab>well in that case I should just be able to dd the qemu image to the disk.

<nexussfan>but the installer still allows you to use the IDE drivers if you need to

<damo22>and the right disk device

<nexussfan>however for some reason my t420 hurd machine doesn't like cd0, so i can't use the installer

<jab>nexussfan: I haven't been able to get the installer to work for me lately. Right now, I'm trying to install the hurd via flashing the debian image.

<damo22>i havent reinstalled since the beginning

<damo22>once you have a working disk you can upgrade

<nexussfan>Yeah

<jab>that's impressive.

<damo22>i did lose my partition once due to corruption, so i might have had to blow it all away once

<damo22>but things are more stable now

<jab>damo22: are you using the 64 bit version more often than the 32 bit version yet ?

<damo22>yes

<nexussfan>I only use 64bit hurd.

<damo22>i only use i386 CI to test

<damo22>and occasionally i boot i386 smp to test something

<nexussfan>I used to use i386 Hurd on my T43 but not anymore

<damo22>the gnumach test suite fails on x86_64 for some tests, we need to fix all those

<nexussfan>Waiting for x86_64 smp

<damo22>well im kind of stumped on this page fault

<nexussfan>does PAE work on i386?

<damo22>yes

<nexussfan>nice

<jab>I forget...are ya'll using the 64 bit version on real hardware ?

<nexussfan>Yes

<damo22>no, i develop in qemu

<jab>gotcha.

<damo22>rebooting a real machine is painful

<nexussfan>My tests/coding are in qemu x86_64, but I run ready software on my real hurd machine

<jab>that still is pretty cool.

<damo22>the APs try to execute code at 0x4000000036

<damo22>not a real address

<nexussfan>The only real thing I am working on for hurd right now is xlibre; i'm trying to debug why the kbd driver isn't working

<damo22>nexussfan: if youre interested in gui, why not work on wayland

<rrq>damo22: is that calling vm_map_msync ?

<jab>nexussfan: did you see that Xorg just deleted 2 years worth of commits?

<damo22>rrq: i dont know

<rrq>yeah I just checked some ...0036 address options in the gnumach symbol table

<damo22>it might be a made up rubbish address

<damo22>intended for some other purpose

<damo22>but somehow gets called

<nexussfan>damo22: that's lots of work with drm, compositor support, etc; xlibre support is much closer anyway, only couple more things to fix. maybe after finishing xlibre support i could work on fixing a wayland compositor for hurd

<nexussfan>jab: yes you already told me

<damo22>nexussfan: i thought the mesa patches sobkas worked on might be enough to get wayland working with software rasterisation

<nexussfan>oh! interesting

<nexussfan>there are a lot of different compositors however, which one should be focused on first?

<damo22>probably the gnome one?

<nexussfan>Mutter okay

<jab>I personally vote on sway. :)

<nexussfan>I was thinking of doing weston but that has a buildd time of 100d :O

<nexussfan>I think we should first do an easier compositor

<damo22>gnome integrates well with desktop

<nexussfan>true

<damo22>its not the lightest one but it would be shiny

<nexussfan>once mesa/hurd gets upstreamed i'll check it out

<jab>as far as I can tell, qemu does not use rumpdisk by default by the way. /etc/fstab shows /dev/hd0 not /dev/wd0

<jab>not super hard to fix. I just thought I'd mention it.

<damo22>its not a bug, its on purpose i think because its not quite ready apparently

<damo22>it still chews too much ram

<damo22>that is probably the last remaining issue

<jab>well I'm not sure what I did wrong, but I could not get rumpdisk to run on qemu

<jab>I was following this guide: https://darnassus.sceen.net/~hurd-web/hurd/rump/rumpdisk/

<damo22>-M q35 ?

<jab>I should probably add that in and see.

<damo22>it needs that so it has AHCI controller

<jab>let me try again.

<jab>damo22: I got rumpdisk working on qemu. Thanks!

<jab>morning friends!

<jab>oh that's cool. The 64 bit hurd is using rumpdisk by default.

<jab>It's only the 32 bit image that is not using it by default.

<jab>and it looks like the 64 bit image by default doesn't make you configure your apt sources.list file. That's nice.

<jab>I thought I saw it say that it was upgrading the icewm. Hmm. I don't recall installing that, but that's cool.

<jab>huh...is this already set up to run X ?

<jab>grrr, guix shell for the hurd website is not working for me again...

<jab>sneek later tell youpi, hey samuel the amd64 README is slightly in correct in the losetup line.

<sneek>Got it.

<jab>sneek later tell youpi this is what I used that worked: " sudo losetup -o $((512*1955840)) /dev/loop0 debian-hurd*.img "

<sneek>Got it.

<jab>sneek later tell youpi, actually I couldn't figure it out. I do know that the 1953792 value that the README mentions here is incorrect. https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/YES_REALLY_README.txt

<sneek>Got it.

<jab>actually I think I did figure out how to resize my hurd qemu image.

<jab>I saw an input output error, so I assumed that I ran the commands wrong. But it was an io error for cd0

<jab``>well I guess I am going to copy the 64 bit hurd qemu image to a disk and try to boot from that disk.

<sneek>Welcome back jab``, you have 1 message!

<sneek>jab``, old says: for example, you can change where something will be installed, without having to mutating the object itself

<jab``>fingers crossed.

<jab``>well I officially have the hurd running on a T420 with 12 GB of RAM!

<jab``>that's awesome!

<jab``>i just need to grow the size of the filesystem

<azert>jab``: that’s great, does x11 work?

<jab``>I got x11 working in qemu. once I get the filesystem resized, I'll try it in real hardware.

<jab``>then I'll need to see if networking works.

<jab``>X works. i3 is pretty snappy. But networking is not working.

<jab``>Time to try rumpnet

<jab``>it is possibly that my filesystem corruption caused the networking issue...

<jab````>hmmm, I think these commands need to be as

<jab````>root

<jab````> https://darnassus.sceen.net/~hurd-web/hurd/rump/rumpnet/

<jab````>I don't know what's happening to my irc nick by the way.

<azert>jab: what is your nic network interface?

<azert>if it is the Intel PRO/1000, then I think that rumpnet is the right driver

<jab>pretty off topic, but did any of ya'll see the guile based build tool talk ? It's called BLUE, and it's fairly impressive what they have got going for it already.

<sneek>jab, you have 2 messages!

<sneek>jab, old says: that the BLUE build system tries to be purely functionnal as much as possible

<sneek>jab, old says: that BLUE wents a to great extent to be able to represent stateful data in a purely manner with delayed expressions. This allows changing the states in the REPL for example without doing any mutation

<Gooberpatrol66>is blue integrated with guix? like can it put build objects in the store?

<jab>Gooberpatrol66: that I don't know, but I'm sure that guix will create a BLUE build system at some point.

IRC channel logs

2026-02-18.log