[Slackbuilds-users] what is the preferred build and test environment

[Christoph Willing]

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):
> http://www.linuxgalaxy.org/
>

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.

chris