Package Details: yay 10.3.1-1

Git Clone URL: https://aur.archlinux.org/yay.git (read-only, click to copy)
Package Base: yay
Description: Yet another yogurt. Pacman wrapper and AUR helper written in go.
Upstream URL: https://github.com/Jguer/yay
Keywords: arm AUR go helper pacman wrapper x86
Licenses: GPL3
Submitter: jguer
Maintainer: jguer
Last Packager: jguer
Votes: 1534
Popularity: 52.03
First Submitted: 2016-10-05 17:20
Last Updated: 2021-07-29 20:25

Pinned Comments

jguer commented on 2021-05-20 11:41

With pacman 6 arriving a rebuild of yay will be necessary, if you upgrade pacman without upgrading yay at the same time, yay will not run after. I'm bumping the pkgrel so it shows up on the upgrade list (and will do so when pacman transitions from staging->core)

In case you end up with a non-functioning yay after the upgrade:

$ pacman -S --needed git base-devel
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si

jguer commented on 2019-04-16 14:08

I cannot delete the spam comments appearing regularly in this page, which has also led me to disable notifications from here. I remind that the best way to receive support or report a problem is through the Upstream URL.

Latest Comments

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

Mr.Tao commented on 2021-07-20 09:07

The package is indeed FTBFS with lto enabled. lto is a legal compiler option, thus the argument that lto is not enabled by default is not valid. It is the responsibility of the maintainer to filter out CFLAGS which are not compatible with the package.

madjoe commented on 2021-07-17 19:08

I encountered this issue with yay, but the maintainer claim it has nothing to do with yay. Could it be a packaging issue?

I tried to update python2-lxml, but for some reason the package is trying to build against python3.

https://github.com/Jguer/yay/issues/1554

masterberg commented on 2021-07-15 22:26

I came here to second what @mikoxyz said; yay should not be broken for users that use lto.

yrlf commented on 2021-07-13 19:09

I came here to second what @mikoxyz said; yay should not be broken for users that use lto.

mikoxyz commented on 2021-06-28 15:40

@yochananmarqos: True, but it doesn't hurt to disable it for those who do have lto enabled in their makepkg.conf

yochananmarqos commented on 2021-06-20 14:15

@mikoxyz: lto is not enabled by default.

mikoxyz commented on 2021-06-20 06:37

This package doesn't build with lto enabled; this patch disables lto for this package

diff --git a/PKGBUILD b/PKGBUILD
index 2aa659e..316d638 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -16,6 +16,7 @@ optdepends=(
 makedepends=(
   'go'
 )
+options=('!lto')
 source=("${pkgname}-${pkgver}.tar.gz::https://github.com/Jguer/yay/archive/v${pkgver}.tar.gz")
 sha256sums=('1782cd4f96c56cc3c92b9fc904873a15a95aecba09dc22c8a6a37a092a1d20cf')

crdx commented on 2021-06-12 22:57

@ozz It might be, but the AUR convention is the bare package name is the source build, *-bin is the binary and *-git is the source build of the tip of the git repo. I tend to look for the *-bin versions of packages first if I can find them.

ozz commented on 2021-06-12 22:54

@crdx Yes, yay-bin is much better, thanks! I would argue that should be the default "yay" and there should be a "yay-src" or something. 600MB is a lot of space on constrained systems.

crdx commented on 2021-06-12 09:58

@ozz

You can use yay-bin if you don't want to have to build it locally. Although if you feel it's "not much more than a wrapper around git and makepkg" then maybe you'd rather not use it at all?