Excellent. I ran a diff between the two versions and confirmed that the only change was to remove the unnecessary dependencies and add webmin-postfix.

diff a/foswiki/conf b/foswiki/conf
index e623b77..8ea401d 100755
--- a/foswiki/conf
+++ b/foswiki/conf
@@ -15,7 +15,7 @@ apt-get update
 DEBIAN_FRONTEND=noninteractive apt-get -y \
     -o DPkg::Options::=--force-confdef \
     -o DPkg::Options::=--force-confold \
-       install apache2 libapache2-mod-php5 php5-common webmin-phpini gnupg post
+       install apache2 gnupg postfix webmin-postfix


 echo "deb http://fosiki.com/Foswiki_debian/ stable main contrib" >>  /etc/apt/s

Actually we don't use tklpatches much these days either. We've moved on to TKLDev. And patches that never got ported to TKLDev haven't been maintained unfortunately.

Having said that, we do still have the Twiki appliance. Twiki appears to be abandonware now, so I'd really love to see a current Foswiki appliance developed for our next release to replace it with.

If you haven't played with it before, TKLDev buildcode is very similar to the old TKLPatch format. So if you are keen to have a stab at a Foswiki appliance, I for one would be super happy! :)

From my brief reading, Foswiki was a fork of Twiki, so you may even find the Twiki buildcode is a reasonable starting place for a Foswiki appliance?!

If you are keen to have a go, I suggest that you start a new forum thread to keep us up to date on how you are going. If you have questions, you can post there and I'll reply ASAP (I try to check in daily, but at least a few times per week).

You'll probably also want to have a browse through the TKLDev docs.

We're way behind the eightball WRT to the next release. We're only just starting to ramp up development on it. So hopefully things will start moving a bit quicker with that. However, we're still a little while away from producing a public v15.0 beta/rc (once it's mostly working, we'll release it; how close to a finished product it is will determine what we label it). And that will likely be just core to start with.

I would anticipate that we'll be working through the appliances over the next 6 months +/-. We intend to release them in batches as they're ready (as we did for v14.2). So there's no rush. We really appreciate anything you could do to help out although I must say, a Foswiki appliance would be a particularly awesome contribution.

Currently, to build an LXC container, you need to first build an ISO. We use buildtasks to do that and you should find it already cloned to /turnkey/buildtasks (we added it by default in TKLDev v14.2). Buildtasks is essentially just a collection of bash scripts (FWIW, it also leverages TKLPatch; so it's not like we don't still use it).

Buildtasks was built and designed with our internal use in mind, but it can still be useful to end users (hence why we made it public). Because we need to ensure that the appliances are consistent across buildtypes, we always build the ISOs first, then the other builds later.

So TBH, it's not really ideal for development. Personally, I usually do early development within the chroot(s). I.e. build/root.build (chroot with initial debian package install), build/root.patched (overlays and conf scripts applied) and build/root.sandbox (last minute adjustments to the code; gets added to an already built ISO.

Then once I get to a point where it's mostly working (at least installing the desired software and has the basics of it working), I'll build an ISO and install to a VM for more testing and development. The only thing that I'd highlight if you follow my workflow; is remembering to copy any tweaked code, back to your TKLDev. It hasn't happened for a while now, but I recall inadvertantly losing work a couple of times because I forgot to copy stuff from the test VM back to TKLDev.

So currently, if you wish to build "straight" to LXC, you'd need to do something like this:

cd buildtasks
./bt-iso new_app
./bt-container new_app-14.2-jessie-amd64

Note that bt-iso only needs the appliance name. It maps that to /turnkey/fab/products/app_name. The version is pulled from the changelog, the arch comes from the host system and the Debian version from the host system or an environment variable.

bt-container requires this info to be explicitly set. It will look for the relevant ISO in /mnt/isos and if it can't find it will try to download it from the TurnKey mirror.

If you run those commands, you will find an ISO in /mnt/isos/ and a LXC container in /mnt/builds/container/. On face value that all seems fine. However, when you build the ISO (i.e. bt-iso) it builds the ISO from scratch (i.e. runs make clean && make in your app directory). It then needs to unpack the ISO and build the container. So it's quite an extended process.

Even though installing the ISO is a bit of a PITA; because adjusting an ISO (via root.sandbox) is so quick (to rebuild the ISO); what you lose on ISO install, you gain back in not needing to rebuild the ISO (and then the container) from scratch.

If you are particularly keen to use LXC for early testing and development, then perhaps writing a new bt script for that purpose may be worth considering? Or if you're a more patient man than me, you could just do ./bt-iso new_app && ./bt-container new_app-14.2-jessie-amd64 and wait...

Looking forward to hearing how you go. If you have any questions or suggestions on how we can improve the TKLDev docs, I'd really love to hear. Good luck! :)

Here is fine for starters. But once you get going, GitHub is probably a better place for development feedback. If you push your buildcode to a repo there, you can use the "issues" of that to ask questions or get clarification. I can point you to code examples from existing appliances and give you explicit suggestions and feedback.

To get my attention on GitHub, please just tag me in a comment (I'm @jedmeister). I should generally respond within a work day or 2.

Hopefully, you should be able to answer many of your own questions via google as I try to keep development discussions public. If not, that's fine, but if we keep all our discussions public, then we can keep building the available resources for new developers such as yourself!

If you don't get a timely response, please feel free to bump your thread (here &/or GH) and/or ping me via email (jeremy AT turnkeylinux.org). Please ensure that you include a link so I can publicly respond to your question.

As a heads up; even though we've started development on v15.0, it's going much slower than I'd hoped. Until we have a public beta/rc based on Debian Stretch, it will be easier to develop on Jessie (i.e. v14.2). The downside, is that it may need some minor tweaks for v15.0, but we don't currently have much choice.

Also, to ensure that your expectations of us aren't too high; we probably won't be in a position to publish any new appliances until we have at least released the first batch of v15.0 appliances. In reality that probably means we're months away from being able to publish anything you create.