I've built this a lot of times on different machines without getting
compile errors, so I'd assume this to be safe. Of course, the compile
time is very small in comparison to bigger packages but it's still an
annoyance to wait for up to a few minutes, especially during
development.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far it was only possible to run john if you've either copied over the
default configuration over to ~/.john and substitute $JOHN with the
right path or set $JOHN to the store path directly.
Both methods are not really a very good user experience, so we're now
patching in the resulting paths into the default rules/configurations.
This also splits off configuration files into $out/etc/john instead of
putting everything into $out/share/john and now also properly installs
the auxiliary programs into $out/bin.
Closes#8792.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
Cc: @offlinehacker
It prevents john from running with older CPUs such as Core2Duo and gives
an illegal hardware instruction error on these CPUs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cleanups are mostly stylistic, like putting src more to the top (to make
sure it won't be missed on updates of the version attribute) or using
mkdir -p instead of ensureDir.
The most significant change here is that we update the package to
1.8.0-jumbo-1, which is the latest tag available and contains community
updates which were already in magnumripper/JohnTheRipper@93f061bc41.
We're now also using fetchurl to ensure that we don't need to clone the
whole repository and keep download times low.
And the derivation name is now "john" instead of "JohnTheRipper",
because most users would expect "nix-env -i john" to work.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changes to the build system required adjusting many packages'
dependencies. On the Nixpkgs side, we no longer propagate the dependency
on cmake (to reduce closure size), so downstream dependencies had to be
adjusted for most packages that depend on kdelibs.
Account for a zany new build system & add myself as a maintainer.
Tested by connecting to a remote system and browsing the web & LAN,
both as root and a regular (sudo) user. Cool tool.
CC @iElectric
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
- upgrade 106 -> 108
- fix passphrase rewrapper (password changing should now work fine) as
discussed on https://bugs.launchpad.net/ecryptfs/+bug/1486470
- add lsof dependency so ecryptfs-migrate-home should work out of the
box
