| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
The motivation for this change is the following: As gnu-netcat,
e. g. does not support ipv6, it is not suitable as default netcat.
This commit also fixes all obvious build issues caused by this change.
|
| |\
| |
| |
| |
| | |
The split needs more time to finish rebuilding,
but the rest seems OK and there are security fixes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`stripHash` documentation states that it prints out the stripped name to
the stdout, but the function stored the value in `strippedName`
instead.
Basically all usages did something like
`$(stripHash $foo | echo $strippedName)` which is just braindamaged.
Fixed the implementation and all invocations.
|
| |/
|
|
|
|
|
|
|
|
| |
bring back ls_tar
replace goPackages with go
don't hardcode /nix/store in vmTools
more docs
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This allows the QEMU VM's to use the /dev/random device, by
getting entropy from the host.
|
| |
|
|
| |
This is blocking the channel update: #16949
|
| |
|
|
|
|
| |
Introduced by mistake
This reverts commit e71a5cb87841f0af4a2279517b77a9a07ba394c0.
|
| |
|
|
|
|
|
|
|
| |
stripHash uses a global variable to communicate it's computation
results, but it's not necessary. You can just pipe to stdout in a
subshell. A function mostly behaves like just another command.
baseHash() also introduces a suffix-stripping capability since it's
something the users of the function tend to use.
|
| | |
|
| |\
| |
| | |
Escape all shell arguments uniformly
|
| | | |
|
| |/
|
|
| |
(cherry picked from commit fd60751ce0c85427423b78d8a46c3f78d65bd0e2)
|
| | |
|
| |
|
|
|
| |
(cherry picked from commit 2cf5dcd99a7d3aac8a39ab98c1738454dfa20bfb)
Signed-off-by: Domen Kožar <domen@dev.si>
|
| |
|
|
|
| |
(cherry picked from commit 00df301ac2fd1818fa1f96debcee23dbb979834d)
Signed-off-by: Domen Kožar <domen@dev.si>
|
| | |
|
| | |
|
| |
|
|
|
| |
The former is deprecated and doesn't handle compressed kernel modules,
so all current usages of it are broken.
|
| |\
| |
| |
| |
| |
| | |
Comparison to master evaluations on Hydra:
- 1255515 for nixos
- 1255502 for nixpkgs
|
| | |
| |
| |
| | |
Their in-place updates break download hashes...
|
| | |
| |
| |
| |
| | |
It's nice to be able to create disk images with -smp 4
in qemu.
|
| |\|
| |
| |
| |
| |
| | |
This is mainly to get the update of bootstrap tools.
Otherwise there were mysterious segfaults:
https://github.com/NixOS/nixpkgs/pull/7701#issuecomment-203389817
|
| | |
| |
| |
| | |
I don't think it's unsafe, if it's meant for nix expressions.
|
| | | |
|
| |\|
| |
| |
| |
| | |
Beware that stdenv doesn't build. It seems something more will be needed
than just resolution of merge conflicts.
|
| | |
| |
| |
| | |
nixpkgs repository.
|
| |\|
| |
| |
| |
| | |
The kde-5 stuff still didn't merge well.
I hand-fixed what I saw, but there may be more problems.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some recent perl version introduced "keys" to return the keys
in random order. As some of the packages are solved by "provides" and
based on the order, this randomness affects what packages get into the
closure.
This problem may be in other nix perl scripts.
|
| | |
| |
| |
| |
| | |
This commit packages qemu-220. This package is qemu-2.2.0
and is only used with Azure.
|
| |\| |
|
| | | |
|
| | | |
|
| |\|
| |
| |
| |
| | |
TODO: there was more significant refactoring of qtbase and plasma 5.5
on master, and I'm deferring pointing to correct outputs to later.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This seems to be the root cause of the random page allocation failures
and @wizeman did a very good job on not only finding the root problem
but also giving a detailed explanation of it in #10828.
Here is an excerpt:
The problem here is that the kernel is trying to allocate a contiguous
section of 2^7=128 pages, which is 512 KB. This is way too much:
kernel pages tend to get fragmented over time and kernel developers
often go to great lengths to try allocating at most only 1 contiguous
page at a time whenever they can.
From the error message, it looks like the culprit is unionfs, but this
is misleading: unionfs is the name of the userspace process that was
running when the system ran out of memory, but it wasn't unionfs who
was allocating the memory: it was the kernel; specifically it was the
v9fs_dir_readdir_dotl() function, which is the code for handling the
readdir() function in the 9p filesystem (the filesystem that is used
to share a directory structure between a qemu host and its VM).
If you look at the code, here's what it's doing at the moment it tries
to allocate memory:
buflen = fid->clnt->msize - P9_IOHDRSZ;
rdir = v9fs_alloc_rdir_buf(file, buflen);
If you look into v9fs_alloc_rdir_buf(), you will see that it will try
to allocate a contiguous buffer of memory (using kzalloc(), which is a
wrapper around kmalloc()) of size buflen + 8 bytes or so.
So in reality, this code actually allocates a buffer of size
proportional to fid->clnt->msize. What is this msize? If you follow
the definition of the structures, you will see that it's the
negotiated buffer transfer size between 9p client and 9p server. On
the client side, it can be controlled with the msize mount option.
What this all means is that, the reason for running out of memory is
that the code (which we can't easily change) tries to allocate a
contiguous buffer of size more or less equal to "negotiated 9p
protocol buffer size", which seems to be way too big (in our NixOS
tests, at least).
After that initial finding, @lethalman tested the gnome3 gdm test
without setting the msize parameter at all and it seems to have resolved
the problem.
The reason why I'm committing this without testing against all of the
NixOS VM test is basically that I think we can only go better but not
worse than the current state.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |\| |
|
| | | |
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While debugging an issue with running NixOps tests, I found out that the
output from debClosureGenerator is not deterministic.
The reason behind this is the way how Provides and Replaces fields are
handled. I haven't yet found out what's the exact issue, but so far
packages "Provides" are more or less picked at random.
So, running the NixOps Hetzner tests we get either mawk, original-awk or
gawk altering on every invocation.
While for the test it isn't poisionous whether wi have mawk or gawk,
having original-awk certainly is, because live-build only works with
mawk or gawk.
The best solution would obviously be to make debClosureGenerator
deterministic, but in the case of "Provides: awk", we can safely pick
mawk by default, because the latter has a "Priority: required" in its
package description.
This also has the advantage that we can safely cherry-pick this to
release-15.09 because it's very unlikely that we'll break the
debClosureGenerator by adding a dependency to commonDebPackages.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | | |
|
| | |
| |
| |
| | |
http://hydra.nixos.org/build/26480662
|
| |\|
| |
| |
| | |
Many non-conflict problems weren't (fully) resolved in this commit yet.
|
| | | |
|
| | |
| |
| |
| | |
This prevents programs from hanging while trying to read from stdin.
|
| | | |
|