| *** ctbruce has joined #baserock | 06:59 | |
| *** fay_ has joined #baserock | 07:37 | |
| *** toscalix has joined #baserock | 07:40 | |
| *** rdale has joined #baserock | 08:01 | |
| *** bashrc has joined #baserock | 08:06 | |
| *** edcragg has joined #baserock | 08:34 | |
| *** anahuelamo has joined #baserock | 08:42 | |
| *** jonathanmaw has joined #baserock | 08:59 | |
| pedroalvarez | jjardon: nah, no need, I don't care about the GDP system anymore | 09:00 |
|---|---|---|
| *** ssam2 has joined #baserock | 09:03 | |
| *** ChanServ sets mode: +v ssam2 | 09:03 | |
| *** CTtpollard has joined #baserock | 09:07 | |
| jjardon | understood, but Its not only about GDP systems, its how we can resolve that kind of situations in general in baserock | 09:11 |
| pedroalvarez | jjardon: feel free to start a conversation in the ML | 09:13 |
| *** locallycompact has joined #baserock | 09:29 | |
| edcragg | hi, i'm considering looking at how the mismatch between mkfs.btrfs and syslinux in deployment prevents Baserock from booting on x86 systems | 11:19 |
| edcragg | was hoping to canvas opinion on what is the best way to achieve this | 11:20 |
| edcragg | as 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 flags | 11:21 |
| edcragg | i'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 syslinux | 11:22 |
| pedroalvarez | I 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 |
| pedroalvarez | also, you might be deploying a system for another architecture | 11:25 |
| edcragg | pedroalvarez: it may still be useful to use the target btrfs tools on another architecture (though syslinux is clearly not needed) | 11:26 |
| edcragg | i have ubuntu systems where images created with mkfs.btrfs aren't even mountable on any other system | 11:26 |
| ssam2 | they won't work on another architecture, though | 11:27 |
| ssam2 | e.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 machine | 11:27 |
| edcragg | this is true | 11:28 |
| edcragg | host tools could be a fallback | 11:28 |
| edcragg | it's just that using host tools you are at the mercy of the host distribution | 11:29 |
| ssam2 | that might be an OK workaround for this problem | 11:29 |
| ssam2 | at least the simple case of native deployment would work and be consistent | 11:30 |
| ssam2 | but for cross-deployments, developers might have to hack their distro | 11:30 |
| edcragg | or for systems not containing the required tools (minimal, maybe others) | 11:34 |
| edcragg | a very minimal deployment system could be built as required, and used in a chroot to deploy | 11:40 |
| ssam2 | you mean, YBD / Morph deploy from inside a sandbox, rather than on the host? I think that's the best solution | 11:41 |
| ssam2 | where the sandbox is built by YBD/Morph and contains tools for deployment | 11:41 |
| edcragg | ssam2: indeed | 11:45 |
| *** gary_perkins_ is now known as gary_perkins | 12:53 | |
| *** tiagogomes has quit IRC | 14:35 | |
| *** tiagogomes has joined #baserock | 14:35 | |
| ssam2 | gtristan: around? | 15:01 |
| ssam2 | i'm trying your Aborginal branch | 15:01 |
| ssam2 | but I get a build failure for binutils: http://paste.baserock.org/xafogumega | 15:02 |
| ssam2 | this only occurs with ENABLE_GPLV3, upstream aboriginal and your branch without ENABLE_GPLV3 seem to build fine | 15:02 |
| ssam2 | any tips on debugging this gratefully received | 15:03 |
| gtristan | oh my | 15:20 |
| gtristan | ssam2, do you have dual-toolchain branch or https://github.com/gtristan/aboriginal/tree/extra-changes ? | 15:22 |
| ssam2 | the latter | 15:22 |
| *** locallycompact has quit IRC | 15:24 | |
| gtristan | havent seen that error before, it seems to be occurring in the first stage where you use host tools to build your first cross | 15:24 |
| ssam2 | yeah | 15:25 |
| ssam2 | i've just discovered http://www.landley.net/aboriginal/FAQ.html#debug_logging, will try to triage a bit better | 15:25 |
| gtristan | maybe my compiler knows where to find -lz in a sneaky default link path ? | 15:26 |
| gtristan | ssam2, In sources/utility_functions.. there is dienow() {} ... I find it useful to add ${SHELL} -i to that function | 15:27 |
| ssam2 | oh, nice | 15:28 |
| ssam2 | it seems to actually be using the host 'cc' for this build | 15:28 |
| ssam2 | but, I definitely have the zlib-devel package installed | 15:28 |
| gtristan | it should right, it's the very first | 15:28 |
| ssam2 | oh, hold that thought | 15:29 |
| ssam2 | zlib-devel doesn't seem to contain libz.a on Fedora | 15:29 |
| *** CTtpollard has quit IRC | 15:29 | |
| ssam2 | and this is a static build | 15:29 |
| ssam2 | let me install 'zlib-static' and try again :-) | 15:30 |
| *** CTtpollard has joined #baserock | 15:30 | |
| ssam2 | much better | 15:31 |
| gtristan | :) | 15:31 |
| *** locallycompact has joined #baserock | 15:33 | |
| anahuelamo | Hi, 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: http://paste.baserock.org/anicumuyew | 15:48 |
| anahuelamo | any idea of how to solve it? | 15:48 |
| rjek | Don't use hash tables for all the things when classes are available? :D | 15:49 |
| rjek | tbh, querying a dictionary for a non-existing key throwing an exception is both the best and worst feature of Python. | 15:52 |
| edcragg | anahuelamo: looks like a recent change in ybd probably caused it to break, b46abb313f258975b76eaea9c524e5c049ba0e74 | 15:54 |
| rdale | it looks like 'cache' is a newly added field in the .meta file, and it isn't in the cached version of an artifact | 15:55 |
| edcragg | ah, so rebuild from scratch? | 15:56 |
| rdale | the fix is to version the artifacts, so the the cached version is invalidated | 15:57 |
| paulsherwood | my breakage | 15:57 |
| paulsherwood | anahuelamo: maybe better to drop back to previous tag | 15:58 |
| anahuelamo | ok, I'll do that | 15:58 |
| pedroalvarez | rdale: or to change the cache key when changing the artifact metadata, so that it rebuilds | 16:05 |
| rdale | yes, i think there is a cache key version in ybd | 16:06 |
| paulsherwood | there is, i didn't increment it because i couldn't see a breakage | 16:07 |
| paulsherwood | is it possible to have private repos on a public trove? | 16:17 |
| rjek | Actually, trove.codethink.co.uk doesn't have a cgit. At least, it doesn't have one that works | 16:18 |
| paulsherwood | (eg customer/linux, with no leakage via the apis or cgit) | 16:18 |
| rjek | paulsherwood: gitano does, Trove might be able to | 16:18 |
| ssam2 | cgit visibility is all-or-nothing | 16:19 |
| ssam2 | you'd have to disable cgit | 16:19 |
| paulsherwood | ah, like trove.codethink.co.uk :) | 16:19 |
| ssam2 | yeah | 16:19 |
| *** ctbruce has quit IRC | 16:19 | |
| ssam2 | a cgit plugin could be written to make cgit cleverer | 16:19 |
| paulsherwood | ok thanks :-) | 16:19 |
| ssam2 | other than that, I think everything goes through Gitano so should be fine | 16:19 |
| paulsherwood | ack | 16:20 |
| ssam2 | actually I wonder if morph-cache-server also needs to be smarter | 16:20 |
| ssam2 | that might leak stuff | 16:20 |
| ssam2 | it 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 API | 16:22 |
| pedroalvarez | ssam2: and.. maybe list the files of a repo? show the contents of a file? | 16:22 |
| ssam2 | actually yes | 16:23 |
| ssam2 | I seem to have built an armv6 Aborignal | 16:55 |
| ssam2 | *Aboriginal | 16:55 |
| ssam2 | tomorrow i'll see if i can build any Baserocks with it | 16:55 |
| ssam2 | (hopefully) | 16:55 |
| paulsherwood | ssam2: using tristan's work? | 16:56 |
| ssam2 | yeah | 16:56 |
| paulsherwood | cool :) | 16:56 |
| gtristan | ssam2, if you have plenty of ram... you might try setting ybd's 'workers' directory to be in a ramfs | 16:58 |
| gtristan | it would take up about 2GB per worker (per 'instance') | 16:59 |
| paulsherwood | best to try this on aws, i would think | 16:59 |
| gtristan | and then the swap would be on a ramfs | 16:59 |
| ssam2 | if the goal is for developers to use this, it should be able to run on my laptop, surely? | 17:00 |
| ssam2 | i have other stuff i can do while waiting for builds | 17:00 |
| *** toscalix has quit IRC | 17:05 | |
| *** jonathanmaw has quit IRC | 17:06 | |
| *** ssam2 has quit IRC | 17:07 | |
| *** edcragg has quit IRC | 17:14 | |
| *** locallycompact has quit IRC | 17:25 | |
| jjardon | Hi, is it expected to have the /usr/lib/mason-setup/ folder in the -build systems? | 17:33 |
| pedroalvarez | jjardon: a quick git grep says: | 17:44 |
| pedroalvarez | extensions/mason.configure:mkdir -p "$ROOT/usr/lib/mason-setup" | 17:44 |
| jjardon | pedroalvarez: does build systems need the mason extension? | 17:45 |
| pedroalvarez | only if you want to deploy a mason | 17:45 |
| *** ctbruce has joined #baserock | 17:56 | |
| *** ctbruce has quit IRC | 18:05 | |
| *** rdale has quit IRC | 18:34 | |
| *** edcragg has joined #baserock | 20:03 | |
| *** gtristan has quit IRC | 22:05 | |
| *** gtristan has joined #baserock | 22:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!