IRC logs for #baserock for Wednesday, 2015-06-03

*** seb__ has joined #baserock02:57
*** seb__ has quit IRC03:13
* paulsher1ood reviews and merges - but nothing seems to happen at g.b.o03:28
*** seb__ has joined #baserock04:25
*** seb__ has quit IRC04:33
paulsher1oodgobject-introspection seems busted in master (i noticed first in ybd, then in morph, and then on mason... how dumb am i?)05:24
* paulsher1ood notices the eventual arrival of libfaketime at g.b.o05:25
*** seb__ has joined #baserock05:27
*** seb__ has quit IRC05:52
straycatpaulsher1ood, we agreed as a group not to merge that06:40
straycatso that's pretty darn irritating06:40
straycat16:28 +pedroalvarez$ tlsa: I wonder if you can use "" in your definitions and wait  |06:42
straycat                     for the lorry once you have something ready                                                             |06:42
straycat16:28  tlsa$ can do06:42
straycatso there was totally no need for this06:42
*** mike has joined #baserock06:49
*** mike is now known as Guest5156006:49
straycatso, i have reverted the change and destroyed delta/libfaketime. looking at the log i realise the irc discussion should have been recorded in the change and perhaps that's what led to this misunderstanding.06:52
*** zoli__ has joined #baserock07:04
*** seb__ has joined #baserock07:38
paulsher1oodstraycat: sorry. i saw that the change was in review, and had +2 already07:38
* paulsher1ood believes that +2, was enough to merge it, and no-one -1d the change, so reverting and destroying was not necessary07:39
*** a1exhughe5 has joined #baserock07:39
straycatahh okay, someone should have recorded the result of the discussion in the change really07:39
paulsher1oodbut this is an unusual situation, which hasn't arisen before i think07:39
paulsher1oodin any case i think we'll need libfaketime :)07:40
paulsher1oodstraycat: but thanks for being pro-active!07:40
straycatpossibly well, but best to be sure first, similarly i almost sent requests for some perl modules then decided to leave it for a bit, and it turns out i didn't need them07:44
straycat*will >.>07:46
SotKjjardon: oops, I thought I'd changed install-essential-files to point at the right place :/07:50
* SotK wonders how to make YBD deploy rather than build07:51
* paulsher1ood is ready to +1 any patch that fixes that without reverting the tidyup07:51
paulsher1oodSotK: give it a cluster instead of a system file?07:51
paulsher1ood(used to work)07:51
* paulsher1ood might have broken it, hasn't tested in a couple of weeks07:52
SotKhmm, looks like I did change install-essential-files07:52
SotK(I saw the same error as jjardon in the first test of the idea I was doing, but pointing to install-files/essential-files/manifest fixed it)07:54
SotKpaulsher1ood: I ran `ybd clusters/test.morph x86_64`, but nothing seems to have been deployed07:55
SotKI'll investigate further07:55
*** bashrc_ has joined #baserock08:03
SotKaha, deploy() returns if there is no 'systems' key in the dict it is passed, so nothing will ever actually get deployed08:09
*** jonathanmaw has joined #baserock08:13
*** mariaderidder has joined #baserock08:16
*** seb__ has quit IRC08:18
*** CTtpollard has joined #baserock08:21
*** CTtpollard has quit IRC08:29
*** CTtpollard has joined #baserock08:29
*** franred has joined #baserock08:32
*** tlsa has quit IRC08:34
*** rjek has quit IRC08:34
*** Kinnison has quit IRC08:34
SotKnow to figure out why install-essential-files is broken :)08:39
*** Kinnison has joined #baserock08:39
*** gary_perkins has joined #baserock08:41
*** rjek has joined #baserock08:42
*** ssam2 has joined #baserock08:49
*** ChanServ sets mode: +v ssam208:49
pedroalvarezOK, systemd 220 fully tested08:50
*** edcragg has joined #baserock08:54
franredpedroalvarez, thanks for that08:54
*** gan has joined #baserock08:55
*** Krin has joined #baserock09:05
* SotK is an idiot09:06
*** lachlanmackenzie has joined #baserock09:14
SotKnot as much as I first thought actually, but still09:14
rjekJust an idi now?09:15
SotKthe problem is that install-essential-files tries to call install-files based on the location of the install-essential-files script09:16
SotKthat worked fine when they were both in morphlib, but morph creates a temporary version of the script if its in definitions before it runs it to set permissions nicely (and historically be able to use scripts from a cached git repo)09:17
SotKso install-essential-files tries to call `/tmp/install-files.configure`, which doesn't exist09:18
* SotK prepares a patch09:22
* SotK sends
radiofreedoes morph build basercok aarch64 on aarch64 currently?09:46
KinnisonWe don't currently have any armv8l64 systems IIRC09:46
Kinnisonit *used to*09:46
Kinnisonbut that was back around mid Feb09:46
ssam2systemd merge has broken definitions:
richard_mawit'll be old kernel headers09:49
ssam2seems to be gobject-introspection that's failing to build09:49
richard_mawoh, it isn't09:49
richard_mawhm, it could possibly be the bison change, we're getting warnings related to code generation09:51
richard_mawthough: "ERROR: can't resolve libraries to shared libraries: gobject-2.0, glib-2.0" suggests someone may have merged the change to move glibc out of foundation or something09:53
SotKgobject-introspection seemed to stop building once the bison change was merged09:55
* richard_maw is checking sha1s himself to verify09:56
pedroalvarezphew, I tested systemd change carefully09:59
richard_mawyep, definitely the Bison change10:00
richard_mawrdale_: ^10:00
richard_mawwe've had bison eat itself over version numbers before10:02
jjardonold version of systemd builds fine with the rdale_ change though10:08
radiofreerdale_: do all of our qt trove url's need to be updated now?10:11
radiofreesince they've moved to gitlab now10:12
radiofreeactually have they moved to gitlab?10:12
richard_mawjjardon: not according to mason10:12
radiofreeno they've moved to code.qt.io10:13
radiofreewhat's the procedure for changing url's in trove config files?10:13
richard_mawjjardon: it was failing to deploy before, but looking at the logs, it fails in gobject introspection before that other failure10:13
Kinnisonradiofree: prepare a patch, submit it to gerrit10:14
richard_mawjjardon: so it's provably *not* the systemd change that broke things10:14
radiofreeKinnison: yeah, but i mean do i just patch the existing json files with the new repo url?10:14
Kinnisonproviding they're the same history, yep10:14
jjardonreally? I think I built several systems yesterday after the rdale_ change. Let me recheck10:16
jjardonSotK: thanks for the quick fix! :)10:18
SotKno problem, sorry I broke it10:18
radiofreeKinnison: i'm not sure, branches have been deleted by the looks of it10:21
Kinnisondeleted branches are okay10:22
Kinnisonso long as the stuff we rely on hasn't been expunged from history10:22
radiofreeis there a way to test whether or not this is going to totally bugger everything up without manually checking a million qt repos?10:23
jjardonstrange then, I can build a base system fine here using this commit of definitions should we condifer this a bug of morph?10:24
Kinnisonradiofree: sadly I don't think so,10:24
jjardonah, neverming, I was building my "split-glib" branch instead.10:27
richard_mawjjardon: in which case the base system may not even include gobject-introspection10:29
jjardonrichard_maw: yes, but I built a weston system as well that definelety includes g-i10:30
richard_mawhm, weird10:31
richard_mawwell currently I don't know why the bison change could cause it to break10:31
richard_mawI'm currently investigating whether it's ignoring .tarball-version or something10:32
pedroalvarezHas anyone reproduced the problem?10:32
*** tlsa has joined #baserock10:32
jjardonI think the root problem here is the use of this to generate the bison version: it expect to have access to git if its not a tarball:  m4_esyscmd([build-aux/git-version-gen .tarball-version]10:35
richard_mawjjardon: hence why we create .tarball-version10:35
paulsher1oodreproduced the build problem, pedroalvarez ? yes i have10:36
paulsher1oodsorry, i may be missing the discussion here10:37
pedroalvarezthe build problem that Mason is currently having10:38
paulsher1ood06:24 < paulsher1ood> gobject-introspection seems busted in master (i noticed first in ybd, then in morph, and then on mason... how dumb am i?)10:38
pedroalvarezthat one10:39
pedroalvarezpaulsher1ood: sorry I missed that :)10:39
paulsher1oodnp - is there anything i can do to help? build log for exmaple?10:39
richard_mawI'm just looking at the build log from mason now10:42
richard_mawit's definitely got 3.0.2 for the version10:42
richard_mawthe only other change I particularly notice is that we don't run the bootstrap script with bash any more10:44
* SotK sends a pull request to ybd10:45
paulsher1oodKinnison: why? so far i've not rejected a single PR :)10:54
paulsher1oodSotK: do i need to test this, or will it 'just work' ? :)10:54
SotKpaulsher1ood: It works for me :)11:00
paulsher1oodSotK: which cluster(s) have you mainly tested with?11:01
SotKpaulsher1ood: a test cluster which deploys a tarball of a build-system11:03
*** zoli__ has quit IRC11:03
paulsher1oodSotK: have you tried a self-upgrade?11:05
paulsher1oodSotK: no testing against any of the clusters in master?11:06
pedroalvareza test suite would be great :)11:07
SotKpaulsher1ood: I didn't want to spend ages building everything11:08
SotKpaulsher1ood: no, but I don't think anything I've changed should affect upgrades?11:08
SotKnot in a way thats different to how it affects normal deployments anyway11:09
*** Guest51560 has quit IRC11:16
*** Guest51560 has joined #baserock11:30
* jjardon sent to fix the bison problem11:53
richard_mawI haven't yet worked out how using sh rather than bash could cause it to break like that11:57
richard_mawjjardon: have you tested this change?11:57
jjardonrichard_maw: only in a base system, Im buildind a weston one now11:58
richard_mawand you reproduced it failing without this change?11:59
pedroalvarezjjardon: didn't they build for you before even with this change?11:59
jjardonrichard_maw: yes11:59
rdale_i tested building shadow with bison and it worked, and so i assumed bison was ok11:59
*** gan has quit IRC12:00
KinnisonSo you didn't run a full set of build tests?12:01
* pedroalvarez facepalms12:01
richard_mawThere's no particularly obvious bashisms in the bootstrap script of bison. trap's not 100% portable across all shells, but it appears to be doing the most portable form, and there can be incompatibilities in the result of failing to source a file, but they guard against its existance.12:07
richard_mawjjardon: I'm not saying it's not because of sh vs bash, just that I'm puzzled as to how the difference causes it to break12:08
rdale_what is the error when building g-o ?12:08
jjardonrichard_maw: yeah, Im not sure what root cause is neither, but I though useful to quickly fix the breackage, then continue investigatin12:09
*** Guest51560 has quit IRC12:10
*** zoli__ has joined #baserock12:10
*** zoli___ has joined #baserock12:11
richard_mawrdale_: generally /usr/include/glib-2.0/glib/glib-autocleanups.h appears to be broken12:12
richard_mawjjardon: ooh, I had a thought. It _could_ be an indirect dependency change, since now something depended on bison now doesn't implicitly depend on bash12:13
richard_mawthough it could be a broken scannerparser.h12:13
jjardonrichard_maw: yeah, true12:13
Zarahm, noticed that the magnifying glass on the baserock wiki search bar doesn't function as a button; in most search bars they function the same as 'enter'. is there any way we can fix that?12:15
* jjardon repeats again: he would like explicit dependencies :)12:15
*** zoli__ has quit IRC12:15
* richard_maw repeats that it's not as simple as that12:15
* rjek repeats the onion from his lunch12:16
jjardonyep, I think the problem probably is in the scannerparser.h though12:16
* jjardon just realized how tidy looks12:18
*** Guest51560 has joined #baserock12:22
pedroalvarezI noticed that libvirt generates a default network by default (/etc/libvirt/qemu/networks/default.xml). I wonder if makes sense to not create it.12:35
Kinnisonperhaps just ensure it's created but not set to autostart?12:36
pedroalvarezthat's another option12:36
rdale_the bison bootstap script has '#! /bin/sh' at the top of it12:38
richard_mawrdale_: doesn't mean it supports busybox sh12:38
richard_mawa lot of systems have /bin/sh -> /bin/bash, which leads some build systems to assume it12:39
paulsher1oodjjardon: yes it's lovely and tidy now... let's keep it that way :)12:40
* paulsher1ood proposes to change 'strata' to 'layers'12:41
paulsher1oodi'll get my coat :)12:42
richard_mawpaulsher1ood: stop trolling #baserock12:42
jmacs+1 from me12:42
* SotK would find layers more confusing than strata12:42
rjekLet's call them 'meta packages'12:42
* rjek runs for the hills.12:42
straycati think we should use locallycompact's naming scheme12:42
rjekstraycat: jake, finn, ice king?12:43
straycatno, we just call everything a leaf12:43
straycatleaves can have other leaves ofcourse12:43
jmacsJust like on real plants, but unlike that.12:44
straycatjmacs gets it12:44
rjekreticulation nodes.12:45
DavePagerjek: Splines?12:45
rjekDon't be silly, DavePage.12:45
paulsher1oodSotK: any chance you could test deploy with some clustes from master?12:47
pedroalvarezKinnison: looking at how others install libvirt, they remove the autostart symlink12:48
pedroalvarezKinnison: so it might be the best solution for us as well12:49
SotKpaulsher1ood: not right now really, I'll set one building/deploying this evening though12:49
Kinnisonpedroalvarez: nod.12:50
straycat is a pretty trivial change, can anyone look at it?12:55
KinnisonWhat is it to be used with?12:56
Kinnisoni.e. when would that be called with unshare=False ?12:56
straycatwith the import tool12:56
KinnisonWell, it looks plausible12:57
Kinnisonwhat testing have you done?12:57
straycati ran the import tool as non-root on my debian box13:00
straycatas well as running all the usual tests13:01
Kinnisonare the "usual tests" including normal deployments?13:01
* Kinnison is not currently au-fait with that -- does it include deployments?13:01
SotKKinnison: There are yarns for testing deployment, yes13:04
Kinnisonthen you can have my +113:04
tlsafor deterministic builds, one of the things we need is constant time.13:16
tlsawe can either do that in definitions (for chunks that need it) or in the tool (morph/ybd)13:16
tlsaif its in definitions, we need to test each chunk, and keep on top of it for chunk updates.13:16
straycattool approach seems better to me13:16
tlsaso I'd prefer to do it in the tool, as part of an environment sanitisation step.13:16
tlsabut I'm not sure if there would be any unwillingness to have to tools to this sort of magic.13:16
Kinnisontlsa: My concern would be if you are using the tool to build something other than a Linux system13:16
tlsahmm, good point13:17
straycatso we need to be able to set something in definitions to enable/disable morph/ybd from using libfaketime?13:18
tlsaseems like a very specific option13:19
tlsawhich I generally don't like13:19
* richard_maw has data for stripped vs unstripped on a base system: 728M rootfs tarball without stripping, 605M rootfs tarball with stripping13:20
Kinnisonso ca. 20% saved13:20
richard_mawand it's not even a completely ELF-binary dominated system13:21
straycatssam2, biff13:26
* SotK has another merge commit which needs reviewing; this time bringing in and its history13:31
richard_mawmoving to definitions.git‽13:33
SotKyes, so that the write extensions can use the code which is in it without needing to depend on all of morphlib13:34
richard_mawoh, I thought you were doing that by putting the common code into the write extensions, rather than defining a manner for write extensions to share code13:34
SotKI could do that, but it seems like it would cause unwanted duplication13:35
straycatare we sure it makes sense to move the write extensions into definitions?13:41
SotKstraycat: Why doesn't it?13:42
rdale_i've configured 4 versions of bison with sh and bash, and again with git using both sh and bash13:42
straycatSotK, because they're the build tool's means of deploying systems?13:42
rdale_and i can't see any differences when sh and bash are used without git13:42
SotKstraycat: there were already some write extensions in definitions though, and many configure extensions?13:43
tlsain morphlib/, LD_PRELOAD is one of the environment vaiables that morph copies from the original environment13:47
tlsawhat's that used for?13:47
tlsa(if its used, then maybe I can't trample it)13:47
KinnisonYou should never trample LD_PRELOAD anyway13:49
Kinnisonyou should always carefully add to it13:49
straycatSotK, okay13:50
tlsaKinnison: I'm just surprised that its a whitelisted one, and wondering why13:50
KinnisonPossibly for hand-bootstrapping stuff13:51
Kinnisonany hint in annotate?13:51
ssam2tksa: this overlaps a bit with something I'm doing: i'm currently looking at building with 'fakeroot'13:53
ssam2which ties into a bigger task I have of moving the sandboxing code from ybd / morph into a separate library13:53
ssam2i'm thinking that the sandboxing library is a good place to deal with 'fakeroot' as well13:53
ssam2maybe it could deal with libfaketime too13:53
tlsaperryl and I are looking at setting up environment to get deterministic builds out13:54
tlsaso things like faketime, for consistent time acros builds, and we'll need a way to make a fixed fake hostname13:54
ssam2i'm a bit worried about code that depends on LD_PRELOAD, but I'm not sure what else we can do for these sorts of things13:55
richard_mawtlsa: patch linux-user-chroot to allow setting the hostname in a new CLONE_NEWUTS namespace?13:55
tlsaand setting timezone, and locale consistently13:55
ssam2it does mean that the system running the build will need to use a libc that is ABI-compatible with the thing being built...13:55
ssam2which seems like it won't always be true13:55
ssam2tlsa: timezone and locale should be fine as environment variables13:56
ssam2but libfaketime is an awkward one13:56
ssam2as is fakeroot13:56
richard_mawwe've got some bits of build-essential that are statically linked, so LD_PRELOAD won't work anyway13:56
richard_mawfor reproducible builds fixing time we can patch around the awkward ones13:57
richard_mawbut for general purpose builds we don't want to have to patch everything13:57
ssam2the alternative for libfaketime is add it to builds /inside/ the sandbox13:57
ssam2which has its own issues...13:57
richard_mawso I think we should build libfaketime inside the sandbox and set LD_PRELOAD, yesh13:57
ssam2on the plus side, if it's built inside the sandbox then I don't have to worry about it conflicting with what I'm looking at ;)13:58
richard_mawI think we'll probably need to build libfaketime at least twice anyway, for LD_PRELOADing before the switch from bootstrap mode to staging mode, and after13:58
ssam2the only other approach I can think of is a bit of a wacky one, inspired by
ssam2which is that we run each build in its own VM, where we can make the clock always report the same time ;)13:59
ssam2that would also mean there's no need for 'fakeroot'14:00
ssam2but, i don't think it would be quick to implement!14:00
richard_mawssam2: :) yeah14:00
tlsawhat if I made morphlib/'s BuildSystem __getitem__ prepend "faketime -f '2015-01-01 00:00:00' " as a short term hack for testing?  Should that work?14:01
ssam2i can't predict whether or not that will work14:01
paulsher1oodtlsa: if you mean will it run the faketime, i think so14:02
richard_mawonly for stuff that doesn't set its own commands14:02
* straycat imagines it couldn't work at the stages where we haven't built faketime14:02
richard_mawstraycat: you'd have to build libfaketime in stage2 of the bootstrap14:02
straycatand prior to that rely on the host?14:03
richard_mawstraycat: if you build it sufficiently early in the stage1 bootstrap you'd probably be ok without needing it there too, provided you could override it to not attempt to faketime itself14:04
* richard_maw assumes faketime is sane enough to not build in timestamps14:04
paulsher1oodwould it be possible to leave faketime out of the targets, while having it in build-essential?14:05
richard_mawpaulsher1ood: yes, with artifact splitting14:06
ssam2i've been wondering recently if we should separate out "build environment" from "system being built" completely14:06
ssam2it's not a panacea at all14:07
paulsher1oodthat would be great if i'ts possible?14:07
tlsafaketime is simply a wrapper program that sets a bunch of environment variables which tell libfaketime how to behave and what time to set, and sets up LD_PRELOAD14:07
ssam2paulsher1ood: the issue I thought of with it is that we still need to bootstrap the build environment somehow14:07
ssam2and if we care just as much about that being reproducible, buildable as non-root, etc. then we're not much better off14:08
ssam2but, maybe it's worth pursuing14:08
paulsher1oodssam2: yup. i'm assuming we can't get stage1 to be bit-for-bit14:08
paulsher1ood(maybe we can't get anything to be b4b, but i live in hope :-)14:08
paulsher1oodi think all of build-essential is already reproducible, though?14:09
paulsher1oodwhere reproducible is a much more vague term :)14:09
ssam2i meant bit-for-bit when I said reproducible14:09
paulsher1oodcan we call it b4b to save typing?14:09
richard_mawI've got a full keyboard, I have no need to abbreviate.14:10
tlsapaulsher1ood: I tested with two minimal system builds on different VMs yesterday.  We're already bit-for-bit for most of the files on the system:
tlsathat's with different times, and different hostnames14:10
tlsasame baserock version used to do the build14:10
paulsher1oodtlsa: WOW! :-)14:12
* paulsher1ood dances a jig, does a back somersault giggling like a mad thing and falls flat on his face :-)14:13
robtaylornice :)14:13
ssam2that is a surprise. cool!14:17
Kinnisonminimal system is a good start14:17
KinnisonIt'd be nice to know what sort of ratio we're at with a base system14:18
Kinnisonthough with libm differing, it might behoove us to sort that first14:18
ssam2nice visualisation tool as well14:19
rdale_i've just built bison and g-o with the busybox sh running bootstrap, but with a dependency on bash and git for the bison chunk, and it worked14:19
richard_mawrdale_: ok, it sounds like stuff depending on bison required bash without it being explictly declared then14:20
ssam2hmm, a more robust alternative to 'fakeroot' might be a FUSE filesystem that did the equivalent of what 'fakeroot' does14:26
ssam2that would mean we don't depend on LD_PRELOAD14:26
ssam2I'll see how I fare with 'fakeroot' first though14:26
robtaylori recall lars suggesting something like that once14:26
* richard_maw doesn't14:27
robtaylorrichard_maw: you're right, i misremember. I'm thinking of the chunk-expanding fuse filesystem.14:28
Kinnisona fuse FS won't help you14:28
Kinnisonif the kernel blocks the syscall14:28
robtaylorgood point14:29
ssam2Kinnison: ah, right14:31
ssam2i suggested that about 5 minutes ago ;) via
* richard_maw just ran some numbers on reducing the target system size14:34
richard_maw is a diff to visualise it14:34
richard_mawI haven't yet gotten around to not including debug symbols on the target system except for the minimal system14:35
richard_mawbut I save 120MB of the size of the base system14:35
richard_mawwith cumulatively 11 lines of code added to morph14:35
richard_mawand if I'd done it entirely in definitions.git, it would have added ~700 lines of code14:36
richard_mawthough I'm still puzzled at some of the diff result14:39
paulsher1oodrichard_maw: can we see the 11 lines?14:43
richard_mawpaulsher1ood: I'll push the series for review after I've sanitised some commit messages. But in the meantime14:45
richard_maw 11 files changed, 463 insertions(+), 788 deletions(-)14:45
richard_maw morphlib/            | 336 --------------------------------------------------------------------14:45
richard_mawI excluded the test suite removal because it was too much like cheating14:45
*** mariaderidder has quit IRC14:46
richard_mawoh, and the most revolting change: morphlib/                  | 689 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------14:46
richard_mawgit thinks I pretty much rewrote the whole file because the diff is line based and is bad at reordering14:47
* pedroalvarez sends a patch to disable the autostart of the default network created by libvirt
richard_mawHave to (16 patches)14:58
*** mariaderidder has joined #baserock15:00
jjardonok, I updated to the minimal patch I think is needed (g-i needs bash)15:01
richard_mawjjardon: is this tested?15:02
tlsa  <-- that's the sort of thing that's different in libm builds15:02
jjardonrichard_maw: only as a base system, building a weston one now15:02
tlsalooks like its due to morph's remp directroy creation being non-deterministic?15:03
rdale_jjardon: i've given 765 a +115:03
richard_mawjjardon: if it works with base, it's probably ok15:04
Kinnisontlsa: well, I wouldn't expect the tempdir names to be identical each time15:04
Kinnisontlsa: But I also wouldn't expect it to reach the non-bootstrap components15:04
tlsaI don't really know anything about the bootstrapping, or build stages15:07
* tlsa has managed to avoid those horrors until now15:07
* Kinnison is surprised we're seeing tmpXXXXX names in the final built system15:08
* tlsa too15:08
Kinnisonsince for properly sandboxed chunk builds we should see / and /foo.inst/ at most15:08
Kinnisonit'd be handy to know if that libm content is really from the real build or has somehow leaked from a bootstrap15:08
tlsaits from the system artifact15:09
KinnisonThat certainly *shouldn't* have any bootstrap in it15:09
KinnisonI really don't want to have to add a fourth layer to build-essential15:09
tlsaI'll look at busybox and see if its the same issue there, or something else15:10
KinnisonYou need to find out *why* those non-isolated paths have managed to be baked in.15:10
tlsaI'm using `xxd` to convert the binarys to hex and `vimdiff` to view, btw15:10
pedroalvarezfranred:  biff re
franredpedroalvarez, ta15:13
franredlooks fine by me15:13
Zarastraycat: I tried testing change 768 and got 'unexpected keyword argument "separate_mount_namespace"'. suspect it may just be that my devel vm is a bit old; if so it might be worth saying what versions of baserock the change is compatible with in the commit. (I tried updating morph and my import tool but the error was still there)15:14
pedroalvarezKinnison: re - libvirt change, makes sense to put -f15:14
pedroalvarezthanks for reviewing15:14
SotKZara: did you set PYTHONPATH to your morph checkout when running the import tool?15:15
straycatZara, depends on current master15:16
straycat(of morph)15:16
richard_mawtlsa: those look like header search paths to me15:16
straycatpedroalvarez, take it "default.xml in 769 is a symlink?15:17
pedroalvarezstraycat: it is15:17
Zarayeah, I think I have the right morph; just cloned it (and my PYTHONPATH is set to that checkout in usr/bin/morph)15:17
pedroalvarezstraycat: should I note that in the commit message?15:18
straycatZara, then you also need to set PYTHONPATH when you run the import tool as SotK says15:18
SotKZara: you'll need to set PYTHONPATH either in the environment or when you run the import tool too15:18
tlsarichard_maw: yeah15:18
straycatpedroalvarez, doesn't bother me, just wanted to make sure :)15:18
Zaraokay, that's odd, didn't need to in the past!15:18
SotKit will have been using the morph that was installed in your system rather than the git checkout then I imagine15:19
pedroalvarezstraycat: ok :) The default network is going to be there, but it's not going to autostart15:19
* straycat nods15:19
tlsarichard_maw: but I'm not sure how they get inside the sandbox15:19
Zaraseems to still be doing the same thing15:20
richard_mawit is worrying, as those paths look like they are from stage2 of the bootstrap15:20
tlsalibm doesn't show up in a grep of definitions15:20
tlsawhere does it come from?15:20
paulsher1oodtlsa:  is that tmpXXXX stuff in ybd too?15:20
tlsapaulsher1ood: I don't know, yet15:21
paulsher1oodtlsa: ok, np15:21
*** a1exhughe5 has quit IRC15:29
*** jonathanmaw has quit IRC16:57
*** ssam2 has quit IRC16:58
*** Krin has quit IRC16:58
richard_mawjjardon: has your build where you've included bash in the dependencies for gobject-introspection built as far as weston?16:59
franredpedroalvarez, +2 to - I think it was a minor change and you already have 3 +1s from previous versions17:00
pedroalvarezoh, I didn't notice straycat's one17:00
richard_mawjjardon: if you have, I'd like to record that in the comments, and vote17:01
jjardonrichard_maw: not yet, I will comment when it finish17:02
richard_mawjjardon: ack17:03
*** bashrc_ has quit IRC17:04
richard_mawjjardon: given my plan would be to +2 and merge if you proved it worked, I'd be fine with you submitting it, if your testing proves it works17:04
jjardonrichard_maw: ok, its at 172/261 so its going to take a while17:05
*** Guest51560 has quit IRC17:06
pedroalvarezmy devel system build, on arm, with that patch, succeded17:07
pedroalvarezwell, no17:08
pedroalvarezi tested the bison one17:08
*** mariaderidder has quit IRC17:21
*** gary_perkins has quit IRC17:38
*** edcragg has quit IRC17:59
*** ctgriffiths has quit IRC18:14
*** lachlanmackenzie has quit IRC18:17
*** ctgriffiths has joined #baserock18:27
*** zoli___ has quit IRC21:12
*** zoli__ has joined #baserock21:51
*** zoli__ has quit IRC22:17
*** zoli__ has joined #baserock22:18
*** zoli__ has quit IRC22:24

Generated by 2.14.0 by Marius Gedminas - find it at!