Hi Paul, On 29 November 2013 07:11:45 Paul Sherwood <paul.sherwood(a)codethink.co.uk&gt; wrote: I would say a couple of things to this. 1) it seems to still be a bug, even if its not currently exhibited on a current baserock systems 2)I think there's a value in being able to develop morph on non baserock environments. Especially as I find current baserock develop systems a little unpleasant to use as a development environment (in particular, missing man pages and some odd behaviour from vim) Thanks Rob

On Fri, Nov 29, 2013 at 08:38:18AM +0000, Paul Sherwood wrote: It's not an insurmountable proposition. Morph is runnable on any Linux system that has python 2.7 and a few python libraries, though we'd probably end up having to package those ourselves if we need new enough versions of cliapp for example. morph can build on any system with a recent enough kernel that it supports linux-user-chroot and has git available. You can even get away without having gcc on the system if you don't need to touch build-essential. Most of the extra dependencies we add to our Baserock systems are to support deployment, but we could theoretically build those dependencies as well and deploy from a chroot. The biggest issue I see with using morph on your host system is that we currently require building as root. This is ok on an isolated development VM, but morph is complicated and most people probably wouldn't feel safe running it with sudo. Deploying without root will be significantly more difficult, since creating disk images is a priviliged operation, but those individual commands could be run with sudo, and there are tools for creating disk images without mounting, but they tend to be more primitive than we need them to be. I see using Baserock as the development systems as an important Dogfooding exercise, and as soon as we have some engineering time for it, I'd like to see us running Baserock on bare-metal with all the nice things expected of a Linux distro. However, if we're going to give up Baserock as a Linux distro, then I think it would make sense to put effort into getting morph working on other distros, since people deploying to devices will already have their own deployment scripts, which may require distro specific tools. tl;dr: it's not a massive amount of work to build on other distros, but we don't have the engineering to do that and have our own distro.

On Fri, Nov 29, 2013 at 11:46:19AM +0000, Paul Sherwood wrote: I'm happy for you to say it's the wrong direction, but I disagree that we'd lose traceability, since we get traceability from knowing which version of morph we're using and the staging area's isolated builds. The only traceability we'd lose is knowing which tools are used in deployment, and we don't keep that information in the deployed system currently anyway. Agreed, unlike other distros Baserock is reproducible and has its focus on embedded systems development and deployment, though I'd like us being easily able for developers to build their own variant systems based off Baserock releases to add things like mutt. Amen to that :-)

On Fri, Nov 29, 2013 at 12:17:23PM +0000, Paul Sherwood wrote: Ah, so instead of the output of a successful build being reproducible, you're concerned with reprocucibly being able to _start_ a build. Arguably in that case it's a question of packaging for each distro, but we don't need that noise. I'm happy continuing to ship disk images in that case, though it may be more convenient for us to provide install scripts, .ova VM packages or maybe even docker containers.

On Thu, Nov 28, 2013 at 11:05:20PM +0000, Rob Taylor wrote: I'm not sure of the cause of this bug, but I'd say it's a bug if the test suite depends on the user's environment, be it locale, time zone, local time, git configuration, or anything else. Tests should be run in a clean environment, at least by default. -- http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/