We just talked about this in private. I don't use this anymore for
various reasons, but willibutz is a wee-slack user and
definetely a well-qualified replacement here.
On start, unicorn, sidekiq and other parts running ruby code emits
quite a few warnings similar to
/var/gitlab/state/config/application.rb:202: warning: already initialized constant Gitlab::Application::LOOSE_EE_APP_ASSETS
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/config/application.rb:202: warning: previous definition of LOOSE_EE_APP_ASSETS was here
/var/gitlab/state/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here
This seems to be caused by the same ruby files being evaluated
multiple times due to the paths being different - sometimes they're
loaded using the direct path and sometimes through a symlink, due to
our split between config and package data. To fix this, we make sure
that the offending files in the state directory always reference the
store path, regardless of that being the real file or a symlink.
We create a wrapper which launches gnome-shell with the correct environment and
cap_sys_nice.
We can then override gnome-shell-wayland.service to use this wrapper.
NOTE: We need to force clear the environment, because the defaults aren't good
for user services. That should probably be fixed.
In NixOS extra capabilities are provided through the ambient set which provides
real inheritability to user run processes [0].
We don't want gome-shell to spawn processes with cap_sys_nice however (apart
from the obvious this also breaks eg. flatpaks). So we drop inheritable when
starting to prevent further inheritance (the ambient set is only propagated
if inherit is set).
[0] https://github.com/torvalds/linux/commit/58319057b7847667f0c9585b9de0e8932b0fdb08
Instead of using execlineb to define the execlineb wrapper, we replace
it by a little C wrapper.
This is mainly done because on non-Linux systems (i.e. mainly macOS),
it is impossible for a shebang interpreter to be itself a shebang
script.
It is, however, perfectly fine to have a chain that goes
shebang -> ELF -> shebang -> ELF -> …
Co-Authored-By: Laurent Bercot <ska-skaware@skarnet.org>
The expression claimed there are differences between the release tarball and the tarball github packages from the tag but fetchFromGitHub literally downloads the same tarball.
While 9fe10288f0 ensured that the
ssh-keysign path is searched for in PATH if not absolute,
it doesn't prevent the configure script from defaulting to an
absolute path in $out/libexec, making the whole effort rather
pointless.
perl is a run-time dependency, so it should be in buildInputs rather
than nativeBuildInputs.
This has been preventing patchShebangsAuto() in fixupOutputHooks from
patching the /usr/bin/perl interpreter shebang in $out/bin/rrsync since
61bc03c017.
Resolves#71198
Jan Tojnar