You are not logged in.
I think I may have found a bug, this happens when installing AUR packages that use GIT
this 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 helpsthanks 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.
Last edited by Spyhawk (2011-08-30 12:34:43)
Offline
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]
╔═(cgirard@cedric-laptop)────(14:24:20 Tue Aug 30)────(/tmp/pacaur)
╚═══[$]> pacaur -Su
ProxyChains-3.1 ([url]http://proxychains.sf.net[/url])
Password:
:: Starting full system upgrade...
warning: cacti: ignoring package upgrade (0.8.7g-1 => 0.8.7g-3)
there is nothing to do
:: Starting AUR upgrade...
:: xmobar-git 20110606-1 -> 20110828-1
:: haskell-time is available in extra
:: haskell-binary is available in community
:: haskell-bytestring is available in extra
:: haskell-extensible-exceptions is available in extra
AUR Targets (1): xmobar-git
Proceed with installation? [Y/n]
And here is the requested log (with Su): http://pastebin.com/sn6VrrBr
Cedric Girard
Offline
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?
cower -u --color=always | tee 1>&2 >(awk -F " " '{print $2}'| sed -r "s:\x1B\[[0-9;]*[mK]::g")
Last edited by Spyhawk (2011-08-30 14:57:46)
Offline
$ cower -u
:: xmobar-git 20110606-1 -> 20110828-1
cower -u --color=always | tee 1>&2 >(awk -F " " '{print $2}'| sed -r "s:\x1B\[[0-9;]*[mK]::g")
:: xmobar-git 20110606-1 -> 20110828-1
xmobar-git
(same result with or without IgnorePkg).
Last edited by X-dark (2011-08-30 15:03:55)
Cedric Girard
Offline
Note that this dependencies where not needed on the previous version of xmobar-git and thus are not installed on my system.
Cedric Girard
Offline
Note that this dependencies where not needed on the previous version of xmobar-git and thus are not installed on my system.
Thanks, that's indeed a very useful information. I still don't get why deps aren't found, but that's probably related to it.
Offline
Maybe these two additional logs may help you:
Same as before but without IgnorePkg in pacman.conf: http://pastebin.com/9KiS5yf0
Diff between the two logs: http://pastebin.com/rfSSdMXJ
Cedric Girard
Offline
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".
Cedric Girard
Offline
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.
Last edited by Spyhawk (2011-08-30 19:24:09)
Offline
Great it is now working and the PKGBUILD has been improved as well!
For your special case, maybe you could check deps array before and after calling IgnoreChecks(). If they differs, it means a dependency has been ignored and the build should fail.
Cedric Girard
Offline
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.
It can be handy.
Offline
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.
Last edited by Spyhawk (2011-08-31 17:47:33)
Offline
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?
that's weird, I couldn't reproduce the problem myself, I don't know what was the problem the other day, anyway nevermind. thanks
Offline
Spyhawk,
I'm going to gives pacaur a whirl.
Somehow, I haven't seen pacaur until now. It looks really good and has seemingly made my pbfetch completely obsolete(as though it wasn't already)
Offline
Spyhawk,
I'm going to gives pacaur a whirl.
Somehow, I haven't seen pacaur until now. It looks really good and has seemingly made my pbfetch completely obsolete(as though it wasn't already)
I guess I should thank you for creating pbfetch first, as it was my first inspiration source when creating pacaur. And if you like pbfetch (you probably do ), you might enjoy pacaur too.
Last edited by Spyhawk (2011-09-03 08:57:08)
Offline
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)enter the number of the package: ___
what do you think?
Offline
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.
Offline
I absolutely understand your point.. I'll try to check what "command-not-found" does or simply live with this missing feature
Offline
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?
Edit: 2.3.5 is out. Hope problem is properly fixed.
Last edited by Spyhawk (2011-09-10 19:54:23)
Offline
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.
My pacaur.conf ... Looks like I have to downgrade to 2.3.3.
~
Offline
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.
Last edited by Spyhawk (2011-09-11 14:19:07)
Offline
2.3.5 works perfect for me- I dont do any locale stuff though, so...
Offline
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.
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.
My pacaur.conf ... Looks like I have to downgrade to 2.3.3.
Cannot reproduce here, i have it_IT.UTF-8 set. Though, i must say, i have a different pacaur.conf.
The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds
Offline
pacaur 2.3.5-1
I'm getting this error after the package was successfully built:
==> Installing package transmission-remote-gui-bin with pacman-color -U...
standard in must be a tty
==> WARNING: Failed to install built package(s).
Installing with
pacman -U transmission-remote-gui-bin-3.1-1-x86_64.pkg.tar.xz
went fine.
FYI, I am on ssh, maybe that has something to do with the error message.
Last edited by SanskritFritz (2011-09-13 12:09:21)
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
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.
Offline