There seems to be a problem with the https certificate at download.virtualbox.org:
fedora-review -b 1481630 -m fedora-rawhide-x86_64
...
08-16 12:46 root         INFO     Downloading (Source0): https://download.virtualbox.org/virtualbox/5.1.26/VirtualBox-5.1.26.tar.bz2
08-16 12:46 root         DEBUG    Exception down the road...
CertificateError: hostname 'download.virtualbox.org' doesn't match either of '*.akamaized.net', '*.akamaihd-staging.net', '*.akamaized-staging.net', '*.akamaihd.net', 'a248.e.akamai.net'
...

An alternative could be to use the http link instead:
http://download.virtualbox.org/virtualbox/5.1.26/VirtualBox-5.1.26.tar.bz2

Taking this review.

Hi Neal,

Please note that the guest kernel modules are not yet in place in the Fedora kernel (I'm working on this) still it would be good to get this review done, so that this can land as soon as the kernel side is ready.

If you want to test things, here are the git repos where I'm cleaning up the 2 missing kernel drivers:

https://github.com/jwrdegoede/vboxguest
https://github.com/jwrdegoede/vboxsf

You need to build both modules, then copy them to /lib/modules/$(uname -r)/misc and then do a depmod -a before rebooting.

Also I see that the rawhide kernels do not yet have the vboxvideo driver enabled (which has landed upstream in 4.13). I've just fixed this, a scratchbuild with the fix is building here now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21262911

Regards,

Hans

Hello , I'm thinking what should write , of course I will do the review ASAP ( today evening or so, next weekend at most ) 
but I got some questions ... 
1 - and VirtualBox server package ? 
2 - And how about do this for VBox 5.2 beta ? , 5.2 beta we should have  

+    VBOX_USE_SYSTEM_GL_HEADERS=1
+    VBOX_NO_LEGACY_XORG_X11=1 \

instead use our patches ...

(In reply to Sergio Monteiro Basto from comment #4)
> Hello , I'm thinking what should write , of course I will do the review ASAP
> ( today evening or so, next weekend at most ) 
> but I got some questions ... 
> 1 - and VirtualBox server package ? 

There are no plans to upstream the vbox host kernel modules, so the VirtualBox-server package will need to stay in rpmfusion. Nothing changes for the rpmfusion pkgs really, other then dropping the -guest-additions sub-package when this one is ready.

> 2 - And how about do this for VBox 5.2 beta ? , 5.2 beta we should have  

README.GuestAdditionsPackaging clearly state that upstream advises to use the latest *stable* release for packaging guest-additions, so that is something to worry about once it becomes stable, and then it will just be as any other package rebase to a new upstream, switch to the new upstream tarbal and fix what ever needs to be fixed.

Neal Gompa, please review it , thanks

Hi, 
After tweak fedora-review [1] I needed 2 patches [2] , I see one issue , the provides of libGL.so.1()(64bit) [3] can we remove this rpm provides ? 
Regards.

[1] 
https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/build/591889/

[2] 
0001-don-t-verify-certificates-of-ssl-connections.patch
0001-use-mock-old-chroot-to-not-break-some-scripts.patch


[3]

Provides
--------
VirtualBox-guest-additions:
    VirtualBox-guest-additions
    VirtualBox-guest-additions(x86-64)
    libGL.so.1()(64bit)

I'm working on setting up a test environment for this, per Hans' comment in comment 3.

IIRC, you need something like this: (taken from libglvnd).

%global __provides_exclude_from %{_libdir}/%{name}
%global __requires_exclude_from %{_libdir}/%{name}

Hi,

(In reply to Nicolas Chauvet (kwizart) from comment #9)
> IIRC, you need something like this: (taken from libglvnd).
> 
> %global __provides_exclude_from %{_libdir}/%{name}
> %global __requires_exclude_from %{_libdir}/%{name}

Thank you for that, that is much better then the old-fashioned provides filtering I had in mind.

Regards,

Hans

(In reply to Sergio Monteiro Basto from comment #7)
> Hi, 
> After tweak fedora-review [1] I needed 2 patches [2] , I see one issue , the
> provides of libGL.so.1()(64bit) [3] can we remove this rpm provides ? 
> Regards.
> 
> [1] 
> https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/
> build/591889/

This link does not work.

> [2] 
> 0001-don-t-verify-certificates-of-ssl-connections.patch
> 0001-use-mock-old-chroot-to-not-break-some-scripts.patch

The pkg builds fine in mock for me, also I don't see these patches anywhere.

> 
> 
> [3]
> 
> Provides
> --------
> VirtualBox-guest-additions:
>     VirtualBox-guest-additions
>     VirtualBox-guest-additions(x86-64)
>     libGL.so.1()(64bit)

I've fixed this for the next release.

Here is a new version:

Spec URL: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions.spec
SRPM URL: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions-5.1.26-3.fc27.src.rpm

Changelog:

* Mon Aug 28 2017 Hans de Goede <hdegoede@redhat.com> - 5.1.26-3
- Put the libGL.so.1 replacement libs and VBoxOGLRun scripts in an -ogl
  subpackage, so that people can install both the i686 and x86_64 versions.
- Filter out libGL.so.1 provides

> BuildRequires:  kBuild >= 0.1.9998
> BuildRequires:  desktop-file-utils makeself yasm
> BuildRequires:  boost-devel
> BuildRequires:  libXcomposite-devel libXmu-devel libXrandr-devel libXt-devel
> BuildRequires:  mesa-libEGL-devel mesa-libGL-devel mesa-libGLU-devel
> BuildRequires:  pam-devel zlib-devel

Could you please break out all the BuildRequires onto newlines? It makes it easier to review...

(In reply to Neal Gompa from comment #13)
> > BuildRequires:  kBuild >= 0.1.9998
> > BuildRequires:  desktop-file-utils makeself yasm
> > BuildRequires:  boost-devel
> > BuildRequires:  libXcomposite-devel libXmu-devel libXrandr-devel libXt-devel
> > BuildRequires:  mesa-libEGL-devel mesa-libGL-devel mesa-libGLU-devel
> > BuildRequires:  pam-devel zlib-devel
> 
> Could you please break out all the BuildRequires onto newlines? It makes it
> easier to review...

Ok, I've updated the .spec and the -3 src.rpm with this change, I've not bumped the release given the very minor nature of this change.

(In reply to Hans de Goede from comment #11)
> (In reply to Sergio Monteiro Basto from comment #7)
> > Hi, 
> > After tweak fedora-review [1] I needed 2 patches [2] , I see one issue , the
> > provides of libGL.so.1()(64bit) [3] can we remove this rpm provides ? 
> > Regards.
> > 
> > [1] 
> > https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/
> > build/591889/
> 
> This link does not work.

Link is here : https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/package/fedora-review/ 

> 
> > [2] 
> > 0001-don-t-verify-certificates-of-ssl-connections.patch
> > 0001-use-mock-old-chroot-to-not-break-some-scripts.patch
> 
> The pkg builds fine in mock for me, also I don't see these patches anywhere.

Patches are here : http://copr-dist-git.fedorainfracloud.org/cgit/sergiomb/builds_for_Stable_Releases/fedora-review.git/tree/

But, patch 0001 we don't need anymore, because now you change https to http in source0 .
The patch 002 if a problem in my system and kde4 in general that /etc/localtime wasn't a symlink . 

Cheers.

@Hans:

The package looks good to me, but I don't want to approve it until you've pinned down the kernel that will support these drivers.

Can you please get this figured out?

Hi Neal,

Thank you for the review and I understand. 2 weeks ago Virtual Box upstream let me know that they want to do some cleanups on the vboxguest character device ioctl API before they are willing to declare it stable and promise they will not break the API in the future. Virtual Box upstream is currently working on these cleanups.

Once these cleanups are done, I will need to adjust my kernel patches to match (*) and then submit a new version of the vbox patches to the upstream Linux kernel. So for now I'm waiting on Virtual Box upstream. I will let you know (here in this bug) when there is some progress.

Regards,

Hans


*) and do a new version of the VirtualBox-guest-additions package implementing the new API)

Thanks!

Hans,

What progress has been made on the drivers?

Hi,

I got a headsup from upstream last Wednesday that the new stable ioctl interface is in place. They did more changes to the ioctl interface then I expected. So now I'm adjusting my cleaned up version of the driver to match the new ioctl interface, I hope to have that done and submit a non RFC v1 of the patch for inclusion into the mainline kernel in 2-3 days.

Regards,

Hans

d

(In reply to Hans de Goede from comment #20)
> Hi,
> 
> I got a headsup from upstream last Wednesday that the new stable ioctl
> interface is in place. They did more changes to the ioctl interface then I
> expected. So now I'm adjusting my cleaned up version of the driver to match
> the new ioctl interface, I hope to have that done and submit a non RFC v1 of
> the patch for inclusion into the mainline kernel in 2-3 days.
> 

Excellent!

ah sorry for that d there. I just meant to CC.

Can there be a subpackage just for the non gui related bits like the shared mounting ?

(In reply to Hans de Goede from comment #20)
> Hi,
> 
> I got a headsup from upstream last Wednesday that the new stable ioctl
> interface is in place. They did more changes to the ioctl interface then I
> expected. So now I'm adjusting my cleaned up version of the driver to match
> the new ioctl interface, I hope to have that done and submit a non RFC v1 of
> the patch for inclusion into the mainline kernel in 2-3 days.

Ok, so I've just send v1 (first non RFC version) of the patch to add the vboxguest driver to the mainline kernel upstream.

I also have prepared a new version of the package based on the 5.2 pre-releases as a 5.2 version of the Guest Additions is necessary since that implements the new ioctl API as it is (hopefully) going upstream:

Spec URL: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions.spec
SRPM URL: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions-5.2.0-0.1.svn68769.fc27.src.rpm

This is based on a svn snapshot as vbox upstream is not releasing source tarbals for the pre-releases.

So VirtualBox 5.2 released... Is there an update to this based on the final release? Also, how has upstreaming the kernel part gone?

(In reply to Neal Gompa from comment #25)
> So VirtualBox 5.2 released... Is there an update to this based on the final
> release?

Yes, which is good news as that implements the same vboxguest ioctl API as which will hopefully go upstream. I've not yet created updated packages, I have put that on my todo list. May take a week or so before I get around to this.

> Also, how has upstreaming the kernel part gone?

v1 result in upstream requesting some more rework, I finished that last week and submitted v2. So far things have been quiet around v2, so it is mostly waiting for some people to find time to review it atm.

@Hans, I'm reviewing VirtualBox packages , to adjust guest 3D passthru, and I have some questions .
1 - you do not add /usr/lib64/VBoxEGL.so to package ? 

2- Reading VBoxOGLRun.sh  we got [1] , shouldn't we enable that as system wide , by default in all system ?  

My plan is update Vbox packages with 5.1.30 in all branches and after that begin to pack 5.2 in rawhide and F27, we / I may start thinking in drop guest-additions in RPMFusion packages or something like that and plan to coordinate the existence of the 2 src.rpms in repos. 

3- Fedora kernels for f27 or rawhide already have vboxguest kernel modules ? or do we need still enable it ? (this part still not studied, but for testing we need one kernel with the modules ... )  

[1]
if VBoxClient --check3d; then
    export LD_LIBRARY_PATH=/usr/lib64/VBoxGuestAdditions:/usr/lib/VBoxGuestAdditions

(In reply to Sergio Monteiro Basto from comment #27)
> @Hans, I'm reviewing VirtualBox packages , to adjust guest 3D passthru, and
> I have some questions .
> 1 - you do not add /usr/lib64/VBoxEGL.so to package ? 
> 
> 2- Reading VBoxOGLRun.sh  we got [1] , shouldn't we enable that as system
> wide , by default in all system ?  
> 
> My plan is update Vbox packages with 5.1.30 in all branches and after that
> begin to pack 5.2 in rawhide and F27, we / I may start thinking in drop
> guest-additions in RPMFusion packages or something like that and plan to
> coordinate the existence of the 2 src.rpms in repos. 
> 
> 3- Fedora kernels for f27 or rawhide already have vboxguest kernel modules ?
> or do we need still enable it ? (this part still not studied, but for
> testing we need one kernel with the modules ... )  
> 
> [1]
> if VBoxClient --check3d; then
>     export
> LD_LIBRARY_PATH=/usr/lib64/VBoxGuestAdditions:/usr/lib/VBoxGuestAdditions

vboxvideo seems to have been activated in the Fedora 27 kernel, but vboxguest is still missing...

Hans,

Any update on the state of VirtualBox guest addition kmods for the Fedora 27 kernel?

Hi,

(In reply to Sergio Monteiro Basto from comment #27)
> @Hans, I'm reviewing VirtualBox packages , to adjust guest 3D passthru, and
> I have some questions .
> 1 - you do not add /usr/lib64/VBoxEGL.so to package ? 

Yes, because it is broken the upstream guest-additions install script also no longer installs it. With this in LD_LIBRARY_PATH gnome will no longer work in Wayland mode.

> 2- Reading VBoxOGLRun.sh  we got [1] , shouldn't we enable that as system
> wide , by default in all system ?  

The opengl passthru code is not all that great:

1) It provides a very old version of opengl, 2.1, many apps including e.g. webGL in firefox will not work with it
2) It makes any GL rendered surfaces being always on top
3) It does work with gnome-shell on top of X11 but the always on top thing then breaks running any OpenGL apps on top of gnome-shell, when you do that everything becomes horribly slow and the window gets no window decorations

TL;DR: the OpenGL passthru support is not in a state where enabling it system-wide is a good idea. This is also why it is disabled by default if you create a new vm.

> My plan is update Vbox packages with 5.1.30 in all branches and after that
> begin to pack 5.2 in rawhide and F27, we / I may start thinking in drop
> guest-additions in RPMFusion packages or something like that and plan to
> coordinate the existence of the 2 src.rpms in repos. 
> 
> 3- Fedora kernels for f27 or rawhide already have vboxguest kernel modules ?
> or do we need still enable it ? (this part still not studied, but for
> testing we need one kernel with the modules ... )  

As Neal already replied vboxvideo is in place I'm still waiting for upstream review of my v2 patch to add vboxguest support upstream. I will go and ping some people about this.

Regards,

Hans

Hans,

Any progress on vboxsf kernel module? IIRC, that's the third one provided by the guest additions...

(In reply to Neal Gompa from comment #31)
> Hans,
> 
> Any progress on vboxsf kernel module? IIRC, that's the third one provided by
> the guest additions...

Correct that is the third module. vboxsf depends on IPC provided by vboxguest, I've it ready for upstream submission but first I need to get vboxguest upstream.

I've pinged one of the upstream maintainers asking for a review of vboxguest.

(In reply to Hans de Goede from comment #9)
> Hi,
> 
> So I've just finished packaging the vbox guest-additions for Fedora proper:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1481630
> 
> I've solved the OpenGL issue there by putting all libs under
> %{_libdir}/VBoxGuestAdditions and
> offering a script to run apps through OpenGL passthru like this:
> 
> VBoxOGLRun glxgears
> 
> I've opted to go this route rather then auto-enable at boot since OpenGL
> passthru has some issues with some apps (and does not work when using
> gnome-shell + other opengl apps on top).

I had modified RPMFusion vbox package with these changes ( just in F27 and rawhide)   
I haven't check it yet 


> With this fix, the ldconfig calls can be moved from the %post scripts, 

hum , I have to check this , I could run tuxcart in a vm without OGL .

> I've
> also removed VirtualBox-guest.modules and the restart of
> modules-load.service since all guest modules will properly autoload so this
> is not necessary.

Fedora kernel already have all modules for guest machines ?

> Feel free to pick up these changes for the rpmfusion pkgs :)

kmk need this [1] all least in my case ... 

[1] 
+    VBOX_PATH_APP_PRIVATE=%{_libdir}/virtualbox \
+    VBOX_PATH_APP_DOCS=%{_docdir}/VirtualBox    \

I was comment https://bugzilla.rpmfusion.org/show_bug.cgi?id=4617#c9

(In reply to Sergio Monteiro Basto from comment #33)

> > With this fix, the ldconfig calls can be moved from the %post scripts, 
> 
> hum , I have to check this , I could run tuxcart in a vm without OGL .

Tuxkart and extreme tux racer still runs well, as they have some king of 3D enabled , so I went forward and applied updates of vbox also in stable branches. 

Now we need prepare update for Vbox 5.2 

Cheers.

Hans,

Any news on vboxguest and vboxsf?

(In reply to Neal Gompa from comment #36)
> Hans,
> 
> Any news on vboxguest and vboxsf?

Actually I send a mail this morning asking another kernel developer if he would be willing to help me out by reviewing the vboxguest driver, if he says yes then I'm going to ask the misc. subsys maintainers if that works for them. TL;DR: still in upstream review process limbo I'm afraid.

Here is a new version of the pkg, updated to 5.2.2:

SPEC: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions.spec
SRPM: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions-5.2.2-1.fc27.src.rpm

Unfortunately the kernel patches are still awaiting review by the misc subsys maintainers upstream. I did manage to get a review done by another kernel contributor (and addressed his comments), so hopefully something will happen wrt this soon.

Hi Hans, 

Did you see this thread [1] I replied please "run app with VBoxOGLRun.sh or
export LD_LIBRARY_PATH=/usr/lib64/VBoxGuestAdditions:/usr/lib/VBoxGuestAdditions" 
which Vic replied with : "I already set LD_LIBRARY_PATH as a  temporary workaround.

Thanks" 

Conclusion, maybe we need enable LD_LIBRARY_PATH all the time , or may we move some files from /usr/lib/VBoxGuestAdditions to /usr/lib/ ? 

Thanks,


[1] 
https://lists.rpmfusion.org/archives/list/rpmfusion-users@lists.rpmfusion.org/thread/L365ROTMFLGVRBJCGT35FRCBLLNGV2PX/

(In reply to Sergio Monteiro Basto from comment #39)
> Did you see this thread [1]

Weird, Vic writes: "Some apps like atril and emacs are failing because VBoxOGLcrutil.so can't be found.", but the only thing requiring VBoxOGLcrutil.so should be the replacement libGL.so.1 which only gets used if LD_LIBRARY_PATH is set in the first place.

I've the feeling that Vic somehow has a ld.so.cache entry pointed to the vbox 
libGL.so.1. I'm not on rpmfusion-users, can you ask him to file a bugzilla so we can discuss this there? Also ask him to check for ld.so.conf.d files which may explain this.

(In reply to Hans de Goede from comment #38)
> Here is a new version of the pkg, updated to 5.2.2:
> 
> SPEC: https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions.spec
> SRPM:
> https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions-5.2.2-1.fc27.
> src.rpm
> 
> Unfortunately the kernel patches are still awaiting review by the misc
> subsys maintainers upstream. I did manage to get a review done by another
> kernel contributor (and addressed his comments), so hopefully something will
> happen wrt this soon.

Quick review with few minors things:

* Keep from using requires on kernel from userspace. Most of the time this is invalid (you could be within a chroot , container or systemd-nspawn, etc). Also you need to select the appropriate variant (on x86_64 kernel-debug exists or even kernel-rt).
# FIXME once kernel modules have landed
#Requires:       kernel >= 4.FIXME

* Please use pkgconf --libs libpng and etc not to hardcode one particular library path. (say if there is a  need to use one particular scl at some point).

* Is there a way "not to hardcode the vendor", such as:
VBOX_BUILD_PUBLISHER=_%{?vendor}%{?!vendor:Unknown}

* The replacement of the RPM Fusion package should works for the "userspace" but not much for the kmod-VirtualBox. Best is probably to keep a (virtual) Provides: VirtualBox-kmod-common = 5.2.2 (the last version of the rpmfusion counterpart before it is disabled). So that kmod-Virtualbox is kept while it will not try to seek the main VirtualBox(host) capability.
Then, it will only be a matter for the kernel

Obsoletes/Provides for the akmod isn't an option because it will affect host kmod-VirtualBox and VirtualBox users.

Another option is probably to only have the Obsoletes: akmod-VirtualBox < 5.22-100
(needs testing).

Good news, the vboxguest kernel module patches have been merged into char-misc-next. If all goes well and they do not get reverted in a couple of days I will add them to the rawhide kernels as downstream patches for now and then we can finally move forward with this review. Note we will then still miss the vboxsf driver. I will submit a much cleaned up version of that upstream soon and then we will see from there.

Nicolas, thank you for your comments, I will try to address those in a new version which I will prepare once the kernel side is sorted out.

(In reply to Nicolas Chauvet (kwizart) from comment #41)
> * Keep from using requires on kernel from userspace. Most of the time this
> is invalid (you could be within a chroot , container or systemd-nspawn,
> etc).

Where one would pretty much never install VirtualBox-guest-additions...

> Also you need to select the appropriate variant (on x86_64
> kernel-debug exists or even kernel-rt).
> # FIXME once kernel modules have landed
> #Requires:       kernel >= 4.FIXME

Ok, so I'm thinking to make the upgrade path issues easier to only
add the VirtualBox-guest-additions to Fedora's repos for F28+ in which case we can simply assume the kernel-bits will be there and not have this. How does this sound from an rpmfusion pov, this should make things easy for rpmfusion too, simply disable the VirtualBox-guest-additions subpackage for F28+.

> * The replacement of the RPM Fusion package should works for the "userspace"
> but not much for the kmod-VirtualBox. Best is probably to keep a (virtual)
> Provides: VirtualBox-kmod-common = 5.2.2 (the last version of the rpmfusion
> counterpart before it is disabled). So that kmod-Virtualbox is kept while it
> will not try to seek the main VirtualBox(host) capability.
> Then, it will only be a matter for the kernel

So what you're suggesting is that people who upgrade a virtual-machine with the rpmfusion akmod installed, keep the akmod, but now it will only built (unused) vbox host modules, instead of building both host _ guest modules, correct?

That sounds reasonable, this should also be easy (change the akmod to only build host modules) if we make the switch for F28+ and keep older releases as is.

Note I will try to fix your other remarks my next version.

Package name should be virtualbox-guest-additions. https://fedoraproject.org/wiki/Packaging:Naming#General_Naming says "Package names should be in lower case" and that's the common practice nowadays. Provides/Obsoletes for the capitalized name are enough to help people upgrade.

http://www.virtualbox.org/wiki/VirtualBox → https://

Likewise, https:// should be used for the download URL. Even if fedora-review had some issue with the certificate, not downloading over http is more important than what fedora-review thinks.

> # FIXME once kernel modules have landed
> #Requires:       kernel >= 4.FIXME
Like kwizart already said, this can never work. You can just drop this part.

BuildRequires: systemd is necessary for %{?systemd_requires}.

96-vbox.preset must be dropped, and the preset must be added following the normal procedue in https://fedoraproject.org/wiki/Starting_services_by_default.

> ConditionVirtualization=|oracle
Nice! This should make the package a total noop on any other system.

> Package name should be virtualbox-guest-additions. https://fedoraproject.org/wiki/Packaging:Naming#General_Naming says "Package names should be in lower case" and that's the common practice nowadays. Provides/Obsoletes for the capitalized name are enough to help people upgrade.

I actually would vote against this, as it's been packaged as "VirtualBox-guest-additions" for long enough and the lowercase thing isn't mandatory (cues from other packagers packaging it are expressly suggested for figuring out names). If you want to add "virtualbox-guest-additions" Provides, that's fine.

That said, if you want to make the change, I won't block it, but I will say you will *have* to have "VirtualBox-guest-additions" work as a way to install it no matter what.

I agree that VirtualBox-guest-additions must be provided either way. But I think the lowercase name is much more in agreement with current style and the guidelines. It also matches the service name. The fact that there was an external package matter that much.

Yep I would appreciate a lower case package name also. I find hard to remember one or another package name often, so not to take the case into account. Using lower case all along make things easier to remember.
(with Obsoletes/Provides in the current package case for compat anyway).

About obsoleting the kmod, I think the only good way would be to only use:
Obsoletes: akmods-VirtualBox < 5.1.31 #whatever version is introduced in fedora
(so without any provides on purpose, not to mess with VirtualBox HYP users).

That been said, I think there is few guest users (people with the virtualbox guest package installed) compared with host one.
(at least I don't install guest drivers on my vbox guests).

(In reply to Hans de Goede from comment #40)
> (In reply to Sergio Monteiro Basto from comment #39)
> > Did you see this thread [1]
> 
> Weird, Vic writes: "Some apps like atril and emacs are failing because
> VBoxOGLcrutil.so can't be found.", but the only thing requiring
> VBoxOGLcrutil.so should be the replacement libGL.so.1 which only gets used
> if LD_LIBRARY_PATH is set in the first place.
> 
> I've the feeling that Vic somehow has a ld.so.cache entry pointed to the
> vbox 
> libGL.so.1. I'm not on rpmfusion-users, can you ask him to file a bugzilla
> so we can discuss this there? Also ask him to check for ld.so.conf.d files
> which may explain this.

Hello , Vic replied was an problem with an guest installation with oracle tools , maybe is not a bad idea check and or clean old installations of guest (since with oracle tool, installation may not be cleaned) here is the transcription of what I think that was relevant: 

"I took a look, but there was nothing of interest in /etc/ld.so.conf.d/, but that did lead me to find an old copy of the Guest Additions in /opt.  I uninstalled that, and re-installed the RPM.  All seems to be well now. (without LD_LIBRARY_PATH)
It seems my problem was self-inflicted.  Apologies." 


Best regards,