| Age | Commit message (Collapse) | Author |
|---|
|
Without this, things like zlib are not found.
|
|
|
|
- add " -std=gnu17" to `env.NIX_CFLAGS_COMPILE`
Fixes build failure with gcc15:
```
In file included from Include/Python-ast.h:3,
from Python/bltinmodule.c:4:
Include/asdl.h:9:15: error: cannot use keyword 'false' as enumeration constant
9 | typedef enum {false, true} bool;
| ^~~~~
Include/asdl.h:9:15: note: 'false' is a keyword with '-std=c23' onwards
Include/asdl.h:9:28: error: expected ';', identifier or '(' before 'bool'
9 | typedef enum {false, true} bool;
| ^~~~
Include/asdl.h:9:28: warning: useless type name in empty declaration
In file included from Include/Python-ast.h:3,
from Python/compile.c:26:
Include/asdl.h:9:15: error: cannot use keyword 'false' as enumeration constant
9 | typedef enum {false, true} bool;
| ^~~~~
Include/asdl.h:9:15: note: 'false' is a keyword with '-std=c23' onwards
Include/asdl.h:9:28: error: expected ';', identifier or '(' before 'bool'
9 | typedef enum {false, true} bool;
| ^~~~
```
|
|
As documented in https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#abi-tag.
This is useful to check whether a wheel is compatible with a certain interpreter. [Pyproject.nix](https://github.com/pyproject-nix/pyproject.nix) has [functions to perform wheel compatibility checking](https://pyproject-nix.github.io/pyproject.nix/lib/pypa.html#function-library-lib.pypa.isWheelFileCompatible) against a Python interpreter, and has computed interpreter ABI tags itself.
The recent addition of free threading (`python313FreeThreading`) complicates this by not being introspectable:
A GIL Python (non free-threaded) has an ABI tag `cp313` while the free-threaded Python has `cp313t`, but the package doesn't communicate whether `enableGIL` is true or false, leaving no way to compute the tag.
The same goes for if debugging support was added to the derivation: A `d` suffix would need to be added.
Additionally ABI tags has no defined format and can really only be accurately computed by having insight into how the ABI tags are used by a specific interpreter, meaning that the only correct place to compute ABI tags is within the context of a particular Python derivation.
While this has no immediate use within nixpkgs it could be used as a basis to provide compatibility assertions regarding wheel compat at eval time.
|
|
|
|
This reverts commit 65a333600d5c88a98d674f637d092807cfc12253.
This wasn't tested for correctness with something like fodwatch [0],
and should not have been (self-)merged so quickly, especially without
further review.
It also resulted in the breakage of at least one package [1] (and that's
the one we know of and was caught).
A few packages that were updated in between this commit and this revert
were not reverted back to using `rev`, but other than that, this is a
1:1 revert.
[0]: https://codeberg.org/raphaelr/fodwatch
[1]: https://github.com/NixOS/nixpkgs/pull/396904 / 758551e4587d75882aebc21a04bee960418f8ce9
|
|
|
|
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](https://github.com/NixOS/nixpkgs/tree/8616af08d915377bd930395f3b700a0e93d08728/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
|
|
|
|
|
|
|
|
|
|
configd is an alias for the SystemConfiguration framework, which is now
always part of the SDK. Removing this parameter because it effectively
does nothing now, which could be misleading to users.
|
|
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
|
|
nix run nixpkgs#silver-searcher -- -G '\.nix$' -0l 'description.*"[Aa]n?' pkgs \
| xargs -0 nix run nixpkgs#gnused -- -i '' -Ee 's/(description.*")[Aa]n? (.)/\1\U\2/'
|
|
In the past I was very active with Python packaging.
For several years now I was hardly around as maintainer,
so it does not make sense I am listed as a maintainer for
these makes. Looking back, I should have removed myself
as maintainer already much longer ago. Anyway, better late
than never.
It's been a fun ride, and I do intend to occasionally contribute
to Nixpkgs, but not in the same way it once was.
|
|
This commit reverts all python changes from 234bb31f611f43f8b744b305ab82035de637aaca.
|
|
The way we build python environments is subtly broken. A python
environment should be semantically identical to a vanilla Python
installation in, say, /usr/local. The current implementation, however,
differs in two important ways. The first is that it's impossible to use
python packages from the environment in python virtual environments. The
second is that the nix-generated environment appears to be a venv, but
it's not.
This commit changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We remove the sitecustomize.py file from the base python package.
This file was used tweak the python configuration after it was
incorrectly initialized. That's no longer necessary.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
|
|
Diff: https://github.com/ActiveState/cpython/compare/v2.7.18.7...v2.7.18.8
|
|
|
|
Apply the patch to fix using libutil.h instead of util.h on Darwin for
`forkpty` and `openpty`.
|
|
|
|
Conflicts:
pkgs/development/libraries/pmdk/default.nix
|
|
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
|
|
Fixes: ee90eca180f ("cpython: Migrate sha256 occurences to hash")
|
|
|
|
Since we are now guarantee that the `resholve` is not exposing `python27`,
let's remove the `stripLibs` hack that tried to reduce its size.
|
|
More information: https://www.activestate.com/products/python/python-2-end-of-life-security-updates/
|
|
|
|
Without `--with-system-{ffi,expat}` flags, Python will use its own
embedded libraries that are out-of-date. Thanks to it, they can be a
security issue. So let's use our own libraries instead.
This is already what Python 3.x does, so should be safe.
|
|
Strip unused libraries from resholve's own python27 derivation, further
reducing its size and reducing its attack surface.
|
|
This PR strips down the modified `python27` derivation used by `resholve`. The
idea is to reduce the possible security issues, and also to make it easier to
bootstrap.
|
|
|
|
|
|
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.
|
|
|
|
Add patches from Arch Linux package (that itself source its patches from
Gentoo) to the following known security issues in Python 2.7:
- CVE-2020-26116
- CVE-2020-27619
- CVE-2020-8492
This should cover all security issues currently listed in
https://www.activestate.com/products/python/python-2-end-of-life-security-updates/.
|
|
Tested as no material change in `out` output with `diffoscope`.
|
|
the argument to optional should not be list
|
|
Python package sets can be overridden by overriding an interpreter
and passing in `packageOverrides = self: super: {...};`. This is fine
in case you need a single interpreter, however, it does not help you
when you want to override all sets.
With this change it is possible to override all sets at once by
appending a list of "extensions" to `pythonPackagesExtensions`.
From reading the implementation you might wonder why a list is used, and
not
`lib.composeExtensions`? The reason is the latter requires knowledge of
the library function. This approach should be easier for most users
as it is similar to how we append to lists of e.g. inputs or patches
when overriding a derivation.
|
|
|
|
|
|
In 9d03ff52229f36ff4b4e9d0ee2db4a46b90512bb I made the CPython builds
reproducible. This required not generating default unoptimized bytecode.
I was under the impression the optimized bytecode would be used then,
but you need to opt-in on that. Not having the default bytecode resulted
in a significant performance hit. Therefore, bytecode is generated again
in this commit, and thereby the builds are no longer reproducible.
https://bugs.python.org/issue29708
|
|
|
|
From the archive `python-gentoo-patches-2.7.18_p8.tar.xz` found at
https://dev.gentoo.org/~mgorny/dist/python/, I copied
`0024-3.6-bpo-42967-only-use-as-a-query-string-separator-G.patch`.
|
|
Achieve reproducible builds of the interpreter. Note this meant
disabling optimizations again.
|
|
The issue manifests itself as the following on `aarch64-darwin`:
```
>>> import ctypes
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/nix/store/i8cq0xrjirz1rcp65wzcyhj6ypzlw9il-python3-3.7.10/lib/python3.7/ctypes/__init__.py", line 551, in <module>
_reset_cache()
File "/nix/store/i8cq0xrjirz1rcp65wzcyhj6ypzlw9il-python3-3.7.10/lib/python3.7/ctypes/__init__.py", line 273, in _reset_cache
CFUNCTYPE(c_int)(lambda: None)
MemoryError
```
The commit we backport is included in Python 3.8, and it reverts
the change that was introduced all the way back in Python 2.7.
|
|
Thanks to the Gentoo team maintaining a fork of python2¹ we can easily
apply their backported patch for this security vulnerability.
[1] https://gitweb.gentoo.org/fork/cpython.git/
|
|
|
|
Fixes #108243
|
