-
Notifications
You must be signed in to change notification settings - Fork 114
Breakage on skipping a package upgrade: "no results found for error)" #267
Comments
Hi, thanks for the report. Someone else reported a somewhat similar issue in the AUR comments a few days ago, but I can't reproduce. From what I can see in the debug output, pacman finds the haskell-gitit package but can't resolve its dependencies tree. In turns, the error code is passed to pacaur that tries to find that "package" in the AUR. The responsible part of the code is in ClassifyPkgs(), which isn't robust enough to take care of "unexpected" pacman errors. However, I'm not sure why this error happens in the first place. The haskell-gitit package doesn't seem to exist at all, and pacaur correctly stops on my machine. If this constantly happens on your machine, could you tell me more about your haskell packages (haskell binary repository enabled?, ...). |
Relevant commit here: 5987e2a. It's kind of easy to make the current code robuster, but it breaks translation support. I'll need to figure out another way of handling this issue. |
Thanks for your quick answer, as always. In an effort to remain concise I forgot to mention the context: I enabled those repos in order to get easier access --well, to get any access actually-- to the two following packages found in the AUR, but uninstallable as is: Anyway, I suspect this has mostly to do with the packages' metada in the ArchHaskell-provided repos. I sent an email yesterday to their mailing list but it seems I have to subscribe first for my message to appear there (ugh). Thanks |
Thank you, I can indeed reproduce the problem now. Yes, the main issue seems due to inconsistencies in the additional Haskell repositories themselves. I had seen a somewhat similar issue in the past (to make it short, I was playing badly with local built packages) and I deemed it not worth fixing, but this is the first time I see an entire repository causing an error. This is an exceptional situation, but the fact that pacaur code isn't robust enough to handle it is a flaw and should be fixed. There are many parameters to take into account in order to fix the current |
Interesting. I appreciate your consideration for this, robutness is of course an always sought-after aspect of a software. I hope you'll manage to wrap your head around this particuliar issue. |
I regularly encounter this issue, except with "dependencies)", not "error)". I've never looked into the cause though. I'm not using any custom repositories. |
@djmattyg007 > Which are the repositories enabled? Or with which packages does that issue occur? |
@rmarquis I have core, extra and community enabled. I'm running a 32-bit On Sun, Dec 28, 2014 at 09:55:54AM -0800, Remy Marquis wrote:
|
Please provide a debug output if the issue occurs again (bash -x pacaur your_command). I cannot do anything without more information. |
Result of "bash -x pacaur -Syu" : https://paste.ee/p/yfht3 I did not actually skip an update. The custom repositories I have enabled are:
|
@Nordic89: First, ensure to rebuild expac. The new version is still in [testing]. Alternatively, install expac-git from AUR, or wait that the new expac arrives in [extra]. Yes, pacman 4.2 and the new libalpm has arrived. Please confirm if this solves the issue for you. |
I've just got the same message from pacaur (:: no results found for error). I was trying to upgrade my system with But even after that I am unable to get rid of that last :: no results found for error... Here is full output: https://paste.ee/p/8oWel |
Pacman 4.2 has landed in [core], and thus cower must be recompiled, and you need expac 4-3 (which is now in [extra]). Please don't report issue until you're sure you've done your pacman/cower/expac update homework. |
Yeah, I saw that a second after submitting above comment, sorry. I am trying to cleanup and upgrade everything properely now, still have some problems with signatures tho... |
Same issue, recompiling cower worked for me. Thanks for the help and for pacaur :) |
Since the ClassifyPkgs() function use the "pacman -Sp" function more or less as a hack to:
I'll need a replacement function that handles all of these, plus handles the errors correctly. Two possibilities:
|
This bug is very tricky to solve. Reimplementing it in another way with all the supported features clearly gives me headache. As a workaround, I've implemented an early check in a1c53bc that ensures the package name doesn't contain ")". It should catch the binary repositories errors. This won't catch libalpm upgrade issue, but that's a different situation. Closing, please reopen if this happens again (and attach full details). |
Polish translation broke because the error string isn't similar anymore to the English string. See #302. The |
I don't know if this is relevant with reference to broken polish translation, but when installing returns error "no results...", updating with command |
@xinulsw > When you get the chance next time, I'd appreciate to see a debug output. Both install (-S) and update (-Syu) commands call the same |
Sorry for delay, here is debug for trying to install greybird theme: Unfortunately i haven't any package right now to upgrade... but i'll post debug as soon as I can. |
Thx. See https://wiki.archlinux.org/index.php/Pacaur#Bug_reports for debug output. The pacman |
Sorry for bloating, here correct debug I hope:
I havent used pre and code tags because in preview log have been cut off. |
$ LANG=C pacaur -S nvidia-ck-ivybridge :: Do you want to skip the above package for this upgrade? [y/N] This message i have seems relevant to this issue. I do really have the dependency conflict, but that's not the point. |
Yup, seems to be the very same issue. |
Here is a more common, related error when making use of the
|
pacsift from pacutils can be used to finally fix this issue. Delaying to pacaur 5.0. |
Hi, when asking pacaur to skip a problematic package "upgrade" (it was a fresh installation actually) it ended up on this error:
Answering No probaby gives a better idea of where the problem stems from:
Doing the same in French and English. Maybe an incorrect handling of space in a certain string?
Here is the full debug log:
The text was updated successfully, but these errors were encountered: