AUR helper problem / improvement

[arnonuehm66]

Hi there,

I love the AUR and install quit a few programs from it. But now and again if one of the biggies, which are compiled from source are to be updated in a very time consuming fashion, I got a sudo timeout problem.

See, if I see the start if a compile-session I turn to another desktop and doing something else like surfing the Internet or watch a movie. So I often forget a about the long installation process and come back to my terminal only to see that sudo timed out, i.e. I had to start from square one again.

I came to the conclusion that --noconfirm is not an option with any AUR helper programs, because then every timeouts were final, even if the helper program ask for repeating entering password, because usually No ([y/N]) is the default answer.

Unfortunately my favorite AUR helper yaourt is deprecated, wich had a completely different tack of the sudo timeout handling, it escalated the password to enter from the sudo password to root password and haltet indefinitely for it to be entered.

So my second best choice trizen (the one that at least ask for another try entering the password) is itself an AUR program and therefore needs an manual installation or another AUR helper.

Do I miss options for yay or the other AUR helper programs to prevent that kind of sudo timeout, or is it possible to nudge the AUR helper programmer to incorporate such a handling ;o)?

So far I will stick with trizen .

Cheers
Jens

[Twifty]

The second sudo prompt is for installing AFTER the package has been built. If you encounter the timeout, just cd into the build directory and do a manual install of the already built package. There is no need to build it again.

[merlock]

You can also increase your sudo timeout length.

Problem when updating via pacman -syu

You might need to increase your timeout. Proceed at your own risk; I personally don’t like to be bothered by sudo passwords… sudo visudo /etc/sudoers.d/01-timeout As based on your error, you’ll want longer than an hour (I.E. 90 minutes), add: Defaults timestamp_timeout=90 Save and close. See if that helps. You can remove the file afterwards to restore the default setting.

[cscs]

What, "sudoloop": true, (in ~/.config/yay/config.json) doesnt work for you ?

Of course, theres the use flag too (man yay):

       --sudoloop
              Loop sudo calls in the background to prevent sudo from timing out during
              long builds.

Note: its technically a security concern … thus its off by default.

[arnonuehm66]

@cscs

What, "sudoloop": true, (in ~/.config/yay/config.json ) doesnt work for you ?

I think nothing won’t work, I just didn’t know. So thank you very much, that’s what I 'm looking for.

Will trying it with the next update.

Just saw after installation of yay I found no ~/.config/yay/config.json, so after a short duckduckgo.com search I found an answer to create one with my edit.

Issue a yay --sudoloop --save and you get a fresh config file with "sudoloop": true, in it:

>$ cat ~/.config/yay/config.json
{
	"aururl": "https://aur.archlinux.org",
	"buildDir": "$HOME/.cache/yay",
	"absdir": "$HOME/.cache/yay/abs",
	"editor": "",
	"editorflags": "",
	"makepkgbin": "makepkg",
	"makepkgconf": "",
	"pacmanbin": "pacman",
	"pacmanconf": "/etc/pacman.conf",
	"redownload": "no",
	"rebuild": "no",
	"answerclean": "",
	"answerdiff": "",
	"answeredit": "",
	"answerupgrade": "",
	"gitbin": "git",
	"gpgbin": "gpg",
	"gpgflags": "",
	"mflags": "",
	"sortby": "votes",
	"searchby": "name-desc",
	"gitflags": "",
	"removemake": "ask",
	"sudobin": "sudo",
	"sudoflags": "",
	"requestsplitn": 150,
	"sortmode": 0,
	"completionrefreshtime": 7,
	"sudoloop": true,
	"timeupdate": false,
	"devel": false,
	"cleanAfter": false,
	"provides": true,
	"pgpfetch": true,
	"upgrademenu": true,
	"cleanmenu": true,
	"diffmenu": true,
	"editmenu": false,
	"combinedupgrade": false,
	"useask": false,
	"batchinstall": false
}

Edit: Changed yay --Syu --sudoloop --save to yay --sudoloop --save