IRC logs for #baserock for Monday, 2015-08-31

*** zoli__ has joined #baserock06:29
radiofreepaulsherwood: to deploy with ybd, it's just clusters/my-upgrade-cluster.morph ?10:32
radiofreei get "KeyError: 'type'" when using jetson-upgrade10:34
radiofreeok looks like ybd doesn't like the "upgrade-type" and "upgrade-location"10:35
radiofreeand upgrades don't appear to be backwards compatible, failed on `system-version-manager list --json`10:36
* radiofree isn't entirely sure which version of system-version-manager supports list --json10:37
* radiofree hacks the call to system-version-manager out for now10:40
radiofreethe good news is the armv7lhf image build on the aarch64 mustang works :D10:44
* paulsherwood hasn't done any deployments for a while10:52
radiofreeyeah i think this is a bug11:01
radiofreemaster of system-version-manager didn't seem to support --json either11:01
radiofreewhat is the way of telling morph to download everything before you start a build11:17
radiofree`[12:01.10] <Kinnison> morph --git-resolve-cache-server=http://nopenopenope/ build system-i-want-to-build-offline`11:22
radiofreeso if this old morph.log on a jetson is anything to go buy, the mustang builds gcc in half the time11:42
radiofreewhich is nice11:42
paulsherwoodcan you post the full log?12:03
radiofreei'll post it in reply on the list12:05
radiofreedo you think 770K is too big?12:05
radiofreehmm.. no one is on dialup anymore12:05
radiofreeok, it is too big     Message body is too big: 1052398 bytes with a limit of 1024 KB12:07
paulsherwoodah, ok12:08
radiofreei'll just e-mail it to you directly thinks it's too big as well12:08
paulsherwoodradiofree: if you can just put it 'anywhere' - i'm collecting build logs at
paulsherwoodradiofree: kewl!12:11
* radiofree finds
radiofreewebgl, running in a qt5 webbrowser, on a jetson, with nouveau!12:13
radiofreei also had youtube working in that session as well, not sure if i recorded that though12:13
paulsherwoodthat's awesome :)12:14
radiofreepaulsherwood: regarding ybd build space requirements, for devel-system-armv7lhf-jetson.morph12:43
radiofreefirst comparable results in jetson v mustang12:47
paulsherwoodradiofree: interesting. so mustang approx twice as fast for compile, because it's using approx twice as many cores12:51
radiofreelooks like it, also the mustang has 16G of RAM compared to 4 on a jetson, so webkit should be able to build without max-jobs: 1 on this12:53
paulsherwoodin other news, i'm starting to think that any ybd instance should be able to act as an artifact-server12:53
radiofreeso i'd be able to log into another jetson and tell it where the location of another jetson/mustang where i've just build an image, and it would use that?12:54
radiofreethat sounds very good12:55
radiofreemake it configurable though, `systemctl enable ybd-artifact-server`12:55
radiofreesome people might not like having some server running by default12:55
paulsherwoodagreed... but in the meantime...*12:56
radiofreecan i try that on the mustang?12:56
paulsherwoodthat's a ybd instance at scaleway12:56
paulsherwoodyup, should work. git pull latest ybd12:57
radiofreehow do i start the server?12:57
paulsherwoodyou'll have to frab with conf files abit12:57
paulsherwoodserver is artifactserver/kbas.py12:57
paulsherwoodit needs to know which directory to serve12:58
paulsherwoodso edit the kbas.conf file12:58
paulsherwoodi need to make the defaults more robust12:58
paulsherwoodand document it12:58
paulsherwoodand the server is currently blocking, so not ideal12:59
radiofreeis the cache key generation different?13:08
radiofreein latest ybd13:08
radiofreewhat i was trying to do was to assembly an armv7lhf image on my x86 laptop using the cache from the mustang13:10
radiofreehowever ybd thinks the cache key for stage1-binutils should be something else13:10
radiofree [stage1-binutils] WARNING: no tree from cache-server 5500a97a2ad1735db5b35bc51cfb825c1f4c38df13:11
radiofreeon the mustang it's efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a13:11
radiofreewhich matches up with the jetson, maybe host architecture is influencing it here?13:11
radiofreeactually i got the same message from the jetson when building initially (15-08-31 11:32:05 [stage1-binutils] WARNING: no tree from cache-server 5500a97a2ad1735db5b35bc51cfb825c1f4c38df)13:13
radiofreeand then13:13
radiofree1 11:32:16 [stage1-binutils] Cache_key is stage1-binutils.427b4336a6b82928bf1f45ba6ce4e1497eedba0f217e426bf83586f04a42142913:13
radiofreehowever the generated artifact was stage1-binutils.efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a13:13
radiofreeaaaah... initially it looks for the actually git tree13:19
paulsherwoodok several things there, radiofree :)13:27
paulsherwood[stage1-binutils] WARNING: no tree from cache-server 5500a97a2ad1735db5b35bc51cfb825c1f4c38df13:27
paulsherwoodthat's a git commit sha, it's trying to work out the tree for that by asking the 'cache server' at (which isn't serving anything to do with caches)13:28
paulsherwoodregarding the cache-key, it depends what arch you're specifying. i assume you didn't expressly state armv7hf when running ybd on x86_64?13:30
* paulsherwood is a bit confused by generated artifact having different cache-key... if that's true it's a bug13:34
* paulsherwood thinks radiofree may be comparing two different artifacts. efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a is present in the mustang log, but 427b4336a6b82928bf1f45ba6ce4e1497eedba0f217e426bf83586f04a421429 is not13:37
*** zoli__ has quit IRC14:14
*** lmackenzie_2015 has joined #baserock14:39
*** zoli__ has joined #baserock15:00
*** lmackenzie_2015 has quit IRC15:28
*** rdale has joined #baserock17:43
*** rdale has quit IRC17:54
*** zoli__ has quit IRC19:03
*** zoli__ has joined #baserock20:24
*** rdale has joined #baserock20:39
*** petefoth_ has joined #baserock21:36
*** petefoth has quit IRC21:37
*** petefoth_ is now known as petefoth21:37
*** zoli__ has quit IRC21:53

Generated by 2.14.0 by Marius Gedminas - find it at!