Package Details: git-delta 0.8.0-3

Git Clone URL: (read-only, click to copy)
Package Base: git-delta
Description: A syntax-highlighting pager for git and diff output
Upstream URL:
Keywords: beautify CLI diff git pager
Licenses: MIT
Submitter: Kr1ss
Maintainer: Kr1ss
Last Packager: Kr1ss
Votes: 34
Popularity: 3.29
First Submitted: 2019-10-08 13:19
Last Updated: 2021-06-07 12:34

Required by (5)

Sources (1)

Latest Comments

1 2 3 4 5 Next › Last »

bdefore commented on 2021-06-08 15:59

thanks @Kr1ss can confirm git-delta-bin works

Kr1ss commented on 2021-06-08 13:14

@bdefore That will resolve automatically when your distro will have moved pacman to version 6 (E/ and maybe after you've done a rebuild of your AUR helper against pacman 6).

I wasn't aware that they haven't done so yet.

EDIT/ For the time being, you could use git-delta-bin, which is a prebuilt binary.

bdefore commented on 2021-06-08 13:06

on my manjaro box i'm no longer able to update git-delta from yay .. the failure mentions the !lto flag being an unknown option. clean build does not fix the issue. the full result i'm seeing from yay:

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
 there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
 -> Missing AUR Packages:  libunique  linux-latest  mhwd-nvidia-340xx  orage
:: 1 Packages to upgrade.
1  aur/git-delta  0.8.0-2 -> 0.8.0-3
==> Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name)
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:1]  git-delta-0.8.0-3

  1 git-delta                                (Installed) (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
:: PKGBUILD up to date, Skipping (1/1): git-delta
  1 git-delta                                (Installed) (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
:: (1/1) Parsing SRCINFO: git-delta
==> ERROR: options array contains unknown option '!lto'
error downloading sources: git-delta

Kr1ss commented on 2021-06-07 12:32

Yep. I can reproduce this when I turn lto on.

For the time being I'll set it to !lto in the PKGBUILD, even though that's the default anyways - just to prevent users who have link time optimization activated running into this.

Thank you for investigating. Cheers !

FallenWarrior2k commented on 2021-06-06 21:41

@Kr1ss I'm assuming you only saw the email notification because I already edited my original comment to add that I was able to trace the issue back to makepkg's new LTO option.

However, once I find out which among the flags it inserts is the culprit, I'll post them here so maybe we can report this to makepkg upstream. Can't test rn though because I'm on Windows atm.

Kr1ss commented on 2021-06-06 18:32

Thanks @FallenWarrior2k, for reporting.

The fist thing that comes to mind as I look at your log is, that there has been a pacman update recently. Which introduced a change in the default CFLAGS in makepkg.conf.

  • makepkg-5.2.2
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
  • makepkg-6.0.0
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 \
        -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"

I can try to reproduce this today cause I'm on the road, and on mobile. But I'll check back tomorrow night, when I'm back at my box.

Cheers !

FallenWarrior2k commented on 2021-06-06 18:16

I'm getting a bunch of undefined references to libonig symbols only when I build this via the PKGBUILD. Logs

I've also tried editing the PKGBUILD to use the system libonig, by setting RUSTONIG_SYSTEM_LIBONIG=1 and RUSTONIG_DYNAMIC_LIBONIG=1 but that gives me a different error. Logs
Here it look like it's somehow failing to find functions from the ansi_colours crate's C source file.

Cloning the repo and doing cargo build --release --locked in there finishes without any issues whatsoever.

Switching to the -bin version for now, but posting the logs in case someone has an idea what might be wrong. For context, it used to build for me and I have 0.8.0-2 installed right now, but I went back to the first pkgrel=2 commit for 0.8.0 and it no longer works either, so I'm assuming this is because of some external thing. If someone can repro, that'd be cool.

EDIT: Found the issue while debugging build issues with another package. Turns out the culprit was makepkg's new LTO option. Builds work again after turning it off.

Kr1ss commented on 2021-06-02 17:29

Thank you for this @ccorn !

[...] I suppose that this has been unintended [...]

Actually, it has - good catch.

[...] the helper splits the build (presumably using makepkg options --nobuild resp. --noprepare). Thus environment settings in prepare() do not get propagated to later stages.

Yeah I've never taken into account that makepkg can execute prepare()/build()/check()/package() functions independently of each other. Something we should definitely support.

I'm going to apply your patch later tonight, and push a pkgrel update. Cheers !

ccorn commented on 2021-06-02 16:18

Two environment-related items:

  • The recent change to set CARGO_HOME via _cargo (which is defined only conditionally) would have the effect that CARGO_HOME is set to the empty string (assuming _cargo has been unset before) when there is no .cargo directory adjacent to the PKGBUILD. I suppose that this has been unintended, otherwise it would have been described with the changes to the msg2 call. The diff below restores the behavior where CARGO_HOME is not changed when it has been defined and nonempty before.

  • I recently tried some AUR helper (instead of my home-grown mixture of Makefiles and devtools) for a clean-chroot build and found that the build does not use the .cargo cache. That is because the helper splits the build (presumably using makepkg options --nobuild resp. --noprepare). Thus environment settings in prepare() do not get propagated to later stages.

Therefore I now propose to define a function _setup_build_env for setting up environment variables and then calling it where needed. The patch below does that and even provides the luxurious option -v because we want the info message to be output at most once.

@@ -18,12 +18,11 @@ backup=("etc/gitconfig.$_name")

-prepare() {
-  # Assist chroot builds with a persistent cargo cache (hat tip @ccorn for this patch)
+_setup_build_env() {
+  # Assist chroot builds with a persistent cargo cache
   if [ -d "$startdir/.cargo" ]; then
-    export _cargo="${CARGO_HOME:-$startdir/.cargo}"
-  else
+    export CARGO_HOME="${CARGO_HOME:-$startdir/.cargo}"
+  elif [ "$1" = "-v" ]; then
     msg2 "NOTE : If you're building in a (clean) chroot and want a persistant
             cargo cache folder specific for this package, you can create
             an empty '.cargo' directory next to the PKGBUILD.  This will
@@ -31,22 +30,24 @@ prepare() {
             when the CARGO_HOME variable is already set in your environ-
+  export RUSTUP_TOOLCHAIN=stable
+prepare() {
   sed -i "/path *=/s|=.*|= /etc/gitconfig.$_name|" "$_name-$pkgver/themes.gitconfig"

 build() {
+  _setup_build_env -v
   cd "$_name-$pkgver"
   # git2 cannot be built with current nightly due to a regression; for ref.:
-  CARGO_HOME="$_cargo" \
   cargo build --release --locked --target-dir ./target

 check() {
+  _setup_build_env
   cd "$_name-$pkgver"
-  CARGO_HOME="$_cargo" \
   cargo test --release --locked --target-dir ./target

Kr1ss commented on 2021-05-30 09:19

Thx a lot @K900. I'm pinning your comment.

EDIT/ The cargo calls are now updated so that stable is used to compile, even when a diffent default is configured.