IRC channel logs

<nexussfan>About audio about hurd; what about sndio? https://sndio.org/

<damo22>nexussfan: i have invested a lot of effort in ALSA, so i would prefer to reuse some of the low level code from that, but not all of it.

<nexussfan>okay

<damo22>i am trying to find time to write a JACK backend that provides just enough of ALSA to make a simple card function

<damo22>so the external audio API would be JACK to applications

<damo22>the problem is, Linux uses "struct device" for sound cards which is a very generic structure requiring a lot of boilerplate code

<damo22>so its very difficult to separate ALSA components from Linux and try to glue it into a userspace program

<azert>damo22: is your strategy viable? I have the impression that Linux drivers often use much of the Linux functionality and are not very portable

<rrq>I have difficulty getting nfs running on hurd-amd64...

<rrq> server at nfshost:/pathname (linux) ...

<rrq>trying: settrans /nfs/stubbe /hurd/nfs -s nfshost:/pathname

<rrq>seems to talk on the net

<rrq>but then hurd sends UDP to port 0 which of course fails

<rrq>am I missing some configuration?

<rrq>first 3 messages from hurd are to port 111, then the 4th is to port 0

<damo22>rrq: i *think* hurd supports nfsv3

<damo22>possibly not 4

<rrq>right, the server supposedly does both 3 and 4

<damo22>you can try forcing the server to use 3

<damo22>nfsd -V 3

<rrq>mmmm this is nfs-kernel-server (on devuan linux) .. maybe I can edit /etc/nfsd.conf

<damo22>rpc.nfsd

<damo22>rrq: /etc/default/nfs-kernel-server put RPCNFSDCOUNT="8 --no-nfs-version 4"

<damo22>then restart the nfsd service

<rrq>ok. trying that

<rrq>same result

<damo22>make sure it only supports 3 by trying to mount it with -o vers=4

<damo22>mount.nfs: Protocol not supported

<damo22>then hurd's nfs might have a version option too

<rrq>I wonder if it's my /etc/exports

<damo22>mount it from linux first

<rrq>mm.. yes I can mount v4 from another host (linux)

<rrq>ACTION biab ... thanks!

<rrq>so server is still v4

<damo22>did you restart it?

<damo22>with the new option

<rrq>yes ...

<damo22>if that is devuan it might be different instructions

<damo22>i dont know

<rrq>all nfs is debian

<damo22>basically you want the call to rpc.nfsd to include "--no-nfs-version 4"

<damo22>check your process list to see the command

<damo22>nfshost $ ps -ef|grep rpc.nfsd

<rrq>it's nfs-kernel-server=1:2.6.2-4+deb12u1 so no rpc.nfsd programs

<damo22>i think there are still userspace parts

<rrq>rpc.mountd and rpcbind

<damo22>rpcinfo |grep nfs

<rrq>3 lines like: 100003 3 tcp 0.0.0.0.8.1 nfs superuser

<rrq>then 3 the same but for ipv6

<rrq>hmm something timed out... now I could remove module nfsv4

<rrq>(with service stopped)

<damo22>how are you stopping/starting the service

<damo22>its not done with modprobe

<rrq>service nfs-kernel-server stop (start)

<rrq>but nfsv4 came back when linux host mounted

<damo22>i see

<damo22>could be a debian bug?

<damo22>that you cant stop 4

<damo22>anyway, might be worth stopping and starting it, then dont attempt mounting v4

<damo22>instead try mounting from hurd

<rrq>so I removed nfsv4 module again and tried from hurd; the module did not come back but still the port 0 udp

<damo22>i dont know how to set up vm with bridged network so i cant test

<rrq>I used vde2: vde option on qemu and a tap

<rrq>hmm I have 2 subhosts on the host that serves nfs; a linux and a hurd

<damo22>-s is for soft retries and takes a numeric parameter

<rrq>ah I understood that as optional

<damo22>try without that parameter

<rrq>"udp port 0 unreachable

<rrq>.. and hurd "hangs" .. (I have to -g from another terminal)

<rrq>nope .. have to ^C and wait :)

<damo22>ok -s is acceptable

<damo22>it defaults to 3

<rrq>does it help to see the handshake tcpdump-ed ?

<damo22>it would if someone was debugging it

<damo22>i cant delve that deep right now

<damo22>you could send that to the mailing list

<damo22>and describe the issue

<rrq>fair enough. thanks for your assistance

<gnu_srs1>Can somebody explain: /usr/include/i386-gnu/gnu/stubs.h:#define __stub_pthread_getcpuclockid, but

<gnu_srs1>/usr/include/i386-gnu/bits/time.h:# define CLOCK_THREAD_CPUTIME_ID 3, and sysdeps/htl/pt-getcpuclockid.c contains:

<gnu_srs1>int pthread_getcpuclockid (pthread_t thread, clockid_t *clock) {#ifdef CLOCK_THREAD_CPUTIME_ID *clock = CLOCK_THREAD_CPUTIME_ID; return 0;

<gnu_srs1>#else return ENOSYS; #endif } stub_warning (pthread_getcpuclockid)

<gnu_srs1>Compiling and calling pthread_getcpuclockid() prints out: warning: pthread_getcpuclockid is not implemented and will always fail

IRC channel logs

2025-12-20.log