IRC logs for #baserock for Friday, 2014-08-08

*** fay_ [] has joined #baserock07:00
*** locallycompact [~lc@] has joined #baserock07:37
*** tiagogomes [] has joined #baserock07:58
*** tiagogomes [] has quit [Remote host closed the connection]08:02
*** tiagogomes [] has joined #baserock08:02
*** tiagogomes [] has quit [Ping timeout: 260 seconds]08:14
*** jonathanmaw [~jonathanm@] has joined #baserock08:20
*** franred [] has joined #baserock08:25
*** tiagogomes [] has joined #baserock08:55
*** locallycompact [~lc@] has quit [Ping timeout: 272 seconds]08:55
*** flatmush [] has joined #baserock09:18
*** locallycompact [] has joined #baserock09:34
*** tiagogomes [] has quit [Remote host closed the connection]10:33
*** tiagogomes [~tiagogome@] has joined #baserock10:43
*** locallycompact [] has quit [Ping timeout: 255 seconds]12:20
*** locallycompact [] has joined #baserock12:22
persiaI was just updating my definitions, and saw the new "mason" directory.  Looking a bit more, there seem to also be directories for distbuild, gitlab-ci-runner, gitlab-server, genivi-devl-system-arm7, and vagrant-files.12:39
persiaMost of these seem to have a similar format, but mason is different, although the contents don't seem too dissimilar: is mason special in some way that blocks using the manifest format?12:40
tlsa1. I was unaware of a standard format, 2. I think the plan is to put it in a chunk eventually12:41
persiaAlso, do we expect the set of these to proliferate within the definitions repository?  If so, why are some other systems (e.g. trove) not done this way?  If not, why do we have so many?12:41
persiatlsa: Heh, yeah, documentation is sparse :)  I just discovered the apparent standard format today when I went looking as a result of seeing the "mason" directory .12:42
persiatlsa: If it goes in a chunk: is there a reason to have that be eventually, rather than sooner?  It strikes me that if these don't belong in definitions, we probably want to block such additions on review, as otherwise everyone downloads the history in the future, containing temporary data that won't be relevant or interesting.12:44
persiaOn an only slightly related topic: does the content of image-package-example/ still have relavance?  Is there a reason someone would not want to use morph for this?12:45
tlsasome could move to a chunk (,, but most of the rest is to configure the deployment, so would likely stay there12:45
persiaSo you think we expect these to proliferate?  Any idea why we don't have such a thing for trove?12:46
tlsano idea12:47
tlsawe used the existing distbuild and trove cluster morphologies as a template for the mason work12:48
persiaThat seems like a sensible place to start.  Perhaps it's just lack of docs that makes it different.12:49
persiaIn my mind, ideally we'd either have it in a chunk (like trove-setup), or use the semi-standard model (like distbuild/manifest and friends). But I have no idea which is the right way, or why one might choose one over the other.12:56
SotKthe "standard format" uses the install-files configure extension, but the mason folder appears to just be used by mason.configure, hence the different layout13:05
persiaSo the expectation is that we will have lots of these folders: as many as one per system, to support install-files?13:16
richard_mawcurrently, yes, though my preferred approach is that when appropriate there is a configuration extension that generates the config, rather than dropping it in with install-files13:18
persiaAlso, can a deployment use multiple configure extensions, so mason could use install-files for the file installs, and then do it's magic?13:19
persiarichard_maw: So when defining a system, if I want deployment-time magic, I should generally expect to write a configuration extension, and do everything therein?13:20
richard_mawpersia: if there's a brand new thing that needs to be configured, yes, though I'd like to make it possible for chunks to be able to provide configuration extensions13:20
persiaAh, so systems wouldn't generally need this sort of thing?13:21
persiaI like that idea.13:21
richard_mawthe reason why we copy files in with configuration extensions though is that the install-files API is arcane and unforgiving13:21
persiaAh.  Yes, I can see how one would wish to avoid that :)13:22
*** liw-orc [] has quit [Quit: Coyote finally caught me]13:54
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]14:59
*** fay_ [] has quit [Remote host closed the connection]15:07
SotKIs there any reason why morph3 should continue to be called morph3 once morph2 is gone?15:31
KinnisonI'd have a final patch which renames it, in your series, if possible15:32
SotKthat was my plan if no-one had any objections to renaming it15:32
Kinnisonmorphlib.morphology.Morphology is a tad long, but perhaps15:33
SotKmorph3 is only ever instantiated by morphloader or some parts of the test suite, so its not often morphlib.morphology.Morphology would be needed15:35
Kinnisonworks for me then15:36
tlsawhat are morph2 and 3?15:38
Kinnisonthe reimplementation and subsequent reimplementation of morph.Morphology15:39
Kinnisonyay hysterical raisins15:39
SotKpart of the codebase uses morph3, and part uses morph2 for hysterical raisins too, so they both hung around15:39
tlsamorph.Morphology's a port of morph?15:39
*** franred [] has quit [Quit: Leaving]16:48
*** jonathanmaw [~jonathanm@] has quit [Quit: Leaving]16:59
*** locallycompact [] has quit [Ping timeout: 260 seconds]17:34
richard_mawI sent a patch for build not needing to create temporary build branches when it doesn't need to:
richard_mawI'll probably take a look at paulsherwood's workflow tweaks mail and the morph2 removal this weekend22:13

Generated by 2.15.3 by Marius Gedminas - find it at!