This tool is necessary in order to update the firmware of the secoder.
The reason I've added this to a separate output "tools" is because it
clearly is not relevant for the PCSC driver itself and it's also very
rarely needed.
I've also verified wether the closure of the PCSC plugin env still only
contains the main output and that's the case.
There are also other tools - cjBingoTest and cjgeldkarte, where the
former doesn't compile due to cjeca32.h not being found and cjgeldkarte,
which does compile but tries to dlopen() the library and subsequently
fails.
Both of these tools however look like they're just performing tests and
are not very useful outside of development, so I opted to not include
them.
Signed-off-by: aszlig <aszlig@nix.build>
3.99.5_SP12:
* Add support for cyberJack one MF
3.99.5_SP11:
* Add support for cyberJack one
3.99.5_SP10:
* Add support for SHUReader and SISReader
* Update to the Reiner-SCT repository rev cyberJack@1305
Signed-off-by: aszlig <aszlig@nix.build>
/cc @Ericson2314
PR was https://github.com/NixOS/nixpkgs/pull/46857
This line broke MacOS cross compilation. paxctl cannot be built on
macOS. Maybe it can be fixed, but no reason to break things
unnecessarily.
Regardless, you definitely need to be more careful about backporting.
I think it’s fine to move fast and break things on master but
with release-18.09 we should be more careful. Something like more
automated testing for cross compilation would also be
helpful (hopefully even making it block).
(cherry picked from commit f9c4075873cb56464126f993d22a1a72f7cfac45)
/cc @Ericson2314
This line broke MacOS cross compilation. paxctl cannot be built on
macOS. Maybe it can be fixed, but no reason to break things
unnecessarily.
Regardless, you definitely need to be more careful about backporting.
I think it’s fine to move fast and break things on master but
with release-18.09 we should be more careful. Something like more
automated testing for cross compilation would also be
helpful (hopefully even making it block).
Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:
{ config, lib, ... }:
{
options.foo = lib.mkOption {
type = lib.types.bool;
default = true;
description = "...";
};
options.bar = lib.mkOption {
type = lib.types.bool;
default = false;
description = "...";
};
config = lib.mkMerge [
(lib.mkIf config.bar {
system.build.bar = "foobar";
})
(lib.mkIf config.foo {
assertions = lib.singleton {
assertion = config.bar;
message = "Bar needs to be enabled";
};
systemd.services.foo = {
description = "Foo";
serviceConfig.ExecStart = config.system.build.bar;
};
})
];
}
This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.
The original pull request references a breakage due to the following:
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.
Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.
