Performing a sync operation gives an error

[Caeleron]

Affected Version

yay v11.1.0 - libalpm v13.0.1

Describe the bug

When performing an action with sync (-S), the following message occurs:

response decoding failed: invalid character '<' looking for beginning of value

Doing a different action, such as -Q, completes normally.

Reproduction Steps

1. yay -Syu
2. Normal packages that are accessible from pacman are downloaded and installed normally.
3. Error message is printed when yay then attempts to work with AUR packages

Expected behavior

yay doesn't crash.

Output

$ yay -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
 -> response decoding failed: invalid character '<' looking for beginning of value

$ yay -Pg
{
	"aururl": "https://aur.archlinux.org",
	"buildDir": "/home/cameron/.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
}

[Nowaker]

It may be an AUR API outage. If you look at https://github.com/Jguer/yay#readme, the icons are all red.

[pakro]

@Nowaker is probably right.
Seems related to #997 and #996.
Error looks very similar.

[tippl]

The AUR api seems to be working fine. Looks like yay calls:

https://aur.archlinux.org/rpc.php?...

Which returns a 404 not found.

Going by the wiki and calling:

https://aur.archlinux.org/rpc?...

Without the .php works fine and returns a json.

No idea what the difference between them is. I only see .php mentioned in some forum posts.

[mazylol]

I am having the same error. I do not thing it is the AUR. Pikaur and other tools are still working.

[rizaldyaristyo]

i can confirm confirm yay -Ss spotify returns

 -> Error during AUR search: request failed: Get "https://aur.archlinux.org/rpc.php?arg=spotify&by=name-desc&type=search&v=5": read tcp 192.168.1.11:37930->95.216.144.15:443: read: connection reset by peer

[pmarreck]

Seeing same error:

❯ yay -Ss jc
-> Error during AUR search: response decoding failed: invalid character '<' looking for beginning of value

-> Showing repo packages only
-> no query was executed
❯ yay --version
yay v11.1.0 - libalpm v13.0.1

If the AUR is in fact down, the error should note as much instead of just bailing because it tried to decode a response that wasn't actually there at all.

[rg872]

same error when searching for conky

$ yay -Ss conky
 -> Error during AUR search: response decoding failed: invalid character '<' looking for beginning of value

 -> Showing repo packages only
 -> no query was executed

success when using pacman

[pmarreck]

Could it be that the AUR used to respond to the .php extension to the rpc call but now suddenly won't? That would also explain this breaking other versions of yay, because it sure seems like a bug of this magnitude would have been fixed quick otherwise!

[tinyzimmer]

PHEW I thought I'd be alone on this one when I went digging through threads

[Cinux90]

lol, I runs out of memory while installing (compiling) something with yay and so my system hangs up. I need to hard reset my system. After that I face the same issue. I expect it's related to the hard reboot. Now I read this.
What should i say??? I'm happy that it's not related to my reset.

[iyanmv]

They updated aruweb repo a few hours ago:
https://gitlab.archlinux.org/archlinux/aurweb/-/tags

Maybe the just upgraded the version in the server.

[koalajoe23]

Could it be that the AUR used to respond to the .php extension to the rpc call but now suddenly won't? That would also explain this breaking other versions of yay, because it sure seems like a bug of this magnitude would have been fixed quick otherwise!

I am unable to compile yay right now, but the only reference I found to "rpc.php" is in

yay/pkg/settings/args.go

Line 30 in 19d42ae

c.Runtime.AURClient.BaseURL = strings.TrimRight(c.AURURL, "/") + "/rpc.php?"

- I can't test removing the php suffix right now but it may be worthwhile to check.

[JimPix1]

Yeah I'm getting this issue as well so it's a problem for every yay user
It'll be fixed soon I imagine

[eboye]

Could it be that the AUR used to respond to the .php extension to the rpc call but now suddenly won't? That would also explain this breaking other versions of yay, because it sure seems like a bug of this magnitude would have been fixed quick otherwise!

I am unable to compile yay right now, but the only reference I found to "rpc.php" is in

yay/pkg/settings/args.go

Line 30 in 19d42ae

c.Runtime.AURClient.BaseURL = strings.TrimRight(c.AURURL, "/") + "/rpc.php?"

• I can't test removing the php suffix right now but it may be worthwhile to check.

I just had this error and I'm 99% this is the "bug" ... they obviously changed the endpoint.

[ObserverOfTime]

I can verify that removing the extension fixes this particular issue.
However, the tests are failing and it's 1AM so I'm not submitting a PR for it.

diff --git i/pkg/settings/args.go w/pkg/settings/args.go
index 2ac583b..20698a6 100644
--- i/pkg/settings/args.go
+++ w/pkg/settings/args.go
@@ -27,7 +27,7 @@ func (c *Configuration) extractYayOptions(a *parser.Arguments) {
 		}
 	}
 
-	c.Runtime.AURClient.BaseURL = strings.TrimRight(c.AURURL, "/") + "/rpc.php?"
+	c.Runtime.AURClient.BaseURL = strings.TrimRight(c.AURURL, "/") + "/rpc?"
 	c.AURURL = strings.TrimRight(c.AURURL, "/")
 }

[kevr]

Please see #1684

[leo-arch]

Confirmed: @pmarreck's guess was right. This workaround works for me too.

[pmarreck]

Glad I guessed it right!
@DivergentClouds has a PR with a one-line fix but without fixed tests. This stops the bleeding but the tests still need to be fixed before this is pulled in IMHO (and I'll note that there are quite a few mentions of "rpc.php", not just the one s/he fixed). I'd do it myself but I'm 1) a go noob, and 2) there seem to be submodules/subdeps involved where the actual changes should take place and that's pretty much out of my wheelhouse of "create PR with simple fixes to code and tests in a language I'm unfamiliar with". That said, a global search/replace for "rpc.php?" with "rpc?" SHOULD fix both the problem and the tests, but I can't confirm.

Note that /src is ignored via .gitignore in yay so most of your search utilities will obey that and not actually show you the other mentions of "rpc.php"

[DivergentClouds]

@pmarreck I use they/them, not she or he

[pmarreck]

@DivergentClouds My bad! Thanks for your efforts

[pwae]

If anyone is wanting to use yay while waiting for the updated release, you can pass in a bit of a dodgy AUR url to get it to work:

yay --aururl 'https://aur.archlinux.org/rpc?xx=' -Syu

[OracleToes]

If anyone is wanting to use yay while waiting for the updated release, you can pass in a bit of a dodgy AUR url to get it to work:

yay --aururl 'https://aur.archlinux.org/rpc?xx=' -Syu

This didn't work for me, it looks like it updated some packages, but when I try to search or install a specific package I get the error "no query was executed" and "response decoding failed... etc"

[nxb1t]

If anyone is wanting to use yay while waiting for the updated release, you can pass in a bit of a dodgy AUR url to get it to work:

yay --aururl 'https://aur.archlinux.org/rpc?xx=' -Syu

This didn't work for me, it looks like it updated some packages, but when I try to search or install a specific package I get the error "no query was executed" and "response decoding failed... etc"

I have compiled yay without that .php suffix in AUR url , now everything works fine

[hron84]

Same with @YesterKo, it seems got fixed withing the last 15 minutes.

[Apple-QAQ]

OK! The bug maybe already fix!

[Apple-QAQ]

OK! The bug maybe already fix!

中文翻译：
好！这个bug好像已经修复了！

[IsAmogusDead]

hmm looks like were all experiencing the same issue

[Apple-QAQ]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

[Apple-QAQ]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

中文翻译：
哈哈！我在中国。我从早到晚都在等待这个错误被修复

[johnpiers]

Thank to everyone for all the posts and getting to the bottom of this issue. I just remade yay 11.1.0-1 (+1655 42.74) and it solved the problem. Thanks again.

[JJymsWorld]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

中文翻译： 哈哈！我在中国。我从早到晚都在等待这个错误被修复

It is so sad. I am also in China, but it is still not working on my computer.

[findghazi]

working now!!

[smac89]

Looks like the aur guys patched it for us, and the patch is scheduled to be removed a month from now:
#1685 (comment)

Patch here: https://gitlab.archlinux.org/archlinux/aurweb/-/commit/101de8e7b18916dd84ae52d39fb853924ea63a42

[Apple-QAQ]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

中文翻译： 哈哈！我在中国。我从早到晚都在等待这个错误被修复

It is so sad. I am also in China, but it is still not working on my computer.

Wish you good luck. Try yay -Syyu~

[Apple-QAQ]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

中文翻译： 哈哈！我在中国。我从早到晚都在等待这个错误被修复

It is so sad. I am also in China, but it is still not working on my computer.

Wish you good luck. Try yay -Syyu~

中文翻译：
祝你好运，试试看 yay -Syyu~

[kevr]

@Apple-QAQ

API 已更改，不再支持 /rpc.php。有一个拉取请求来解决这个问题，但是对这个文件的支持已经恢复了一个月，以便有时间更新这个项目。届时，它将被删除。请确保您在下个月保持最新状态，以避免将来出现问题。

很抱歉给您带来麻烦。

[Apple-QAQ]

So I woke up this morning and, having forgotten all about this issue from last night, casually proceeded to yay -Syu; and what do you know, everything works again as it should. Maybe the AUR guys realized it was indeed bad taste to break this on a Friday afternoon and they reversed the change?

LOL! I'm in China. I wait for this bug to be fixed from morning to night

中文翻译： 哈哈！我在中国。我从早到晚都在等待这个错误被修复

It is so sad. I am also in China, but it is still not working on my computer.

[Apple-QAQ]

API 已更改，不再支持 /rpc.php。有一个拉取请求来解决这个问题，但是对这个文件的支持已经恢复了一个月，以便有时间更新这个项目。届时，它将被删除。请确保您在下个月保持最新状态，以避免将来出现问题。

很抱歉给您带来麻烦。

translate to English:
The API has been changed to no longer support / RPC.php. There is a pull request to solve this problem, but support for this file has been restored for a month to allow time to update the project. At that time, it will be deleted. Please make sure you stay always update next month to avoid problems in the future.
I'm sorry for the trouble.

[Apple-QAQ]

@Apple-QAQ

API 已更改，不再支持 /rpc.php。有一个拉取请求来解决这个问题，但是对这个文件的支持已经恢复了一个月，以便有时间更新这个项目。届时，它将被删除。请确保您在下个月保持最新状态，以避免将来出现问题。

很抱歉给您带来麻烦。

English: Thank you! And I'm looking forward to update my yay~
中文：谢谢你老外！然后我也很期待更新我的yay~

[chemicalzen]

rebuilt yay, working great now, thanks for the fix!

[JJymsWorld]

rebuilt yay, working great now, thanks for the fix!

I also rebuild it ,but it is still not working. I don't know why 😭

[kevr]

Hello. I'm the person responsible for this issue, and I'd like to clarify some things here.

We've ported the AUR over to Python from PHP, which required a complete rewrite of the website. We had just a couple of people doing this over the past half a year or so. During the port, we had followed https://aur.archlinux.org/rpc documentation spec; we found, after releasing, that the /rpc.php route was mentioned in the Arch Wiki, and that some clients used this endpoint.

Do note that the Arch Wiki is primarily user-driven, and so this is not an authoritative source of truth when it comes to the AUR. While the majority of it is on point, and the AUR guidelines should be followed, the usage of /rpc.php was never provided by upstream's doc.

The issue here was multi-faceted on release:

• (1) AUR now rewrites trailing slashes to their unslashed counterparts
• (2) The /rpc.php endpoint was no longer supported. However, this being supported previously was a complete biproduct of the use of PHP, and this route was never defined internally, and is not part of the API spec.

(1) will be supported for the /rpc/ route from now on. The issue here was that the internal client does not seem to follow redirects; even so, a non-redirected response is slightly faster, and so we'll keep this.
(2) has been temporarily resolved server-side. This gives yay users a chance to upgrade to a version that uses /rpc as opposed to /rpc.php, which a PR has been made for already.

• Release notice here https://lists.archlinux.org/pipermail/aur-general/2022-February/036786.html
• Thread which dives into the specific of this problem: https://lists.archlinux.org/pipermail/aur-general/2022-February/036787.html

With a complete rewrite of the website, we missed some things, including this issue. That being said, the majority of AUR helpers are already using /rpc, and so this was a hump in the road, but not a large one overall.

So, anyway, tl;dr - it was my fault that this happened, and I apologize for the inconvenience. I did try to get this resolved from our side as quick as possible.

PS: Thanks to everybody here who was so quick to action and bring this thread up. We immediately got wind of it, and it was a large part of the reason it even got resolved that next morning. You are all great!

[Dhongli]

That's great. I'm wait for the update! Thank you!

中文翻译：

挺牛逼的。我等更新呢！谢谢你们！

同等

[Dhongli]

OK! The bug maybe already fix!

中文翻译：

好！这个bug好像已经修复了！

兄台，你做了什么操作吗，我按照上面说的正则替换了一下不管用

[Jguer]

Closing this issue as fixed on yay-git and on imminent release after some fast QA.

#1685 (comment)

Fixed by #1685

[Apple-QAQ]

OK! The bug maybe already fix!

中文翻译：
好！这个bug好像已经修复了！

兄台，你做了什么操作吗，我按照上面说的正则替换了一下不管用

nothing... today's update was fixed

[awsms]

i can confirm confirm yay -Ss spotify returns

 -> Error during AUR search: request failed: Get "https://aur.archlinux.org/rpc.php?arg=spotify&by=name-desc&type=search&v=5": read tcp 192.168.1.11:37930->95.216.144.15:443: read: connection reset by peer

I have been getting this error for 3 hours now.

edit: not a bug, server is down. #2217 (comment)