The test only checked for existence of the rule file in the output path
of the rulefile generator.
However, we also need to check whether the basename of the file is also
the one we're currently searching for.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's the same as openalSoft (same package source and version). I suppose it
contained original Creative open-source OpenAL implementation some time ago, but
then it changed and nobody noticed. It's referenced nowhere, anyway.
This update was generated by hackage2nix v20151217-10-ga610b1b using the following inputs:
- Nixpkgs: e9a140b725
- Hackage: 346d9f8466
- LTS Haskell: 6661045692
- Stackage Nightly: 0ad9eda835
CipherScan is a simple way to find out which SSL ciphersuites are
supported by a target.
It can take advantage of the extra features in Peter Mosmans' openssl
fork (which is also included in this commit).
Currently the check against FHS paths in the rule files is only checking
against the original paths from in services.udev.packages.
However we do fix up some of these paths in the udev rules generator and
the warning is against the unfixed rule files and therefore prints a lot
of false positives.
This pull request not only improves this warning but also makes the
rules generator fail if there are FHS still left in one of the rules
file.
Addresses #12722 as well so we can assure that this won't happen again
in the future.
Partially reverts the following commits:
9f2a61c59cc4e4ce278e6582cb4bdca9c2088755
9c13fe6604358e5255457422acbe8e03734f1e44
As @edolstra pointed out, it would make more sense to do this by default
instead of having that allowImpurePaths option. This of course might
break systems which add extra packages to udev, but on the upside it's
hard to miss one of these paths now because it won't get buried in the
ocean of build output lines.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
