"Failed to parse JSON" on AUR upgrade #688
Comments
|
Got the exact same error since a few days. Solution proposials from #597 didn't help either |
|
Well, it isn't the URL that is too long. You have lot of AUR packages (about 300), but the length limit is reached only with about 400 to 450 packages. The code should be able to handle more by splitting the request in subrequests (see #209 and #504), but that isn't used here. See the URL length check here, you're still way under the limit:
Two possible reasons come to mind, both involving the underlying curl:
I'd suggest starting to check if cower works correctly ( |
|
I can actually install packages, I updated pacaur using pacaur funnily enough (to make sure it wasn't a bug in the release I was using), but the full update doesn't work. The certificate issue doesn't seem to be a problem either, as single packages work. Both with cower and pacaur. I tried the solution from #597 regardless. Here's the curl version:
|
|
I'm having the same issue. |
|
Pacaur uses the default URL length limit, but it's possible the server settings got changed recently. Apart from this, I have no real idea about the reason curl fails here, and I'm afraid you guys are on your own. |
|
As an extra piece of data: When I run |
|
Interesting info. I arbitrarily chose 4125 as the urlmax value, seems to work now as a workaround. |
|
All right, I asked around a bit and here is a more likely explanation for the issue: The newest curl release At this time, it is not clear to me if that sole change is reponsible for the issue, or if an associated server setting also plays a role. I'll adjust the max value as soon as I find out the right value. |
|
I've looked into the various HTTP2 RFC, curl and nghttp2 documentation, but wasn't able to determine any information of a possible new limitation of the URL length. I've played a bit with the AUR RPC (in my browser) and was able to determine that the server is still limited to the original total 8190 bytes length. Thus, the issue is effectively due to the new behavior of curl, which now uses HTTP/2 for HTTPS connections by default. I've empirically determined that curl returns an error code 56 ( Feeback welcome. Edit: Looks like the default nginx value for http/2 is defined here (4k). Thanks to eschwartz/contributors in -devops channel. |
|
Pulled down the -git version and all seems to be working again. Cheers! |
|
Thanks. New stable version has been released. |
|
I'm still getting this issue. |
|
Then please open a new ticket and attach the according debug output. |
Important
Read me first: Bug reports
AND FOR GODS SAKE, do not ask support questions on the bug tracker. I'm not here to fix your freaking INCOMPETENCE.
Or.give.me.MONEY. For paying support, see Paypal link in man page.
Version
pacaur -vDescription
JSON parsing fails, most likely because of too many args to URL?
I tried to see if I cut down the number of args to see if it would work, and it did in fact get the JSON once the args list was shorter.
Output
pacaur -Syu --noedit --needed --devel --noconfirmDebug output
bash -x pacaur <your command>The text was updated successfully, but these errors were encountered: