IRC channel logs


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
<gnu_srs1>I'm cross-compiling...
<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
<youpi>(at least it's supposed to)
<gnu_srs1>youpi: Hello, can I set passive translators from within Linux?
<youpi>like I said above
<youpi>I don't know more
<youpi>damo22: could you create yourself a -guest account on
<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>debian git, why?
<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>2.30 should be fine
<youpi>possibly 2.29 has less problems
<gnu_srs1>Which Debian patches are really needed?
<youpi>normally, none
<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
<youpi>that hasn't reached irc it seems
<youpi>they seem to have expired
<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>? that should be working
<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)
<gnu_srs1>The only running process is gnumach.
<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
<gnu_srs1>I even tried init=/bin/bash
<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
<gnu_srs1>and a hang