Package Details: rav1e-git 0.3.3.r326.ged4d6781-1

Git Clone URL: https://aur.archlinux.org/rav1e-git.git (read-only, click to copy)
Package Base: rav1e-git
Description: The fastest and safest AV1 encoder
Upstream URL: https://github.com/xiph/rav1e
Licenses: custom, BSD
Conflicts: rav1e
Provides: librav1e.so, rav1e
Submitter: Chocobo1
Maintainer: Chocobo1
Last Packager: Chocobo1
Votes: 7
Popularity: 0.013029
First Submitted: 2018-02-25 07:31
Last Updated: 2020-07-18 04:40

Required by (13)

Sources (1)

Latest Comments

1 2 Next › Last »

Chocobo1 commented on 2020-07-18 04:40

Since ffmpeg now depends on rav1e, could you please add librav1e.so to provides?

Sure, done.

another commented on 2020-07-17 19:59

Since ffmpeg now depends on rav1e, could you please add librav1e.so to provides?

linkmauve commented on 2020-05-15 00:10

Hi, cargo-c is now in community, you can add it to makedepends and stop building it. :)

Chocobo1 commented on 2020-03-23 13:59

error: The subcommand 'install' wasn't recognized \ changing in line 46 "$srcdir/bin/cargo-cinstall" install to "$srcdir/bin/cargo-cinstall" cinstall \ does work. I think cargo-c v0.6.0 did break that(same with rav1e 0.3.1-1)

Thanks! Fixed now.

toggleton commented on 2020-03-23 13:02

error: The subcommand 'install' wasn't recognized

changing in line 46 "$srcdir/bin/cargo-cinstall" install to "$srcdir/bin/cargo-cinstall" cinstall

does work. I think cargo-c v0.6.0 did break that(same with rav1e 0.3.1-1)

gmes78 commented on 2020-01-23 04:06

I see no such file on my builds, where does it come from?

I'm using the Rust nightlies, maybe it's because of that. This file is also mentioned in the Rust packaging guidelines.

Chocobo1 commented on 2020-01-23 03:54

/usr/.crates2.json should be removed from the package.

I see no such file on my builds, where does it come from?

gmes78 commented on 2020-01-23 00:29

/usr/.crates2.json should be removed from the package. I also suggest passing the -f flag to rm, so that if /usr/.crates2.json (or /usr/.crates.toml) isn't there, the build doesn't fail.

gmes78 commented on 2019-11-22 18:21

OK, updated although I haven't really compared the run time differences. A quick glance reveals that cargo-c is spending most of its time waiting for rustc to complete so I guess time difference won't be significant.

I made a comparison just now:

$ rm -rf src/ pkg/ && makepkg -o --noprepare && time makepkg --noarchive
makepkg --noarchive  906,78s user 14,30s system 215% cpu 7:07,42 total
$ git reset --hard PKGBUILD && git pull
$ rm -rf src/ pkg/ && makepkg -o --noprepare && time makepkg --noarchive
makepkg --noarchive  630,62s user 14,11s system 177% cpu 6:03,62 total

The difference between the former (cargo-c with optimizations) and the latter (cargo-c without optimizations) is that the latter is 64 seconds faster. Which is the exact same difference as my other comparison.

In other words, disabling optimizations for cargo-c doesn't impact its runtime speed in any noticeable way.

Chocobo1 commented on 2019-11-22 03:24

May I suggest building cargo-c in debug mode?

OK, updated although I haven't really compared the run time differences. A quick glance reveals that cargo-c is spending most of its time waiting for rustc to complete so I guess time difference won't be significant.