let aaru = "aa-remove-unknown"; in
aaru tests whether /sys/kernel/security/apparmor/profiles can be opened.
Even though the file's permissions usually are 0444, open() still might
return `EPERM`, as this is a virtual filesystem. Thus, using `test -r`
doesn't suffice for this check.
What aaru does to solve this is (approximately)
if ! read … < /sys/kernel/security/apparmor/profiles; then
echo "Meh";
fi
In principal this works just fine. When looking closer, it doesn't
(which is the root cause of #273164). Careful readers will notice that
the actual access check (for `open()`) isn't actually related to the
`read` invocation, but the shell's input redirection, which works
totally fine:
If the file can't be opened, the shell will return an error and the test
fails. `read` won't even be invoked. The culprit is, the `read` shell
builtin might potentially jeopardize the *successful* test result
(`open()` succeeding): When no profiles are loaded, the file will be
empty and `read` will return 1 for `EOF`.
As the `if`'s command is only invoked after the actual test succeeded,
`true` is the command of choice here.
I would prefer fixing this upstream, but I refuse to register an account
there because GitLab.com wants me to validate an email address (sure), a
phone number (why?) and a valid payment method ([redacted]).
This fixes#273164 (»Apparmor service fails to start after nixos-rebuild
switch«).
With buildPythonApplication the PYTHONPATH is now populated properly,
which should address the ModuleNotFoundError issue.
I also moved some of the substitutions from postInstall to prePatch, so
they don't conflict with the wrapped executables.
Because upstream does not seem to hardcode binary paths in the utils
anymore, some of the old substituteInPlace rules could be removed.
Partial fix for nixpkgs#169056
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
