For this we just need to advance by one additional commit on master
which fixes the compilation of libk.so on *BSD with -Werror.
Additionally we need to reflect the change that the system double
for x86_64 FreeBSD now also includes the FreeBSD version.
ActiveState is a company that is maintaining a fork of Python 2 to fixes
its security issues. Their support is paid, however the code is
open-source. See the details here:
https://www.activestate.com/products/python/python-2-end-of-life-security-updates/
This enable us to drop a bunch of CVE's patches for Python 2.7 and also
it should be easier to maintain, since we can just bump the version once
ActiveState tags a new version.
The startup script used by jconsole (/bin/profile.ijs) doesn't try very hard to understand the file hierarchy it lives in, and just did not work with NixOS. For reasons unknown, it Just Worked for some time, but finally broke with an actual error message every time you launch jconsole in recent versions of nixpkgs.
This commit just overwrites all the heuristics J uses to find out where its installation files are, to point where they actually are put by the installer.
Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
Prior to this commit, pythonRelaxDeps would only support removing
version constraints from "Requires-Dist" lines formatted in a particular
way ("foo (>= 1.2.3)"). This way is deprecated as per PyPA Core Metadata
Specs v2.1 [1]:
> Tools parsing the format should accept optional parentheses around
> this, but tools generating it should not use parentheses.
Additionally, a "Requires-Dist" dependency specification can contain
other metadata than just package name and version (extra names,
environment marker). These were being silently dropped by the prior
version of pythonRelaxDeps, or the version could not be relaxed.
The actual grammar is defined in PEP 508 [2]. Our tool of choice here is
sed extended regexps, so there's only so much we can do to be correct
with this parser. The regexp implemented in this commit makes an attempt
at supporting [extra] names, ; env_markers, as well as version specs
without parentheses. There are still unsupported features (URL specs) as
well as unhandled edge cases, but at some point trying to make the
regexp better is bound to awake ZALGO [3].
[1] https://packaging.python.org/en/latest/specifications/core-metadata/#requires-dist-multiple-use
[2] https://peps.python.org/pep-0508/#grammar
[3] https://stackoverflow.com/a/1732454/179806
stdenv is included in the package set. It does not provide a Python
module however and was therefore catched by the test. Because we do need
it we provide an exception for it.
This adds a test to ensure no new uses of `buildPythonApplication` can
be added to `python-packages.nix`.
Python packages can be grouped into two groups: 1) applications and 2)
packages providing importable modules. In `python-packages.nix` we only
want to have 2). 1) should be in the top-level package set.
To achieve this, all setup hooks need to be marked as being a setup hook.
For the setup hooks in the Python packages set this is done by creating
a new builder, `makePythonHook`.
Because there were issues with splicing, the file importing all the hooks
is converted to an extension. All non-packages were moved out of `python-packages.nix`
into `python-packages-base.nix`. The `keep` argument to `makeScopeWithSplicing
was cleaned up as well; there is no need to keep this one manually in sync
reducing the risk of breaking cross-compilation.
Before packages did not had to set `format = "other";` if had a custom
installPhase and would not produce a dist folder.
The current error message is hard to understand by new users:
> Executing pythonOutputDistPhase
> mv: cannot stat 'dist': No such file or directory
This commit improves the error message.
BEFORE:
the python derivation did not contain .nativeDrv and .crossDrv because
it was not from the __splicedPackages set
the python used in mk-python-derivation.nix was for host
```
nix-repl> pkgsCross.aarch64-multiplatform.python3Packages.xpybutil.nativeBuildInputs
[ «derivation /nix/store/bhz39ds4v02hn6x4py4mzjyilw4a589h-python3-aarch64-unknown-linux-gnu-3.10.7.drv» «derivation /nix/store/v880cnh4ml7czmivfbk3cdh93hz9yvbn-hook.drv» «derivation /nix/store/f243ab7wv92gqsmc9h7gr0qcnj0xcgdb-hook.drv» «derivation /nix/store/880lf8895bzn8d94lrr2y7ilgkxq0lc4-python-remove-tests-dir-hook.drv» «derivation /nix/store/fzjnhawfs1wpw58hcd1vxd9y750dc08y-python-remove-bin-bytecode-hook.drv» «derivation /nix/store/n8l59iparx98yfw8g5ydqmzmk3fdic75-setuptools-setup-hook.drv» «deri→
```
AFTER:
the python derivation does contain .nativeDrv and .crossDrv because
it is from the __splicedPackages set
those 2 are what makes nativeBuildInputs and buildInputs function
properly
the python used in mk-python-derivation.nix is for build
```
nix-repl> pkgsCross.aarch64-multiplatform.python3Packages.xpybutil.nativeBuildInputs
[ «derivation /nix/store/hvb9yxgv1133cfhxxd869sibldvv2vdx-python3-3.10.7.drv» «derivation /nix/store/v880cnh4ml7czmivfbk3cdh93hz9yvbn-hook.drv» «derivation /nix/store/f243ab7wv92gqsmc9h7gr0qcnj0xcgdb-hook.drv» «derivation /nix/store/880lf8895bzn8d94lrr2y7ilgkxq0lc4-python-remove-tests-dir-hook.drv» «derivation /nix/store/fzjnhawfs1wpw58hcd1vxd9y750dc08y-python-remove-bin-bytecode-hook.drv» «derivation /nix/store/n8l59iparx98yfw8g5ydqmzmk3fdic75-setuptools-setup-hook.drv» «derivation /nix/store/7vyhynla→
```
Test with:
nix-build -A lua.tests pass
Tests are very limited for now, goal is mostly to put the infra into
place and enrich the tests when dealing with lua issues.
add luaPath/luaCpath as passthrough
makes it easier to generate LUA_PATH/LUA_CPATH
right now the src is ignored in:
```
lush-nvim = buildNeovimPlugin {
pname = "lush.nvim";
version = "2022-08-09";
src = fetchFromGitHub {
owner = "rktjmp";
repo = "lush.nvim";
rev = "6b9f399245de7bea8dac2c3bf91096ffdedfcbb7";
sha256 = "0rb77rwmbm438bmbjfk5hwrrcn5sihsa1413bdpc27rw3rrn8v8z";
};
meta.homepage = "https://github.com/rktjmp/lush.nvim/";
};
```
which is very confusing. With this PR, we correctly override the src and
the version of the package. We introduce a rockspecVersion attribute of
lua package to be able to still find the rockspec when the
"version" field needs to be different than "rockspecVersion".
Since the Nix command used is an implementation detail of the script,
it's the script that will have to be updated if the command changes,
it's the script that should be opting into this, rather than making
the user do it globally.
Since c0972c16dc ("update-python-libraries: add missing dependency nix"),
Nix will be provided as a dependency, so we know we'll always be using
a modern version and no longer need the fallback.
*Flags implies a list
slightly relevant:
> stdenv: start deprecating non-list configureFlags https://github.com/NixOS/nixpkgs/pull/173172
the makeInstalledTests function in `nixos/tests/installed-tests/default.nix` isn't available outside of nixpkgs so
it's not a breaking change
