IRC logs for #baserock for Thursday, 2016-06-02

*** gtristan has quit IRC00:47
*** gtristan has joined #baserock01:45
*** gtristan has quit IRC04:03
*** pedroalvarez has quit IRC04:23
*** pedroalvarez has joined #baserock04:24
*** ChanServ sets mode: +v pedroalvarez04:24
*** gtristan has joined #baserock05:22
*** CTtpollard has joined #baserock07:08
*** fay has joined #baserock07:26
*** fay is now known as faybrocklebank07:27
*** rdale has joined #baserock08:02
pedroalvarezpaulsherwood: I don't understand why the path and name have to match08:12
pedroalvarezI thought the problem leeming described was that 'name's have to match in the stratum and in the chunk. Not anything related with paths..08:13
*** edcragg has joined #baserock08:16
*** faybrocklebank has quit IRC08:18
*** faybrocklebank has joined #baserock08:18
*** jonathanmaw has joined #baserock08:33
paulsherwoodpedroalvarez: you may be right... however, if stratum has name: foo and path/to/foo.morph, i think it would be logical to insist that foo.morph describes foo?08:50
pedroalvarezthen, names are useless08:50
paulsherwoodyes, they are. there are examples without names, too, iirc08:51
paulsherwooddo you disagree with my reasoning above?08:52
paulsherwoodyou think it would be ok for foo..morph to contain a definition of bar, not foo?08:52
pedroalvarezjust saying, that if they have to match, then we are duplicating information08:54
paulsherwoodyou haven't answered my question :) is it ok for foo.morph to contain a definition of something named bar, not foo?08:56
pedroalvarezmaybe you want names like "uboot@genivi" but don't want filenames with '@' s for example08:57
pedroalvarezi don't know. I was just saying that the problem was something different, and now we have to change definitions for the fix you have introduced in ybd08:58
pedroalvarezand the fix is not really fixing the problem08:58
paulsherwoodoh, dear.08:59
paulsherwooda) i'm not saying we 'have to' change definitions. i'm suggesting it08:59
paulsherwoodb) with the change, ybd handles current and past definitions ok... but it warns for this situation09:00
pedroalvareznote that my main concern is that maybe your fix is not really fixing the problem leeming described09:00
paulsherwoodc) you may be right that i have not fixed the problem09:00
paulsherwoodbut i'm trying to :)09:00
paulsherwoodso his issue is at https://github.com/devcurmudgeon/ybd/issues/22309:01
paulsherwoodi take it you're saying that the error is that stratum specifies foo in path/to/foo.morph, and foo.morph doesn't contain a definition of foo09:04
paulsherwoodand you're ok with foo.morph containing bar, not foo. so the stratum can specify bar, in path/to/foo.morph09:05
*** locallycompact has joined #baserock09:06
pedroalvarezthat's what I understood from the issue description09:06
paulsherwoodwhat i understood from it is that foo.morph shouldn't contain 'bar' :)09:06
paulsherwoodbecause it's clearly confusing09:07
pedroalvarez"In the event that names do not match from your stratum and chunk morph files"09:07
paulsherwoodleeming: how did you *fix* this? i assume you modified foo.morph to contain foo, not bar?09:08
pedroalvarezoh dear.09:08
pedroalvarez_o_09:08
paulsherwoodpedroalvarez: why oh dear? i'm trying to understand the actual user perspective here09:09
leemingpaulsherwood, yes you are right. I corrected the name in the chunk to match the one listed in the stratum09:21
leemingI had templated the file form a previous one i was working on but forgot to change the name field09:22
leemingonly noticed it as I saw the ordering of the chunks in the output, and it seemed that a chunk was being skipped before the error09:22
edcraggthis sort of thing should error imo, this is the current behaviour of morph09:28
paulsherwoodedcragg: 'this sort of thing' - can you be more precise? there's a difference between my interpretation of what this problem actually is and pedroalvarez's, for example09:40
*** locallycompact has quit IRC09:43
edcraggpaulsherwood: errors/mistakes in definitions, for which the build tool should produce a clear indication of the problem so it can be fixed09:45
SotKis having the name different from the filename really an error?09:46
rjekThat drives me mad, and always has09:46
paulsherwoodi think it's confusing, and would prefer to make it an error. but it has not been an error so far09:46
SotKif they need to be the same, we should remove the name field altogether09:47
paulsherwoodSotK: it's not that simple. we support compound definitions in one file, with or without the possibility of a separate morph file for each09:47
paulsherwoodie right now we have actual examples of names with no path, and paths with no names09:48
paulsherwoodi would in general prefer to restrict things to make it clearer for users what's going on, but even so i wouldn't want to achieve it by rejecting all previous versions of definitions09:50
SotKis there some difference in meaning between the name and the path?09:50
SotKit seems to me that they are both a way to identify a chunk09:51
SotKs/chunk/definition/09:51
paulsherwoodpath refers to an actual file. name doesn't09:51
paulsherwoods/refers/is expected to refer/09:51
SotKdoes that make a real difference in how things work internally?09:54
SotKI just feel like having two separate things which *must* be the same is likely to be annoying rather than useful09:57
paulsherwoodyes, it does (at least for ybd, i don't know how morph parses definitions)09:57
paulsherwoodSotK: at the moment, we have two separate things which are normally the same, but occasionally different. and in most cases where they're different, the difference looks like a mistake09:58
paulsherwoodtake a look at some of the examples in https://gerrit.baserock.org/#/c/2170/09:59
paulsherwoodrjek: can you be precis about what drives you 'mad, and always has' ?10:02
rjekThe thing where a definition's name must match its filename10:03
*** tiagogomes has quit IRC10:04
paulsherwoodso you want that a name does not need to match10:07
paulsherwood?10:07
SotKpaulsherwood: what actually is the difference in how things work ooi?10:08
rjekpaulsherwood: I think the test is pointless.  Either take the name from the filename, or take the name from the name: field10:09
rjekI'd be happy with either :)10:09
SotKIndeed, most of those examples look like mistakes, or someone changing a filename but not the name itself, but I don't see any value in forcing them to be the same and yet allowing them to both exist10:10
SotKits just duplicating data, and will cause annoyance every time someone makes a mistake like the ones in https://gerrit.baserock.org/#/c/2170/10:10
paulsherwoodi agree that it's duplicating data, except when one of the fields is missing.10:11
SotKso make one of the fields mandatory, and get rid of the other?10:11
*** locallycompact has joined #baserock10:12
SotKdoes "path" have to be a path to a real file?10:12
paulsherwoodi wanted to go that route last year (my preference was 'name' to be mandatory and unique)10:12
paulsherwoodcurrently path needs to be a real file, yes10:12
paulsherwoodexcept when path is not specified :)10:13
paulsherwoodeg http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/audio-bluetooth.morph#n1310:13
paulsherwoodalsa-lib has no morph file, hence no path10:13
SotKwhat happens when path isn't specified? just assume defaults?10:14
paulsherwoodthe alsa-lib example covers that... build-system is specified, no need for a morph file10:14
SotKwhat is the problem with causing name to be mandatory and unique then?10:16
* SotK is confused10:16
paulsherwoodother people didn't want that10:16
paulsherwoodbecause it would require that (for example) we have linux@x86, linux@jetson etc10:17
paulsherwoodit would be much easier to parse definitions, though :)10:19
SotKI thought we already had some chunks named like that?10:20
paulsherwoodwe do. but it's not mandatory10:20
paulsherwoodwe have non-unique names10:20
leemingisn't there some way of just parsing the chunk references and detecting at each leaf if the stratum chunk name, matches the chunk file name (1 and only 1 match in the file)10:20
*** gtristan has quit IRC10:21
SotKso currently we need some unique combination of `path + name` right?10:21
paulsherwoodin a way, i think this is a smaller example of the complexities that happen in bitbake recipes10:21
*** tiagogomes has joined #baserock10:21
paulsherwoodunless something is locked down, we end up with variations10:21
paulsherwoodSotK: correct10:21
paulsherwoodso ybd creates pseudo path for things that are missing one, and indexes on that10:22
* locallycompact would also like to put into the pot of "things that would make definitions easier to parse", removing the context sensitive "kind:" field and moving it to the file extension.10:23
paulsherwoodlocallycompact: the pot is quite large. and the hole through which to pass changes is quite small currently10:24
paulsherwoodleeming: not sure what you mean. could you repeat, without 'leaf'? maybe give an actual example?10:24
leemingpaulsherwood, leaf refering to a leaf node in a parse tree10:25
paulsherwoodleeming: you did comp sci. i did not, sadly. and there is no 'tree' in my understanding of ybd10:25
leemingurm.. a whiteboard drawing would be much easier for me :\ ... let me think if i can reword10:27
paulsherwoodleeming: draw it and send a pic? :)10:27
pedroalvarezsystem == trunk10:27
pedroalvarezstrata == branches10:27
pedroalvarezchunk == leaf10:27
locallycompactno10:27
paulsherwoodlol10:27
paulsherwoodi thought i understood, for a moment, until locallycompact spake10:28
locallycompactok then, yes10:28
leemingform my understanding. The stratum references chunks files, can these chunk files can have more than chunk definition inside?10:28
SotKno10:28
leemingif it is a one to one mapping, then there are redundancies. From the stratum side, I define the chunk name and path. in the chunk file I redefine the name10:29
paulsherwoodnot currently. one of my objectives when starting ybd was to get to a generic compound component which could contain arbitrary nested components10:29
locallycompactincidentally, that's this picture - https://en.wikipedia.org/wiki/Series-parallel_partial_order10:30
locallycompact'arbitrary nested components'10:30
leemingassuming this is a sane thing to do. If we build up a dictionary of 'seen' morph refs from the stratum, and compare against the actually defines from chunks10:30
paulsherwoodmaybe that's what morph does - ybd just parses all the morph files10:32
SotKis our current requirement of having the name in the chunk file anything except a hangover from before chunks were in definitions?10:33
paulsherwoodpartially that, but also if there's no morph file, how else would you reference the chunk?10:34
locallycompactwithout name, and with kind superfluous, "chunk" morphs are just a collection of build instructions, it's just a non general DEFAULT then10:35
SotKlocallycompact finished where I was going10:36
locallycompactI think that can be made to make sense10:36
rjekTut, neither morph nor ybd parse YAML files10:36
rjekThe yaml library does the parsing.10:36
rdalei think file extensions and file paths in definitions are wrong because they aren't part of yaml and make it difficult to serialize into other formats10:36
rjekmorph and ybd /interpret/ the parsed data structures10:36
rjek</pedantic>10:36
leemingrjek, true, that is actually the source of the error I had10:36
paulsherwoodyes, but we still need to identify each chunk somehow, with a 'name' or 'label'. unless you expect that we leave them anonymous... which would be more confusing for users, not less10:37
leemingrjek, but if there was some pre-parse before that. we could throw a useful error10:37
locallycompactrdale, I disagree, they make it easier because I can parse context-free10:37
SotKpaulsherwood: why do we need anything more than the path to identify the chunk definition?10:37
paulsherwoodbecause some chunk's don't have files10:37
paulsherwoodeek, bad apostrophe10:38
SotKok, so all chunks have a name defined in the *stratum*10:38
rjekHow does one define a chunk without putting the definition in a file?10:38
paulsherwoodSotK: correct10:38
SotKsome of those chunks have a path, which is to a file which duplicates that name10:38
paulsherwoodrjek: a chunk is named within a stratum's morph file, for example10:39
SotKif we remove the name from that file (and the kind), it becomes just a set of build instructions10:39
SotKwhich is referenced by a chunk (in a stratum)10:40
SotKs/referenced/used/10:40
paulsherwoodhow does a user refer to a chunk? i think 'name' is required for that10:40
locallycompactthat's in the stratum10:41
SotKyes10:41
locallycompacta 'chunk' lives in the stratum, references a project and a set of build instructions10:41
SotKwe don't share chunks between strata anyway, so we don't lose anything there10:42
paulsherwoodyes we do - a given chunk morph file can be used in various strata10:42
SotKbut the chunk still needs to be defined (given a repo, ref, name, build-system, and so on) in the stratum10:43
paulsherwoodtrue10:43
locallycompactthat stays true, but the name just a hindrance, it's just another thing with a name that references the same build instructions10:43
paulsherwoodmy head is exploding, sorry10:43
leemingpaulsherwood, mine too.. i keep thinking I figure it out :D10:44
locallycompacthere's a problem I have right now, I want to install two different version of corba using the same build instructions10:58
*** wdutch has left #baserock10:59
locallycompactcan that be done without keeping duplicate morph files?10:59
locallycompactI think it can't10:59
edcraggnot without being hacky i don't think10:59
SotKindeed10:59
leemingso we need a new type, a meta-chunk? then add in the stratum "uses" ?11:01
locallycompactI don't think so11:02
leemingbuild-instructions != chunk-to-build, there is overlap11:02
SotKno, we need to make chunk morph files to not mention what chunk they are11:02
leemingtrue11:03
* SotK ponders writing something to the list11:03
edcraggthat could work11:03
leemingso currently the name inside the chunk is only there for reference? assuming there is only a one to one mapping?11:04
SotKso way way back, the chunk morph files lived in the source repo for the chunk11:05
SotKafaict, having the name in there is a hangover from that11:06
SotKI don't see any other reason for its existence anyway11:06
paulsherwoodlocallycompact: no, it can't currently11:20
*** gtristan has joined #baserock11:41
paulsherwoodjjardon: did you test https://gerrit.baserock.org/#/c/2162/ ?12:10
*** edcragg has quit IRC14:30
*** edcragg has joined #baserock14:32
*** edcragg has quit IRC15:11
*** edcragg has joined #baserock15:11
locallycompactI have some thing happening in a thing I'm building that says undefined reference to `dbus_message_iter_init'16:48
locallycompactI have the dbus libraries16:48
richard_mawif it's genivi, do you have their weird patches?16:52
locallycompactweird patches eh16:52
*** jonathanmaw has quit IRC17:13
*** rdale has quit IRC17:13
*** locallycompact has quit IRC17:15
*** edcragg has quit IRC18:04
*** edcragg has joined #baserock22:45

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