As discussed in kiss-community/repo#100 and #39, we seem to be in favor of switching to blake3.
The following changes are made:
- All newly generated checksums are blake3
- The user is prompted to generate blake3 checksums if sha256 sums are present (maybe this should be automatic)
- For installed packages, we can fall back to sha256 to check etcsums
This includes a name change of the `checksums` and `etcsums` files -- I'm not sure of any better way to detect whether sha256 sums are in use, as blake3 sums are the same length.
Feedback is appreciated
Co-authored-by: Owen Rafferty <owen@owenrafferty.com>
Reviewed-on: https://codeberg.org/kiss-community/kiss/pulls/72
If KISS_PATH=:: or even KISS_PATH=:/repo1:/repo2, the `IFS=:; set -- $KISS_PATH`
trick leaves some of $@ as empty strings. These cause git to print errors.
Instead, skip empty arguments.
Demonstration of bug:
$ cd
$ KISS_PATH=::: kiss u 2>&1 | sed '/Checking/q'
-> Updating repositories
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
-> Checking for new package versions
The git commands producing the errors are:
git -C "" rev-parse 'HEAD@{upstream}'
and when the argument to -C is empty, the current working directory is
unchanged. Therefore, if PWD happens to be inside a git tree, this
command could have unexpected effects: currently, if KISS_PATH contains
(an) extra colon(s), and PWD is in a git repo with an upstream, the repo
is updated irrespective of whether it is in KISS_PATH or a package repo.
This behaviour is also fixed by this commit.
If the chroot is exited with nonzero status, kiss-chroot runs `die
chroot failed`. Then, die runs `exit 1` which causes the trap to
execute. However, in this scope, "$@" is "chroot failed", so the trap
evaluates $1 to be "chroot" rather than the mountpoint given to the
kiss-chroot script. Then, the trap tries to unmount "chroot/dev" etc
rather than the true mountpoint.
This patch uses double quotes rather than single when setting the trap,
so that $1 is expanded then and the mountpoint is stored for when the
trap is called.
Commit d94c811 changed `sort -u` to `uniq -u`; these are not equivalent.
`uniq -u` suppresses all duplicate lines, but `sort -u` removes all but
one. In the case of there being no command-line args, PWD is taken as
the package, and if that package is in a repo already in KISS_PATH, the
repo will be in KISS_PATH twice. This will cause the `kiss search`
command to give two entries for PWD, and `uniq -u` removes both.
Revert to `sort -u` to keep one of those entries.
If the package in PWD is not installed, there will be not entries left;
if it is installed, kiss-maintainer will try to get the history from
/var/db/kiss/installed/pkg, which is not a git repo.
Example of the incorrect behaviour:
KISS_PATH=/home/me/repo/core
PWD=/home/me/repo/core/musl
$ sh -x /usr/bin/kiss-maintainer
+ '[' ]
+ export 'KISS_PATH=/home/me/repo/core::/home/me/repo/core'
+ set -- musl
+ kiss search musl
+ uniq -u
+ read -r repo
+ read -r repo
+ cd /var/db/kiss/installed/musl
+ git log -1 version
+ m=
+ :
+ m=
+ m=
+ '[' ]
+ continue
+ read -r repo
(no output)
if a package contains a file with a quote in it's name, xargs complains
about an unmatched quote and fails, and the pipeline is aborted.
this patch escapes all non-alphanumeric characters so that xargs can
handle such filenames.
Ctrl+C is now correctly blocked during installation and removal
and ordering of pkg_clean is maintained.
Two new hooks have been added, SIGINT and SIGEXIT. These run in
the corresponding signal handlers.
Fixes#280
