***Server sets mode: +nt
***Out`Of`Control is now known as Viper
***rekado_ is now known as rekado
***apteryx is now known as Guest44796
<gnu_srs1>youpi: Is there some easy way to uninstall glibc files installed by make install? I have not found such targets in the sources. <youpi>gnu_srs1: I don't know about an uninstall target in glibc <youpi>if that was at the / of your system, you probably don't want to do it since that'd remove your libc <gnu_srs1>When cross-compiling all other packages should be built before glibc. Building these package after glibc confuses the inclusion of header files. <gnu_srs1>Further which packages are needed to get networking, netdde, etc? <youpi>networking: hurd & netdde, and their dependencies, e.g. libpciaccess etc. <youpi>I don't see which inclusion of header files would be confused <youpi>perhpas have a look at the rebootstrap script from helmut <youpi>(helmutg/rebootstrap on salsa.debian.org) <youpi>in particular, see what's before $LIBC_NAME stage1 cross build <youpi>which is the first glibc build (after gcc/binutils/gnumach headers) <youpi>I'm however surprised: isn't this bootstrap thing documented in a shared place? <youpi>it looks to me like both you are guix people are re-doing the same work <damo22>bootstrapping a hurd system from scratch sounds hard to me <damo22>i even had trouble transferring a working hurd system from an image to a real disk <damo22>hopefully that fast symlink patch fixed that <damo22>to use rumpdisk.static for / do we need pci-arbiter.static ? how would a translator attach to a node without a / <damo22>or do we need an initrd.img ramdisk for / and then chroot into a rump disk? <damo22>why cant gnumach have / built in with a memory backed /dev or /servers <damo22>i mean just to hold the initial translated nodes <youpi>damo22: IIRC I had already written my thoughts on it in some mail ? <youpi>Subject: Running rump for the / filesystem <youpi>Date: Mon, 9 Dec 2019 00:08:38 +0100 <gnu_srs1>youpi: Hust FYI: I'm building from upstream tarballs, not using any Debian stuff (except some patches) <youpi>but I mean looking at what option helmut's script passes to the various glibc stages it his bootstrap <youpi>but as I mentioned, you probably want to synchronize with guix people, who are basically doing the same <gnu_srs1>If the people at savannah would be nicer I would have the git directory available by now. Maybe I'll go for gitlab or github... <youpi>isn't it about just creating a repo in the hurd savannah group ? <gnu_srs1>I do have a working hurd image with the scripts I've rewritten based on Flavio's work. <youpi>that's not what my question is about <youpi>also, I'm not talking about scripts, but about documentation <gnu_srs1>I've asked to be added to the hurd savannah group, but was rejected due to not all patches had copyright entries... <youpi>you'll probably not be able to share scripts with guix people <youpi>because you'll have a different workflow <youpi>but documentation, you can share <youpi>? you are already in the hurd savannah group <gnu_srs1>I cannot upload the git tarball without permission?? <youpi>you need to get a git repository to be created in the hurd group <youpi>and then you can push to the repository <youpi>did you ask for that explicitly? <youpi>I don't see where you wrote that you just wanted to add a git tree to the hurd group <youpi>I don't see where Ineiev has not been "nice" <youpi>he is indeed extremely conservative about copyright notices <youpi>but he explained what he wants <gnu_srs1>I have now added copyright notices in a file in the patches directory. And confirmed that the cross-built hurd image boots. I'll re-upload the git tarball. <gnu_srs1>I don't regard Ineiev as not nice either. I just realized by then the amount of work to add more copyright stuff. <gnu_srs1>I would like to get hurd-cross published so I can get some help with the FIXMEs and move on to cross-compiling more packages. <gnu_srs1>And updating to the most recent tarballs. And getting network functioning etc. <gnu_srs1>I think cross-compiling can be very useful for other people, like for arch-hurd. <gnu_srs1>And to port not available packages to Hurd, e.g. fpc, rust, etc. <gnu_srs1>Regarding Guix it seems like janneke has already succeeded to support Hurd, so cross-compiling is no longer needed. <janneke>gnu_srs1: i managed to cross compile the hurd, we don't have a system image just yet <youpi>gnu_srs1: guix bootstrap is very much like cross-compiling <gnu_srs1>yes, but it is guile-based not scripted. <youpi>that's what I meant what I said you'd not share script, but you can share documentation <civodul>when booting, mach prints "task loaded:" <youpi>ah that piece is still in the gnumach bootstrap yes <civodul>how do you go about debugging hanging at that point of the boot process? :-) <civodul>youpi: how does one break into the kernel to see the list of tasks? <Pellescours>youpi: do you know why the build of git is failling ? I saw that's because one test fail <youpi>Pellescours: which build of which git failing how? (as in: concerning gnumach I'm not getting any issue) <civodul>my ext2fs.static is stuck in ext2fs/pager.c:1146 (per trace/tu) <civodul>am i missing something that would prevent proper page fault handling? <youpi>civodul: not in the FS at least <civodul>i'm guessing the fault is supposed to be handled and ext2fs resumed right away at that point? <youpi>by gnumach calling back into ext2fs' pager to install the page <civodul>and the pager is another thread, right? <Pellescours> git : Depends: git-man (< 1:2.25.1-.) but 1:2.26.0-1 is to be installed <Pellescours>E: Unable to correct problems, you have held broken packages. <youpi>aaaah, the build of the git package <youpi>yes, one test fails, haven't investigated <civodul>youpi: re the ext2fs hang, i'm using vanilla glibc 2.31, could i be missing patches? <youpi>civodul: do you build with PIE ? <civodul>the hurd is not built with PIE AFAICS <youpi>I mean the ext2fs binary, is it built with PIE <youpi>if so, there are allocation issues with sbrk, see the pie-sbrk patch in the topgit <youpi>apart from that I don't see anything that debian has that would be required <civodul>dunno, but i don't see it in the build log <janneke>ignore me... -- that was a foreign distro's gcc configure option that hurt me in mes <youpi>without having to specify it <youpi>thus not showing up in the log <civodul>i added printfs all around but i don't see anything <civodul>which would mean it doesn't even read on the commad <youpi>remember you can use mach_print() <youpi>(mach needs to be build with --enable-kdb for mach_print to actually print) <civodul>youpi: where's mach_print defined actually? <civodul>but there's really nothing but the declaration <civodul>also, why does "trace/tu" show just one frame? <youpi>civodul: see the wiki, it talkes about it <youpi>trace/tu is supposed to show the whole backtrace indeed <civodul>so the code does run beyond diskfs_console_stdio <civodul>but for some reason, printfs don't go through <civodul>youpi: were there any changes "recently" in the VM RPCs or somewhere in that area? <wleslie>I mean even for the 2nd of April the press doesn't hurt (: <civodul>there's been a lot of work going on in fact <wleslie>I'm absolutely trying out that qemu image <damo22>youpi: so "module rump" would that be a grub module? <gnu_srs1>youpi: Where do I find a tarball of libdde? <youpi>gnu_srs1: you mean upstream tarball? <janneke>gnu_srs1: joke? i've been working on hurd support for over a month now! <gnu_srs1>youpi: I need an upstream tarball to cross-compile for a Hurd VM image. <youpi>civodul, janneke: when creating a tarball of an image, use tar -S <youpi>so it create a sparse file when unpacking <youpi>gnu_srs1: that's all I know of <gnu_srs1>janneke: Yes, I know you have been successful within Guix recently, but much work remains... <wleslie>"bash: cannot create temp file for here-document: No space left on device" I guess I did not clear enough (: *rekado tries to remember “tar -S” for the next time <gnu_srs1>I'll hopefully get the hurd-cross repo published tomorrow at savannah. <youpi>also, before packing, it's a good think to, from linux, mount the FS, fill it with a huge file full of zeros, sync, remove the file, umount <janneke>gnu_srs1: yes, civodul really cut some corners today <youpi>and then cp --sparse=always file.img file2.img <youpi>cp will perforate holes where it finds zeroes <damo22>janneke: what do you need help with? <janneke>damo22: i think civodul knows the details, but this guix vm image was a pretty ugly hack <janneke>we really want proper support in guix to build a guix vm <damo22>i dont know much about guix, sorry <civodul>we've had troubles getting the initial ext2fs.static to start, as discussed earlier today <janneke>then, we only really started with the hurd, so apart from what's needed in a minimal base system, we haven't built many packages <civodul>yes, plus debugging work where we'll need the insight of y'all! :-) <janneke>then, there's the build daemon that does not run in a chroot; there's a patch lingering around that needs to be finished <damo22>so are you cross building hurd from a running guix system? <janneke>yes, i think that's where focus will be shifting <janneke>i have worked mostly on native guix builds until now <damo22>theres a native guix build of hurd? <civodul>yes, janneke succeeded in building things natively (currently on Debian) ***coderobe5 is now known as coderobe
<janneke>yes, i've been running guix on the debian vm <user_oreloznog>civodul, janneke, damo22, youpi and others: fantastic! I'm in love :) <damo22>the day is just beginning for me <damo22>i think guix is very cool, but i also think we need to get more drivers working <damo22>i'll be focusing on rump again soon <alextee[m]>i'll start packaging like crazy when the audio stack is ready :) <damo22>i tried fixing the audio stack in netbsd, seems like a more accurate buffer pointer doesnt seem to do much unless the applications use it <damo22>one of the netbsd devs added softfloat support to netbsd kernel so i could use a floating point DLL, but turns out i could do it just with integers 
