IRC logs for #baserock for Friday, 2014-09-26

*** petefotheringham [] has joined #baserock04:34
petefotheringham is now known as petefoth05:01
*** pedroalvarez [] has quit [No Ping reply in 180 seconds.]06:28
*** pedroalvarez [] has joined #baserock06:29
Mode #baserock +cnt by card.freenode.net06:29
*** paulsherwood [] has joined #baserock06:30
*** SotK [] has joined #baserock06:46
petefothAm I correct in thinking that the `morph` commands `build-morphology' and 'distbuild-morphology' are no longed needed / used?07:13
SotKwe use them when we make releases to ensure that the releases don't end up with any uncommitted changes or file:// refs in afaik07:14
petefothHow does that work? Are we using them in a negative sense? I'm not sure of the exact differences between 'build' and 'build-morphology'. Is it that build doesn;t work with uncommitted changes where build-morhology does?07:21
SotK`morph build <system>` puts any uncommitted changes from local repositories its using into temporary branches which won't exist in the corresponding repo in the Trove07:23
SotK`morph build-morphology <repo> <ref> <system>` builds "system" as it is defined at "ref" in "repo", so unless you force it to use your local (potentially edited) checkout of definitions it will ensure that none of your local changes or local repo paths (ie file:///src/ws/foo/bar/baz) get into the built system07:26
petefothSotK: Thanks. So we could make do with a single build command, with an option --allow-uncommitted-changes (which shoudl default to 'false'07:28
SotKpetefoth: I agree07:29
SotKI think we've talked about that before, but I can't recall any of the discussion07:30
SotKI think that morph distbuild should be `morph build --distbuild-address=armv7-distbuild-network` or similar too tbh, where no --distbuild-address given means run locally07:31
*** paulsher1ood [] has joined #baserock07:31
*** paulsher1ood [] has quit [Client Quit]07:32
paulsherwoodsimpler would be to have a script, only do the release build if git status is clean07:34
paulsherwoodimo we should get out of the habit of re-implementing git stuff with morph commands/options07:35
SotKthat could still have file:// refs in definitions unless we made sure to check for that too07:35
paulsherwoodgit grep 'file:///'07:35
SotKreleases should be done by Mason anyway, and that shouldn't make local changes07:36
paulsherwoodeven better :)07:36
petefothSo we need to decide whether morph build will allow uncommitted changes07:38
paulsherwoodpersia proposed (and i now agree) that we should only build what's currently in git.07:43
paulsherwoodso for messing aroung, one would git commit --amend  repeatedly07:44
paulsherwoodthis approach would be easy to explain, and reduce uncertainty07:44
paulsherwoodSotK: did i hear you say somewhere that the GENIVI FSA build clones and builds navit?07:45
SotKpaulsherwood: you did07:46
SotKthe idea is that it makes it easy to build, you just clone the FSA repo, change to src/script and run make all2, which gets all the build-dependencies installed for you07:47
paulsherwooddid that work for you?07:47
SotKnot in the slightest07:47
paulsherwoodgreat in theory07:48
SotKit uses `sudo apt-get install` to get most things it needs (glibmm, boost, dbus-c++ and other stuff)07:49
SotKit then clones the navigation-service stuff and builds that07:50
SotKwhich in turn clones navit and builds it07:50
SotKhowever in my experience, it got itself all tangled up and tried to build things in the wrong order07:51
SotKand some bits wouldn't build07:51
SotK*however*, there were some commits yesterday and the day before which have made it better07:52
paulsherwoodswitch to cmake? that seems like quite a radical step to take? :)07:55
SotKyeah, but the script is much better than a maze of makefiles07:57
*** dutch_ [] has joined #baserock08:01
dutch_ is now known as ctdutch08:01
*** flatmush [] has quit [Remote host closed the connection]08:07
*** flatmush [] has joined #baserock08:09
*** pdar [] has joined #baserock08:20
*** ssam2 [~ssam2@] has joined #baserock08:26
*** jonathanmaw [] has joined #baserock08:29
ssam2jjardon: thanks for the patches recently08:37
ssam2do you have a system morph you could share that'd allow me to try all of them together ?08:37
ssam2I could work it out from the patches, but I presume you already have one08:38
jjardonssam2: you can build genivi-foundation baseline system08:39
jjardonwell, to try all of the but the NetworkManager one08:39
ssam2yeah, I'll do that and just verify that Weston still works08:39
*** benbrown_ [] has joined #baserock08:39
ssam2might be nice to check X11 too, but I guess we're not actually using X for anything right now08:39
jjardonwell no, you can try that as well to try connman builds correctly as well08:40
jjardonssam2: I did not try X, only wayland and weston08:41
jjardonI will use X soon, so if anything is broken (it should not) I will fix it08:41
jjardonssam2: BTW, the linux-headers patch is needed to build recent versions of systemd, so lets try to merge it even if we have a fix in NetworkManager now08:42
ssam2ok, I'll submit08:43
*** tiagogomes [~tiagogome@] has joined #baserock08:52
paulsherwoodssam2: are we going for your wiki changes?08:55
jjardonssam2: just realize YAML support comments, rigth? Maybe makes sense to rework the llvm patch to document every configuration parameter that we use that is not the default08:56
ssam2paulsherwood: I don't know08:56
paulsherwood+1 from me08:56
ssam2jjardon: yes, definitely makes sense to put comments in the morohology08:56
ssam2paulsherwood: I'll send a mail to the list proposing the change08:57
ssam2I know the wiki change is small, but I feel that there's an accompanying change in mindset that goes with it08:57
ssam2and it needs coordination08:57
jjardonok, I will follow that policy from now on: any configuration different from the default should be documented08:58
ssam2jjardon: it might be better to put the comments as shell comments in the commands fields, rather than in the YAML08:58
ssam2because if a program does `yaml.load(foo);` then it loses all the YAML comments :(08:58
* ssam2 notices that all the comments have been stripped from the GCC morphologies in definitions08:59
jjardonssam2: oh, ok. Is there an example of that approach somewhere?09:00
ssam2I thought the GCC morphs were an example, but clearly not!09:00
ssam2jjardon: i think for systemd it's linux 3.7 rather than linux-api-headers 3.7 that is the requirement09:14
paulsherwoodpedroalvarez: i notice some fails in the public mason, then pass on the same commit - do we understand why?09:17
paulsherwooddo we have too many moving parts here? :)09:18
pedroalvarezpaulsherwood: yeah, this is because g.b.o. was going up and down. and I decided to do a "hack" to use the baserock-clone Trove  running on
pedroalvarezpaulsherwood: and the hack made this errors happen09:19
paulsherwoodpedroalvarez: does mason create artifacts?09:20
pedroalvarezpaulsherwood: mason is a distbuild cluster, it populates an artifact-cache-server (in this case the trove running on with artifacts09:21
paulsherwoodok so if i were to switch to 93, i would get cached artifacts from master assuming mason PASSes?09:22
paulsherwoods/93/93 as my default trove/09:22
paulsherwoodpedroalvarez: further question - any objection to making that mason build genivi baseline instead of (or as well as) devel? istm it spends a lot of time idle.09:28
pedroalvarezI will answer botho of your questions soon, I'm in the middle of something, sorry09:29
pedroalvarezbut I have anwers :)09:29
paulsherwoodssam2: ok09:30
violetaI guess that the "jetson-upgrade.morph" mentioned in the wiki for upgrading baserock it's the same as "./clusters/jetson-upgrade.morph" ?09:43
paulsherwoodistm there may be a bug or two in that09:45
pedroalvarezpaulsherwood: here now09:48
paulsherwoodvioleta: ^^ may or may not help you09:48
* paulsherwood awaits pedroalvarez comments with excitement09:49
pedroalvarezpaulsherwood: If you use the .93 trove ( or only use it as an artifact-cache-server in your morph.conf) you will have cached artifacts from master, but only for devel systems.09:50
pedroalvarezpaulsherwood: If this is not happening, is because Mason doesn't have the latest morph, and you are probably using the latest. There has been a change that affected the cache key of some artifacts09:51
paulsherwoodright, understood09:51
paulsherwoodand the idea of genivi as opposed to devel?09:51
paulsherwoodor as well as?09:51
* paulsherwood wonders about hacking the mason to latest morph09:52
pedroalvarezpaulsherwood: that's a good idea, and actually we tried to do that a week ago (mainly Sam), but we found a problem in disbuild building the genivi-systems, making distbuild crash09:53
pedroalvarezpaulsherwood: hacking mason to latest morph / upgrading mason is possible, but some changes in the morph codebase have broken distbuild. We are going to try to integrate the distbuild tests and fix distbuild so this doesn't happen again.09:54
paulsherwoodok, sorry if i'm rehashing old discussion09:58
pedroalvarezso things to do regarding distbuild: add tests, match distbuild code with latest morph changes, and fix encoding error which prevent us to distbuild genivi.09:59
pedroalvarezpaulsherwood: no worries10:00
paulsherwoodssam2: on your api-headers change?10:17
paulsherwoodmaybe it's me?10:17
richard_mawno, it looks like linux requiring bash10:18
KinnisonIIRC they don't really require bash10:19
KinnisonAt least we can bootstrap them usually with just busybox sh10:19
Kinnisonand a /bin/bash of the form #!/bin/sh\nexec /bin/sh "$@"\n10:19
richard_mawnot with this error10:19
KinnisonOh :-(10:19
richard_mawbusybox ash doesn't support the ERR trap specifier10:20
richard_mawbut tbf, we probably don't need that10:20
*** violeta [] has quit [Ping timeout: 272 seconds]10:21
ssam2paulsherwood: hmm,, amybe I've changed the wrong ref10:23
ssam2oh no, wait10:23
ssam2the problem is that `make mrproper` doesn't work10:23
ssam2but we don't need it to work, since we start from a clean Git checkout10:23
ssam2but I should have changed the morphology. thanks for reviewing this and spotting the mistake!10:24
*** violeta_ [] has joined #baserock10:26
paulsherwoodnp :)10:27
paulsherwoodcan i get a revie on
SotKpaulsherwood: +110:28
Kinnisonlooks okay to me, if you've deployed using it, then +1 from me too10:28
paulsherwoodi haven't, but i expect no-one has been able to deploy with the existing version either tbh10:29
KinnisonI think you're right10:29
paulsherwoodi'm wrestling with ssh weirdness10:29
Kinnisonhostnames with dashes in are a bad thing too10:29
paulsherwoodif someone could merge it, i'll ask a small army to try deploying with it ;)10:30
paulsherwoodKinnison: did i hear a +1 ? :)10:33
paulsherwoodvioleta_: if you're using latest morph and deploying on jetson, could you try the above?10:34
pedroalvarezpaulsherwood: assuming that systems/devel-system-armv7lhf-jetson.morph is present, +110:35
pedroalvarezheheh :)10:36
paulsherwooda beer for whoever merges :)10:36
violeta_paulsherwood, I needed to make that change for it to work, but later I had an ssh problem so I haven't deployed it yet10:36
* Kinnison backs away slowly from the merge button10:36
paulsherwoodweird. i have ssh problems too10:37
pedroalvarezI can help with ssh problems10:37
paulsherwoodthis requires investigation, but it's not related to that change10:37
paulsherwoodKinnison: why did you back away, Kinnison ? other refreshments are possible10:37
Kinnisonpaulsherwood: I know better, there might be a shilling in the bottom of that beer10:38
KinnisonAlso, I'm staring at smartdevice link10:38
Kinnisonbetter not confuse the issue with other merges10:38
pedroalvarezKinnison: is that a -1? otherwise the path already has a +210:39
KinnisonIt is not a -110:39
* Kinnison gave a +110:39
Kinnisonit has +310:39
* pedroalvarez merges10:39
pedroalvarezpaulsherwood: merged in f8eb5d55ef5edc933442f489ae806a5a70d2a0cc, thanks for the patch10:42
paulsherwoodssam2: would you mind pushing a V2 branch, for clarity?10:43
* paulsherwood is confusing himself with git10:43
ssam2in fact, I meant to and then forgot :)10:44
ssam2too much in my head today10:44
paulsherwoodi know the feeling10:45
ssam2i bet :) baserock/sam/linux-api-headers-3.8-v210:45
paulsherwoodon it10:45
*** fay__ [] has quit [Ping timeout: 260 seconds]11:05
*** ssam2 [~ssam2@] has quit [Ping timeout: 260 seconds]11:05
*** violeta__ [] has joined #baserock11:05
*** flatmush [] has quit [Ping timeout: 272 seconds]11:05
*** tpollard_ [] has quit [Ping timeout: 246 seconds]11:05
*** ctdutch [] has quit [Ping timeout: 258 seconds]11:05
*** jonathanmaw [] has quit [Ping timeout: 245 seconds]11:05
*** fay__ [] has joined #baserock11:05
*** tpollard_ [] has joined #baserock11:05
*** violeta_ [] has quit [Ping timeout: 272 seconds]11:05
*** sam__ [] has quit [Ping timeout: 272 seconds]11:05
*** ssam2 [] has joined #baserock11:06
*** ctdutch [] has joined #baserock11:06
*** jonathanmaw [] has joined #baserock11:06
*** sam__ [] has joined #baserock11:06
*** flatmush [] has joined #baserock11:07
*** flatmush [] has quit [Ping timeout: 245 seconds]11:13
*** fay__ [] has quit [Ping timeout: 250 seconds]11:13
*** sam__ [] has quit [Ping timeout: 246 seconds]11:13
*** ssam2 [] has quit [Ping timeout: 272 seconds]11:14
*** ctdutch [] has quit [Ping timeout: 260 seconds]11:14
*** violeta__ [] has quit [Ping timeout: 260 seconds]11:14
*** tpollard_ [] has quit [Ping timeout: 258 seconds]11:14
*** jonathanmaw [] has quit [Ping timeout: 272 seconds]11:14
*** jonathanmaw [] has joined #baserock12:22
*** violeta_ [] has joined #baserock12:26
*** violeta_ [] has quit [Client Quit]12:28
*** violeta_ [] has joined #baserock12:28
*** fay_ [] has joined #baserock12:29
*** CTtpollard [] has joined #baserock12:34
*** dutch_ [] has joined #baserock12:34
* SotK wonders why gcc-tarball is not cached when he built a system just a couple of hours ago12:38
*** fay_ [] has quit [Ping timeout: 245 seconds]12:39
Kinnisonchanged trove?12:39
SotKKinnison: nope12:40
SotKI attempted to deploy an upgrade, which proceeded to take about an hour and a half to try "creating orig subvolume" before I cancelled it to try again with reduced load on my system12:41
*** flatmush [] has joined #baserock12:41
SotKwhen I tried the upgrade again, I got the error about gcc not being cached12:41
SotKrunning morph build again to update my cache has fixed it (with no rebuilding needed)12:42
*** violeta_ [] has quit [Ping timeout: 244 seconds]12:43
*** violeta_ [] has joined #baserock12:44
violeta_ is now known as violeta12:44
*** jonathanmaw_ [] has joined #baserock12:44
*** fay_ [] has joined #baserock12:45
*** tlsa [GAJ2RkPGHr@gateway/shell/pepperfish/x-draikeasjskuayhm] has quit [Ping timeout: 245 seconds]12:45
*** jonathanmaw [] has quit [Ping timeout: 272 seconds]12:46
paulsherwoodSotK: was this on x86?12:50
SotKpaulsherwood: yes12:50
paulsherwoodthat is weird. for future reference, i'd kill any deploy that hadn't succeeded within 15 mins12:50
paulsherwood(devel upgrade, that is)12:51
SotKpaulsherwood: so would I, but I'd gone out to lunch :)12:51
violetawhat can I do to not get asked "root@localhost's password" every time?12:54
*** ssam2 [] has joined #baserock12:54
SotKwhen deploying an upgrade?12:55
SotKssh-copy-id root@localhost12:55
violetayes, thanks12:55
*** tlsa [EwSz9lfVxe@gateway/shell/pepperfish/x-nsbtiexqeqjbdljr] has joined #baserock12:56
jonathanmaw_ is now known as jonathanmaw12:57
paulsherwoodssam2: i've mostly built devel with your api-headers-v2 branch. 2014-09-26 13:16:28 [Build 132/149] [python-requests] Building chunk python-requests13:16
paulsherwooddo i need to deploy and test, or is build enough?13:16
ssam2if it builds, ship it13:21
ssam2it's only changes to header files13:21
paulsherwoodok, +1 from me, then13:21
paulsherwoodshall i reply on the ML?13:21
KinnisonGiven this is linux-kernel-headers and frankly eglibc would have exploded if it'd been awful, I'm fine with that being merged. +113:22
* paulsherwood has built eglibc on two different br machines13:24
ssam2thanks. I'll merge but I want to do 1 fixup, which is to remove the 'make mrproper' line from strata/armv7lhf-cross-toolchain/armv7lhf-cross-linux-api-headers.morph to match the other ones13:25
ssam2to match the other linux-api-header morphs that I already changed13:26
Kinnisonssam2: agreed13:26
violetawho can edit wiki.baserock?13:28
pedroalvarezvioleta: any changes in mind?13:30
violetapedroalvarez, small one, changing "my new version" for "my_new_version" because the command actually doesn't work with spaces13:31
pedroalvarezvioleta: what page?13:31
paulsherwoodpedroalvarez: did you find a solution to my upgrade fail situation on openstack?13:31
pedroalvarezpaulsherwood: I didn't :(13:33
paulsherwoodpedroalvarez: no problem. did you identify what's causing it? maybe i can bruteforce past it?13:33
pedroalvarezvioleta: please, fix it. :)13:33
violetadone \o/13:33
pedroalvarezvioleta: 13:34
pedroalvarezpaulsherwood: the upgrade deployiment is almost using the same code as rawdisk deployment, but is failing to write the new /etc/fstab correctly13:35
pedroalvarezpaulsherwood: maybe i can provide you a bruteforce workaround, but not a fix13:36
paulsherwoodpedroalvarez: no problem. i'll investigate myself13:37
pedroalvarezpaulsherwood: actually! if you put ROOT_DEVICE: /dev/vda in the cluster morphology to do the upgrade, maybe is enough13:37
paulsherwoodooh... ok13:38
pedroalvarezbut this is still a workaround13:38
paulsherwoodis it? couldn't we add that explicitly to upgrade-devel if it works?13:39
paulsherwoodtrying now :)13:39
pedroalvarezpaulsherwood: no, because then upgrades of systems that are using /dev/sda will break13:40
ssam2i think we should have a `morph update-self` command which reads the deployment config from /baserock/deployment.meta and deploys an upgrade with the same config13:41
ssam2disclaimer: it may not be that simple, in practice13:41
paulsherwoodthat would be lovely13:41
pedroalvarezour current upgrade reads from deployment.meta13:42
ssam2does it?13:42
paulsherwoodi expect it does, my test systems have everything except 'src'13:45
paulsherwoodpedroalvarez: W-0-0-T!!!!!13:48
* paulsherwood has successfully built/deployed/rebooted into a test version in the cloud13:48
paulsherwoodi know it's only a tiny step, but it's made my day :)13:49
pedroalvarezgood to hear :)13:51
paulsherwoodnext step... GENIVI in the cloud :)13:52
violetaafter many unsuccessful tries I've managed to deploy my build \o/13:52
pedroalvarezwow! friday and things are working! :D13:53
fay_good news all round :)13:53
paulsherwoodit's early, yet :)13:58
violetapaulsherwood, why did you remove the HOSTNAME in the jetson-upgrade.morph ?14:01
pedroalvarezvioleta: because hostname should be the same one that the system is currently using14:02
violetathe system where I'm building?14:03
violetabecause my system's hostname is baserock-jetson and the new build is only 'baserock'14:04
pedroalvarezhow have you invoked the "upgrade magic"?14:04
violetapedroalvarez, exactly like that14:05
pedroalvarezvioleta: right, I think is incomlete, it should include `jetson.HOSTNAME="$(hostname)`14:06
violetapedroalvarez, ok!14:07
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:07
violetahow do I know how up to date is the system I'm going to build?14:09
paulsherwoodcan you be more precise?14:09
pedroalvarezvioleta: if you are in the definitions repository, you can run `git show` and see from when is the last commit14:10
violetaah, nice14:11
*** doffm [~mdoff@] has joined #baserock14:34
pedroalvarezdoffm: all this packages should be wokring now
pedroalvarezi was going to say: warlock is not under python-packages 14:47
KinnisonCould I get an opinion on please?14:55
KinnisonI've built several systems, both x86_64 and ARM (Jetson) with the change, and deployed and run stuff with it14:56
KinnisonIt updates our cmake to the latest non-3.x build.14:56
Kinnisoncmake 3.x is a larger change than I'm comfortable with at this point14:56
pedroalvarezKinnison: have you done build tests?14:56
* Kinnison has not done a full build on top of a system deployed with the change, no14:57
KinnisonBut since nothing in our bootstrap depends on cmake, I don't see how it could affect it14:57
* pedroalvarez wants a mason building from a "experiments" branch14:57
KinnisonSuch a beast would be v.useful14:57
pedroalvarezKinnison: the commit and the tag are ok, you have my +1 assuming that it works14:58
tlsahas firehose been resurrected on openstack?14:58
*** dutch_ [] has quit [Quit: Quit]14:59
Kinnisontlsa: Not yet14:59
tlsaaww, OK14:59
SotKKinnison: +1 from me too14:59
tlsaI thought firehose was the most usefull and exciting bit14:59
Kinnisontlsa: It's all there waiting.  Our chosen OpenStack provider isn't ready for us to do heavy-lifting on their platform for a little bit yet15:00
jjardontlsa: it is :)15:00
tlsaah, ok15:00
* Kinnison sees a +1 from pedro and a +1 from sotk15:00
* Kinnison shall push15:01
KinnisonThanks guys15:01
Kinnisonpaulsherwood: That change gets you another step closer to building Smart Device Link :-)15:01
pedroalvarezI should submit a patch now for gcc that we are expecting a lot of rebuilds15:02
pedroalvarezs/now for gcc that/for gcc now that/15:02
KinnisonI think cmake was the lowest in the stack of the things I needed15:03
richard_mawpedroalvarez: careful, it'll likely clash with the latest thing ssam2 sent15:04
*** violeta [] has quit [Ping timeout: 272 seconds]15:05
jjardonhi, after rebasing one of my branches against current master , morph build is stuck in "Resolving artifacts" Any idea what could be the problem?15:07
KinnisonCould be a networking issue15:08
KinnisonDo you have debug logging on?  If so, what's in morph.log?15:09
paulsherwoodjjardon: restart?15:09
* paulsherwood hasn't seen that for a long time15:10
* pedroalvarez assumes this is a distbuild15:10
jjardonpaulsherwood: that was the first thing I tried ;) Im trying a smaller branch now, lets see15:10
jjardonpedroalvarez: is the distbuild publicy available ?15:11
pedroalvarezno, we don't have a public distbuild network15:11
jjardonok, nevermind, seems there is something wrong in my GNOME stratum15:12
jjardonpedroalvarez: then I do not have access to it ;)15:13
pedroalvarezjjardon: pardon? :/15:15
paulsherwoodpedroalvarez: jjardon is working in the open15:17
pedroalvarezyeah, my previous comment was to ask if this error was happening in a distbuild or in a local build15:19
pedroalvarezalso, anyone can deploy a distbuild network ( I want to believe that )15:20
pedroalvarezmeh, I was trying to deploy a disk of 4M instead of 4G, and obiously it was failing..15:49
*** ssam2 [] has quit [Quit: Leaving]16:12
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]16:33
*** CTtpollard [] has quit [Quit: Ex-Chat]17:05
*** fay_ [] has quit [Quit: Leaving]17:06
*** jonathanmaw [] has quit [Quit: Leaving]17:09
*** pdar [] has quit [Quit: leaving]17:31
pedroalvarezI just hit this bug:
pedroalvarezNow I'm sad :/20:11
pedroalvarezI should go back to my openstack bubble20:22

Generated by 2.15.3 by Marius Gedminas - find it at!