Fzf: Errors on fzf --version

[anstadnik]

• [x] I have read through the manual page (man fzf)
• [x] I have the latest version of fzf
• [x] I have searched through the existing issues

Info

• OS
  
  
  
  • [x] Linux
  
  
  • [ ] Mac OS X
  
  
  • [ ] Windows
  
  
  • [ ] Etc.
  
  
• Shell
  
  
  
  • [ ] bash
  
  
  • [x] zsh
  
  
  • [ ] fish
  
  

Problem / Steps to reproduce

fzf --version returns nothing.
I have Arch Linux. When I install fzf from pacman, and run fzf --version, I got nothing. If I install fzf-git from AUR, which should download and build the last version from git, I have the following output:

 Failed to Failed to run "fzf --version":version information missingpanic: Invalid build: version information missing

goroutine 1 [running]:
main.main()
        *path_to_fzf*/fzf/main.go:13 +0x8b

Some plugins rely on that info, for example, coc-fzf-preview excension for coc.nvim for Neovim.

[junegunn]

The package build is broken. Please report the issue to the package maintainers.

[yannick1974]

Hi @junegunn,
I have the same problem. If I build the release tar.gz, the "fzf --version" is empty; although if I clone the git repository and build from it, the returned version is "0.24.0-1 (3304f28)".

[junegunn]

Thanks for letting me know but there's nothing I can do. You should report the problem to the package maintainers so they can fix the build.

[yannick1974]

Oh, no. I'm building from the release tarball. The problem is that the Makefile gets the version number from git which obviously does not work in the tarball. You should state in BUILD.md that the instructions apply to a clone of the git repository only.

[yannick1974]

Of course, manually changing VERSION in the Makefile does the trick. ;-)

[junegunn]

@yannick1974 Oh I see, thanks for pointing that out.

[anstadnik]

Are you planning to fix that? I assume that it's the reason that the problem occurs when FZF is installed from packages. If you aren't gonna fix that, the issue can be closed.

[Foxboron]

@junegunn

Yo, it was missed as there was no mentions of the version change in the changelog and the Arch package never utilized the Makefile for building.

Changing to the Makefile requires git obviously, but I'm curious if you intend to keep signing git tags and commits with your GPG key. Can I pin it in the package?

[junegunn]

@Foxboron I don't know which packages are out there and how they are built. No one really contacted me before releasing their packages in their ways. So how would I know? 🤔 What I regularly do is to push signed tags, build official binaries, upload them to the GitHub releases page with the tag, and make sure that they work as I planned. I haven't guaranteed anything beyond that.

I'm curious if you intend to keep signing git tags and commits with your GPG key

Yes.

Can I pin it in the package?

Not sure what that means. I'm not familiar with the process.

[junegunn]

Anyways, I now use https://github.com/junegunn/fzf/blob/master/.goreleaser.yml to build binaries.

[Foxboron]

I don't know which packages are out there and how they are built.

Most probably use the github tarballs from the published tags, and some use git.

I haven't guaranteed anything beyond that.

But go get was described as working prior to this release. The assumption of this continuing to work is gone and removed when it was pointed out.

Not sure what that means. I'm not familiar with the process.

It implies that I add the GPG keyid to the package and if the release key changes there should be cross-signatures to establish trust between new release keys.

[junegunn]

It was my oversight not to update the doc accordingly. I even forgot go get way existed as I haven't used it for years. I would've paid more attention to it if I knew there were packages that use the method. Anyway, since 3304f284a565bc77d8a1009d8e1770e651b95c5c, fzf will not even work if version information is not injected, so hopefully, this will make package maintainers notice that they should update their methods.

[xalexalex]

Hey,
chiming in to say that the fact that fzf --version doesn't work in v24.0 does not only impact packagers, but also fzf-vim, which gets a blank string as version and refuses to run anything, complaining of E605: Exception not caught: You need to upgrade fzf. Found: (fzf). Required: 0.23.0 or above.

[junegunn]

With b5e0e29ec6a149fa948c0399af34572d450d3dda, binaries will be given the default version number (an imprecise one, 0.24, no patch version) when you forgot to pass a proper -ldflags so that they will pass the test.

0.24.1 is out and this will be fixed soon one way or another.

[kabeersvohra]

Created a ticket with apt maintainers to upgrade this to the latest version: https://answers.launchpad.net/ubuntu/+source/fzf/+question/693783