| *** zoli__ has joined #baserock | 06:29 | |
| radiofree | paulsherwood: to deploy with ybd, it's just ybd.py clusters/my-upgrade-cluster.morph ? | 10:32 |
|---|---|---|
| radiofree | i get "KeyError: 'type'" when using jetson-upgrade | 10:34 |
| radiofree | ok looks like ybd doesn't like the "upgrade-type" and "upgrade-location" | 10:35 |
| radiofree | and 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 --json | 10:37 | |
| * radiofree hacks the call to system-version-manager out for now | 10:40 | |
| radiofree | the good news is the armv7lhf image build on the aarch64 mustang works :D | 10:44 |
| * paulsherwood hasn't done any deployments for a while | 10:52 | |
| radiofree | yeah i think this is a bug | 11:01 |
| radiofree | master of system-version-manager didn't seem to support --json either | 11:01 |
| radiofree | what is the way of telling morph to download everything before you start a build | 11:17 |
| radiofree | `[12:01.10] <Kinnison> morph --git-resolve-cache-server=http://nopenopenope/ build system-i-want-to-build-offline` | 11:22 |
| radiofree | so if this old morph.log on a jetson is anything to go buy, the mustang builds gcc in half the time | 11:42 |
| radiofree | which is nice | 11:42 |
| paulsherwood | :) | 11:51 |
| paulsherwood | can you post the full log? | 12:03 |
| radiofree | i'll post it in reply on the list | 12:05 |
| radiofree | do you think 770K is too big? | 12:05 |
| radiofree | hmm.. no one is on dialup anymore | 12:05 |
| paulsherwood | paste.baserock.org? | 12:06 |
| radiofree | ok, it is too big Message body is too big: 1052398 bytes with a limit of 1024 KB | 12:07 |
| paulsherwood | ah, ok | 12:08 |
| radiofree | i'll just e-mail it to you directly paste.baserock.org thinks it's too big as well | 12:08 |
| paulsherwood | radiofree: if you can just put it 'anywhere' - i'm collecting build logs at https://github.com/devcurmudgeon/build-logs | 12:08 |
| radiofree | paulsherwood: http://seriousinternetbusiness.com/james/ybd-mustang.log | 12:10 |
| paulsherwood | radiofree: kewl! | 12:11 |
| * radiofree finds http://seriousinternetbusiness.com/james/vids/webgl.mp4 | 12:13 | |
| radiofree | webgl, running in a qt5 webbrowser, on a jetson, with nouveau! | 12:13 |
| radiofree | i also had youtube working in that session as well, not sure if i recorded that though | 12:13 |
| paulsherwood | that's awesome :) | 12:14 |
| radiofree | paulsherwood: regarding ybd build space requirements, for devel-system-armv7lhf-jetson.morph | 12:43 |
| radiofree | http://fpaste.org/261445/14410250/ | 12:43 |
| radiofree | first comparable results in jetson v mustang | 12:47 |
| radiofree | http://fpaste.org/261448/14410252/ | 12:47 |
| paulsherwood | radiofree: interesting. so mustang approx twice as fast for compile, because it's using approx twice as many cores | 12:51 |
| radiofree | looks 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 this | 12:53 |
| paulsherwood | in other news, i'm starting to think that any ybd instance should be able to act as an artifact-server | 12:53 |
| radiofree | so 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 |
| paulsherwood | yup | 12:54 |
| radiofree | that sounds very good | 12:55 |
| radiofree | make it configurable though, `systemctl enable ybd-artifact-server` | 12:55 |
| radiofree | some people might not like having some server running by default | 12:55 |
| paulsherwood | agreed... but in the meantime... http://212.47.246.254/* | 12:56 |
| radiofree | can i try that on the mustang? | 12:56 |
| paulsherwood | that's a ybd instance at scaleway | 12:56 |
| paulsherwood | yup, should work. git pull latest ybd | 12:57 |
| radiofree | how do i start the server? | 12:57 |
| paulsherwood | you'll have to frab with conf files abit | 12:57 |
| paulsherwood | server is artifactserver/kbas.py | 12:57 |
| paulsherwood | it needs to know which directory to serve | 12:58 |
| paulsherwood | so edit the kbas.conf file | 12:58 |
| paulsherwood | i need to make the defaults more robust | 12:58 |
| paulsherwood | and document it | 12:58 |
| paulsherwood | and the server is currently blocking, so not ideal | 12:59 |
| radiofree | is the cache key generation different? | 13:08 |
| radiofree | in latest ybd | 13:08 |
| radiofree | what i was trying to do was to assembly an armv7lhf image on my x86 laptop using the cache from the mustang | 13:10 |
| radiofree | however ybd thinks the cache key for stage1-binutils should be something else | 13:10 |
| radiofree | [stage1-binutils] WARNING: no tree from cache-server 5500a97a2ad1735db5b35bc51cfb825c1f4c38df | 13:11 |
| radiofree | on the mustang it's efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a | 13:11 |
| radiofree | which matches up with the jetson, maybe host architecture is influencing it here? | 13:11 |
| radiofree | actually 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 |
| radiofree | and then | 13:13 |
| radiofree | 1 11:32:16 [stage1-binutils] Cache_key is stage1-binutils.427b4336a6b82928bf1f45ba6ce4e1497eedba0f217e426bf83586f04a421429 | 13:13 |
| radiofree | however the generated artifact was stage1-binutils.efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a | 13:13 |
| radiofree | aaaah... initially it looks for the actually git tree | 13:19 |
| paulsherwood | ok several things there, radiofree :) | 13:27 |
| paulsherwood | [stage1-binutils] WARNING: no tree from cache-server 5500a97a2ad1735db5b35bc51cfb825c1f4c38df | 13:27 |
| paulsherwood | that's a git commit sha, it's trying to work out the tree for that by asking the 'cache server' at git.baserock.org (which isn't serving anything to do with caches) | 13:28 |
| paulsherwood | regarding 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 bug | 13:34 | |
| * paulsherwood thinks radiofree may be comparing two different artifacts. efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a is present in the mustang log, but 427b4336a6b82928bf1f45ba6ce4e1497eedba0f217e426bf83586f04a421429 is not | 13:37 | |
| *** zoli__ has quit IRC | 14:14 | |
| *** lmackenzie_2015 has joined #baserock | 14:39 | |
| *** zoli__ has joined #baserock | 15:00 | |
| *** lmackenzie_2015 has quit IRC | 15:28 | |
| *** rdale has joined #baserock | 17:43 | |
| *** rdale has quit IRC | 17:54 | |
| *** zoli__ has quit IRC | 19:03 | |
| *** zoli__ has joined #baserock | 20:24 | |
| *** rdale has joined #baserock | 20:39 | |
| *** petefoth_ has joined #baserock | 21:36 | |
| *** petefoth has quit IRC | 21:37 | |
| *** petefoth_ is now known as petefoth | 21:37 | |
| *** zoli__ has quit IRC | 21:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!