IRC logs for #baserock for Friday, 2016-09-30

*** locallycompact has quit IRC00:10
*** gtristan has quit IRC06:08
*** gtristan has joined #baserock06:38
paulsherwoodtiagogomes: ssam should be but i don't know where he is07:06
*** paulwaters_ has joined #baserock07:14
*** toscalix has joined #baserock07:32
*** ctbruce has joined #baserock07:37
*** franred has joined #baserock08:28
*** rdale has joined #baserock08:34
gtristanIn the artifact metadata... I find the metadata lists all files and their parent directories which are found in the artifact, but there is an inconsistency regarding the ${package}.meta file itself08:41
gtristanit seems that every -misc artifact lists the baserock directory and omits the meta file itself08:42
gtristanHow should this be fixed; do we ignore/remove the baserock/ meta directory from the artifact splitting rules entirely ? Or should we specify the metadata file ?08:42
paulsherwoodgtristan: i've started thinking about this already, because radiofree has a use-case where the current splitting doesn't keep up08:53
paulsherwoodi.e. he wants to create a new default rule, and apply that for a system. but existing chunks were built without any knowledge of the new rule08:54
paulsherwoodso i think this means that chunk metadata should be just a list of files, and rules only apply at system-creation-time08:55
gtristanNot sure exactly what that means, you mean split the whole system up in different ways than which the chunks were already split ?08:55
paulsherwoodchunks are not actually 'split' at the moment. each chunk artifact contains all the files... the chunk.meta describes what possible split-chunks should contain08:56
paulsherwoodbut it would be better to figure out the split-chunks only when they're needed08:56
gtristanI'm not sure what is the reason to change this, but I'm sure radiofree has one :)08:57
gtristanI.e. seems to me pretty similar, to define the data either at chunk creation time or system creation time08:57
gtristanbut perhaps there is more context in play at that point ?08:57
paulsherwoodhe has a new rule... let's call it 'ultra-splitting'... wants to build systems with it... but it shouldn't require a full rebuild of all the chunks08:58
gtristanI'm a bit skeptical of that though (at first sight at least), because if the splitting would be done differently at system creation time; then the result is...08:58
gtristanthe same stratum of chunks might end up being split differently; /depending/ on which system they were included in ??08:58
gtristanwhich sounds unstable08:59
paulsherwoodput it another way... any splitting rules should only affect the cache-key of systems which apply that rule. chunks should be the same08:59
paulsherwoodthe split applies for stratum and system, not chunk09:00
gtristanOk so in any case, we're still going to end up with a phase where a system is an artifact, and contains a baserock/ subdirectory containing meta files for each chunk, with their splitting rules in there09:01
gtristanOnly that the generation of that metadata will occur later on... correct ?09:01
paulsherwoodso the chunk metadata will not contain any split information09:02
gtristanSure, that worksforme...09:02
paulsherwoodack. now i just need to code it :-)09:03
gtristanso in any case, the question I am asking is unrelated I think09:03
gtristanShould the metadata itself be encoded into the artifacts in splitting rules ? Or not ?09:04
gtristanI tend to lean towards not09:04
paulsherwoodyup, i just wanted to highlight that i'm about to change the metadata anyway09:04
* paulsherwood tries to wrangle what gtristan is thinking/wanting09:04
gtristanBecause this metadata seems to currently at least be generated at various levels, and for instance strata metadata files remain unmentioned09:04
gtristanThere is no way I can see that the strata metadata file is included in any assembled system09:05
* paulsherwood is pretty sure it is09:06
paulsherwoodbut i may be wrong of course09:06
gtristanpaulsherwood, Ok what I'm looking at is basically: Chunk meta files list the baserock/ directory in their -misc artifact (but FAIL to mention the filename itself)09:07
*** locallycompact has joined #baserock09:07
gtristanpaulsherwood, while there is no rule that says, that a specific artifact should be generated containing a stratum metafile at all09:07
gtristanpaulsherwood, so I can sort of infer that for say, the acl build, it's acl.meta says that acl-misc claims what is in the 'baserock/' directory09:08
gtristanHowever, nothing says that core.meta should be included in any artifact09:09
gtristanat all09:09
* paulsherwood is downloading an acl artifact from kbas09:09
* gtristan chooses acl because it's just alphabetically first09:09
gtristanpaulsherwood, notice though; that our conversation is entirely distorted, because we now have 2 definitions of the word 'artifact'09:10
* paulsherwood only has one... a tarball generated by ybd (since this conv is not about morph's approach( but it has different characteristics depending on whether it's of a chunk, stratum, system09:11
gtristanpaulsherwood, right, in for instance our conversation yesterday I used the term artifact with franred in a different way09:13
paulsherwoodok, to mean what?09:13
gtristanI.e. that a chunk is split into multiple artifacts09:13
gtristanDo we even have a word for that ?09:13
* paulsherwood doesn't09:13
gtristanor that's what I meant, maybe I didnt use that word exactly09:13
gtristan<gtristan> franred, ah I see what you mean, in which case the licence needs to be something at the artifact splitting level09:14
paulsherwoodmorph artifacts are pre-split09:14
paulsherwoodsorry.. by that i mean morph generates foo-bin foo-lib foo-misc09:14
locallycompactThose are just artifacts09:14
locallycompactsplit :: Artifact -> List<Artifact>09:15
gtristanOk so... My question is, does the baserock metadata go into an artifact (as in, a split up artifact, a piece of a chunk), or does it not ?09:15
gtristanA chunk tarball with cache key currently stores a baserock/ directory with it's metafile, and does that go into any 'artifact' ? does it belong inside foo-misc ?09:16
gtristanOr should it be omitted entirely :)09:16
SotK(there are stratum artifacts and system artifacts too, they aren't just for chunks)09:16
paulsherwoodgtristan: i accept that there's an inconsistency, ie /baserock is not only for foo-misc. but i'm not sure what you want to *do* with the metadata so i don't know how to answer yet09:17
rdalewhen a system is assembled by ybd, any artifacts which are split will have only the meta data in /baserock for the split parts that they use09:17
gtristanpaulsherwood, generate rpms of course :)09:17
gtristanpaulsherwood, practical reason for the question: I have this obnoxious baserock/ directory listed, and an orphaned foo.meta file09:18
*** ctbruce has quit IRC09:18
gtristanIf the splitting medatata lists the baserock directory at all, it should list the file so it can be claimed and packaged09:18
gtristanor not list the baserock directory at all, leaving it as a special case09:18
paulsherwoodaha. so in my proposed scheme, foo-chunk/baserock/foo.meta would contain a list of all files including /baserock/foo.meta, no split information09:19
paulsherwoodie it will list the file09:19
gtristanpaulsherwood, however that raises the interesting question: How do stratum and system metadata files get 'claimed' ?09:20
paulsherwoodgtristan: are you proposing to create rpms of strata and systems too?09:20
*** ctbruce has joined #baserock09:21
gtristanpaulsherwood, no, I'm questioning why the metadata files should be considered in the splitting rules at all, if only some of that metadata is to be claimed and other metadata not09:21
paulsherwoodi'm aiming towards: chunk.meta lists all files. stratum/baserock contains chunk-misc.meta, chunk-bin.meta etc, but not a copy of chunk.meta09:25
*** persia_ has quit IRC09:28
gtristanfoo-chunk.meta lists all files, I tend to disagree that it should list itself as one of those files; this means that... bar-stratum/baserock/foo-chunk-misc.meta should list the file baserock/foo-chunk.meta ? Which then makes me wonder... at the end of the day, where is baserock/foo-chunk-misc.meta listed ?09:30
gtristanpaulsherwood, ^^^ you see how this is sort of circular ?09:30
paulsherwoodi do, yes. i'm ok dropping chunk.meta from itself09:30
*** persia_ has joined #baserock09:31
paulsherwoodradiofree: if you're around, could you point to a ref of definitions with your example new splitting rule(s), please?09:32
*** ctbruce has quit IRC09:53
* gtristan pulls out trivial patch
*** gtristan has quit IRC10:00
*** ctbruce has joined #baserock10:09
*** cphang has quit IRC11:01
tiagogomesIf no one objects, I would like to merge
pedroalvarezthat repo could do with a little .travis script11:09
SotKtiagogomes: lgtm11:09
tiagogomespedroalvarez one step at a time :)11:10
pedroalvareztiagogomes: please, merge that11:11
*** cphang has joined #baserock11:13
*** cphang has quit IRC11:44
tiagogomesSo... I am trying to run linux-user-chroot without being root. I am getting a "execv: No such file or directory" error11:46
tiagogomesStrace shows this clone: Operation not permitted11:46
pedroalvareznamespaces support in kernel? or something like that?11:46
tiagogomessame command works with root11:46
richard_mawhm, you get ENOENT if a namespace flag is not supported I think11:47
pedroalvarezthat error msg rings a bell11:48
pedroalvarezbut can't recall atm11:48
tiagogomes`sudo  /usr/bin/linux-user-chroot /tmp/pytest-of-tiagogomes/pytest-8/test_mount_point_writable_linu0/sandbox test-file-is-writable`11:50
tiagogomes`/usr/bin/linux-user-chroot /tmp/pytest-of-tiagogomes/pytest-8/test_mount_point_writable_linu0/sandbox /bin/test-file-is-writable`11:50
tiagogomesboth are working11:50
tiagogomesBut I don't understand why test-file-is-writable works as it is inside a bin directory in the chroot dir, unless linux-user-chroot sets $PATH?11:52
tiagogomesIf so, why it doesn't for the non-root version11:53
*** cphang has joined #baserock11:59
tiagogomesmoar things for sandboxlib:
tiagogomesleeming ^^12:17
*** cphang has quit IRC12:50
*** cphang has joined #baserock13:03
*** cphang has quit IRC13:08
tiagogomesanyone fancies having a quick look at
*** cphang has joined #baserock13:20
leemingsorry back, will have a look in a sec tiagogomes13:33
leemingI also noticed/wondered where the path magic happened13:37
leemingbut assumed there was some implicit /bin search for path13:37
leemingahh good. i was not completely sure with this test :
leemingglad you thought it was strange too13:41
leemingtiagogomes, I am not getting 100% passes14:00
leemingi suggested a fix, but needs verifying14:00
tiagogomesok, all pass to me tough. But I am not testing with different versions of python interpreters14:01
paulsherwoodCTtpollard: is the source for the new GENIVI hmi launcher thing avilable somewhere now?14:06
* paulsherwood wonders how hard it would be to integrated it in the applicable baserock systems 14:07
CTtpollardpaulsherwood: yep14:10
paulsherwoodwhy two branches?14:12
CTtpollardThe powers that be decided a branch was more suitable than a new repo14:12
paulsherwoodso which would we use?14:13
paulsherwoodoh,  one repo with two completely different codebases in it?14:13
pedroalvarezi'd hope they push all of it to master14:15
pedroalvarezat some point14:15
cphangHi, small thing,added a lorry file for review:
paulsherwoodanyone else?14:31
* paulsherwood would be quite excited to see freertos built the baserock way14:32
pedroalvarezsvn lorry14:32
pedroalvarezis it big?14:32
paulsherwoodcphang: ^^ ?14:32
pedroalvarezyears and years of history?14:33
* paulsherwood guesses not... it's an rtos for microcontrollers14:33
pedroalvarezI'm happy to merge and see if that works or not just by waiting14:33
* paulsherwood *hopes* there's history :)14:33
pedroalvarezis there a git mirror available somewhere?14:33
leemingtiagogomes, this was running the test as root/sudo for some of the chroot tests. i think it is a py3 issue14:33
paulsherwoodpedroalvarez: eg, 1632 commits14:35
pedroalvarezwell, they are not too many14:36
paulsherwoodpedroalvarez: if that's a +1 i'll merge :)14:37
tiagogomesleeming the problem is that I don't know how to install python3.3 and python3.414:38
leemingoh, apparently that is difficult.. ive just been making sure it works in 2 + 314:39
cphangpedroalvarez, paulsherwood, I think that git repo hasn't been updated since 2012.14:39
cphangThere is a history here:
cphangTo date: 2471 revisions for freeRTOS.14:44
*** janderJLR has joined #baserock14:46
*** janderJLR is now known as JasonA14:46
JasonAHopefully ybd questions are welcome here.  I am curious if ybd can handle repos with submodules that have submodules.  I have spent a little bit of time looking at the code, and it seems to not recurse lower than the  top-level .gitmodules14:49
leemingJasonA, I was just asked this out of channel. Not sure if i know what submodules refer to in this context14:50
JasonASorry, git submodules14:50
leemingoh right14:51
JasonASpecifically, I want to build Qt5 using the supermodule, which contains all of the Qt projects as submodules.  Some of those submodules also have submodlues14:51
leemingi know as much as doing a --recursive flag when cloning the init repo... if you can do this after cloneing the 'master' repo, im wondering if you can stick in a chain of commands in the build-instructions part of the morph (im guessing)14:52
leemingunfortunately, the best person to answer this is off sick :(14:53
leeming(unless he is lurking)14:53
leeminglocallycompact, ^14:53
leemingbut, if it is a generic hack with the definitions files.. others might be able to help too14:54
* SotK thought ybd recursively cloned submodules and their submodules, but may be mistaken14:56
*** CTtpollard has quit IRC14:56
franredJasonA, I think you can define the submodules in the yaml
franredand for every chuck you define their submodules14:56
franrednot sure if it is what you are looking for14:57
SotKa glance at the code suggests I am mistaken, unless I'm missing something14:57
JasonAYeah, the issue is that some of the submodules also have submodules.  So I have defined the top-level submodule in the morph, but once one of those tries to get built its submodules were not checked out15:00
JasonAThe Qt5 supermodule has a perl script to do the recursive checkout and a gew other things.  Another option would be to tell ybd not to checkout submodules at all if that is possible15:02
SotKJasonA: I suspect needs to be done around also, if you're in the mood to try fixing it15:02
*** CTtpollard has joined #baserock15:02
JasonAAh, I see.  I have a fork of ybd I will try that in15:03
SotKthough, you'll probably want to remove lines 180 to 183 too if you do that15:05
JasonAYes, basically just move that functionality into _checkout15:05
* SotK realises he linked an old commit so the line numbers are off15:07
JasonANo problem, I get the idea.  Thanks for your help15:07
SotKyw :)15:07
rdalei wouldn't use submodules to build qt5 as it is likely you will need to customise the build of a particular module in a different way to the other modules15:24
*** ctbruce has quit IRC15:27
JasonAYeas, but I can handle that in the configure steps.  I am trying to avoid having to update the 20+ submodules SHAs every time I want to upgrade Qt versions15:28
rdalei see - upgrading the sha1s is tedious i agree15:28
pedroalvarezlast time I looked at that code in ybd, it was recursive15:30
pedroalvarezbut it looks like SotK has found the problem15:31
SotK looks to be the change that broke it15:32
JasonAAh yes, well I am about to kick off a build to test SotK's suggestion15:33
JasonAIf it works I will submit the patch, if anyone is interested15:34
* SotK expects there will be interested people15:34
pedroalvarezpaulsherwood will be interested, yes15:34
*** franred has quit IRC16:00
*** CTtpollard has quit IRC16:02
leemingwhy don't some chunks have install-commands defined?16:15
leemingis "make install" implicit?16:15
SotKcan you link an example?16:16
SotKleeming: you mean like for example?16:25
leeminghmm no.. i am just trying to figure out locallycompact's new lib... can't seem to find which files it actually pulls16:28
leeming one i just tried to track down was 'xz'16:28
leemingbut that seems to pull from upstream but can't find the build morph for it16:29
*** toscalix has quit IRC16:29
leemingwondering if the binary is packaged in these repos instead of compiling source?16:30
SotK is xz16:30
jmacsleeming: In morph, some commands have defaults depending on the build-system16:30
leemingah is that so jmacs ?16:30
SotKit has build-system: autotools, so should get the default install-commands from DEFAULTS for that16:31
SotKslow snap16:31
jmacsWith autotools selected, the default is make DESTDIR="$DESTDIR" instll16:31
leemingah that kinda makes sense then16:31
SotKleeming: see
SotKthat bash morph also has build-system: autotools, but overrides the default configure and post-install commands16:32
leemingso for the xz example, im assuming a "xz.morph" isn't needed as it just runs the autotools build16:33
* leeming proceeds to x-ref ybd and defslib16:33
*** tiagogomes has quit IRC16:43
*** rdale has quit IRC17:30
*** lachlanmackenzie has quit IRC18:43
*** locallycompact has quit IRC19:59
*** gtristan has joined #baserock20:56

Generated by 2.15.3 by Marius Gedminas - find it at!