Build various tools from the coreboot tree with a generic builder for better
maintainability and provide a buildEnv with all of them, similar to other
distributions' coreboot-utils package.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Update conmon to v0.2.0 and move it into a dedicated package. Since we
are now using conmon as dedicated package, cri-o does not need to built
it, too.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
A recent upgrade of cargo-vendor changed its output slightly, which
broke all cargoSha256 hashes in nixpkgs.
See https://github.com/NixOS/nixpkgs/issues/60668 for more information.
Since then, a few hashes have been fixed in master by hand, but there
were a lot still to do, so I did all of the ones left over with some
scripts I wrote.
The one hash I wasn’t able to update was habitat's, because it’s
currently broken and the build doesn’t get far enough to produce a
hash anyway.
It seems to be broken upstream too, and fixing it is far down the
priority list:
https://www.virtualbox.org/pipermail/vbox-dev/2017-June/014561.html
Additionally, 3d support seems to rely on VBoxOGL.so being symlinked
from libGL.so (which we can't), and Oracle doesn't plan on supporting
libglvnd either. (#18457)
This commits adds the CRI-O package, which includes the `crio` binary as
well as `conmon` and `pause`. The configuration is not part of this
package because it would be included in a service.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
gnupg is gnupg 2.2. gnupg1 is also gnupg 2.2, just with a few extra
symlinks in the bin directory. None of these packages need those
symlinks, and it's confusing for them to say they're depending on
"gnupg1", so switch their dep to plain "gnupg".
Quite some fixing was needed to get this to work.
Changes in VirtualBox and additions:
- VirtualBox is no longer officially supported on 32-bit hosts so i686-linux is removed from platforms
for VirtualBox and the extension pack. 32-bit additions still work.
- There was a refactoring of kernel module makefiles and two resulting bugs affected us which had to be patched.
These bugs were reported to the bug tracker (see comments near patches).
- The Qt5X11Extras makefile patch broke. Fixed it to apply again, making the libraries logic simpler
and more correct (it just uses a different base path instead of always linking to Qt5X11Extras).
- Added a patch to remove "test1" and "test2" kernel messages due to forgotten debugging code.
- virtualbox-host NixOS module: the VirtualBoxVM executable should be setuid not VirtualBox.
This matches how the official installer sets it up.
- Additions: replaced a for loop for installing kernel modules with just a "make install",
which seems to work without any of the things done in the previous code.
- Additions: The package defined buildCommand which resulted in phases not running, including RUNPATH
stripping in fixupPhase, and installPhase was defined which was not even run. Fixed this by
refactoring using phases. Had to set dontStrip otherwise binaries were broken by stripping.
The libdbus path had to be added later in fixupPhase because it is used via dlopen not directly linked.
- Additions: Added zlib and libc to patchelf, otherwise runtime library errors result from some binaries.
For some reason the missing libc only manifested itself for mount.vboxsf when included in the initrd.
Changes in nixos/tests/virtualbox:
- Update the simple-gui test to send the right keys to start the VM. With VirtualBox 5
it was enough to just send "return", but with 6 the Tools thing may be selected by
default. Send "home" to reliably select Tools, "down" to move to the VM and "return"
to start it.
- Disable the VirtualBox UART by default because it causes a crash due to a regression
in VirtualBox (specific to software virtualization and serial port usage). It can
still be enabled using an option but there is an assert that KVM nested virtualization
is enabled, which works around the problem (see below).
- Add an option to enable nested KVM virtualization, allowing VirtualBox to use hardware
virtualization. This works around the UART problem and also allows using 64-bit
guests, but requires a kernel module parameter.
- Add an option to run 64-bit guests. Tested that the tests pass with that. As mentioned
this requires KVM nested virtualization.
In Linux 4.19 there has been a major rework of the overlayfs
implementation and it now opens files in lowerdir with O_NOATIME, which
in turn caused issues in our VM tests because the process owner of QEMU
doesn't match the file owner of the lowerdir.
The crux here is that 9p propagates the O_NOATIME flag to the host and
the guest kernel has no way of verifying whether that flag will lead to
any problems beforehand.
There is ongoing work to possibly fix this in the kernel, but it will
take a while until there is a working patch and consensus.
So in order to bring our default kernel back to 4.19 and of course make
it possible to run newer kernels in VM tests, I'm merging a small QEMU
patch as an interim solution, which we can drop once we have a working
fix in the next round of stable kernels.
Now we already had Linux 4.19 set as the default kernel, but that was
subsequently reverted in 048c36ccaa
because the patch we have used was the revert of the commit I bisected a
while ago.
This patch broke overlayfs in other ways, so I'm also merging in a VM
test by @bachp, which only tests whether overlayfs is working, just to
be on the safe side that something like this won't happen in the future.
Even though this change could be considered a moderate mass-rebuild at
least for GNU/Linux, I'm merging this to master, mainly to give us some
time to get it into the current 19.03 release branch (and subsequent
testing window) once we got no new breaking builds from Hydra.
Cc: @samueldr, @lheckemann
Fixes: https://github.com/NixOS/nixpkgs/issues/54509
Fixes: https://github.com/NixOS/nixpkgs/issues/48828
Merges: https://github.com/NixOS/nixpkgs/pull/57641
Merges: https://github.com/NixOS/nixpkgs/pull/54508
Our VM tests and everything related to our virtualisation infrastructure
is currently broken if used with kernel 4.19 or later.
The reason for this is that since 4.19, overlayfs uses the O_NOATIME
flag when opening files in lowerdir and this doesn't play nice with the
way we pass the Nix store to our QEMU guests.
On a NixOS system, paths in the Nix store are typically owned by root
but the QEMU process is usually run by an ordinary user. Using O_NOATIME
on a file where you're not the owner (or superuser) will return with
EPERM (Operation not permitted).
This is exactly what happens in our VM tests, because we're using
overlayfs in the guests to allow writes to the store.
Another implication of this is that the default kernel version for NixOS
19.03 has been reverted to Linux 4.14.
Work on getting this upstream is still ongoing and the patch I posted
previously was incomplete, needs rework and also some more review from
upstream maintainers - in summary: This will take a while.
So instead of rushing in a kernel patch to nixpkgs, which will affect
all users of overlayfs, not just NixOS VM tests, I opted to patch QEMU
for now to ignore the O_NOATIME flag in 9p.
I think this is also the least impacting change, because even if you
care about whether access times are written or not, you get the same
behaviour as with Linux 4.19 in conjunction with QEMU.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: https://github.com/NixOS/nixpkgs/issues/54509
nvidia_x11 and persistenced were modified to provide binaries which can be
mounted inside a docker-container to be executed there.
most ldconfig-based discovery of bundled nvidia libraries is patched out
ldconfig itself is patched to be able to deal with patchelf'ed libraries
See https://sourceware.org/bugzilla/show_bug.cgi?id=23964
Removes the `-i` from the `go build` commands. Once the PR is merged
and released, this patch won't be required anymore.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
podman is a binary build from libpod : libpod is a library used to
create container pods. podman aims to be *almost* compatible with the
docker cli but doesn't require a docker daemon.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
This currently uses a binary-only package, since building
jailer/firecracker all on their own is somewhat complex from my
attempts.
This will later be changed into a source-only build, ideally.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
… and add man pages, which means `containerd` becomes a multi-output
derivation : `containerd.bin` and `containerd.man`.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
It does not work if the sha256 is not hex, it fails because VBoxExtPackHelperApp requires to be given a hex hash.
See https://github.com/NixOS/nixpkgs/issues/34846 where the same problem was fixed some time ago.
I had to drop xorriso because it didn't seem to want to compile with it
any more, and had to add libopus as a build input because it wouldn't
compile without that.
You can use stdenv.hostPlatform.emulator to get an executable that
runs cross-built binaries. This could be any emulator. For instance,
we use QEMU to emulate Linux targets and Wine to emulate Windows
targets. To work with qemu, we need to support custom targets.
I’ve reworked the cross tests in pkgs/test/cross to use this
functionality.
Also, I’ve used talloc to cross-execute with the emulator. There
appears to be a cross-execute for all waf builds. In the future, it
would be nice to set this for all waf builds.
Adds stdenv.hostPlatform.qemuArch attrbute to get the qemuArch for
each platform.
In a few cases it wasn't clear so I left them as-is.
While visiting these moved other things to nativeBuildInputs
when it was clear they were one of these cases:
* makeWrapper
* archive utilities (in order to unpack src)
* a few of these might no longer be needed but leaving for another day
Unlike docker (cli only) this probably won't work on darwin.
github.com/docker/libnetwork/networkdb
can't load package: package github.com/docker/libnetwork/ns: build constraints exclude all Go files in /private/tmp/nix-build-docker-proxy-7b2b1feb1de4817d522cc372af149ff48d25028e.drv-0/go/src/github.com/docker/libnetwork/ns
/cc ZHF #45961
Since years I'm not maintaining anything of the list below other
than some updates when I needed them for some reason. Other people
is doing that maintenance on my behalf so I better take me out but
for very few packages. Finally!
This makes the command ‘nix-env -qa -f. --arg config '{skipAliases =
true;}'’ work in Nixpkgs.
Misc...
- qtikz: use libsForQt5.callPackage
This ensures we get the right poppler.
- rewrites:
docbook5_xsl -> docbook_xsl_ns
docbook_xml_xslt -> docbook_xsl
diffpdf: fixup
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/singularity/versions.
<details><summary>Version release notes (from GitHub)</summary>
Greetings Singularity containerizers!
This release contains fixes for a _high severity_ security issue affecting Singularity 2.3.0 through 2.5.1 on kernels that support overlay file systems (CVE-2018-12021). A malicious user with network access to the host system (e.g. ssh) could exploit this vulnerability to access sensitive information on disk and bypass directory image restrictions like those preventing the root file system from being mounted into the container.
Singularity 2.5.2 should be installed immediately, and all previous versions of Singularity should be removed. The vulnerability addressed in this release affects kernels that support overlayfs. If you are unable to upgrade immediately, you should set `enable overlay = no` in `singularity.conf`.
In addition, this release contains a large number of bug fixes. Details follow:
## [Security related fixes](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12021)
- Removed the option to use overlay images with `singularity mount`. This
flaw could allow a malicious user accessing the host system to access
sensitive information when coupled with persistent ext3 overlay.
- Fixed a race condition that might allow a malicious user to bypass directory
image restrictions, like mounting the host root filesystem as a container
image
## Bug fixes
- Fix an error in malloc allocation #1620
- Honor debug flag when pulling from docker hub #1556
- Fix a bug with passwd abort #1580
- Allow user to override singularity.conf "mount home = no" with --home option
#1496
- Improve debugging output #1535
- Fix some bugs in bind mounting #1525
- Define PR_(S|G)ET_NO_NEW_PRIVS in user space so that these features will
work with kernels that implement them (like Cray systems) #1506
- Create /dev/fd and standard streams symlinks in /dev when using minimal dev
mount or when specifying -c/-C/--contain option #1420
- Fixed * expansion during app runscript creation #1486
As always, please report any bugs to:
https://github.com/singularityware/singularity/issues/new</details>
These checks were done:
- built on NixOS
- /nix/store/3igwiqi311c18w13y5r7zrgpcnzylg9l-singularity-2.5.2/bin/singularity passed the binary check.
- Warning: no invocation of /nix/store/3igwiqi311c18w13y5r7zrgpcnzylg9l-singularity-2.5.2/bin/run-singularity had a zero exit code or showed the expected version
- 1 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 2.5.2 with grep in /nix/store/3igwiqi311c18w13y5r7zrgpcnzylg9l-singularity-2.5.2
- directory tree listing: https://gist.github.com/ed6db09ad43a19c6abf2d35d15ef489c
- du listing: https://gist.github.com/9bd23f4d6ee86a9eb2ba7ec5c986741d
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
I no longer use rancher and can test this derivation.
Also rancher-compose should have the same version as the rancher cluster
used. So it is better to be build by the user using it rather having a
random version in nixpkgs.
