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.
Katalin Rebhan