Pakku unable to find packages

[PMunch]

It seems like something have broken with Pakku and/or AUR. I'm trying to install the GCC cross-compiler for ARM and I just get an error saying it can't find arm-linux-gnueabihf-gcc-stage2 which is evidently there. It seems to be able to find other things just fine, but not this specific package.

[peter ~ ] 16685 $ pakku -S arm-linux-gnueabihf-gcc
:: Resolving build targets...
checking AUR database for targets...
(1/1) cloning repositories                                                                                                                00:00 [########################################################################################] 100
resolving dependencies...
(1/1) cloning repositories                                                                                                                00:00 [########################################################################################] 100
(2/2) cloning repositories                                                                                                                00:00 [########################################################################################] 100
error: unable to satisfy dependency 'arm-linux-gnueabihf-gcc-stage2>=11.2.0-3' required by arm-linux-gnueabihf-glibc
▐1▋[peter ~ ] 16686 $ pakku -S arm-linux-gnueabihf-gcc-stage2
:: Resolving build targets...
checking AUR database for targets...
(1/1) cloning repositories                                                                                                                --:-- [########################################################################################] 100
error: target not found: arm-linux-gnueabihf-gcc-stage2

[zqqw]

It seems to find it OK trying this myself just now. Sorry for the delayed reply, I'll have to look at my notification settings on this repo.

[zqqw]

I hit this error today for the first time updating on someone else's high speed direct fiber business connection - perhaps due to a different DNS server? This may work, hopefully try it again in due course, it works on my usual connection but that always did, it could be better anyway, see the recent discussion on the Trizen bug tracker regarding dropping the trailing slash on rpc avoiding a redirect.

diff --git a/src/aur.nim b/src/aur.nim
index 8f555cb..aa263c7 100644
--- a/src/aur.nim
+++ b/src/aur.nim
@@ -65,7 +65,7 @@ proc getRpcPackageInfos*(pkgs: seq[string], repo: string, useTimeout: bool):
       try:
         let responses = distributed.map(pkgs => (block:
           withCurl(instance):
-            let url = aurUrl & "rpc/?v=5&type=info&arg[]=" & @pkgs
+            let url = aurUrl & "rpc?v=5&type=info&arg[]=" & @pkgs
               .map(u => instance.escape(u))
               .foldl(a & "&arg[]=" & b)
             performString(url, useTimeout)))
@@ -146,7 +146,7 @@ proc findAurPackages*(query: seq[string], repo: string, useTimeout: bool):
     withAur():
       try:
         withCurl(instance):
-          let url = aurUrl & "rpc/?v=5&type=search&by=name-desc&arg=" &
+          let url = aurUrl & "rpc?v=5&type=search&by=name-desc&arg=" &
             instance.escape(query[0])
 
           let response = performString(url, useTimeout)

[zqqw]

Actually the error I got was different:

checking AUR database for upgrades...
error: failed to perform request: Couldn't resolve host name

Then it went on to list all the aur packages I have installed saying:

warning: (package name) was not found in AUR

and I also encountered it at my usual location using the modified url above, although I didn't get it when I retried pakku -Syu, meanwhile I've not had any further problems trying on the other connection with the trailing slash still in place - so this seems simply a random connection issue, in fact it seems to be curl fails and prompts this error when called in src/wrapper/curl.nim and possibly it's related to the timeout limits:

    timeoutMs = 155,
    connectTimeoutMs = 156,

which might possibly be a bit short:
https://curl.se/libcurl/c/curl_easy_setopt.html

[PMunch]

That does sound familiar, my system also lists out all packages and tells me they can't be found. I'll try the above patch and see if it works.

[PMunch]

After a lot of digging (goodness gracious this codebase is a jungle) I finally figured out what the issue is. It all stems from these lines https://github.com/zqqw/pakku/blob/master/src/common.nim#L885-L888. Basically .SRCINFO doesn't exist, so it default to empty metadata, and this causes the package to be considered as not found. As a workaround I used execProcess("makepkg --printsrcinfo", workingDir = repoPath) instead of the empty string to create the .SRCINFO when it doesn't exist. Why it doesn't exist though is anyones guess, I checked this package in particular and it does have a .SRCINFO in it. The only thing I can think of is the cache directory settings. I changed mine a while ago because I hadn't updated in so long that it would fill up my /tmp trying to update. So I changed one cache dir to go to a hard-drive instead, maybe Pakku is pulling the SRCINFO into a different cache folder than it is trying to read from?

[zqqw]

I'd suggest trying to add something like:

echo "repoPath & \"/.SRCINFO\" = ", repoPath & "/.SRCINFO"
quit(1)

after the "else" to hopefully find out where it thinks SRCINFO should be and then look where it actually is on your filesystem, which could help at least determine that much.

[hochata]

I also stumbled with this issue. But in my case it seems a previous failed build left a /tmp/pakku/<pkg> directory with an incorrect structure. Because the directory existed, no repository was cloned and no .SRCINFO was present. In my case the solution was simply to delete /tmp/pakku/<pkg> directory. But if generating the file solved your problem, I guess it is something different.

I looked around a bit more and Pakku already generates .SRCINFO for Pacman packages using this procedure. But it seems .SRCINFO is a requirement for AUR packages, so I guess Pakku just assumed it will be there.

For where the .SRCINFO should be, the repo is cloned here and the file is read from this path. For what I can tell, they are the same location. I guess printing the repoPath and trying to looks through its contents might help.

I guess you just changed the UserCacheDir and TmpDir in the configuration file to change the cache location?

[zqqw]

https://github.com/zqqw/pakku/blob/master/src/feature/syncsource.nim#L26
I think it's probably there as the files get copied at some point except for .gitignore .SRCINFO but I'm not sure why it works in other cases, there must be some different path being used that requires SRCINFO and it ought to be investigated, because this could be a case of SRCINFO should be here but perhaps it shouldn't be required instead, don't know.

[zqqw]

7410349

That should hopefully help with the problem I have encountered a few times, curl is retried 3 times after a random delay of 2 to 3 seconds to avoid collisions with other Pakku users. It already has a 15 second timeout on the curl call but that didn't seem to be hit, it apparently errors out quickly on rare occasions.

src/wrapper/curl.nim
104:      let timeoutMs = if useTimeout: 15000 else: 0

The 155 and 156 above weren't the timeout but magic number flags for those curl commands. I don't think this patch affects the SRCINFO issue which seems separate.