IRC logs for #baserock for Thursday, 2015-11-12

*** edcragg_ has joined #baserock00:41
*** edcragg has quit IRC00:43
*** edcragg_ has quit IRC01:40
*** gtristan has quit IRC01:50
*** gtristan has joined #baserock02:23
gtristanhmmm, anyone tell me why ca-certificates in core.morph is... such a mess ?06:03
gtristanactually, what it is intended to actually do, it does not do06:04
gtristanI cannot explain why there is a baserock/debian/... delta there either06:04
gtristanWell, I can hazard a guess06:04
gtristanHere is my guess: The really important system-integration semantics for chunk morphologies was added as an afterthought06:05
gtristanFor a really long time, it would seem that we worked around that missing piece by hacking things in weird ways at make install time06:05
gtristanthis would explain why system-integration remains undocumented06:06
gtristanand would explain why strata/core/ca-certificates.morph tries to do at make install time, what it really only needs to do at system-integration time06:06
gtristanand maybe explains the downstream hackery/patch against the update-ca-certificates script06:07
gtristanThe problem is, this morph... which literally *nothing* in the build depends on... will cause me to rebuild, literally everything... just because it is in core... so if I get this wrong, it will be a huge waste :-/06:08
gtristanSo the question which really needs answering is: Is there any reason at all for the certificates to be actually installed properly in the staging area during the build phase ?06:09
gtristanIs there some packages which rely on fully installed certs, just in order to build ?06:09
gtristanIf that is the case, the patch I will propose will be invalid06:09
gtristanFor now I will try a "trick" to do it in a chunk in gnome.morph, upgrade to the latest debian tag with fresh certs and do it without the downstream patch06:11
gtristanaha, beautiful, that explains it06:31
gtristanhttp://paste.baserock.org/mapozasoci06:32
gtristanThat is why the ca-certificates build is broken and we dont know about it06:32
gtristanThe simple GNU makefiles in the upstream package are really badly implemented06:33
gtristanas such they dont propagate errors in sub makes06:33
gtristanInterestingly, it automatically answers the question I asked before - the builds we are making have no problem without properly installed certs06:34
gtristanErgo, it should be totally safe to remove the crackpot update-ca-certificates at install time, along with the downstream delta, and just do that part in system-integration06:35
gtristanjjardon, I think you should take another look at 893259d724707190f763a980bc055ad9c87f753506:43
gtristanjjardon, that commit is what breaks the ca-certificates chunk in core06:44
gtristanjjardon, simply by making ca-certificates depend on python3 instead of python206:44
gtristanIs there a reason why python3 sits in core.morph and python2 does not ?06:47
gtristanit looks like we need python2 to also be in core.morph, simplest option06:47
gtristanhmmm, well, I guess the breakage introduced by 893259d724707190f763a980bc055ad9c87f7535 should be fairly limited06:49
gtristanthis is one specific case where a chunk's build fails but it is not apparent without actually checking the build log06:49
gtristanthat shouldnt be too common06:50
*** gtristan has quit IRC07:25
straycatsomeone should point gtristan to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010416.html and http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010432.html when he gets back08:01
straycatthen finally to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html08:01
straycati guess we should add a comment in the definitions08:01
*** gtristan has joined #baserock08:02
straycat08:01  straycat$ someone should point gtristan to08:02
straycat                 http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010416.html and08:02
straycat                 http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010432.html when he gets back08:02
straycat08:01  straycat$ then finally to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html08:02
straycat08:02  straycat$ i guess we should add a comment in the definitions08:02
straycatgtristan, hello, ^08:02
* gtristan opens links08:03
gtristanhi straycat :)08:03
gtristanstraycat, regarding the first two links... I saw that in the history08:04
gtristanstraycat, what boggles my mind is why was the install stuff not removed ?08:04
gtristanand the baserock/debian/<date> delta ?08:04
straycatgtristan, did you see pedro's response to the v1 of the patch i sent?08:05
straycatwhen we removed the install stuff, we could no longer git clone over https, which is what pedro expected08:05
gtristanI see08:06
* gtristan followed the links: curl08:06
gtristanhmmm08:06
straycatso we probably should have added a comment to the definitions for future reference08:06
gtristanwell, today we have to fix the python problem at least08:06
straycatmerging the patch i sent the other week should fix that problem08:07
gtristanstraycat, I'll add a comment and git review that, indeed - that certainly deserves a comment at least for now08:07
straycatsounds good :)08:07
gtristanoh you have a patch for python ?08:07
straycati have a patch for upstream's python install script08:08
straycati spoke to the upstream who seems willing to take the patch if it works, i just haven't had time to submit it to them08:08
gtristan:-/08:08
gtristanWe need better policy in baserock08:09
straycat?08:09
gtristanWe cannot allow our hell-bent insistence on fixing upstream cost us a day of malfunctioning systems in baserock08:09
gtristanthat just doesnt work, at least not for me :-/08:10
straycati think there's some misunderstanding08:10
gtristanThere has to be a priority on our own definitions producing usable output08:10
straycatwe are not blocked by upstream08:10
straycatall we have to do is merge the patch i sent to the list to the land i suggested08:10
gtristanI see, ok sorry - so lets do that ?08:11
gtristanat least we can do that today08:11
straycatif you think my patch is sane and are willint to +1 it, then i'd be happy to merge it today if no one else here objects08:11
straycat*willing08:11
gtristanstraycat, how about we do this in a new delta based on this years version of ca-certs ?08:11
straycati'd rather not, i've only tested that branch08:12
straycatif you want to update the certs that's a separate issue08:12
gtristantested = ... checking that popular modern software still works with the produced certs ?08:12
gtristanhmmm08:13
gtristanI think we can do with last years certs for now08:13
straycattested here = verified that the certificate filenamed produced by the python2 version match the certificate filenames produced by the python3 version, which both in turn match the certificate filenames produced without the patch AND building a system with the change, deploying it and ensuring i could clone over https from bitbucket and github08:13
* straycat assumes you mean 'without' there08:14
gtristanstraycat, that sounds like a thorough test for the python script yes08:15
gtristanI mean, I think we can do _with_ last years certs... as I can see the currently used delta is based on a 2014... debian tag08:16
gtristan2014's certs :)08:16
gtristanwell, soon they will be 2 years old :)08:16
* straycat nods08:18
* gtristan +1s on the list08:21
*** ctbruce has joined #baserock08:26
straycatokay cool, let's wait a while for others and if they don't object i'll merge it08:26
gtristanhttps://gerrit.baserock.org/1460 <-- comment in ca-certificates.morph08:31
gtristanstraycat, I wonder if the downstream patch we already have there could be avoided with a manual chroot issued in the install commands08:32
gtristanchroot $DESTDIR update-ca-certificates08:32
gtristanor08:33
gtristanchroot $DESTDIR /sbin/update-ca-certificates08:33
gtristanchroot might not be functional at core though, may bail out due to missing bash08:33
gtristaneh, it's more complicated than that :-/08:34
*** ctbruce has quit IRC08:50
*** ctbruce has joined #baserock08:53
*** bashrc_ has joined #baserock09:06
*** franred has joined #baserock09:10
*** jonathanmaw has joined #baserock09:19
*** toscalix has joined #baserock09:22
*** tiagogomes has joined #baserock09:29
richard_mawgtristan: yeah, DESTDIR isn't a full chroot, it's just a packaging directory, and we overlay those directories on top of each other when making staging areas09:29
richard_mawplus, you're not allowed to use chroot in the build sandbox09:29
gtristanrichard_maw, yeah I was mixed up thinking that... DESTDIR in fact $sandbox/${package}.inst09:33
richard_maw09:34
gtristanI think I have found something interesting though :)09:34
gtristanstraycat, https://github.com/bagder/curl/blob/master/acinclude.m4#L255609:34
gtristanI havent finished digesting the m4 macro just yet, but I believe that we totally dont need to stage the certs09:35
gtristanwe just need to pass an appropriate configure flag to libcurl09:35
richard_mawah, another case of potentially being able to break a dependency by configuration09:35
gtristanto tell it where the certs should be at runtime09:35
richard_mawthis approach came up at the time, but I don't know whether we decided against it explicitly, or whether we just failed to find the way.09:36
gtristanrichard_maw, today when looking at this particular issue, the staging of dependencies came back to mind, of course09:37
gtristanI was thinking (and it's really just a wild idea at this point), since we have system-integration - if there could be a potential stage of the build at which point we could assert that system-integration staging were possible09:39
gtristanand perhaps optionally, or by default, after that point; run the system-integration hooks while staging any build after that point09:39
*** mariaderidder has joined #baserock09:39
*** mariaderidder has joined #baserock09:40
gtristanrichard_maw, it's a good point that one can potentially break by configuration - quite a philosophical discussion: "is it better to rely on configure scripts to deduce as much as possible about the target system, or not"09:41
*** mariaderidder has quit IRC09:41
pedroalvarezat the time I integrated ca-certificates I don't think I could have read that m4 macro...09:42
gtristanin this case I tend to think it better to pass a configure flag rather than to patch ca-certificates09:42
gtristanpedroalvarez, you write the python, I'll write the m4 ;-)09:42
pedroalvarezheh09:42
pedroalvarezwell, I think if we can avoid that delta... it will be good09:43
pedroalvarezca-certificates delta09:43
* gtristan asks daniel in #curl09:44
richard_mawI think the delta for python3 support is acceptable, since I like the flexibility of being able to run it with fewer dependencies09:44
richard_mawI also like libcurl not depending on ca-certs, since it forces a spurious rebuild when updating certificates09:44
straycatit's likely onlt temporary09:44
straycatrichard_maw, does that patch look sane to you?09:44
* richard_maw hasn't had his caffeine yet09:45
richard_mawwhich patch is this?09:45
richard_mawcontext is difficult09:45
straycathttp://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html09:46
richard_mawoh yes, I reviewed that earlier, it looked good at the time09:47
richard_maw+109:48
straycatokay great i'll merge it thanks09:48
straycatwill submit it upstream as soon as i can09:48
gtristanpedroalvarez, http://paste.baserock.org/ovorinivef09:50
gtristanpedroalvarez, there is a cut-paste of my convo with daniel09:51
gtristanin short --with-ca-bundle=/usr/share/ca-certificates should do the trick09:51
gtristanand we can drop that delta safely09:51
*** gary_perkins has joined #baserock09:52
richard_mawgtristan: except that when we do run ca-certificates we need to depend on python209:55
straycatgtristan, if you're talking about the delta i'm about to merge, then we can't drop it09:56
gtristanrichard_maw, there are 2 deltas09:56
gtristanone of them for the python2 python3, another to hack the paths09:56
gtristanI mean we can drop the delta which hacks the paths, and drop the make install thing in the definition09:57
gtristan... if we add the --with-ca-bundle flag to libcurl of course :)09:58
gtristanpr --with-ca-path sorry09:58
gtristanor, even09:58
pedroalvarezgood!09:59
pedroalvarez+1 to drop "sbin/update-ca-certificates" delta10:00
gtristan:)10:00
gtristanideally we should tear out the ca-certificates.morph from core, but that's a whole other story :-/10:01
* richard_maw thinks being able to have update-ca-certificates generate things into "$DESTDIR" is generally useful10:01
gtristanrichard_maw, I'm not entirely sure I agree or disagree - I think it's unneeded baggage to carry though, do *we* have a use for that ?10:03
pedroalvarezwe could try to submit that upstream: http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/commit/?h=baserock/debian/20140325&id=e9b06b26d9e57444e74a5cb6beca3f12726fc3c610:04
gtristanperhaps if it was considered generally useful, that delta could sit in a patch in an upstream bug report instead of in our downstream delta ?10:04
gtristanpedroalvarez, right, I would advocate not blocking on that and still dropping it locally, whether or not it was proposed upstream10:05
pedroalvarezof course, I don't want to block it10:07
gtristanOk, gnome-online-accounts mostly works now... virtual-box internet was shakey this startup... so I'm not sure if geoclue worked10:09
gtristanregarding the certs, since I got annoyed, I dont mind being the one picking up the pieces :)10:10
*** edcragg has joined #baserock10:10
gtristanProposed course of action: straycat pushes the python fix to baserock/debian/<thing> branch (and probably makes a commit to core.morph to pick up the new commit)... that problem is solved10:11
gtristanThen, I will create a new branch with straycat's python related delta but without the other, and I will prepare a definitions branch for review which does A.) Drops the make install mumbo-jumbo and B.) Passes the needed configure switch (with comments) to libcurl.morph10:12
gtristanI will boot the GNOME vm with that and git clone an https://git.something.repository10:12
gtristanto test it10:12
gtristan... sounds good ?10:12
pedroalvarezit does sound good10:20
gtristangreat10:20
* gtristan elects pedroalvarez as the benevolent dictator and follows his lead10:20
pedroalvarez:)10:21
pedroalvarezI'll try to submit the other delta upstream in the meantime10:21
*** ssam2 has joined #baserock10:21
*** ChanServ sets mode: +v ssam210:21
gtristanpedroalvarez, ok well... dont hold your breath... this is core we're talking about10:22
gtristanso... probably I will clean out my artifact cache completely... I'm about due for that... and let the build heat my room overnight10:23
paulsherwoodgtristan: why clean it out? ybd should do that itself, now? :)10:24
gtristanpaulsherwood, does it ? how so ?10:24
paulsherwoodit checks available space, culls artifacts oldest first10:24
gtristanah not bad10:25
straycatpaulsherwood, is there an option to disable that?10:25
gtristanthere should probably be indeed - I would think setting a limit on the overall artifact cache size would be a good semantic10:26
paulsherwoodstraycat: default is min-gigabytes: 10. if you set it to zero, it won't cull. it won't work, either, if there's no space :)10:26
gtristanallowing an unlimited10:26
gtristanpaulsherwood read my mind :)10:26
paulsherwood:)10:26
straycati personally prefer having a command to do garbage collection, but okay10:27
gtristanstraycat, right, there are semantic issues with that I think though... you garbage collect for which target exactly ?10:28
gtristanstraycat, and for which active branches do you want to keep artifacts :)10:28
tiagogomesis there a reason why morph doesn't is not using the schemas to do a basic validation of the morphologies other than lack of time to do implement that functionality?10:28
ssam2morph's validation code predates the json-schema schemas10:29
ssam2I have reservations about just switching to json-schema, because its error messages can be a bit rubbish10:29
ssam2but probably makes sense to switch and then manually handle any errors are really confusing10:30
straycatgtristan, agreed, i just personally don't like the idea of a tool secretly removing artifacts without my knowledge10:30
gtristanstraycat, yeah, it's a tricky problem :)10:31
*** nowster has joined #baserock10:31
*** locallycompact has joined #baserock10:32
* richard_maw objected to moving to purely json schema because it only does syntactic validation, rather than semantic too10:34
richard_mawyou'd need an ontology like ssam2 was looking at for automated tooling around that level of validation10:34
tiagogomes"to do a basic validation" ...10:34
richard_mawah, I missed a detail there10:35
*** tiagogomes has left #baserock10:37
richard_mawI'm still unsure if the definitions providing the validation schema makes sense for anything more than a "coding style" level where you opt to deny old aliases or deprecated features, effectively allowing you to restrict yourself to a subset of the format the tooling understands10:38
*** tiagogomes has joined #baserock10:38
richard_mawsince the point of the validation that the build tool does is to be able to provide a better error message if the definitions aren't in a form it understands, so the tool also needs a schema10:38
richard_mawwhich may potentially make using schema in the definitions a redundant feature10:39
*** paulsherwood has left #baserock10:39
richard_mawanyway, that's an old argument10:40
* pedroalvarez plans to redeploy storyboard.baserock.org11:05
Zara\o/11:06
pedroalvarezI was planning on doing it with ansible, but looks like the deployment is already implemented in puppet11:06
ssam2that's what I used to deploy the original11:08
ssam2it wasn't smooth sailing for 2 reasons: the Puppet scripts expect to run on Ubuntu but I used Fedora, and also they seem to use a fork of the Apache puppet module, but I didn't realise at the time and used the upstream one11:09
ssam2also puppet is a bit crazy, but just about usable11:09
pedroalvarezssam2: so, suggestions?11:09
pedroalvarezI'd love to go with ansible tbh11:09
pedroalvarezOn the same way as everything else in our infra11:09
ssam2depends how much time you have :-)11:10
pedroalvarezthat's true11:12
pedroalvarezOk, I'll start playing with puppet11:12
tiagogomesAnsible rocks11:14
ZaraI know nothing of storyboard's puppet scripts, but there may be other puppet scripts within openstack projects that have switched to ansible (I see a lot of talk about ansible in the channels I'm in, though it's not something I've paid much attention to). so you might be able to find some helpful things around, not sure...11:15
Zaraseems you can have a puppet in your ansible https://github.com/openstack-infra/ansible-puppet11:17
Zaraor an ansible in your puppet: https://github.com/openstack-infra/puppet-ansible11:17
tiagogomeslol11:18
Zarathe words 'ansible' and 'puppet' no longer look like words to me, so I'm off.11:18
pedroalvarezhahahh this is crazy11:20
pedroalvarezwhat's next, running python from shell and shell from python?11:20
pedroalvarezhm.. hang on11:20
* gtristan files https://bugs.freedesktop.org/show_bug.cgi?id=92915 and tests...11:30
gtristanif this fixes geoclue, there will be only one remaining system integration bug left to deal with in GNOME's platform: the keyring issues11:31
pedroalvarezgtristan: that bug has been answered11:34
pedroalvarezsaying that you don't need those rules11:34
gtristanI just saw that11:34
gtristanand disagree11:34
gtristanModemManager seems to install the action11:34
gtristanand geoclue would clearly need to be authorized to ask modemmanager for this11:35
gtristanmaybe the problem is upstream modemmanager ?11:35
tiagogomesis there any documentation of the archs supported in Baserock and that the possible valid fields for it?11:41
gtristanpedroalvarez, see the new comment11:42
gtristanpedroalvarez, we will install the rule... the alternative is that we compile ModemManager without "strict" mode, allowing any old user to query location info, this doesnt sound more desirable11:45
gtristanpedroalvarez, also, see IRC with hadess: http://paste.baserock.org/uhesogobor11:46
pedroalvarez<hadess> the problem is the debian developers not reporting back upstream about those problems...11:48
pedroalvarezheh11:48
*** locallycompact has quit IRC11:48
pedroalvarezI guess they will fix that upstream :)11:48
*** locallycompact has joined #baserock11:48
ssam2tiagogomes: not really11:50
ssam2in http://wiki.baserock.org/definitions/current/#index7h3 I just linked to the relevant Morph code11:50
ssam2i don't think it really makes sense to standardise them, makes more sense to make definitions flexible enough that we don't need a canned list of architectures in each the build tool11:50
ssam2-the11:50
tiagogomesssam2 right, I asked because I am tempted to remove the armv7 to armv7l normalization that occurs in morphologyloader11:54
ssam2i guess that's some backwards compatibility thing11:54
gtristanpedroalvarez, so... what would be the policy for branching ca-certificates... I will create a baserock/tristanvb/debian/20140325 branch to test against ?12:00
gtristanpedroalvarez, basically its just the same branch with the delta reverted I guess ? reverting it allows for a later merge12:01
pedroalvarezgtristan: didn't you want also to upgrade the certs?12:01
gtristanI do12:02
gtristanif that's alright, that makes things a bit less complicated12:02
gtristanthen we get a branch without that delta, and I just test against a local file:///repo12:02
pedroalvarezalthough.. I still don't see straycat's patch12:03
pedroalvarezstraycat: have you failed to merge it?12:04
gtristanit's merged in the delta12:04
gtristanhttp://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/commit/?h=baserock/debian/20140325&id=c9124556cfc5d29d4fd0d7b688bf4873a6098bf312:04
gtristanbut no definitions patch yet12:04
pedroalvarezI see, sorry cgit was confusing me12:04
gtristanwe could skip it and live with another day of broken certs until after I test the changeover12:05
gtristaninstead of having everybody build everything from core upwards two days in a row12:05
pedroalvarezthat's ok12:06
pedroalvarezregarding upgrading to latest certs... I'm not sure now :)12:07
pedroalvarezif it has been tested I won't mind12:07
pedroalvarezI'm just worried about these encoding/decoding issues that the patch solves12:08
gtristanpedroalvarez, the new certs are just the new tag: debian/2015042612:08
gtristanI have been building with that, its most probably just a couple of added certs12:09
straycatpedroalvarez, i've rebased the sha change it's building, i'll submit the change once it's done12:11
gtristanhttp://paste.baserock.org/acoqehakal <-- git log debian/20140325...debian/2015042612:11
pedroalvarezgtristan: diff: http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/diff/?h=baserock/debian/20140325&id=1ce8e63dcfea6b9258da356dc023895e6f694144=651de1c8439c6206ea76b7d502daa9de05b5a46112:13
gtristanpedroalvarez, you want me to review the certs by eye ?12:15
gtristano_O12:15
gtristanI can see it has "\231\213\120\224\327"... must be good !12:16
pedroalvarezthat wasn't my intention12:16
pedroalvarezIt's clear that nothing else changes but the certs12:17
gtristanyes, that is unclear, it's an upgrade to mozilla 2.4 certs12:18
pedroalvareznote that you don't have to build the entire sytem to test this change. A base system has git in it12:19
gtristanI am connecting to google and facebook accounts with GOA using the new certs fwiw12:21
gtristannot that that means much12:21
straycatgtristan, is that new cert change based on the the change i just merged?12:21
gtristanstraycat, no, I am building with the new certs as a hacked workaround from the gnome strata12:22
gtristanI have not dared to rebase master, I will lose a day - trying to resolve geoclue before I dive that deep12:22
straycatokay i don't understand how that fixes your problem12:22
gtristanstraycat, I have python2 of course12:23
gtristanonce you reach gnome you have that :)12:23
straycatbut the ca-certs are in core which doesn't?12:23
gtristanalternatively, we could have just built ca-certificates with the python it wanted, also :)12:23
gtristannot the ca-certs which are in GNOME, locally in my definitions sandbox, unstaged12:23
straycatright okay12:24
gtristansigh, ok blast it, geoclue still has problems as we approach 10pm12:31
* gtristan migrates to home12:31
* gtristan thinks geoclue does not run as the geoclue user12:32
*** gtristan has quit IRC12:33
*** nowster has quit IRC12:50
*** nowster has joined #baserock12:52
*** nowster has quit IRC12:56
*** nowster has joined #baserock13:01
*** gtristan has joined #baserock13:21
*** toscalix has quit IRC13:33
tiagogomesyikes, I tried the validation example on jsonschema website and the output is not nice indeed13:43
tiagogomesIt jut says field $foo isnot valid under any given schemas13:43
gtristanpedroalvarez, what is the "base system"... I dont see it in clusters/13:48
gtristanthere is one in systems...13:49
gtristanbah, 11pm is not the time to try to figure anything out... never mind me :)13:50
pedroalvarezyeah, we don't have clusters for everything13:51
pedroalvarezit used to be build-essential + core + foundation + bsp13:51
pedroalvarez(before we started moving things out from them)13:51
gtristanif it doesnt do it all by itself, I'm not interested :)13:52
gtristananyway, assuming the patch is accepted, the overnight heating build will give me artifacts I can use :)13:52
gtristanCurl build config: http://paste.baserock.org/uriruqeseh13:53
gtristan 'ca cert bundle' is what is generated by update-ca-certificates13:54
gtristanshould work fine13:54
pedroalvarezyeah, it should13:54
*** toscalix has joined #baserock14:05
*** paulwaters_ has joined #baserock14:37
*** Walkerdine has joined #baserock14:37
*** paulwaters_ has quit IRC14:38
WalkerdineHi15:19
pedroalvarezhello!15:34
WalkerdineIs there anyway to check if a particular repository is having problems?15:35
pedroalvarezhm... with which one are you having problems?15:37
pedroalvarezI can try to reproduce the error if that helps15:38
*** Walkerdine has quit IRC15:43
*** Walkerdine has joined #baserock15:58
WalkerdineI am having problems with genivi-demo-platform-0.1-rebase16:02
WalkerdineI keep getting a preconfigure error when its building the HMI16:04
Walkerdine[Build 352/355] [genivi-demo-platform-hmi] Running pre-configure-commands16:04
* tiagogomes ponders writing his own validator based on jsonschema16:05
Walkerdinepre-configure failed16:05
tiagogomesWalkerdine mm,  it doesn't show anything else?16:24
pedroalvarezNote that I don't know the status of the genivi-demo-platform system on that branch16:25
pedroalvarezWalkerdine: Could you build the version in master branch please?16:26
Walkerdinewhich version is that16:26
pedroalvarezWalkerdine: can you point me to the instructions that you are following so that I can understand what you are doing ?16:27
Walkerdinehttp://wiki.projects.genivi.org/index.php/Hardware_Setup_and_Software_Installation/Jetson16:28
pedroalvarezright16:28
radiofreethat probably needs updating16:29
pedroalvarezWalkerdine: can you tell me what version of morph do you have?16:29
pedroalvarezradiofree: yes, I'll try to do that16:29
WalkerdineWhich ever is in 15.2516:29
pedroalvarezaha, ok16:29
pedroalvarezthing is that I don't know if that baserock 15.25 can build latest version16:32
pedroalvarezgah16:32
WalkerdineI did build it a few weeks ago but now I haven't been able to16:35
pedroalvarezInstructions updated16:43
WalkerdineWhich instructions?16:50
pedroalvarezWalkerdine: is now all in the wiki. but basically you need to do: http://paste.baserock.org/inamowecax16:50
WalkerdineIs this for a newer version of baserock?16:51
pedroalvareznewer version of morph, but in those commands it's inlcuded what's needed to use the version you need16:52
pedroalvarezit's also in the wiki16:52
WalkerdineAh but is it better now to use the newest version?16:53
WalkerdineI knew morph was the reason why I was using 15.2516:54
pedroalvareznow a newer version is needed16:55
*** CTtpollard has quit IRC16:58
WalkerdineHm okay16:58
*** jonathanmaw has quit IRC17:01
gary_perkinsHi, I hope someone can help. Trying to properly deploy a trove to openstack, but it seems the cloud-init isn't being run (no /etc/trove/trove.conf being created) and there is nothing in /home. I've tried 'systemctl restart trove-setup' and it seemed to do nothing. is there a script I can try manually running to create the git,lorry,etc. directories?17:10
ssam2cloud-init and trove-setup are different things...17:13
ssam2but both will need to run17:13
ssam2and should17:13
ssam2can you paste the errors from `systemctl status` for trove-setup.service and cloud-init.service ?17:13
*** ctbruce has quit IRC17:20
*** franred has quit IRC17:21
gary_perkinsssam2: Here: http://paste.baserock.org/ujopizipay17:25
pedroalvarezNote that the trove setup service needs trove.conf to run17:25
pedroalvarezMi guess is that this file was supposed to be created with cloud init17:26
pedroalvarezMy*17:26
ssam2yeah, "ConditionPathExists=/etc/trove/trove.conf was not met"17:26
ssam2so that's why trove-setup.service does nothing17:26
ssam2if you add that file manually, then run trove-setup.service, it'll work17:27
gary_perkinsok, so the root cause is the cloud-init I supply on the nova boot cmd line?17:27
gary_perkinsok, I'll try manually running the cloud-init script, thanks :)17:28
gary_perkins\o/ It's working now! Thanks ssam2 & pedroalvarez :)17:35
gary_perkinssupplying a script to nova boot never seems to work for me :(17:36
*** tiagogomes has quit IRC17:49
*** ssam2 has quit IRC17:54
*** bashrc_ has quit IRC18:02
gary_perkinsI've now re-run nova boot with a tweaked cloud-config.sh (I removed the "runcmd:" and "- |" lines which seem to yamlise it) and it works!!18:04
*** locallycompact has quit IRC18:26
gary_perkinshmmm... actually, no it didn't :( So re-ran the cloud-config.sh script manually and I'm happy :)18:31
*** toscalix has quit IRC18:39
*** edcragg has quit IRC18:57
*** Walkerdine has quit IRC18:58
*** zoli_ has left #baserock19:06
*** Walkerdine has joined #baserock19:10
*** zoli_ has joined #baserock19:25
*** edcragg has joined #baserock20:36
*** Walkerdine has quit IRC20:37
*** Walkerdine has joined #baserock20:39
*** Walkerdine_ has joined #baserock22:04
*** Walkerdine has quit IRC22:06
*** Walkerdine_ has quit IRC22:20
*** Walkerdine_ has joined #baserock23:01
*** Walkerdine_ has quit IRC23:05
*** gary_perkins has quit IRC23:50
*** gary_perkins has joined #baserock23:51
*** edcragg has quit IRC23:52
*** edcragg has joined #baserock23:52
*** wdutch has quit IRC23:54
*** wdutch has joined #baserock23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!