IRC channel logs


back to list of logs

***Server sets mode: +nt
***rekado_ is now known as rekado
<janneke>'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?
<janneke>hey civodul! you just missed: =>
<civodul>janneke: you can use "-o hurd" from GNU/Linux anyway?
<janneke>civodul: yeah .. if you're root
<janneke>with mothacehe's disk-image, we lose
<civodul>why is that?
<civodul>it invokes mke2fs as well, right?
<janneke>yes, but without root priviliges
<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>that doesn't make a difference
<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>so there are several ways
<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>just one will do :-D
<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 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> resource busy
<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"
<civodul>just sayin'
<bmelo>is it real hurd will switch to another microkernel than mach?
<civodul>i don't think so :-)
<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>ie, remove these checks
<janneke>+ EXT4_SB(dentry->d_sb)->s_es->s_creator_os ==
<janneke>+ cpu_to_le32(EXT4_OS_HURD);
<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