IRC logs for #baserock for Monday, 2016-04-11

*** ctbruce has joined #baserock06:59
*** fay_ has joined #baserock07:37
*** toscalix has joined #baserock07:40
*** rdale has joined #baserock08:01
*** bashrc has joined #baserock08:06
*** edcragg has joined #baserock08:34
*** anahuelamo has joined #baserock08:42
*** jonathanmaw has joined #baserock08:59
pedroalvarezjjardon:  nah, no need, I don't care about the GDP system anymore09:00
*** ssam2 has joined #baserock09:03
*** ChanServ sets mode: +v ssam209:03
*** CTtpollard has joined #baserock09:07
jjardonunderstood, but Its not only about GDP systems, its how we can resolve that kind of situations in general in baserock09:11
pedroalvarezjjardon: feel free to start a conversation in the ML09:13
*** locallycompact has joined #baserock09:29
edcragghi, i'm considering looking at how the mismatch between mkfs.btrfs and syslinux in deployment prevents Baserock from booting on x86 systems11:19
edcraggwas hoping to canvas opinion on what is the best way to achieve this11:20
edcraggas far as i'm aware there have been a number of solutions proposed  1) use syslinux and btrfs from the host  2) Upgrade Baserock's syslinux and fiddle with btrfs flags11:21
edcraggi'm thinking about using btrfs tools and syslinux from the target system for deployment, as this means we control both the btrfs tools version and the version of syslinux11:22
pedroalvarezI don't think it would be good to do that. I agree that controlling the environment will give us reproducibility, but in this case you can't assume that you will deploy a system with syslinux and mkfs.btrfs..11:25
pedroalvarezalso, you might be deploying a system for another architecture11:25
edcraggpedroalvarez: it may still be useful to use the target btrfs tools on another architecture (though syslinux is clearly not needed)11:26
edcraggi have ubuntu systems where images created with mkfs.btrfs aren't even mountable on any other system11:26
ssam2they won't work on another architecture, though11:27
ssam2e.g. if i'm deploying a system for ARM, using an x86_64 machine, i can't run the mkfs.btrfs  from inside that ARM image on my x86_64 machine11:27
edcraggthis is true11:28
edcragghost tools could be a fallback11:28
edcraggit's just that using host tools you are at the mercy of the host distribution11:29
ssam2that might be an OK workaround for this problem11:29
ssam2at least the simple case of native deployment would work and be consistent11:30
ssam2but for cross-deployments, developers might have to hack their distro11:30
edcraggor for systems not containing the required tools (minimal, maybe others)11:34
edcragga very minimal deployment system could be built as required, and used in a chroot to deploy11:40
ssam2you mean, YBD / Morph deploy from inside a sandbox, rather than on the host? I think that's the best solution11:41
ssam2where the sandbox is built by YBD/Morph and contains tools for deployment11:41
edcraggssam2: indeed11:45
*** gary_perkins_ is now known as gary_perkins12:53
*** tiagogomes has quit IRC14:35
*** tiagogomes has joined #baserock14:35
ssam2gtristan: around?15:01
ssam2i'm trying your Aborginal branch15:01
ssam2but I get a build failure for binutils:
ssam2this only occurs with ENABLE_GPLV3, upstream aboriginal and your branch without ENABLE_GPLV3 seem to build fine15:02
ssam2any tips on debugging this gratefully received15:03
gtristanoh my15:20
gtristanssam2, do you have dual-toolchain branch or ?15:22
ssam2the latter15:22
*** locallycompact has quit IRC15:24
gtristanhavent seen that error before, it seems to be occurring in the first stage where you use host tools to build your first cross15:24
ssam2i've just discovered, will try to triage a bit better15:25
gtristanmaybe my compiler knows where to find -lz in a sneaky default link path ?15:26
gtristanssam2, In sources/utility_functions.. there is dienow() {} ... I find it useful to add ${SHELL} -i to that function15:27
ssam2oh, nice15:28
ssam2it seems to actually be using the host 'cc' for this build15:28
ssam2but, I definitely have the zlib-devel package installed15:28
gtristanit should right, it's the very first15:28
ssam2oh, hold that thought15:29
ssam2zlib-devel doesn't seem to contain libz.a on Fedora15:29
*** CTtpollard has quit IRC15:29
ssam2and this is a static build15:29
ssam2let me install 'zlib-static' and try again :-)15:30
*** CTtpollard has joined #baserock15:30
ssam2much better15:31
*** locallycompact has joined #baserock15:33
anahuelamoHi, I just built and deployed systems/devel-system-x86_64-generic.morph in a baserock x86_64 VM using morph and everything went ok, but When I tried to build with YBD I have this error:
anahuelamoany idea of how to solve it?15:48
rjekDon't use hash tables for all the things when classes are available? :D15:49
rjektbh, querying a dictionary for a non-existing key throwing an exception is both the best and worst feature of Python.15:52
edcragganahuelamo: looks like a recent change in ybd probably caused it to break, b46abb313f258975b76eaea9c524e5c049ba0e7415:54
rdaleit looks like 'cache' is a newly added field in the .meta file, and it isn't in the cached version of an artifact15:55
edcraggah, so rebuild from scratch?15:56
rdalethe fix is to version the artifacts, so the the cached version is invalidated15:57
paulsherwoodmy breakage15:57
paulsherwoodanahuelamo: maybe better to drop back to previous tag15:58
anahuelamook, I'll do that15:58
pedroalvarezrdale: or to change the cache key when changing the artifact metadata, so that it rebuilds16:05
rdaleyes, i think there is a cache key version in ybd16:06
paulsherwoodthere is, i didn't increment it because i couldn't see a breakage16:07
paulsherwoodis it possible to have private repos on a public trove?16:17
rjekActually, doesn't have a cgit.  At least, it doesn't have one that works16:18
paulsherwood(eg customer/linux, with no leakage via the apis or cgit)16:18
rjekpaulsherwood: gitano does, Trove might be able to16:18
ssam2cgit visibility is all-or-nothing16:19
ssam2you'd have to disable cgit16:19
paulsherwoodah, like :)16:19
*** ctbruce has quit IRC16:19
ssam2a cgit plugin could be written to make cgit cleverer16:19
paulsherwoodok thanks :-)16:19
ssam2other than that, I think everything goes through Gitano so should be fine16:19
ssam2actually I wonder if morph-cache-server also needs to be smarter16:20
ssam2that might leak stuff16:20
ssam2it doesn't have a "list all repos" method, so it's not major, but I think if you had a list of repos you thought might exist, you could work out whether they exist or not by calling the morph-cache-server API16:22
pedroalvarezssam2: and.. maybe list the files of a repo? show the contents of a file?16:22
ssam2actually yes16:23
ssam2I seem to have built an armv6 Aborignal16:55
ssam2tomorrow i'll see if i can build any Baserocks with it16:55
paulsherwoodssam2: using tristan's work?16:56
paulsherwoodcool :)16:56
gtristanssam2, if you have plenty of ram... you might try setting ybd's 'workers' directory to be in a ramfs16:58
gtristanit would take up about 2GB per worker (per 'instance')16:59
paulsherwoodbest to try this on aws, i would think16:59
gtristanand then the swap would be on a ramfs16:59
ssam2if the goal is for developers to use this, it should be able to run on my laptop, surely?17:00
ssam2i have other stuff i can do while waiting for builds17:00
*** toscalix has quit IRC17:05
*** jonathanmaw has quit IRC17:06
*** ssam2 has quit IRC17:07
*** edcragg has quit IRC17:14
*** locallycompact has quit IRC17:25
jjardonHi, is it expected to have the /usr/lib/mason-setup/ folder in the -build systems?17:33
pedroalvarezjjardon: a quick git grep says:17:44
pedroalvarezextensions/mason.configure:mkdir -p "$ROOT/usr/lib/mason-setup"17:44
jjardonpedroalvarez: does build systems need the mason extension?17:45
pedroalvarezonly if you want to deploy a mason17:45
*** ctbruce has joined #baserock17:56
*** ctbruce has quit IRC18:05
*** rdale has quit IRC18:34
*** edcragg has joined #baserock20:03
*** gtristan has quit IRC22:05
*** gtristan has joined #baserock22:40

Generated by 2.15.3 by Marius Gedminas - find it at!