- This information is availabe from environment variables defined by
maintainers/scripts/update.nix
- Renamed the shell script to generic-update-script.sh
- Add a new optional argument (representing the package name) to the
shell script
- The version lister is called with a new optional
argument (representing the package attribute path)
When TOFU was unable to download the file, there would be no hash
in the fetch log, causing the grep to fail. Since the script
is set to errexit, it would terminate the processing without
any output. Let’s instead print the fetch log.
Some update scripts (e.g. sublime4) already use all-zeroes hashes
for resetting a version when updating multiple sources.
When `update-source-version "${attrPath}" 0 "${lib.fakeSha256}"`
was executed, u-s-v would not be able to detect that the hash
changed and would fail with the following message:
Failed to replace temporary source hash of '…' to the final source hash!
The update script worked when we tested it because change detection itself
was broken until recently: https://github.com/NixOS/nixpkgs/pull/190554
This would do a pointless slow `nix-instantiate` call for a feature
that is rarely used – initially, it was added for Firefox updates
186de9ca9e
but now not even that uses it.
Additionally, this would break stuff like `cargoDeps`,
which lack the url attributes.
Previously, we only made `sed` back up the version replacement.
This meant that `cmp` would already recognize the files
as changed before replacing hash and the other values,
and the error would not be printed.
Let’s always make the `sed` create a backup so that we can
detect success of each situation. This will no longer
allow us to revert to the original version on failure
but the updated file should be tracked in git anyway.
It used to use src.url, but when that was changed the comments weren't
updated.
Fixes: 7aae279ad9 ("unstableGitUpdater: fix updating fetchzip-based sources")
a67950f20b added `url` attribute
from `fetchurl` and therefore also from `fetchzip`.
We previously relied on `url` from fetchgit-based fetchers
to find the repo URL but now it will just return tarballs
in the case of `fetchFrom{GitHub,GitLab}`.
Let’s add an attribute to `fetch{git,FromGitHub,FromGitLab}`
to expose a repo URL consistently.
That way gitUpdater could be used to extract most recent published
releases for .nix files that don't use git directly to define builds.
An example is iproute2 package which does not have a single place
to lookup most recent release.
- Add the 'gitUpdater' helper function to update git based packages, using the
'genericUpdater' function.
- Rework argument passing to the `list-git-tags' and 'list-archive-two-level-versions' scripts.
- Replace 'genericUpdater' plus 'list-git-tags' by 'gitUpdater'
It is important to keep the version as parsed by `builtins.parseDrvName`
monotonic for packages that often switch between stable and unstable versions,
for nix-env to be able to update them reliably.
Let’s optionally use the version format described by RFC 107:
https://github.com/NixOS/rfcs/pull/107
The downside is that it requires fetching
more commits to be able to determine the latest tag.
When `fetchFromGitHub` uses `fetchzip` instead of `fetchgit` internally,
which is the most common use case, there is no `src.url` attribute
so the update will fail.
Let’s fix that by falling back to `src.meta.homepage`,
which these fetchers set to the repository URL.
In flakes, packages are not exposed directly but instead they are declared
inside “packages” or “legacyPackages” output under their host platform.
flake-compat reflects this.
Let’s look for an attribute also in these outputs if the direct lookup fails.
When update-source-version is run in a repo with flake-compat,
it would find the files in Nix store.
Let’s replace them with the local path of the repository.
Adds a --rev=<revision> parameter to the script that makes it possible
to explicitly specify a new revision.
Useful to update unstable packages, where the version and revision may
be independent.
This improves on the previous verison of this script.
Previously it only accepted one attr, and required
explicit passing of the "broken" value.
This script is meant to be used to mark failing hydra builds as broken in the meta attrs
To use the script, you should pass the list of failing attrs as arguments to the script.
Example: `cat failing-attrs | xargs ./pkgs/common-update/scripts/mark-broken`
Generating a list of failing attrs: (this should be improved at a later date)
- Go to the most recent hydra evaluation with all builds completed
- Select the "builds still failing" tab
- Highlight and select all packages, should be prefixed with `nixpkgs.`
- Use regex and editor foo to leave only the attr names
- Use the above example command to then execute the script
OTHER NOTES:
- The `denyFileList` and `denyAttrList` will likely need to be updated slightly
to align with the conventions used in nixpkgs at execution time
- Any attrs which failed for any reason will be written to `failed-marks.txt`.
Those attrs will likely need manual attention as disablement will likely be conditional.
- updateScript:
A nix expression that can be used in passThrough to update a package
- list-git-tags:
A shell script to list available tags in a git repository
- list-archive-two-level-versions:
A shell script to list available versions in a web site in two
levels: there is a page listing the available major.minor versions,
and for each of them there is another page listings the patch level
versions major.minor.patch.
It is suitable for Xfce packages for instance.
How the updater works:
1. collect the available versions from the source repository (using a
script given as argument)
2. print the collected versions (for debugging)
3. (optionally) apply some transformation to the collected versions to
make them compatible with the versions used in nixpkgs (for instance,
tags in the Xfce git repository may be prefixed with the package name,
and the prefix need to be removed)
4. sort the available versions in decreasing order
5. choose the first version that pass validation:
- check if the version may be a development version
- if the version IS unstable, skip it and give a warning about
skipping a development version (for debugging)
- if the version COULD BE unstable, take it and give a warning
about taking a potential development version (for debugging)
- if the version IS stable, take it
6. update the package version and checksum in its nix expression
7. print the git commands for adding the modified files and for
committing the changes
