Re: pacaur - an AUR helper that minimizes user interaction

saad wrote:

I think I may have found a bug, this happens when installing AUR packages that use GITthis is what happened when installing the package "dex-git"

the file dex-git-20101113-1-any.pkg.tar.xz does not existe, the generated file is called dex-git-20110830-1-any.pkg.tar.xz, I think that pacaur shouldn't read the package version from the PKGBUILD when calling pacman, but from the system date. I hope this helps

thanks Spyhawk for all the good work, please keep up

Saad> I actually cannot reproduce the problem. Could you test with another git package, and download dex-git PKGBUILD and run "makepkg -sfi" on it to see if it install?

X-dark > You're right, the aur and git version are slightly different. I actually did release 2.3.2 on the aur, but forgot to commit and push to github, started coding again and pushed when I realized I forgot to do it. I didn't bother to stash the additional change as that is a very minor change that should not change pacaur behavior (I renamed all occurrences of "ignorepkgs" var to be less confusing with "ignoredpkgs").

Yup, the actual packaging sucks and I never took time to change it. I was aware of the "soft" and "hard" git tag, but didn't realize that github create tarball with hard tag. Thanks for the tip!

Also, I'm afraid that I cannot reproduce your problem (with/without IgnorePkg var, and tried with both the aur and git 2.3.2 to be sure). The output is similar in both cases:

$ pacaur -S xmobar-git
:: Package(s) xmobar-git not found in repositories, trying aur...
:: ghc is available in extra
:: haskell-x11 is available in community
:: haskell-x11-xft is available in community
:: haskell-extensible-exceptions is available in extra
:: haskell-array is available in extra
:: haskell-containers is available in extra
:: haskell-directory is available in extra
:: haskell-filepath is available in extra
:: happy is available in extra
:: alex is available in extra
:: haskell-bytestring is available in extra
:: haskell-pretty is available in extra
:: haskell-process is available in extra
:: haskell-syb is available in extra
:: haskell-unix is available in extra
:: haskell-mtl is available in extra
:: haskell-network is available in extra
:: haskell-old-locale is available in extra
:: haskell-time is available in extra
:: haskell-utf8-string is available in community
:: haskell-old-time is available in extra
:: haskell-parsec is available in extra
:: haskell-stm is available in extra
:: haskell-binary is available in community
:: wireless_tools is available in core
:: ghc is available in extra
:: haskell-transformers is available in extra
:: haskell-alsa-core is flagged out of date
:: haskell-libmpd is flagged out of date
AUR Targets (9): xmobar-git haskell-alsa-mixer haskell-alsa-core c2hs haskell-language-c haskell-hinotify haskell-libmpd haskell-timezone-olson haskell-timezone-series
Proceed with installation? [Y/n] n

Could you generate a report with "bash -x pacaur -S <package>"? There might be an additional reason to that very same bug.Edit: I've just seen that you encounter the problem while upgrading - please also test with "pacaur -Sua pkg", but I guess I probably need to fix something in the upgrade operation.

Re: pacaur - an AUR helper that minimizes user interaction

Actually it works with pacaur -S but not with pacaur -Su:

╔═(cgirard@cedric-laptop)────(14:24:05 Tue Aug 30)────(/tmp/pacaur)
╚═══[$]> pacaur -S xmobar-git
ProxyChains-3.1 ([url]http://proxychains.sf.net[/url])
:: Package(s) xmobar-git not found in repositories, trying aur...
:: haskell-binary is available in community
:: haskell-time is available in extra
:: haskell-bytestring is available in extra
:: haskell-extensible-exceptions is available in extra
AUR Targets (3): xmobar-git haskell-timezone-olson haskell-timezone-series
Proceed with installation? [Y/n]

Re: pacaur - an AUR helper that minimizes user interaction

X-dark > Honestly, I'm puzzled. I've tried with a random aur package that has an aur dependency (changed both release number in order to simulate an update) and it succeed. Looking at your log and the above, it seems that cower itself can't find all updates well before the IgnorePkgs() check itself.

Could you check that "cower -u" report the three package? Also, are those packages reported when you run the following command?

Re: pacaur - an AUR helper that minimizes user interaction

I may have found what is wrong.In the "IgnoreChecks" function you have the first test that return false because $upgrade is true. Then "aurdepspkgs" are never added back into $deps (you only parse "aurpkgs").This is why the initial deps : "xmobar-git haskell-timezone-series haskell-timezone-olson" are transformed into "xmobar-git".

Re: pacaur - an AUR helper that minimizes user interaction

X-dark wrote:

I may have found what is wrong.In the "IgnoreChecks" function you have the first test that return false because $upgrade is true. Then "aurdepspkgs" are never added back into $deps (you only parse "aurpkgs").This is why the initial deps : "xmobar-git haskell-timezone-series haskell-timezone-olson" are transformed into "xmobar-git".

Well done :]I don't have a way to test this currently, but what you say seems 100% correct to me. On "normal" upgrade, all packages are in the ${aurpkgs[@]} array, which is not the case when the upgrade pull some extra dependencies. I'll cleanup the pkgbuild and release the next version. Thanks for helping me to sort this issue out ;]

Edit: Solving this issue raises another one: when a pulled dependency of an upgrade is ignored, the upgrade (if not ignored) will fail to build. The code to handle those specific case is to write, but I'll release 2.3.3 now anyway as they probably don't happen frequently.

Re: pacaur - an AUR helper that minimizes user interaction

Is there any plan for a selective upgrade option, like yaourt does?

For example, this morning I felt like updating. I run pacaur -Syu and see that linux-ck needs to be updated along with a bunch of other stuff. Well, I don't feel like waiting for the compile right now.

So, I have to cancel the upgrade and rerun pacaur with the --ignore flag.

With yaourt, when it prompts for whether or not you want to upgrade, you have three options: y, n, or m. When you press m, your text editor opens with a list of upgradable packages. You simply delete the ones you don't want to upgrade this time.

Re: pacaur - an AUR helper that minimizes user interaction

X-dark > That would probably be sufficient when upgrading a single package, but I'm afraid more code is needed to handle all other cases.

pogeymanz > There is no plan to include such a feature. Way out of scope of this project and road to bloatedness imho. Pacaur design aims to stay simple and similar to pacman: You enter a command, and pacaur executes exactly that. I'd suggest you to check available upgrade with "pacaur -Qu" (-Qua for aur update only) prior to any upgrade operation.

Re: pacaur - an AUR helper that minimizes user interaction

Hi, I have a feature request, it is not important but I think it would be nice to have it (maybe by enabling it as an option, for making happy also the "purist" people who don't want too much stuff.. )

it is an example, I just wanted to install "zukitwo-themes" from AUR, I searched it with "pacaur -Ss zukitwo" and after I found it, I simply by error entered "pacaur -S zukitwo --aur --noconfirm"actually pacaur returns a very basic ":: no results found for zukitwo" because the package on AUR actually is "zukitwo-themes"

it would be nice if, instead of saying (no package found), pacaur proposes to install a package that matches with the name, for example, in this case, it would have prompted something like this:

:: no results found for zukitwo:: have you meant one of the following?1) zukitwo-themes (description bla bla bla)

Re: pacaur - an AUR helper that minimizes user interaction

Berseker > I think that is a feature that could be provided by the "command-not-found" suggestion program (or whatever it is called in arch repo), or by expending bash completion. I don't believe that's pacaur job to provide such a feature, and quite frankly, I'm actually more interested in fixing pacaur's bugs than adding new extra small features that greatly increase debug and maintenance work.

Re: pacaur - an AUR helper that minimizes user interaction

Re: pacaur - an AUR helper that minimizes user interaction

2.3.4 is released, fixing the most annoying bug: pacaur now handle packages conflict without losing its fast workflow. Although I tried to test many conflicts scenario and fixed all misbehavior I came across, please report any misbehavior (conflicts failing, false positive reinstall warning, etc.).There is also a minor bug in install output (missing line return), but I'll handle that later.

EDIT:Found a major bug when installing some pkgs, I'll revert to 2.3.3 for now. Thus, 2.3.4-release 2 is 2.3.3.Why do I always find bug right after releasing to the world and never when doing internal testing?

Re: pacaur - an AUR helper that minimizes user interaction

I'm having a problem with the latest pacaur (2.3.5, didn't occur with 2.3.3), and it seems to be related to my locale settings. If I try to install a package from AUR with LC_ALL=C pacaur -Sa, the package installs flawlessly, though pacaur doesn't "stop" at the Proceed with installation? prompt (it just installs the package).

Yet if I don't set LC_ALL=C (so everything is set to de_DE.UTF-8), pacaur doesn't even install the package - it just says Build directory cleaned.

Re: pacaur - an AUR helper that minimizes user interaction

Strange, as I didn't change anything related to locale. Anyway, thanks for the report. In the meantime, 2.3.3 is available here if you need to downgrade. Also, it would be great if you could test and confirm that the problem doesn't occur with 2.3.3, as I'm unable to reproduce the problem myself.

Re: pacaur - an AUR helper that minimizes user interaction

Re: pacaur - an AUR helper that minimizes user interaction

Spyhawk wrote:

BasT wrote:

I've been using pacaur for a few weeks now and i really like it except for one MAJOR issue:When installing packages from AUR it only asks for the password once the package is ready to be installed. If the password then isn't entered within a certain amount of time the whole build directory including the finished package get deleted!

Workaround: Disable the "clean" option in pacaur.conf and clean your directories manually with "pacaur -cc". No idea if this could be fixed without major code overhaul as "obviously, makepkg doesn't like that" :]

Aside from disabling "clean" option, i don't know how you could fix that, since sudo works like that intentionally. If you don't want that, please set sudo timeout as shown on Arch wiki.

Weegee wrote:

I'm having a problem with the latest pacaur (2.3.5, didn't occur with 2.3.3), and it seems to be related to my locale settings. If I try to install a package from AUR with LC_ALL=C pacaur -Sa, the package installs flawlessly, though pacaur doesn't "stop" at the Proceed with installation? prompt (it just installs the package).

Yet if I don't set LC_ALL=C (so everything is set to de_DE.UTF-8), pacaur doesn't even install the package - it just says Build directory cleaned.

Re: pacaur - an AUR helper that minimizes user interaction

GSF1200S, lucak3> Thx for confirming. I tried myself with various locales and couldn't reproduce the problem.Weegee> You can check with 2.3.3 to ensure that the changes I did are/aren't the reason of your problem.lucak3,BasT> Another way to "bypass" this issue would be to set the $PKGDEST var, so compiled pkgs would be moved to this directory prior to any cleaning operation.SanskritFritz> Works for me here (local install). I've never seen the "tty" message before. I know some people use tsock or proxychains when doing remote operation, you might have a look there.