emulators/virtualbox-ose: Update to 6.1.26

[madpilot]

Summary

I'm testing the virtualbox update to the latest update.

This update includes extensive changes to the audio subsystem. Due to this our patches for OSS don't apply anymore. Altough a cursory look at the changes makes me think the patches are not needed and the code now does the right thing.

However pulseaudio support has stopped working. Virtual machines configured to use pulseaudio fail to start with the following error:

Failed to construct device 'ichac97' instance #0 (VERR_CFGM_VALUE_NOT_FOUND).

Looking in the VM logs I found these related lines:

00:00:00.958601 Audio: Initializing PulseAudio driver
00:00:00.958624 AssertLogRel /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-6.1.24/src/VBox/Devices/Audio/DevHda.cpp(5042) int hdaR3Construct(PPDMDEVINS, int, PCFGMNODE): RT_SUCCESS(rc)
00:00:00.958644 LUN#0: rc=VERR_CFGM_VALUE_NOT_FOUND
00:00:00.958654 PDM: Failed to construct 'hda'/0! VERR_CFGM_VALUE_NOT_FOUND (-2103) - Value not found.

Due to this regression I'm submitting the update here instead of committing it.

I'm looking for help fixing the issue.

Test Plan

Have pulseaudio also work and then commit.

[madpilot]

BTW the error VERR_CFGM_VALUE_NOT_FOUND makes me suspect something is going wrong with the VM xml configuration file. But I have found no clue about what is missing.

[dereks_lifeofadishwasher.com]

Can you upload the .vbox file?

[madpilot]

In D31264#704128, @dereks_lifeofadishwasher.com wrote:

Can you upload the .vbox file?

Sure, I'm attaching an archive with the vbox file and the full log produced while trying to start the machine.

Simply changing the output driver to OSS makes it work fine.

vbox-data.tar.xz7 KBDownload

[grahamperrin]

TIL: the host audio driver can be changed for the saved state of a running machine.

I successfully tested a switch from null to OSS, so I guess that (if this PulseAudio issue is not easily resolved) guests that use PulseAudio might similarly be switched to OSS.

[madpilot]

The virtualbox developers released version 6.1.26

I'm creating a new patch to update to it.

The changelog does not indicate anything changed in the audio drivers area this time. Anyway I'm testing the update and report here once I have patches ready.

[madpilot]

Revise patch to update port to new version 6.1.26.

Unluckily the pulseaudio regression is unchanged.

I also noticed that both 6.1.24 and 6.1.26 now create an output file with some information in my home directory every time I launch a VM. Not a blocker but slightly annoying!

[koobs]

emulators/virtualbox-ose/files/patch-configure

13–14

Replace hard-coded /usr/local with SUB_FILES AND %%LOCALBASE%% or modify/set them with CONFIGURE_ARGS instead of patching, which would seem to be the better option.

60

Can this be done with CONFIGURE_ENV / CONFIGURE_ARGS VBOX_GSOAP_CXX_LIBS='-lz' ?

[madpilot]

Will submit patch with changes suggested by koobs in his first comment .

emulators/virtualbox-ose/files/patch-configure

13–14

Good catch. Please note that this was existing code I did not modify it myself in this patch.

60

That would not work because VBOX_GSOAP_CXX_LIBS is calculated on the fly based on pkg-config output. In fact I don't understand why that -lz is necessary. Looks like it should be reported by by the gsoap library pkg-config script, but other consumers don't seem to care.

I'm adding it there manually to make virtualbox compile. Any other solution would require even more intrusive changes to the configure script.

[madpilot]

emulators/virtualbox-ose/files/patch-configure

13–14

Looking at this, there are actually a bunch of these that require fixing. I'm taking a look.

[madpilot]

emulators/virtualbox-ose/files/patch-configure

13–14

Sorry for multiple replies. Actually there is this in the Makefile:

@${REINPLACE_CMD} -e 's|/usr/local|${LOCALBASE}|g' \
            ${WRKSRC}/Config.kmk ${WRKSRC}/configure \

Changing this logic would require re-engineering the whole thing, which I don't think is really worth it.

[koobs]

@madpilot Yep, sure, those are the things that just stood out to me as odd, or in need of improvement.

What is the nature/impact of the pulseaudio regression? Are there alternatives / workarounds? Any way we can highlight this for users?

What are possible avenues from here?

[madpilot]

In D31264#706846, @koobs wrote:

@madpilot Yep, sure, those are the things that just stood out to me as odd, or in need of improvement.

They are, problem is there is a complex structure of REINPLACE_CMDs that would require major reworking if we decided to change that part.

What is the nature/impact of the pulseaudio regression? Are there alternatives / workarounds? Any way we can highlight this for users?

I have not had time to really look at the pulseaudio issue. Not sure if I'm able to find a solution though.

The alternative is using native OSS audio and we can notify users via UPDATING or the existing pkg-message.

What are possible avenues from here?

Apart from finding a fix, the only solution is committing the update with pulseaudio broken and notifying users. I don't see any alternative.

[madpilot]

I filed a ticket upstream:

https://www.virtualbox.org/ticket/20484

[grahamperrin]

In D31264#706646, @madpilot wrote:

… 6.1.24 and 6.1.26 now create an output file with some information in my home directory …

As far as I know, this is not new behaviour. You might find that the file persists only if there's a problem.

I have, for example, 2021-07-10-10-31-49.049-VirtualBoxVM-4810.log created and modified on 10th July (with 6.1.22).

[madpilot]

After some thought (and being unable to fix the issue) I think the best course of action is to temporarily exclude the PULSEAUDIO option until a fix is found.

That option is also off by default, so there is no change for people using binary packages or default options.

I decided to disable it leveraging the EXCLUDE variable, adding a comment. This, IMHO, makes clear what the intention is and also makes it quite easy to activate it back later.

If there are no objections I'd like to commit this update in a few days.

[koobs]

No objections, lets just explicitly include/explain that in the commot log message, and include any upstream references (if they exist)