You are not logged in.
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
Then don't use yay.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
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
pacman -Syu first.
then you might try trizen.
Offline
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
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
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
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.
Online
Thanks for the answers V1del. As always very helpful.
Offline
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!
Offline
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.
Offline
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
Offline
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.
Offline
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 packages • Zsh and other configs
Offline
I like aurutils and maintaining a local repository. It's not difficult, folks.
Offline
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.
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.
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.
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
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
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)
Offline
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
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.
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.
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.
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
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)
Offline
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
Offline
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)
Offline
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
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