Add this hook to checkPhase to allow for running MPI application in
the sandbox. It detects the MPI implementations and sets the respective
environment variables.
The `name` & `version` attributes only existed in a previous form of
the API before it was switched over to using `fetchzip` &
`applyPatches`[1]. The attributes existed to be able to throw an
evaluation error with upgrade instructions when this was used. However,
this was before 22.11, so this shouldn't be in use anymore (and if
somebody is doing a migration from a very old NixOS, this is still
documented in the 22.11 release-notes[2]).
Anyways, this simplifies the code a little bit and also having both
`appName`/`appVersion` and `name`/`version` in there is quite confusing. But
still, I figured it's less confusing to not re-use attributes that were
deprecated in the past, hence the alternative naming.
[1] 3ca9b9a8ad
[2] d41b381310
This change makes sure that each Nextcloud plugin installed provides a
`meta` section with proper license information.
Unfortunately, the metadata from the appstore is useless for this
purpose since it doesn't differentiate between e.g. AGPL 3.x and AGPL
3.x or any later version. In fact, this isn't consistent between their
software, e.g. `bookmarks` has `agpl3Plus` according to the files'
headers[1] whereas `twofactor_nextcloud_notification` is AGPL 3 only[2].
I don't think there's any trivial and reasonable way to retrieve this
information programatically, so I decided to change the format of
`nextcloud-apps.json`[3] to also contain the license in the form of the
license attribute we have in `lib/licenses.nix`, i.e. GNU AGPL 3 or
later is `agpl3Plus`.
I retrieved the information using the following approach:
* go to the source code of $app at the revision we currently have
packaged
* check for a license identifier (does it specify the license only or
the license "or any later version")?
* first in `src/main.js` because most apps from Nextcloud itself used
actual spdx identifiers in the frontend's source-code.
* then in `lib/AppInfo/Application.php` which each Nextcloud app has.
License changes should be updated accordingly when updating the apps. As
with any other package in nixpkgs as well, this currently needs to be
done manually (or as part of the review process)[4].
Also, I decided to change the `name` of the `applyPatches` derivation
from `source-patched` to `nextcloud-app-${appName}-${appVersion}`. When
deploying a lot of apps (and probably displaying the diff using
`nix store diff-closures` on deploy), the current output isn't very
helpful. This is purely optional because I didn't want to break the
interface of `fetchNextcloudApp` again.
[1] https://github.com/nextcloud/bookmarks/blob/v13.1.0/lib/AppInfo/Application.php#L6
[2] https://github.com/nextcloud/twofactor_nextcloud_notification/blob/v3.7.0/lib/AppInfo/Application.php
[3] This isn't really well-defined since it's preprocessed with `jq(1)`
before passing the apps to nc4nix.
[4] Though notable license changes (e.g. agpl -> gpl) would also pop up
in the diff of <nextcloudversion>.json, so this is pretty easy to
catch.
The command `fakechroot` errored with buffer overflows. The `proot`
command doesn't seem to suffer from the same problem. The tar command
creating the layer errors with "permission denied" on a bunch of paths
in /proc but the layer seems to get built anyway.
this splits hardeningCFlags into hardeningCFlagsAfter and
hardeningCFlagsBefore (where most flags still remain) to allow
us to *append* `-D_FORTIFY_SOURCE=` values to the command-line,
forcing our choice of fortify level and avoiding potential
redefinition warnings/errors through use of `-U_FORTIFY_SOURCE`
While using libredirect in conjunction with geckodriver, I stumbled on
odd segfaults that happened when running the wrapped statx() call from
libredirect:
0x00007ffff7ddd541 in __strncmp_avx2 () from .../lib/libc.so.6
0x00007ffff7f6fe57 in statx () from .../lib/libredirect.so
0x00005555558d35bd in std::sys::unix::fs::try_statx::h2045d39b0c66d4e8 ()
0x00005555558d2230 in std::sys::unix::fs::stat::ha063998dfb361520 ()
0x0000555555714019 in mozversion::firefox_version::hdc3b57eb04947426 ()
0x00005555556a603c in geckodriver::capabilities::FirefoxCapabilities::version::h58e289917bd3c721 ()
0x00005555556a77f5 in <geckodriver::capabilities::FirefoxCapabilities as webdriver::capabilities::BrowserCapabilities>::validate_custom::h62d23cf9fd63b719 ()
0x000055555562a7c8 in webdriver::capabilities::SpecNewSessionParameters::validate::h60da250d33f0989f ()
0x00005555556d7a13 in <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold::h9427a360a3d0bf8f ()
0x0000555555669d85 in <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter::hd274d536ea29bb33 ()
0x00005555555c05ef in core::iter::adapters::try_process::hdf96a01ec1f9b8bd ()
0x000055555561768d in <webdriver::capabilities::SpecNewSessionParameters as webdriver::capabilities::CapabilitiesMatching>::match_browser::hfbd8c38f6db17e9f ()
0x00005555555ca6ef in <geckodriver::marionette::MarionetteHandler as webdriver::server::WebDriverHandler<geckodriver::command::GeckoExtensionRoute>>::handle_command::h13b98b9cb87a69d6 ()
0x00005555555e859e in webdriver::server::Dispatcher<T,U>::run::h746a8bf2f0bc24fd ()
0x000055555569ff0f in std::sys_common::backtrace::__rust_begin_short_backtrace::h3b920773bd467d2a ()
0x00005555555dbc99 in core::ops::function::FnOnce::call_once{{vtable.shim}}::h81ba7228877515f7 ()
0x00005555558d31a3 in std::sys::unix:🧵:Thread:🆕:thread_start::h4514580219a899c5 ()
0x00007ffff7d0ce24 in start_thread () from .../lib/libc.so.6
0x00007ffff7d8e9b0 in clone3 () from .../lib/libc.so.6
The reason why I found this odd was because it happens in the following
piece of code (shortened a bit):
1 static const char * rewrite(const char * path, char * buf)
2 {
3 if (path == NULL) return path;
4 for (int n = 0; n < nrRedirects; ++n) {
5 int len = strlen(from[n]);
6 if (strncmp(path, from[n], len) != 0) continue;
7 if (snprintf(buf, PATH_MAX, "%s%s", to[n], path + len) >= PATH_MAX)
8 abort();
9 return buf;
10 }
11 return path;
12 }
When inspecting the assembly, I found that the check for the null
pointer in line 3 was completely missing and the code was directly
entering the loop and then eventually segfault when running strncmp()
with a null pointer as its first argument.
I confirmed that indeed that check was missing by compiling libredirect
with "-O0" and comparing the generated assembly with the optimized one.
The one compiled with "-O0" had that check while the optimized one did
not and indeed when running geckodriver with the unoptimized version it
worked fine.
Digging in the Git history, I found 5677ce2008,
which actually introduced the null pointer check. Going back to that
commit however, the check actually was still in the generated assembly.
So I bisected between that commit and the most recent one and ended up
with commit ca8aa5dc87, which moved
everything to use GCC 7.
I haven't found out why *exactly* GCC was optimizing the check away, but
playing around on Godbolt with various other compilers seems that other
compilers such as Clang are doing it as well. Additionally, given that
passing NULL to stat() is UB, my guess is that compilers tend to assume
that such an argument can't be NULL. My assumption is based on the fact
that GCC warns with "argument 1 null where non-null expected" when
passing NULL to eg. stat().
To address this for now, I marked the path argument of the rewrite()
volatile and also added a test that should cause a segfault in case this
would regress again as it already did.
Signed-off-by: aszlig <aszlig@nix.build>
Since coreutils v9.2 the `--no-clobber` flag results in a non-zero exit
code when the destination files exist. Using `--update=none` will now
reproduce the old behavior of `--no-clobber`.
However, the `--update=none` flag was introduced in coreutils v9.3 and
thus `mergeImages` will fail if you have an older version than v9.3 in
stdenv after applying this commit.
[coreutils v9.3 changelog](f386722dc0/NEWS (L48))
Derivations built with `writeShellScriptBin`
should always be runnable with `nix run`. At present,
the derivation is missing both `meta.mainProgram`
and `pname`– this means that `nix run` falls back
to inferring the bin path from `name`. This is
unreliable and depends on faulty heuristics.
For context, reference the following snippet from
`nix run --help`:
If installable evaluates to a derivation, it will try to execute the
program <out>/bin/<name>, where out is the primary output store path
of the derivation, and name is the first of the following that exists:
· The meta.mainProgram attribute of the derivation.
· The pname attribute of the derivation.
· The name part of the value of the name attribute of the derivation.
