On recent head, after src commit 66c5fbca7719dc, the insmntque1(9)
function arguments changed.
Adapt virtualbox code, following what has been done in base with
other filesystems migrating to insmntque(9).
The conflict checks compare the patterns first against the package
names without version (as reported by "pkg query "%n"), then - if
there was no match - agsinst the full package names including the
version (as reported by "pkg query "%n-%v").
Approved by: portmgr (blanket)
In the commit to update virtualbox-ose to 6.1.28 I made a one line
mistake when reapplying a patch which failed to apply as is.
In the patch
files/patch-src_VBox_HostDrivers_Support_freebsd_SUPDrv-freebsd.c
I did not replay a part removing the line:
rc = copyout(pHdr, pvUser, cbOut);
which was rewriting some data that it should not. The correct code
was anyway present after this leftover statement.
This error made virtualbox log a lot of warnings about Bad CPU
context like this:
vboxdrv: Bad CPU context error at line 373 in SUPDrv-freebsd.c:
ulCmd=0x2000568a: 0x282->0x287!
These seem to be unharmful, but anyway indicate a problem that this
commit fixes.
Reported by: Kevin Oberman <rkoberman@gmail.com> (via mailing list)
Fixes: a3db7da59f
- Add updated information about supported versions, installation
commands and mitigation for a known issue.
- Removed reference to the wiki page.
Reviewed on github:
https://github.com/freebsd/freebsd-ports/pull/115
PR: 254412
While here, make sure gtk-update-icon-cache is only on run dependency
where added as a dependency
Enforce gtk3 to depend on gtk-update-icon-cache (previously it was
inheriting the dependency)
In the virtualbox virtual filesystem code we ship as a patch some
code in an else block is commented out. This produces a code path
in which a pointer variable is dereferenced in an unassigned state,
causing random crashes.
Lacking a better fix, give a default value of NULL to the pointer,
which at least avoids the random pointer dereference issue.
PR: 255386
Import patch to teach VirtualBox to check availability of AIO
resources before trying to allocate more.
This prevents crashes when using AIO in VirtualBox.
PR: 168298
To disable the PULSEAUDIO option I used the OPTIONS_EXCLUDE variable
in commit 416b34d584.
Turns out this overwrites OPTIONS_EXCLUDE from slave ports. I'm
fixing this by only adding the PULSEAUDIO exclusion to the existing
EXCLUDE variable if defined.
NOTE: While it would be enough to bump PORTREVISION in the slave
port, I'm bumping PORTREVISION on master port to avoid adding
variables that are easily forgotten in future changes and could
cause even more breakage.
PR: 258256
Pointy Hat: myself
This new version has a regression in the pulseaudio host audio
driver. If enabled any VMs configured to use it fails to start.
Since no fix has been found the PULSEAUDIO option is forcibly
disabled. If you have any VM configured to use pulseaudio for audio
input/output, please reconfigure them to use a different driver.
Upstream ticket: https://www.virtualbox.org/ticket/20484
Other changes:
- Remove old patches that don't apply, the audio system has been
reworked upstream and the behavior of these patches is included in
the new code
- Add upgrading pkg-message note about the PULSEAUDIO option issue
described above
Reviewed by: koobs
Differential Revision: https://reviews.freebsd.org/D31264
Looks like this patch was removed in commit df5c241ed2
It is required to build with the DEBUG optioni (not default).
PR: 257777
Reported by: Mario Felicioni <marietto2008@gmail.com>
Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
After src commit e266a0f7f001 a module is not allowed to call
kern_kldload while being loaded. The virtualbox module is doing
exactly this though. virutalbox used to do this because the ng_ether
netgraph node did not provide version information in the past and
there was no way to properly depend on it.
ng_ether has gained versioning information in base r238844 more
than ten years ago, so we can now unconditionally properly depend
on it, since this revision is now included in all supported FreeBSD
versions.
Thanks to Tomoaki AOKI for identifying the base commuit exposing
the issue.
PR: 256505
Tested by: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
MFH: 2021Q2
Differential Revision: https://reviews.freebsd.org/D30722
- Also update related kmod and additions ports
- In additions, use INSTALL_LIB to install X11 modules, so binaries
get stripped
- Trim some `#if __FreeBSD_version` checks for unsupported FreeBSD
versions from patches
PR: 255301
Due to a compiler/linker command line ordering issue, VirtualBox 6
fails to compile on 11.x when a ports provided SSL library is
used.
Fix the order of -L options passed to the linker where the ssl
library is used.
Thanks to Chad Jacob Milios <milios@ccsys.com> for suggesting the
correct fix.
PR: 254295
Submitted by: russo@bogodyn.org
MFH: 2021Q2
In r560502, I added a patch to support EPOCH to VirtualBox 5. When we upgraded
to VirtualBox 6, that patch was (unintentionally) removed, making it impossible
to use bridge move without this current patch.
Approved by: jkim, madpilot
Differential Revision: https://reviews.freebsd.org/D29319
- Old VirtualBox OSE 5.2.44 preserved as "-legacy" versions of the
ports (repocopied)
- Add back extra patch removed in r528258, actually required to
build DEBUG kmod
- Correctly define WITH_DEBUG when enabling the DEBUG option, so
binaries are not stripped
Please note that this new version supports only amd64 CPUs. If you need
to use older hardware please install the legacy ports.
Note that moving VM snapshots across major updates is unsupported, it's
strongly suggested to properly shutdown VMs before upgrading, please
check UPDATING for further details.
This update is the result of work from many people, and thanks to all
who gave feedback and tested things.
Patch based on work from: Mario Lobo <lobo@bsd.com.br> and jkim.
PR: 234878
Submitted by: kunda <chitty_cloud@me.com>
Approved by: vbox (implicit)
Reviewed by: decke
Tested by: jwb,
martin ilavsky <ilavsky.martin@gmail.com>,
Mario Lobo <lobo@bsd.com.br>
Relnotes: https://www.virtualbox.org/wiki/Changelog-6.1
Differential Revision: https://reviews.freebsd.org/D28871
work at runtime as much as possible.
The OpenGL bits in VirtualBox 5 are an old implementation that does
not play too well with what wee have in the tree now. Thesse patches
simply change the funzionn prototypess in VirtualBox to match the
ones from mesa so it caan compile and interface as much as possible
with it.
Thanks to Ronald Klop <ronald-lists@klop.ws> for testing.
PR: 250315
Submitted by: rozhuk.im@gmail.com
Approved by: portmgr (fixit blanket)
VirtualBox embeds an outdated version of glext.h, causing it to
fail to build due to symbols being redefined incorrectly.
Import patch which forces virtualbox to append it's own include
paths, thus not "obscuring" the system provided OpenGL include file.
PR: 250315
Submitted by: rozhuk.im@gmail.com
Approved by: portmgr (fixit blanket)
- Use vm_pager_allocate() to allocate OBJT_PHYS objects. This ensures
that they're initialized properly.
- Don't assume that user wiring will succeed.
This had been a team effort, with multiple independent reports,
a wide variety of experiments, and patches written by kib@
and refined by markj@.
I'm bumping PORTREVISION and aligning the revision of both kmod and
application; it's possible the application bump isn't actually
needed but let's make sure they both get rebuilt with this
important (because of changed kernel assumptions) fix.
PR: 249326
Submitted by: kib, markj
Reported by: adridg, Rainer Hurling
Reviewed by: adridg
Approved by: koobs (vbox)
MFH: 2020Q3
I removed a bzero() call to reduce compiler warnings in the previous commit
(r544829). It turned out the next memcpy() call was also wrong. Just use
natural assignments here not to obfuscate the code.
Reported by: Martin Simmons (martin at lispworks dot com) (some time ago)
- Adapt and regenerate patches
- Reduce differences in patch-src_VBox_Devices_PC_vbox-cpuhotplug.dsl [1]
Patch based on one provided by Mario Lobo <lobo@bsd.com.br>.
Many thanks to people who provided ideas and suggetions in the
PR and review.
PR: 244212
Submitted by: Nikita Stepanov <nikitastepan0v@bk.ru>
Reviewed by: kevans [1]
Tested by: lwshu
Approved by: ports-secteam (joneum)
MFH: 2020Q3
Security: 1e7b316b-c6a8-11ea-a7d5-001999f8d30b
Differential Revision: https://reviews.freebsd.org/D25496
The runtime breakage that started occurring after the LLVM 7 -> 8 transition
has been diagnosed with help from cem@, and the attached patch fixes it. The
problem ended up being that tail-call optimization was being applied to this
function (which should probably be written in assembly instead) and moving
the tail-call to later on after some stack manipulations. The problem with
this is that this particular function uses alloca() to carefully craft a
stack that it's expecting to be used for the function it's calling at the
end.
The new patch fixes this using a technique that was committed later on in
upstream changeset 75061 to address a similar failure with GCC sanitizers
enabled. The FreeBSD-specific component of this patch is using the different
stack setup if __clang__ is defined as well.
The extra hunk in the Config patch has been added because the VirtualBox
build system cannot cope with LLVM version numbers in the way it's
expecting. Hardcode it to GCC 4.2 for FreeBSD, which is what the clang
__GNU* macros describe, to fix build breakage that happens with newer LLVM
as the build system decides our LLVM is an even older and more broken
version of GCC with a broken regparm.
PR: 236616, 244847
Approved by: koobs (mentor)
MFH: 2020Q2 (blanket: major runtime build fix)
This is a regression of something that was working in the past. Please
keep the _GCC_RUNTIME handling even if removing USE_GCC as it may
come back again in the future and be forgotten.
- Fix build on 11.3 with ports ssl. [2]
PR: 245048 [1]
PR: 243315 [2]
Submitted by: John Hein <jcfyecrayz at liamekaens.com> [2]
