- Make some arguments more fitting (the path is actually full, not just relative to prefix…).
- Increase the purity of packages* functions (they now take pkgs from argument, not from scope).
- Add some documentation comments.
`update.nix` extracts `passthru.updateScript` attributes in the main repo
and when they are relative paths (e.g. `./update.sh`), Nix will resolve them
to absolute paths in the main repo.
Update scripts can use $(dirname $0) to get the location of files they
should update but that would point to the main repo.
We want them to modify the appropriate git worktree instead
so we replace the prefix accordingly.
`git rev-parse --show-toplevel` will resolve symlinks but, fortunately,
Nix will do that as well, so the path will match:
https://github.com/NixOS/nixpkgs/pull/98304#issuecomment-695761754
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.
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.
- EXIV2_BUILD_PO has been replaced by EXIV2_ENABLE_NLS
https://github.com/Exiv2/exiv2/commit/076585d1476283bc7cffcf08e9006fc64ffbfa10
Confusingly, the former still appears in the flag summary.
- Remove enableParallelBuilding since it is on by default with CMake
- Reorder the expression
- Apply upstream GNUInstallDirs patch
- Build stuff in build phase, not in install phase
- Add maintainers field (empty at the moment)
The latest version is not compatible with Python 3.8,
let's cherry-pick some patches from master.
Also pre-prepare for incoming release of GStreamer 1.18.
- use pkg-config instead of pkgconfig alias
- use placeholders for cmakeFlags
- do not skip build rpath
- udev replacements no longer apply https://github.com/TheImagingSource/tiscamera/commit/47d4fb246b5f82763f87ad57c7d1ed3420655e96
There are some misplaced dependencies like gobject-introspection and orc that should probably go to nativeBuildInputs but upstream detects them incorrectly.
GPaste ships keybindings for gnome-control-center. Those depend on GSettings schemas
but there is currently no mechanism for loading schemas other than using global ones
from $XDG_DATA_DIRS. Eventually, I want to add such mechanism but until then,
let's return the impure sessionPath option that was removed in
https://github.com/NixOS/nixpkgs/commit/f63d94eba340c05cd241c478deb518204514fce8
The incompatibility does not seem to exist any more: programs linked against fc 2.12
on fc 2.14 system seem to at least display text, even while printing tons of errors
(as long as you generate fc cache manually), and same thing the other way around.
Hopefully it will not be an issue in the future.
This reverts commit edf2541f02.
Turns out lot of software (including Chromium) use bundled fontconfig
so we either need to wrap every one of those, or re-introduce the global
unversioned config. The latter is easier but weakens hermetic configs.
But perhaps those are not really worth the effort. Given that programs
linked against fc 2.12.6 on fc 2.13.92 system seem to at least display text,
even while printing tons of errors (as long as you generate fc cache manually),
and same thing the other way around, hopefully it will not be an issue in the future.
We give up on the hermetic configs in exchange for getting rid of lot of complexity.
The many-years abandoned GStreamer 0.10 branch no longer builds so let's remove it. Hopefully nothing used it these days.
GConf has been abandoned for years too and would not work without user running the daemon.
The many-years abandoned GStreamer 0.10 branch no longer builds so let's remove it. Hopefully nothing used it these days.
GConf has been abandoned for years too and would not work without user running the daemon.