IRC channel logs


back to list of logs

***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.
<damo22>this was april fools in 2017:
<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>he doesn't have such issue
<youpi>(helmutg/rebootstrap on
<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>(+hurd 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>(or on IRC or some such)
<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>sure I understand that
<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>I don't understand
<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
<gnu_srs1>Yes, that is the culprit.
<youpi>i.e. get an item added to
<youpi>did you ask for that explicitly?
<gnu_srs1>From Ineiev <>: see
<youpi>I don't see where you wrote that you just wanted to add a git tree to the hurd group
<gnu_srs1>Ok, that is here:
<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
*janneke lost a M-x
<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.
<gnu_srs1>And I'm not fluent in guile :(
<youpi>that's what I meant what I said you'd not share script, but you can share documentation
<youpi>on the wiki, typically
<civodul>when booting, mach prints "task loaded:"
<civodul>and later, we see "start ext2fs:"
<civodul>where does that message come from?
<youpi>from hurd startup pieces
<civodul>oh boot_script_task_resume
<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?
<civodul>the sysreq kind of thing
<civodul>kbd suggests ext2fs is stuck in vm_fault_continue:
<Pellescours>youpi: do you know why the build of git is failling ? I saw that's because one test fail
<civodul>uh, bad window
<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>youpi: doing a apt install git gives this:
<civodul>i see 4 threads for ext2fs
<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 ?
<youpi>there is the pie-sbrk patch
<civodul>youpi: for libc?
<civodul>the hurd is not built with PIE AFAICS
<civodul>it's plain master
<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>it's not built with PIE AFAICS
<janneke>isn't pie the default nowadays?
<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>default = gcc does it
<youpi>without having to specify it
<youpi>thus not showing up in the log
<civodul>then yes
<civodul>i added printfs all around but i don't see anything
<civodul>which would mean it doesn't even read on the commad
<civodul>doesn't reach diskfs_console_stdio
<youpi>printf would need to malloc
<youpi>remember you can use mach_print()
<youpi>that doesn't require much
<youpi>(mach needs to be build with --enable-kdb for mach_print to actually print)
<civodul>ah ok
<civodul>youpi: where's mach_print defined actually?
<civodul>oh found the decl in libc
<civodul>it always helps to ask :-)
<civodul>but there's really nothing but the declaration
<civodul>libc and libmachuser don't have it
<civodul>damnit, dead end!
<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>could it be device_open that fails?
<civodul>youpi: were there any changes "recently" in the VM RPCs or somewhere in that area?
*wleslie applauds
<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
<wleslie>freeing up some space now
<gnu_srs1>janneke: Nice 1st april joke ;)
<gnu_srs1>go hurd go :)
<damo22>youpi: so "module rump" would that be a grub module?
<gnu_srs1>youpi: Where do I find a tarball of libdde?
<youpi>damo22: yes
<youpi>gnu_srs1: you mean upstream tarball?
<janneke>gnu_srs1: joke? i've been working on hurd support for over a month now!
<youpi>gnu_srs1: I don't know if there is an upstream tarball, AFAIK what we use is from
<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
<janneke>and we can certainly use some help!
<youpi>cp will perforate holes where it finds zeroes
<civodul>nice trick
<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
<janneke>so, lots of "porting" work
<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
<damo22>thats cool!
<janneke>yes, i think so too!
<user_oreloznog>civodul, janneke, damo22, youpi and others: fantastic! I'm in love :)
<janneke>ty, what a day
*janneke -> zZzzz
<damo22>the day is just beginning for me
*alextee[m] uploaded an image: Screenshot from 2020-04-01 23-09-57.png (15KB) < >
<alextee[m]>it works!
<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