[Slackbuilds-users] what is the preferred build and test environment
chris.willing at iinet.net.au
Fri Sep 9 00:30:58 UTC 2016
On 09/09/16 09:37, King Beowulf wrote:
> On 09/08/2016 02:00 PM, Tim Dickson wrote:
>> Hi everyone, I use sbopkg for building packages, but for my own
>> slackbuilds I need to test them on both 32bit and 64bit slackware.
>> Ideally, they would be clean installs, with just the dependencies
>> required for the build to be tested. I would like to do this with
>> minimum of fuss, and wondered what you guys (and gals) did ??
>> Up till now, I have used 2 separate test machines, or one machine with
>> two slackware installations on different partitions, but I haven't
>> managed a clean starting state for each slackbuild. I have somewhat
>> limited internet data allowance, so don't want to re-download the sbo
>> tree for every slackbuild when building dependencies. I made limited use
>> of qemu on windows to run some slackware vm's a while ago, but prefer
>> solely using linux for testing.
>> any simple examples or a howto or wiki would be appreciated, and
>> probably useful to all slackbuild creators.
>> Thanks, Tim
>> PS. some builds are for graphical programs that use opengl, I don't know
>> if that affects the choice of environment or not.
> I use qemu (since I am the maintainer!) to create clean Slackware
> environments. I set up a file share for both onto a SBo git clone on
> the host (which actually point to a NFS on a separate server..). I
> create a base image, then a work-in-progress copy-on-write image.
> I create a script with a zenity "GUI" to maintain the BASE and WIP
> images with all command line option. If you are interested you can look
> at the scripts here (item #6):
I have an almost identical setup to Ed (just no gui) and find it to be
an extremely efficient way to do builds & testing. I used Virtual Box
for a while but have found it much easier (for me) to juggle BASE/WIP
status with Qemu. When my script runs to do a build, it uses the hoorex
tool to calculate an ordered list of any other required packages and (as
well as installing in the VM) dumps resulting package(s) back into the
"real" file system for installation there when/if needed.
In the qemu environment, graphical programs will use mesa which is fine
for general testing but, of course, won't be as fast as with hw
accelerated setup. However an app built with mesa in a VM will still use
whatever hw acceleration is available at run time. An example of this is
NVENC support which can be included in ffmpeg by supplying the necessary
API file at build time but won't be available at run time unless
appropriate nvidia card and binary driver are installed i.e. works on
real machine but not when testing in the VM.
More information about the SlackBuilds-users