| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
See https://github.com/NixOS/nixpkgs/issues/106950
> They way it's worded says buildInputs are for build-time and nativeBuildInputs are for run-time. The other documentation leads me to believe it is the other way around.
|
|
|
|
DocBook does not support creating labels for unordered list items so we need to add a link label ourselves.
|
|
It was briefly mentioned in stdenv docs but since it interacts with wrapGAppsHook, it should be documented here.
|
|
Additionally fixes the "list of names and emails" to be a list of maintainer expressions.
A follow-up from the discussion in https://github.com/NixOS/nixpkgs/pull/96666
|
|
Document conventions around adding new maintainers
|
|
Adding them to `maintainers/maintainer-list` in a separate commit.
Co-Authored-By: Pavol Rusnak <pavol@rusnak.io>
Co-Authored-By: Atemu <atemu.main@gmail.com>
Co-Authored-By: Kevin Cox <kevincox@kevincox.ca>
|
|
I made a mistake merge. Reverting it in c778945806b undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2b
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c209)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
|
|
I'm sorry; I didn't notice it contained staging commits.
This reverts commit 17f5305b6c20df795c365368d2d868266519599e, reversing
changes made to a8a018ddc0a8b5c3d4fa94c94b672c37356bc075.
|
|
Teach installShellCompletion how to install completions from a named
pipe. Also add a convenience flag `--cmd NAME` that synthesizes the name
for each completion instead of requiring repeated `--name` flags.
Usage looks something like
installShellCompletion --cmd foobar \
--bash <($out/bin/foobar --bash-completion) \
--fish <($out/bin/foobar --fish-completion) \
--zsh <($out/bin/foobar --zsh-completion)
Fixes #83284
|
|
|
|
|
|
docs.stdenv: remove reference to replace tool
|
|
|
|
By adding prompts and removing unnecessary indentation.
|
|
This hook moves systemd user service file from `lib/systemd/user` to
`share/systemd/user`. This is to allow systemd to find the user
services when installed into a user profile. The `lib/systemd/user`
path does not work since `lib` is not in `XDG_DATA_DIRS`.
|
|
dudebout/document-nix-env-multiple-output-install-bug
document nix-env bug relating to multiple output installation
|
|
|
|
Wanted to link them.
|
|
licenses: Make single-version-only GPL explicit
|
|
|
|
I commonly see people use the former when they should use the latter.
Would be also in line with the SPDX change https://www.gnu.org/licenses/identify-licenses-clearly.html
|
|
|
|
https://hydra.nixos.org/build/128037886/nixlog/1/tail
error: element "variable" not allowed anywhere
|
|
maintainers/scripts/update.nix: Add support for auto-commiting changes
|
|
The environment variable will contain the attribute path the script is supposed to update.
|
|
We no longer need it for most use cases so I am making it experimental.
I have something in mind where it might be useful in the future (customizing commit messages)
but for now, it would only confuse people.
|
|
|
|
We can determine all of them when attrPath is present so we might jsut as well do it.
|
|
Instead of having the updateScript support returning JSON object,
it should be sufficient to specify attrPath in passthru.updateScript.
It is much easier to use.
The former is now considered experimental.
|
|
Update scripts can now declare features using
passthru.updateScript = {
command = [ ../../update.sh pname ];
supportedFeatures = [ "commit" ];
};
A `commit` feature means that when the update script finishes successfully,
it will print a JSON list like the following:
[
{
"attrPath": "volume_key",
"oldVersion": "0.3.11",
"newVersion": "0.3.12",
"files": [
"/path/to/nixpkgs/pkgs/development/libraries/volume-key/default.nix"
]
}
]
and data from that will be used when update.nix is run with --argstr commit true
to create commits.
We will create a new git worktree for each thread in the pool and run the update
script there. Then we will commit the change and cherry pick it in the main repo,
releasing the worktree for a next change.
|
|
validatePkgConfig: init
|
|
* Add id
* Mention rpath
* The control variables do not really have to be env vars (though without structuredAttrs there is not a difference)
|
|
This adds the `validatePkgConfig` hook, which can be used to validate
pkg-config files in the output(s). Currently, this will just run
`pkg-config --validate` on all `.pc` files, capturing errors such as
the issue that was fixed in #87789.
The hook could be extended in the future with more fine-grained
checks.
|
|
|
|
|
|
|
|
|
|
Fixes #85038
|
|
This has changed a few times from 2008 to 2012: cdc74e167, d9213df2c,
and 095db9fe3.
|
|
Since this commit on nixos-homepage, the homepage was 404-ing:
https://github.com/NixOS/nixos-homepage/commit/179733c176c1f625bb18d4eba38480b888471a7a
|
|
|
|
I can't say I really understand that much about our cross stuff,
but this seems very clear.
|
|
|
|
|
|
|
|
|
