IRC channel logs

<gnucode>afternoon

<sneek>nexussfan: Greetings!

<gnucode>nexussfan: what are you porting today ?

<nexussfan>nothing yet

<nexussfan>i may try to do icecat

<Alicia>I'm also poking at icecat but I don't really know what I'm doing with it

<nexussfan>it seems like buildicecat just makes an icecat source

<nexussfan>doesn't compile it

<Alicia>yeah

<gnucode>hmmm.

<Alicia>from my notes so far: in python/mozbuild/mozbuild/configure/constants.py add GNU as a kernel option, and __GNU__ for kernel_preprocessor_checks

<Alicia>and configure with --enable-audio-backends="oss" (default is pulseaudio, but we don't have that, I think)

<nexussfan>we don't have any real sound right now

<nexussfan>rumpaudio works but it's a bit broken

<gnucode>did you get rumpaudio to work on real hardware?

<Alicia>yep, "oss" just lets it continue without errors :)

<gnucode>also are we calling it rumpaudio or rumpsound ?

<nexussfan>no, i got a /hurd/crash

<nexussfan>wish pypy2 was still packaged :(

<Alicia>right now I'm stuck at it trying to find a rustc target, and rustc has x86_64-unknown-hurd-gnu but icecat's configure fails to find it. it shows x86_64-unknown-gnu0.9 as the host triplet, which I'm guessing is part of the problem

<nexussfan>oh yeah

<nexussfan>i remember that issue

<nexussfan>normally unix-like systems show something like linux7 for the linuxkernel version 7

<nexussfan>but for some reasons they did like "if os startswith(linux) then return linux"

<nexussfan>but no exception for hurd

<youpi>Alicia: yes, llvm/rust insist on having different names from the gnu ones

<youpi>so there needs to be some translation

<youpi>in whatever takes the gnu triplet and gives that as target to rustc

<nexussfan>annoying

<Alicia>nothing is giving the triplet to rustc yet. it gets a list from rustc --print target-list and then I guess narrows it down somehow. haven't found where hurd-gnu disappears yet

<nexussfan>rustc print target-list just shows all of the targets that the rustc supports

<Alicia>yes

<nexussfan>not sure if there is a way to get the current target in rustc

<Alicia>( build/moz.configure/rust.configure seems to be where this happens)

<youpi>rustc --print host-tuple

<youpi>?

<Alicia>oh! that fixed it (maybe not a proper fix, but it went further) by adding these two lines at the beginning of def detect_rustc_target: out = check_cmd_output("rustc", "--print", "host-tuple").splitlines() next line: return out[0]

<nexussfan>looks right

<Alicia>it looks... too simple, compared to the length of the original function

<nexussfan>how is it going now? :D

<Alicia>so far so good. was missing some dependencies but was able to install them. taking a break to try to generate a patch file of my changes so far

<nexussfan>sounds right

<nexussfan>maybe you can send it to https://lists.gnu.org/mailman/listinfo/gnuzilla-dev

<Alicia>I will look into it later

<Alicia>these are the changes so far: https://ion.nu/tmp/icecat.patch

<nexussfan>pretty short so far

<youpi>Rust's --target options are similar to, but not exactly the same

<youpi> # as, the autoconf-derived targets we use.

<youpi>see that comment

<youpi>i.e. it's taking host_or_target

<youpi>and then fixing the gnu-to-rust details

<youpi>(it's indeed not just host-tuple that you want, when cross-compiling icecat)

<Alicia>yeah

<Alicia>apparently it depends on nodejs which is not available in the repository

<nexussfan>Sad :(

<Alicia>just another step on the path :)

<nexussfan>Cant wait for rms using hurd :D

<gnucode>he would probably only use debian GNU/hurd if it was one of the FSF approved distros...

<nexussfan>guix/hurd exists

<nexussfan>he uses trisquel though

<gnucode>guix/hurd is cool, but only has 300 some packages at the moment...

<nexussfan>yeah

<nexussfan>where's the source for the coreboot vesa console for hurd?

<nexussfan>graphics driver

<damo22>it basically doesnt have one, it reuses the existing framebuffer exported by the bios

<nexussfan>oh

<damo22>multiboot ifno

<damo22>info

<nexussfan>so how come X doesn't work then? if it uses the existing fb

<damo22>oh you mean coreboot

<nexussfan>yes

<damo22>sorry

<damo22>its in src/drivers i think

<nexussfan>src?

<damo22> https://code.zammit.org/damo22/coreboot/src/branch/vesa-vbe-passthru

<nexussfan>k

<damo22>i added something in that branch its not upstream yet

<nexussfan>does that work with hurd xorg?

<damo22>i dont know

<nexussfan>alright

<damo22>its missing the TODO section

<damo22>in the commit message

<damo22>but even without my changes, you could compile a coreboot rom with VBE_LINEAR_FRAMEBUFFER enabled on some platforms i think instead of VGA_TEXT_FRAMEBUFFER

<damo22>it might work instead

<Alicia>I tried adding more RAM to my 64bit debian hurd VM and started getting weird issues (I/O errors at 4-8GB, full bootloop at 20GB, two lines printed then back to grub)

<Alicia>is this a known issue? and is it the same on real hardware?

<sam_>[01:42] <Alicia> apparently it depends on nodejs which is not available in the repository

<sam_>I believe you can precompile these bits from e.g. linux and then provide it, which should help to begin with

<sam_>i think someone also recently hacked it to work with quickjs instead of nodejs

<sam_>(to make it work on sparc)

<nexussfan>ah

<nexussfan>maybe that works

<sam_>let me find it

<Alicia>oh neat (I'm unfamiliar with quickjs though)

<Alicia>I prefer to compile natively if I can accomplish it

<nexussfan>yeah

<nexussfan>native compiling is always nice

<sam_> https://bugzilla.mozilla.org/show_bug.cgi?id=1482433#c13 -> https://github.com/sparclinux/issues/issues/59 (where cbmuser ended up having it working)

<nexussfan> https://github.com/mozilla-firefox/firefox/compare/main...andrieshiemstra:firefox:main

<Alicia>nexussfan: btw have you tried 64bit Hurd on real hardware? I ran into weird issues when I tried to increase my VM's RAM to 4GB or higher, wondering if it's a qemu-specific issue

<Alicia>(I/O errors at 4-8GB, full bootloop at 20GB, two lines printed then back to grub)

<nexussfan>i've tried the x86_64 hurd on real hardware

<nexussfan>it works perfectly

<nexussfan>even the SMP

<Alicia>and I'm guessing it's not <4GB RAM?

<nexussfan>8GB ram

<Alicia>ah

<Alicia>I switched to 32bit to be able to have a little more RAM. didn't have any luck with compiling nodejs (which I think ate all my ram on 64bit), but the quickjs patch seems to work, together without the 'node' wrapper from https://github.com/sparclinux/issues/issues/59#issuecomment-3694685366 which was needed to get past configure (of course the proper fix would be to make configure look for quickjs)

<Alicia>currently stuck on networking issues in the multiprocessing python module used by ipc/ipdl/ipdl.py

<Alicia>together with*

<Alicia>Commenting out setsockopt on line 605 of /usr/lib/python3.13/multiprocessing/connection.py gets a little further, but then there are more issues with socket connections missing an address. not sure where the address is supposed to come from yet

<sam_>excellent

<Alicia>ah, with -M q35 64bit boots with 4GB RAM, but 20GB still bootloops

<Alicia>10GB works

<Alicia>16GB works. that should be enough for now :)

<Alicia>sneek: later tell gnucode I think I found the -M q35 thing, it only happens for 4+GB of RAM. But I imagine it's not specific to rumpdisk because when I tried for 20GB it quickly bootloops back to grub, with or without -M q35

<sneek>Got it.

<Alicia>oh, icecat's configure also has a --disable-nodejs option, sidestepping the whole need to patch in support for quickjs

<nexussfan>Nice

IRC channel logs

2026-03-15.log