Package Details: ripgrep-git 11.0.1.r8.5ce2d73-1

Git Clone URL: https://aur.archlinux.org/ripgrep-git.git (read-only, click to copy)
Package Base: ripgrep-git
Description: A search tool that combines the usability of The Silver Searcher with the raw speed of grep.
Upstream URL: https://github.com/BurntSushi/ripgrep
Licenses: MIT, Unlicense
Conflicts: ripgrep
Provides: ripgrep
Submitter: sigma
Maintainer: sigma (burntsushi)
Last Packager: sigma
Votes: 12
Popularity: 0.000000
First Submitted: 2016-09-24 00:05 (UTC)
Last Updated: 2019-05-14 09:31 (UTC)

Dependencies (5)

Required by (41)

Sources (1)

Latest Comments

linkmauve commented on 2021-01-31 19:05 (UTC) (edited on 2021-01-31 19:21 (UTC) by linkmauve)

Hi, you shouldn’t set RUSTFLAGS manually in build(), and especially not set it to -C target-cpu=native as it will prevent the built package from running on CPUs which don’t have at least all of the flags of the building CPU, for instance when building on Haswell and running on Ivy Bridge the generated AVX2 instructions won’t be available.

The proper way to set RUSTFLAGS is in each user’s /etc/makepkg.conf, it’s already set on line 53 on current pacman.

SolarAquarion commented on 2019-05-10 13:28 (UTC)

ripgrep should probably have fish as a optdepend for completions

ronjouch commented on 2019-04-13 01:09 (UTC)

Since today and https://github.com/fish-shell/fish-shell/commit/5989a92dae3dcbed3f868345811ab178f04bf3c8 , build of fish-git succeeds but installation fails with:

error: failed to commit transaction (conflicting files)
fish-git: /usr/share/fish/completions/rg.fish exists in filesystem (owned by ripgrep)

What's the standard in Arch? Should fish or ripgrep provide the completions? Asked the same question in AUR / fish-git ( https://aur.archlinux.org/packages/fish-git/#news )

tei8ho commented on 2018-09-16 17:06 (UTC) (edited on 2018-09-16 17:07 (UTC) by tei8ho)

I assume this on me, but I get zsh completions but not bash ones.

==> Entering fakeroot environment...

==> Starting package()...

install: target '/home/USERNAME/Code/makepkg/build/ripgrep-git/pkg/ripgrep-git/usr/share/bash-completion/completions/rg' is not a directory

==> ERROR: A failure occurred in package(). Aborting...

warning: package ripgrep-git failed to build, skipping

[USERNAME@LAPTOP ripgrep]$ ls ~/Code/makepkg/build/ripgrep-git/pkg/ripgrep-git/usr/share/zsh/site-functions/

berquist commented on 2018-04-01 00:18 (UTC)

I was having trouble installing because the find call for the manpage was returning multiple hits. It's crude, but this solved it:

install -Dm644 $(find "$srcdir/$pkgname"/target/release/build -name "rg.1" | head -n 1) "$pkgdir/usr/share/man/man1/rg.1"

mrkline commented on 2017-01-23 18:58 (UTC) (edited on 2017-01-23 18:59 (UTC) by mrkline)

Thanks for fixing things up so quickly! Unfortunately, I think a few more tweaks need to be made. First, you grab the latest tag with git tag | grep -v "^[a-zA-Z]" | tail -n1 but unless I'm mistaken, `git tag` prints tags in lexicographic order by default. (So, some future 0.4.10 release would be listed before 0.4.2). Based on http://stackoverflow.com/a/29601177, I believe we want something along the lines of: git tag --sort=-v:refname | grep '^[0-9]' | head -1 Also, according to the VCS packaging guidelines, I believe we want a version string resembling: <last tagged version>.r<commits since tag>.<SHA of HEAD> But the current pkgver() gives <last tagged version>.r0.<SHA of the last tagged version> I believe a pkgver that gives the desired output resembles the following: pkgver() { local tag=$(git tag --sort=-v:refname | grep '^[0-9]' | head -1) local commits_since=$(git rev-list $tag..HEAD --count) echo "$tag.r$commits_since.$(git log --pretty=format:'%h' -n 1)" } Thanks again!

mrkline commented on 2017-01-21 20:54 (UTC)

After a bit more digging, the problems might be that the latest tag (wincolor-0.1.2-6) has a smaller version number than the one in the PKGBUILD (0.1.17.2). At least, that's the impression I get from cower: $ cower -u :: ripgrep-git wincolor.0.1.2.6.rb678862-1 -> 0.1.17.2.rf5eb36b-1 I assume the tags "wincolor-0.1.2", "ignore-0.1.6", etc. just pertain to dependencies, but could pkgver() in the PKGBUILD be adjusted accordingly?

mrkline commented on 2017-01-20 21:58 (UTC)

For some reason, pacaur attempts to rebuild this package every time I run `pacaur -Syu`, even without `--devel`. This suddenly started happening in the last few days - does anybody have any idea what might cause it? I did notice that the version "number" now starts with `wincolor`, e.g., `ripgrep-git-wincolor.0.1.2.4.r7a926d0-1`. Could something be off about how `pkgver()` works in the PKGBUILD, compared to other dev packages?