Thanks for the tips. I had actually already figured out from the source code that I needed to build the ISO first. I'll keep in mind that it needs a git repo for custom appliances.
I did figure out that I can re-name the ISO and as long as I keep the same basic name and pass my custom name, e.g. openldap-struebel as the appliance that the bt-container script will work quite happily with it. It works quite well to create containers of patched appliances which I generate as described below.
To generate a patched ISO, I hacked together a script based on the bt-iso script which will apply a tklpatch to the root.sandbox before generating the ISO. I'm currently using that with my tklpatches to customize the base appliances. If you'd like I can publish it for possible inclusion into the official buildtasks. It does require a patch to the tklpatch-extract-iso script to unsquash the root.sandbox over the product.rootfs if it exists in the ISO. Should I fork the tklpatch repo and submit a pull request with that patch?
Most of my patches are published on my GitHub account, although I don't think I've put my master patches up. There are a couple where I configure specific users that I don't want to publish publicly. The main reason for using the patch system is for maintainablilty since some of the patches I use for multiple appliances. I was thinking that to include it into the tkldev system it would be nice to allow a user common similar to the official common that could hold user-custom makefiles, overlays, scripts, etc. Possibly, I could just fork the turnkey common and create a separate branch, I'm just not super comfortable with the advanced usage of git, especially from the command line since I'm primarily a Windows user with TortoiseHg. What are your thoughts on supporting a user common vs just having us fork the turnkey common?
Thanks for the tips
Thanks for the tips. I had actually already figured out from the source code that I needed to build the ISO first. I'll keep in mind that it needs a git repo for custom appliances.
I did figure out that I can re-name the ISO and as long as I keep the same basic name and pass my custom name, e.g. openldap-struebel as the appliance that the bt-container script will work quite happily with it. It works quite well to create containers of patched appliances which I generate as described below.
To generate a patched ISO, I hacked together a script based on the bt-iso script which will apply a tklpatch to the root.sandbox before generating the ISO. I'm currently using that with my tklpatches to customize the base appliances. If you'd like I can publish it for possible inclusion into the official buildtasks. It does require a patch to the tklpatch-extract-iso script to unsquash the root.sandbox over the product.rootfs if it exists in the ISO. Should I fork the tklpatch repo and submit a pull request with that patch?
Most of my patches are published on my GitHub account, although I don't think I've put my master patches up. There are a couple where I configure specific users that I don't want to publish publicly. The main reason for using the patch system is for maintainablilty since some of the patches I use for multiple appliances. I was thinking that to include it into the tkldev system it would be nice to allow a user common similar to the official common that could hold user-custom makefiles, overlays, scripts, etc. Possibly, I could just fork the turnkey common and create a separate branch, I'm just not super comfortable with the advanced usage of git, especially from the command line since I'm primarily a Windows user with TortoiseHg. What are your thoughts on supporting a user common vs just having us fork the turnkey common?