Patch 'build-find-pre-built-heimdal-build-tools-in-case-of-.patch' no longer applied. I found that LibreELEC maintainers had posted on https://bugzilla.samba.org/show_bug.cgi?id=14164, and that they had an updated patch, so let's just fetch that.
Why do we need `--with-systemd`? Samba 4.23 has a build script regression that no longer auto-detects systemd libraries. I intend to raise this with Samba's bugzilla, but in short:
* Samba 4.23 upgraded its bundled waf from 2.0.26 (used in 4.22.x) to 2.1.6.
* waf 2.1.6 switched the CLI option parser from `optparse` to `argparse`, in which case the default boolean was previously `None`, but is now `False`.
* In `lib/util/wscript`, the systemd options are registered like `opt.add_option('--with-systemd', action='store_true', dest='enable_systemd')`.
* In `lib/util/wscript_configure`, the libsystemd checks are guarded by `options.enable_sytemd != False`, and thus is no longer true when unspecified.
The discard_const macro casts through uintptr_t, which newer clang
rejects as non-constant in static initializers. Use a direct void*
cast instead via substituteInPlace.
It doesn't fix the cross compilation issues related to the surrounding
commits, but it is a good idea to set it anyway. Also, `libtasn1` needs
to be added nativeBuildInputs for `asn1Parser` to be detected properly
and for `bin/dumpmscat` script to be added.
This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
ce5ebeb90c ("samba4: fixup build on linux") removed liburing from
buildInputs on Linux to work around a compilation error [1]. A fix for
the compilation error was included in liburing 2.11 [2]. Readd the
liburing dependency to restore support for vfs_io_uring.
[1]: https://hydra.nixos.org/build/298833701/nixlog/3/tail
[2]: 1b99ce4856
https://hydra.nixos.org/build/298833701/nixlog/3/tail
What I tried:
- updating to 0.20.8 doesn't solve the issue
(we could still do that easily, e.g. on staging;
I just didn't feel like trashing successful binaries for aarch64-darwin)
- upgrading to 0.22.1 brings others (2 patches not applying and more problems...)
1) Fix dependencies for stuff that is not needed or impossible to
build on FreeBSD
2) Add various un-emulatable-cross pieces initially developed for tdb
3) Fix many issues related to samba not actually wanting to compile
cross between different OSes.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 57b193d8dd
result/bin/apply-formatting $NIXPKGS_PATH
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
the cups headers are part of the sdk but the library is not, which
causes configure to detect cups but the build fails with a link error.
explicitly enable / disable cups based on `enablePrinting` flag.
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"
```
Otherwise references to the Python interpreter inside the set are wrong, as demonstrated by:
``` nix
with import <nixpkgs> { };
let
python' = python3.override {
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the _non_ overriden requests.
And the same with `self`:
```
with import <nixpkgs> { };
let
python' = python3.override {
self = python';
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the overriden requests.
This can manifest itself as file collisions when constructing environments or as subtly incorrect dependency graphs.
These flags are not part of waf, they're custom flags that are not
widely implemented. More packages are broken because of these flags
being added than actually recognise them.
Of the packages in Nixpkgs that directly depend on wafHook that we can
attempt to cross compile (i.e. all their dependencies cross compile),
5 already successfully cross compile and recognise these flags, 2
already successfully cross compile because they have been opted out of
these flags, 3 don't cross compile successfully for reasons unrelated
to these flags, and for the remaining 7, the only thing stopping them
cross compiling successfully is that they are being passed these flags
that they don't recognise.
All of the five successfully cross-compiling packages that do
recognise these flags are samba projects: ldb, talloc, tdb, tevent,
and samba4. So this isn't a general waf convention, just a samba one.
It therefore doesn't make sense to set these flags by default. They
should just be included in the expressions for each samba project,
like all the other quirks common to samba build systems.
This change fixes cross compilation of the following packages:
blockhash ganv ndn-cxx mda_lv2 pflask raul saldl
