[SOLVED] Cower fails to build

bstaletic · 2014-12-19 15:52:10

Heloo,

I've recently enabled [testing], and received pacman upgrade which installed libalpm.so.9, but cower was built against libalpm.so.8 on my system. First thought - rebuild cower. Unfortunately I received the following error:

bstaletic@arch cower % makepkg  
==> Making package: cower 12-1 (Fri Dec 19 16:43:28 CET 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found cower-12.tar.gz
  -> Found cower-12.tar.gz.sig
==> Validating source files with md5sums...
    cower-12.tar.gz ... Passed
    cower-12.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
    cower-12.tar.gz ... FAILED (the public key 487EACC08557AD082088DABA1EB2638FF56C0C53 is not trusted)
==> ERROR: One or more PGP signatures could not be verified!

How do I fix this? Is the key really not trusted or is there something wrong with my archbox?

My ~/.gnupg/gpg.conf looks like this:

# Options for GnuPG
# Copyright 1998-2003, 2010 Free Software Foundation, Inc.
# Copyright 1998-2003, 2010 Werner Koch
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you specify which option file to use (with the command line
# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf
# by default.
#
# An options file can contain any long options which are available in
# GnuPG. If the first non white space character of a line is a '#',
# this line is ignored.  Empty lines are also ignored.
#
# See the man page for a list of options.

# Uncomment the following option to get rid of the copyright notice

#no-greeting

# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.

#default-key 621CC013

# If you do not pass a recipient to gpg, it will ask for one.  Using
# this option you can encrypt to a default key.  Key validation will
# not be done in this case.  The second form uses the default key as
# default recipient.

#default-recipient some-user-id
#default-recipient-self

# By default GnuPG creates version 4 signatures for data files as
# specified by OpenPGP.  Some earlier (PGP 6, PGP 7) versions of PGP
# require the older version 3 signatures.  Setting this option forces
# GnuPG to create version 3 signatures.

#force-v3-sigs

# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you may want to use this option.

#no-escape-from-lines

# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification.  However for new
# installations it should be enabled.

require-cross-certification


# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set.  Please check the man page
# for supported character sets.  This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation.  Note that future version of GnuPG will change to UTF-8
# as default character set.

#charset utf-8

# Group names may be defined like this:
#   group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678".  Note there is only one level of expansion - you
# cannot make an group that points to another group.  Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients.  In these cases it is better to use the key ID.

#group mynames = paige 0x12345678 joe patti

# Some old Windows platforms require 8.3 filenames.  If your system
# can handle long filenames, uncomment this.

#no-mangle-dos-filenames

# Lock the file only once for the lifetime of a process.  If you do
# not define this, the lock will be obtained and released every time
# it is needed - normally this is not needed.

#lock-once

# GnuPG can send and receive keys to and from a keyserver.  These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyservers:
#      hkp://keys.gnupg.net
#
# Example LDAP keyservers:
#      ldap://pgp.surfnet.nl:11370
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
#      hkp://keyserver.example.net:22742
#
# If you have problems connecting to a HKP server through a buggy http
# proxy, you can use keyserver option broken-http-proxy (see below),
# but first you should make sure that you have read the man page
# regarding proxies (keyserver option honor-http-proxy)
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other.  Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin.  hkp://keys.gnupg.net is an example of
# such a "server", which spreads the load over a number of physical
# servers.  To see the IP address of the server actually used, you may use
# the "--keyserver-options debug".

keyserver hkp://keys.gnupg.net
#keyserver http://http-keys.gnupg.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net

# Common options for keyserver functions:
#
# include-disabled = when searching, include keys marked as "disabled"
#                    on the keyserver (not all keyservers support this).
#
# no-include-revoked = when searching, do not include keys marked as
#                      "revoked" on the keyserver.
#
# verbose = show more information as the keys are fetched.
#           Can be used more than once to increase the amount
#           of information shown.
#
# use-temp-files = use temporary files instead of a pipe to talk to the
#                  keyserver.  Some platforms (Win32 for one) always
#                  have this on.
#
# keep-temp-files = do not delete temporary files after using them
#                   (really only useful for debugging)
#
# honor-http-proxy = if the keyserver uses HTTP, honor the http_proxy
#                    environment variable
#
# broken-http-proxy = try to work around a buggy HTTP proxy
#
# auto-key-retrieve = automatically fetch keys as needed from the keyserver
#                     when verifying signatures or when importing keys that
#                     have been revoked by a revocation key that is not
#                     present on the keyring.
#
# no-include-attributes = do not include attribute IDs (aka "photo IDs")
#                         when sending keys to the keyserver.

#keyserver-options auto-key-retrieve

# Uncomment this line to display photo user IDs in key listings and
# when a signature from a key with a photo is verified.

#show-photos

# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input.  If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# The default program is "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"
# On Mac OS X and Windows, the default is to use your regular JPEG image
# viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
# photo-viewer "display -title 'KeyID 0x%k'"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"
keyring /etc/pacman.d/gnupg/pubring.gpg

EDIT:

I tried moving the directory and using the default, which produced the following error:

bstaletic@arch cower % makepkg                                                                                                                                        -- INSERT --
==> Making package: cower 12-1 (Fri Dec 19 17:47:35 CET 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found cower-12.tar.gz
  -> Found cower-12.tar.gz.sig
==> Validating source files with md5sums...
    cower-12.tar.gz ... Passed
    cower-12.tar.gz.sig ... Skipped
==> 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!

If I add the last line to gpg.conf, it shows the first error posted.

Last edited by bstaletic (2014-12-19 20:59:05)

thiagowfx · 2014-12-19 17:53:54

You should probably trust in the key. Try doing a

sudo pacman-key --lsign-key 1EB2638FF56C0C53

If any error message about the key not being found appears, you'll have to add it yourself. Maybe with

sudo pacman-key -r 1EB2638FF56C0C53

bstaletic · 2014-12-19 18:26:08

I've added the key, but the error about the public key 487EACC08557AD082088DABA1EB2638FF56C0C53 not being trusted remained.
I also tried locally singing the key above (487EA...) but the error remained.

Could have something happened that made the key go on to the untrusted list??

Last edited by bstaletic (2014-12-19 18:27:38)

karol · 2014-12-19 18:29:42

bstaletic wrote:

Could have something happened that made the key go on to the untrusted list??

https://www.archlinux.org/news/gnupg-21 … n-keyring/ ?

bstaletic · 2014-12-19 18:43:40

I've read the news and did what was asked of me, yet the problem is still there.

P.S. Just to be sure, I have just redone the procedure described in the news.

EDIT:
The maintainer of cower just updated the package and his signature and now everythin is working.

Last edited by bstaletic (2014-12-19 20:58:49)

SimbaClaws · 2015-01-26 21:27:16

bstaletic wrote:

I've read the news and did what was asked of me, yet the problem is still there.
P.S. Just to be sure, I have just redone the procedure described in the news.
EDIT:
The maintainer of cower just updated the package and his signature and now everythin is working.

As of today I'm having the same issue as you did. Did the maintainer change the gpg key back to the not working one?
I can't seem to get it added to my keyring for some reason.

EDIT: when I add the key 1EB26.. to my pacman-key it shows that nothing changed and the key seems to be fine.
But when I build the package it tells me that the key is an unknown public key.

Last edited by SimbaClaws (2015-01-26 21:50:30)

bstaletic · 2015-01-26 22:29:18

Nothing happened to the key pacman got updated, and with it the way it interacts with gnupg.

Arch Linux

#1 2014-12-19 15:52:10

[SOLVED] Cower fails to build

#2 2014-12-19 17:53:54

Re: [SOLVED] Cower fails to build

#3 2014-12-19 18:26:08

Re: [SOLVED] Cower fails to build

#4 2014-12-19 18:29:42

Re: [SOLVED] Cower fails to build

#5 2014-12-19 18:43:40

Re: [SOLVED] Cower fails to build

#6 2015-01-26 21:27:16

Re: [SOLVED] Cower fails to build

#7 2015-01-26 22:29:18

Re: [SOLVED] Cower fails to build

Board footer