Package Details: cower 16-1

Git Clone URL: https://aur.archlinux.org/cower.git (read-only)
Package Base: cower
Description: A simple AUR agent with a pretentious name
Upstream URL: http://github.com/falconindy/cower
Keywords: aur
Licenses: MIT
Submitter: falconindy
Maintainer: falconindy
Last Packager: falconindy
Votes: 693
Popularity: 31.518544
First Submitted: 2010-12-30 02:30
Last Updated: 2016-03-27 18:33

Pinned Comments

falconindy commented on 2016-03-21 12:57

If you are having problems installing this package due to signature verification, please run the below before running makepkg:

gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53

If makepkg still complains after this:

1) Ensure you're using makepkg, and not some wrapper.
2) Ensure you don't have GNUPGHOME set in /etc/makepkg.conf or ~/.makepkg.conf, or that the value of GNUGPHOME in makepkg.conf matches that which you've run the above gpg command with.
3) Ensure that the tarball you downloaded matches the md5sums in the PKGBUILD.

If you have problems locating pod2man during the build, please figure out where your PATH is being overridden. /etc/profile.d/perlbin.sh from the perl package will ensure that pod2man is in your PATH.

Kindly do not do the following because of failures in source tarball verification:

1) Complain that the package is broken.
2) Mark the package out of date.

Due to the amount of spam I receive, I've been forced to disable notifications for this package.

Latest Comments

runical commented on 2016-06-21 20:42

@trygveaa: Whether or not cower is written and maintained by a TU/dev is irrelevant. The AUR is not supported and the policy is to not put AUR helpers in the official repositories. You can try and reopen that discussion yet again, but it won't get you anywhere (and the AUR is not the right place to have this discussion).

Also, if you want to download the pkgbuild, use git with 'git clone https://aur.archlinux.org/$PKGNAME.git'. Works for almost every package. Only split packages have some problems.

trygveaa commented on 2016-06-21 17:54

@djmattyg007: But cower is an application written and supported by falconindy, and since he maintains packages in Arch, he could have maintained cower there as well. Whether the AUR itself is supported or not is irrelevant as far as I see it.

djmattyg007 commented on 2016-05-15 03:34

@trygveaa the answer to that question is obvious: the AUR isn't officially supported by the Arch Linux developers.

trygveaa commented on 2016-05-04 15:46

@falconindy: May I ask if there is any specific reason you don't maintain this in the official repo, rather than AUR? Having it in the official repos would be nice, especially for headless machines, so you wouldn't have to use the web page (or find an URL to download) at all.

runical commented on 2016-04-03 14:54

@AsamK: Assuming you run ArchlinuARM, cower is in the official repos there. [1]

[1] https://archlinuxarm.org/packages/armv6h/cower

AsamK commented on 2016-04-03 12:44

Could you add armv6h to arch? I tested it and it works fine.

Talion commented on 2016-03-28 21:34

While I very much appreciate this package and the efforts required to maintain it, continually receiving the signature verification error on the eight computers I manually update is maddening.

The latest:
gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53
results in the error:
unknown public key 1EB2638FF56C0C53

I found the solution which works for me, now, at: https://bbs.archlinux.org/viewtopic.php?id=152337

[quote=The warning is shown due to signature files attached to the package. It can be solved for packages made by archlinux devs:
- run as user
"# gpg --list-keys"
in order to create a gpg database for your current user, if it is not present already.

- add
"keyring /etc/pacman.d/gnupg/pubring.gpg"
to the end of
~/.gnupg/gpg.conf.[/quote]

kyak commented on 2016-03-27 16:12

@falconindy could you please bump a new release with the LC_NUMERIC fix? This warning is really annoying, and propagates strangely to aur helpers based on cower (like pacaur).
I don't feel like using cower-git, since i will definitely forget to switch back to regular cower once a new version is released.

TrialnError commented on 2016-03-26 23:26

@Case_Of, @ef004: https://github.com/falconindy/cower/issues/126
Either locally modify the PKGBUILD and add the commit as a patch or switch to cower-git until a new version is released.

brittyazel commented on 2016-03-26 18:53

the pod2man issue is that you are not running your terminal as a "login shell" but rather as the default. Without setting it to be a "login shell" the scripts in /etc/profile.d are not sourced, and perl is not added automatically to your path. If you toggle on this setting however, whenever you open the shell it will source all of those files, and add the necessary paths.

I don't yet know if a downside to using "login shell" or a better option to fix this issue.

ef004 commented on 2016-03-26 17:59

after todays update to 15-1 i get
cower -u
warning: unhandled type 2 for key Popularity
...(the same warning 6 more times)
(I have 7 packages installed)
I've already tried recompiling and reinstalling all dependencies
(and i have no config file for cower, if that helps)
edit: downloading and searching still works... no idea if updating works tho

Case_Of commented on 2016-03-26 17:45

I'm getting dozens of those messages on v15: warning: unhandled type 2 for key Popularity
But it still work well though.

falconindy commented on 2016-03-26 17:06

wkoomson, you're mistaken. pod2man is accessible via /etc/profile.d/perlbin.sh. So, something in your "freshly installed arch system" has been tainted to break this.

wkoomson commented on 2016-03-25 13:42

Even after adding Dave Reisner's PGP key, the makepkg didn't work until I ran this command:

sudo ln -s /usr/bin/core_perl/pod2man /usr/bin/pod2man

This is because pod2man is in a directory within /usr/bin, so the command in the Makefile as-is won't work. I'm on a freshly installed arch system.

rabarrett commented on 2016-03-22 05:43

cyisfor:

Yes, when I check with pacman, I get the same response as you:
pacman -Qo /usr/bin/core_perl/pod2man
/usr/bin/core_perl/pod2man is owned by perl 5.22.1-2

cyisfor commented on 2016-03-22 04:14

$ pacman -Qo /usr/bin/core_perl/pod2man
/usr/bin/core_perl/pod2man is owned by perl 5.22.1-2

perl is a dependency of cower. Unless you have perl-fake?

rabarrett commented on 2016-03-21 21:57

I'm not sure if I'm making progress or not.

faconindy's gpg line worked.

I followed the rest of his instructions (checking I don't have GNUGPHOME set wrong orthe wrong tarball), but when I run
makepkg -sri

(after Starting build(),) I get:
==> Starting build()...
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 14" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127

falconindy commented on 2016-03-21 12:57

If you are having problems installing this package due to signature verification, please run the below before running makepkg:

gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53

If makepkg still complains after this:

1) Ensure you're using makepkg, and not some wrapper.
2) Ensure you don't have GNUPGHOME set in /etc/makepkg.conf or ~/.makepkg.conf, or that the value of GNUGPHOME in makepkg.conf matches that which you've run the above gpg command with.
3) Ensure that the tarball you downloaded matches the md5sums in the PKGBUILD.

If you have problems locating pod2man during the build, please figure out where your PATH is being overridden. /etc/profile.d/perlbin.sh from the perl package will ensure that pod2man is in your PATH.

Kindly do not do the following because of failures in source tarball verification:

1) Complain that the package is broken.
2) Mark the package out of date.

Due to the amount of spam I receive, I've been forced to disable notifications for this package.

JonnyJD commented on 2016-03-21 12:19

@rabarett:
Make sure that you use the same user.
You might be running makepkg with a different user (special user or even root.. which you shouldn't) than the one you are running "gpg --recv-key" with.

rabarrett commented on 2016-03-21 07:58

No, that doesn't work. I already did that in previous steps. When I do it (again) now, it just states:
gpg: key F56C0C53: "Dave Reisner <d@falconindy.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

Then any attempt to install cower causes the error I typed below.

Romzetron commented on 2016-03-21 00:47

Try this command, and then makepkg.

gpg --recv-key 1EB2638FF56C0C53

pavelki commented on 2016-03-20 11:55

I am getting the same error as rabarrett on 2016-03-18 19:45

rabarrett commented on 2016-03-18 19:45

When I try manually with makepkg (using the PKGBUILD from cower), I get this:

...
cower-14.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
ERROR: One or more PGP signatures could not be verified!

runical commented on 2016-03-16 20:34

@rabarrett Did you try building the package manually before messing with an aur helper?

Also: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking. That should cover it.

rabarrett commented on 2016-03-16 19:49

niezniszczalny, I just tried that too, but with no luck.

I didn't have the gpg.conf file, so I went ot the link you referred me to and read it. I tried to get it to autocreate the gpg.conf file by running gpg and gpg2. Despite reading the man files for those, I couldn't seem to figure out the right way to "run" it the first time (for most attempts, it would respond "Go ahead and type your message", and I didn't know what to type, so I just hit ctrl-c. But eventually I got set up a passphrase, email, etc. Many of the config files were in ~/.gnupg, but still not gpg.conf file. So I copied the skeleton file from /usr/share/gnupg to ~/.gnupg/ and renamed it gpg.conf. I then uncommented the line you indicated and ran the pacman-key refresh. I saw it bring in lots of new keys and signatures and I was pretty hopeful. But when I was done and tried to use yaourt to install pacaur (which uses cower as dependency), it still failed for the same reason:

ERROR: One or more PGP signatures could not be verified!
ERROR: Makepkg was unable to build cower.


It appears there must be something else I need to do, but I thought the point of AUR was that it takes care of many of these installation issues for us. If there is another page I should read to help myself more, please let me know.

niezniszczalny commented on 2016-03-16 17:19

@xtor91 solution worked for my PGP problem. To remind everybody:
"Just to make sure everyone understands exactly how to resolve the issue where the PGP signature could not be verified while installing this package.

First, edit "~/.gnupg/gpg.conf" and uncomment the following line (remove the #):
keyserver-options auto-key-retrieve

Then, execute the following command:
sudo pacman-key --refresh-keys

The PGP signature should now be properly verified. "

If someone doesn't have gpg.conf file (as me) please read carefully wiki https://wiki.archlinux.org/index.php/GnuPG#Configuration_files
'Configuration files' section

rabarrett commented on 2016-03-13 23:27

I followed that (added with gpg --keyserver pgp.mit.edu --recv-keys F56C0C53).

Still no help. When using yaourt to add cower (as part of installing pacaur in my case--or on its own), I still get the error:

ERROR: One or more PGP signatures could not be verified!
ERROR: Makepkg was unable to build cower.

dlin commented on 2016-03-09 05:55

To solve the PGP problem, you can try one of these command.
gpg --keyserver pgp.mit.edu --recv-keys F56C0C53
curl "https://pgp.mit.edu/pks/lookup?op=get&search=0xF56C0C53" -o - | gpg --import

gothmog.todi commented on 2016-03-01 06:28

please read the older comments. you have to import the right gpg key.

bubuntux commented on 2016-03-01 06:10

==> ERROR: One or more PGP signatures could not be verified!

goetzc commented on 2016-02-05 00:02

Sure, as a rebuild is necessary for everybody, a pkgrel increment would have solved the problem for many people.

vyachkonovalov commented on 2016-02-02 22:09

@arnottcr, you're right.
And I think pkgrel just should be incremented in this case.

axolotl commented on 2016-02-02 20:06

core/pacman hit version 5.0.0-1 as of 2016-02-01 05:05 UTC
It appears that manually rebuilding cower does fix the issue

thx1138 commented on 2016-01-31 15:24

> it uses cower
Apparently not for this particular command. It worked for me as shown.

Rasi commented on 2016-01-31 10:22

ehm.. you cant reinstall with pacaur, because it uses cower :)

thx1138 commented on 2016-01-31 01:49

If you get testing/pacman 5.0.0-1, cower will throw

cower: error while loading shared libraries: libalpm.so.9: cannot open shared object file: No such file or directory

where testing/pacman 5.0.0-1 has now /usr/lib/libalpm.so.10.0.0

You could then re-compile cower with the new version of libalpm,

pacaur -S cower

wwed commented on 2016-01-08 11:14

to resolve gpg-error:
gpg --keyserver pgp.mit.edu --recv-keys F56C0C53

thestinger commented on 2015-12-13 06:59

@JohnRobson: Read the older comments or the wiki. The package using a GPG signature for the source isn't a bug, and more packages should do it.

JohnRobson commented on 2015-12-13 06:56

==> Verifying source file signatures with gpg...
cower-14.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build cower.

ThePierrezou commented on 2015-10-19 18:55

@runical Sorry I don't know if i'm blind or stupid but i didn't check. Sorry :/
Thanks

runical commented on 2015-10-18 20:03

@ThePierrezou: Did you even take a look at the comments or the wiki? If not, please do so. If you did, look again and if it is still unclear, formulate a question with the needed information.

ThePierrezou commented on 2015-10-18 19:54

Hi,
Having pgp key error when trying to install this package.
Can you do something ?
Thanks

runical commented on 2015-09-29 18:54

On top of that, ArchARM includes it in their own AUR repo, so there is no need to actually build it.

thestinger commented on 2015-09-29 17:42

The officially supported architectures are i686 and x86_64. Packages in the official repositories don't include ARM architectures in the architecture array, so it's strange to expect AUR packages to do it...

pozar87 commented on 2015-09-29 17:37

It also seems work well on 'armv6h'

Best Regards

luka12345 commented on 2015-09-29 11:18

Can you please add armv7h to the arch list? So it looks like this:

arch=('i686' 'x86_64' 'armv7h')

I've tested it on this platform and it works just fine.

Barikad commented on 2015-09-14 18:52

gpg --recv-keys 1EB2638FF56C0C53

Ownaginatious commented on 2015-09-14 01:50

To anyone still having issues with the GPG signatures, here is a very clear explanation of the issue and how to fix it: http://jotham-city.com/blog/2015/02/14/verifying-gpg-signatures-for-makepkg/

I still had problems after following everything everyone mentioned below. Changing the keyserver to hkp://pgp.mit.edu in the gpg.conf file is what ended up fixing it.

Hope that resolves some headaches!

highway commented on 2015-09-09 22:02

do I need to do something after enabling auto-retrieve? I still get the error when I have my server selected, and gpg.conf file set to get the keys automatically. do I need to add falconindy's key somewhere?

tiberiousr commented on 2015-09-09 12:59

md5sum in the PKGBUILD is incorrect, it should be 0e09bb69078ab5134ddaf5e7ccb0c414

JonnyJD commented on 2015-09-08 01:50

@thestinger:
Yes, GPG is not only "cower related". However, this *is* a frequent problem here and listing the solution here helps. Regardless of having it documented in more general places (and previous comments..).
Packages not using GPG signatures aren't necessarily bad. Most upstream sources are not signed. At least not the tarballs. Debian for example signs the dsc files inline, which doesn't help in AUR (out of the box) for multiple reasons. Many other upstream tarballs are not signed in any way.
Anyways, having https://bugs.archlinux.org/task/10863?project=2 implemented would help.

thestinger commented on 2015-09-07 22:56

@JonnyJD: It's not a caveat related to this package though... *any* package using GPG signatures for source verification will require either retrieving the key manually or using auto-retrieve. The quality of AUR packages just tends to be quite low so people aren't including upstream's GPG signatures. If people built packages from the repos via ABS they would hit it all the time.

falconindy commented on 2015-09-07 22:42

I feel like this package is turning into an Arch Linux IQ test...

1) Do you know how shell initialization works? The perl package already adds the relevant paths via /etc/profile.d magic. This is for simplicity.
2) Do you understand how makepkg and GPG signatures work? You need to import my key in order to verify the signature. This is for your own good.

If you've answered "no", or "I'm not sure" to either of the above questions, then you're probably also here posting a duplicate of a comment complaining that my packaging is broken in some way.

alexvanaxe commented on 2015-09-07 22:39

I got an error:
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 13" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127
==> ERROR: A failure occurred in build().
Aborting...

To solve this I had to export this before:
export PATH=/usr/bin/core_perl:$PATH

bjo commented on 2015-09-06 09:35

Sign here
[ ]
if you read the comments below.

Simone98RC commented on 2015-09-06 09:33

Latest release won't be installed due to unknown PGP key error (1EB2638FF56C0C53).

JonnyJD commented on 2015-09-03 10:47

It might help to vote for this:
https://bugs.archlinux.org/task/10863?project=2
This would add a maintainer info box here (above the comments).

Crashlog commented on 2015-09-03 10:40

The information about key auto-retrieval should probably be put in a more visible place on the wiki. Otherwise this really will never stop.

kyak commented on 2015-09-03 06:50

This will never stop. Just you watch.

thestinger commented on 2015-09-03 02:01

Read the previous comments.

MichaelRpdx commented on 2015-09-03 02:00

makepkg failure:
==> Verifying source file signatures with gpg...
cower-13.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)

Where should I have this key from?

colinkeenan commented on 2015-09-01 00:00

cp /usr/share/gnupg/gpg-conf.skel ~/.gnupg/gpg.conf

If you discover you're missing ~/.gnupg/gpg.conf

colinkeenan commented on 2015-08-31 23:59

For anyone else reading these comments who discovers they don't have "~/.gnupg/gpg.conf", you can copy it:

cp /usr/share/gnupg/gpg-conf.skel ~/.gnupg/gpg.confcp /usr/share/gnupg/gpg-conf.skel ~/.gnupg/gpg.conf

JonnyJD commented on 2015-08-25 00:04

@Ravenman:
Please do read how user configuration files (dot files) work.
This is the exact same problem everybody has.

Yes, your installation is a bit older and your home directory doesn't have a default gpg.conf already. Mine also didn't.
That doesn't mean that you can't just put that line in a newly created configuration file. Or the system-wide installation.

Do what @Crashlog says, read this:
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
and possibly this:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/home.html
It explains how the "dot files" work. You seem to have some misconceptions here.
Though, I tried to find a good intro on how configuration files (user/system) work and with my Google magic most of the results didn't explain that part at all..

Crashlog commented on 2015-08-24 23:39

@Ravenman, you should read the wiki page for makepkg.

Also, when you get an error that a file doesn't exist, your first instinct shouldn't be to switch packages entirely. It should be to try and figure out _why_ the file doesn't exist.

Crashlog commented on 2015-08-24 23:34

@Ravenman, you should read the wiki page for makepkg.

Ravenman commented on 2015-08-24 23:32

@JonnyJD Do you think that I did not read before asking for help?

Do you know my system?.

Your mentioned solution did not work for me:

[user@localhost ~]$ cat ~/.gnupg/gpg.conf
cat: /home/user/.gnupg/gpg.conf: No such file or directory
[user@localhost ~]$

My solution may not be correct, but is it worked for me and perhaps it may be useful for someone else.

Yes, it's rude. If you are tired of giving answers to the same question, let someone else do it and those ways are not necessary.

JonnyJD commented on 2015-08-24 23:09

@Ravenman:
No, that is nonsense.
Yes, cower-git doesn't check the source signature, but using the git version of cower is not the solution.

The solution is to configure gnupg to load the keys automatically or you should do it manually.

And seriously:
The solution to your problem is given exactly one post below yours by xtor91

Edit "~/.gnupg/gpg.conf" and uncomment the following line (remove the #):
keyserver-options auto-key-retrieve
(for the user running makepkg)

There are more than 500 votes for this package. If you do have a problem then it is likely that you are not the first.
READ THE PREVIOUS COMMENTS.

That might sound rude, but there have been more than 70 comments this year already and most of them because of the issue and it was answered at least a dozen times already.

Ravenman commented on 2015-08-24 22:59

Solution is simple: If you need install cower in your system at this time, try with cower-git (Available in AUR too).

@graysky Thanks by your help.

graysky commented on 2015-08-24 22:16

Holy overkill, batman. How many times are people going to post the same exact problem which has been answered ad nauseam in this very AUR page?

<<Disable notifications>>

Ravenman commented on 2015-08-24 21:16

I can not install this package:

==> Building and installing package
==> Making package: cower 13-1 (Mon Aug 24 16:13:48 COT 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading cower-13.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 23051 100 23051 0 0 28207 0 --:--:-- --:--:-- --:--:-- 28179
-> Downloading cower-13.tar.gz.sig...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 287 100 287 0 0 1247 0 --:--:-- --:--:-- --:--:-- 1253
==> Validating source files with md5sums...
cower-13.tar.gz ... Passed
cower-13.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
cower-13.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build cower.
==> Restart building cower ? [y/N]
==> ------------------------------
==>

Somebody knows one fix?

xtor91 commented on 2015-08-22 22:55

Just to make sure everyone understands exactly how to resolve the issue where the PGP signature could not be verified while installing this package.

Edit "~/.gnupg/gpg.conf" and uncomment the following line (remove the #):
keyserver-options auto-key-retrieve

Then try installing again, the PGP signature should now be properly verified.

@JonnyJD: fixed.

xtor91 commented on 2015-08-22 18:13

Just to make sure everyone understands exactly how to resolve the issue where the PGP signature could not be verified while installing this package.

Edit "~/.gnupg/gpg.conf" and uncomment the following line (remove the #):
keyserver-options auto-key-retrieve

Then try installing again, the PGP signature should now be properly verified.

@JonnyDJ: fixed.

JonnyJD commented on 2015-08-22 16:24

How does pacman-key come into this? This would update the special keyring used for pacman. This has nothing to do with the keyring used by makepkg.

Makepkg uses the default keyring of the user running makepkg.
You also don't need to update/refresh anything. Run makepkg again and it will work.

xtor91 commented on 2015-08-22 16:21

Just to make sure everyone understands exactly how to resolve the issue where the PGP signature could not be verified while installing this package.

First, edit "~/.gnupg/gpg.conf" and uncomment the following line (remove the #):
keyserver-options auto-key-retrieve

Then, execute the following command:
sudo pacman-key --refresh-keys

The PGP signature should now be properly verified.

thestinger commented on 2015-08-21 06:51

@sadid: Or you could turn on key auto-retrieve instead of disabling a security feature.

sadid commented on 2015-08-21 06:47

I install it by "makepkg --skipinteg -sc" due to its failure with integrity check!

Crashlog commented on 2015-08-20 22:27

And also read the wiki page for makepkg.

thestinger commented on 2015-08-20 22:26

@bjo: Turn on auto-retrieve if you don't want to fetch keys yourself then.

bjo commented on 2015-08-20 22:26

Signature check fails due to unknown pgp key.

DoctorJellyface commented on 2015-08-02 11:52

Binero, for future reference, you had perl installed, but it's configuration wasn't sourced yet. That happens on boot.

qqqqqqqqq9 commented on 2015-06-09 08:23

runical commented on 2015-06-06 08:55

@betseg: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

betseg commented on 2015-06-06 08:38

Signature error...

betseg commented on 2015-06-06 08:37

gpg error

Binero commented on 2015-06-01 15:30

@runical @l1n The issue seems to have resolved itself, thanks anyway. :)

l1n commented on 2015-05-27 12:56

@Binero: For future reference, appending the location of pod2man to my PATH solved it for me (See https://bbs.archlinux.org/viewtopic.php?id=120256).

runical commented on 2015-05-26 20:32

@Binero: That command is provided by the perl package. Give some more info on when you find the error. As is, there is absolutely no info with which we can help.

runical commented on 2015-05-26 20:31

@Binero: Do you have perl installed?

Binero commented on 2015-05-26 15:53

Getting an error:
/bin/sh: pod2man: command not found

Crashlog commented on 2015-05-18 14:35

mthx, read the wiki: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

mthx commented on 2015-05-18 14:30

Got an error installing cower. It appears as though the PGP signature can not be verified.

==> Verifying source file signatures with gpg...
cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build cower.

boyvanduuren commented on 2015-05-12 07:30

Just want to confirm visit's reply (2015-03-21 04:42), compilation of cower on armv6h works. Could you please add it to the supported architectures?

falconindy commented on 2015-05-09 14:48

You've unsuccessfully proposed a correlation between a set of completely unrelated events.

1) If you're hitting a timeout, either increase the timeout or decrease the number of threads (thereby decreasing the number of connections). The manpage explains how to adjust these values.

2) You need to quote the URL if it contains shell metachars like '&'. The URL passed to curl is being cut off at that point and the process is backgrounded, and your shell now contains the shell variable "arg" with the value "cower".

3) DNS is wholly irrelevant if you're getting back a response from the remote in your terminal and in your browser. The name lookup was clearly successful if you were able to send a request and get a response.

alonhar commented on 2015-05-09 13:15

when I type cower -u
I get "Timeout was reached"

I think that I my problem is that
curl -s https://aur.archlinux.org/rpc.php?type=search&arg=cower

give me {"version":1,"type":"error","resultcount":0,"results":"No request type\/data specified."}

but on the browser https://aur.archlinux.org/rpc.php?type=search&arg=cower
is a list success.

I tried change the dns to google dns but I dont see any changes.

ethanol commented on 2015-05-01 07:28

For some reason today, I got the following notices/warnings:

gzip: stdin: not in gzip format

gzip: stdin: not in gzip format

Maybe pass the --quiet flag to zcat?

Naypam commented on 2015-04-11 07:54

Just a quick thanks to runical, adding "keyserver-options auto-key-retrieve" to my ~/.gnupg/gpg.conf fixed the error I was getting.

Thanks.

visit commented on 2015-03-21 04:42

Please add 'armv6h' to the arch array. Tested it and works.

crs commented on 2015-03-04 20:16

I think these are additional makedepends: make gcc binutils fakeroot yajl

falconindy commented on 2015-03-04 20:16

You can think that all you want. You're wrong.

crs commented on 2015-03-04 20:15

I think these are additional makedepends: make gcc binutils yajl

runical commented on 2015-02-28 09:24

@darkstar999: Did you set up a personal keyring? The key has to be in the personal keyring of the user in order to build, even with the validpgpkeys array. The validpgpkeys array only overwrites the trust values, not the need to have the key in the first place.

So, set up your keyring and to automate the retrieval process, put the following in .gnupg/gpg.conf:

keyserver-options auto-key-retrieve

You can find a skeleton config file in /usr/share/gnupg/gpg-conf.skel

darkstar999 commented on 2015-02-28 07:38

Pleas fix The PGP ERROR!

==> Überprüfe Gültigkeit der Quell-Dateien mit md5sums...
cower-12.tar.gz ... Durchgelaufen
cower-12.tar.gz.sig ... Übersprungen
==> Überprüfe Signaturen der Quell-Dateien mit gpg...
cower-12.tar.gz ... FEHLGESCHLAGEN (Unbekannter öffentlicher Schlüssel 1EB2638FF56C0C53)
==> FEHLER: Eine oder mehrere PGP-Signaturen konnten nicht überprüft werden!

Zatherz commented on 2015-02-12 20:08

@SirPortal
env PATH="$PATH:/usr/bin/core_perl" makepkg

runical commented on 2015-02-04 12:10

We really need to update the wiki on the AUR to include a link to the makepkg wiki page.

@Kuci: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Kuci commented on 2015-02-04 09:14

cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)

richli commented on 2015-02-01 16:45

@SirPortal:

$ pacman -Qo $(which pod2man)
/usr/bin/core_perl/pod2man is owned by perl 5.20.1-1

perl is already a makedep, so I don't know why you'd get that error

SirPortal commented on 2015-02-01 09:07

pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 12" README.pod cower.1
/bin/sh: pod2man: command not found
there isn't pod2man in repo and even in aur :(

SirPortal commented on 2015-02-01 09:05

pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 12" README.pod cower.1
/bin/sh: pod2man: command not found
if pod2man is in packge add package to dependencies

SirPortal commented on 2015-02-01 09:03

/bin/sh: pod2man: command not found

gyurman commented on 2015-01-31 15:53

gpg --keyserver pgp.mit.edu --recv-key 1EB2638FF56C0C53

erholst commented on 2015-01-29 07:30

Ah, ok. Thx. I just imported the key with:
gpg --keyserver subkeys.pgp.net --recv-key 1EB2638FF56C0C53
and then it worked. Did enable auto-key-retrieve but forgot to restart so it didn't work.

thestinger commented on 2015-01-29 06:55

There is no need to sign / trust any keys, makepkg doesn't care about that.

thestinger commented on 2015-01-29 06:54

Enabling auto-key-retrieve will result in GPG automatically retrieving the key. It will validate the sources with the key as long as the fingerprint is listed in the PKGBUILD, which it is. If you don't want to use auto-key-retrieve then you can fetch them manually but there's not really any security advantage to doing it by hand with `--recv-keys`.

erholst commented on 2015-01-29 06:45

does not work.
what command do i have to type to make the keys work?

why should i not sign blindly? 99% of AUR doesn't even have keys...
how can i disable a key one time and not globally if i am not supposed to sign without knowing the person personally?

thestinger commented on 2015-01-29 06:44

(uncomment `keyserver-options auto-key-retrieve` in ~/.gnupg/gpg.conf and your life will be a lot easier - the fingerprints are in the PKGBUILDs now anyway)

erholst commented on 2015-01-29 06:44

does not work.
what command do i have to type to make the keys work?

why should i not sign blindly? 99% of AUR doesn't even have keys...

erholst commented on 2015-01-29 06:43

package does not work, how do i add the keys to make it work?

thestinger commented on 2015-01-29 06:42

can someone make this crappy user work? i want to gain back my faith in humanity, thx

quelqu'un peut faire ce travail de paquet de merde ? je veux utiliser pacaur , thx

== > Überprüfe Signaturen der Quell - Dateien mit gpg ...
recroqueviller - 12.tar.gz ... FEHLGESCHLAGEN ( Unbekannter öffentlicher Schlüssel 1EB2638FF56C0C53 )
== > FEHLER : Eine oder mehrere PGP - Signaturen könnten nicht überprüft werden !
== > FEHLER : makepkg konnte recroqueviller nicht erstellen .
== > Erstellen von blottir neu starten ? [ J / N ]

erholst commented on 2015-01-29 06:38

can someone make this crappy package work? i want to use pacaur, thx

==> Überprüfe Signaturen der Quell-Dateien mit gpg...
cower-12.tar.gz ... FEHLGESCHLAGEN (Unbekannter öffentlicher Schlüssel 1EB2638FF56C0C53)
==> FEHLER: Eine oder mehrere PGP-Signaturen konnten nicht überprüft werden!
==> FEHLER:Makepkg konnte cower nicht erstellen.
==> Erstellen von cower neu starten?[j/N]

alexjj commented on 2015-01-17 05:45

@DrewFmStateFarm, try this:
To allow makepkg to fetch keys as needed from the keyserver automatically, uncomment the option keyserver-options auto-key-retrieve in the ~/.gnupg/gpg.conf configuration file.

Worked for me after it complained about PGP key.

bmoriarty commented on 2015-01-16 04:06

Someone correct me if I'm wrong (like if this is an insecure approach), but to fix the missing key error that @awim mentioned you can just do:

pacman-key --recv-key F56C0C53

To add the key to the keyring. It works for me, and was easier than copy/pasting from pgp.mit.edu.

DrewFmStateFarm commented on 2015-01-16 00:54

Looks like your resource sigs are broken or out of date.

Soukyuu commented on 2015-01-13 13:50

Hmm... I'm getting this when building cower (makepkg -sri)

pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 12" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127

I used to be able to build it just fine, perl is installed. If it matters, I'm accessing the PC via vnc.

falconindy commented on 2015-01-12 15:56

SysGhost: please stop filling my inbox with garbage and rebuild cower in a clean directory.

makepkg -Ci

SysGhost commented on 2015-01-12 15:49

See this thread:
https://bbs.archlinux.org/viewtopic.php?id=191605

Post #5

@SanskritFritz
Nope. I even tried rebooting ht computer. Also tried unisntalling cower, and rebuild it manually. Still no go. pacman and its databases works just fine, so there should be no faults there.

SysGhost commented on 2015-01-12 15:42

See this thread:
https://bbs.archlinux.org/viewtopic.php?id=191605

Post #5

SanskritFritz commented on 2015-01-12 15:42

Weren't you running pacman at the same time?

SysGhost commented on 2015-01-12 15:13

Out of the blue, cower stopped working:

failed to initialize alpm: could not find or read directory
error: failed to initialize alpm library

I made no changes on my system. No updates. It just suddenly stopped working.
It worked at first. Then it didn't.

ProfessorKaos64 commented on 2015-01-09 03:21

techstone's solution worked great, i'll have to remember that. Thanks!

awim commented on 2015-01-08 08:01

those who faced the problem

==> Verifying source file signatures with gpg...
cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!

reading the following article will help.

http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

specifically i was confused because `pacman-key --list-keys` listed falconindy and i was getting the 'unknown public key' error

SanskritFritz commented on 2015-01-07 15:11

@techstone Thank you!

techstone commented on 2015-01-07 14:52

@SanskritFritz, go to http://pgp.mit.edu/ and extract a key using "0xF56C0C53" as the search term. Click on the "F56C0C53" hyperlink in the resulting page which should bring to the public key. Copy/paste the whole block into a text file and then run "gpg --import <text_file_name>" on your Arch box.

SanskritFritz commented on 2015-01-07 09:26

I can't get the key via gpg due to firewall restrictions. How can I manually download and install the key?

neitsab commented on 2015-01-07 00:47

For those not willing to manually download every key they need to build AUR packages, know that GPG can be instructed to do it automatically itself: see the Tip box at https://wiki.archlinux.org/index.php/Makepkg#Signature_checking. It solved my AUR packages update issues (but not my trust ones ;-))

agent0 commented on 2015-01-04 23:46

hollunder's problem was solved by poly's solution for me:
gpg --keyserver pgp.mit.edu --recv-keys F56C0C53

blablubb1234 commented on 2014-12-31 11:29

+1 for hollunder's solution. Works perfectly well :)

blablubb1234 commented on 2014-12-31 11:29

+1 for hulunder's solution. Works perfectly well :)

Xarin commented on 2014-12-29 22:51

My bad, wasn't paying enough attention with my google fu, reinstalling package-query worked.

Scimmia commented on 2014-12-29 22:39

@Xarin, package-query has nothing to do with cower. If you have a problem with package-query, fix package-query.

Xarin commented on 2014-12-29 22:36

Apologies if I'm missing something. I've manually reinstalled cower successfully but I'm still "getting package-query: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory"

Sara commented on 2014-12-29 18:35

Ah, didn't see the previous comment, retrieving the key is indeed better. :P Thanks!

Sara commented on 2014-12-29 18:33

I rebuilt cower by also passing the "skipinteg" option to makepkg. Whether or not that's ideal is a different question... but cower does work perfectly now, post rebuilding.

polyzen commented on 2014-12-29 18:31

kyak, it would've been. This worked for me: gpg --keyserver pgp.mit.edu --recv-keys F56C0C53

hollunder commented on 2014-12-29 18:15

Cower 12-2 no longer works:
$ cower -udf
cower: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

Rebuilding it fails too:
==> Verifying source file signatures with gpg...
cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!

kyak commented on 2014-12-29 17:49

Well, i only had to spend some time figuring out how to import his PGP key into my local keyring. Wouldn't it be convenient if the maintainer posted the command?

echo "keyring /etc/pacman.d/gnupg/pubring.gpg" >> ~/.gnupg/gpg.conf

Anyway, if it's wrong, please correct me.

polyzen commented on 2014-12-29 16:13

Please read the comments before posting one of your own. The maintainer already provided the solution, which is to import his PGP key into your local keyring

fallon9111 commented on 2014-12-29 11:27

FYI:
$ makepkg --skippgpcheck

orschiro commented on 2014-12-29 08:19

@brittyazel

Thanks for commenting. I face the same PGP issue and thought it is an issue on my local system.

brittyazel commented on 2014-12-29 08:16

Trying to reinstall cower today after the pacman update, I get this error:

cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> ERROR: One or more PGP signatures could not be verified!

I had to force the makepkg to ignore package checking in order to get it to build.

gnubeest commented on 2014-12-29 04:34

@whahn1983: Because you didn't rebuild cower against the new libalpm.

whahn1983 commented on 2014-12-29 04:14

After Pacman 4.2 update, "cower: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory"

Siavash commented on 2014-12-21 06:54

@poly Thanks!

polyzen commented on 2014-12-21 05:43

Although I've rebuilt cower since the pacman upgrade, it keeps looking for libalpm.so.8:

> cower -u
cower: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

Dec 19 06:08 /usr/lib/libalpm.so.9.0.0
cower 12-2 Build Date: Sun 21 Dec 2014 12:30:47 AM EST

polyzen commented on 2014-12-20 16:14

Slavash, you could just change the Source yourself

https://wiki.archlinux.org/index.php/PKGBUILD#source

Siavash commented on 2014-12-20 03:43

@falconindy

Hello, source tarballs hosted on your website aren't accessible from Iran. Can you please change the download links to the ones hosted on github?

Siosm commented on 2014-12-19 19:04

My bad sorry, I've removed my horrible comment...

falconindy commented on 2014-12-19 17:51

Do NOT locally sign my key.

The 12-2 PKGBUILD has a validpgpkeys entry, which asserts that only my key is valid for signing the package. You must *import* my key to your local keyring, but do NOT sign it.

Do NOT locally sign my key.

Oh, and by the way, do NOT locally sign my key.

Siosm commented on 2014-12-19 17:46

@bstaletic: you also need to at least locally sign the key and with pacman 4.2 you will also need to trust it:
$ gpg --lsign 1EB2638FF56C0C53

bstaletic commented on 2014-12-19 17:36

Failed to build the package. By default makepkg shows "cower-12.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)", and if I add "keyring /etc/pacman.d/gnupg/pubring.gpg" to my ~/.gnupg/gpg.conf makepkg says " cower-12.tar.gz ... FAILED (the public key 487EACC08557AD082088DABA1EB2638FF56C0C53 is not trusted)
==> ERROR: One or more PGP signatures could not be verified!"

davispuh commented on 2014-11-22 06:49

'armv7h' can be added to arch, it compiled and seems to be working.

bhoppi commented on 2014-09-23 01:21

Today I keep got messages like this for each installed AUR packages:
error: [*]: Problem with the SSL CA cert (path? access rights?)

falconindy commented on 2014-08-14 19:45

You can either import and trust my key, or you can skip pgp sum checking...

Soukyuu commented on 2014-08-14 18:13

installing the package just gave me this:
===============
==> Verifying source file signatures with gpg...
cower-11.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.

Anonymous comment on 2014-06-30 06:13

I don't think curl and openssl should be listed as deps as pacman pulls them in, unless you are just being explicit in case that changes.

juantascon commented on 2014-06-17 15:58

I think is not added automatically because I'm using fish instead of bash, adding core_perl to PATH fixed it. Cheers

Snowman commented on 2014-06-03 12:48

This is already done by the perl package. You need to relogin after installing perl for the change to take effect.

kaede commented on 2014-06-03 10:33

Getting the same error:
/bin/sh: pod2man: command not found

What about including
export PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl"
in the installer script?

smlb commented on 2014-05-17 11:09

@juantascon: `export PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl"`

You need to export perl path in your {.bashrc,.zshrc}

thestinger commented on 2014-04-22 18:30

The only supported architectures are i686 and x86_64. If you're using Arch ARM, adding the architecture to packages here is your responsibility for now.

1ace commented on 2014-04-22 18:13

I didn't think of it this way, but I guess you're right.
You could add `armv6h` then, as I tested it and it compiles and works fine :)

thestinger commented on 2014-04-22 17:16

The architecture refers to the compiled package, not the source package. Using 'any' would be incorrect because the resulting package wouldn't be considered architecture dependent.

1ace commented on 2014-04-22 16:59

I think you should set the `arch` to `any`, as it is a source package, not precompiled for only some architectures.

cippaciong commented on 2014-04-21 16:09

@juantascon: You are probably missing perl which is a makedepend.

juantascon commented on 2014-04-21 15:42

Im getting this error:

==> Extracting sources...
-> Extracting cower-11.tar.gz with bsdtar
==> Starting build()...
cc -std=c99 -g -pedantic -Wall -Wextra -pthread -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DCOWER_VERSION=\"11\" -D_FORTIFY_SOURCE=2 -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro cower.c -lcurl -lalpm -lyajl -larchive -lcrypto -o cower
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 11" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127
==> ERROR: A failure occurred in build().
Aborting...

falconindy commented on 2014-04-13 11:51

Seems like the dom0 that code.falconindy.com is on was wedged. The whole thing was rebooted at some point.

fiveofakind commented on 2014-04-13 06:48

Yeah, definitely could have been either way, I didn't think to check it using external means at the time. Just wanted to let people know in case it wasn't just me who had the problem. Anyway, sorry for the comment spam!

SanskritFritz commented on 2014-04-13 06:39

I didn't doubt it, just pointed out that it works again, or you had a problem with your network.

fiveofakind commented on 2014-04-13 06:29

pretty sure it was down at the time I posted, it's up now though

SanskritFritz commented on 2014-04-13 06:08

http://www.downforeveryoneorjustme.com/code.falconindy.com
It's just you. http://code.falconindy.com is up.

fiveofakind commented on 2014-04-13 03:44

Can't download the source.. code.falconindy.com is down

cippaciong commented on 2014-03-24 19:49

@qdoe: ARM architecture is not officially supported by Archlinux so I don't think he should add it in the PKGBUILD.
That said, I suggest you to install cower from archlinuxarm aur repo (described here http://archlinuxarm.org/developers/contributing) or simply build it with makepkg --ignorearch (or makepkg -A) to ignore the arch field in the PKGBUILD as the archlinuxarm devs do themselves.

5chdn commented on 2014-03-24 19:16

Hi, could you add 'armv6h' to arch in PKGBUILD file?
This allows to install cower on raspberry pi.

Tested & working:
arch=('i686' 'x86_64' 'armv6h')

thestinger commented on 2014-03-05 16:26

@indianahorst: There's no reason to seek help by being rude and confrontational. This package works for others, so there's clearly something wrong on your system. I'm tired of getting these emails, so you can consider this while suspended.

kyak commented on 2014-03-05 07:00

This PKGBUILD works very fine here. Maybe we wait for indianawhorst to reboot for perl directories from profile.d to get added to the path.

indianahorst commented on 2014-03-05 00:25

@Siosm
> This PKGBUILD works fine

It doesn't. Proof:

----------------------------------------------------
==> Validating source files with md5sums...
cower-11.tar.gz ... Passed
cower-11.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
cower-11.tar.gz ... gpgkeys: HTTP fetch error 6: Could not resolve host: pgpkeys.pca.dfn.de
FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.
==> Extracting sources...
-> Extracting cower-11.tar.gz with bsdtar
==> Starting build()...
cc -std=c99 -g -pedantic -Wall -Wextra -pthread -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DCOWER_VERSION=\"11\" -D_FORTIFY_SOURCE=2 -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro cower.c -lcurl -lalpm -lyajl -larchive -lcrypto -o cower
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 11" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127
==> ERROR: A failure occurred in build().
Aborting...
:: cower cleaned

----------------------------------------------------

I am not willing to change anything in /etc/profile.d just because this single package has changed anything (here: relying on pod2man).

Instead, I will stop using this piece of software and use something more functional like Yaourt.

Just for the record: base-devel is installed, including automake.
And: pod2man is in the shell search path:
~$ which pod2man
/usr/bin/core_perl/pod2man

indianahorst commented on 2014-03-05 00:23

@Siosm
> This PKGBUILD works fine

It doesn't. Proof:

----------------------------------------------------
==> Validating source files with md5sums...
cower-11.tar.gz ... Passed
cower-11.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
cower-11.tar.gz ... gpgkeys: HTTP fetch error 6: Could not resolve host: pgpkeys.pca.dfn.de
FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.
==> Extracting sources...
-> Extracting cower-11.tar.gz with bsdtar
==> Starting build()...
cc -std=c99 -g -pedantic -Wall -Wextra -pthread -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DCOWER_VERSION=\"11\" -D_FORTIFY_SOURCE=2 -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro cower.c -lcurl -lalpm -lyajl -larchive -lcrypto -o cower
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 11" README.pod cower.1
/bin/sh: pod2man: command not found
Makefile:27: recipe for target 'cower.1' failed
make: *** [cower.1] Error 127
==> ERROR: A failure occurred in build().
Aborting...
:: cower cleaned

----------------------------------------------------

I am not willing to change anything in /etc/profile.d just because *your* package has changed anything (here: relying on pod2man).

Instead, I will stop using this piece of software and use something more functional like Yaourt.

Just for the record: base-devel is installed, including automake.
And: pod2man is in the shell search path:
~$ which pod2man
/usr/bin/core_perl/pod2man

vicp74 commented on 2014-03-04 22:50

juantascon: You should install base-devel: pacman -S --needed base-devel

To use pod2man, this package depends on perl. Nevertheless, to use a package from AUR, the users are supposed to install base-devel [1] so they install pacman [2] and automake (which depends on perl, so it should be installed [3]) among others.

[1] https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Getting_started
[2] By the way, it's not necesary to add pacman or curl as dependencies because pacman requires curl.
[3] https://www.archlinux.org/packages/core/any/automake/

Siosm commented on 2014-03-04 22:35

@ndianahorst: This PKGBUILD works fine. Have you even tried to understand what's wrong with your setup?

indianahorst commented on 2014-03-04 22:18

No. This package, maintained by you, doesn't build. In the past, it has built. So *you* have to fix it.

falconindy commented on 2014-03-04 16:54

pod2man is part of perl and a fragment in /etc/profile.d makes it accessible via your PATH. Nothing to be fixed in cower.

juantascon commented on 2014-03-04 16:43

can't compile version 11-1, probably missing dependency:

make: Entering directory '/root/cower/src/cower-11'
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 11" README.pod cower.1
/bin/sh: pod2man: command not found

Cheers

Snowman commented on 2014-02-03 02:59

The license file is missing.

lparcq commented on 2014-01-25 15:30

You're right :-) Thanks for changing this anyway.

falconindy commented on 2014-01-24 17:54

It's "intentional" in that you didn't follow the makedepends and bash-completion wasn't installed.

I just pushed cower 11 which no longer relies on bash-completion.

lparcq commented on 2014-01-24 17:36

cower install a shell script in the root directory. Is it on purpose?
Thank you.

doits commented on 2014-01-18 17:51

armv76h works for me

jellysheep commented on 2014-01-15 14:44

@falconindy: Thank you for clarifying and updating the wiki article.

falconindy commented on 2014-01-14 21:00

The text you cite was added a mere 3 days ago by a user, not a developer or TU. The wiki should be fixed.

The counterexample is that hundreds of packages in the binary repos contain makedepends on packages in base.

jellysheep commented on 2014-01-14 20:45

cdown is right, I think. https://wiki.archlinux.org/index.php/PKGBUILD#makedepends says:
"The groups base and base-devel are assumed to be already installed when building with makepkg. Members of "base" and "base-devel" should not be included in makedepends arrays."
So perl should not be included in makedepends.

falconindy commented on 2014-01-06 20:19

> Does this really need bash-completion as a makedepends?
The Makefile says it is needed. If you dislike this, use cower-git until whenever I tag the next release.

> Also, "perl" is in base and therefore does not need to be in makedepends.
This is garbage. Dependencies in base-devel are assumed, not base. Everything else should be explicitly listed. Any other approach is wrong, sorry.

cdown commented on 2014-01-06 08:58

Also, "perl" is in base and therefore does not need to be in makedepends.

cdown commented on 2014-01-06 08:57

Does this really need bash-completion as a makedepends? If so, why? It's quite irritating to have to uninstall it after every upgrade.

thermionix commented on 2013-12-13 08:07

armv6h works for me

pentago commented on 2013-12-10 10:47

I'm having problems compiling cower inside KVM VPS.

I get this even though i installed 64bit OS:
==> Making package: cower 10-2 (Tue Dec 10 11:46:33 CET 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found cower-10.tar.gz
-> Found cower-10.tar.gz.sig
==> Validating source files with md5sums...
cower-10.tar.gz ... Passed
cower-10.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
cower-10.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.
==> Extracting sources...
-> Extracting cower-10.tar.gz with bsdtar
==> Starting build()...
make: Entering directory '/home/pentago/.build/cower/src/cower-10'
cc -std=c99 -g -pedantic -Wall -Wextra -pthread -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DCOWER_VERSION=\"10\" -D_FORTIFY_SOURCE=2 -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro cower.c -lcurl -lalpm -lyajl -larchive -lcrypto -o cower
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 10" README.pod cower.1
cower.c:1:0: error: CPU you selected does not support x86-64 instruction set
/* Copyright (c) 2010-2011 Dave Reisner
^
<builtin>: recipe for target 'cower' failed
make: *** [cower] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/home/pentago/.build/cower/src/cower-10'
==> ERROR: A failure occurred in build().
Aborting...

ewtoombs commented on 2013-10-31 04:28

Why is bash-completion a makedepend?

codyps commented on 2013-09-08 10:08

armv7h works for me.

kdb424 commented on 2013-07-10 12:20

armv7f and armv6h tested working. Please add in the pkg so I can update easier. I'll report any time when broken as I have several arm systems all running this.

SanskritFritz commented on 2013-06-06 05:02

@flaccid
https://wiki.archlinux.org/index.php/Pkgbuild#makedepends
"Warning: The group base-devel is assumed already installed when building with makepkg . Members of "base-devel" should not be included in makedepends arrays."

flaccid commented on 2013-06-06 04:38

I can confirm this builds using on arch linux arm (RPi) using:
arch=('i686' 'x86_64' 'armv6h')
makedepends=('perl' 'make' 'fakeroot' 'gcc')

flaccid commented on 2013-06-06 04:32

Also I think gcc is needed in makedepends as it uses cc.

flaccid commented on 2013-06-06 04:28

I think makedepends is missing make and fakeroot.

falconindy commented on 2013-05-14 18:17

Please collect your thoughts so that you can post *once* and not spam my inbox for every comment you decide isn't pretty enough and must be deleted.

No, I'm not really interested in supporting wrappers. There's minimal support for BYO handling with the -b flag.

ackalker commented on 2013-05-14 18:16

@falconindy
I'm using cower (and like it a lot!) in my own little AUR wrapper script, and I would like to be able to tell cower whether or not to output errors (like expac) when using a format string:

$ cower -i --format="%n-%v" thispackagedoesnotexist
error: no results found
$ cower -iq --format="%n-%v" thispackagedoesnotexist
error: no results found

$ expac -S "%n-%v" thispackagedoesnotexist
$ expac -Sv "%n-%v" thispackagedoesnotexist
error: package `thispackagedoesnotexist' not found

because sometimes I want to handle the error myself using the exit code.
For now, I have to resort to redirecting stderr to /dev/null.
Could you please look into this? Thanks in advance.

ackalker commented on 2013-05-14 18:16

@falconindy
I'm using cower (and like it a lot!) in my own little AUR wrapper script, and I would like to be able to tell cower whether or not to output errors (like expac) when using a format string:

$ cower -iq --format="%n-%v" thispackagedoesnotexist
error: no results found
$ cower -iqq --format="%n-%v" thispackagedoesnotexist
error: no results found

$ expac -S "%n-%v" thispackagedoesnotexist
$ expac -Sv "%n-%v" thispackagedoesnotexist
error: package `thispackagedoesnotexist' not found

because sometimes I want to handle the error myself using the exit code.
For now, I have to resort to redirecting stderr to /dev/null.
Could you please look into this? Thanks in advance.

ackalker commented on 2013-05-14 18:12

@falconindy
I'm using cower (and like it a lot!) in my own little AUR wrapper script, and I would like cower to be quiet (like expac) when using a format string, like:

$ cower -iq --format="%n-%v" thispackagedoesnotexist
error: no results found
$ cower -iqq --format="%n-%v" thispackagedoesnotexist
error: no results found

$ expac -S "%n-%v" thispackagedoesnotexist
$ expac -S "%n-%v" thispackagedoesnotexist

because I want to handle the error myself using the exit code.
For now, I have to resort to redirecting stderr to /dev/null.
Could you please look into this? Thanks in advance.

ackalker commented on 2013-05-14 18:01

I'm using cower 9-1

ackalker commented on 2013-05-14 18:00

@falconindy
I'm using cower (and like it a lot!) in my own little AUR wrapper script, and I've run into a little problem trying to get cower to be quiet:

$ cower -iq thispackagedoesnotexist
error: no results found
$ cower -iqq thispackagedoesnotexist
error: no results found

because I want to handle the error myself using the exit code.
For now, I have to resort to redirecting stderr to /dev/null.
Could you please look into this? Thanks in advance.

ThomasWinwood commented on 2013-05-13 13:18

I read the note on the wiki as a MAY NOT, not a SHOULD NOT. If it's intended to be more binding, then it should be worded to reflect that.

proudzhu commented on 2013-05-13 12:58

According to the wiki[1], as pacman depends on curl, curl should not be included in the depends array.

[1]: https://wiki.archlinux.org/index.php/PKGBUILD#depends

SanskritFritz commented on 2013-05-13 12:48

Agreed. If pacman stops depending on curl tomorrow, then what?

falconindy commented on 2013-05-13 12:45

And I vehemently disagree with the wiki. Dependencies should not be omitted because they're transitively fulfilled. cower links directly to curl, therefore it depends on curl and the PKGBUILD should reflect that.

proudzhu commented on 2013-05-13 12:10

According to the wiki[1], as pacman depends on curl, curl should not be included in the depends array.

[1]: https://wiki.archlinux.org/index.php/PKGBUILD#depends

demizer commented on 2013-05-13 06:27

I'm getting errors when I attempt to check for updates. It seems cower shits the bed when checking packages for a custom repository:

$ cower -u --debug
debug: found config option: Color => (null)
debug: initializing curl
debug: initializing alpm
debug: registering alpm db: testing
debug: registering alpm db: core
debug: registering alpm db: extra
debug: registering alpm db: community-testing
debug: registering alpm db: community
debug: registering alpm db: demz-repo-community
debug: registering alpm db: demz-repo-testing
debug: registering alpm db: infinality-bundle
error: no targets specified (use -h for help)
debug: releasing curl
debug: releasing alpm

Here is the repo:

[infinality-bundle]
SigLevel = Never
Server = http://bohoomil.cu.cc/infinality-bundle/$arch

Snowman commented on 2013-04-12 22:59

I'm getting timeout errors:
$ cower -u
error: [sagasu]: Timeout was reached
error: [flatzebra]: Timeout was reached
error: [adesklet-weatherforecast]: Timeout was reached
error: [burgerspace]: Timeout was reached
error: [cower]: Timeout was reached
error: [capchroot]: Timeout was reached
error: [python2-futures]: Timeout was reached

Snowman commented on 2013-04-12 09:30

license file is missing:
cower E: Missing custom license directory (usr/share/licenses/cower)

falconindy commented on 2013-04-07 20:29

Because you're using an old version of pacman.

Anonymous comment on 2013-04-07 20:25

When I try to build it I get this:

[denis@vaio-arch ~]$ cd /home/denis/Desktop/cower
[denis@vaio-arch cower]$ makepkg -s
==> Making package: cower 9-1 (Sun Apr 7 23:21:54 CEST 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving Sources...
-> Downloading cower-9.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 22294 100 22294 0 0 36603 0 --:--:-- --:--:-- --:--:-- 36607
-> Downloading cower-9.tar.gz.sig...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 287 100 287 0 0 750 0 --:--:-- --:--:-- --:--:-- 751
==> Validating source files with md5sums...
cower-9.tar.gz ... Passed
cower-9.tar.gz.sig ... FAILED
==> ERROR: One or more files did not pass the validity check!



WHY? :-(

chelqo commented on 2013-04-06 15:52

cower-9 does not compile with pacman-4.0.3
I think the PKGBUILD must be like that:
depends=('curl' 'yajl' 'pacman>=4.1')

bidulock commented on 2013-04-05 02:07

pacman 4.1 is [core] now

bidulock commented on 2013-04-05 02:07

maggie commented on 2013-04-01 19:45

@Falcon - April fools?

falconindy commented on 2013-04-01 19:42

No. I'd rather you simply avoid [testing].

maggie commented on 2013-04-01 19:37

Thank you spyhawk. I use [testing] on my laptop.
@FalconIndy: Please make this package require pacman<=4.0.3 to avoid this for others.

Spyhawk commented on 2013-04-01 19:33

maggie> That's because you are using pacman 4.1. Install cower-git instead.

maggie commented on 2013-04-01 19:28

I cannot build this pacakge.

% makepkg -s
==> Making package: cower 8-1 (Mon Apr 1 15:26:20 EDT 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found cower-8.tar.gz
-> Found cower-8.tar.gz.sig
==> Validating source files with md5sums...
cower-8.tar.gz ... Passed
cower-8.tar.gz.sig ... Passed
==> Verifying source file signatures with gpg...
cower-8.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.
==> Extracting sources...
-> Extracting cower-8.tar.gz with bsdtar
==> Starting build()...
make: Entering directory `/home/mags/cower/src/cower-8'
cc -std=c99 -g -pedantic -Wall -Wextra -pthread -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DCOWER_VERSION=\"8\" -D_FORTIFY_SOURCE=2 -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro cower.c -lcurl -lalpm -lyajl -larchive -lcrypto -o cower
pod2man --section=1 --center="Cower Manual" --name="COWER" --release="cower 8" README.pod cower.1
cower.c: In function ?alpm_init?:
cower.c:409:6: warning: implicit declaration of function ?alpm_db_register_sync? [-Wimplicit-function-declaration]
cower.c:429:2: warning: implicit declaration of function ?alpm_option_get_localdb? [-Wimplicit-function-declaration]
cower.c:429:11: warning: assignment makes pointer from integer without a cast [enabled by default]
cower.c: In function ?alpm_pkg_is_foreign?:
cower.c:460:2: warning: implicit declaration of function ?alpm_option_get_syncdbs? [-Wimplicit-function-declaration]
cower.c:460:8: warning: assignment makes pointer from integer without a cast [enabled by default]
cower.c: In function ?alpm_provides_pkg?:
cower.c:476:8: warning: assignment makes pointer from integer without a cast [enabled by default]
/tmp/ccnp2MnF.o: In function `alpm_provides_pkg':
/home/mags/cower/src/cower-8/cower.c:476: undefined reference to `alpm_option_get_syncdbs'
/tmp/ccnp2MnF.o: In function `alpm_init':
/home/mags/cower/src/cower-8/cower.c:409: undefined reference to `alpm_db_register_sync'
/home/mags/cower/src/cower-8/cower.c:429: undefined reference to `alpm_option_get_localdb'
/tmp/ccnp2MnF.o: In function `alpm_pkg_is_foreign':
/home/mags/cower/src/cower-8/cower.c:460: undefined reference to `alpm_option_get_syncdbs'
collect2: error: ld returned 1 exit status
make: *** [cower] Error 1
make: Leaving directory `/home/mags/cower/src/cower-8'
==> ERROR: A failure occurred in build().
Aborting...

tomxtobin commented on 2013-03-12 15:20

I get a warning when building this package:

==> Verifying source file signatures with gpg...
cower-8.tar.gz ... FAILED (unknown public key 1EB2638FF56C0C53)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.

Jesin commented on 2013-03-03 18:15

I hastily flagged this out-of-date and then realized I didn't know of any way to take it back. It turns out the package you have here is fine, I just needed to rebuild it against the new libarchive.

And then I realized this was just discussed in the comments a few hours ago. I'll check the comments before I press "flag out of date" button in the future, sorry about that. ^^;

Jesin commented on 2013-03-03 18:12

I hastily flagged this out-of-date and then realized I didn't know of any way to take it back. It turns out the package you have here is fine, I just needed to rebuild it against the new libarchive. Sorry! ^^;

kyak commented on 2013-03-03 18:03

@graysky thanks! sorry for noise :)

graysky commented on 2013-03-03 17:49

@kyak - https://github.com/falconindy/cower/issues/48#issuecomment-14347648

kyak commented on 2013-03-03 17:42

cower must be rebuilt against updated libarchive soname.

How about you bump the package version so it gets updated?

stativ commented on 2013-02-07 18:40

The integrity check fails for me.

Spyhawk commented on 2013-02-07 13:26

Proxy support is already implemented. See https://github.com/falconindy/cower/issues/33

SanskritFritz commented on 2013-02-07 12:28

How about a transparent proxy? That might work. Haven't tested myself though.

graysky commented on 2013-02-07 11:34

Dave - is it possible to use cower behind a proxy? Didn't see anything in the man page.

HalosGhost commented on 2013-02-05 00:45

Fair enough. I'll try to get it worked out. Thank you again for your work, and for your guidance.

falconindy commented on 2013-02-05 00:43

Yes, your PATH is fubar, just like so many other people who have commented on the same thing on this very same page.

HalosGhost commented on 2013-02-05 00:33

Oh wow, I completely missed that. Yet, I have perl installed (I did even when that first build failed), and the build continues to fail. Any thoughts on what's gone wrong?

HalosGhost commented on 2013-02-05 00:32

Oh wow, I completely missed that. Yet, I have perl installed (I did even when that first build failed), and the build continues to fail. Any thoughts on what's gone wrong?

falconindy commented on 2013-02-05 00:28

...but it is in makedepends.

HalosGhost commented on 2013-02-05 00:28

Ahh, I see. Is there a reason perl isn't in makedepends then? (not trying to be hostile, I just want to understand).

falconindy commented on 2013-02-05 00:13

I encourage you to scroll through the comments. pod2man is provided by perl.

HalosGhost commented on 2013-02-05 00:12

falconcindy, 8-1 fails to build for me. It would appear that it errors out during the build when attempting to run pod2man; returns command not found and the make exits with error code 127. Full make output is available here: http://ix.io/4hk

Thank you for your work!

falconindy commented on 2013-01-30 02:26

Because AUR helpers will never be anywhere else but the AUR. That's how it is.

graysky commented on 2013-01-29 23:44

Falconindy - Why in the world is cower not in [core]? It is every bit as useful as pkgfile IMO. Yes, I know the process by which packages in the AUR transition into [community]. [core]/pacman should reference in optdepends both pkgfile and cower by the way.

kyak commented on 2012-12-14 20:30

mandos, you should have a look at "pacaur" which does exactly this, but more elegant.

mandos commented on 2012-12-14 13:21

Thank you falconidy!!
This command is, I believe, a big help for people that have packages from AUR installed.

It is not the correct thing to do, you are right and I understand it now that I'm thinking it over.

Thanks again for the reply, it works like a charm

falconindy commented on 2012-12-14 12:07

for p in */; do ( cd "$p"; makepkg -sci); done

There is simply no way you will convince me that having cower call make pkg is the correct thing to do.

mandos commented on 2012-12-14 12:02

I have a question about package updating (which I would to be added to cower to if possible).

I use "cower -udd" inside an empty folder to get updates for my AUR packages.
Then I would love to be able to run "makepkg -sci" in all those folders at once.
I've come up to this command:
"find . -type d -maxdepth 1|grep -v ^.$|sed 's/^\.\///g'|while read line;do cd $line;makepkg -sci;cd ..;done"
but it doesn't really do the job write, it stops when trying to install the first compiled package.

Any ideas on this? Could something like an "auto-call to makepkg" be part of cower?
I know that what I'm trying to do isn't the most sane thing, because AUR packages should be checked. But lately I'm feeling quite comfortable with it so I would like to automate it.

falconindy commented on 2012-11-04 18:58

The NoSSL and --nossl options no longer exist since the AUR is no longer available on non-SSL.

artafinde commented on 2012-09-26 23:55

confirmed it's working on ARM. On Raspberry Pi works fine

falconindy commented on 2012-09-23 00:58

Not the same, but you're right. Because the Makefile uses redirection, cower.1 will be created regardless of whether or not pod2man to exists. Granted, a clean build directory should always be used, but this is easily fixed in the Makefile as well.

cfr42 commented on 2012-09-23 00:42

Please ignore this if it is the same as the April bug and will be fixed in due course.

If pod2man fails on the first run of makepkg because pod2man is not available, running makepkg a second time with pod2man available succeeds but fails to produce a usable man page. (man page is empty.) This scenario is definitely possible - I installed the resulting package just fine and then discovered the empty man page.

I think - but I'm not certain - that invoking makepkg a second time succeeds even if pod2man remains unavailable (but obviously this also results in an empty man page). I'm not quite sure about this scenario because I thought I'd got pod2man available but when it didn't work out thought maybe I was mistaken.

Note that the makedepends does not prevent this.

dauerbaustelle commented on 2012-08-03 19:54

Also works on arm, please add to architecture list

thestinger commented on 2012-05-08 13:38

@MystKid: pacman -Syu, and stop doing partial upgrades

Anonymous comment on 2012-05-08 13:24

make: Entering directory `/home/nico/Downloads/src/cower-5'
cc -o cower cower.o -lcurl -lalpm -lyajl -larchive -lcrypto -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libcurl.so: undefined reference to `SSL_CTX_set_srp_password'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libcurl.so: undefined reference to `SSL_CTX_set_srp_username'
collect2: ld returned 1 exit status
make: *** [cower] Errore 1
make: Leaving directory `/home/nico/Downloads/src/cower-5'

im unable to buil it

SanskritFritz commented on 2012-04-06 09:41

quantax, thanks. I tried your suggestion in the PKGBUILD like this:
build() {
cd "$pkgname-$pkgver"
touch README.pod #oops
sleep 1
touch cower.1
make
}
This way the README.pod remains empty, but that is ok, I have man cower.

quantax commented on 2012-04-06 09:20

About the manual page being empty:

After the tarball is extracted make considers cower.1 out
of date and tries to rebuild it. If README.pod is created
with touch in the PKGBUILD it is empty. Thus after pod2man
is run the manual page is empty too.

To solve this you also have to touch cower.1 after you have
touched README.pod. This will render the former file newer than
the latter and thus make will skip rebuilding the manual page
and happily continue building/installing.

SanskritFritz commented on 2012-04-03 12:32

Nah, no need then.
Just wanted to make sure it got your attention :)

falconindy commented on 2012-04-03 12:31

If you want to... my internet is flaky outside of work this week, but it'll be fixed soon enough.

SanskritFritz commented on 2012-04-03 12:23

Should I file a bug report on github?

falconindy commented on 2012-04-02 21:34

Nope, my fault. Tried to be clever and remove the pod2man makedep by shipping the doc pre-built, but it seems I've failed ;). I've actually got a branch locally that converts this project to autotools. While it's overkill, it scratches the itch.

SanskritFritz commented on 2012-04-02 21:25

Strangely with cower 4, after makepkg the README.pod and cower.1 files are empty in the src directory (tried more than once), meanwhile those files are OK in the cower-4.tar.gz file. bsdtar bug, or is something wrong here with my arch?

Spyhawk commented on 2012-01-12 15:57

@falconindy> Understood.

falconindy commented on 2012-01-12 15:47

I don't buy the idea that dependencies are always solved transitively. cower's dependency list (mostly) reflects the output of readelf -d /usr/bin/cower. If anything, I need to add libarchive as a dependency.

Spyhawk commented on 2012-01-12 15:39

@falconindy> Sorry if I didn't express myself correctly (English isn't my native language, and I just realized that my previous comment is ambiguous), but I was thinking about removing the "curl" dependency, not the "pacman 4" dependency. Since cower 3.0.9 is compatible with pacman 4 only, and that curl is provided by pacman 4 I guess it makes little sense to include a dependency of a dependency in the PKGBUILD. Or did I miss something else?

falconindy commented on 2012-01-10 22:21

Please read the comments on this page. You are not a special or unique snowflake.

Spyhawk commented on 2011-12-29 09:40

Pacman 4 depends on curl, so I guess it can be removed from the depends() array.

Spyhawk commented on 2011-12-13 23:16

ZekeSulastin> I didn't know about this tip, thanks! :]

ZekeSulastin commented on 2011-12-13 23:05

Or (as I learned after taking a beating from falconindy for overcomplicating things and avoiding him) modify the make line in the PKGBUILD as follows:

LDFLAGS+=' -lcrypto' make

Spyhawk commented on 2011-12-13 20:02

If cower-legacy doesn't compile, I guess you'll have to add something like "sed -i 's/-larchive/-larchive -lcrypto/g' Makefile" in the PKGBUILD.

ZekeSulastin commented on 2011-12-11 01:56

-lcrypto needs to be added to LDFLAGS for up-to-date systems

ZekeSulastin commented on 2011-12-11 01:43

On several up-to-date systems, cower-legacy fails to build with a /usr/bin/ld error. This can be fixed by adding -lcrypto to the LDFLAGS, but since there is no ./configure step the method I used to work around this was to write a quick patch to add it.

I also fixed the maintainer/contributor to comply with the Arch Package Guidlines; I left pkgrel at 1 because updating is not necessary if cower-legacy is currently installed and working.

New PKGBUILD: http://paste.pocoo.org/show/3F8o5Zf1zE8ACIYosydf/
The patch, named add-lcrypto.patch: http://paste.pocoo.org/show/lEB179sVboWhquLHVEQN/
A nice premade tarball that I tested - it works: http://dl.dropbox.com/u/48629685/cower-legacy-3.0.5-1.src.tar.gz

JokerBoy commented on 2011-11-13 10:47

Use cower-legacy with pacman 3.x!

bug commented on 2011-11-13 09:53

Fails to build.

mitch_feaster commented on 2011-11-10 16:36

Actual 3.0.5 checksum:

md5sums=('ec9abe3a458257d6389bff35722d32a9')

jdarnold commented on 2011-11-04 19:05

The 3.0.5 md5 checksum is b2489abfd52a6ca37bb96233ade25c3d FWIW

defcon commented on 2011-10-31 20:31

cannot build it.

https://bbs.archlinux.org/viewtopic.php?id=129434

gulafaran commented on 2011-10-28 01:52

updated , added provides=('cower')

SanskritFritz commented on 2011-10-27 13:34

This also
provides=cower

ZekeSulastin commented on 2011-10-27 13:16

Meh, it is what it is. Two things though:

1) falconindy mentioned setting pkgver to 3.05 and the checksum to b2489etc. - however, that's the current checksum :p I'm not on my Arch box to check what the actual checksum is, but I used makepkg -g >> PKGBUILD to add it, removing the original. It's not ideal, but it worked.

2) gulafaran uploaded a cower-legacy PKGBUILD to the AUR if changing a few lines in a bunch of PKGBUILDs is too much of a hassle, and I know at least pacaur points to it for the time being ...

Thanks for cower, falconindy - it does make life easier, even if [testing] screws everything up :p

Anonymous comment on 2011-10-25 03:05

I agree. I specifically use cower to automate the upgrading of aur packages, and it's very silly to have cower itself fail every single time. Plus a new user of cower will simply see the package build fail without knowing to dredge up an older version to match the current stable release of Arch.

How about cower-testing? Then the bleeding edge users can have a version that works for them without interfering with the common user. Users of testing should expect these sorts of extra steps anyways... stable users shouldn't.

louipc commented on 2011-10-25 02:48

cower is at version 3, thus considered stable (out of early development).

The accepted practice is to base releases on the established stable libraries,
thus pacman in [core], not [testing] (unless maybe the project is in early development).

That seems to be a source of much confusion.
A lot of people don't use testing, but they do use cower.

Is it too much to ask that the latest cower release builds against a verified [core] system?

I guess there's nothing stopping someone from uploading a 'cower-stable' package
to the AUR. That would be kind of redundant though when [testing] is moved to [core].

Sara commented on 2011-10-22 11:10

Why don't you put explicit dependence on pacman >= 4.0, to prevent broken builds of cower?

Anonymous comment on 2011-10-19 17:51

Not sure if this is just me or what. When I build cower the pkg folder ends up empty. It says it installs but executing "cower" just says
not found. I've checked /usr/bin/ and I don't see it. Other packages build fine.

falconindy commented on 2011-10-18 10:12

Since several people have asked... if you get build errors such as "unknown type name 'alpm_handle_t'" it's because you're not using pacman from testing -- change the pkgver to 3.0.5, update the checksum to b2489abfd52a6ca37bb96233ade25c3d and build.

Anonymous comment on 2011-10-15 07:20

@HokieTux You need to use pacman from [testing]

Anonymous comment on 2011-10-14 23:17

Just grabbed this and tried to build it with a fully updated system - compiling failed due to a whole bunch of unknown type errors:
http://pastebin.com/PHK7PMxn

falconindy commented on 2011-10-14 21:52

I'll state it one more time. This package has always, and will always, follow the latest release of pacman. If I do this, you have the option to update to something I've deemed to be a stable release. If i don't, you're forced to grab a possibly unstable build from git.

If you don't use testing, don't upgrade. It's that simple. Calm your OCD. Relax. Take a deep breath.

Anonymous comment on 2011-10-14 21:26

@falconindy : Would it be not better to avoid updating this package until pacman 4 is released ? I think people using [testing] should go for the -git package, and this one should be considered as "stable" (match [core]). Of course the choice is your in the end... Oh and, I won't miss the occasion to thank you again for your handy little tool !

trusktr commented on 2011-10-14 11:37

I was about to upgrade but then I saw your comment (falcon) thanks to yaourt, which shows recent comments. Waiting for a working build (pacaur is broken right now). By the way, some nice colored features like those yaourt has would be nice. Try "yaourt -Su --aur" and see how nice the colored output is. The comment previews are nice to have too. And the aur voting. pacaur is fast though. If we had all the nice interface of yaourt, but the speed of pacaur, that'd be super awesome.

falconindy commented on 2011-10-13 21:35

Pacman4 is barely in testing. However, this package always follows the latest stable. If you dont use testing then dont upgrade cower. Its that simple.

That said, this build is also broken. Ill update in a bit when i get home.

Foucault commented on 2011-10-13 20:37

Has pacman 4 made it to [core] ? Because 3.0.7 is compiled against alpm 7.0 judging from the compilation errors when building cower 3.0.7.

aidenn commented on 2011-05-04 00:15

Yay! Got it again. Sending mail.

aidenn commented on 2011-05-04 00:10

Hmm... can't reproduce it. Now it just works. I was in the middle of setting up my Arch when I compiled cower and it started segfaulting. It happened almost every time I used cower. Now I'm pretty much finished, rebooted after installing the new kernel, saw your reply, tried to do it again and nothing. I tried -dding a couple of random packages from AUR but after 10 tries with perfect behavior (complete with listing the dependencies) I gave up.

If it ever comes back I'll remember to catch it somehow. ;)

falconindy commented on 2011-05-03 23:51

@aidenn: Please email me (or open a github ticket) with an example of the output, preferrably with --debug enabled. There's no way I can troubleshoot this without more info.

aidenn commented on 2011-05-03 23:17

The latest version keeps segfaulting on exit for me, mostly during cower -dd multiple_packages_here. It does what it's supposed to do, downloads the PKGBUILDS, however it _does not_ list dependencies that are outside AUR. Clean Arch install, Eee PC 901, compiled with -march=native -O2 -pipe -fomit-frame-pointer. It worked a week ago just fine with the same setup.

Anonymous comment on 2011-04-27 15:27

It seems to be compiling now, thanks! I guess that it took a couple of days for my system to get up to speed.

Nice little program btw! I very much appreciate what you've done with it.

fabertawe commented on 2011-04-27 09:48

Firstly, thanks for Cower, it's great :)

Today I'm getting...
cower: error while loading shared libraries: libyajl.so.1: cannot open shared object file: No such file or directory

I have yajl-2.0.0-2 installed but checking the file list it doesn't provide libyajl.so.1 -
yajl /usr/lib/libyajl.so
yajl /usr/lib/libyajl.so.2
yajl /usr/lib/libyajl.so.2.0.0

Thanks.

falconindy commented on 2011-04-27 01:05

Yes, it does depend on yajl>=2.0. If you're following the only supported upgrade path in Arch, you'll have it.

Anonymous comment on 2011-04-27 01:02

Also, thanks for the cower. Its great!

Anonymous comment on 2011-04-27 01:01

Then, this depends on yajl>=2.0. Please add this dependence on the PKGBUILD.

falconindy commented on 2011-04-26 20:57

You need to be using yajl 2.0 from community.

Anonymous comment on 2011-04-26 20:56

Compilation currently fails for me with the following errors:

cower.c: In function ‘task_query’:
cower.c:1874:3: error: too few arguments to function ‘yajl_alloc’
/usr/include/yajl/yajl_parse.h:130:26: note: declared here
cower.c:1892:3: error: implicit declaration of function ‘yajl_complete_parse’ [-Werror=implicit-function-declaration]

msx commented on 2011-03-24 20:04

Much better ;) Tnx!

falconindy commented on 2011-03-24 10:01

@msx: Please update pacman.

msx commented on 2011-03-24 06:47

Hello falconindy, I have this error message while trying to compile:

==> Iniciando build()... (initianting/starting build)
cc -c -march=x86-64 -mtune=generic -O2 -pipe --std=c99 -g -pedantic -Wall -Wextra -Werror -DCOWER_VERSION=\"3.0.1\" cowe
cc1: warnings being treated as errors
cower.c: En la función ‘alpm_provides_pkg’: (tranlated: in function ‘alpm_provides_pkg’:)
cower.c:430:5: error: declaración implícita de la función ‘alpm_find_satisfier’ (trans.: implicit declaration in function ‘alpm_find_satisfier’)
cower.c: En la función ‘resolve_dependencies’: (trans.: in function ...)
cower.c:1567:28: error: la inicialización crea un puntero desde un entero sin una conversión (trans.: error: inicialization creates a pointer from an integer without a conversion)
make: *** [cower.o] Error 1

Tnx.

Anonymous comment on 2011-03-20 21:12

Only just discovered this! Thanks falconindy :)