IRC logs for #baserock for Wednesday, 2014-08-13

*** vmeson [~quassel@] has quit [Quit: No Ping reply in 300 seconds.]06:28
*** vmeson [~quassel@] has joined #baserock06:28
*** tiagogomes [~tiagogome@] has joined #baserock07:22
*** TonyHo [607e64bf@gateway/web/freenode/ip.] has joined #baserock07:22
TonyHoHi  is anyone here?  I have a problem when 'morph init'07:24
TonyHoIt hints 'ImportError: No module named cliapp' . It seems the python package is missing?07:25
TonyHoI use the baserock-current-genivi-baseline-x86_64-1.img, want to build the TegraK1 rootfs07:26
*** fay_ [] has joined #baserock07:29
petefothTonyHo: 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 Jetson07:31
rjekTonyHo: Are you running morph inside a Baserock VM, or on another OS?07:32
TonyHo I run the morph in VM07:33
paulsherwoodhi TonyHo07:33
TonyHoHi it's good to see some people here07:34
rjekTonyHo: 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
paulsherwoodso, 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 morph07:36
rjekAh, good catch paulsherwood07:37
paulsherwoodgreat. and you've followed the instructiosn to setup and create /src partition?07:37
TonyHoYes, I have done it, and just checkout the definitions git repo to branch baserock/tegra07:38
TonyHoI refer the, chapter 'How to build GENIVI Baseline for ARMv-7'07:39
paulsherwoodok - let me check  it's a while since i tried that07:40
TonyHoOK :)07:40
paulsherwoodoh dear - those build instructions are quite old :/07:42
paulsherwoodso i guess from your email that you mainly care about Jetson?07:42
paulsherwoodwe haven't yet updated our GENIVI instructions to Jetson - the aim is to have that ready for the next GENIVI AMM07:43
paulsherwoodbut in the meantime there are better instructions for getting starttyed with Jetson...07:43
paulsherwoodthey are not *exactly* for what you're aiming at, but should be close enough to start07:44
paulsherwoodwhen others arrive this morning they can hopefully comment more exactly07:45
TonyHoI see that have a video, demonstrate that the wayland/weston running on the Jesson07:45
TonyHoSo I guess I can reproduce this on Jetson Pro, and I just want to reproduce07:46
paulsherwoodand if you follow
paulsherwoodyou *may* be able to get your board set up as a baserock  devel machine07:47
paulsherwoodhowever i would say that Jetson Pro and Jetson TK1 are not the same - iirc the boot load and flashing processes are different07:47
TonyHoWe can use the old fastboot and kernel to boot07:48
paulsherwoodif it were possible for you i'd strongly suggest the TK1 :)07:48
paulsherwoodTonyHo: yes, you're right07:48
paulsherwoodbut ultimately i expect you may need new kernel etc07:49
paulsherwoodok - good luck, please ping back later07:49
*** fay_ [] has quit [Ping timeout: 245 seconds]07:50
*** fay_ [] has joined #baserock07:51
paulsherwoodTonyHo: actually, maybe James' email could be more help to you
paulsherwoodbut in any case your enquiry has shown we need to updated some instructions here :)07:58
TonyHoYes,but Jams' email don't have a guide a link to guide people build08:00
TonyHoHe gives out the rootfs, but no instruction to build it, and I have no experience with the baserock08:00
TonyHoNow the morph hints that no sufficient space to build08:02
TonyHoDoes now it's night in your location?08:03
rjekTonyHo: It's about 9am.08:06
rjekTonyHo: I imagine Sam or James will be about within an hour.08:06
TonyHoOh, We are 4pm here.08:06
TonyHoI wan to resize the VM sda by execute 'VBoxManage modifyhd baserock-current-devel-x86_64.img --resize 30720 '08:08
TonyHoIt 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
TonyHoIs my commands wrong?08:09
Kinnisonthe .img file is not a VBox hard drive08:09
Kinnisonyou need to VBoxConvert it to a .vdi before you can resize it08:10
KinnisonI'm sure there's instructions somewhere on the wiki08:10
TonyHoYes, it is here:
*** jonathanmaw [] has joined #baserock08:12
KinnisonDid you do: $ VBoxManage convertdd baserock.raw baserock.vdi --format VDI08:12
TonyHo No, I resize it directly08: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
KinnisonVBoxManage can only convert vdi files08:14
Kinnisonyou need to use the convertdd command virt to turn the .img into a .vdi08:14
Kinnisonthen you can resize the .vdi08:14
* Kinnison is not very good at typing this morning08:15
* Kinnison should go find tea08:15
TonyHoShould I convert back to brtfs after resize?08:19
*** jonathanmaw_ [] has joined #baserock08:20
*** jonathanmaw [] has quit [Ping timeout: 264 seconds]08:21
TonyHoI guess I should resize the brtfs after booting the vm?08:21
KinnisonVDI is a container format, the btrfs should survive, and yes, once booted, you need to tell btrfs to resize to the full disk again08:24
jonathanmaw_ is now known as jonathanmaw08:26
pedroalvarezTonyHo: 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
TonyHoIt's not cross-compile?08:36
KinnisonBaserock is explicitly native-compile08:36
Kinnisonin order to reduce deltas08:36
TonyHoOK, thanks08:37
*** jonathanmaw_ [] has joined #baserock08:44
*** jonathanmaw [] has quit [Ping timeout: 255 seconds]08:46
*** jonathanmaw__ [] has joined #baserock08:49
*** jonathanmaw_ [] has quit [Ping timeout: 245 seconds]08:52
*** ssam2 [] has joined #baserock08:54
*** ssam2_ [] has joined #baserock08:57
*** jonathanmaw_ [] has joined #baserock08:58
*** ssam2 [] has quit [Ping timeout: 240 seconds]08:59
*** jonathanmaw__ [] has quit [Ping timeout: 244 seconds]09:00
*** TonyHo [607e64bf@gateway/web/freenode/ip.] has quit [Ping timeout: 246 seconds]09:00
*** jonathanmaw__ [] has joined #baserock09:01
*** ssam2 [] has joined #baserock09:02
*** ssam2 [] has quit [Read error: Connection reset by peer]09:03
*** ssam2_ [] has quit [Ping timeout: 264 seconds]09:04
*** jonathanmaw_ [] has quit [Ping timeout: 272 seconds]09:04
jonathanmaw__ is now known as jonathanmaw09:18
*** flatmush [] has joined #baserock09:20
*** jonathanmaw_ [] has joined #baserock09:31
radiofreeif i use the rawdisk extension and tell it to write to..... say /dev/mmcblk0p109:31
radiofreewould that work?09:31
*** flatmush [] has quit [Ping timeout: 240 seconds]09:33
*** jonathanmaw [] has quit [Ping timeout: 245 seconds]09:33
richard_mawradiofree: it currently treats the existance of the disk as cause to try to upgrade it instead I think09:35
*** jonathanmaw_ [] has quit [Ping timeout: 264 seconds]09:35
radiofreeyes it does09:36
radiofreerichard_maw: if it didn't do that, would it work?09:36
radiofreei 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 environment09:37
*** jonathanmaw_ [] has joined #baserock09:38
*** flatmush [] has joined #baserock09:40
richard_mawradiofree: 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 does09:44
*** fay_ [] has quit [Ping timeout: 272 seconds]09:45
*** ssam2 [] has joined #baserock09:56
*** fay_ [] has joined #baserock09:59
jonathanmaw_ is now known as jonathanmaw10:00
*** fay_ [] has quit [Ping timeout: 260 seconds]10:37
*** jonathanmaw_ [] has joined #baserock10:51
*** flatmush1 [] has joined #baserock10:52
*** jonathanmaw [] has quit [Ping timeout: 255 seconds]10:53
*** flatmush [] has quit [Ping timeout: 255 seconds]10:54
*** flatmush1 [] has quit [Ping timeout: 245 seconds]10:57
*** jonathanmaw_ [] has quit [Ping timeout: 260 seconds]10:57
*** ssam2_ [] has joined #baserock11:00
*** ssam2 [] has quit [Ping timeout: 240 seconds]11:03
*** jonathanmaw_ [] has joined #baserock11:12
*** flatmush [] has joined #baserock11:13
*** fay_ [] has joined #baserock11:28
jonathanmaw_ is now known as jonathanmaw11:30
paulsherwoodrichard_maw: build for edited chunk with uncommitted morph now works, thank you :)13:13
richard_mawno problem13:14
paulsherwoodi still see ERROR: ref foo is invalid ref... for cases where i do git fiddlings (eg detached head) though13:14
richard_mawyou 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 repository13:15
ssam2_regards 'git bisect', there's another approach we could take to achieve the same thing13:15
ssam2_which is check the builds of each commit into an OSTree repo, then bisect across that13:15
paulsherwoodrichard_maw: sure i was just remarking, in case it was unexpected13:15
Kinnisonssam2_: How much resource would be needed to achieve that?13:16
ssam2_same as storing all the cached artifacts in a Trove13:16
ssam2_actually, a lot less because there'd be no duplicate files13:16
KinnisonBut it'd be storing more than we might conceivably store in a Trove13:17
paulsherwoodthat sounds like lots of work - i should have kept quiet13:17
Kinnisonbecause typically we only put individual builds we expect to retain onto a Trove's cache13:17
ssam2_I thought that at least persia would like us to store the artifacts for each commit13:18
ssam2_something to think about for the future, anyway13:18
persiaIndeed.  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
paulsherwoodthat's wrong, though, for a user who just wants to experiment, only publish once it's working13:18
ssam2_OK, when I say "each commit", I mean "each commit of master of definitions.git"13:19
paulsherwoodah ok13:19
ssam2_otherwise, yes :)13:19
paulsherwoodnot sure how that relates to my git bisect use-case though13:19
ssam2_oh, good point13:20
ssam2_it'd work if you had your own Trove which had all your build history on it13:20
ssam2_but, you might not13:20
KinnisonI think commits should only reach master after they have been built by a CI/CD pipeline which stores the artifacts onto git.baserock.org13:21
KinnisonI also think that no more than N arbitrary commits back, plus some fixed-point releases should be retained13:21
Kinnisoni.e. if you bisect back far enough, you'll need to build13:21
paulsherwood+1 i think13:21
persiamaster on a shared repo (organisationally or globally) even.13:21
KinnisonI was only thinking of g.b.o but persia is right, this is applicable at organisational levels too13:22
paulsherwoodi was talking about morph edit foo; then git bisect on foo, not bisecting definitions?13:23
persiaIn that case, artifacts wouldn't be generated, so we'd need a local build.13:23
persiaNote 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
paulsherwoodi can't reasonably expect artifacts for all commits of foo, for all combinaions with other stuff that habe changed and thus affected the cache13:24
Kinnisonpaulsherwood: aah righty13:24
persiapaulsherwood: Depends on the size of your organisation's build cluster :)13:24
paulsherwoodpersia: no, i don't think it does really :)13:25
paulsherwoodpersia: it's not morph edit, it's morph build, imo - but i may be biassed13:25
paulsherwoodanyway i'll be quiet now13:26
* persia is confused13:26
persiaAh, you want morph build to work on current bisect results without modification to definitions?13:27
richard_mawand 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 branch13:27
paulsherwoodpersia: as i described in example 3
persiaI'm happy if it uses the last commit on my current branch, but yeah, changing branches shouldn't break it.13:29
paulsherwoodrichard_maw has already fixed 1 and 4 :-)13:29
persiapaulsherwood: I haven't found a good way to express it yet, but I don't think 2&3 should work.13:30
persiaBut until I can explain how I think it ought work instead, this isn't very useful.13:30
persiaThe core of my concern is that you're asking build to build something that isn't recorded in definitions.13:32
paulsherwoodyes, that's the point - i want to diagnose a problem or try something, without updating definitions. i'm in a workarea, working13:32
persiaWhereas 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
paulsherwoodnice in theory. not much use in practice, i think13:35
paulsherwoodymmv of course13:35
paulsherwoodmy original example of this was tracing when linux stopped building in baserock - sometime between 3.n and 3.n+113:36
persiaUnderstood.  To make it work the way I want requires more tooling, which doesn't exist.13:36
persiaIf there was `morph update-ref` or whatever, you'd just run that between bisect and build.13:37
paulsherwoodlet's leave off, i'm sure folks have more pressing and fun things to do :)13:38
richard_mawpressing yes, fun no13:38
persiaBut I'm a bit closer to having a useful response to the objectionable parts of that mail :)  Maybe tomorrow.13:39
*** fay_ [] has quit [Ping timeout: 260 seconds]14:21
*** fay_ [] has joined #baserock14:38
*** ratmice__ [] has quit [Ping timeout: 245 seconds]14:47
*** ratmice__ [] has joined #baserock14:48
*** fay_ [] has quit [Remote host closed the connection]15:02
radiofreerichard_maw: is it ok to merge the morph changes?16:14
richard_mawradiofree: probably; I'm a little worried that it may break something else, as our test suite doesn't include any VM deployments though16:19
radiofreerichard_maw: ok i'll test with an x86 deployment16:20
richard_mawif that works, then I think it is mergeable16:21
*** jonathanmaw [] has quit [Quit: Leaving]16:21
radiofreerichard_maw: i'll try this at home later, trying to fetch the cache on this connection is going to take a while...16:33
paulsherwoodcan i do a deployment somehow to prove this?16:36
paulsherwoodprobably not, i guess :)16:38
*** ssam2_ [] has quit [Quit: Leaving]16:40
radiofreehi, 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 built16:52
radiofreehmm, maybe it's because i've gone straight to the upgrade16:53
pedroalvarezmaybe because you are using different versions of morph in the initiator and in the distbuild network?16:53
radiofreemy distbuild network was a distbuild network or one, or is the initiator the vm?16:55
radiofreeof one sorry16:56
radiofreei'll upgrade the vm to morph master16:56
pedroalvarezthe initiator is the vim16:56
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]17:00
*** tiagogomes [~tiagogome@] has joined #baserock17:02
*** tiagogomes [~tiagogome@] has quit [Client Quit]17:02
*** flatmush [] has quit [Ping timeout: 245 seconds]17:37
radiofreestarting building a new devel image, sadly from scratch, hopefully will be able to test the changes didnt break anything by the end of the night18:41
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]21:12
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock21:13

Generated by 2.14.0 by Marius Gedminas - find it at!