IRC channel logs

<spk121>today I added a hurd x64 VM to my CI on github. So now I am test-building a program on hurd along with linux and bsd. I'm pleased

<sneek>Welcome back spk121, you have 1 message!

<sneek>spk121, janneke says: hmm did you remove "kill" for mingw, how would i kill my daemon that wrote a pid file, can't we get kill back ;-)?

<spk121>lol. this sneek msg from janneke must be ancient. I've been offline for months

<janneke>and in an interesting channel too

<etno>sneek has the memory of an elephant

<etno>sneek: botsnack

<sneek>:)

<etno>I would be curious to see the timestamps of messages people never reclaimed

<ahoka>Wait, kill was removed from mingw?

<ahoka>I've been gone too long

<spk121>Well, for the record, the kill command in Guile's mingw port was removed because they decided to use the posix_spawn gnulib module as the basic process abstraction, which broke the mingw port's custom PID table code

<diegonc>o/

<diegonc>crap, gnumach FTBFS :(

<diegonc>I guess its bisect time hehe

<etno>Maybe we could use damo's build env to do sanity-check on the incoming commits ?

<etno>When the maintainers team (yeah, I know...) accepts a patch, then it is pushed to a branch ahead of master, and once everything is green, master is fastforwarded.

<diegonc>that would be cool, indeed!

<etno>I would be willing to contribute resources to such build/test system if needed.

<diegonc>I wonder if that would mean moving away of the email worflow for patches

<diegonc>*from (and many more, that doesn't compile in english haha)

<etno>This part doesn't have to change with what I propose.

<diegonc>bisect session ended, patch sent \o/

<diegonc>BTW, what's the difference between a simple_lock and a simple_lock_irq?

<diegonc>and why panic_lock is one (irq flavoured) an not the other?

<diegonc>nevermind, the irq one disables interrupts

<diegonc>I need to google before asking :P

<youpi>diegonc: see the start of kern/lock.h

IRC channel logs

2026-04-11.log