You are not logged in.

#1 2020-07-29 21:52:54

cmdywrtr27
Member
Registered: 2019-11-23
Posts: 5

95% of the time I use yay, it fails

hi, i am having a weird issue with YAY. whenever i open a terminal and try to install a package from the AUR, i do 'yay -S 'whatever package'' but 95%+ of the time, it fails with ERROR: An unknown error has occurred. Exiting... error downloading sources: 'whatever package'. when prompted, i always just hit 'enter' to go with the default option. the research i could do told me that it isn't normal for that to happen so I am not really sure how to go about diagnosing this issue or what commands to input so any help would be greatly appreciated.

Last edited by cmdywrtr27 (2020-07-29 21:53:39)

Offline

#2 2020-07-29 21:59:34

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 9,866
Website

Re: 95% of the time I use yay, it fails

Then don't use yay.


Sakura:-
Mobo: MSI X299 TOMAHAWK ARCTIC // Processor: Intel Core i7-7820X 3.6GHz // GFX: nVidia GeForce GTX 970 // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 5x 1TB HDD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#3 2020-07-29 22:00:12

loqs
Member
Registered: 2014-03-06
Posts: 11,206

Re: 95% of the time I use yay, it fails

Please post the command you used and its full output.
Please also build the same PKGBUILD with makepkg and post the output of that for comparison.

Offline

#4 2020-07-30 00:21:49

orhun
Member
Registered: 2020-03-31
Posts: 2

Re: 95% of the time I use yay, it fails

pacman -Syu first.

then you might try trizen.

Offline

#5 2020-07-30 01:36:27

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 17,339

Re: 95% of the time I use yay, it fails

Please remember, neither yay, yogurt, or trizden are Arch Linux projects.  I always dread threads along these lines, because these "helpers" reflect badly upon Arch Linux, and they should not.   To compound things, the seasoned members here, who do know what they are doing where it comes to Arch, are not going to be offering any help -- they don't use these tools.  Well meaning members who may not be as experienced with Arch Linux may try to help; the problem being these "helpers" really do not help.   And, as I will say, as did WorMzy, don't use them.  I am not alone in this; I can think of no staff here that would disagree.  And then we are accused of being unwelcoming.

Please, learn to use makepkg.  And, real helpers like Auracle.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#6 2020-07-30 04:58:38

Awebb
Member
Registered: 2010-05-06
Posts: 5,513

Re: 95% of the time I use yay, it fails

ewaller wrote:

And, real helpers like Auracle.

If it wasn't for the build order feature, I'd use https://aur.archlinux.org/rpc.php all the time.

Offline

#7 2020-07-30 10:01:39

d_fajardo
Member
Registered: 2017-07-28
Posts: 770

Re: 95% of the time I use yay, it fails

Please forgive my naivety but this thread gives me the opportunity to ask questions. I use yay but I learned how to use makepkg as well. I have experimented writing small PKGBUILDs myself for myself my own small private 'repository' and of course I need to learn how to use makepkg. Also those times yay doesn't work, I usually can stall via makepkg.
My questions are, why are there so much negativity among seasoned users with these helpers? Are they implemented in a way contrary to Arch? Are they mainly because they are not Arch Linux projects? Do they have security loopholes? Could they trigger something that can break a system?
Again these are questions I've been meaning to ask and I think this is just a good opportunity.

Offline

#8 2020-07-30 11:02:11

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 10,101

Re: 95% of the time I use yay, it fails

The problem is that the underlying process is hidden from the user. I don't have a general issue with helpers and I've extensively used even yaourt when it was still alive . But that's all under the pretense that I can easily switch to makepkg and identify and discern makepkg from helper issues.  If the OP had done the necessary work to familiarize themselves with the general process I doubt that this thread would exist in the form that it does.  That's when the negativity comes up, because it's clear by the thread structure that this was not done and you really, really should be able to double check issues with makepkg to make informed decisions.

As for security loopholes/system breakage, you are running additional code, that's always an additional interaction of potential failures. How do you know that when the sudo prompt comes up that it is really only used to run the appropriate invocation of makepkg and not installing a back door behind you? How do you know the maintainer didn't typo it's AUR cache deletion procedure and rm's your entire root ? You either check the source of the helper, trust its maintainer or don't use it, or all of the above.

Offline

#9 2020-07-30 11:39:16

d_fajardo
Member
Registered: 2017-07-28
Posts: 770

Re: 95% of the time I use yay, it fails

Thanks for the answers V1del. As always very helpful.

Offline

#10 2020-07-30 12:01:39

Buddlespit
Member
From: Chesapeake, Va.
Registered: 2014-02-07
Posts: 470

Re: 95% of the time I use yay, it fails

As an avid user of 'yay', I have to say that you (OP) should really learn how to make packages manually (makepkg) before trying ANY AUR helper. Not only will this give you a better understanding of what's happening when a PKBUILD is used (when you inspect a PKBUILD before installing), but also an idea of where to look when something goes wrong. Have you looked at the PKBUILD for 'yay'? Do you know where the configuration file is?

I'm a 'lazy' Linux user. My KDE desktop has been running without reinstallation for a few years now. When I run into a problem, nine times out of ten, it's my fault. I've worked out most of the kinks in my system through reading, both the wiki and forums. This has gone from being a hobby to my primary desktop, so I want it to run properly all the time. That takes understanding and a willingness to learn something new.

Welcome (belatedly) to Arch Linux. Now, go learn something!


TUF GAMING X570-PLUS, Ryzen 7 3800X, RTX 2070 SUPER, Arctis 5 usb audio, 16GB 3800 cl15 (1900 inf fab) memory, 1 nvme, 3 ssd, 1 hhd (8TB tot.)

Offline

#11 2020-07-30 15:29:33

cmdywrtr27
Member
Registered: 2019-11-23
Posts: 5

Re: 95% of the time I use yay, it fails

thanks buddlespit, i hope to achieve the same desktop as u describe but the only "issue" is there is no real 'guide' so-to-speak on learning linux from beginning to end. everything i have learned up to this point has been from reading and doing it on my own, i have probably installed arch 25+ times plus other distro's and i sometimes get conflicting answers thats why i wish there was a guide of some sort to help new linux users. That is kind of a half sarcastic and half real comment. i know it isn't going to happen but in a perfect world i wish we had a proven guide to show the proper way to learn instead of gathering information from lots of different sources and using our best judgement to decide what is right or what is the best way to do things.

anyway, back to earlier, loqs asked to see the output of the command i used. im just gunna post a screenshot if that is okay. i just dont feel like typing a whole lot today.

also, ewaller, if u come back to this post, i fully understand what u are saying, as a follow up question, youre saying to stay away from helpers and learn makepkg? i would rather learn arch the 'right way' instead of the easy way or whatever is recommended on youtube.

https://i.imgur.com/e2IjfJ5.png

https://i.imgur.com/rgn60M7.png

Offline

#12 2020-07-30 15:39:57

Slithery
Forum Moderator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 3,931

Re: 95% of the time I use yay, it fails

cmdywrtr27 wrote:

anyway, back to earlier, loqs asked to see the output of the command i used. im just gunna post a screenshot if that is okay. i just dont feel like typing a whole lot today.

No, that isn't OK...
CoC - Posting pictures and code
https://wiki.archlinux.org/index.php/Li … in_clients


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#13 2020-07-30 17:37:38

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 29,009
Website

Re: 95% of the time I use yay, it fails

cmdywrtr27 wrote:

instead of gathering information from lots of different sources and using our best judgement to decide what is right or what is the best way to do things.

This is the textbook definition of learning.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#14 2020-07-30 17:40:31

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,016
Website

Re: 95% of the time I use yay, it fails

WorMzy wrote:

Then don't use yay.

What he said. ^^^

The topic of your post, "95% of the time I use yay, it fails," begs the question: why do you continue to use it?  pacman -Rs yay


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#15 2020-07-30 17:50:13

zpg443
Member
Registered: 2016-12-03
Posts: 90

Re: 95% of the time I use yay, it fails

I like aurutils and maintaining a local repository. It's not difficult, folks.

Offline

#16 2020-07-30 18:25:46

d_fajardo
Member
Registered: 2017-07-28
Posts: 770

Re: 95% of the time I use yay, it fails

cmdywrtr27 wrote:

the only "issue" is there is no real 'guide' so-to-speak on learning linux from beginning to end

I sympathize with you. There is the installation guide in the beginning but after that you're pretty much on your own. That is because everyone has a different 'end' for their machine but really Arch has one of the best and uptodate documentation for whatever 'end' you aim.

cmdywrtr27 wrote:

everything i have learned up to this point has been from reading and doing it on my own

Welcome to the club! You're not alone.

cmdywrtr27 wrote:

i sometimes get conflicting answers

You're probably asking the wrong questions or looking for answers in the wrong places. There can be heated discussions on this forum discussing solutions to problems but rarely it happens there are conflicting answers.

cmdywrtr27 wrote:

i would rather learn arch the 'right way' instead of the easy way or whatever is recommended on youtube.

That's the spirit! But forget the youtubes. Read the docs and if you don't understand things clearly, admit it humbly to this forum and ask for clarification.

For what you're experiencing, perhaps:
https://wiki.archlinux.org/index.php/Arch_Build_System

That link is not an easy take but an important knowledge for understanding Arch.
And learn makepkg - it's fun doing it with makepkg. A bit slow but fun!

Last edited by d_fajardo (2020-07-30 18:42:05)

Offline

#17 2020-07-30 19:16:53

loqs
Member
Registered: 2014-03-06
Posts: 11,206

Re: 95% of the time I use yay, it fails

As makepkg is failing due to something raising SIGUSR1 that needs to be investigated first.
If you create a new user and run makepkg as that new user on the zplug PKGBUILD does that produce the error?

Offline

#18 2020-07-30 19:19:34

Buddlespit
Member
From: Chesapeake, Va.
Registered: 2014-02-07
Posts: 470

Re: 95% of the time I use yay, it fails

Ok, Slithery got you on the pics. But from the pics, it doesn't look like a yay issue, especially if building the package with makepkg doesn't work. Could you post your makepkg.conf? Use the  tags, it'll keep the moderators from beating you about the head and shoulders with the code of conduct. Plus, it looks 'kewl'.

edit: beaten by loqs

Last edited by Buddlespit (2020-07-30 19:20:28)


TUF GAMING X570-PLUS, Ryzen 7 3800X, RTX 2070 SUPER, Arctis 5 usb audio, 16GB 3800 cl15 (1900 inf fab) memory, 1 nvme, 3 ssd, 1 hhd (8TB tot.)

Offline

#19 2020-07-31 10:11:53

cmdywrtr27
Member
Registered: 2019-11-23
Posts: 5

Re: 95% of the time I use yay, it fails

i hope this is the right conf u were talking about, there are two different ones. this one is from /etc/makepkg.conf and the other is in /usr/bin/. these files should be okay, i have never edited them before... i'll make a new user and get back to u on if that one acts the same way.

 
#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
#  Format: 'protocol::agent'
DLAGENTS=('file::/usr/bin/curl -gqC - -o %o %u'
          'ftp::/usr/bin/curl -gqfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
          'http::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'https::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'rsync::/usr/bin/rsync --no-motd -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget

#-- The package required by makepkg to download VCS sources
#  Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
            'git::git'
            'hg::mercurial'
            'svn::subversion')

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!distcc !color !ccache check !sign)
#  A negated environment option will do the opposite of the comments below.
#
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#-- check:    Run the check() function if present in the PKGBUILD
#-- sign:     Generate PGP signature file
#
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Default: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug)
#  A negated option will do the opposite of the comments below.
#
#-- strip:      Strip symbols from binaries/libraries
#-- docs:       Save doc directories specified by DOC_DIRS
#-- libtool:    Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs:  Leave empty directories in packages
#-- zipman:     Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge:      Remove files specified by PURGE_TARGETS
#-- debug:      Add debugging flags as specified in DEBUG_* variables
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug)

#-- File integrity checks to use. Valid: md5, sha1, sha224, sha256, sha384, sha512, b2
INTEGRITY_CHECK=(md5)
#-- Options to be used when stripping binaries. See `man strip' for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip' for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip' for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
#-- Directory to store source code in for debug packages
DBGSRCDIR="/usr/src/debug"

#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""

#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(gzip -c -f -n)
COMPRESSBZ2=(bzip2 -c -f)
COMPRESSXZ=(xz -c -z -)
COMPRESSZST=(zstd -c -z -q -)
COMPRESSLRZ=(lrzip -q)
COMPRESSLZO=(lzop -q)
COMPRESSZ=(compress -c -f)
COMPRESSLZ4=(lz4 -q)
COMPRESSLZ=(lzip -c -f)

#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
PKGEXT='.pkg.tar.zst'
SRCEXT='.src.tar.gz'

Last edited by cmdywrtr27 (2020-07-31 10:13:11)

Offline

#20 2020-07-31 12:23:11

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: 95% of the time I use yay, it fails

d_fajardo wrote:

My questions are, why are there so much negativity among seasoned users with these helpers?

I suspect mostly because they break constantly and not only fail in their primary purpose of making installing AUR packages easier, but in fact quite often make it much much harder.  Case in point: this thread.

d_fajardo wrote:

Are they implemented in a way contrary to Arch?

Not really, although there is a long history of authors of AUR helpers giving absolutely horrific and dangerous advice with is contrary to the safe or proper use of an arch linux system.  This has likely contributed a bit, but it's not the main issue.

d_fajardo wrote:

Are they mainly because they are not Arch Linux projects?

Nope, this one I'm sure is not relevant.  Some of the most loved and frequently used bits of software discussed on the forums are not arch linux projects.  Vim, i3, suckless tools (dwm, st, etc), the kernel itself: none of these are arch linux projects.

d_fajardo wrote:

Do they have security loopholes? Could they trigger something that can break a system?

I'm not aware of specific security loopholes, but the haphazard way some of them are written raises legitimate suspicion of this.  As for triggering something that can break the system ... yes and no.  If used properly this is unlikely, but by their nature several (not all) AUR helpers make it so easy to misuse them that they effectively incentivize bad habits and bad choices.  So they trigger the end user to break their own system.

Note here I say "most" a couple of times.  This is particularly true of one that I just noticed has been removed from our wiki pages on AUR helpers: it's not even mentioned anymore which is great.  It used to be the go-to tool of every foolish new archer.  This unnamed helper was undoubtedly the worst of the worst.  But is yay much better?  Does yay even try to be much better?  Yay is a fork of "the evil one" and even named itself after it.  I think yay's maintainer deserves a bit of credit for the degree to which they've mitigated it's harm, but frankly I just think it's a fools errand to try to patch up something that was so poorly designed from the start.  Yay is the result of attempting to polish a turd.

So when a thread starts with the claim "95% of the time yay fails" some of us don't wonder what's going wrong and see the opportunity to solve that problem.  Rather we think: huh, you mean it actually works 5% of the time?

Some people define a bug as software behavior that is counter to the intent.  Others define a bug as behavior that is counter to expectations.  And if we don't expect something to work, failing to work is not really a bug, but just the design of the software.

Last edited by Trilby (2020-07-31 12:26:00)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#21 2020-07-31 16:07:27

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,515

Re: 95% of the time I use yay, it fails

Nah, I'll take yaourt over pacaur or pikaur or trizen any day.

Source: I'm one of the maintainers of pacman/makepkg, and I've read the code for both yaourt and pacaur. The latter was far more terrifying. But lots of ignorant people insisted the former is "literally the devil" and the latter is "the best thing about Arch and everyone should use it, it's the ONLY correct way to use the AUR". So it became a meme.

I know exactly why people think yaourt is "unusually bad" compared to other AUR helpers:

- unlike pacaur, it wasn't actively promoted by the developer as an elitist "I'm better than other AUR helpers" superiority complex

- unlike yay, it's no longer in the business of adding new features (but it doesn't automatically follow that what used to work, stopped working...)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Online

#22 2020-07-31 16:32:08

Alad
Wiki Admin/IRC Op/TU
From: Bagelstan
Registered: 2014-05-04
Posts: 2,092
Website

Re: 95% of the time I use yay, it fails

Geez, and I thought I was bad at bikeshedding AUR helpers... (*)

OP: post output from

printenv PKGDEST
printenv PACMAN

(*) Just one thing I'd like to add to this pointless discussion: yaourt was the only pacman wrapper ever which actually warned people AUR packages were unsupported (in red blinking text, no less). All the others including yay/pacaur/$whatever_is_fasionable_nowadays blur the distinction between AUR and repository packages fully. These newer helpers have also shown worse technical difficulties than yaourt ever has, like locking you out from the AUR RPC only because you tried installing a package. So I would not say yaourt is the worst of the worst - but taking the same concept and making it worse indeed is.

Last edited by Alad (2020-07-31 16:34:03)


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Honest Alad's Package Emporium—Now with added bugs! (Grand reopening: December 1st 2018)

Offline

#23 2020-07-31 17:56:51

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,515

Re: 95% of the time I use yay, it fails

Alad wrote:

Geez, and I thought I was bad at bikeshedding AUR helpers... (*)

I have a Ph.D in that, though.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Online

#24 2020-07-31 18:03:06

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: 95% of the time I use yay, it fails

It's not so much bikeshedding when the OP specifically said they were interested in other peoples' reasoning behind something.

Of course I only now realized that this request didn't actually come from the OP.  So oops: it may or may not be bikeshedding, but it is OT.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#25 2020-08-01 01:36:11

cmdywrtr27
Member
Registered: 2019-11-23
Posts: 5

Re: 95% of the time I use yay, it fails

alad, not sure if your comment completely solved it but when i read it, it reminded me of something i saw in my .zshrc config (which happens to be borrowed and tweaked). i got no output from printenv PKGDEST but when i did printenv PACMAN i got "powerpill" as the output and i went into my .zshrc config, deleted a line (export pacman=powerpill? i believe it was) re-ran the yay -S zplug which failed before and now it finished without any errors!

so that is definitely progress, not sure if it solved it 100% as time will tell but i'm guessing it did.

from what i just described, do u think that was the culprit? that, and my lack of knowledge of aur helpers... and i guess zsh too? think yay should be A-okay from here on out or should i run another command to double check anything?

Offline

Board footer

Powered by FluxBB