Available Decompression on Windows?

I’m considering putting together a ready-to-use VirtualBox VM, pre-primed for building ar71xx and ath79 for recalcitrant users. I’d like to compress it.

What is readily available for Windows 10 users past zip?

  • gzip
  • xz

Is tar generally available now?

sure thats needed?
the trouble of unpacking would probably consume any convenience gains from a faster transfer.

Nope, none of these. However you could use .cab files if .zip is too generic / old school :sweat_smile:

Might not be relevant, but also .iso images are supported (i.e. they can be mounted as a virtual disc drive without additional software).

2 Likes

7-zip provides the above, for those willing...

3 Likes

Thanks -- old-school zip may be the answer if the native VirtualBox "export appliance" doesn't do any compression. The goal is that this is as turn-key as possible to be able to support users that may not have significant Linux experience.

I'd say that it would be a bad idea in general. Such images tends to get old fast and you'll just pile up more support requests than what you normally would like to handle. It would be a better idea to update the wiki (which probably would recieve more contributions if it used markdown instead of dokuwiki syntax) on how to get the toolchain running on distro X.

If you want to keep the size down I'd highly suggest that you use Alpine which works great instead of Debian. There are also a few tricks you can do to make the image file smaller in size such as zeroing free space. There's also quite a performance hit compared to Hyper-V (Pro or higher only) in my experience. You might want to consider VDI for compatibility with both Hyper-V and Virtualbox (might be a bit troublesome however as Hyper-V will most likely use virtio drivers).

To answer your original question however, only zip and cab are support but as others also have mentioned you can use 7z as pretty much anyone knows what it is and if they can't figure it out they most likely can't figure out VirtualBox etc either.

1 Like

Please don't. Official build base line is Debian.

2 Likes

Unless @jeff is going to base the VM off Debian 8 it doesn't really matter as things will still break as seen earlier.

It is not about failures, it is about using things as a baseline which are used by a large fraction of the developers and/or the CI system itself.

Bringing a musl based host system into the equation may result in build issues without readily available reproducers and/or solutions.

And as I said, by that reasoning using any else than Debian 8 is a bad idea.

Then why suggest Alpine in the first place?

1 Like

I would say if someone is going to use Virtual Box and build images, then they would have a proper compression utility installed.

If ZIP format gives you the compression you want, then that could do. Otherwise, you could use TAR, GZIP, XZ, and of course 7Z.

7-Zip supports all of them, and it's free and open source.
https://www.7-zip.org/

1 Like

That was meant as a response to your objection to use anything else than Debian. If so, Debian 8 is the only option as anything else diverges from the buildbots which already are hard to reproduce as very few still runs a distro with GCC 4.X for instance as the recent bump of CMake showed pretty clearly. (https://github.com/openwrt/openwrt/commit/d4540354303949c93b20ea0148afd90ce5e40ea6#comments)

Having that in mind, it also sparks the question whether attempts such as https://github.com/openwrt/openwrt/pull/1937 are doomed from the start as it will not build on the buildbots unless python is imported into /tools.

@jeff
In case you've missed this might be of interest.

I think there is an option where 7zip provides an installer kinda thing that doesn't even need the 7zip installed on Windows. It just works as it is and you can extract the files. I'm not sure if it's actually provided by 7zip itself or there's something else involved in the process. But IMO 7zip has provided the best compression so far, at least for me. So I think 7zip should be the way to go for Windows.

Correct. An option called Create SFX archive, available only when you select the Archive format as 7z. Choosing such option create an executable EXE file containing the compressed data.

But that will require that the files are compressed on a Windows machine, which might be forbidden for some Linux and FreeBSD gurus.

1 Like

Note that 7-zip support for compressed tar files is utter garbage and requires two steps - first uncompress the GZ, then extract the tar.

Single-step decompression of .tar.gz or .tar.bz2 is only available via some funky command line trickery.

However - I think I misread what you were intending to do, you're thinking of compressing the VM, not the actual releases? If so, gzipping or bzipping the OVA and requiring 7-zip might work, since it's only a single file.

The question is how much space you would actually save - since an OVA should allow for thin provisioning.

1 Like

If I do prepare an image, as diizy brings up never-ending support issues, I would probably just go with the .ova image, which appears to handle both archiving and compression.

Any Windows-specific compression scheme, especially executables, falls far outside of a "works anywhere" goal.

I kind of forgot that OVA is, fundamentally, a ZIP file - so while there might be more efficient compression schemes, they won't work very well with an OVA since it's already compressed.

Most of the benefit from an OVA is from thin provisioning - and I'm not sure if there are any techniques for ensuring that empty space is properly marked as "empty" when you export the OVA. I've gained a lot of VMWare knowledge over the past few months at work (I run a dedicated ESXi host for my department's engineering needs), but exporting OVAs for general use isn't something I've done any work with.

A VM may be my only option for rebuilding GL.iNet's u-boot given that their source appears to break on recent Ubuntu distros.

I don't think the distro selection is a big deal, as long as it's a "standard" one. Of course there are som snags from time to time.

In our team we have two developers using Debian, two using OpenSuse, one Ubuntu and two using Windows. Actually one guy has two Windows laptops, because a customers VPN solution breaks Windows networking so it's almost useless without uninstalling the VPN client:-) On the Windows machines they used Ubuntu under VMWare, but now they use a scaled down OpenSuse docker image. Or if they are in the office and a bit lacy, build on one of the OpenSuse machines that are always there and up and running. SSH is a marvelous tool! I think the Ubuntu machine uses that docker image now because of some updated tool in latest Ubuntu, and he was too lacy to fix it. The purpose of the docker image is to have consistent "official " builds, but it is obviously useful for test builds too.

On OpenSuse we had to fix a couple of bugs in package makefiles, like using host headers and linking against staging libs, and linking tools against staging libs and using the host libs at run time. And by accident that worked on some versions of Ubuntu and Debian, because the staging libs and host libs where equal enough. But it is still bugs even when it works.

But we don't care much for the docker image size, so no advice there. So I guess this post is kind of useless:-)