IRC channel logs
2019-12-01.log
back to list of logs
***Server sets mode: +nt
<damo22>does anyone have a link to the custom mplayer that has rump audio support? i lost ir <gnu_srs1>Hello, can I set passive translators from within Linux? There are no fsysopts/settrans binaries in Linux available. <gnu_srs1>Same problem with creating /dev files: no settrans <swivel>gnu_srs1: I don't understand, Linux is not Hurd <swivel>nothing requiring hurd kernel interfaces will work on linux afiak <youpi>gnu_srs1, swivel: nowadays hurd uses an xattr to set translators <youpi>so that can be done on linux too <gnu_srs1>youpi: Hello, can I set passive translators from within Linux? <youpi>damo22: could you create yourself a -guest account on salsa.debian.org? <gnu_srs1>youpi: When cross-compiling I used git for gnumach and hurd, and glibc-2.30. I used patches: tg-mach-hurd-link.diff and tg-hurdsig-SA_SIGINFO.diff (had to modify it to make it apply) <gnu_srs1>The cross built hurd did not boot. The I found that glibc.git-0b262ca4c64cd9042576ddb9969607c0ea1187d7.patch was not available to glibc-2.30 from <gnu_srs1>Nevertheless, applying it and rebuilding still did not create a bootable Hurd image. <youpi>gnu_srs1: we don't keep 2.29 and 2.30 branches in sync all the time <gnu_srs1>Perhaps using glibc-2.29 or git upstream directly would be better? <youpi>we just pull from 2.29 into 2.30 on e.g. upload <youpi>possibly 2.29 has less problems <youpi>but I don't think anybody tested booting <youpi>so probably some upstreaming is missing <gnu_srs1>All cross-built packages are using upstream versions, no Debian patches, except for glibc. <gnu_srs1>So, what's best: Build glibc-2.30 and try booting with that on a Debian/ image? <youpi>don't try to mix hand-built libc and a Debian system, that's complex to get working properly <gnu_srs1>Or debug the failed cross-built boot of hurd? <youpi>but what you can do is to copy your ext2fs.static into a Debian system <youpi>so that Debian itself will use the Debian libc, and only ext2fs.Static will use your libc <youpi>thus you'll have only one thing to debug <gnu_srs1>I think the file record locking patches need to be in glibc as well as in hurd? <youpi>gnu_srs1: both upstream and debian have compataibility support <gnu_srs1>OK, I'll try to boot a debian image with the cross-built ext2fs.static using 2.30. BBL <youpi>btw, "did not boot" is way not precise enough for anybody to have any advice to give <gnu_srs1>I've already pasted output and code to paste.debian.org <youpi>that hasn't reached irc it seems <gnu_srs1>Probably gone by now. I'll create new pastes. <gnu_srs1>Have to create a new image with serial output though. <gnu_srs1>But then I cannot get into the debugger with C-A-d <youpi>it does work on my serial console <youpi>ah, so it does start booting <youpi>it looks like it just doesn't find the fsysopts command? <gnu_srs1>I edited runsystem in different ways. Seems like something hangs: (18:39:57) srs: show all threads give me 7 tasks, each having more than one thread: gnumach, ext2fs, exec, /hurd/startup, /hurd/proc, /hurd/auth, /hurd/term(9) <youpi>you could make runsystem just start a shell, to debug what is working and what is not working <youpi>not surprising: the script is made to abort if it fails in any way, so if a command fails, then nothing is running any more <youpi>just put /bin/bash in the script, before the last command that seems to be failing <gnu_srs1>Ok, I have now a bash prompt. What's next? <gnu_srs1>ls resulted in: normal output, then /libexec/runsystem: line 60: 10 segmentation fault /bin/bash