Limit-on-update/delete is useful for, amongst other things, bounding the
amount of work done in a single SQL statement. It is not enabled by
upstream by default, but Debian does enable it.
Because the parser generator doesn't receive NIX_CFLAGS_COMPILE, the
setting has to go through the --enable-update-limit configure flag.
Maybe in the future, if this derivation moves to e.g. CFLAGS, this
feature enablement can be made uniform with the others.
The tests seem to be unreliable (at least when SQLite is built by the
Nix daemon). Sometimes they succeed, but they often do not.
Even if SQLite were removed from the bootstrap, this would still be a
problem, so disable the tests for now.
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>
This breaks my linux->freebsd cross build. It's only relevant for
32-bit systems, and the right way to do this is to set
_FILE_OFFSET_BITS, not hacks like this. Plus, whether we use 64-bit
file APIs on 32-bit platforms is really a decision we should be making
globally, not per package.
This update includes a move from autotools to autosetup, which
requires from build/configure flag changes.
3.49.1 included some bugs with static compilation which 3.49.2
fixes. 3.50.1 was released during the merge request's lifetime and
included for further stabilization improvements to sqlite.
NB first iterations of this included tcl in the inputs; but per some
scattered repository comments, tcl is currently unreliable (broken?) in
static.
They are not doing anything right now. This is in preparation for their
complete removal from the tree.
Note: several changes that affect the derivation inputs (e.g. removal of
references to stub paths in build instructions) were left out. They will
be cleaned up the next iteration and will require special care.
Note: this PR is a result of a mix of ugly regex (not AST) based
automation and some manual labor. For reference, the regex automation
part was hacked in: https://github.com/booxter/nix-clean-apple_sdk
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
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](8616af08d9/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.
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
