IRC channel logs

<gasc>Hey guuys, just trying to be sure I'm working on the usb drivers on the correct manner accourdlying to the Hurd and/or Mach design, is there any reference material for what is the current aim?

<gasc>I will have to logout, but I will read the logs, thanks in advance

<gnucode>gasc the best way to work on the usb drivers is using rump stuff.

<gnucode> http://hurd.ion.nu/hurd/rump/rumpusbdisk.html

<gnucode>damo22: is the expert on this subject

<gnucode>it would be a good idea to just document how to use a usb stick on the Hurd. rumpusbdisk is your best bet...

<damo22>there is no point reinventing a usb stack from scratch, when there is rump

<damo22>im not an expert

<damo22>i just plugged things together and made a monolithic usb driver

<damo22>i was working on splitting the stack using ugenhc/ugen

<damo22>from memory i ran into a small issue that blocked me

<damo22>/dev/ugen would not appear in the rump /dev

<damo22>youpi: FYI https://code.zammit.org/damo22/gnumach is a mirror of upstream savannah and syncs every 10 minutes and does a CI build if any new commits

<damo22>this could be useful for you in particular to know if anything you pushed broke anything within 15 minutes

<youpi>the result should probably be sent to the commit mailing list

<damo22>i dont have a smtp server available to send mail from cli

<damo22>the one i actually use to send patches is a proton mail bridge, but its not something i can set up easily

<damo22>its thanks to rrq that we have a CI host with 14 cores

<damo22>if golang 1.25 was ported to riscv64 i could add another host with 8 cores

<rrq>using hurd-amd64 with gnumach-1.8-amd64-smp.gz I get SIGTRAP in "sleep" (in mach_msg, calling 0x0000000001094c2c of libc.s0.0.3) ... is that something to follow up?

<rrq>trapped instruction is "ret" after preceding "syscall" with %rax = $0xffffffffffffffe7

<rrq>non-informed observation is that the syscall left the stack in a mess

<rrq>repeatable error

<gnucode>I'll find a spot to document some stuff about the CI on the wiki.

<damo22>please dont document the CI before its fully set up

<gnucode>ok. Just ping me when it's fully set up and documented.

<gnucode>sorry...

<gnucode>meant to say when it's fully set up. Maybe CC on the email that you send to your email to bug-hurd introduction the Hurd's CI, and I'll translate your email into documentation.

<gnucode>wow...that made no sense...let me try again.

<gnucode>when the CI is fully set up, and you send an announcement to bug-hurd for it...then I'll translate that email into wiki documentation.

<damo22>youpi: does the hurd installer have a text based version that can be easily automated with simple keypresses?

<damo22>qemu wants me to write a CI test harness that installs hurd into a vm and then executes their tests

<damo22>it may be useful so they can run the CI themselves and ensure hurd port does not rot

<Gooberpatrol66>the guix installer is text based and it has hurd as an option

<sneek>Gooberpatrol66, you have 1 message!

<sneek>Gooberpatrol66, gasc says: I have tried the 8gen intel (i3 and i5) read the logs of the chat. I will look more deeply on the machines that at least boot. Debian Hurd Netinst iso tested.

<youpi>damo22: there's the serial version that is probably the simplest to drive (we used to have CI on the debian jenkins, using that)

<youpi>and you can use the text debconf frontend, which is simple text question/answer

<damo22>ok

<jab>afternoon friends!

<gnucode>howdy friends!

<jab>gentle reminder that I'll be sending in the Qoth Q2 this week, so be sure to get your feature in if you want to be on the qoth.

IRC channel logs

2026-06-21.log