From now on, only the testing branch of grsecurity will be supported.
Additionally, use only patches from upstream.
It's impossible to provide meaningful support for grsecurity stable.
First, because building and testing \(m \times n \times z) [1], packages
is infeasible. Second, because stable patches are only available from
upstream for-pay, making us reliant on third-parties for patches. In
addition to creating yet more work for the maintainers, using stable
patches provided by a third-party goes against the wishes of upstream.
nixpkgs provides the tools necessary to build grsecurity kernels for any
version the user chooses, however, provided they pay for, or otherwise
acquire, the patch themselves.
Eventually, we'll want to remove the now obsolete top-level attributes,
but leave them in for now to smoothe migration (they have been removed
from top-level/release.nix, though, because it makes no sense to have
them there).
[1]: where \(m\) is the number of grsecurity flavors, \(n\) is the
number of kernel versions, and z is the size of the `linuxPackages` set
* Perform HTTP HEAD request instead of full GET (lighter weight)
* Don't log output of curl to the journal (it's noise/debug)
* Use explicit http:// URL scheme
* Reduce poll interval from 10s to 2s (respond to state changes
quicker). Probably not relevant on boot (lots of services compete for
the CPU), but online service restarts/reloads should be quicker.
* Pass --fail to curl (should be more robust against false positives)
* Use 4 space indent for shell code.
The current postStart code holds Jenkins off the "started" state until
Jenkins becomes idle. But it should be enough to wait until Jenkins
start handling HTTP requests to consider it "started".
More reasons why the current approach is bad and we should remove it,
from @coreyoconnor in
https://github.com/NixOS/nixpkgs/issues/14991#issuecomment-216572571:
1. Repeatedly curling for a specific human-readable string to
determine "Active" is fragile. For instance, what happens when jenkins
is localized?
2. The time jenkins takes to initializes is variable. This (at least
used to) depend on the number of jobs and any plugin upgrades requested.
3. Jenkins can be requested to restart from the UI. Which will not
affect the status of the service. This means that the service being
"active" does not imply jenkins is initialized. Downstream services
cannot assume jenkins is initialized if the service is active. Might
as well accept that and remove the initialized test from service
startup.
Fixes#14991.
Regression introduced by dfe608c8a2ecfdf0ab2838a967440207250a0b95.
The commit turns the two arguments into one attrset argument so we need
to adapt that to use the new calling convention.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
