According to the tool's (Valknut, formerly DCGUI) website [^1],
the original author stopped maintaining the tool this library was
used for after the version packaged in nixpkgs up to now:
> Nach der Veröffentlichung von Valknut 0.3.7 stellte Mathias Küster die Arbeit an Valknut ein.
Someone else took over development, but the publishing folder for dclib
doesn't contain any new versions after v. 0.3.23 (2009) either [^2].
The GUI distribution folders also look abandoned.
As the version from 2009 also fails with the same build error and
this library isn't referenced anywhere else in nixpkgs (and there's
no listed maintainer), I advocate for removing this package.
[^1]: https://www.berlios.de/software/valknut/
[^2]: https://sourceforge.net/projects/wxdcgui/files/dclib/
We have added nixpkgs-vet as a regular package to nixpkgs a while ago,
so we can now use it from pinned nixpkgs. This avoids pulling a
platform-specific binary version from upstream.
This change also allows to run the tool easily locally, the same way as
other tools:
nix-build ci -A nixpkgs-vet
This will do a full check of the repo with the exception of
nixpkgs-vet's "ratchet" checks: Those depend on having two branches to
compare, but the default is to only look at the head branch. Those
ratchet checks will still be run in CI, though.
We now plan to backport updates, so the release note shouldn't specify
exact versions.
Reworded to improve clarity.
Co-authored-by: John Titor <50095635+JohnRTitor@users.noreply.github.com>
By consistently checking out nixpkgs into the same location in every
workflow, it's easier to reason about the different workflows at once.
We also use crystal-clear names to make clear, which checkouts are
considered trusted, because they only contain target-branch-code and
which checkouts are untrusted, because they contain code from the head
branch. By naming the checkout directories trusted/untrusted, it's
obvious at the call-site.
One example of where we likely did the wrong thing is the nixpkgs-vet
workflow: Fetching the toolVersion from the untrusted checkout opens the
door for an injection into the download URL, thus code could be
downloaded from anywhere. This is not a problem, because this workflow
does not run with elevated privileges, but it's a scary oversight
nonetheless.
Using core.setOutput is much nicer than having to parse the json
"result" on the outside. This also avoids some very odd errors, when the
result can, for unknown reasons, *not* be parsed as JSON later on.
Also avoiding a bit of duplication between the "if mergeable" branches.
In PRs with multiple commits and merge conflicts the logic "targetSha ==
immediate parent of mergedSha" doesn't hold anymore. The head and base
commits of the PR's branch have some commits inbetween them, instead.
Before this change, we'd get a "fatal: invalid reference" on the
"worktree add". Now, not anymore, because we fetch the right commit
directly.
Petr Portnov