IRC logs for #baserock for Wednesday, 2015-10-14

*** gtristan has joined #baserock02:02
*** zoli_ has joined #baserock05:42
jjardonpedroalvarez: check wayland-gdp depends on input-common05:43
*** zoli_ has quit IRC06:23
*** gtristan has quit IRC06:40
*** paulwaters_ has joined #baserock06:43
*** ssam2 has joined #baserock07:08
*** ChanServ sets mode: +v ssam207:08
pedroalvarezjjardon: thanks for the hint. I'll take a look at that07:15
pedroalvarezjjardon: I finally managed to get the drm backend working on rpi2, but with some horrible patches on top, and it's not very stable :/07:16
*** gtristan has joined #baserock07:30
*** edcragg has joined #baserock07:48
*** CTbruce has joined #baserock07:52
*** CTbruce has quit IRC07:54
*** ctbruce has joined #baserock07:54
* paulsherwood finds consistent broken build at westongdp07:56
*** jonathanmaw has joined #baserock07:56
*** toscalix__ has joined #baserock07:57
paulsherwoodjonathanmaw: ^^ any ideas?08:00
jonathanmawpaulsherwood: the weston-gdp build failure?08:00
jonathanmawmy first guess is that it's because it shares the same chunk name as another weston in definitions, so ybd picked the wrong one (hence libinput dependency problems)08:01
jonathanmawI'm looking to see whether that's the case08:01
paulsherwoodi see muliple definitions of libinput, not of westin08:04
paulsherwoodstill, if we're going to continue allowing multiple definitions of foo, this is a bug in ybd08:05
*** bashrc_ has joined #baserock08:05
*** franred has joined #baserock08:09
persiaI don't think we should permit multiple defintions of foo: it's confusing to humans as well as tools.08:09
paulsherwoodi agree, but definitions has been in that state forever08:10
paulsherwoodand in the real world, if we have, say an openstack system and an openwrt system and a genivi system, they may not all agree on version of foo08:14
jonathanmawit looks like we're using the wrong version of libinput - ybd used the one in input-common, when it should have used the one from input-genivi08:14
paulsherwoodjonathanmaw: any objection to us renaming libinput => libinput genivi ?08:14
paulsherwoodlibinput-genivi, or libinput@genivi08:15
jonathanmawmy guess is because ybd looked for the chunk named "libinput", not the chunk named "libinput" inside the current strata08:15
jonathanmawI'll try with libinput@genivi08:15
paulsherwoodif you push that, i can build it too08:16
jonathanmawlooks like weston built08:21
paulsherwoodyup, for me too08:21
pedroalvarezweston-gdp name on the strata and in the chunk differ08:21
pedroalvarezstrata/weston-genivi-gdp.morph has "name: weston" for the weston chunk, but "strata/weston-genivi/weston-gdp.morph" has "name: weston-gdp"08:24
pedroalvarezand now I see the libinput problem you were talking about08:25
paulsherwoodjonathanmaw: i guess we should fix that08:28
jonathanmawok, changing the chunk spec in the weston-genivi-gdp stratum to be named "weston-gdp"08:34
* paulsherwood waits for the push08:35
* paulsherwood waits for the push08:36
paulsherwoodsorry... i'm not impatient... faulty keypresses08:36
* pedroalvarez is working on a rebased version of the gdp branch08:37
pedroalvarezto see what problems we are going to face beforehand08:37
paulsherwoodpedroalvarez: with jonathanmaw's changes?08:37
paulsherwood[weston] ERROR: No definition found for weston08:39
pedroalvarezjonathanmaw: I think there is a build-dependency on the same stratum that also should be chaned to weston-gdp08:39
jonathanmawgah! so there is!08:40
jonathanmawpushed again ¬_¬08:40
* paulsherwood and pedroalvarez are contributing to this discussion to cheer ourselves up while in a meeting :)08:40
pedroalvarezthat is actually true08:40
pedroalvarezpaulsherwood: do we know how long takes to build the qt stuff in moonshot?08:41
pedroalvarezaround 40 minutes :)08:43
paulsherwood15-10-13 02:15:21 [42/322/322] [qtwebkit] Elapsed time for build of qtwebkit.01684e28d15542557e00826028910ff0e02e1ee4b2167e9b0612e47fe58cd3d4 00:40:1608:43
pedroalvarezlet's use that monster to build our stuff!08:44
paulsherwoodpedroalvarez: i have five of them at themoment. can create another few if we need them08:46
jonathanmaw\o/ system artifact assembled!08:47
paulsherwoodhere too... x5 :)08:47
paulsherwooddoes it blend, though?08:47
*** mariaderidder has joined #baserock08:48
* jonathanmaw tries the cluster morph08:49
pedroalvarezsuspense music playing08:50
jonathanmawit took 21 seconds to not do much...08:50
paulsherwoodwhat's in your cluster?08:50
*** toscalix__ is now known as toscalix08:53
* paulsherwood may have broken deploy lately08:56
* jonathanmaw hides under a desk and waits for the world to end08:57
*** tiagogomes has joined #baserock08:57
paulsherwoodjonathanmaw: try an older version of ybd, just to humour me, say 15.3808:58
paulsherwoodwhere's radiofree when we need 'im? :)09:02
jonathanmawfor lack of ability to deploy, I've decided to see what happens when I rebase against master and try building09:09
jonathanmawI seem to be in multimedia, at the moment09:09
paulsherwoodjonathanmaw: can you paste your deploy output?09:10
*** gtristan has quit IRC10:00
*** gtristan has joined #baserock10:16
paulsherwoodcouple of quick morph questions...10:30
paulsherwoodin the absence of any config, which directory does  'Fetching to local cache' use?10:30
paulsherwoodand does anyone know what the actual url is that morph creates to request a given artifact foo?10:31
SotK1) I think `~/.cache/morph/artifacts` or similar10:32
SotK2) `$ARTIFACT_CACHE_SERVER/1.0/artifacts?filename=foo` I think10:34
SotKwhere $ARTIFACT_CACHE_SERVER is the value of artifact-cache-server in your config10:35
paulsherwoodok, i'll try that, tvm10:35
pedroalvarezI wonder if morph does a check before fetching10:36
pedroalvareztries, and if that doesn't work then continues10:38
pedroalvarezand SotK answer to 2) looks right looking at the code10:39
pedroalvarezpaulsherwood: it think the default location for the artifacts is "/tmp/morph_tmp/chunks"11:07
paulsherwoodpedroalvarez: i think SotK was correct, actually11:07
pedroalvarezmm.. ok, I wonder why they are not going in there in my environment11:08
paulsherwoodmaybe you have a morph.conf file?11:10
pedroalvarezI do have a morph.conf file but just to set up the cache server11:11
pedroalvarezhm.. I found this:
pedroalvarezno, it doesn prove I'm right11:13
pedroalvarezlet me research a bit more11:13
*** gary_perkins has quit IRC11:14
*** gary_perkins has joined #baserock11:15
pedroalvarezhah, I see. my cachedir is /home/ubuntu/.cache/morph/, but that is being created inside of the chroot, where the ubuntu user doesn't exist11:20
SotKpedroalvarez: /tmp/morph_tmp/chunks is the chunk hardlink cache IIRC11:22
pedroalvarezit is11:23
pedroalvarezsorry for the confusion11:23
*** ssam2 has quit IRC11:33
* gtristan just submitted a few gerrit patches (hopefully less of a mess than last time !) which integrate GDM in the gnome-system-x86_64 build11:50
gtristanonly 4 patches this time, and pretty isolated11:50
pedroalvarezgtristan: good11:51
gtristancurrently I did not enable gdm by default, since it doesnt really work without first creating a user11:51
* paulsherwood can has* serving artifacts..... TO MORPH!!!!!11:51
pedroalvarezgtristan: there is still a bug on your latest patch series11:51
pedroalvarezwhich has been merged11:51
gtristanpedroalvarez, which one... is it the dependency order thing ?11:52
* gtristan though jjardon fixed that11:52
pedroalvarezgtristan: "gnome-shell" has gitmodules11:52
gtristanhmmm, this part is tricky for me :-/11:52
pedroalvarezI can take a look at that, but not right now11:53
pedroalvarezgtristan: oh, because you don't have push access to g.b.o, right?11:53
gtristanpedroalvarez, afaics, the baserock strategy is to include a delta/patch which changes that on correct ?11:53
pedroalvarezpaulsherwood: woot!11:53
pedroalvarezgtristan: yup11:53
jjardongtristan: pedroalvarez there is a patch in gerrit to fix that11:53
pedroalvarezjjardon: nice, sorry for not  checking before11:53
* SotK wonders how paulsherwood did that11:53
gtristanpedroalvarez, right basically... actually I have to write another email to the list about that - we need some CI strategy for cases where we want to automatically rebase our gitmodule patches (or, perhaps handle the gitmodules differently than with deltas)11:54
richard_mawgtristan: or to do our own translation of the repository url for the submodules11:55
* gtristan was too busy getting burried under PAM today to give thought to the list :-/11:55
richard_mawthere was a proposal to change the definitions format to allow a method of translating the submodule paths at build time, but it hasn't happened yet11:56
paulsherwoodSotK: i ran morph to build a system... it pulled artifacts from whereever it normally does11:57
SotKpaulsherwood: nice :)11:57
paulsherwoodSotK: then i ran kbas to serve artifacts from the directory where morph put its artifacts11:57
paulsherwoods/kbas/my newly hacked kbas/11:58
paulsherwoodSotK: and then `morph build systems/base-system-armv7lhf-highbank.morph --artifact-cache-server=`11:58
pedroalvarezgtristan: a lot of things merged :)11:58
gtristanpedroalvarez, so quick !11:59
pedroalvarezI liked you moved from master to tags11:59
* paulsherwood decides he deserves lunch today11:59
* SotK is happy to see kbas moving closer to being a universal artifact cache server11:59
gtristanyeah... well I did pickup on the comments from the last patchset (amid the 300+ emails received) :)11:59
gtristanpedroalvarez, next I will be looking into some CI strategies for the gnome strata (after I get some applications and smooth bootup)... and I am thinking:12:00
gtristanA.) Split up dependencies into a gnome-deps strata separately, with only stable release tags12:01
gtristanB.) Isolate everything that is eligible for CI style builds, and continuously pull from master, but only for gnome.morph12:01
paulsherwoodSotK: noted12:02
gtristanpedroalvarez, I'll bring this up on the list soon, but it's something to think about, perhaps we will want a gnome-stable/ and gnome-continuous/ directory ?12:02
*** persia has quit IRC12:02
SotKgtristan: sounds like a job for CIAT12:03
pedroalvarezSotK: shh!! the more help we have the better!12:03
gtristanhahah, yes well I'm sure CIAT will have something to do with it12:03
*** persia has joined #baserock12:03
pedroalvarezgtristan: moving the deps to gnome-deps makes a lot of sense to me12:04
gtristanthere needs to be some automation, but also there needs to be some strategy in definitions12:04
pedroalvarezabout gnome-stable and gnome-continuous.. would they be the same but one of them using master and the other using tags?12:04
gtristanpedroalvarez, its just a random off-the-top-of-my-head idea, but basically that was the idea yeah12:04
gtristanone would be dedicated to being overwritten by some automated process (-continuous) and the other would be stable release tags only12:05
pedroalvarezI'believe jjardon's dream is to go with latest master for everything12:05
gtristanI think that has about 0.1% chance of booting (if you really mean *everything*)12:06
pedroalvarezmaybe we can configure CIAT to:12:06
pedroalvarez1) check that master keeps building12:06
pedroalvarez2) Propose changes only for new tags12:06
pedroalvareznono, everything for gnome12:06
pedroalvarezso it will at least boot :)12:07
gtristanwell - I think there is value in both to be honest12:07
pedroalvarezI believe we have been using master on systemd and linux having as a result fully working systems12:08
gtristanthey are different goals of course12:08
gtristanthere is also the aspect/possibility of tagging the definitions repository at auto-build time, so that a given 'nightly' build or such can be exactly reproducible at a later date12:09
gtristananyway I am getting a bit ahead of myself :)12:10
jonathanmawI'm updating the GENIVI Demo Platform morphs to the latest master, and it's complaining about not defining the build system. I take it I should be running the migrations to fix that. How do I run the migrations?12:11
jjardonabout not booting: for reference gnome-continuous builds master of everything (with some temporal exceptions) from systemd up12:12
pedroalvarezjonathanmaw: `./migrations/run-all`12:13
pedroalvarezjonathanmaw: if you have rebaed, then your VERSION file will have version: 6, and then ignore the migrations from 5 to 612:13
jonathanmawso I should run the migrations, then rebase, correct?12:14
SotKjonathanmaw: has a suggested workflow12:14
SotKidk if thats actually useful in this situation though12:15
jjardongtristan: IMHO, tracking master is the only way baserock can be useful to contribute upstream12:15
jonathanmawhrm, no module named ruamel.yaml12:16
jonathanmawpython with a makefile? weird.12:17
pedroalvarezjonathanmaw: my rebase here: baserock/pedroalvarez/gdp-rebase-wip12:17
pedroalvarezthis hack make it build
gtristanjjardon, if it actually builds more than 1 time out of 10 then that may be viable, but I still tend to disagree12:18
gtristanjjardon, for instance, take the perspective of a GNOME module maintainer, Am I really interested to know that my software breaks when built againt a low level unstable package ?12:18
gtristanI dont think so12:18
gtristanthe reverse is also true12:18
jjardongtristan: mmm, I think disagree: Im interesed in notify mesa devels that a change in its driver broke gnome-shell12:19
gtristanit becomes interesting though, when you take the whole system, and do separate CI for say, Xorg - this tells Xorg developers that *their* latest master may have problems with *stable* dependencies and cause problems in *stable* GNOME, which is more useful12:19
gtristanright, and I would rather root out noise coming from notifying mesa developers about breakage in unstable highlevel soft12:20
toscalixgtristan: I would be interested in evaluate the integration agains a lower level component that is instable if it brings a new feature that I am interested on12:22
gtristanand anyway, this is really only CI related12:22
toscalixI would also be interested depdnding on the release cycle of my project compared to the release cycle of the lower level *in the stack( component12:23
gtristanthere are a lot of ifs12:23
toscalixgtristan: agree12:24
gtristanone becomes dependent on bleeding edge dependencies when one branches away from stable, *sometimes*12:24
gtristanthis is hopefully advertised in a modules configure script, too12:24
toscalixAm I really interested to know that my software breaks when built againt a low level unstable package ? Sometimes12:25
* jonathanmaw is not sure how to install ruamel (so that migrations can run). I ended up with a load of .egg files in /usr/lib/python2.7/site-packages, but "import ruamel.yaml as yaml" throws "ImportError: No module named yaml"12:26
gtristanjjardon, to be honest though, *personally* I am more interested in baserock's capability of creating a repeatable/stable system, if I were to use it for embedded, the flipside is, "Are we good at producing a stable firmware"12:26
jjardonthink big: if everyone work in master, all the components gets integrated all the time, so you dont need to spend large amount of time integrating stuff: for example, gcc developers doesnt get a lot of feedback of the software they are releasing until is packaged by the distros and they start to rebuild everything; Im sure it would interesting for them check12:27
jjardonif a commit breaks a lot of other components or not12:27
gtristanjjardon, which is why essentially I think they are separate goals - and probably we need some way to separate those "build-stable" and "build-continuous"12:27
jjardonwe can have both worlds; but all master is definelety more challenging12:27
jjardongtristan: yeah, I think we agree12:28
PhlogistiqueIs there a "Why baserock" design document besides ? In particular from reading the docs it looks like Baserock does not embrace cross-developpement and instead prefers developpers to work inside a VM; is there a rationale for that?12:46
toscalixso do you guys agree that we have here two different use cases? 1.- upstream developer that wants to know how her code behaves in its environment (other upstream components. 2.- Linux based embedded system integrators12:46
toscalixjjardon: gtristan did I understand it right?12:47
richard_mawPhlogistique: by cross-development do you mean cross-compiling to build your system to target another CPU architecture to that you build from, or cross-platform where the tooling is expected to be run from a variety of platforms?12:52
Phlogistiquerichard_maw: the former12:53
gtristantoscalix, on that much I think we agree; I dont see the tool as very useful if I cannot get a reliable base system and build my $product on top of it, and I think it's interesting to have CI of upstream third parties as a side-effect12:53
jjardontoscalix: I think so, but I think they overlap in a lot of cases: you want to work close to upstream if you want to add support to a new driver/hardware12:53
gtristantoscalix, probably, my own priority is the opposite of jjardon's12:54
toscalixone of things I am interesting in figuring out is how much they overlap. That would help us to establish priorities in the near future12:54
gtristanfor instance, I want to take my $product deployed using baserock, and run my own CI against the *latest stable* upstream baseline too12:54
toscalixI assume that we have developers which personal interest is upstream development vs other which have "heartbeat piple" as main motivation12:55
richard_mawPhlogistique: ah, then the rationale for that is that there's many projects that dont cross-compile successfully without patching, and the patches may not be acceptable by upstream, since they don't habitually cross-compile. We instead prefer native builds so that it's easier to update those components to new versions, since we don't need to keep rebasing the cross-compilation support patches.12:56
* gtristan looks up heartbeat piple12:56
jjardontoscalix: basically if you manage to track master of everything successfully, its quite trivial to implement the other use case (keep some chunk without changes)12:56
Zararichard_maw: I didn't ask the original question, but thanks for that, was wondering about it. :)12:57
pedroalvarezpaulsherwood: hm.. my qtwebkit build is taking longer than 40 minutes, I wonder if I have to set up different makeflags or something12:57
toscalixjjardon: I see. That clarification helps12:57
* SotK wonders if the wiki needs that answer on an FAQ page or something12:57
jjardonso thats why I think we should approach the most difficult use case12:57
ZaraSotK: +112:58
gtristantoscalix, "Staying as close to upstream as possible simplifies integration and maintenance at big scale", I believe this to be true, but it's hard to convince people of that12:58
richard_mawPhlogistique: as for why we prefer to work in VMs (or chroots), it's because while we take great efforts to improve reproducibility and reliability with sandboxed builds, for the early bootstrap steps it depends on what you have available in your host system, so we prefer you run the Baserock tools from a known working system12:58
toscalixSotK: we will put some effort in the coming weeks in simplifying the entry point for a newcommer12:59
petefoth Cross-compilation is mentioned (under 'Uncertain wishes') on the Wishlist page
toscalixgtristan: nobody that integrates software will believe you if you put the concept simple and integration in the same sentence13:00
gtristantoscalix, for instance just this summer, we had our downstream of debian jessie as our base system on which we built our $product - to me it seemed a no-brainer to regularly integrate from upstream jessie, but it's amazing the stop energy I encountered there13:00
toscalixand there are very limited proofs of that13:00
toscalixthe other case is easier to sell, maintenance becomes easier13:01
gtristanI mean, we of course have our *own* testing process, and upgrading the OS invalidates *everything*, welcome to a new set of bugs13:01
toscalixgtristan: I get it, I believe13:01
gtristanof course it becomes interesting to have immense validation, if I can test my downstream 'baserock' with the latest 'stable upstream' and automate as much testing as possible - that reduces the stop energy13:03
* SotK hopes that effort will involve creating an FAQ page rather than just tidying up guides :)13:03
* gtristan heads out... it's getting late13:04
gtristaninteresting chat :)13:04
*** gtristan has quit IRC13:05
toscalixSotK: I think we miss an approach that clarifies what is BAserock for, how can benefit certain use cases....13:05
Phlogistiquerichard_maw petefoth: interesting, thanks for the answer13:05
SotKtoscalix: +113:05
toscalixSotK: which will require an exercise of "let's raise our head and look around"13:06
petefothtoscalix: I think we haven't documented that, because we don't really know yet13:06
toscalixpetefoth: we will13:06
toscalixwe need to13:06
toscalixand we will13:06
paulsherwoodpedroalvarez: using ybd or morph?13:09
paulsherwoodpedroalvarez: check if max-jobs is set in the morph file?13:10
pedroalvarezpaulsherwood: do you have a suggestion for the right number on the moonshot?13:10
*** ssam2 has joined #baserock13:10
*** ChanServ sets mode: +v ssam213:10
pedroalvarezi've set it to 8 after realising  that the default is 213:10
paulsherwoodpedroalvarez: max-jobs = number of cores or 9, whichever is less (is my current engineering approximation)13:12
paulsherwoodsomeone should fix morph to not do 1.5*cores.13:12
pedroalvarezI guess morph failed to figure out the number of cores on the chroot because /proc is not mounted13:14
richard_mawpedroalvarez: it's using the wrong API to find out the number of cores then13:16
richard_mawyou don't need to use /proc/cpuinfo13:16
richard_mawthere's the nproc command, which uses the right getconf call13:16
pedroalvarezcpu_count() returns 1 :/13:21
richard_mawpedroalvarez: weird, what version of python are you running there? it should have multiprocessing.cpu_count()13:23
pedroalvarezrichard_maw: I mean, I can import it, and when executing it it returns 1, as number of cores13:24
richard_mawpedroalvarez: multiprocessing, or morphlib?13:25
pedroalvarezrichard_maw: multiprocessing.cpu_count13:26
richard_mawhm, then that's the glibc call returning 113:27
richard_mawbah, that sysconf isn't a nice syscall, it reads it out of /sys13:28
richard_mawso yes, it's falling back to 1 because it's unable to determine it any other way13:29
pedroalvarezjonathanmaw: I managed to do the migration to v6 on "baserock/pedroalvarez/gdp-rebase-wip"13:31
jonathanmawI tried that and it told me I had 404 errors when getting something for qtwayland and audiomanagerdemo, so I fixed that manually13:31
jonathanmawI'm currently building gcc, so that looks like it'll be a long haul13:32
pedroalvarezjonathanmaw: are you using morph?13:33
pedroalvarezon a moonshot chroot?13:33
jonathanmawcurrently on Jetson, looking into starting it on a moonshot chroot13:33
pedroalvarezok, for the moonshot:
pedroalvarezjonathanmaw: for the jetson, use the same artifact-cache-server13:34
paulsherwoodjonathanmaw: may help... but don't move linux-user-chroot13:34
*** paulwaters_ has quit IRC13:56
paulsherwoodjonathanmaw: i've checked that morph builds systems if they're in (say) an automotive directory, rather than the systems dir. could we move all genivi systems to a new automotive dir?13:58
paulsherwood(and clean up strata later)13:58
jonathanmawpaulsherwood: ok, I'll start on that13:59
jonathanmaw(I hope that won't affect cache-keys)13:59
richard_mawit shouldn't13:59
paulsherwooddoesn't seem to14:00
*** CTtpollard has quit IRC14:00
pedroalvarez2015-10-14 14:00:03 [Build 334/370] [qtwebkit] Elapsed time 00:52:3314:00
paulsherwoodtold you... morph is slower than ybd :)14:01
*** fay_ has quit IRC14:01
paulsherwoodto be fair, that might be a different measure... maybe it includes artifact creation etc14:02
pedroalvarezit does, but only the build-commands took 52 minutes14:05
paulsherwoodmax-jobs = 8?14:05
paulsherwoododd, then14:05
pedroalvarezI wonder if anything else slows down a bit the build14:06
pedroalvarezlinux-user-chroot vs chroot14:06
pedroalvarezor writing the stdout somewhere (idk if ybd also does that)14:07
paulsherwoodybd writes to a log14:07
persia(catching up on backscroll): regarding cross-compilation: I don't know of a cross-compiler that generates the same code as a native compiler would generate.  I know of several projects to address this, but even if there are no patches required upstream, the results can differ in surprising ways, and the problems inherent in this have not yet been fully addressed.14:13
pedroalvarezrichard_maw: thanks for your lorry-controller patch14:17
pedroalvarezmakes me happy, I'll don't have to care about the db anymore14:17
* richard_maw prepares a definitions patch14:18
tiagogomeswas morph ever profiled?14:21
richard_mawearly versions were14:21
persiatiagogomes: Parts of it were, several times.  I don't know if all of it was.  I know that some bits were sped up at the cost of others at some points, depending on what was more frequently used and/or painfully slow.14:23
*** fay_ has joined #baserock14:32
paulsherwoodanyone know what the default serial terminal settings shoudl be for a jetson?14:59
pedroalvarezscreen /dev/ttyUSB0 115200 ?15:00
paulsherwoodsplurge of random characters15:01
*** jonathanmaw has quit IRC15:01
pedroalvarezthen it isn't15:01
pedroalvarezhehe, when I forget I try all the possibilities :)15:02
* SotK has always had success with 115200 on a jetson15:02
pedroalvarezyes, just checked and it is 11520015:02
paulsherwoodthat's what i thought. my jetson is misbehaving, then15:03
pedroalvarezI can check that if that's true if you want15:05
pedroalvarezbtw, boost also takes ages to compile?15:05
SotKquite a while, yeah15:05
pedroalvarezlooks like it only uses one core15:09
pedroalvarez[boost] Elapsed time 00:43:1215:10
pedroalvarezdbus-python fails with:
pedroalvarezlooking into that15:15
* pedroalvarez adds audio-bluetooth.morph as dependency for genivi-demo-platform-libs.morph15:18
* paulsherwood establishes that it must be his mac playing silly rather than the jetson15:23
paulsherwoodturned out to be the serial cable15:41
pedroalvarezaha! boost building in 8 cores!15:52
*** fay_ has quit IRC15:56
*** ssam2 has quit IRC15:57
pedroalvarez[boost] Elapsed time 00:10:4916:02
pedroalvarezmuch better16:02
pedroalvarezlooks like I'll be deploying shortly gdp to raspberry pi :)16:08
pedroalvarezpaulsherwood: would it be possible to have that kbas serving morph artifacts in my moonshot node too?16:09
pedroalvarezOr should I push these artifacts to that node16:09
paulsherwoodpedroalvarez: there's broadly two possibilities...16:10
paulsherwood(for ybd)16:10
paulsherwood- upload artifacts as they are built16:10
paulsherwood- run ybd to pull artifacts from another server16:11
paulsherwoodbut are you using morph, or ybd?16:11
paulsherwoodyou could run kbas there, to serve those artifacts16:11
pedroalvarezbut my build just failed :/16:11
pedroalvarezyes, that would be ideal16:12
pedroalvarezI could also run morph-cache-server to be fair16:12
pedroalvarezbuild error:
pedroalvarezlooking into that right now16:13
paulsherwoodfor kbas... ssh in, then in an uptodate checkout of ybd, create a kbas.conf file and set artifact-dir: /src/armv7chroot/root/.cache/morph/artifacts or whatever is the full path16:15
pedroalvarezpaulsherwood: easy! thanks16:16
paulsherwoodmaybe you'll want mode: production as well16:17
paulsherwoodin other news, i'm now running ybd on jetson, downloading cached artifacts from moonshot :)16:18
paulsherwoodwhich is rather faster than building them, i notice16:19
pedroalvarezaudiomanagerdemo building \o/16:19
pedroalvarezit was missing a dependency16:19
*** ctbruce has quit IRC16:20
paulsherwoodnote to self... ybd counter doesn't incrememt on cache downloads16:20
paulsherwood15-10-14 00:19:39 [33/322/322] [genivi-demo-platform-armv7lhf-jetson] Elapsed time for artifact creation 00:03:4016:27
*** franred has quit IRC16:41
*** Stanto has quit IRC16:50
*** richard_maw has quit IRC16:50
*** ctgriffiths has quit IRC16:50
*** dabukalam has quit IRC16:50
*** JPohlmann has quit IRC16:50
*** nowster has quit IRC16:50
*** pedroalvarez has quit IRC16:50
*** benbrown_ has quit IRC16:50
*** pedroalvarez has joined #baserock16:55
*** ChanServ sets mode: +v pedroalvarez16:55
pedroalvarezthis kbas serving morph artifacts works16:56
*** nowster has joined #baserock16:59
*** benbrown_ has joined #baserock16:59
* pedroalvarez deploys gdp to a rpi17:00
pedroalvarezlet's see how it blows up :)17:00
*** mariaderidder has quit IRC17:02
* paulsherwood deploys it to a jetson, using ybd17:02
*** bashrc_ has quit IRC17:04
*** nowster has quit IRC17:07
*** benbrown_ has quit IRC17:07
*** JPohlmann has joined #baserock17:07
*** JPohlmann has joined #baserock17:07
*** richard_maw has joined #baserock17:08
*** ChanServ sets mode: +v richard_maw17:08
*** ctgriffiths has joined #baserock17:08
*** dabukalam has joined #baserock17:08
*** Stanto has joined #baserock17:10
*** nowster has joined #baserock17:10
*** benbrown_ has joined #baserock17:10
paulsherwood/src/definitions # system-version-manager list17:12
paulsherwood[ 5660.123183] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)17:12
paulsherwoodfactory (running)17:13
paulsherwoodfoo-bar (default)17:13
paulsherwooddeploy with (fixed) ybd successful... now to reboot :)17:13
paulsherwoodit boots17:14
paulsherwoodit's beer o'clock17:14
*** gary_perkins has quit IRC17:29
pedroalvarezHmm it look like it works, but this kernel is not stable. Doesn't show anything on the screen17:47
*** edcragg has quit IRC17:59
*** brlogger has joined #baserock19:23
*** toscalix__ has joined #baserock22:30
*** toscalix has quit IRC22:30
*** toscalix__ has quit IRC22:34
*** toscalix__ has joined #baserock22:34
*** petefoth_ has joined #baserock23:58
*** petefoth has quit IRC23:59
*** petefoth_ is now known as petefoth23:59

Generated by 2.14.0 by Marius Gedminas - find it at!