| *** gtristan has quit IRC | 00:47 | |
| *** gtristan has joined #baserock | 01:45 | |
| *** gtristan has quit IRC | 04:03 | |
| *** pedroalvarez has quit IRC | 04:23 | |
| *** pedroalvarez has joined #baserock | 04:24 | |
| *** ChanServ sets mode: +v pedroalvarez | 04:24 | |
| *** gtristan has joined #baserock | 05:22 | |
| *** CTtpollard has joined #baserock | 07:08 | |
| *** fay has joined #baserock | 07:26 | |
| *** fay is now known as faybrocklebank | 07:27 | |
| *** rdale has joined #baserock | 08:02 | |
| pedroalvarez | paulsherwood: I don't understand why the path and name have to match | 08:12 |
|---|---|---|
| pedroalvarez | I 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 #baserock | 08:16 | |
| *** faybrocklebank has quit IRC | 08:18 | |
| *** faybrocklebank has joined #baserock | 08:18 | |
| *** jonathanmaw has joined #baserock | 08:33 | |
| paulsherwood | pedroalvarez: 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 |
| pedroalvarez | then, names are useless | 08:50 |
| paulsherwood | yes, they are. there are examples without names, too, iirc | 08:51 |
| paulsherwood | do you disagree with my reasoning above? | 08:52 |
| paulsherwood | you think it would be ok for foo..morph to contain a definition of bar, not foo? | 08:52 |
| pedroalvarez | just saying, that if they have to match, then we are duplicating information | 08:54 |
| paulsherwood | you haven't answered my question :) is it ok for foo.morph to contain a definition of something named bar, not foo? | 08:56 |
| pedroalvarez | maybe you want names like "uboot@genivi" but don't want filenames with '@' s for example | 08:57 |
| pedroalvarez | i 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 ybd | 08:58 |
| pedroalvarez | and the fix is not really fixing the problem | 08:58 |
| paulsherwood | oh, dear. | 08:59 |
| paulsherwood | a) i'm not saying we 'have to' change definitions. i'm suggesting it | 08:59 |
| paulsherwood | b) with the change, ybd handles current and past definitions ok... but it warns for this situation | 09:00 |
| pedroalvarez | note that my main concern is that maybe your fix is not really fixing the problem leeming described | 09:00 |
| paulsherwood | c) you may be right that i have not fixed the problem | 09:00 |
| paulsherwood | but i'm trying to :) | 09:00 |
| paulsherwood | so his issue is at https://github.com/devcurmudgeon/ybd/issues/223 | 09:01 |
| paulsherwood | i 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 foo | 09:04 |
| paulsherwood | and you're ok with foo.morph containing bar, not foo. so the stratum can specify bar, in path/to/foo.morph | 09:05 |
| *** locallycompact has joined #baserock | 09:06 | |
| pedroalvarez | that's what I understood from the issue description | 09:06 |
| paulsherwood | what i understood from it is that foo.morph shouldn't contain 'bar' :) | 09:06 |
| paulsherwood | because it's clearly confusing | 09:07 |
| pedroalvarez | "In the event that names do not match from your stratum and chunk morph files" | 09:07 |
| paulsherwood | leeming: how did you *fix* this? i assume you modified foo.morph to contain foo, not bar? | 09:08 |
| pedroalvarez | oh dear. | 09:08 |
| pedroalvarez | _o_ | 09:08 |
| paulsherwood | pedroalvarez: why oh dear? i'm trying to understand the actual user perspective here | 09:09 |
| leeming | paulsherwood, yes you are right. I corrected the name in the chunk to match the one listed in the stratum | 09:21 |
| leeming | I had templated the file form a previous one i was working on but forgot to change the name field | 09:22 |
| leeming | only noticed it as I saw the ordering of the chunks in the output, and it seemed that a chunk was being skipped before the error | 09:22 |
| edcragg | this sort of thing should error imo, this is the current behaviour of morph | 09:28 |
| paulsherwood | edcragg: '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 example | 09:40 |
| *** locallycompact has quit IRC | 09:43 | |
| edcragg | paulsherwood: errors/mistakes in definitions, for which the build tool should produce a clear indication of the problem so it can be fixed | 09:45 |
| SotK | is having the name different from the filename really an error? | 09:46 |
| rjek | That drives me mad, and always has | 09:46 |
| paulsherwood | i think it's confusing, and would prefer to make it an error. but it has not been an error so far | 09:46 |
| SotK | if they need to be the same, we should remove the name field altogether | 09:47 |
| paulsherwood | SotK: it's not that simple. we support compound definitions in one file, with or without the possibility of a separate morph file for each | 09:47 |
| paulsherwood | ie right now we have actual examples of names with no path, and paths with no names | 09:48 |
| paulsherwood | i 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 definitions | 09:50 |
| SotK | is there some difference in meaning between the name and the path? | 09:50 |
| SotK | it seems to me that they are both a way to identify a chunk | 09:51 |
| SotK | s/chunk/definition/ | 09:51 |
| paulsherwood | path refers to an actual file. name doesn't | 09:51 |
| paulsherwood | s/refers/is expected to refer/ | 09:51 |
| SotK | does that make a real difference in how things work internally? | 09:54 |
| SotK | I just feel like having two separate things which *must* be the same is likely to be annoying rather than useful | 09:57 |
| paulsherwood | yes, it does (at least for ybd, i don't know how morph parses definitions) | 09:57 |
| paulsherwood | SotK: 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 mistake | 09:58 |
| paulsherwood | take a look at some of the examples in https://gerrit.baserock.org/#/c/2170/ | 09:59 |
| paulsherwood | rjek: can you be precis about what drives you 'mad, and always has' ? | 10:02 |
| rjek | The thing where a definition's name must match its filename | 10:03 |
| *** tiagogomes has quit IRC | 10:04 | |
| paulsherwood | so you want that a name does not need to match | 10:07 |
| paulsherwood | ? | 10:07 |
| SotK | paulsherwood: what actually is the difference in how things work ooi? | 10:08 |
| rjek | paulsherwood: I think the test is pointless. Either take the name from the filename, or take the name from the name: field | 10:09 |
| rjek | I'd be happy with either :) | 10:09 |
| SotK | Indeed, 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 exist | 10:10 |
| SotK | its 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 |
| paulsherwood | i agree that it's duplicating data, except when one of the fields is missing. | 10:11 |
| SotK | so make one of the fields mandatory, and get rid of the other? | 10:11 |
| *** locallycompact has joined #baserock | 10:12 | |
| SotK | does "path" have to be a path to a real file? | 10:12 |
| paulsherwood | i wanted to go that route last year (my preference was 'name' to be mandatory and unique) | 10:12 |
| paulsherwood | currently path needs to be a real file, yes | 10:12 |
| paulsherwood | except when path is not specified :) | 10:13 |
| paulsherwood | eg http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/audio-bluetooth.morph#n13 | 10:13 |
| paulsherwood | alsa-lib has no morph file, hence no path | 10:13 |
| SotK | what happens when path isn't specified? just assume defaults? | 10:14 |
| paulsherwood | the alsa-lib example covers that... build-system is specified, no need for a morph file | 10:14 |
| SotK | what is the problem with causing name to be mandatory and unique then? | 10:16 |
| * SotK is confused | 10:16 | |
| paulsherwood | other people didn't want that | 10:16 |
| paulsherwood | because it would require that (for example) we have linux@x86, linux@jetson etc | 10:17 |
| paulsherwood | it would be much easier to parse definitions, though :) | 10:19 |
| SotK | I thought we already had some chunks named like that? | 10:20 |
| paulsherwood | we do. but it's not mandatory | 10:20 |
| paulsherwood | we have non-unique names | 10:20 |
| leeming | isn'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 IRC | 10:21 | |
| SotK | so currently we need some unique combination of `path + name` right? | 10:21 |
| paulsherwood | in a way, i think this is a smaller example of the complexities that happen in bitbake recipes | 10:21 |
| *** tiagogomes has joined #baserock | 10:21 | |
| paulsherwood | unless something is locked down, we end up with variations | 10:21 |
| paulsherwood | SotK: correct | 10:21 |
| paulsherwood | so ybd creates pseudo path for things that are missing one, and indexes on that | 10: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 | |
| paulsherwood | locallycompact: the pot is quite large. and the hole through which to pass changes is quite small currently | 10:24 |
| paulsherwood | leeming: not sure what you mean. could you repeat, without 'leaf'? maybe give an actual example? | 10:24 |
| leeming | paulsherwood, leaf refering to a leaf node in a parse tree | 10:25 |
| paulsherwood | leeming: you did comp sci. i did not, sadly. and there is no 'tree' in my understanding of ybd | 10:25 |
| leeming | urm.. a whiteboard drawing would be much easier for me :\ ... let me think if i can reword | 10:27 |
| paulsherwood | leeming: draw it and send a pic? :) | 10:27 |
| pedroalvarez | system == trunk | 10:27 |
| pedroalvarez | strata == branches | 10:27 |
| pedroalvarez | chunk == leaf | 10:27 |
| locallycompact | no | 10:27 |
| paulsherwood | lol | 10:27 |
| paulsherwood | i thought i understood, for a moment, until locallycompact spake | 10:28 |
| locallycompact | ok then, yes | 10:28 |
| leeming | form my understanding. The stratum references chunks files, can these chunk files can have more than chunk definition inside? | 10:28 |
| SotK | no | 10:28 |
| leeming | if 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 name | 10:29 |
| paulsherwood | not currently. one of my objectives when starting ybd was to get to a generic compound component which could contain arbitrary nested components | 10:29 |
| locallycompact | incidentally, that's this picture - https://en.wikipedia.org/wiki/Series-parallel_partial_order | 10:30 |
| locallycompact | 'arbitrary nested components' | 10:30 |
| leeming | assuming 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 chunks | 10:30 |
| paulsherwood | maybe that's what morph does - ybd just parses all the morph files | 10:32 |
| SotK | is our current requirement of having the name in the chunk file anything except a hangover from before chunks were in definitions? | 10:33 |
| paulsherwood | partially that, but also if there's no morph file, how else would you reference the chunk? | 10:34 |
| locallycompact | without name, and with kind superfluous, "chunk" morphs are just a collection of build instructions, it's just a non general DEFAULT then | 10:35 |
| SotK | locallycompact finished where I was going | 10:36 |
| locallycompact | I think that can be made to make sense | 10:36 |
| rjek | Tut, neither morph nor ybd parse YAML files | 10:36 |
| rjek | The yaml library does the parsing. | 10:36 |
| rdale | i 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 formats | 10:36 |
| rjek | morph and ybd /interpret/ the parsed data structures | 10:36 |
| rjek | </pedantic> | 10:36 |
| leeming | rjek, true, that is actually the source of the error I had | 10:36 |
| paulsherwood | yes, 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 less | 10:37 |
| leeming | rjek, but if there was some pre-parse before that. we could throw a useful error | 10:37 |
| locallycompact | rdale, I disagree, they make it easier because I can parse context-free | 10:37 |
| SotK | paulsherwood: why do we need anything more than the path to identify the chunk definition? | 10:37 |
| paulsherwood | because some chunk's don't have files | 10:37 |
| paulsherwood | eek, bad apostrophe | 10:38 |
| SotK | ok, so all chunks have a name defined in the *stratum* | 10:38 |
| rjek | How does one define a chunk without putting the definition in a file? | 10:38 |
| paulsherwood | SotK: correct | 10:38 |
| SotK | some of those chunks have a path, which is to a file which duplicates that name | 10:38 |
| paulsherwood | rjek: a chunk is named within a stratum's morph file, for example | 10:39 |
| SotK | if we remove the name from that file (and the kind), it becomes just a set of build instructions | 10:39 |
| SotK | which is referenced by a chunk (in a stratum) | 10:40 |
| SotK | s/referenced/used/ | 10:40 |
| paulsherwood | how does a user refer to a chunk? i think 'name' is required for that | 10:40 |
| locallycompact | that's in the stratum | 10:41 |
| SotK | yes | 10:41 |
| locallycompact | a 'chunk' lives in the stratum, references a project and a set of build instructions | 10:41 |
| SotK | we don't share chunks between strata anyway, so we don't lose anything there | 10:42 |
| paulsherwood | yes we do - a given chunk morph file can be used in various strata | 10:42 |
| SotK | but the chunk still needs to be defined (given a repo, ref, name, build-system, and so on) in the stratum | 10:43 |
| paulsherwood | true | 10:43 |
| locallycompact | that stays true, but the name just a hindrance, it's just another thing with a name that references the same build instructions | 10:43 |
| paulsherwood | my head is exploding, sorry | 10:43 |
| leeming | paulsherwood, mine too.. i keep thinking I figure it out :D | 10:44 |
| locallycompact | here's a problem I have right now, I want to install two different version of corba using the same build instructions | 10:58 |
| *** wdutch has left #baserock | 10:59 | |
| locallycompact | can that be done without keeping duplicate morph files? | 10:59 |
| locallycompact | I think it can't | 10:59 |
| edcragg | not without being hacky i don't think | 10:59 |
| SotK | indeed | 10:59 |
| leeming | so we need a new type, a meta-chunk? then add in the stratum "uses" ? | 11:01 |
| locallycompact | I don't think so | 11:02 |
| leeming | build-instructions != chunk-to-build, there is overlap | 11:02 |
| SotK | no, we need to make chunk morph files to not mention what chunk they are | 11:02 |
| leeming | true | 11:03 |
| * SotK ponders writing something to the list | 11:03 | |
| edcragg | that could work | 11:03 |
| leeming | so currently the name inside the chunk is only there for reference? assuming there is only a one to one mapping? | 11:04 |
| SotK | so way way back, the chunk morph files lived in the source repo for the chunk | 11:05 |
| SotK | afaict, having the name in there is a hangover from that | 11:06 |
| SotK | I don't see any other reason for its existence anyway | 11:06 |
| paulsherwood | locallycompact: no, it can't currently | 11:20 |
| *** gtristan has joined #baserock | 11:41 | |
| paulsherwood | jjardon: did you test https://gerrit.baserock.org/#/c/2162/ ? | 12:10 |
| *** edcragg has quit IRC | 14:30 | |
| *** edcragg has joined #baserock | 14:32 | |
| *** edcragg has quit IRC | 15:11 | |
| *** edcragg has joined #baserock | 15:11 | |
| locallycompact | I have some thing happening in a thing I'm building that says undefined reference to `dbus_message_iter_init' | 16:48 |
| locallycompact | I have the dbus libraries | 16:48 |
| richard_maw | if it's genivi, do you have their weird patches? | 16:52 |
| locallycompact | weird patches eh | 16:52 |
| *** jonathanmaw has quit IRC | 17:13 | |
| *** rdale has quit IRC | 17:13 | |
| *** locallycompact has quit IRC | 17:15 | |
| *** edcragg has quit IRC | 18:04 | |
| *** edcragg has joined #baserock | 22:45 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!