| *** vmeson [~quassel@128.224.252.2] has quit [Quit: No Ping reply in 300 seconds.] | 06:28 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 06:28 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:22 | |
| *** TonyHo [607e64bf@gateway/web/freenode/ip.96.126.100.191] has joined #baserock | 07:22 | |
| TonyHo | Hi is anyone here? I have a problem when 'morph init' | 07:24 |
|---|---|---|
| TonyHo | It hints 'ImportError: No module named cliapp' . It seems the python package is missing? | 07:25 |
| TonyHo | I use the baserock-current-genivi-baseline-x86_64-1.img, want to build the TegraK1 rootfs | 07:26 |
| *** fay_ [~fay@host86-175-11-242.range86-175.btcentralplus.com] has joined #baserock | 07:29 | |
| petefoth | TonyHo: the gusys who will be able to help wioth this aren't in hte office yet. They should be in fairly soon to give you an answer to this and your emailed enquiry about compiling for Jetson | 07:31 |
| rjek | TonyHo: Are you running morph inside a Baserock VM, or on another OS? | 07:32 |
| TonyHo | I run the morph in VM | 07:33 |
| paulsherwood | hi TonyHo | 07:33 |
| TonyHo | Hi it's good to see some people here | 07:34 |
| paulsherwood | :-) | 07:34 |
| rjek | TonyHo: Hmm, interesting: does the error it produces tell you where it looked? | 07:34 |
| rjek | (I can't remember if Python does that) | 07:34 |
| paulsherwood | so, to be clear - the baseline image is not used to do builds . have you installed a devel machine? | 07:35 |
| TonyHo | Yes, now I'm tring the baserock-current-devel-x86_64.img to morph | 07:36 |
| rjek | Ah, good catch paulsherwood | 07:37 |
| paulsherwood | great. and you've followed the instructiosn to setup and create /src partition? | 07:37 |
| TonyHo | Yes, I have done it, and just checkout the definitions git repo to branch baserock/tegra | 07:38 |
| TonyHo | I refer the http://wiki.baserock.org/genivi/, chapter 'How to build GENIVI Baseline for ARMv-7' | 07:39 |
| paulsherwood | ok - let me check it's a while since i tried that | 07:40 |
| TonyHo | OK :) | 07:40 |
| paulsherwood | oh dear - those build instructions are quite old :/ | 07:42 |
| paulsherwood | so i guess from your email that you mainly care about Jetson? | 07:42 |
| TonyHo | Yes | 07:43 |
| paulsherwood | we haven't yet updated our GENIVI instructions to Jetson - the aim is to have that ready for the next GENIVI AMM | 07:43 |
| paulsherwood | but in the meantime there are better instructions for getting starttyed with Jetson... | 07:43 |
| paulsherwood | http://wiki.baserock.org/guides/jetson_distbuild_cluster/ | 07:44 |
| paulsherwood | they are not *exactly* for what you're aiming at, but should be close enough to start | 07:44 |
| paulsherwood | when others arrive this morning they can hopefully comment more exactly | 07:45 |
| TonyHo | I see that http://wiki.baserock.org/ have a video, demonstrate that the wayland/weston running on the Jesson | 07:45 |
| paulsherwood | yes | 07:46 |
| TonyHo | So I guess I can reproduce this on Jetson Pro, and I just want to reproduce | 07:46 |
| paulsherwood | and if you follow http://wiki.baserock.org/guides/jetson_distbuild_cluster/#index2h1 | 07:46 |
| paulsherwood | you *may* be able to get your board set up as a baserock devel machine | 07:47 |
| TonyHo | OK | 07:47 |
| paulsherwood | however i would say that Jetson Pro and Jetson TK1 are not the same - iirc the boot load and flashing processes are different | 07:47 |
| TonyHo | We can use the old fastboot and kernel to boot | 07:48 |
| paulsherwood | if it were possible for you i'd strongly suggest the TK1 :) | 07:48 |
| paulsherwood | TonyHo: yes, you're right | 07:48 |
| paulsherwood | but ultimately i expect you may need new kernel etc | 07:49 |
| paulsherwood | ok - good luck, please ping back later | 07:49 |
| TonyHo | Fine. | 07:50 |
| *** fay_ [~fay@host86-175-11-242.range86-175.btcentralplus.com] has quit [Ping timeout: 245 seconds] | 07:50 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 07:51 | |
| paulsherwood | TonyHo: actually, maybe James' email could be more help to you http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-June/006529.html | 07:57 |
| paulsherwood | s/James/Sam/ | 07:58 |
| paulsherwood | but in any case your enquiry has shown we need to updated some instructions here :) | 07:58 |
| TonyHo | Yes,but Jams' email don't have a guide a link to guide people build | 08:00 |
| TonyHo | He gives out the rootfs, but no instruction to build it, and I have no experience with the baserock | 08:00 |
| TonyHo | Now the morph hints that no sufficient space to build | 08:02 |
| TonyHo | Does now it's night in your location? | 08:03 |
| rjek | TonyHo: It's about 9am. | 08:06 |
| rjek | TonyHo: I imagine Sam or James will be about within an hour. | 08:06 |
| TonyHo | Oh, We are 4pm here. | 08:06 |
| TonyHo | I wan to resize the VM sda by execute 'VBoxManage modifyhd baserock-current-devel-x86_64.img --resize 30720 ' | 08:08 |
| TonyHo | It hints VBoxManage: error: Could not get the storage format of the medium '/work/TegraK1/VM/baserock-current-devel-x86_64.img' (VERR_NOT_SUPPORTED) | 08:08 |
| TonyHo | Is my commands wrong? | 08:09 |
| Kinnison | the .img file is not a VBox hard drive | 08:09 |
| Kinnison | you need to VBoxConvert it to a .vdi before you can resize it | 08:10 |
| Kinnison | I'm sure there's instructions somewhere on the wiki | 08:10 |
| TonyHo | Yes, it is here: http://wiki.baserock.org/guides/vm-setup/#index7h2 | 08:11 |
| *** jonathanmaw [~jonathanm@host5-81-88-142.range5-81.btcentralplus.com] has joined #baserock | 08:12 | |
| Kinnison | Did you do: $ VBoxManage convertdd baserock.raw baserock.vdi --format VDI | 08:12 |
| Kinnison | ? | 08:12 |
| TonyHo | No, I resize it directly | 08:13 |
| TonyHo | file baserock-current-devel-x86_64.img baserock-current-devel-x86_64.img: BTRFS Filesystem (label "baserock", sectorsize 4096, nodesize 4096, leafsize 4096) | 08:14 |
| Kinnison | VBoxManage can only convert vdi files | 08:14 |
| Kinnison | you need to use the convertdd command virt to turn the .img into a .vdi | 08:14 |
| Kinnison | then you can resize the .vdi | 08:14 |
| TonyHo | OK | 08:14 |
| * Kinnison is not very good at typing this morning | 08:15 | |
| * Kinnison should go find tea | 08:15 | |
| TonyHo | Should I convert back to brtfs after resize? | 08:19 |
| *** jonathanmaw_ [~jonathanm@host5-81-88-142.range5-81.btcentralplus.com] has joined #baserock | 08:20 | |
| *** jonathanmaw [~jonathanm@host5-81-88-142.range5-81.btcentralplus.com] has quit [Ping timeout: 264 seconds] | 08:21 | |
| TonyHo | I guess I should resize the brtfs after booting the vm? | 08:21 |
| Kinnison | VDI is a container format, the btrfs should survive, and yes, once booted, you need to tell btrfs to resize to the full disk again | 08:24 |
| jonathanmaw_ is now known as jonathanmaw | 08:26 | |
| pedroalvarez | hello! | 08:29 |
| pedroalvarez | TonyHo: I think that worth mentioning that if you want to build a system for Jetson (armv7) you need to install a baserock development system in the same architecture to be able to build it. | 08:34 |
| TonyHo | pedroalvarez: Using the VM cannot do this? Should I build in the target board? | 08:36 |
| TonyHo | It's not cross-compile? | 08:36 |
| Kinnison | Baserock is explicitly native-compile | 08:36 |
| Kinnison | in order to reduce deltas | 08:36 |
| TonyHo | OK, thanks | 08:37 |
| *** jonathanmaw_ [~jonathanm@host31-51-83-207.range31-51.btcentralplus.com] has joined #baserock | 08:44 | |
| *** jonathanmaw [~jonathanm@host5-81-88-142.range5-81.btcentralplus.com] has quit [Ping timeout: 255 seconds] | 08:46 | |
| *** jonathanmaw__ [~jonathanm@host86-186-16-192.range86-186.btcentralplus.com] has joined #baserock | 08:49 | |
| *** jonathanmaw_ [~jonathanm@host31-51-83-207.range31-51.btcentralplus.com] has quit [Ping timeout: 245 seconds] | 08:52 | |
| *** ssam2 [~ssam2@host86-186-16-192.range86-186.btcentralplus.com] has joined #baserock | 08:54 | |
| *** ssam2_ [~ssam2@host86-186-16-184.range86-186.btcentralplus.com] has joined #baserock | 08:57 | |
| *** jonathanmaw_ [~jonathanm@host86-186-16-184.range86-186.btcentralplus.com] has joined #baserock | 08:58 | |
| *** ssam2 [~ssam2@host86-186-16-192.range86-186.btcentralplus.com] has quit [Ping timeout: 240 seconds] | 08:59 | |
| *** jonathanmaw__ [~jonathanm@host86-186-16-192.range86-186.btcentralplus.com] has quit [Ping timeout: 244 seconds] | 09:00 | |
| *** TonyHo [607e64bf@gateway/web/freenode/ip.96.126.100.191] has quit [Ping timeout: 246 seconds] | 09:00 | |
| *** jonathanmaw__ [~jonathanm@host81-156-208-245.range81-156.btcentralplus.com] has joined #baserock | 09:01 | |
| *** ssam2 [~ssam2@host81-156-208-245.range81-156.btcentralplus.com] has joined #baserock | 09:02 | |
| *** ssam2 [~ssam2@host81-156-208-245.range81-156.btcentralplus.com] has quit [Read error: Connection reset by peer] | 09:03 | |
| *** ssam2_ [~ssam2@host86-186-16-184.range86-186.btcentralplus.com] has quit [Ping timeout: 264 seconds] | 09:04 | |
| *** jonathanmaw_ [~jonathanm@host86-186-16-184.range86-186.btcentralplus.com] has quit [Ping timeout: 272 seconds] | 09:04 | |
| jonathanmaw__ is now known as jonathanmaw | 09:18 | |
| *** flatmush [~flatmush@host81-156-208-245.range81-156.btcentralplus.com] has joined #baserock | 09:20 | |
| *** jonathanmaw_ [~jonathanm@host81-152-87-124.range81-152.btcentralplus.com] has joined #baserock | 09:31 | |
| radiofree | if i use the rawdisk extension and tell it to write to..... say /dev/mmcblk0p1 | 09:31 |
| radiofree | would that work? | 09:31 |
| *** flatmush [~flatmush@host81-156-208-245.range81-156.btcentralplus.com] has quit [Ping timeout: 240 seconds] | 09:33 | |
| *** jonathanmaw [~jonathanm@host81-156-208-245.range81-156.btcentralplus.com] has quit [Ping timeout: 245 seconds] | 09:33 | |
| richard_maw | radiofree: it currently treats the existance of the disk as cause to try to upgrade it instead I think | 09:35 |
| *** jonathanmaw_ [~jonathanm@host81-152-87-124.range81-152.btcentralplus.com] has quit [Ping timeout: 264 seconds] | 09:35 | |
| radiofree | ah | 09:35 |
| radiofree | yes it does | 09:36 |
| radiofree | richard_maw: if it didn't do that, would it work? | 09:36 |
| radiofree | i was thinking it would be pretty cool to just write to an sd card on this jetson board, reboot and test the system (it checks the sd card before emmc), remove sd and reboot back into the devel environment | 09:37 |
| *** jonathanmaw_ [~jonathanm@host81-147-121-158.range81-147.btcentralplus.com] has joined #baserock | 09:38 | |
| *** flatmush [~flatmush@host81-147-121-158.range81-147.btcentralplus.com] has joined #baserock | 09:40 | |
| richard_maw | radiofree: if we change the logic a little to require UPGRADE=yes in the environment for the disk upgrade logic, we can create and loop a disk image if it doesn't exist and continue to format and install the image if it does | 09:44 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 09:45 | |
| *** ssam2 [~ssam2@92.41.111.102.threembb.co.uk] has joined #baserock | 09:56 | |
| *** fay_ [~fay@host81-147-121-158.range81-147.btcentralplus.com] has joined #baserock | 09:59 | |
| jonathanmaw_ is now known as jonathanmaw | 10:00 | |
| *** fay_ [~fay@host81-147-121-158.range81-147.btcentralplus.com] has quit [Ping timeout: 260 seconds] | 10:37 | |
| *** jonathanmaw_ [~jonathanm@host109-155-211-192.range109-155.btcentralplus.com] has joined #baserock | 10:51 | |
| *** flatmush1 [~flatmush@host109-155-211-192.range109-155.btcentralplus.com] has joined #baserock | 10:52 | |
| *** jonathanmaw [~jonathanm@host81-147-121-158.range81-147.btcentralplus.com] has quit [Ping timeout: 255 seconds] | 10:53 | |
| *** flatmush [~flatmush@host81-147-121-158.range81-147.btcentralplus.com] has quit [Ping timeout: 255 seconds] | 10:54 | |
| *** flatmush1 [~flatmush@host109-155-211-192.range109-155.btcentralplus.com] has quit [Ping timeout: 245 seconds] | 10:57 | |
| *** jonathanmaw_ [~jonathanm@host109-155-211-192.range109-155.btcentralplus.com] has quit [Ping timeout: 260 seconds] | 10:57 | |
| *** ssam2_ [~ssam2@188.29.105.39.threembb.co.uk] has joined #baserock | 11:00 | |
| *** ssam2 [~ssam2@92.41.111.102.threembb.co.uk] has quit [Ping timeout: 240 seconds] | 11:03 | |
| *** jonathanmaw_ [~jonathanm@188.30.132.111.threembb.co.uk] has joined #baserock | 11:12 | |
| *** flatmush [~flatmush@188.30.132.111.threembb.co.uk] has joined #baserock | 11:13 | |
| *** fay_ [~fay@188.30.132.111.threembb.co.uk] has joined #baserock | 11:28 | |
| jonathanmaw_ is now known as jonathanmaw | 11:30 | |
| paulsherwood | richard_maw: build for edited chunk with uncommitted morph now works, thank you :) | 13:13 |
| richard_maw | no problem | 13:14 |
| paulsherwood | i still see ERROR: ref foo is invalid ref... for cases where i do git fiddlings (eg detached head) though | 13:14 |
| richard_maw | you know what impending deadlines we have, so I won't be able to look at that one for now, and the suggested fix to that one was to completely change how morph knows to use the locally checked out version, from matching ref to injecting metadata into the repository | 13:15 |
| ssam2_ | regards 'git bisect', there's another approach we could take to achieve the same thing | 13:15 |
| ssam2_ | which is check the builds of each commit into an OSTree repo, then bisect across that | 13:15 |
| paulsherwood | richard_maw: sure i was just remarking, in case it was unexpected | 13:15 |
| Kinnison | ssam2_: How much resource would be needed to achieve that? | 13:16 |
| ssam2_ | same as storing all the cached artifacts in a Trove | 13:16 |
| ssam2_ | actually, a lot less because there'd be no duplicate files | 13:16 |
| Kinnison | But it'd be storing more than we might conceivably store in a Trove | 13:17 |
| paulsherwood | that sounds like lots of work - i should have kept quiet | 13:17 |
| Kinnison | because typically we only put individual builds we expect to retain onto a Trove's cache | 13:17 |
| Kinnison | no? | 13:17 |
| ssam2_ | I thought that at least persia would like us to store the artifacts for each commit | 13:18 |
| ssam2_ | something to think about for the future, anyway | 13:18 |
| persia | Indeed. The way I use definitions.git master, any time there's a commit without artifacts, I have to build them locally, which I find annoying. | 13:18 |
| paulsherwood | that's wrong, though, for a user who just wants to experiment, only publish once it's working | 13:18 |
| ssam2_ | OK, when I say "each commit", I mean "each commit of master of definitions.git" | 13:19 |
| paulsherwood | ah ok | 13:19 |
| ssam2_ | otherwise, yes :) | 13:19 |
| paulsherwood | not sure how that relates to my git bisect use-case though | 13:19 |
| ssam2_ | oh, good point | 13:20 |
| ssam2_ | it'd work if you had your own Trove which had all your build history on it | 13:20 |
| ssam2_ | but, you might not | 13:20 |
| Kinnison | I think commits should only reach master after they have been built by a CI/CD pipeline which stores the artifacts onto git.baserock.org | 13:21 |
| Kinnison | I also think that no more than N arbitrary commits back, plus some fixed-point releases should be retained | 13:21 |
| Kinnison | i.e. if you bisect back far enough, you'll need to build | 13:21 |
| paulsherwood | +1 i think | 13:21 |
| persia | master on a shared repo (organisationally or globally) even. | 13:21 |
| Kinnison | I was only thinking of g.b.o but persia is right, this is applicable at organisational levels too | 13:22 |
| paulsherwood | i was talking about morph edit foo; then git bisect on foo, not bisecting definitions? | 13:23 |
| persia | In that case, artifacts wouldn't be generated, so we'd need a local build. | 13:23 |
| persia | Note that this works fine today if one ignores morph edit, so it's just a matter of thinking about what we want morph edit to do. | 13:24 |
| paulsherwood | i can't reasonably expect artifacts for all commits of foo, for all combinaions with other stuff that habe changed and thus affected the cache | 13:24 |
| Kinnison | paulsherwood: aah righty | 13:24 |
| persia | paulsherwood: Depends on the size of your organisation's build cluster :) | 13:24 |
| paulsherwood | persia: no, i don't think it does really :) | 13:25 |
| paulsherwood | persia: it's not morph edit, it's morph build, imo - but i may be biassed | 13:25 |
| paulsherwood | anyway i'll be quiet now | 13:26 |
| * persia is confused | 13:26 | |
| persia | Ah, you want morph build to work on current bisect results without modification to definitions? | 13:27 |
| richard_maw | and paul is right that you'd expect the current state of your checkouts to be used, rather than have it not work because you changed the branch | 13:27 |
| paulsherwood | persia: as i described in example 3 http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-August/007413.html | 13:29 |
| persia | I'm happy if it uses the last commit on my current branch, but yeah, changing branches shouldn't break it. | 13:29 |
| paulsherwood | richard_maw has already fixed 1 and 4 :-) | 13:29 |
| persia | paulsherwood: I haven't found a good way to express it yet, but I don't think 2&3 should work. | 13:30 |
| persia | But until I can explain how I think it ought work instead, this isn't very useful. | 13:30 |
| paulsherwood | :-) | 13:31 |
| persia | The core of my concern is that you're asking build to build something that isn't recorded in definitions. | 13:32 |
| paulsherwood | yes, that's the point - i want to diagnose a problem or try something, without updating definitions. i'm in a workarea, working | 13:32 |
| persia | Whereas I think that's explicitly bad: I want definitions updated so that once I have it working, i can share my work without needing to reverify everything anc clean it up. | 13:33 |
| paulsherwood | nice in theory. not much use in practice, i think | 13:35 |
| paulsherwood | ymmv of course | 13:35 |
| paulsherwood | my original example of this was tracing when linux stopped building in baserock - sometime between 3.n and 3.n+1 | 13:36 |
| persia | Understood. To make it work the way I want requires more tooling, which doesn't exist. | 13:36 |
| paulsherwood | (yet) | 13:37 |
| persia | heh. | 13:37 |
| persia | If there was `morph update-ref` or whatever, you'd just run that between bisect and build. | 13:37 |
| paulsherwood | let's leave off, i'm sure folks have more pressing and fun things to do :) | 13:38 |
| richard_maw | pressing yes, fun no | 13:38 |
| paulsherwood | awww | 13:38 |
| persia | But I'm a bit closer to having a useful response to the objectionable parts of that mail :) Maybe tomorrow. | 13:39 |
| *** fay_ [~fay@188.30.132.111.threembb.co.uk] has quit [Ping timeout: 260 seconds] | 14:21 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 14:38 | |
| *** ratmice__ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 245 seconds] | 14:47 | |
| *** ratmice__ [bosshog@nightfall.forlorn.net] has joined #baserock | 14:48 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Remote host closed the connection] | 15:02 | |
| radiofree | richard_maw: is it ok to merge the morph changes? | 16:14 |
| richard_maw | radiofree: probably; I'm a little worried that it may break something else, as our test suite doesn't include any VM deployments though | 16:19 |
| radiofree | richard_maw: ok i'll test with an x86 deployment | 16:20 |
| richard_maw | if that works, then I think it is mergeable | 16:21 |
| *** jonathanmaw [~jonathanm@188.30.132.111.threembb.co.uk] has quit [Quit: Leaving] | 16:21 | |
| radiofree | richard_maw: i'll try this at home later, trying to fetch the cache on this connection is going to take a while... | 16:33 |
| paulsherwood | can i do a deployment somehow to prove this? | 16:36 |
| paulsherwood | probably not, i guess :) | 16:38 |
| *** ssam2_ [~ssam2@188.29.105.39.threembb.co.uk] has quit [Quit: Leaving] | 16:40 | |
| radiofree | hi, i've just built an arm system in an x86 vm with distbuild, however when i try and deploy morph is telling me the system hasn't been built | 16:52 |
| radiofree | hmm, maybe it's because i've gone straight to the upgrade | 16:53 |
| pedroalvarez | maybe because you are using different versions of morph in the initiator and in the distbuild network? | 16:53 |
| radiofree | my distbuild network was a distbuild network or one, or is the initiator the vm? | 16:55 |
| radiofree | of one sorry | 16:56 |
| radiofree | i'll upgrade the vm to morph master | 16:56 |
| pedroalvarez | the initiator is the vim | 16:56 |
| pedroalvarez | s/vim/vm/ | 16:56 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 17:00 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 17:02 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Client Quit] | 17:02 | |
| *** flatmush [~flatmush@188.30.132.111.threembb.co.uk] has quit [Ping timeout: 245 seconds] | 17:37 | |
| radiofree | starting building a new devel image, sadly from scratch, hopefully will be able to test the changes didnt break anything by the end of the night | 18:41 |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 21:12 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 21:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!