IRC logs for #baserock for Friday, 2015-04-10

*** zoli__ has joined #baserock06:09
*** Albert has joined #baserock07:10
*** a1exhughe5 has joined #baserock07:28
straycatfranred, i think you misunderstand the suggestion08:04
straycatin any case i'm kinda getting tired of arguing over every little detail in baserock08:04
*** rdale has joined #baserock08:05
pedroalvarezstraycat: the thing is that only moving configobj is not enough08:10
pedroalvarezcloud-init is already missing things that are in python-common08:11
pedroalvarezI don't know what is failing in this conversation, really08:11
pedroalvarezstraycat: maybe you are missing the fact that cloudinit in the base systems is already broken, since we moved things from cloudinit-support to python-common08:12
pedroalvarezat that point we should have included python common to base systems, but we forgot08:12
perrylcan anyone tell me how to set PYTHONPATH to run a specific version of morph?08:16
franredperryl, <-- and then you set the morph repo to the branch that you want to test?08:17
straycatpedroalvarez, yeah that wasn't clear, regardleess there's no compelling reason to add all this bloat to the base system. why do i need to be able to deploy a base system to openstack?08:23
*** jonathanmaw has quit IRC08:29
straycatso my vote is removing cloud-init from the base system to keep things minimal, maybe it's worth appealing to others for their thoughts08:31
pedroalvarezI don't have a strong opinion about that. I'm only worried about base systems being broken08:31
richard_mawsince base is ill-defined and cloud init is broken in its current state, so nobody can be using it, I'd +1 a patch to remove it08:34
* richard_maw looks at the gerrit link08:34
*** edcragg has joined #baserock08:34
franredSame here, I am not opposed to remove cloud-init support from the base-systems either08:35
*** ssam2 has joined #baserock08:37
*** ChanServ sets mode: +v ssam208:37
*** jonathanmaw has joined #baserock08:38
*** gary_perkins has joined #baserock08:38
franredssam2, good morning, we are discussing about remove cloud-init support from base-systems there are 2 +1 to remove, 2 +0, do you have anything against this?08:38
jjardon+1 from me to remove it as well08:40
ssam2I think it's a bad idea, but I'm not going to block it08:40
ssam2i based the Gerrit system off the base system, for example, and was handy to not then have to add cloud-init support08:41
ssam2but it's not the end of the world08:41
franredstraycat, pedroalvarez, richard_maw, jjardon, ssam2, ok, I will abandon and create a patch to remove the cloud-init support from base-systems08:46
pedroalvarezfranred: also the configure exts08:47
franredpedroalvarez, sorry I don't undertand, you want me to configure exts or remove it?08:49
pedroalvarezlet me think, one second08:50
richard_mawfranred: remove the cloud-init configuration extensions listed in the system I guess08:50
pedroalvarezyes, although if we keep it there, and someone tries to configure a system with cloud-init, the deployment will fail08:51
franredpedroalvarez, I'd suggest to remove it too08:53
pedroalvarezfranred: meh, just remove the "cloud-init" configuraton extensions from the systems as well08:53
franredpedroalvarez, snap08:54
* richard_maw has just noticed that one of his irssi scripts is not currently functioning08:54
richard_mawquick, someone say cloud08:55
straycatfranred, cool08:57
franredstraycat, ssam2, richard_maw, pedroalvarez, jjardon,
straycatahh i hadn't noticed gerrit lets you edit the commit message from the web ui, that's nice09:10
richard_mawit doesn't re-flow it for you though, which annoys me09:11
* richard_maw accidentally wrote a very long line in it, since the web ui line wrapped it without breaking the line in the output09:11
Albertybd/morph-related: I've been looking at a bug on YBD where strata that have the same name as chunks cause errors in recursion. I was wondering how morph handles this?09:12
straycatrichard_maw, your +1 doesn't seem to apply to the version with the updated commit msg09:12
richard_mawAlbert: badly in general, but specifically it knows that strata can only depend on other strata, and chunks can only depend on other chunks, so it disambiguates based on that, which means we don't get a loop there09:13
richard_mawAlbert: we've previously had loops from accidentally being able to depend on a chunk from another strata, and it being unpredictable which version was actually referred to, but we don't accidentally depend on the wrong kind of definition09:14
* jjardon thinks morph should enforce unique names to avoid problems09:15
* SotK too09:16
richard_mawmaybe, but I can't make my mind up about whether we should re-work the definitions so that you do this by file names *having* to be unique, or post-hoc validatoin to make sure you haven't defined something twice09:16
*** wschaller has joined #baserock09:17
AlbertIn this case we have the 'ruby' strata depending on the 'ruby' chunk. There are others besides. I assume morph handles this.09:17
SotKI wonder if it would be better to think of that as "Definitions version X requires names to be unique."09:17
*** Krin has joined #baserock09:17
SotKand then tools which support that (ie. both morph and ybd) should enforce uniqueness09:18
AlbertI was thinking some sort of mangling in ybd for the time being09:19
Albertbut that would be a pain09:19
SotKAlbert: you could send a patch to definitions to rename the ruby stratum to ruby-common or similar09:20
SotKI doubt there would be objections09:20
richard_mawSotK: I believe paulsherwood is working on one09:20
* richard_maw saw him push a branch09:20
AlbertI gather from paulsherwood that conversations ensue09:20
AlbertBut paul would prefer YBD to handle what morph can handle, so I was wanting to find out how you guys have done it.09:27
richard_maweffectively it's just a different namespace09:28
richard_mawmorph is currently buggy in that there's a strata namespace and a chunks namespace, when what would make sense is a per-stratum chunks namespace09:28
AlbertWhat if the effect of these bugs, and how tractable or otherwise are they? In other words is it an approach worth taking/avoiding in YBD?09:39
Albertis *09:39
richard_mawAlbert: the effect of that bug is that if two strata hava a chunk called foo, then we end up with one with the union of the dependencies, and the build commands and build commit selected arbitrarily as the first encountered in the traversal09:41
richard_mawin the wrong circumstances this can result in a loop09:42
AlbertSo unique names would benefit all?09:43
*** sambishop has quit IRC09:43
richard_mawunique names, or per-stratum scoped names09:43
straycatper-stratum scoped makes more sense imo09:45
*** sambishop has joined #baserock09:45
AlbertOK thanks for your input guys. Much appreciated.09:45
* SotK thinks so too09:45
* paulsherwood would prefer unique names, as he has said many times09:45
paulsherwoodhowever, for ybd i want to be able to build all previous versions of definitions.git, and morphs.git if possible, so i need to find a way to deal with the recursion09:46
richard_mawpaulsherwood: for _all_ versions of morphs.git, you'd need to use the timestamp of the commit to reason about the definitions format09:47
AlbertSo a similar namespaces approach?09:47
paulsherwoodrichard_maw: you may be right. i have a theory, though :)09:47
* paulsherwood has been wrong before, of course09:48
richard_mawpaulsherwood: I recall some changes that were staged to change the behaviour of an existing field, I'm not sure you'd have sufficient context without checking the time09:48
paulsherwoodrichard_maw: ok, thanks for the warning :-)09:48
paulsherwoodrichard_maw: note i'm trying to ignore as many fields as possible :-)09:49
*** jonathanmaw has quit IRC09:49
richard_mawpaulsherwood: I'm not sure how well that will serve you, as we only introduced fields when we thought we needed them09:50
paulsherwoodrichard_maw: fair enough. but i can ignore 'kind' for example. and 'products', currently09:52
paulsherwoodrichard_maw: i thought i could ignore 'name' because others suggested that, but it seems i can't09:52
richard_mawkind was pretty much always possible to ignore because of context, products can be ignored if you don't need to have a small initramfs, as can the artifacts fields09:52
jjardonpaulsherwood: are you still working in a patch to have unique names in our definitions?09:55
paulsherwoodi started one. my concern based on the discussion here is that only jjardon and paulsherwood are actually in favour of it10:03
jjardonAnd SotK . and I think richard_maw would be OK with that as well10:05
rdalei think we should have proper nested scopes, and having only global names doesn't scale10:06
richard_mawI'm not yet convinced that morph needs to enforce uniqueness, or _how_ to do so, but for our definitions, I think uniqueness helps the cognitive load10:06
richard_mawso I'm happy to +1 a patch to rename the strata to make it so10:07
ssam2I think unique names in definitions is a good idea10:07
ssam2I wasn't sure about names like 'lorry-common', that's kind of why I didn't reply yet10:08
ssam2cus I haven't got a better idea :)10:08
SotKlorry-core maybe?10:09
SotKthey both seem a bit strange though I feel10:09
jmacsAnything ending in '-core' sounds like a music genre to me10:09
paulsherwoodlorry-things, lorry-group, lorry-set, lorry-stuff10:13
* jjardon voted lorry-group10:14
paulsherwoodone more +1 and i'll do the patch10:15
paulsherwood(ruby-group, erlang-group, ansible-group, swift-group)10:15
richard_mawor we could take the gnu convention and stuff -utils or -tools10:15
* paulsherwood has learned the hard way, over many years, that names are a source of disproportionate grief10:16
richard_mawthough that may end up in the silly situation of having coreutils-utils10:16
richard_mawthere are 2 challenges in computing: 1. names, 2. memory management, 3. off by one errors10:16
paulsherwood4. pbkac :)10:16
radiofree+1 lorry-group10:16
paulsherwoodwe have a winner :-)10:17
*** jonathanmaw has joined #baserock10:17
richard_mawI didn't like lorry-group, but couldn't articulate why, so if I can't justify it to myself, it's not even worth mentioning, because I can't justify this opinion to anyone else10:18
DavePageAnd now you've mentioned it by talking about how you're not going to mention it. Cicero would be proud :)10:18
* SotK marginally prefers lorry-components to lorry-group, but decided to stop bikeshedding10:20
ssam2lorry-group is OK10:22
*** wschaller has quit IRC10:31
straycatoh wait10:32
AlbertBut this renaming still leaves the fact that YBD can't deal with older versions?10:34
AlbertCan someone provide a quick pointer to the where morph deals with namespaces so I can take a look?10:37
straycatrdale, fwiw i agree *shrug*10:46
*** wschaller has joined #baserock10:47
richard_mawAlbert: not easily, there's no explicit namespacing, sources of all kind are put in the sourcepool in, and the artifactresolver joins up the dependencies10:48
paulsherwoodAlbert: not yet, but i still have hope :)10:48
richard_mawstraycat, rdale: As do I, but I think morph should be able to support both10:48
straycatwell yeah unique would be a subset of per stratum scoped...10:49
ssam2Albert: Morph calculates the cache identity of a source here:
persiaOn lorry-foo: I don't care enough to suggest we change it after the above discussion, but generally believe that we ought describe things in terms of themselves, rather than what they might contain.  So "archive-mirroring" would be a sensible sort of function name, using this case as an example, which function can be sensibly added as a feature for a system.10:49
ssam2Albert: you can see it uses a different algorithm depending on the 'kind' field10:49
ssam2so a chunk named foo and a stratum named foo will have different cache identities10:49
ssam2does that help?10:50
ssam2persia: that's a good idea, at least for 'lorry'10:50
persiaFor lorry, I'm +1 on "lorry-group" just to make the issue go away, but I'd prefer the same logic I used above to be applied next time.10:51
ssam2me too10:51
Albertthanks ssam richard_maw10:56
jjardonI think thats orthogonal to the previous conversation: you can always use archive-mirroring-group to name the stratum11:20
persiaI don't think "group" belongs there.  I think the names for larger components should be semantically mapped to functions, so that the system defintion reads like a list of functions.11:32
persiaAnd while I agree it is orthogonal to the issue of name duplication, I assert it is very critical to the process of eliminating name duplication.11:32
persia(whether this is always a good idea is another discussion, which I'm not prepared to enter today)11:32
*** wschaller has quit IRC12:02
* SotK idly wonders why we have "build-system-x86_64.morph" but "devel-system-x86_64-generic.morph"13:40
*** wschaller has joined #baserock13:42
ssam2it kind of makes sense ... 'generic' says 'you might want to adapt this for your own needs'13:43
ssam2where build-system is more of a fixed 'you need this stuff to build Baserock, nothing more.'13:43
ssam2although none of that is really true, I'd happily remove -generic from everything13:43
jonathanmawI have a baserock VM on my laptop, but it is apparently too slow to build systems in a reasonable timeframe. I can get another VM on a server somewhere (I assume), but will have a problem upgrading the one on my VM (for testing) - it only gives an IP address as part of my laptop's virtual network. How do I get it accessible on a wider network?13:43
ssam2why not use a chroot on your laptop?13:44
jonathanmawssam2: for building?13:44
ssam2they do work for building, but if your laptop is slow that might still be too slow13:44
persiaThose should probably be reconciled at some point, yes.13:45
persiaDo we expect multiple x86 BSP flavours?13:45
ssam2but for testing, maybe a chroot would be appropriate. Then upgrading is just a case of: deploy test chroot as .tar -> manage-baserock add foo ./path/to/.tar -> enter-baserock foo13:45
nowsterpaulsherwood: talking about line noise earlier.... # LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$1}=$213:46
nowster; } END { for (sort keys %x) { printf "%-32s %s\n", $_, $x{$_}; } }' morph.log13:46
ssam2persia: i don't think a one-size-fits-all kernel config will ever be possible.13:46
ssam2although we try, at the moment :)13:46
nowster... try again ...13:46
nowster# LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$1}=$2; } END { for (sort keys %x) { printf "%-32s %s\n", $_, $x{$_}; } }' morph.log13:46
ssam2bless you13:47
nowsterwhere's the build times link on the wiki?13:48
jonathanmawssam2: can't test in a chroot, I need graphics, and my experiences with the fbdev renderer in a chroot have been unfriendly.13:49
ssam2oh, if you need graphics, a chroot probably isn't appropriate13:51
ssam2i can't really help with virtualmachine networking though, it makes my head spin13:52
ssam2nowster: no idea, can't find it using the search box13:52
ssam2nowster: 'git grep' in my local clone of the wiki turned up
nowsterssam2: I found it by searching for an arbitrary time13:53
persiassam2: I used to agree with you, but the Canonical kernel team convinced me otherwise during a long series of summit sessions over many years when they explained to me why there was no need for separate kernels for servers, tablets, phones, realtime systems, audio mixing decks, virtual machines, etc., and that a kernel that worked well for desktop could also meet all those needs.13:55
ssam2i shall bow to their knowledge, then :)13:56
persiaThey may be mistaken, and I encourage others who know better to continue to have multiple BSPs: I've just given up the argument as I lost it too many times in a row.13:57
*** straycat has left #baserock13:57
nowsterpage updated14:01
nowster# LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$2}.="$1 "; } END { for my $t (reverse sort keys %x) { for (sort split(/ /,$x{$t})) { printf "%s [%s]\n", $t, $_; } } }' morph.log14:02
pedroalvareznowster: maybe worth noting that "script" in the page?14:05
nowsterGood idea!14:05
pedroalvareznowster: I'd suggest a removal of the artifacts and morph.log14:06
nowsterpedroalvarez: beg pardon?14:07
nowsterOh, I see! Delete the cache and the existing morph log.14:09
pedroalvareznowster: I mean, my suggestion was to add some information about how to generate those build-times, and that would be something like 1) remove the artifacts to make sure that you re-build everything. 2)remove morph.log to clean it and remove previous build times 3) build whatever you like 4) run this perl script14:09
pedroalvarezI can do that actually14:09
nowsterAm editing page14:10
pedroalvarezta :)14:10
nowsterOK... who misspelled artefacts? :)14:11
pedroalvareznowster: hehe,`git blame`14:11
pedroalvareznowster: cool14:19
* pedroalvarez adds a [toc]14:20
perryli have a couple of quick questions about my distbuild-start/cancel, both are currently working via duplicating the Initiator class and renaming it (i.e. InitiatorStart, InitiatorCancel); would this be better pushed as-is and change to using super in a follow-up patch, or modified to use super(Initiator, self) now?14:48
ssam2if you can do it in one without the patch being really confusing, do it in one. But doing it separately and having a note saying 'I'll clean this up a separate change' would be fine too14:49
ssam2*in a separate change14:49
perrylno problem, that makes sense! the patches have been tested and work fine as is, it's more of a cluttering issue. i'll see how it looks, add a comment about cleanup and then push14:51
ssam2if you do it in a separate patch you can test squashing them and see how it looks14:56
perryli have done, it's a +439, -10 beast14:56
perrylthere is an issue in that it's rebased off my list-jobs patch, not sure whether to rebase that out so there's no duplication with the list-jobs patch currently in review14:58
ssam2makes sense to base it off that branch, since we need all of them for the 'build without persistant connection' feature to be much use15:00
perrylaye, there's very little way of testing if start and cancel work without it, unless you're willing to delve into morph-controller.log each time15:01
perrylright, if that's sorted i'll push the branch for review now15:01
radiofreethe jetson times are now widely off15:06
radiofreei suppose widely off works15:06
nowsterpaulsherwood: you'll notice I've updated it15:06
radiofreebasically they're not a true reflection anymore (gcc doesn't take an hour to build)15:06
radiofreehow should i update them? remove the current ones? add to the top of the list?15:14
*** zoli__ has quit IRC15:16
paulsherwoodradiofree: remove the current ones15:16
paulsherwoodmaybe separate into pages for each class of hardware?15:17
* pedroalvarez removes his identical answer15:17
* persia has very strong opinions about the different meanings of "artifact" and "artefact", and wonders which page is potentially using "artefact" in the desire to have consistent semantics.15:23
jjardonWhat's the difference? A quick google search shows they mean the same15:26
rdalei found this comment which i like: "Seems to be an artifact of two countries separated by one language!"15:27
nowsterIf I put "artifact" into the Oxford Dictionaries site it corrects it to artefact.15:33
nowsterOK. We have it with "i" in the USA and "e" in the UK and some other places.15:34
rdalei prefer avoiding british english for anything to do with computer programming15:35
nowsterrdale: you mean "programing", surely? :)15:36
rdaleis it? oh no15:36
nowsterconsonant doubling like that is a British trait15:36
jmacsIf you were truly British you'd write computer programmes15:37
persiajjardon: The difference used to be that "artifact" was something created by artifice, and "artefact" was something that was a side-effect of creation.  The US decided to spell the words the same in the early 20th century because it was too confusing to differentiate, and certain parties in the UK decided that "artefact" must be a UK spelling of US "artifact" in the late 20th century.  I don't agree with any of the modern interpretations, and want the15:37
persia traditional ones, because the distinction is useful.15:37
nowsterNoah versus Samuel15:38
SotKpersia: +115:38
jmacspersia: So "JPEG artefact" would be a correct use?15:38
persiajmacs: Yes.15:38
persiaA baserock artifact may likely contain a jpeg artefact.15:39
nowsterArs Gratia Artis!15:39
* nowster roars quietly.15:40
jjardonpersia: interesting, thanks for the explanation15:41
nowsterThere's a similar history to the -ise/-ize split.15:43
persianowster: What was the semantic difference for that one?15:44
* persia thought it was just a difference of opinion in orthography between Oxford and Cambridge15:44
nowsterIt's all Greek to me. :)15:44
*** a1exhughe5 has quit IRC15:45
*** CTtpollard has quit IRC15:46
*** zoli__ has joined #baserock15:59
*** petefoth has joined #baserock16:26
*** petefoth has quit IRC16:29
*** zoli__ has quit IRC16:30
*** simonh_ has quit IRC16:44
*** simonh_ has joined #baserock16:46
*** jonathanmaw has quit IRC16:48
*** Krin has quit IRC16:48
*** wschaller has quit IRC16:53
*** tiagogomes_ has quit IRC16:57
*** ssam2 has quit IRC17:08
*** Albert has quit IRC17:12
*** simonh_ has quit IRC17:24
*** sambishop has quit IRC17:35
*** sambishop has joined #baserock17:47
*** edcragg has quit IRC17:50
*** flatmush1 has joined #baserock17:53
*** flatmush has quit IRC17:53
*** gary_perkins has quit IRC17:54
*** sambishop has quit IRC18:33
*** zoli__ has joined #baserock18:42
*** zoli__ has quit IRC18:46
*** sambishop has joined #baserock18:55
*** zoli__ has joined #baserock22:33
*** zoli__ has quit IRC23:08

Generated by 2.15.3 by Marius Gedminas - find it at!