***Server sets mode: +nt
***rekado_ is now known as rekado
<janneke>so...it's been a week and my linux xattr gnu.* patch hasn't been commented on <janneke>maybe that's o good thing, i wrote it to be /very/ conservatively, and only allow using gnu.* xattr on a "Hurd" type file system (as created by mkfs -t ext2 -o hurd -O ext_attr) <janneke>now, we are hitting a problem with this when building disk-images without root access in guix <janneke>the problem could be solved if we allowed xattr gnu.* be set on a linux file system...ideas, civudul? <civodul>janneke: you can use "-o hurd" from GNU/Linux anyway? <janneke>with mothacehe's disk-image, we lose <janneke>inside qemu-image, i used: mount, setxattr -- but that doesn't work without being root :-/ <civodul>so the problem is that "mke2fs -d DIR" ignores xattrs? <civodul>(i think mothacehe 's code uses that) <civodul>"Normally mke2fs will copy the extended attributes of the files in the directory hierarchy specified via the (optional) -d option." says mke2fs(8) <civodul>so if you set xattrs on the directory passed to "mke2fs -d", they should be preserved <janneke>well, to be able to set xattr's named "gnu.*" at all, linux needs to be patched <civodul>but for that you need the patched kernel, so you need a VM, and we're back to the beginning <janneke>and the patch i submitted is very conservative <janneke>so i was pondering (trying to ask you) if we would/should dare to resubmit it, and dare some more <janneke>eg to allow setting gnu.* xattrs on a plain linux fs <civodul>you can't assume that guix-daemon is running under a properly patched kernel <civodul>thus, you can't use gnu.* xattrs at all <janneke>well, that's something i would like to assume <civodul>... unless you run the whole process in a VM <civodul>but that's what mothacehe managed to avoid <janneke>"creating images for the hurd is not supported unless XXX", isn't that acceptable? <janneke>as soon as that patch is in upstream linux, of course? <civodul>i don't think so, it would fail too "randomly" <civodul>this thing is supposed to be about reproducibility ;-) <civodul>1. reintroduce a VM for the purposes of Hurd images <civodul>2. avoid xattrs for the next couple of years <civodul>3. patch mke2fs or use libext2fs directly so we have more freedom over what we put into the file system <civodul>3b. implement ext2 as a Guile module :-) *janneke waits for acceptable options ;-) <civodul>you mean "for *more* acceptable options"? :-) <janneke>well, maybe 1, 2 and 3 combined are acceptable? <civodul>maybe we can use nyacc to generate libext2fs bindings? <civodul>maybe #2 is the best solution short-term, even if it's frustrating <janneke>3b sounds fun, but...i'd really like to get a guix vm up and running some time soon? <civodul>if you really insist on spawning Guile right away, you can patch Guile to set up pflocal at startup <civodul>janneke: for that, find a first milestone that doesn't involve getting rid of runsystem.sh and all IMO <civodul>that should work now, with what you and mothacehe did on the image stuff? <janneke>well, 1. works on wip-hurd-vm, i think <janneke>i'm not sure about /servers/exec yet, how we should get that to work (without 1. qemu-vm) <janneke>civodul: oh, while i thought it would be "more elegant" not to go through bash, i thought it would be/become necessary for/when starting the shepherd <janneke>i'm sensing you propose to postpone that, so i'm all for it! <civodul>janneke: yeah, i agree that it's a worthy goal of course :-), but we can separate it from getting "guix system vm-image --target=i586-pc-gnu" working <janneke>okay, yes separation is very desirable! <janneke>okay, so for the record... this <janneke> /hurd/startup: Failed to bind to /servers/startup: Device or <janneke>error while booting can be taken at face-value <janneke>the problem we had (created), was that /servers/{exec,startup,...} were hard links to the same file <janneke>that does not work, there's no translators needed, but it's essential that these individual empty files exist! <janneke>(oh, they don't need to be empty -- they can contain their name ;-) <civodul>i'm sure it's also fine if they contain the string "42" <bmelo>is it real hurd will switch to another microkernel than mach? <janneke>so, civodul, youpi -- any thoughts on lifting the "file system type == Hurd' check on the linux xattr patch, shall I remove that restriction? <janneke>+ EXT4_SB(dentry->d_sb)->s_es->s_creator_os == <janneke>(so, drop the mke2fs "-o hurd" requirement) <youpi>I'd say we shouldn't require -o hurd indeed <janneke>thanks -- i added it to make the patch more conservative (and thus hopefully easier to upstream) <janneke>...but only after i learnt that using xattr's may be used (later) to drop the "-o hurd" hack altogether? ***Emulatorman____ is now known as Emulatorman