LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Building packages in VirtualBox guest (https://www.linuxquestions.org/questions/slackware-14/building-packages-in-virtualbox-guest-4175463732/)

kikinovak 05-28-2013 04:23 AM

Building packages in VirtualBox guest
 
Hi,

I'm currently considering the purchase of a more powerful workstation, in replacement of my old Dell Optiplex "Buildbox". Up until now, I've been building all extra Slackware packages (about 200, from a52dec to xvidcore) on this dedicated box. It's configured as a multiboot, with Slackware-13.37 and Slackware-14.0 installed both in 32-bit and 64-bit variants. I put the resulting binary packages on a USB disk and on a pair of CD-Rom, to redistribute them on other machines.

Now I'm considering doing all this on a series of virtual guests on a workstation PC with the necessary resources. I'm wondering though if packages built inside VirtualBox (with the VirtualBox graphic driver installed) a) will build and b) can be reused on other machines. I'm thinking about stuff like wxGTK or Firefox ESR, who refuse to build under some conditions, for example when the NVidia proprietary driver is installed. I vaguely wonder if something similar can happen with the vbox drivers. I'd rather ask before, since this will decide whether I'm doing a multiboot on this machine or not.

Cheers,

Niki

ReaperX7 05-28-2013 09:03 PM

As long as none of them are kernel dependencies or machine specific in compile options, then you should be okay.

ruario 05-29-2013 02:02 AM

If the virtual machines are only for building you could avoid installing anything non official prior to building your packages, i.e. don't even bother installing the guest additions on them. The guest additions provide some niceties (like X drivers to make the window resize on the fly) but are not 'needed' for a build machine. If you install nothing extra you can be sure your VMs are vanilla.

One nice thing with Virtual Machines like VirtualBox is the snapshot capabilities. After first install of Slackware take a snapshot while it is in a clean state. Then you can build one or more packages and roll back to this clean state.

P.S. To transfer your built packages over to the host (when you don't have additions installed in the guest) just use scp or sftp.

kikinovak 05-29-2013 02:18 AM

Quote:

Originally Posted by ruario (Post 4961117)
If the virtual machines are only for building you could avoid installing anything non official prior to building your packages, i.e. don't even bother installing the guest additions on them. The guest additions provide some niceties (like X drivers to make the window resize on the fly) but are not 'needed' for a build machine. If you install nothing extra you can be sure your VMs are vanilla.

I guess that's exactly my concern. Will my packages be built correctly (that is, usable on other machines) if built in a virtual environment with guest additions installed? There are some basic features like correct X display configuration and use of shared folders between host and guest that I'm very used to, and I simply don't want a machine that only works like a chicken flies or a horse swims.

ruario 05-29-2013 02:30 AM

I'll step out of the discussion then as I don't actually know would have to test (same as you) to be sure. Personally I would just skip the guest additions to be 100% sure. I really don't think you need them, but I take your point about convenience.

I'll leave someone else to answer in that case, who is already certain that the guest additions are ok.

solarfields 05-29-2013 03:03 AM

Quote:

Will my packages be built correctly (that is, usable on other machines) if built in a virtual environment with guest additions installed?
May be someone from the SBo admins team can tell how they check the submitted SlackBuilds?

ruario 05-29-2013 04:15 AM

You could always take a couple of the packages you are unsure about (e.g. you highlighted wxGTK and Firefox ESR) and build them twice. Once without guest additions and once with. Pay attention to any differences during build and then run ldd on the binaries at the end and diff the difference, finally give them a quick run in a different vanilla environment. Sure it is time consuming but it is not like you will be doing it all the time. Just now so you can satisfy yourself that they are the same.

To be honest I would probably do this no matter what anyone else told me if I wanted to be certain.

By the way are you tweaking the build options for Firefox ESR? If not why not just repackage the binaries that Mozilla provide? Much quicker and the result for them will obviously be the same then as you haven't actually built them.

ppr:kut 05-29-2013 04:31 AM

Quote:

Originally Posted by kikinovak (Post 4961125)
I guess that's exactly my concern. Will my packages be built correctly (that is, usable on other machines) if built in a virtual environment with guest additions installed? There are some basic features like correct X display configuration and use of shared folders between host and guest that I'm very used to, and I simply don't want a machine that only works like a chicken flies or a horse swims.

I don't see an issue there. The nvidia blob replaces files of stock slackware, that's why it sometimes causes issues. The vbox guest additions do not. However, I don't have them installed on any of my VMs I use for building packages. They are as close to stock as possible (with the only addition being icecream so the builds are not horribly slow. My -current VMs don't even have that though).
I couldn't care less about X in my VMs and shared folders you can just as well make from the other side by using sshfs (i.e. mount a folder from the guest on the host).

kikinovak 05-29-2013 07:53 AM

Quote:

Originally Posted by ruario (Post 4961195)
By the way are you tweaking the build options for Firefox ESR? If not why not just repackage the binaries that Mozilla provide? Much quicker and the result for them will obviously be the same then as you haven't actually built them.

I just haven't thought about it. I'll give it a try. :)

chess 05-29-2013 07:53 AM

Personally, if you are only setting up the virtual machine to build packages, it might be easier and faster to simply install Slackware into a chroot directory and then build your packages in there. I've built 64 bit and 32 bit packages on my 64 bit machine for years. Look at AlienBob's post here:

http://www.linuxquestions.org/questi...8/#post4096892

kikinovak 05-29-2013 07:55 AM

Quote:

Originally Posted by ppr:kut (Post 4961207)
I don't see an issue there. The nvidia blob replaces files of stock slackware, that's why it sometimes causes issues. The vbox guest additions do not. However, I don't have them installed on any of my VMs I use for building packages. They are as close to stock as possible (with the only addition being icecream so the builds are not horribly slow. My -current VMs don't even have that though).
I couldn't care less about X in my VMs and shared folders you can just as well make from the other side by using sshfs (i.e. mount a folder from the guest on the host).

Thanks very much ! That's exactly what I wanted to know.

The reason why I use X is I'd like to use my virtual guest installations as sandboxes for various desktop configuration tweaks. And without guest additions, any graphical environment will look like a box of LEGO for toddlers.

ruario 05-29-2013 08:37 AM

Quote:

Originally Posted by ruario (Post 4961195)
By the way are you tweaking the build options for Firefox ESR? If not why not just repackage the binaries that Mozilla provide? Much quicker and the result for them will obviously be the same then as you haven't actually built them.

Quote:

Originally Posted by kikinovak (Post 4961302)
I just haven't thought about it. I'll give it a try. :)

If you want to have a quick test, you can use my latest-firefox script (or you could use relevant parts of it in your own SlackBuild).

Be aware that my script is not a traditional SlackBuild. It checks for the version installed and only builds (well repacks really) if a newer/different version is available. It also fetches the binary "source" package from Mozilla itself. Additionally it can do the repack as a regular user but produce a package with root owned files. I use it if I want a development or ESR version of Firefox (of if there is a delay in Pat updating the regular package).

To force ESR, set the variable FFESR to Y, e.g.:

Code:

FFESR=Y ./latest-firefox
If you want French Language, set the variable FFLANG to fr, e.g.:

Code:

FFLANG=fr FFESR=Y ./latest-firefox
If you want to repackage a different architecture (e.g. 64-Bit on a 32-Bit build machine), set ARCH, e.g.:

Code:

ARCH=x86_64 FFLANG=fr FFESR=Y ./latest-firefox
I have similar scripts for Opera and Google Chrome.

tronayne 05-29-2013 10:19 AM

Hey, Niki,

I've compiled Windows stuff in a Win7 guest and installed the result on a "real" Win7 system for a guy and it worked just fine -- the guest has the both the guest additions and the extension pack installed.

I have had a Slackware 32-bit guest on my 64-bit server, again with guest additions and extension pack, built stuff in the 32-bit guest and ftp'd it to a remote server, also worked (and still is) fine. Now that was 13.37, not 14.0, but I can't see why it would be a problem.

Like other folk have said, try it and see.

Hope this helps some.


All times are GMT -5. The time now is 12:13 PM.