IRC channel logs


back to list of logs

***Server sets mode: +nt
***rekado_ is now known as rekado
<gnu_srs1>youpi: Reverting gnumach to 28b53508aa4cd06933fa1bcbbaa791ad12ecbf51: Date: Tue Jan 28 00:48:58 2020 +0100 made hurd booting again :)
<gnu_srs1>Going forward in time now.
<gnu_srs1>Problems are probably some of the 64bit commits.
<damo22>gnu_srs1: are you using a debian system?
<gnu_srs1>damo22: No, everything is cross-compiled from tarballs.
<gnu_srs1>I use a Debian GNU/Linux system as host box, however.
<damo22>gnu_srs1: sounds difficult, any particular reason you do that when debian is already packaged?
<gnu_srs1>I was considering cross-compiling the Guix bootstrap tarballs (not needed now I believe).
<gnu_srs1>Additionally on could port SW requiring bootstrapping from itself like gpc, rust, etc.
<gnu_srs1>And other Hurd distros might benefit, like arch-hurd.
<damo22>i saw that guix can launch qemu and boot a bootstrapped system from scratch?
<damo22>is that a cross compiled bootstrap from scratch?
<gnu_srs1>I don't think Guix has a successful boot yet.
<damo22>but its planning to right?
<gnu_srs1>Yes they are. My cross-compilation is from scratch with git sources for hurd, gnumach and mig and tarballs for the rest.
<damo22>why dont you work together
<damo22>i mean its a pity to duplicate all that effort
<damo22>you probably already know a few tricks with the compilation that you can share with each other
<damo22>i dont know anything about guix but it seems like the recipes are well defined, and once you write one, you can share it
<damo22>instead of hand coding a bash script to compile a bunch of tarballs i guess :shrugs:
<youpi>gnu_srs1: perhaps try 00fe44e565d0ec292bb06a5677ee175cd0851a69
<youpi>which I'm sure have been tested
<rekado>with Guix we are currently stuck with ext2fs seemingly freezing on boot.
<rekado>I’ll try using our cross-built ext2fs in the Debian GNU/Hurd image to see which of the things isn’t working.
<rekado>(and the other way around may make sense to test, too)
<damo22>i am working on rump disk drivers
<gnu_srs1>As soon as the gnumach problems are solved, I'll try to get the scripts published at savannah under the Hurd group.
<rekado>damo22: rump is the future!
<civodul>rekado: janneke noticed that that our non-boot dynamically-linked ext2fs hangs similarly
<rekado>damo22: I’d love to get more rump drivers.
<damo22>rekado: are you aware of the underlying ext2fs translator needing a special flag in the dev node set to attach the translator?
<damo22>settrans etc
<rekado>janneke: rumpkernel, the NetBSD stuff that allows the Hurd to reuse NetBSD drivers.
<gnu_srs1>youpi: Version 00fe44e565d0ec292bb06a5677ee175cd0851a69 fails :(
<youpi>ok so use git bisect
<youpi>"Going forward in time now. " are you not using git bisect?
<damo22>rekado: i will make net and audio work after i get disk working
<youpi>for audio, remember that Robert did some work already, better base on it :)
<damo22>yeah im reusing his packages
<damo22>it probably already works
<youpi>also, we'd probably want to work on usb before network (since we already hvae network from netdde, it's less a priority)
<youpi>possibly, yes
<damo22>ok yes, usb
<youpi>probably needs some rework, iirc it's currently only a lib
<youpi>and not a translator
<damo22>i think usb will be easier than disk
<youpi>I wouldn't say that
<youpi>because we'll probably need to define a translator interface for that
<youpi>or perhaps just one translator that contains the USB drivers and expose a disk device interface
*janneke looks up from under their stone
<janneke>rekado: oh?
<gnu_srs1>youpi: Have to read man git-bisect
<damo22>janneke: dont worry, soon you will have a userspace disk driver
<youpi>gnu_srs1: a manual is not a tutorial, rather read a tutorial
<damo22>its working actually just not for /
<rekado>janneke: you may find this interesting:
<janneke>(...and a man-page is not a manual ;-)
<janneke>rekado: tnx!
<rekado>janneke: and this is what I was actually looking for:
*janneke build another guix image, now with all debian-hurd tarballs&patches
<rekado>lots of details on how rumpkernel and hurd can be joined
<youpi>janneke: in the sense I know "manual", it is
<youpi>i.e. the details of what option is there, what it does etc.
<youpi>but surely not an introductio nindeed
<janneke>youpi: i'm just GNU-trolling
*janneke likes info pages much better :-)
<youpi>rekado: is that report linked from the wiki?
<youpi>sure, info pages are meant to be introductive
<rekado>I didn’t find it on the wiki
<youpi>then please add it at a proper place
<rekado>I had it downloaded a long time ago and searched the title in DDG
<rekado>will do
<damo22>building rumpkernel was tedious but robert did a good job packaging most of it
<damo22>i noticed all the copyright notices were added to the deb package
<damo22>that would have taken ages to compile
<damo22>i mean just the list of copyrights
<damo22>ive kept all that but updated the rumpkernel package to latest upstream
<damo22>the userspace pci component needed a fair bit of work, im glad its mostly all working now
<janneke>civodul: aaargh! /exactly/ the same result: "start ext2fs: " <hang>
*janneke is going to try all gnumach patches too
<youpi>note that this hang is not uncommon
<youpi>it seems there is a race in the bootstrap there
<youpi>try to just reboot
<youpi>sometimes I have to retry a few times
<damo22>ive also seen this when my fs was prepared externally by linux
<damo22>something related to the translators not being settrans'd
<janneke>youpi: hmm, okay! (i haven't seen this before using the debian image in the topic)
<civodul>janneke: this one's 100% reproducible though, and not just for the bootstrap ext2
<civodul>so there must be something :-)
<janneke>yes; could still be something in patched mach headers that expand to wrong code
<janneke>pretty weird
<damo22>i had an issue where there were stale .defs files lying around in the build tree
<damo22>overriding the mig stuff
***bpsecret- is now known as bpsecret
<damo22>is there a channel for offtopic chatter?
<youpi>gnu_srs1: how do you call ./configure for gnumach?
<youpi>damo22: not that I know of
<damo22>im feeling very isolated... :( i worked a week from home and hardly spoke to a soul
<youpi>well, chatter is welcome here when there is no technical discussion going on :)
<youpi>I don't remember your situation, are you a student?
<damo22>i used to be, now im a fully fledged worker
<damo22>been working for 3 years in the same job
<youpi>are you freelance?
<damo22>im an employee at a hospital
<youpi>so you don't really have colleagues in your IT department I guess?
<damo22>i work in bioinformatics, not really IT
<damo22>but i do have ppl
<damo22>theyre also working from home
<youpi>in our research team we had a virtual apero yesterday evening
<youpi>I don't know what the proper english word would be
<youpi>having snacks & beers and chatting
<damo22>i like to work on hurd because i feel it is a good goal to complete a GPLv3 OS
<damo22>i also have grown to like a microkernel model instead of monolithic
<youpi>the provided flexibility really is nifty yes
<damo22>also, theres less baggage i find with hurd than say the linux based systems i have used
<youpi>which kind of baggage do you think of?
<damo22>systemd monolith
<damo22>theyre the main ones i dont like
<damo22>i mean tagging files with security metadata might not be a bad idea, but i dont like how it is managed
<damo22>i really dont like pulseaudio
<youpi>fortunately pipewire is coming :)
<damo22>if it is based on ALSA, i fear it wont be much better
<damo22>coreaudio is a superior system
<youpi>it is based on alsa, but done by multimedia people
<youpi>unlike pulseaudio
<damo22>you can request different quality buffers with different expected latencies from coreaudio and simultaneously align two clocks from two sound cards to make an aggregate
<damo22>ALSA cannot do this
<damo22> <--- i think i posted this before, we made a list of all the things we need to fix
<damo22>but even pipewire devs cant fix this
<damo22>i think we have a chance of fixing it in hurd, because its not monolithically tied to the kernel
<damo22>basically audio on GNU is screwed unless someone fixes it
<gnu_srs1>youpi: configure --build=x86_64-linux-gnu --host=i686 -pc-gnu --enable-kdb --enable-kmsg --enable-pae --prefix=/tools
<damo22>because the lowest level needs work
<youpi>gnu_srs1: try without --enable-pae
<youpi>possibly I broke that variant
<youpi>yes, with enable-pae it doesn't boot, I'll have a look
<youpi>in the meanwhile you can avoid --enable-pae, that'll just limit your memory to 1GB
<gnu_srs1>I'm bisecting now. BBL
<gnu_srs1>youpi: After bisecting: 0b3504b6db86c531e8b53b8e9aa9030db6e72357 is the first bad commit, see
<civodul>youpi: with the Guix-built binaries, the page fault of ext2fs in disk_cache_init is not serviced
<civodul>the thing just hangs, as if the pager never got a message
<janneke>civodul: ah, that dereference is supposed to communicate by page-fault?
<civodul>janneke: yes, it's supposed to trigger a page fault, AIUI
<civodul>and that page fault is supposed to be served by ext2fs' pager
<rekado>damo22: oh, another bioinfo person!
*rekado works for a bioinfo research group
<user_oreloznog>rekado: cool :-)
<youpi>gnu_srs1: I believe I have fixed the issue with PIE
<youpi>the bisect was indeed very useful