IRC logs for #baserock for Wednesday, 2015-05-06

*** zoli__ has joined #baserock00:48
*** zoli__ has quit IRC00:52
*** zoli__ has joined #baserock02:36
*** zoli__ has quit IRC02:42
*** zoli__ has joined #baserock04:38
*** zoli__ has quit IRC04:42
*** zoli__ has joined #baserock05:26
*** sambishop has quit IRC05:34
*** inara has quit IRC05:48
*** inara has joined #baserock06:03
*** zoli__ has quit IRC06:15
*** zoli__ has joined #baserock06:36
*** sambishop has joined #baserock06:57
* straycat meows07:03
*** a1exhughe5 has joined #baserock07:11
straycat was a good article07:29
*** Albert__ has joined #baserock07:30
*** Albert__ has quit IRC07:33
*** Albert has joined #baserock07:34
*** persia_ has quit IRC07:39
*** persia_ has joined #baserock07:40
*** persia_ has joined #baserock07:40
*** sherm_ has joined #baserock07:52
*** mariaderidder has joined #baserock07:53
*** bashrc has joined #baserock08:07
*** edcragg has joined #baserock08:19
KinnisonThank you straycat, that is an interesting article indeed.08:19
*** gary_perkins has joined #baserock08:27
*** jonathanmaw has joined #baserock08:27
*** ssam2 has joined #baserock08:31
*** ChanServ sets mode: +v ssam208:31
*** bfletcher has joined #baserock08:33
ssam2good morning08:37
KinnisonHi ssam208:38
ssam2I have a bunch of Morph patches that it'd be nice for people to review08:39
ssam2there is a reward at the end08:39
Kinnisonis it chocolate?08:40
ssam2this distbuild branch seems to fix a longstanding problem at a customer site: (And has +1 from franred already)08:40
ssam2it's not chocolate08:40
Kinnisonthere's merge conflict statements in the summary08:40
ssam2a couple of other tiny distbuild ones (+1 already from straycat): and
ssam2Kinnison: yes, they depend on each other so patches 2, 3, and 4 will show as 'merge conflict' until patch 1 is merged08:41
ssam2one patch for sysroot.write that fixes a regression (+1 from richard maw already):
ssam2and the reward: first version of patches to make `morph build` and `morph deploy` work from any checkout of definitions.git (not requiring a workspace and system branch):
Kinnisonssam2: regarding 502 -- are you going to be submitting a new patch based on your discussion with Richard Maw?08:46
Kinnisonssam2: (cp -al)08:46
ssam2I didn't have time to test that, so no08:46
pedroalvarezssam2: I like that reward!"08:55
*** rdale has quit IRC08:58
*** Stanto has quit IRC08:58
*** SotK has quit IRC08:58
*** rdale has joined #baserock09:00
*** Stanto has joined #baserock09:00
*** SotK has joined #baserock09:00
* straycat had forgotten about and will look at it now09:07
*** straycat is now known as reviewcat09:08
*** lachlanmackenzie has joined #baserock09:16
*** Krin has joined #baserock09:24
rdalei've reverted the gcc 5.1 commit and built my system with that, and it is still hanging on startup in syslinux09:24
persiardale: To confirm: using a non-gcc5.1 devel system, you reverted the change, and built a new devel system, and using that, you built your system, and it doesn't work?09:25
rdaleyes, it doesn't work with gcc 4.9.209:26
persiaBut a devel system built with gcc 4.9.2 works?09:27
tiagogomes_rdale reverting gcc 5.1 worked for me09:28
rdalei built a system in an existing image with 5.1 and that works. what doesn't work is building an img file in /src/tmp, copying it out and running it with kvm09:28
pedroalvarezThe variables of this problem are a bit complex. Please, specify the version of gcc of the Host (devel system doing the deployment) and the version of gcc of the system being deployed09:28
rdalehost is gcc 5.1, deployed system is 4.9.209:29
rdaleso maybe i need to downgrade my host?09:29
pedroalvarezI think that is the problem09:29
pedroalvarezthe version of gcc of the host doing the deployments09:29
tiagogomes_yes, my host gcc is 4.9.209:30
pedroalvarez"the problem" - the variable that makes it crash09:30
rdaleright - i need a gcc 4.9.2 host then09:30
pedroalvarezthe problem might be syslinux or btrfs-progs being built with gcc 5.109:32
pedroalvarezBut this is just a guess09:33
ssam2This is where richard maw's idea of doing deployment in a container that is a Baserock system, rather than in the host directly, seems nice09:33
rdaleyes, i think i assumed that was what was going on09:34
persiaCan we reuse the same sandbox environment we use to build the chunks, or would it require yet another container structure?09:34
ssam2I'm not sure. Certainly I'd like Morph to have only one way of doing containers09:38
KinnisonThe protocol for deployment allows for deployment extensions to access the wider world09:38
Kinnisonthe one containment mechanism would need extending to parameterise that kind of thing09:38
persiaKinnison: So no network at build-time, but network at deploy-time?09:39
Kinnisonpersia: indeed09:40
Kinnisonpersia: also deployment protocol allows for the configure/write extensions to have access to host resources09:40
Kinnisonpersia: e.g. filesystems for storing metadata etc09:40
ssam2deployment protocol also allows them to delete the entire host, so i'd be up for limiting it a bit09:40
* Kinnison notes that deploying to self ( needs to remain a viable operation in whatever changed world you come up with09:41
persiaDoes it need be rw, or does ro work?  I wonder if we could do something like bind-mount the current commit of definitions to /definitions in the staging area, to be read-only.09:42
ssam2indeed. Maybe that could be done by allowing the container to contact the host's system-version-manager process (or equivalent) somehow09:42
persiaI thought deploy-to-self was an ssh operation, where the self involved was coincidental, rather than being special in terms of host interaction.09:42
persiaJust allowing network ought handle that.09:42
pedroalvarezpersia: i think you are right09:43
ssam2persia: true, but you can do 'ssh root@localhost rm -Rf /*' right now :)09:43
persiassam2: Yes, but preventing that requires a level of invasiveness that is more than I would prefer.09:44
persiaWhereas a poorly coded write extension could remove one's entire host system even if one was targeting something else, which is a bit more painful.09:45
jonathanmawpedroalvarez: Kinnison has asked me to help with testing your pam changes (since my genivi-demo-platform work relies on pam)09:57
jonathanmawanything I can help with?09:58
pedroalvarezjonathanmaw: see the current status of the patch:
pedroalvarezI've cheked that loginctl shows a session open, but I don't know if this patch will break your current work10:01
*** rdale has quit IRC10:11
*** rdale has joined #baserock10:12
richard_mawI'm working on a `morph diff` command to make it easier to see what changed between branches of definitions10:16
Kinnisonssam2: Who can abandon a patch in gerrit?  Only the author?10:17
ssam2not sure10:18
ssam2I think anyone in Mergers or the author10:18
ssam2or maybe it's Administrators and the author10:18
SotKI think its the latter10:18
ssam2SotK: if you don't see an 'Abandon' button for a patch where you're not the author, then I guess so10:19
* Kinnison wonders what the ettiquette should be on patches which are materially abandoned by their author, but not specifically marked as such10:19
SotKssam2: indeed I do not10:19
richard_mawI wanted to have it work by computing a full build graph, so you could diff two systems and see "in this system chunk foo also depends on bar", but our data model doesn't allow you to parse and graph multiple systems together. The biggest issue is the architecture, but we want to add parameterisation, which would make it even more inappropriate in its current state10:20
Kinnisone.g. -- written and submitted over a month ago, a concern posted 2 weeks ago, still nothing from the author since 2 minutes after the initial submission10:20
ssam2richard_maw: I would love to be able to have systems of multiple architectures in one source pool.. but I imagine it's too much work for now10:21
richard_mawssam2: it's definitely too much work for now, given committments that want a `morph diff` by friday, I'd estimate it'd take a week to pull the source pool code apart and put it back together to allow graphing multiple systems at once10:22
richard_mawssam2: I think I'll have to fall back to parsing on top of the morphology set10:23
persiajjardon: Any thoughts on 133?  Are you planning to get back to it?10:23
persiaKinnison: As reflected by my immediately prior post: I think we ought just poke the submitter to see what they plan.  If someone is absent from the community, we can look at something more complicated, but for folk who are relatively active, it ought be as simple as a reminder.10:26
Kinnisonpersia: I was wondering if perhaps some kind of bot could poke the entries on gerrit directly10:28
*** flatmush has quit IRC10:28
Kinnisonpersia: that way we'd have a central location for the pokings, and perhaps a way to have a robotic policy10:28
persiaI think this should be the central location for the pokings.10:28
persia(where "this" is #baserock@freenode)10:29
KinnisonIRC is ephemeral10:29
KinnisonEphemeral pokings are harder to track10:29 make it less so10:29
persiaAnd I'm not sure I understand the value of tracking pokings.10:29
KinnisonBecause I'd like to see "poked N times after M days of silence -> auto-abandon patch"10:30
jmacsDo we not have an email address for each patch submitter?10:30
Kinnisongerrit's patch list is already becoming unwieldy10:30
persiajmacs: We do.10:30
persiaIf the list is unwieldy, we need to do better at cleaning it.10:30
jmacsThen have a bot send an email after a week/month of inactivity10:30
ssam2Gerrit's patch list is already becoming unwieldy, but I think that's partly because there are several big patch series on there10:30
persiaWhile some of that is reviewing, most of it is being better about actually landing stuff before we submit new stuff.10:31
ssam2there are many patches for both OSTree and Firehose10:31
*** flatmush has joined #baserock10:33
jjardonpersia: maybe, there are other issues with more priority though10:36
*** flatmush has quit IRC10:39
jonathanmawpedroalvarez: can you give use-cases where you can log into a system with the wrong password. I'm having trouble reproducing that problem before using your patch.10:41
pedroalvarezjonathanmaw: oh, no, the actual problem is that you can't use the `su` command10:42
*** flatmush has joined #baserock10:42
jonathanmawpedroalvarez: I'm not sure what the addition of in system-auth is for, then.10:42
pedroalvarezjonathanmaw: so, currently you can't do: `su git -c 'echo foo'`10:44
Kinnisonjonathanmaw: if you do the fix to shadow *without* the addition of *then* you get the login-with-wrong-password issue10:44
Kinnisonjonathanmaw: which you can verify by commenting out the pam_deny lines in your generated system10:44
Kinnisonjonathanmaw: pam.d files use # as a comment marker10:45
pedroalvarezKinnison: now you are here, what is '-' for in a pam.d file?10:45
Kinnisonpedroalvarez: depends where10:46
pedroalvarezat the start10:46
jonathanmawnoted. a worrisome thought occurs though - to properly test that your patch doesn't break the genivi-demo-platform, I'll have to rebuild everything from login upwards, which is an overnight job10:46
pedroalvarezhm... I guess that only adding the pam.d files won't give you the same result10:47
jonathanmawpedroalvarez: yep. I could do a massive hack and re-install shadow, pam, systemd, etc... on top of my system afterwards, but I don't trust the integrity of that.10:48
pedroalvarezwell, no rush, I'd prefer if this is well tested10:48
tiagogomes_what is the purpose of strata/bsp-x86_both-tools.morph10:55
Kinnisonfor chroot systems to be able to deploy disk images, they need the bsp tooling but not a kernel10:55
persiajjardon: Understood.  If you think it's still relevant, let it be.  If you are done with it, abandon it.  If you're just distracted, no worries (but maybe leave a note to that effect on the review).10:57
persiaOn rebuilding being an overnight job: do we have any way of parallelising builds to reduce this cost?10:58
pedroalvarezKinnison: sorry, I got distracted "-session required close"11:00
* Kinnison will have a look in a bit11:03
tiagogomes_btrfs-utils 4.0 didn't solved the boot problem11:12
pedroalvarezit might be the case that upstream hasn't spotted the error, nor fixed it11:14
jjardonssam2: about , you need a fix in the install-files extension make it work (already merged) ( . Should we consider this a change in the definitions format?11:15
tiagogomes_or syslinux could be the culprit11:15
pedroalvareznothing regarding gcc in btrfs-progs/syslinux11:15
pedroalvarezwell, there are things, but nothing obvious11:15
tiagogomes_what's that flag to show the build output11:16
pedroalvarez--verbose I believe11:17
pedroalvarezbut you should have it in you artifacts/ folder11:17
pedroalvarezsomething like /src/cache/artifacts/<cache-key>.build-log11:18
ssam2jjardon: yes11:25
ssam2jjardon: we should perhaps look at moving some configure extensions into definitions.git to avoid this problem...11:26
pedroalvarezoh, Raspberry PI2 for GDP11:28
pedroalvarezI still want to put baserock in a PI11:28
jjardonssam2: ok, should I upgrade the definitions versions and then work on the move?11:28
ratmice__Kinnison: while I do understand the need for a smooth review queue, archival purposes are important, e.g. I recently revisited a ~5 year old patch upon discovering the thing blocking it is part of some ~13 year old deprecated behavior11:39
pedroalvarezmorph.git and definitions.git are too connected...11:39
persiapedroalvarez: +111:41
persiaI believe we've run into the problem of deciding we have two buckets, and trying to put everything in one or the other, so that both are confusing.11:42
persiaRather, I think we would do better to cause morph to only be a tool for building/deploying/analysing definitions, and defintions to only be declarative definitions of systems.11:43
persiaAll the other bits would do better somewhere else, which would make the others less tightly bound.11:43
pedroalvarezare the extensions part of the tools or part of the definitions?11:43
persiaThat's the sort of issue we need to determine.11:44
persiaCurrently the extensions contain both logic and configuration.11:44
persiaAs such, I suspect they ought be scrapped, and replaced with something sane.11:45
pedroalvarezI'm currently thinking that configure extenisons are part of definitions, but my thoughts might be caused by an specific case11:45
persiaI think that the description of how to configure a system belongs in the definitions.11:46
pedroalvarezwe have to think about this, yes11:46
ssam2I  think config extensions should go in definitions11:46
persiaBut I'm not convinced that the logic that processes that description does.11:46
persiaAs such, I think that trying to determine where "configureation extensions" go is the part that makes it hard.11:47
* richard_maw grumbles about MorphologyLoader being unnecessarily object oriented, given it has no __init__ and it only uses self to call other functions11:47
ssam2also, all the configure extensions should be replaced with Ansible scripts :)11:47
persiassam2: Does that require ansible on the target, or can ansible be used to manipulate the target remotely from the host at deploy time?11:48
* persia still has a dream of being able to deploy really tiny systems, including systems that are not running a linux kernel or POSIX userspace11:48
ssam2it'd require SSH on the target11:50
ssam2wait,no it wouldn't11:51
ssam2ansible could do its thing at deploy time and manipulate the system directly in a chroot11:51
ssam2but it probably doesn't actually make sense to force Ansible on everyone11:51
ssam2I need to do a 15.19 release this week11:52
ssam2I've done some draft release notes:
ssam2There are a couple of blockers: syslinux being broken is the main one11:52
ssam2I think since it's Wednesday already, reverting GCC to 4.9 for the release is the sensible option11:52
persiaIf ansible can operate at deploy time, then I'm +1 on forcing ansible on everyone.11:53
ssam2cool :)11:53
persiaThat's an entire other group of people who are working on having YAML to configure systems, which is what we have.11:53
persiaSo if we aren't using their stuff, then we're just playing catch-up (and probably badly)11:53
persiaBut, please, be sure that we have at least one working configured system (e.g. minimal) that doesn't have any ansible runtime support in the deployed system, so relies on ansible to do things at deployment time.11:54
pedroalvarezssam2: the release notes look ok to me12:00
*** mariaderidder has quit IRC12:02
*** zoli__ has quit IRC12:02
richard_mawmy only issue with ansible is wondering how it would interact with read-only /usr deployments12:02
*** zoli__ has joined #baserock12:02
persiassam2: For the release notes: could morph have a tag as the minimum thing to upgrade to in order to use defintions 15.19?12:03
persiaAlso, release notes indicate upgrade to gcc 5.1, but I thought you suggested downgrading again to 4.912:04
persiaFor systemd, it may be useful to indicate between which releases the commit is, so people don't have to hunt.12:05
persiaSame for libxslt12:05
jjardonssam2: I will upgrade the wiki if it gets merged12:06
*** zoli__ has quit IRC12:07
persiaThe headline of the release notes indicates definitions version 2, but the new architectures section indicates definitions version 3.  Are these inconsistent for a reason?  If so, this should be made clear.  If not, they should be consistent.12:07
jjardonpersia: definitions are using format 2, morph support 3 as well12:08
Kinnisonratmice__: Abandoned patches are not, iirc, deleted12:08
persiaI'm not entirely happy about making a release that cannot generate x86 development images.12:09
ratmice__persia: don't think ansible at deploy time would necessarily work in that case you specified (non-linux kernel/userspace)12:09
persiaratmice__: Depends on the target.  For a image target, the image can be unpacked, and managed with the host semantics.  For a remote target, the ansible contents ought be able to handle the right format, so long as ssh works.12:10
persiaThat said, I may not understand ansible.12:10
ratmice__a lot of times, you can generate an image from linux with some juju, without being able to mount it12:10
jjardonssam2: Maybe worth mention the upgrade to mesa 10.5.4?12:10
persiaratmice__: Yes, but the current model involves mounting a filesystem to run the system-integration commands, so we can be fairly confident that we are able to do this.12:11
tiagogomes_I was having a go at updating syslinux but it is not trivial and it would require some changes. Besides it would need to be tested for Ironic, and pxeboot write12:11
jjardontiagogomes_: there is a patch to update syslinux already12:11
jjardonbut I was told it will break pxeboot12:11
tiagogomes_jjardon, there are a lot of things wrong with that patch12:11
ratmice__persia: so if one can avoid system integration commands that should be fine12:12
jjardontiagogomes_: I didnt see any review from you in gerrit12:12
persiaratmice__: Sure: similarly, if one needs to construct an image that cannot be mounted, one could avoid configuration extensions.12:13
tiagogomes_jjardon I left a note that it would break Ironic. I'll augment it12:13
ratmice__anyhow, I'd never really decided on whether actually generating our target images as a deployment was needed, having a known system from which everybody generates them is already an improvement :)12:15
jjardontiagogomes_: go ahead with your approach, I do not think I will have time to work on it this week12:16
persiaratmice__: Hrm?  How can everybody generate target images if one cannot actually generate a target image?12:17
ratmice__persia: ah, our main deployment from baserock is the target image generation system including all of the cross compilers, still using the custom makefiles/host binaries/shell scripts invoking host binaries to generate the target image12:21
persiaratmice__: Ah, so you use Baserock to deploy a known system for others to use to deploy various systems?12:21
persiaNow your comment makes sense: yes, whether to do it that way or single-stage depends on what makes sense for your workflow.12:22
persiaThe BSP/SDK code is for a similar sort of workflow, where one uses Baserock to generate tooling that folk can use to develop software for a target system.12:22
*** zoli__ has joined #baserock12:24
ratmice__yeah, It's kind of weird in our case because of the host binaries, being provided by one deployment then used in the other (complicated by the inability to mount)12:26
persiaHeh, indeed.12:28
ratmice__so, in general that would mean that we have one branch of the definitions which were only usable under the deployment of another branch12:29
persiaRight.  Rather than self-hosting, you'd end up with a set of defintions used to generate the development systems, and an entirely separate set of definitions used to generate target systems.12:30
ssam2thanks for feedback on release notes, will get to it in a bit12:36
ratmice__and FWIW the reason we can't mount it is essentially we build a swap partition, the kernel boots it and starts mapping memory from disk, so doing so means reimplementing the entire kernel in linux12:37
ratmice__s/in linux/in the linux kernel/12:38
persiaOh, nifty12:39
*** nowster has joined #baserock12:43
ratmice__so considering those programs written to the swap can be 3rd party (and including the initial baserock images bootstrapping our deployment) we're at our 4th branch I believe.. :)12:48
ratmice__so yeah, for now at least i've just figured that it adds a whole lot of complexity i'm not going to worry about at the moment12:53
nowsterHi all. I have a ./configure script that tries out the set*uid() calls, which fail under linux-user-chroot12:57
nowsterI notice that linux-user-chroot is not setuid12:57
radiofreepedroalvarez: for genivi specific systemd units should we push them to to avoid cluttering up definitions?12:58
persianowster: Are you running morph as root?  If so, I would think the lack of setuid would not impact that.12:58
nowsteryes I am running as root12:59
* persia doesn't understand why root should have issues calling the set*uid() calls13:00
nowsterbecause linux-user-chroot drops those privs13:00
nowster      if (prctl (PR_SET_NO_NEW_PRIVS, 1) < 0 && errno != EINVAL)13:00
nowster        fatal_errno ("prctl (PR_SET_NO_NEW_PRIVS)");13:00
nowster      else if (prctl (PR_SET_SECUREBITS,13:00
nowster                 SECBIT_NOROOT | SECBIT_NOROOT_LOCKED) < 0)13:00
nowster        fatal_errno ("prctl (SECBIT_NOROOT)");13:00
KinnisonIt's part of the protection l-u-c does13:02
nowsterthe configure script detects it's running non-root and falls back to not actually checking the functions work, but if run as root it will check them13:03
*** edcragg has quit IRC13:07
*** edcragg has joined #baserock13:09
*** mariaderidder has joined #baserock13:09
pedroalvareztiagogomes_: I'm currently thinking that we can copy the probably-culprit-chunk-artifacts to a working system, unpack them and see what happens13:11
pedroalvarezjust an idea, I'm not currently debugging that13:11
ratmice__nowster: maybe upstream would accept a patch to disable the check from a configure option? (not that any of the configure option mechanisms are readily applicable in a clean fashion)13:12
tiagogomes_pedroalvarez we can, but I am not going to do it to mine for obvious reasons :)13:12
nowsterratmice__: it's not even autotools!13:12
pedroalvareztiagogomes_: I can, I guess13:12
tiagogomes_nowster not using autopain is a good sign13:13
nowsterit's samba13:13
nowsterand they're using a new python-y build system called "waf"13:13
tiagogomes_pedroalvarez that would help, as I am not completely sure is a syslinux problem13:14
pedroalvarezI'm assuming that these artifacts are currently in, so that I don't have to build anything13:14
* pedroalvarez will do that13:15
*** reviewcat is now known as straycat13:16
AlbertI'm trying to build a completely fresh Genivi AudioManager within a Baserock VM> I'm getting the error: "Can't find common-api generated headers!". Anyone seen this before?13:25
radiofreethat sounds incredibly genivi specific, did build-depend on whatever common-api is?13:26
AlbertIndeed it is genivi-specific. Sorry should've said.13:27
AlbertSorry radiofree, not sure I understood the question13:28
radiofreei don't know what common-api is, but it sounds like you need headers it generates, did you build depend on common-api?13:29
AlbertI'm doing a fresh AudioManager 6.2, which is necessitating an update to CommonAPI, so I'm building that too. It is on that that I am getting that specific error.13:30
radiofreeso it's commonapi that's complaining about common-api headers?13:31
AlbertI'll paste an output13:32
pedroalvarezOk, new version to fix shadow + PAM:
AlbertNo, I tell a lie: This is AudioManager's build that is failing. I have already built CommonAPI. The output is at BUT I'm going to revisit CommonAPI build to make sure it is built and installed properly.13:35
AlbertIt's always when you discuss it with someone that you notice your own possible errors.13:36
rdalei would fix the syntax error in the cmake file whatever that is13:37
radiofreedoes you audiomanager chunk build-depend on commonapi?13:37
radiofreeif it does, i suggest checking through cmake/CommonAPIGenerator.cmake to see what it's trying to do/find13:37
AlbertBTW those log files haven't been particularly enlightening.13:37
straycatrichard_maw, 290483010cfc7945cd4483fadd1d98c3b83efb3 seems to have broken morph checkout :/13:38
richard_mawstraycat: taking a look now13:40
persiaIs that not a positive thing?13:40
AlbertIt chunk builds yes. But I'm bringing it up to date to meet dependency requirements up to date. Sadly the released version of AudioManager had some build-killing errors that I've already fixed (!)13:40
richard_mawstraycat: how is it broken? doesn't work as it should, or crashes when attempted?13:41
straycatrichard_maw, the push url is the same as the fetch url13:41
richard_mawhm, test suite will have missed that distinction because it has no difference in its configuration13:43
Albertrdale, Missed that. There have been several of those but it is to do with versioning of cmake. It should have allowed that with just a warning.13:43
radiofreehow do you see the log for a failed systemd service?13:44
radiofreejournalctrl _PID=foo gives me nothing13:44
bashrcsystemctl status <servicename>13:44
radiofreethat doesn't give me any useful logging other than it failed13:44
richard_mawjournalctl -u $unit_name13:46
ssam2journalctl --unit=xx sometimes works13:46
ssam2persia: we have users who are used to the `morph checkout` workflow, we shouldn't break it for them13:46
persiaAt least not without warning.  I very much hope we will eventually break it for them, but I can accept not doing so unintentionally.13:47
ssam2about having a tag of Morph as 'the minimum thing to upgrade to in order to use definitions 15.19': what if we tagged morph.git with each version of definitions.git that it understood ?13:48
ssam2so morph 'baserock-definitions-v2' would be needed to build 15.1913:49
straycatwould be good to have all of this workflow along with the structure of definitions defined somewhere so we can refer to that13:49
ratmice__nowster: they do seem to have amassed quite a bit of logic in their build/configure stuff it would appear :/13:49
richard_mawstraycat: I'm still spinning up on this failure, it sounds like the issue is that checking whether the in-memory version is None is a completely inappropriate way to test whether it is set on-disk13:49
richard_mawstraycat: and it's set on-disk at clone time13:50
richard_mawstraycat: can you try putting ` is None and` before the check for the in-memory fetch_url and push_url are compared to None13:52
AlbertYeah, I got rid of that error report but it doesn't fix it.13:53
persiassam2: I'm fine with tagging morph with things like "comprehends-definitions-v2", "comprehends-definitions-v3", etc. (or some more concise representation), so long as the nature of the representation also allows "no-longer-comprehends-defintions-v2", etc.13:54
ssam2that seems a bit too hard to represent in a `git tag`, then13:55
straycatrichard_maw, sure, though i'd assumed you'd reproduced this yourself?13:56
richard_mawstraycat: sorry, I haven't yet, task switching is currently expensive, so I was deferring until I could easily switch and test13:58
persiassam2: It's a matter of semantics: perhaps "definitions-v2-supported" and "definitions-v2-unsupported"?  Even "defv2" and "nodefv2"?14:02
straycatrichard_maw, yes that seems to fix it14:03
persiaThe other sensible option is to semantically version morph, and constrain these sorts of changes to specific release windows (but that probably makes everyone using use-latest-morph cry)14:03
richard_mawstraycat: cool, thanks for trying it, I've only just got as far as reproducing the fault14:03
paulsherwoodssam2: i can't help feeling we're making this harder than it needs to be.14:04
ssam2persia: why is it useful to be able to check out a version of Morph that can't build a certain version of definitions?14:04
paulsherwood(the versioning thing)14:04
ssam2me too, I would love for someone to come up with a good way to do it that doesn't break things for people who are trying to upgrade their systems later on14:04
persiassam2: Rather, it is useful to be able to look at annotated history, and check out the last version that *could* read a certain version.14:04
paulsherwood(and the deploy extensions thing etc)14:04
persiaSo tag-114:04
paulsherwoodssam2: would you still love it if the way didn't involve morph, at all? :)14:05
ssam2even more so14:05
* persia would probably do that with `git checkout tag-that-cannot-build-something && git checkout HEAD-1`14:05
richard_mawstraycat: I can confirm the fix, do you want to submit it or should I?14:05
* richard_maw runs test suite14:06
straycatrichard_maw, feel free :)14:06
*** edcragg has quit IRC14:15
*** edcragg has joined #baserock14:17
*** straycat is now known as reviewcat14:42
radiofreeswitching vt's in baserock seems a bit broken14:45
radiofreeseems to hang on "Starting Getty on ttyx"14:45
reviewcati don't fully understand the fix either, just that we can't use that comparison for named repos?14:46
pedroalvarezKinnison: sorry but I don't understand your comment here:
pedroalvarez"systemd adds a number of files"14:49
Kinnisonsystemd's pam.d stuff, is it *only* system-auth or is there more?14:49
pedroalvarezKinnison: there are 2 more, but they have "session  include system-auth" at the bottom14:50
Kinnisondo they have any auth lines?14:51
Kinnison'session include ...' will only do includes for session, not for auth :)14:51
richard_mawreviewcat: if it's a named remote, there's sufficient config on-disk and the url fetch off disk logic is smart enough to give you the other url as a default14:51
richard_mawreviewcat: the issue is that we need to do this logic ourselves for unnamed remotes14:51
richard_mawreviewcat: and there was a bug in whether we needed to do it for named remotes, and they interacted badlty14:52
pedroalvarezKinnison: grr... then the 'systemd-user; file doesn't have that:
*** reviewcat is now known as straycat14:53
Kinnisonsystemd-user doesn't have any auth14:54
Kinnisonso that's fine14:54
Kinnisonit probably doesn't do auth since user sessions are, in theory, pre-authenticated14:54
pedroalvarezKinnison: oh, do you see that '-' prefixes?14:54
KinnisonI think that causes "if not present, silently ignore"14:55
Kinnisonrather than raising warnings that the file isn't there14:55
pedroalvarezeven if it's optional14:55
Kinnisonoptional will still raise a logged warning if the entry can't be found14:55
pedroalvarezrichard_maw suggested me to add that prefix to the pam_selinux requirement14:55
pedroalvarezgood to know14:56
Kinnisonpedroalvarez: I am not the oracle of all PAM knowledge though14:56
Kinnisonpedroalvarez: so don't trust me, do research14:57
pedroalvarezinvestigating now14:57
pedroalvarezI couldn't find useful information about this14:57
* Kinnison fears PAM's source may be the best information14:57
* Kinnison also fears PAM's source14:57
pedroalvarezKinnison: thankf for your help14:58
pedroalvarezthanks even14:58
*** tiagogomes_ has quit IRC15:00
* richard_maw found an oblique reference to the - prefix of lines in pam config in an old website after having seen it used once15:03
richard_mawI failed to find any official documentation or the example15:03
pedroalvarezit doesn't make any difference15:04
Kinnison                if (tok[0] == '-') { /* do not log module load errors */15:08
Kinnison                    handler_type = PAM_HT_SILENT_MODULE;15:08
Kinnison                    ++tok;15:08
Kinnison                }15:08
Kinnisonfrom pam_handlers.c15:08
ratmice__seems to be documented in pam.conf(5)15:08
Kinnisonso it is15:10
* Kinnison failed to find that on his last read-through15:10
* richard_maw failed to find it on 5 read-throughs15:10
richard_mawdoes that stop it counting module load failure as an error though?15:11
richard_maws/an error/reason to refuse or gain entry independently of the result of running the module/15:11
Kinnison            if (handler_type != PAM_HT_SILENT_MODULE)15:12
Kinnison                pam_syslog(pamh, LOG_ERR, "adding faulty module: %s", mod_path);15:12
Kinnison            success = PAM_SUCCESS;  /* We have successfully added a module */15:12
KinnisonBased on that, I think missing modules are somehow ignored?15:12
Kinnisonpam's code confuses me15:13
richard_mawit looks to me like it just doesn't log the result, it still appears to interpret failure to load as identical to the module failing to authenticate15:13
richard_mawthough it's still plausible that it couts a missing module as a success independently of whether a - is listed15:14
straycatif there's no comments on i will merge it15:15
* richard_maw is annoyed that he has spent all day puzzling through how best to load all the definitions in a repository for inspection without duplicating the loading logic, but has gained an understanding where the flaw is in the model that prevents us graphing multiple systems at once15:17
richard_mawSources are the point of conflation between the logical structure of the input, and the working data structure of what will be produced15:18
richard_mawit's only once Sources are passed to the artifact graphing code that they become invalid for analysing the logical structure of the input15:18
ssam2could a couple of people review (revert GCC to 4.9.2) please?15:30
ssam2I'd like to get it merged today so the Masons can do the rebuild overnight15:31
straycati seem to be running into all the broken things today15:34
richard_mawssam2: not being one of the people who reviewed the update to 5.1 I'm not sure how much use I'd be, but I'll take a look15:39
radiofreessam2: is that actually the case? i believe richard_maw reverted that and it still didn't work?15:42
radiofreeor maybe i missed the rest of the conversation15:42
richard_mawradiofree: I believe you meant someone else15:42
radiofreerdale: :)15:43
rdalei reverted by my host environment, and the deployed system to 4.9.2 and all is well again15:46
*** sherm_ has quit IRC15:46
radiofreegodspeed gcc 5.1 then15:47
*** 16WAAW5JF has joined #baserock15:48
rdalei've given 584 a +115:49
rjekInteresting nick, tiago.15:49
* richard_maw grumbles that zookeeper-clients had a broken morphology path to strata/test-tools.morph (was missing the .morph)15:56
*** 16WAAW5JF is now known as tiagogomes15:56
richard_mawKrin: ^15:56
straycatbetter not mention that zookeeper still contains 'github' in the repo field then >.>15:59
Krinthey did? i did a lot of testing on them before committing anything... do you need me to solve anything? or are you grumbling that i hadnt solved it?15:59
Krinrichard_maw, ^16:01
richard_mawKrin: look at systems/zookeeper-client-x86_64.morph16:02
richard_mawparticularly the test-tools entry in the strata list16:02
richard_mawit's missing the .morph off the end of the "morph" path16:02
pedroalvarezrichard_maw: does it fail to build? or just silently ignores it?16:03
richard_mawfails to create the source pool16:04
*** a1exhughe5 has quit IRC16:05
Krinhuh. it silently ignored it previously, i'd built that from fresh 5 times before committing it. as it was the first thing i'd done with baserock. i'll take a look and see what is going on while this other thing download (it's taking a while anyway)16:06
straycatcan you also fix it so that we're not downloading the chunk from github while you're there16:07
*** jonathanmaw has quit IRC16:07
Krini'll look at that straycat. but i seem to be seeing an entirely different version of the file to everyone else... the version i see does not have a test-tools entry.16:17
Krin*pulls again and now it IS there* huh...16:18
pedroalvarezoh, the test-tools change has been a recent addition16:18
persiaKrin: Which branch and which commit?16:18
persiaKrin: compare
pedroalvarezthe bug is here:
persiaKrin: And
pedroalvarezs/is/is being introduced/16:19
* Krin 's poor little brain explodes16:22
*** zoli__ has quit IRC16:24
Krinwell the test tools thing should not have been added. that was a mock program that was optional. and instructions for adding it are in the documentation, but it should not be there by default. and i'll try and work out how to make it go away from the default download16:26
Krin(the overall system)16:27
*** ssam2 has quit IRC16:39
*** mariaderidder has quit IRC16:51
pdarWhen deploying multiple images with a cluster morphology, is there a way to define common fields for each of the images you want to deploy. In the attatched cluster morphology I have a whole bunch of repeated lines and I wondered if it was possible to avoid this.
persiaI believe inheritance was discussed previously, but I don't believe it was implemented.  I may be wrong (and would be delighted in this case)16:52
* pdar crosses fingers for inheritance16:54
richard_mawpdar: there's two ways16:58
richard_maw1. there's a deploy-defaults field that can be used to set them for the whole file16:58
richard_maw2. you can use the yaml anchors, refs and merge keys syntax16:58
richard_mawpdar: the twonode and threenode definitions show the second way16:58
persiaOh right, (2) was the big argument against implementing inheritance: YAML already has it.16:59
pdarrichard_maw: cool, thanks! I'll check them out and see what I can c ome up with17:00
*** bashrc has quit IRC17:01
richard_mawpdar: see
richard_mawpersia: there was some form of inheritance we wanted, but it had to cross file boundaries so yaml inheritance wouldn't've been appropriate17:04
persiaFor clusters?  I thought that was for contents.17:04
richard_mawpersia: there's previously been arguments against using yaml inheritance because its syntax is arcane, and we should have a mechanism for inheritance at the structural level, rather than syntactic17:04
richard_mawI don't recall any discussions about inheritance for clusters17:05
richard_mawapart from when I first suggested using yaml inheritance in clusters17:05
persiaMy memory was that we had some discussion about deployment variable inheritance around when we were knocking the sharp edges off `morph upgrade`, maybe 10-15 months ago.17:06
persiaBut as I said, I may be mistaken (especially given the span of time)17:07
Zarasmartest thing I've done today: told a stratum to build-depend on itself. Morph was willing to spend an indefinite amount of time 'deciding on task order'...17:11
pedroalvarezZara: didn't it fail at some point?17:11
pedroalvarez"level recursion exceeded" or something like that?17:11
Zarapedroalvarez: maybe it would have done; I did leave it while I got a cup of tea, so probably >5 minutes, but not hours17:11
ZaraI thought there was probably something odd going on so ^C'd out of there17:12
*** CTtpollard has quit IRC17:13
pdarrichard_maw: Awesome! Thanks for the paste!17:16
*** tiagogomes has quit IRC17:18
*** zoli__ has joined #baserock17:25
*** gary_perkins has quit IRC17:30
*** zoli__ has quit IRC17:30
* SotK is surprised it went for 5 minutes before hitting the maximum recursion depth17:48
pedroalvarezYeah, me too17:55
*** rdale has quit IRC18:08
*** lachlanmackenzie has quit IRC18:23
*** zoli__ has joined #baserock18:42
*** cyndis has quit IRC18:43
*** Krin has quit IRC18:47
*** Stanto has quit IRC18:47
*** SotK has quit IRC18:48
*** inara has quit IRC18:48
*** inara has joined #baserock18:49
*** Krin has joined #baserock18:49
*** Stanto has joined #baserock18:49
*** SotK has joined #baserock18:49
*** inara` has joined #baserock18:49
*** cyndis has joined #baserock19:10
paulsherwoodis it just me, or does install-essential-files not work for deploy --upgrade ?19:13
paulsherwoodi haven't used cycle-sh for a while, but i am sure it used to work.19:14
*** cyndis has quit IRC19:18
*** cyndis has joined #baserock19:19
SotKpedroalvarez: aha, its just stuck in an infinite loop when creating the source pool19:48
*** sambishop has quit IRC20:31
SotKZara, pedroalvarez: should fix that indefinite hang20:48
persiaOh, heh21:26
*** bjdooks has quit IRC22:07
*** bjdooks has joined #baserock22:07
*** petefoth has quit IRC22:29
*** Albert has quit IRC22:43
pedroalvarezGreat SotK! I'll review that tomorrow22:50
pedroalvarezpaulsherwood: I believe you need a newer morph22:50
KinnisonI'm sure straycat submitted a patch which fixed the infinite-recursion issue months ago22:54
pedroalvarezI guess that we forgot about old patches in the ML when we moved to Gerrit22:59
Kinnisononly a month ago23:05
*** zoli__ has quit IRC23:28

Generated by 2.14.0 by Marius Gedminas - find it at!