The file is an example makefile for developing bash plugins, and
contains stuff like:
````
example: example.o
$(SHOBJ_LD) $(SHOBJ_LDFLAGS) $(SHOBJ_XLDFLAGS) -o $@ example.o $(SHOBJ_LIBS)
````
So no package is really going to depend on that, and it's making the
.dev output keep a reference to the bootstrap tools. Just nuke it.
This reverts commit 9f86136cef.
Rust is nowadays required for building Firefox, so the channel updates
are blocked on this.
(It also builds fine for me.)
This reverts commit c0cef0425e.
The output of the command-line tool has changed somewhat and at least
nixos-generate-config.pl needs modifications to match. I'm leaving that
to someone who knows a bit more about btrfs.
Issue #24810.
There was one confusing recent failure of this:
http://cache.nixos.org/log/myla8bc17j8spmifdxmrz9jswxwsf5w6-vm-test-run-hibernate.drv
I don't have any real ideas on what could cause the problem but there is
at least one theoretical one: the system starts hibernating before the
listener process manages to open the TCP port for listening, and it can't
open it after resuming because not enough pages from the netcat binary
have been paged in (and as the 9p filesystem holding it is now toast,
they can't be loaded anymore).
Commit 9b049849bf deleted the patch file
(and reference to it from fontconfig default.nix), but left the one in
2.10.nix which break evaluation.
As the package seems to build fine without the patch, just remove the
reference.
cc @ttuegel in case this was not the correct thing to do.
Currently, if you try to build a NixOS config including channel.nix, e.g.:
nix-build -I nixpkgs=. -I nixos-config=nixos/modules/installer/cd-dvd/installation-cd-minimal.nix nixos -A config.system.build.isoImage
twice in a row, you end up with two different build results. This is
caused by the 'result' symlink of the first build affecting the channel
contents of the second build.
If we use filterSource with a predicate that ignores the 'result'
symlinks, the problem is gone. Do the same thing for VIM/Emacs
swap/backup files to avoid even more 'spurious' rebuilds.
Additionally, filter out the '.git' directory at the same time, as we
'rm -rf' it from the result anyway. This avoids a considerable amount of
unnecessary file I/O copying and deleting the .git directory.
This reverts commit b806e25d65.
This seems to push Hydra's memory usage out of the roof fail nixos
evaluating with:
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
Let's revert this for now. It's not a big deal at all since the
nixpkgs-unstable jobset is still building the packages.
Because if you don't, the configure script assumes that your getcwd()
function is broken. Which then makes bash use it's own getcwd()
implementation, which doesn't work if the path to the current directory
contains bind mounts in its paths. This shows up as:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Bad file descriptor
... and fails the aarch64 glibc build with sandboxes enabled.
Sigh.
Because if you get it wrong, you get a very confusing error message at
the end of the kernel build, which is quite painful as the build can
take a long time.
This reverts commit a5f4e22289.
Breaks the stdenv build, e.g.: http://hydra.nixos.org/build/50015717
In general, the architectures are different enough that there is no
reason to consider both as ARM, just like we don't consider x86_64 as
32-bit x86.
cc @fpletz
When not cross compiling, nativeBuildInputs and buildInputs have
identical behaviour. Currently that is implemented by having
mkDerivation do a concatenation of those variables in Nix code and pass
that to the builder via the nativeBuildInputs attribute.
However, that has some annoying side effects, like `foo.buildInputs`
evaluating to `[ ]` even if buildInputs were specified in the nix
expression for foo.
Instead, pass buildInputs and nativeBuildInputs in separate variables as
usual, and move the logic of cross compilation vs. native compilation to
the stdenv builder script. This is probably a tiny bit uglier but
fixes the previous problem.
Issue #4855.
The upstream release is from 2004. The website of this software talks
about configuring XFree86. I *highly* doubt this software is of any use
nowadays.
It fails with hardening-related errors like:
reloc.o: In function `.L41':
reloc.c:(.text+0x452): undefined reference to `__stack_chk_fail_local'
... and several others as well!
Since nobody has noticed that this package has been broken the entire
16.09 release, it's probably not worth to try fixing it.
(Note that this is a different package from memtest86plus!)
This way we have the benefit of the usual Nixpkgs style, and gain a
slight reduction in amount of code in the updater.
Also use callPackage to reduce duplication of the dependencies of the
update script and use makeBinPath to make things neater.
Adds a script to help automatically upgrading packages: this one can
patch name/version attributes like:
version = "50.1.0";
name = "bc-1.06";
... to the given version, and updates the sha256 hash to match.
Usage is:
update-source-version <attr> <new-version> [<new-source-hash>]
where:
- attr is the attribute path of the package
- new-version is the version string to be patched in
- new-source-hash is the optional sha256/etc. hash of the source.
If not given, the script will automatically calculate it.
This is added to a subdirectory where other useful scripts can be added
in the future, like figuring out the newest version from a git repo or
GitHub releases etc.
Tuomas Tynkkynen