Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transient gpg-keyserver problem fails build #8720

Closed
Anthchirp opened this issue Nov 7, 2017 · 6 comments
Closed

transient gpg-keyserver problem fails build #8720

Anthchirp opened this issue Nov 7, 2017 · 6 comments
Labels

Comments

@Anthchirp
Copy link

Using these directives in .travis.yml

sudo: false
language: python
addons:
  mariadb: '10.1'

the following happened:

Installing MariaDB version 10.1
mysql stop/waiting
Executing: /tmp/tmp.lKyedWTEmC/gpg.1.sh --recv-keys
--keyserver
hkp://keyserver.ubuntu.com:80
0xcbcb082a1bb943db
gpg: requesting key 1BB943DB from hkp server keyserver.ubuntu.com
gpgkeys: key CBCB082A1BB943DB can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
W: GPG error: http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY CBCB082A1BB943DB
W: The repository 'http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu trusty InRelease' is not signed.
W: There is no public key available for the following key IDs:
CBCB082A1BB943DB  
W: http://dl.hhvm.com/ubuntu/dists/trusty/InRelease: Signature by key 36AEF64D0207E7EEE352D4875A16E7281BE7A449 uses weak digest algorithm (SHA1)
W: http://ppa.launchpad.net/couchdb/stable/ubuntu/dists/trusty/Release.gpg: Signature by key 15866BAFD9BCC4F3C1E0DFC7D69548E1C17EAB57 uses weak digest algorithm (SHA1)
$ PACKAGES='mariadb-server mariadb-server-10.1'
$ if [[ $(lsb_release -cs) = 'precise' ]]; then PACKAGES="${PACKAGES} libmariadbclient-dev"; fi
4.53s$ sudo apt-get install -y -o Dpkg::Options::='--force-confnew' $PACKAGES
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  libterm-readkey-perl
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  galera-3 iproute libjemalloc1 libmariadbclient18 libmysqlclient18
  libsystemd-daemon0 mariadb-client-10.1 mariadb-client-core-10.1
  mariadb-common mariadb-server-core-10.1
Suggested packages:
  mailx mariadb-test tinyca
The following packages will be REMOVED:
  libmysqlclient-dev mysql-client-5.6 mysql-client-core-5.6 mysql-server-5.6
  mysql-server-core-5.6
The following NEW packages will be installed:
  galera-3 iproute libjemalloc1 libmariadbclient18 libsystemd-daemon0
  mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server
  mariadb-server-10.1 mariadb-server-core-10.1
The following packages will be upgraded:
  libmysqlclient18
1 upgraded, 11 newly installed, 5 to remove and 96 not upgraded.
Need to get 20.6 MB of archives.
After this operation, 10.8 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  mariadb-common galera-3 libmysqlclient18 libmariadbclient18
  mariadb-client-core-10.1 mariadb-client-10.1 mariadb-server-core-10.1
  mariadb-server-10.1 mariadb-server
E: There were unauthenticated packages and -y was used without --allow-unauthenticated

so MariaDB was not installed, and MySQL was started instead.

Since we run MariaDB specific stuff the build subsequently fell over.

Possible solutions (some may be more appropriate than others):

  • deal with keyserver problems by retrying
  • include the key in the container statically
  • fail the build early if the specified addon can't be installed
  • run apt for this addon with --allow-unauthenticated
  • allow me to run the addon apt in my repository with --allow-unauthenticated
  • allow me to modify the environment before the addons directive is parsed
@beniwohli
Copy link

I have a similar issue that seems to have the same root cause: connectivity issues with keyserver.ubuntu.com. This is triggered by using apt sources:

Adding APT Sources (BETA)
$ export DEBIAN_FRONTEND=noninteractive
0.18s$ curl -sSL "http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0x9ECBEC467F0CEB10" | sudo -E apt-key add -
gpg: no valid OpenPGP data found.
The command "curl -sSL "http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0x9ECBEC467F0CEB10" | sudo -E apt-key add -" failed and exited with 2 during .
Your build has been stopped.

Restarting the build usually solves the issue, but it's annoying as it happens quite often.

Instead of fetching the key on every build, would it make sense to bake that key into the images?

(Also, could it be a problem that this key is fetched via HTTP and not HTTPS?)

@Chaser324
Copy link

Chaser324 commented Nov 9, 2017

I just issued a pull request which failed testing for similar reasons - keyserver.ubuntu.com not responding. No clue which side of that retrieval isn't working.

Searching for similar errors - #380 and #381 were caused by the key server actually shutting down due to excess load, so it might be worth investigating the status of keyserver.ubuntu.com.

It could also be related to this current connectivity issue, although this isn't a OSX build: https://www.traviscistatus.com/incidents/rqf3s76q1rtw

gpg: requesting key D3D831EF from hkp server keyserver.ubuntu.com
gpgkeys: key 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

The command "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF" failed and exited with 2 during .

Your build has been stopped.

@stale
Copy link

stale bot commented Apr 13, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@MrStonedOne
Copy link

This is a prime example of why stale issue closing is cancer.

The bug still existed only it got hidden because nobody saw it for a while and nobody worked on fixing it.

@maxheld83
Copy link

just to chime in; this bug is still alive and kicking.
It's really annoying when Travis builds "fail" for these kinds of reason.

@rmcgirr83
Copy link

And happening again today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants