IRC channel logs

<rrq>anubis is javascript mostly and runs on/in the browser; plus some the server side stub inserted "before" actual service.

<rrq>it acts against bots primarily on the idea that they don't run client side javascript.

<damo22>i heard google was going to convert recaptchas into QR codes that only verify on google approved devices

<damo22>wouldnt that break most of the internet for forms?

<damo22>whitekiba: how are you going with smp review?

<rrq>I'm using gnumach-image-1.8-amd64-smp in qemu, but with "-smp 1" (as it locks up otherwise) ... I could run with remote gdb but I'm too much in the dark about how to get something out of that; I guess I'd need actual source and symbol map or something

<damo22>yeah, that is expected

<rrq>hmmm as is, it does compile mig, gnumach and hurd (if slowly) so I guess I might be able to compile that particular commit, and share that to the (outside) gdb controller

<damo22>whitekiba has apparently fixed smp with LLM assistance. I would like to read the patches

<rrq>is there a repeatable test case?

<damo22>yeah the qemu test suite?

<damo22>it passes on i386 smp but fails on x86_64 smp i think

<damo22>i cant remember

<rrq>test suite for building gnumach?

<rrq>or building hurd?

<damo22> https://code.zammit.org/damo22/gnumach-sv/actions/runs/78/jobs/0/attempt/1

<damo22>that was the last time i tested master properly

<damo22>i should make it auto run when savannah is pushed

<rrq>mmm test suite form building gnumach 32-bit? or you mean testing 32bit building of gnumach 32bit vs 64bit building of gnumach 64bit ?

<rrq>my first lockup (wiht -smp 4) was during "apt-get update", after all packages being downloaded

<rrq>I would want a test case of gnumach locking up; too much to investigate all possible user code

<damo22>test suite builds and then executes gnumach in qemu

<damo22>for many combinations of compile flags

<damo22>with some basic test cases run in userspace

<rrq>hmm I wonder if my qemu setup works recursively

<damo22>i ported qemu to hurd, i wonder if its upstream yet

<rrq>isn't that my gnumach-image-1.8-amd64-smp 2:1.8+git20260224-9 ?

<rrq>sorry

<rrq>too early :)

<rrq>no, I can't see it with apt-cache

<rrq>there's "virtme - Helper scripts to test kernel code on qemu" ... could maybe be patched to use a sibling qemu (?)

<rrq>or I can just run the tests in my hurd-amd64 qemu ?

<rrq>first, with smp=1, configure the repo and compile the test programs, then try running them with smp=4

<rrq>"the repo" = "my workspace"

<rrq>(I'll give it a go when my cat permits...)

<damo22>rrq: see pm

<rrq>trying autoconf in gnumach (workspace) I get some errors: "undefined or overquoted macro" ... do I just ignore those?

<rrq>(tag v1.8+git20260224)

<rrq>asch ignore those.. pebkac

<rrq>damo22: is it possible to run the gnumach tests within the hurd-amd64 I have?

<rrq>.. well asuming I start it up with smp=4 or something

<damo22>you need qemu with my patches

<damo22>so you can run qemu inside hurd

<damo22>x86_64-linux-gnu-gcc -ftrivial-auto-var-init=pattern -static -nostartfiles -nolibc -ffreestanding -I../tests/include -I./tests/include-mach//include -I./tests/mig-out -ggdb3 -DMIG_EOPNOTSUPP -fno-stack-protector ../tests/test-hello.c ../i386/i386/strings.c ../kern/printf.c ../kern/strings.c ../util/atoi.c ../tests/syscalls.S ../tests/start.S ../tests/testlib.c ../tests/testlib_thread_start.c ./tests/errlist.c ./tests/mig-out/device.user.c

<damo22>./tests/mig-out/device_reply.user.c ./tests/mig-out/device_request.user.c ./tests/mig-out/mach_debug.user.c ./tests/mig-out/exc.server.c ./tests/mig-out/gnumach.user.c ./tests/mig-out/mach4.user.c ./tests/mig-out/mach.user.c ./tests/mig-out/mach_host.user.c ./tests/mig-out/mach_port.user.c ./tests/mig-out/task_notify.server.c ./tests/mig-out/mach_i386.user.c -o tests/module-hello

<damo22>In file included from ../tests/test-hello.c:19:

<damo22>../tests/include/testlib.h:30:10: fatal error: string.h: No such file or directory

<damo22> 30 | #include <string.h> // we shouldn't include this from gcc, but it seems to be ok

<damo22> | ^~~~~~~~~~

<damo22>compilation terminated.

<damo22>i am trying to cross compile gnumach from riscv -> x86_64

<damo22>i can compile gnumach but the test suite wont compile

<rrq>I would have preferred just compiling the tests :( then run manually

<damo22>rrq: see .forgejo/workflows/action.yaml there is a script that does exactly that in the CI

<rrq>mmm not sure how to interpret that one

<damo22>did you find the script?

<rrq>yes

<damo22>ok

<damo22>it does make gnumach.gz and then make VERBOSE=true check

<damo22>thats all you have to do to execute all the tests

<rrq>yes, when I "make check" it creates bootable isos for running the tests then removes them

<damo22>yea but do you have qemu installed?

<rrq>no I want to build and run a test :)

<rrq>not a qemu with a test

<damo22>?

<damo22>it needs to boot the iso to run the test

<rrq>hmm it tests the boot up?

<damo22>yes it boots gnumach that you just compiled with the test harness

<damo22>the point is to run a check against the kernel per commit

<rrq>I have a running qemu; can't I just run the test program in that?

<damo22>the test program is useless without the right kernel

<damo22>what would you be testing?

<rrq>I thought to test this kernel

<damo22>well it needs to boot the iso with the test in it, before anything else runs

<damo22>and the gnumach kernel from that commit

<damo22>are you compiling gnumach inside hurd or on linux?

<rrq>I'm running gnumach-image-1.8-amd64-smp=2:1.8+git20260224-9, with smp=1, and compile in that as well

<rrq>this time I compiled that commit

<damo22>ok so you need to install qemu inside hurd

<damo22>and run a nested gnumach iso

<damo22>test

<rrq>that's the restriction I don't understand

<damo22>or you can copy the kernel you compiled in hurd up to the host, then run the test as a qemu

<damo22>but you need the iso

<damo22>its easier if its executed from the same build directory

<damo22>because its supposed to be "make check"

<rrq>right; so no intermediate target for building the actual test program

<damo22>the tests are designed to call qemu from the same machine as the built kernel

<damo22>you can do that from hurd or from the linux host

<damo22>but you need qemu in both cases

<rrq>think I found it: "make tests/module-hello" makes the "hello" test program

<damo22>i think you can do make debug-hello

<rrq>no; that removes it all (since I haven't installed qemu)

<rrq>but the intermediate target tests/module-hello leaves it there

<rrq>there are a couple of warnings in the libkernel.a building

<rrq>nothing serious

<rrq>hmm test/module-hello doesn't run (an ELF 64-bit LSB executable)

<damo22>i think it needs to be loaded as a grub module?

<damo22>you cant just run it on a hurd userspace

<damo22>thats why you need the iso

<rrq>interesting; I installed gdb to check, and it actually breaks in _start on setting up argc

<rrq>in testlib.c

<rrq>in c_start, called from _start

<rrq>ok; I guess gnumach provides %rsp on entry for the modules ... differently from "user mode" execution

<rrq>fair enough

<saravia_>hi, excuse me, some recomendation of an irc for share scripting and programs xD!!

<saravia>the gentoo version is stable?

<sam_>please stop posting this stuff in random channels

<saravia>sam_: sorry, am I making a mistake?

<sam_>youv'e been posting non-sequiturs for the last few hours in various channels and not replying to any responses

<sam_>i don't know why

<saravia>for example which one?

<mlxdy>saravia_: "hi, excuse me, some recomendation of an irc for share scripting and programs xD!!"

<mlxdy>I also saw that

IRC channel logs

2026-06-14.log