You are not logged in.
Such a great tool, i have a problem to report: cower doesn't parse a PKGBUILD correctly, while makepkg does. The PKGBUILD in question is pcsx2-svn: 'cower -dd pcsx2-svn' asks me to install all lib32* stuff, but it's incorrect, since i'm using 32bit !! Instead, giving 'makepkg -s' inside the extracted tarball directory does begin the build immediately.
The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds
Offline
Such a great tool, i have a problem to report: cower doesn't parse a PKGBUILD correctly, while makepkg does. The PKGBUILD in question is pcsx2-svn: 'cower -dd pcsx2-svn' asks me to install all lib32* stuff, but it's incorrect, since i'm using 32bit !! Instead, giving 'makepkg -s' inside the extracted tarball directory does begin the build immediately.
I'm not the dev, but as I understand it, the reason for that is that lots of people use bashisms to provide alternate deps etc. in PKGBUILDs, and its not possible to parse those properly without actually running the PKGBUILD. Which is of course not cower's job.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
ngoonee is correct. To expand a bit, cower implements its own parser which is probably 90% accurate for PKGBUILDs. lib32 packages are something it will probably never get right because of the logic in assigning arch-dependent dependencies.
On the other hand, makepkg sources the PKGBUILD, meaning its using Bash's 100% reliable parser to properly resolve those dependencies.
In short, working as intended. cower will unfortunately never be 100% accurate here.
Offline
What would you suggest to solve this problem? I mean, is there a way to write PKGBUILDs so that they can be parsed easily by non-sourcing AUR helpers like cower?
The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds
Offline
It's not a problem I'm interested in solving based on time/reward, especially if it means disturbing the AUR "ecosystem" and insisting that PKGBUILDs meet some extra, imaginary, unofficial criteria. Bash's built in parser is over 9000 (literally, not just dbz style) lines of yacc grammar. cower uses about 100 lines of C to get an 80-90% solution that works well enough for my purposes.
Offline
Just tagged and uploaded cower 3.0.5 to the AUR to support the new datafields in AUR 1.9 (maintainer, first submitted, last modified). Not sure when I'll get around to implementing the new multiinfo query since it doesn't necessarily offer any user facing benefits.
Offline
burp from [community] doesn't seem to work for me right now, maybe due to recent AUR changes? It could just be my wonky proxy here though, so could someone please confirm?
EDIT: or it could be my wonky brain.... I was trying to upload .pkg.tar.gz instead!
*must* *resist* *temptation* *to* *delete* *post*
Sorry for the noise falconindy and whoever else is subscribed here.
Last edited by ngoonee (2012-07-04 05:09:42)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
burp from [community] doesn't seem to work for me right now, maybe due to recent AUR changes? It could just be my wonky proxy here though, so could someone please confirm?
EDIT: or it could be my wonky brain.... I was trying to upload .pkg.tar.gz instead!
*must* *resist* *temptation* *to* *delete* *post*
Sorry for the noise falconindy and whoever else is subscribed here.
Lol.
ᶘ ᵒᴥᵒᶅ
Offline
I would sincerely suggest lowering the default number of threads for cower to either 1 or 2. I know it was discussed about a year ago, and that cower should use less threads if it doesn't need to, but having errors be the default behaviour seems kind of counter productive. Also, as it only really matters for --update operations, unless you have a massive number of AUR packages, a small number of threads will not hurt you. Having 10 threads for me took about a whole minute to return errors, whereas a check with 1 or 2 threads returned no errors in a few seconds.
Note: I have only 13 AUR packages. Also, my internet isn't that great (6mbit/s down) which could have something to do with it.
Thinkpad T420 | Intel 3000 | systemd {,--user}
PKGBUILDs I use | pywer AUR helper
Offline
I would sincerely suggest lowering the default number of threads for cower to either 1 or 2. I know it was discussed about a year ago, and that cower should use less threads if it doesn't need to, but having errors be the default behaviour seems kind of counter productive. Also, as it only really matters for --update operations, unless you have a massive number of AUR packages, a small number of threads will not hurt you. Having 10 threads for me took about a whole minute to return errors, whereas a check with 1 or 2 threads returned no errors in a few seconds.
Note: I have only 13 AUR packages. Also, my internet isn't that great (6mbit/s down) which could have something to do with it.
There's a config file to adjust this yourself. See the example in /usr/share/doc/cower/config
Offline
KaiSforza wrote:I would sincerely suggest lowering the default number of threads for cower to either 1 or 2. I know it was discussed about a year ago, and that cower should use less threads if it doesn't need to, but having errors be the default behaviour seems kind of counter productive. Also, as it only really matters for --update operations, unless you have a massive number of AUR packages, a small number of threads will not hurt you. Having 10 threads for me took about a whole minute to return errors, whereas a check with 1 or 2 threads returned no errors in a few seconds.
Note: I have only 13 AUR packages. Also, my internet isn't that great (6mbit/s down) which could have something to do with it.
There's a config file to adjust this yourself. See the example in /usr/share/doc/cower/config
I realize this and have edited the file, I'm just saying that having this be the default behaviour seems to be an issue. It would just make sense to have the default be lower.
Thinkpad T420 | Intel 3000 | systemd {,--user}
PKGBUILDs I use | pywer AUR helper
Offline
I found a crash-bug in cower: If both HOME and XDG_CONFIG_HOME are unset, it segfaults when trying to log an error about not being able to find the config file. It looks like since parse_configfile() is called before strings_init(), it's not safe to call cwr_fprintf() from there:
$ gdb ./cower
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ataraxia/nobackup/cower/src/cower-6/cower...done.
(gdb) r -u
Starting program: /home/ataraxia/nobackup/cower/src/cower-6/cower -u
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403af9 in cwr_vfprintf (stream=0x7ffff6e89060 <_IO_2_1_stderr_>, level=LOG_ERROR, format=0x409760 "Unable to find path to config file.\n",
args=0x7fffffffd550) at cower.c:643
643 prefix = colstr->error;
(gdb) bt
#0 0x0000000000403af9 in cwr_vfprintf (stream=0x7ffff6e89060 <_IO_2_1_stderr_>, level=LOG_ERROR, format=0x409760 "Unable to find path to config file.\n",
args=0x7fffffffd550) at cower.c:643
#1 0x00000000004039c4 in cwr_fprintf (stream=0x7ffff6e89060 <_IO_2_1_stderr_>, level=LOG_ERROR, format=0x409760 "Unable to find path to config file.\n")
at cower.c:610
#2 0x0000000000405729 in parse_configfile () at cower.c:1216
#3 0x0000000000408c47 in main (argc=2, argv=0x7fffffffe808) at cower.c:2364
(gdb) p colstr
$1 = (struct strings_t *) 0x0
And yes, this case came up in a real-world situation - I'm running "cower -u" from a systemd service, and it sets neither of these variables by default. (I worked around it easily by setting HOME=/ in this service file.)
Offline
Relevant:
https://github.com/falconindy/cower/com … 2192d21eb8
https://github.com/falconindy/cower/com … 1dcbf9d307
So now you can have a config file, even with HOME and XDG_CONFIG_DIR unset
Last edited by falconindy (2012-09-09 01:30:19)
Offline
Relevant:
https://github.com/falconindy/cower/com … 2192d21eb8
https://github.com/falconindy/cower/com … 1dcbf9d307So now you can have a config file, even with HOME and XDG_CONFIG_DIR unset
Thanks for the quick fix, looks great.
Offline
Can I search for orphans? Currently I use
pacman -Qqm | cower -i --format "%n %m" - | grep orphan
but maybe '-m' could do that too.
Can cower print the new urls, the ones with package name instead of the ID: https://aur.archlinux.org/packages/dehtml/ instead of https://aur.archlinux.org/packages.php?ID=36246 ?
Offline
Can I search for orphans? Currently I use
pacman -Qqm | cower -i --format "%n %m" - | grep orphan
but maybe '-m' could do that too.
No. The AUR needs to offer this feature. I have no way to query for orphans.
Can cower print the new urls, the ones with package name instead of the ID: https://aur.archlinux.org/packages/dehtml/ instead of https://aur.archlinux.org/packages.php?ID=36246 ?
Yes.
Last edited by falconindy (2012-11-14 20:33:03)
Offline
Hi falconindy, sorry if this is the wrong thread, but it is the only I could find
I like cower , so much in fact that I decided it would be the only 'alien' program on my Arch ISO.
I have a project you can find on my GitHub page
Everything works as expected, so this is a very nice tool to have on ISO ... easy AUR access, wonderful.
Now the question; on the ISO, in the root of the file system '/', there is a file called cower, it is the bash_completion file
Since this is placed there during creation of the ISO, I can't break in and change the Makefile, should I change this/is it a problem the file is there or leaf it as is, I mean it is working...
I know I could clone the cower to my main machine, but I thought the way it's done now, you would always install a fresh version, and don't need to pull first...
Besides that, it's also easier for other people to use it this way.
Thanks qinohe
Offline
Now the question; on the ISO, in the root of the file system '/', there is a file called cower, it is the bash_completion file
It's there because you don't have bash-completion installed at the time of building the package. I'll update the makedepends.
Offline
@qinohe, are you saying that when you include cower in the build, it puts the bash completion file at /cower instead of /usr/share/bash-completion/completions/cower? If you include the cower package in the archiso's list of packages to include, it should install cower like it would any other package.
Edit: Wow, I need to learn to refresh my browser before responding to crap.
Last edited by WonderWoofy (2013-10-12 14:54:23)
Offline
Ah, is that what's happening. thanks in advance. It's neater if it's on the right place.
Also I searched trough the files on a correct installed system, where is that completion file located normally?
Offline
Offline
@qinohe, are you saying that when you include cower in the build, it puts the bash completion file at /cower instead of /usr/share/bash-completion/completions/cower? If you include the cower package in the archiso's list of packages to include, it should install cower like it would any other package.
Edit: Wow, I need to learn to refresh my browser before responding to crap.
Thanks this may not be 'your' topic, but yes if you build the ISO with archiso and git clone cower, and make and install it during building, yes thats what happens
$ pacman -Ql cower-git | grep completion cower-git /usr/share/bash-completion/ cower-git /usr/share/bash-completion/completions/ cower-git /usr/share/bash-completion/completions/cower
I go shame myself in the corner..
Last edited by qinohe (2013-10-12 15:06:22)
Offline
Thanks for upgrading cower falconindy, would you be willing to do the same for cower GitHub files?
I wasn't that clear I see, but thats how I pull the files, and build with, thanks
Offline
Thanks for upgrading cower falconindy, would you be willing to do the same for cower GitHub files?
I wasn't that clear I see, but thats how I pull the files, and build with, thanks
I don't understand what you're asking for.
$ git push
Everything up-to-date
$ git push --tags
Everything up-to-date
Offline