Package Details: alacritty-git

Git Clone URL: (read-only, click to copy)
Package Base: alacritty-git
Description: A cross-platform, GPU-accelerated terminal emulator
Upstream URL:
Keywords: GPU rust terminal
Licenses: Apache
Conflicts: alacritty
Provides: alacritty
Submitter: quininer
Maintainer: quininer
Last Packager: quininer
Votes: 90
Popularity: 0.28
First Submitted: 2016-11-01 13:53
Last Updated: 2020-09-03 15:24

Required by (13)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

SoN commented on 2020-11-22 22:24

Hello, I noticed some mixed up spaces and tabs in the indentation, so here I provide this humble patch:

Thanks for maintaining this package and have a nice day.

codyps commented on 2020-11-07 21:13

Thanks for getting back to me on this @quininer. It's not entirely clear from your reply what your concern is here, and I hope you could clarify that for me.

The patch I've proposed doesn't require manual action from folks using makepkg, it just means that a cargo home that is separate from the one they use for doing normal cargo builds will be used for building packages. Is there some type of non-packaged & non-tracked configuration in the cargo home that we expect to have applied to the package? Alternately, are we concerned about having dependencies for this package downloaded/built separately from a particular users cargo home?

Generally, it's advisable to build arch packages in ways that don't depend on other items in the user's environment (which is why so often folks talk about using clean chroots for building packages). This type of thing (not depending on other random state) leads me towards the idea that re-using an existing cargo home isn't a great choice here.

I don't think it's a good idea to require package-specific environment modification to enable a package to build when one is using completely normal options (like debug). It's also the case that the current PKGBUILD behavior here (installing files into home dir when debug is enabled) does not appear to be supported by the Arch package guidelines.

If you're still concerned about having a separate cargo home: consider that you may be able to either: 1. find appropriate -ffile-prefix-map options, or 2. work with makepkg itself to improve support for this particular use case.

If you decide you wish to persue either of those, I encourage fixing the package in the mean time by applying the patch I've already proposed.

Finally, if there's a desire not to support debug for some reason, the PKGBUILD should explicitly disable it in it's OPTIONS (OPTIONS += (!debug)) (I don't like that solution, but it's better than generating packages that depend on the building user's home dir and install files into that same building user's home dir).

quininer commented on 2020-11-07 07:19

@codyps If you need debug package, you can add the environment variable before makepkg, instead of requiring everyone to copy a $HOME/.cargo.

codyps commented on 2020-11-05 22:45

This package still doesn't work properly with OPTIONS+=(debug). Please apply the patch I provided in my previous comment.

codyps commented on 2020-08-12 16:14


Currently, when OPTIONS+=(debug) is set in makepkg.conf, this package tends to install source code files into the home directory of the user that built the package.

This appears to be due to the debug info referencing files in the $HOME/.cargo directory (which are picked out of the debug info to fill the -debug package).

Normally, the debug info would be edited so that all files end up under the /usr/src/debug/<pkgname> directory, but if the source files exist outside of the srcdir (like files in `$HOME/.cargo) this doesn't work.

To resolve this, the environment variable CARGO_HOME should be set to place the directory formerly at $HOME/.cargo into the srcdir.

Here's a patch which makes this change and results in proper /usr/src/debug content:

sinshutu commented on 2020-03-15 01:19

Thank you for the maintenance. However, the build failed at this commit: c79216caadd5b287f27048fc97454022f791ad73

I don't know the cause, but I solved it by the following method

diff --git a/PKGBUILD b/PKGBUILD
index 79ed747..621b5ca 100644
@@ -33,7 +33,7 @@ package_alacritty-git() {

        cd $_pkgname

-       desktop-file-install -m 644 --dir "$pkgdir/usr/share/applications/" "$srcdir/$_pkgname/extra/linux/alacritty.desktop"
+       desktop-file-install -m 644 --dir "$pkgdir/usr/share/applications/" "$srcdir/$_pkgname/extra/linux/Alacritty.desktop"

        install -D -m755 "target/release/alacritty" "$pkgdir/usr/bin/alacritty"
        install -D -m644 "extra/" "$pkgdir/usr/share/man/man1/alacritty.1"

There is no confirmation, but there may be a compatibility problem with desktop-file-utils

$ yay -Qi desktop-file-utils
name                   : desktop-file-utils
version                : 0.24-2

FichteFoll commented on 2020-02-20 00:42

It appears the terminfo files are now included in ncurses, which is probably why the split package has been removed.

However, git still needs to be added as a makedep.

~ λ pacman -Fl ncurses | grep alacritty
ncurses usr/share/terminfo/a/alacritty
ncurses usr/share/terminfo/a/alacritty+common
ncurses usr/share/terminfo/a/alacritty-direct

~ ∀ pacman -Fl alacritty-terminfo-git
alacritty-terminfo-git usr/
alacritty-terminfo-git usr/share/
alacritty-terminfo-git usr/share/terminfo/
alacritty-terminfo-git usr/share/terminfo/a/
alacritty-terminfo-git usr/share/terminfo/a/alacritty
alacritty-terminfo-git usr/share/terminfo/a/alacritty-direct

FFY00 commented on 2020-02-18 23:26

1ace, sorry for the late reply, AUR is awful at handling notifications.

My comment last comment was referring to alacritty-terminfo (somehow I forgot to mention it, :facepalm:), which you now have seemed to have removed. Please reinstate it and make it any.

jhenson commented on 2020-01-27 22:08

This package should have a git listed as a make dep.

1ace commented on 2020-01-22 09:35

@FFY00: all your comments are correct except the last one.

The arch field is about the compatibility to use the package, not to build it. Once compiled, alacritty can only run on the arch it was built for, not on any arch (like a simple script would, for instance), so the current value is correct and changing it to any would be wrong.

Again, all your other comments are good and should be applied to this package.