IRC channel logs

<damo22>i just emailed the rump guru to see if he approves my build script patch

<damo22>once it's upstreamed into netbsd i can work on upgrading our rump

<damo22>Pellescours: did you end up building more rump

*enyc meows

<damo22>i wish rust didnt change so much

<damo22>i almost got it to build on 1.29 but thats ancient now

<Pellescours>damo22: i tried but it's hard

<Pellescours>i'm able to use headers in src/sys

<Pellescours>(doing this is not tge proper way but it's working)

<Pellescours>but then i'm stuck when building pci-userspace

<Pellescours>I don't know how to build it without buildrump.sh

<Pellescours>and otherwise autotools have problem to detect rump/rump.h it detect it but when verifying that it builds it fails due tu register_t redefinition

<Pellescours>the header changed a bumit in this part and we have to define some variable before includong the header to prevent the redefinition

<zamfofex>Hello, everyone! I have decided to continue my Guix/Hurd/networking pursuits. Last time, I was facing a problem with multiple definitions of some struct. I think it was introduced by the latest commit to dde_net, so i just picked the previous commit, and it seems to have stopped complaining about it!

<zamfofex>Now it seems like the “pci-arbiter/main.c” file (which seems required by netdde) is a bit outdated, because it calls the function “machdev_trivfs_init” with arguments, whereas it seems to have been refactored to accept none.

<zamfofex>The question I have is (hopefully) pretty simple: Is it sufficient to patch the file to remove the arguments, or is there now a different way to pass in those values?

<youpi>zamfofex: I don't understand. In the hurd repository, pci-arbiter/main.c: machdev_trivfs_init (argc, argv, next_task, "pci", NULL /* _SERVERS_BUS "pci" */, &bootstrap); just follows the prototype of libmachdev/machdev.h:int machdev_trivfs_init(int argc, char **argv, mach_port_t bootstrap_resume_task, const char *name, const char *path, mach_port_t *bootstrap);

<zamfofex>youpi: You are right, I misread the diff of commit 9049b963b6023ef6d7bd3f8c81ef5ab1f3b43fd3. But the build error message is strange, then, because it tells me that both the ‘machdev_trivfs_init’ and the ‘machdev_trivfs_server’ should take no arguments, whereas ‘pci-arbiter/main.c’ does call them with arguments.

<zamfofex>See: https://paste.debian.net/plainh/a0e91892

<youpi>../libmachdev/machdev.h:36:5: note: declared here

<youpi> int machdev_trivfs_init(void);

<youpi>is that file really so?

<youpi>it's not so in the git repo

<zamfofex>I could verify. I’m not sure about how familiar you are with Guix, but the builds are performed in containers, so it’s not possible for me to have set up the files wrong manually. I have to use the ‘-K’ flag so that it allows me to see the files after a failed build.

<zamfofex>youpi: This is how the file looks: https://paste.debian.net/plainh/1c33a9e5

<youpi>that file hasn't been so in the hurd git repo since july 2020 ?

<zamfofex>That’s strange, I think. Specially so because the ‘pci-arbitrer/main.c’ file seems to be updated.

<zamfofex>I think I found the problem: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/hurd.scm#n370 It seems it copies the files from the “dde” branch of the “incubator” repo before trying to run the build. But it seems the files from “incubator/dde” are outdated!

<zamfofex>It copies the files from only three directories, it seems, “libmachdev”, “libmachdevdde” and “libddekit”.

<youpi>libmachdev has been integrated, no need to copy it over

<zamfofex>youpi: I wanted to mention that I was eventually able to build a Hurd image! My packages are a month outdated, so I’m going to update them and try to generate another one before trying it out, though, but I feel like I am hopefuly it will work well! Thanks for your help!

<youpi>good :)

<zamfofex>I wanted to mention that I still can’t get the netdde thingie to work! I’m still getting the same error as last year, where it tells me “translator died”. I verified the channel logs, and the error matched pretty much one to one as back then.

<youpi>did you try to run it by hand with settrans -a /dev/netdde /hurd/netdde

<youpi>?

<youpi>("translator died" is not informative, it just tells that netdde quit)

<zamfofex>Yes, I did pretty much the exact thing I had done last time. I wrote ‘settrans -fga /dev/netdde "$(which netdde)"’, and got the same error as last time: ‘vm_allocate_contiguous: (ipc/mig) bad request message ID’

<zamfofex>See: https://logs.guix.gnu.org/hurd/2020-10-16.log and https://logs.guix.gnu.org/hurd/2020-10-17.log

<youpi>$(which netdde) ?

<youpi>do you have netdde in your PATH ?

<zamfofex>Yes.

<youpi>about vm_allocate_contiguous, do you have an up to date gnumach?

<zamfofex>I haven’t updated the gnumach version, no, only the ‘hurd’ and ‘netdde’ packages. It seems Guix currently uses commit 097f9cf735ffa1212b828682ad92f0f6c5f1c552 for gnumach.

<zamfofex>Do you feel like that could be the reason for my issues?

<youpi>bad request message ID means the server side of the RPC doesn't know about the rpc

<youpi>so it really just looks like a version of gnumach that simply doesn't know about the RPC

<zamfofex>Yeah, it seems the aforementioned commit is from November of 2019. (!!!)

<zamfofex>So it’s fairly outdated.

<zamfofex>I think imma keep trying tomorrow, or maybe on Monday. youpi: Thank you for the help once again, by the way! I really appreciate it.

IRC channel logs

2021-09-18.log