VM dedicated to compiling Deviation

for my own needs, I just want to be able to build for target hardware 7e, using linux.

if discrete installs of tools on baremetal is the better way, I'll happily do that. I'd prefer to do that

but VM's make debugging more sane, right? its easier to snapshot a whole VM, upload it and have people look at it (and even restart it when needed) than to remotely tshoot local installs.

anyway, if there is a list of versions I should have, I'll try to fetch those precise ones out and do local installs. I did not check any readme's yet, so I'll go there first.

no desire to build anything on windows or for windows not sure about emulators - have not read about those yet. I'm happy if I can build reliable images for my 7e and I'm planning on buying a 2nd 7e just as my test bed (want the main 7e as my daily driver, lol).

so, let me know the right way to go forward. if someone is going to put effort into updating a VM, I'll be a test subject for you. if not, I'll do the baremetal discrete tool install and see if I can get to a stable baselevel (and freeze it).

so far, the devices (models) I have are: syma x5, hubsan x4, cheerson cx10, jjrc h8 mini, jjrc h20, and maybe something else I'm forgetting (or soon to buy) all of these fly really well with the 7e and I'd like to be able to have a stable tree that has support for all of those families, and that I can try to hack on and play around with.

thx

Ok, got it. On my 64-bit linux docker image, I need to install the multiarch-support and libc6-i386 packages, and then the launchpad binaries run fine. Probably an issue with docker images being stripped-down linux installs, so they didn't include that. If all you want to do is build a 7E DFU, that's the only really critical part.

Here's the apt-get I use for the simple deviation image:
binutils \
dpkg-dev \
libc6-i386 \
gettext \
make \
mercurial \
mingw32 \
mingw32-binutils \
mingw32-runtime \
multiarch-support \
python-dev \
software-properties-common

BTW, I was wrong earlier - this includes the tools for building the windows emulators, but not local ones. The dividing line was whether or not you needed a tool chain for the local machine. If you're not interested in the windows emulator, you can leave off the mingw*. IIRC, the only other thing added for building the emulator was the dpkg-dev package.

most of that looks like standard installed stuff, anyway. I'm pretty sure I won't need mingw32* since my target won't be windows and I won't build on windows.

now, if I need to avoid certain versions of those tools, that's when a frozen 'do not update' VM would make sense. I'd fetch the magic versions, do the install and consider that a dedicated build system that never gets updates unless there's a reason for it.

but if I can always use 'current' for those tools, that means I can use my everyday workstation (3.19 kernel, some version of MINT that is recent enough) and just layer what I need on that, directly.

sounds like the ARM tools should be installed and then locked down, since those are the critical ones.

when I get my 2nd 7e, I'll be brave enough to do a local build and local flash. not on my daily driver until I have been thru this a few times


edit: only thing my main linux box didn't have, from that list, was mercurial. and I don't have ARM installed, yet, either.