The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
Updates VirtualBox from version 5.0.12 to 5.0.14.
Upstream changes are (without bug IDs):
* GUI: properly limit the number of VCPUs to the number of physical cores
on Mac OS X
* Audio: fixed a bug which prevented loading a saved state of a saved
guests with HDA emulation (5.0.12 regression)
* Audio: don't crash if the backend is unable to initialize
* Audio: fixed audio capture on Mac OS X
* Storage: fixed a possible crash when attaching the same ISO image
multiple times to the same VM
* BIOS: properly report if two floppy drives are attached
* USB: fixed a problem with filters which would not capture the device
under certain circumstances (5.0.10 regression)
* ExtPack: black-list Extension Packs older than 4.3.30 due to
incompatible changes not being properly handled in the past
* Windows hosts: fixed a regression which caused robocopy to fail
* Linux hosts: properly create the /sbin/rcvboxdrv symbolic link (5.0.12
regression)
* Mac OS X hosts: several fixes for USB on El Capitan
* Linux Additions: fixes for Linux 4.5
Full upstream changelog with bug IDs can be found at:
https://www.virtualbox.org/wiki/Changelog
The reason I was reluctant to merge this before were these symbol lookup
errors:
vboxsf: Unknown symbol VBoxGuest_RTMemTmpFree (err 0)
vboxsf: Unknown symbol VBoxGuestIDCCall (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexRequest (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexRelease (err 0)
vboxsf: Unknown symbol VBoxGuest_RTLogRelGetDefaultInstanceEx (err 0)
vboxsf: Unknown symbol VBoxGuest_RTErrConvertToErrno (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexCreate (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexDestroy (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemContFree (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexRelease (err 0)
vboxsf: Unknown symbol VBoxGuestIDCOpen (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertShouldPanic (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemContAlloc (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexRequest (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexCreate (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemTmpAllocTag (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexDestroy (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertMsg1Weak (err 0)
vboxsf: Unknown symbol VBoxGuestIDCClose (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertMsg2Weak (err 0)
However, after testing it against 5.0.12, the same errors occur there as
well, so it is likely related to our VM tests.
This makes pythonPackages.sqlalchemy the most up to date revision (it
was called sqlalchemy_1_0 before), and maintains the various “legacy”
versions available as pythonPackages.sqlalchemyX for X in {7,8,9}.
All derivations that required `sqlalchemy_1_0` now require `sqlalchemy`
while those that required `sqlalchemy` now require `sqlalchemy7`.
The derivations are not changed, only the attribute names they are
bound to.
This will probably be mandatory soon, and is a step in the right
direction. Removes the deprecated meta.version, and move some meta
sections to the end of the file where I should have put them in
the first place.
See http://nixos.org/nixpkgs/manual/#sec-package-naming
I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Excerpt from upstream release notes:
This release also contains the security fixes for XSA-137, XSA-138, XSA-141 to XSA-153.
XSA-139 and XSA-140 only apply to QEMU Upstream and are fixed from versions 2.3.1 and 2.4.0 of QEMU.
The qemu portion of XSA-135 has also been applied to qemu-traditional.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Also prepare to support multiple stage1 flavors.
The 'host' flavor would be preferred to reuse systemd components instead
of downloading/unpacking/processing a CoreOS PXE image.
* bump stage1 base image to v794.1.0 according to upstream release
* make use of BUILDDIR environment variable to control output path
* make use of the configure option for the stage1 image path and the stage1 base image path
* fix homepage URL
* add myself to the list of maintianers
This fixes the error message: GLib-GIO-Message: Using the 'memory'
GSettings backend. Your settings will not be saved or shared with other
applications.
It caused old saved settings to be forgotten, and new settings to be lost
when virt-manager is closed.
VirtualBox had support for DBUS even in version 4.x, but it appears that
nothing in our VM test triggered it to load, thus I didn't notice the
runtime error:
rtldrNativeLoad: dlopen('libdbus-1.so.3', RTLD_NOW | RTLD_LOCAL) failed:
libdbus-1.so.3: cannot open shared object file: No such
file or directory
The upstream commits I think are responsible for this to come to surface
are _probably_ (did I ever mention that I love SVN? *cough*) one of
these:
https://www.virtualbox.org/changeset/55664/vboxhttps://www.virtualbox.org/changeset/55602/vbox
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Regression introduced in 7ffb1f3bde.
Also added a small notice so that this hopefully won't happen with
future updates.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 0e0e3c0c08.
I've been seeing quite some QEMU segfaults on Hydra,
hopefully reverting the bump will fix the issue.
(cherry picked from commit 863c121c0782b82900d736f9f71dbcfa80f62e1d)
Signed-off-by: Domen Kožar <domen@dev.si>
Second attempt to resolve this issue. Copies stage1 image into expected
place manually. This has been improved in rkt master where there is a
configure option for specifying the location of this file. Can update
when next stable rkt is released.
The rkt build process requires a stage1 image. By default it will try
and download one with wget from coreos.com during the build. This change
explicitly downloads the image using `fetchurl`, verifying checksum,
then passes that to the build using appropriate configure flag.
Using $storepath/sbin is deprecated according to commit 98cedb3, so
let's avoid putting anything in .../sbin for the guest additions.
This is a continuation of the initial commit done by @ctheune at
1fb1360, which unfortunately broke VM tests and only changed the path of
the mount.vboxsf helper.
With this commit, the VM test is fixed and I've also verified on my
machine that it is indeed working again.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This places mount.vboxsf in $out/bin instead of sbin, because as
reported in #9063 it seems that the the mount tools are no longer
looking into $storepath/sbin/mount.$what but into
$storepath/bin/mount.$what instead.
However, I haven't found any commit which changes this behavior and
couldn't reproduce it. Also, merging this will break the VirtualBox
tests, but I'm merging it anyway in an effort to remove $storepath/sbin
from virtualboxGuestAdditions entirely.
Tested against virtualbox NixOS VM test, which of course failed as said
before.
