The original build broke with the following linker issue:
```
CXXLD _PythonMagick.la
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: cannot find -l-L/nix/store/4gh6ynzsd5ndx37hmkl62xa8z30k43y1-imagemagick-6.9.9-34/lib
collect2: error: ld returned 1 exit status
```
This happens since `BOOST_PYTHON_LIB` wasn't set properly, however
`_PythonMagick.la` was linked with `-l$(BOOST_PYTHON_LIB)
$(MAGICK_LIBS)`. With an empty `BOOST_PYTHON_LIB` the linker got
confused.
To work around this, the `boost` library directory needs to be specified
explicitly. To ensure that the changes take effect, the original
`configure` script shipped with `$src` needs to be removed and recreated
using the `autoreconfHook`.
Additionally the `imagemagick` license (https://spdx.org/licenses/ImageMagick.html)
needs to be added to `lib/licenses.nix` to document the proper license
of `pythonmagick` in the meta section.
This has been not touched in 6 years. Let's remove it to cause less
problems when adding new cross-compiling infrastructure.
This also simplify gcc significantly.
- moved function into strings.nix
- renamed function from makePerl5Lib
- removed duplicates entries in the resulting value
- rewrote the function from scratch after learning a few things (much cleaner now)
Another attempt after my sloppy 48ccdf322d.
@Infinisil, thanks again, reverted in 4794aa5de2 and explained my mistakes in 48ccdf322d (commitcomment-29678643). I start with their work and provide this proof of this commit's correctness:
```nix
(lib.fixedPoints.extends (lib.flip g) f) # now
((f: rattrs: self: let super = rattrs self; in super // f self super) (lib.flip g) f) # inline extends
(self: let super = f self; in super // (lib.flip g) self super) # beta reduce
(self: let super = f self; in super // g super self) # beta reduce
(self_: let super = f self_; in super // g super self_) # alpha rename
(self_: let super = f self_; in super // g super self_) # original, same
```
Eventually we might harmonize `overrideScope`'s `g` parameter with the general pattern, but I leave that breaking change as a separate step. Best not to refactor and break at once, and at least the abstractions make the oddity clearer.
$ nix repl lib
Welcome to Nix version 2.0.2. Type :? for help.
Loading 'lib'...
Added 350 variables.
-- this is the exact example from the function's documentation:
nix-repl> recursiveUpdateUntil (path: l: r: path == ["foo"]) {
# first attribute set
foo.bar = 1;
foo.baz = 2;
bar = 3;
} {
#second attribute set
foo.bar = 1;
foo.quz = 2;
baz = 4;
}
{ bar = 3; baz = 4; foo = { bar = 1; baz = 2; quz = 2; }; }
-- although the documentation says:
{
foo.bar = 1; # 'foo.*' from the second set
foo.quz = 2; #
bar = 3; # 'bar' from the first set
baz = 4; # 'baz' from the second set
}
binutils expects x86_64-unknown-netbsd<version> (only 3 parts!). Any other combo seems to fail.
Also handle darwin versions similarly.
/cc @Ericson2314
* The ELK stack is upgraded to 6.3.2.
* `elasticsearch6`, `logstash6` and `kibana6` now come with X-Pack which is
a suite of additional features. These are however licensed under the unfree
"Elastic License".
* Fortunately they also provide OSS versions which are now packaged
under: `elasticsearch6-oss`, `logstash6-oss` and `kibana6-oss`.
Note that the naming of the attributes is consistent with upstream.
* The test `nix-build nixos/tests/elk.nix -A ELK-6` will test the OSS
version by default. You can also run the test on the unfree ELK using:
`NIXPKGS_ALLOW_UNFREE=1 nix-build nixos/tests/elk.nix -A ELK-6 --arg enableUnfree true`
Nix now supports floats & we can pretty easily map them to Plist’s
<real></real> type. Note that I am unsure how this affects older
version of Nix that may or may not have builtins.isFloat available.
Make sure this satisfies minver.nix’s "1.11" requirement.
Instead of using a string to describe kernel config, use a nix
attribute set, then converted to a string.
- allows to override the config, aka convert 'yes' into 'modules' or
vice-versa
- while for now merging different configs is still crude (last spec wins),
at least there should be only one CONFIG_XYZ value compared to the current string
config where the first defined would be used and others ignored.
[initial idea by copumpkin in 2016, a major rebase to 2018 by teto]
It wasn’t exactly clear which NDK you were using previously. This adds
an attribute to system that handles what version of the NDK we should
use when building things.
/cc @Ericson2314
Before this change `mkRenamedOptionModule` would override option defaults
even when the old option name is left unused. For instance
```nix
{
optios = {
services.name.new = mkOption {
default = { one = {}; };
};
};
imports = [
(mkRenamedOptionModule [ "services" "name" "old" ] [ "services" "name" "new" "two" ])
];
config = {};
}
```
would evaluate to
`{ config.services.name.new = { two = {}; }; }`
when you'd expect it to evaluate to
`{ config.services.name.new = { one = {}; }; }`.
In particular, now the mainline kernel can be built on the RPi 1 as well
(so kernelBaseConfig should always be a mainline defconfig from now on).
And RPi 2 users can now use linux_rpi without doing the
`nixpkgs.config.platform = lib.systems.platforms.raspberrypi2;` dance.
toPath has confusing semantics and is never necessary; it can always
either just be omitted or replaced by pre-concatenating `/.`. It has
been marked as "!!! obsolete?" for more than 10 years in a C++
comment, hopefully removing it will let us properly deprecate and,
eventually, remove it.
There are two different official variations which differ in their float
support, so such a blanket statement is invalid.
`lib.systems.platforms.*android` already handles each case correctly.
Correcting an error in 827ef09140.
ARM ABIs now have a float field. This is used as a fallback to lessen
our use of `platform.gcc.float`. I didn't know what the MIPs convention
is so I kept using `platform.gcc.float` in that case.
Assigning a list of 10 or more elements to an option having the type
`loaOf a` produces a configuration value that is not honoring the
order of the original list. This commit fixes this and a related issue
arising when 10 or more lists are merged into this type of option.
Without this change
(coercedTo str toInt int).check "foo"
would evaluate to true, even though
(coercedTo str toInt int).merge {} [{ value = "foo"; }]
will throw an error because "foo" can't be coerced to an int.
The commented-out configs are @shlevy's old known-good ones. I changed
them as needed to play nice with lib.systems.parse but did not test so
leaving them as comments for now.
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
The function isn’t used anywhere and `addErrorContext` is an undocumented
builtin.
The builtin is explicitely qualified at its two uses in the module system.
`attrNamesToStr` is very specific (and pretty trivial), so it doesn’t make sense
to have it in the library.
`traceXMLVal(Marked)` are just a builtin and `trace` and not very useful in
general (trace output should not be parsed anyway).
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
