IRC logs for #buildstream for Thursday, 2017-09-21

*** crazynig has joined #buildstream01:12
crazynigANOTHER NIGGER ACTING CRAZY!!01:13
crazynighttps://www.youtube.com/watch?v=ySSdeYpoWBU01:13
crazynigrealnigzlqctosqu.onion or realnigzlqctosqu.onion/666701:13
crazynigpaulsherwood laurenceurhegyi adds68 uajain persia hergertme benbrown jjardon[m] waltervargas[m] mattiasb mrmcq2u[m] cgmcintyre[m] ptomato[m] anahuelamo juergbi brlogger gitlab-br-bot ironfoot01:13
*** crazynig has left #buildstream01:13
*** tristan has joined #buildstream01:16
*** ChanServ sets mode: +o tristan06:26
paulsherwoodmarvellous what idiots can achieve on the internet, dontcha think?07:23
paulsherwoodthis makes me wonder, is it possible to edit the irc logs? would be a shame to have that kept for posterity07:24
*** bochecha has joined #buildstream07:57
*** jonathanmaw has joined #buildstream08:14
tristanhere ?09:06
tristanoh was there a spam bot ?09:07
tristanThat can happen09:07
tristanah yeah, sometimes its that, sometimes its all praise allah09:08
tristansometimes it's come see our darkweb thing !09:08
*** tlater has joined #buildstream09:13
paulsherwoodtristan: time to put on your BD hat :)09:36
tristanpaulsherwood, ah are we talking my metric ton of emails ?09:57
tristanheh09:57
paulsherwoodyup. "Encourage debate where necessary, but if things get bogged down, be a benevolent dictator"09:58
tristanYeah, it's over now09:58
paulsherwood:)09:58
*** bochecha has quit IRC10:13
*** tristan has quit IRC10:49
*** tristan has joined #buildstream11:34
*** bochecha has joined #buildstream12:12
*** tlater has quit IRC12:54
*** tlater has joined #buildstream12:57
jonathanmawhrm, I'm running buildstream on an ARM system, and I'm getting the error "Creating new namespace failed, likely because the kernel does not support user namespaces.  bwrap must be installed setuid on such systems." when I try to start building.12:59
jonathanmawfirst occurs when running ldconfig for the first time.13:00
jonathanmawI've already tried `chmod u+s /usr/bin/bwrap`13:00
jonathanmawis there a difference being "installed setuid" and "the binary has setuid permission"?13:07
jonathanmawalso, getting a kernel that has user namespaces enabled is going to be a problem for me, since I'm not quite sure where the kernel for this came from, and especially not how to get a uImage for it (aarch64)13:09
tlaterHm. Mounting the fuse mount in the sandbox root causes mount to hang.13:34
tlaterI think it's because sandbox mount->fuse mount point, fuse mount point->sandbox mount13:34
tlaterBut I can't make out what the correct mount paths should be if that's wrong]13:35
tristanjonathanmaw, it must be setuid root13:41
jonathanmawtristan: the bwrap binary has full permissions "-rwsr-xr-x 1 root root 43064 Jul 25 20:10 /usr/bin/bwrap"13:42
tristantlater, I doubt this is the reason13:42
jonathanmawI thought that was setuid root13:42
tristantlater, you might just try to manual fusermount something and then mount something in a subdir to test it, though13:43
tristanjonathanmaw, ummm that should be correct permissions13:44
tristanit's same as I have here13:44
tlatertristan: What path is the sandbox supposed to run in? $BUILDDIR/root or $BUILDDIR/scratch/<something>13:44
tlaterBecause right now I'm mounting $BUILDDIR/root -> $BUILDDIR/scratch/_ -> $BUILDDIR/root13:45
tristanjonathanmaw, oh wait, that error message; might actually mean what it says, and if it does; I dont think there is anything to be done for it13:45
tristansigh13:46
* tristan now has to remember all the details of how he setup the mount map ?13:46
tristanI cant say off the top of my head really13:46
tlaterWell, I can bash my head into this for a bit longer, just if you happened to know :)13:47
tristanThe scratch directories are so that the fuse mounts have a dedicated place to cache things13:47
tristanThe _s are substituted /s13:47
tristan(s being the plural of the char)13:48
tlaterAh, so _ would just be /13:48
tlaterAnd _ is a cache of /13:48
tristanmaybe, I cant recall13:48
tlaterHm. Well, more debugging required then.13:48
jonathanmawtristan: hrm, googling around, it's possible that it's a problem that's fixed in newer versions of bwrap.13:49
tristanaha13:51
tristantlater, So it's like this13:52
tristantlater, see sandboxbwrap.py Mount() class __init__()13:53
jonathanmawthis chroot is debian unstable, so I'm surprised that the version is as old as 0.1.8. looks like I'm going to have to build it from source13:54
jonathanmawhrm, 0.1.8 looks like the newest bubblewrap.13:55
tristantlater, if there is safe hardlinks, then: "The mount source will be $BUILDDIR/scratch/{normalized_sandbox_relative_path}/mount"13:55
tristanjonathanmaw, your kernel has linux namespaces ?13:55
jonathanmawCONFIG_NAMESPACES=y13:56
tristantlater, and "The mount origin will be $BUILDDIR/root/not/normalized/sandbox/path13:56
tristan"13:56
jonathanmawCONFIG_USER_NS is not set13:56
tristantlater, so there is an origin and a source; the source is the only thing of concern for users of that Mount() class that exists in _sandboxbwrap.py13:57
tristantlater, the source is the mount point we use to remount into $BUILDDIR/root during sandbox.run()13:57
tristanSo yes; the mounts are intentionally remounted *in place*13:58
tlatertristan: So I should indeed mount $SOURCE -> $BUILDDIR/root ?13:58
tristantlater, this means that once everything is staged and a build fails, you dont have this crazy directory structure with things staged all over the place13:58
tristanwell, maintaining a single dir is intentional, I suppose it could be implemented a bit differently13:59
tlaterDarn, I hoped this would be the issue. I'm still not sure why mount fails in this case.13:59
tristantlater, the answer to your last is No. Unless it's the one case that you happen to be mounting the rootfs :D13:59
tlatertristan: That's exactly the case where it fails :(13:59
tristanAre they happening in the right order ?14:00
tristanthat's of course important14:00
tlatertristan: Pretty sure they are. Even if I comment out all other mounts it still fails.14:00
tristanjonathanmaw, you probably need that yeah14:00
tristanjonathanmaw, I dont see how on earth bubblewrap could create a namespace without it14:00
tristana user namespace, of course14:01
tlaterThat is, if by correct order you don't mean $SOURCE -> $BUILDDIR/root, $FUSE_WIZARDRY -> $SOURCE14:01
tristantlater, as I said; try it in a shell14:01
tristantlater, I rather meant, mounting / before mounting /buildstream14:02
tlatertristan: Yeah, those are done in the right order. Hm, I'll try doing it completely manually.14:02
tristanexactly14:02
tristanI cant say exactly for sure that the bubblewrap mounts are of the same nature, but I *think* they are just regular bind mounts done by privileged bwrap14:03
tristanso if that's the case; it should be the same with calling mount14:03
tlatertristan: I've read through the bubblewrap source, I'm pretty sure they are. Which is why I'm so confused by this.14:04
tristannod14:04
tristantlater, I wonder; if you are perhaps failing to cleanup your devpts/tmpfs/procps mounts14:07
tlatertristan: For debugging I've completely removed any mounting besides root - in this case that shouldn't matter.14:08
tristanmaybe trying to mount foo/bar/baz on top of itself, when foo/bar/baz/dev is mounted devpts, causes an issue by hiding an existing devpts ?14:08
tristanespecially if it's busy ?14:08
tristanAh14:08
tristantlater, this can be helpful: https://github.com/skorokithakis/python-fuse-sample/blob/master/passthrough.py#L13014:10
tristantlater, thats a python fuse example, and the bottom shows how you can take our SafeHardliksOps and use it in a standalone main()14:11
tlatertristan: Cool, ta, easier than reading the buildstream source :)14:11
tristanso you could reproduce in the shell better14:11
tristanyou could even try the example verbatim and possibly reproduce I dont know, but you could just copy/paste ours and run it just as easy :)14:12
* tristan tries to disappear again...14:12
tristanjonathanmaw, since you ran into this; it wouldnt be bad to file a bug14:19
tristanjonathanmaw, we should probably be able to tell you that it's not going to work at install time14:19
* tlater understands FUSE now \o/14:19
tristantlater, not until you've dug though libfuse C library14:20
tristanwhich is, gross14:20
* tlater will avoid doing that14:20
gitlab-br-botbuildstream: issue #92 ("buildstream fails and prints an error message from bwrap when run on a system running a kernel lacking CONFIG_USER_NS") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/9214:24
tlaterWell, I've confirmed that I'm definitely doing *something* wrong when mounting the way I currently do :)14:34
tlaterHAHA, I was right! The sandbox is supposed to run in $BUILDDIR/scratch/_/mount14:55
*** tristan has quit IRC15:35
*** adds68 has quit IRC15:54
*** adds68 has joined #buildstream15:56
*** jonathanmaw has quit IRC16:28
*** adds68 has quit IRC16:28
*** adds68 has joined #buildstream16:28
*** adds68 has quit IRC16:30
*** bochecha has quit IRC16:45
*** tlater has quit IRC17:02

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!