Provide a way to determine what repos are causing yay to freeze

[octylFractal]

Is your feature request related to a problem? Please describe.

One of my git packages has a repository that is unresponsive, unfortunately I can't tell which one it is because yay's verbose flags do not emit any sort of text indicating which repository it's checking. This leads to yay freezing when doing yay -Y --gendb.

Describe the solution you'd like

Some way to figure out what repository is causing this freeze, either via logging it in verbose mode, or adding an additional flag.

Describe alternatives you've considered

I could try using strace to figure out what repository is the problem here, but that would only work if yay makes calls out to the git command and doesn't use a git lib instead. Regardless, even if it did work it's a fragile way to get this information.

Additional context

As this is potentially a bug (I feel like it's not, but maybe I'm wrong), I've included the output of the bug report commands:

• yay -V

yay v11.0.2.r36.g2552cf1 - libalpm v13.0.1

• yay -Pg

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

[konatizer]

I can confirm that I've been having this problem too, yay -Syu and yay -Y --gendb will both result in a hang. currently on yay v11.0.2.r36.g2552cf1 - libalpm v13.0.1 i've tried yay -Sc and yay --clean and it still hangs, definitely not an expert on the subject so any help would be greatly appreciated.

[Jguer]

Yay should handle these cases, I'm labeling it as a bug

[dpendolino]

Same thing happening to me:

❯ yay -Pg
{
	"aururl": "https://aur.archlinux.org",
	"buildDir": "/home/dpendolino/.cache/yay",
	"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,
	"completionrefreshtime": 7,
	"bottomup": true,
	"sudoloop": false,
	"timeupdate": false,
	"devel": false,
	"cleanAfter": false,
	"provides": true,
	"pgpfetch": true,
	"upgrademenu": true,
	"cleanmenu": true,
	"diffmenu": true,
	"editmenu": false,
	"combinedupgrade": false,
	"useask": false,
	"batchinstall": false,
	"singlelineresults": false
}
~/git
❯ yay -V
yay v11.1.0.r3.g65ecee9 - libalpm v13.0.1

[JCallicoat]

I am getting the same kinds of hangs when yay is checking devel packages either when doing a gendb or upgrading devel packages. The culprit in my case seems to be git ls-remote for projects hosted on gitlab.freedesktop.org.

Here is what I see when yay is hanging:

pgrep -fa git ... 1879934 git ls-remote https://gitlab.freedesktop.org/xorg/lib/libxft.git HEAD 1879935 /usr/lib/git-core/git remote-https https://gitlab.freedesktop.org/xorg/lib/libxft.git https://gitlab.freedesktop.org/xorg/lib/libxft.git 1879936 /usr/lib/git-core/git-remote-https https://gitlab.freedesktop.org/xorg/lib/libxft.git https://gitlab.freedesktop.org/xorg/lib/libxft.git 1880086 git ls-remote https://gitlab.freedesktop.org/spice/spice-protocol.git HEAD 1880097 /usr/lib/git-core/git remote-https https://gitlab.freedesktop.org/spice/spice-protocol.git https://gitlab.freedesktop.org/spice/spice-protocol.git 1880103 /usr/lib/git-core/git-remote-https https://gitlab.freedesktop.org/spice/spice-protocol.git https://gitlab.freedesktop.org/spice/spice-protocol.git

I can reproduce this by manually running the git ls-remote commands and they work like 2 out of 5 times and just hang the other times. I took some pcaps when it's hanging and gitlab.freedesktop.org is sending back tcp keepalive responses but no data, so I assume that's why ls-remote doesn't just close the connection with an error.

Note that this happens with paru as well but a timeout was added to kill the git ls-remote process after 15 seconds here https://github.com/Morganamilo/paru/commit/62788913442c5c08ae2956f6b0d856fad2f57785

I tried to simulate this in yay with --git /usr/bin/timeout --gitflags '30 git' and I can see it is being used for other repos like:

1880201 /usr/bin/timeout 30 git ls-remote https://github.com/fmtlib/fmt.git HEAD

But for some reason it doesn't seem to be applied to gitlab.freedesktop.org repos.

[JCallicoat]

Hmm it seems like there should already be a 5 second timeout from here https://github.com/Jguer/yay/blob/65ecee9cb67134a059eb2b315fa12d956558480e/pkg/vcs/vcs.go#L61-L64

[dpendolino]

This might have something to do specifically with gitlab.freedesktop.org. I can't repro with any source packages built from github,com.

Cloning from https://gitlab.freedesktop.org/ directly succeeds only about 1/5 attempts for me currently. I've tried from my home and a Linode VPS.

[Jguer]

"debug": true

can be used in yay's config file to diagnose the failing package