I'm trying to build cairo with debuild.

I get to the end and this message:

gpg: skipped "Robert Ancell <robert.ancell@canonical.com>": secret key not available

Since I'm not Robert Ancell, this makes sense - how do I make it use my own key ?

gpg --list-key outputs:
$ gpg --list-key /home/stu/.gnupg/pubring.gpg
pub   1024R/2ADA7053 2009-05-04 uid                  Launchpad PPA for Aleksander Morgado

pub   2048R/17F35B46 2015-01-28 uid                  Stuart Axon
<stu.axon@gmail.com> uid                  Launchpad PPA for Stuart
Axon <stuaxo2@yahoo.com> sub   2048R/B8E8ED59 2015-01-28

and I have env var:

  • What debuild command did you use? Try adding the -us -uc flags. – Seth Feb 22 '16 at 21:30
  • It works fine with debuild -us -uc, but I think that is for an unsigned build ? I want to make my own PPA, which needs a signed build I think(?) - so I tried using a plain debuild – Stuart Axon Feb 22 '16 at 22:03
  • Yes, that would be unsigned. If you are trying to make a PPA then I assume you made changes to the source. If so, why did you not update the changelog? (debuild asks for the key belonging to the user of the last changelog entry) – Seth Feb 22 '16 at 22:05
  • Thanks - I didn't update as I didn't (don't) know what I'm doing. - I guess I should use dch -i to update the version + edit the changelog.. (?) – Stuart Axon Feb 22 '16 at 22:13
  • 2
    I would. Just say something simple like "rebuild with x flags to fix y". For versioning help take a look at the versioning section here: help.launchpad.net/Packaging/PPA/BuildingASourcePackage. Basically, since the cairo-dock version in the repos is 3.4.1-0ubuntu1, Yours should be 3.4.1-0ubuntu1ppa1. – Seth Feb 22 '16 at 22:30

debuild asks for the key of the user who last edited the changelog. If you are uploading to a PPA then your package must be different from its equivalent currently in the repositories and so you should have edited the changelog.

Use dch to update the version and changelog, then rebuild. debuild will ask for your key. (If you're not sure what version numbers to use take a look at the Launchpad help docs.)

  • Ticked, as this was my problem, upvoted the other one for detail - not sure how to give out points fairly in this weird gamified world. – Stuart Axon Feb 24 '16 at 15:48

Use the -k option to tell debuild which key to use, e.g.

debuild -kB57F5641

Note that there's no space allowed between the -k and the key ID.


I'm currently using XUbuntu 16.04 "Xenial Xerus" and was experiencing the same problem: both debuild and debsign were returning this secret key not available error, although I did create a local key and by the way I had uploaded it to the Ubuntu Keyserver, too.

I had already tried to manually set my key by using the -k option. I also set my key as my default key, and I also edited the debian/changelog file, among a LOT of other things, but nothing worked: I was still getting the same error.

...then I realized that I had created my key with gpg2 instead of gpg. Guess what I did?

  • First, I opened a shell terminal window and renamed the gpg binary:

    sudo mv /usr/bin/gpg /usr/bin/gpg.bak
  • Then I created a gpg symbolic link pointing to the gpg2 binary:

    sudo ln -s /usr/bin/gpg2 /usr/bin/gpg

After I did this, commands like debuild -S -sa, debsign some-file_source.changes et cetera finally worked.

I don't know what exactly is wrong with debuild, debsign, dpkg-buildpackage et cetera, but I'm under the impression that they're sending parameters to gpg although only gpg2 can parse ("understand") such parameters. Hence, making a symbolic link (in order to create a fake gpg binary that actually runs the gpg2 binary) solves the issue.

There are more elegant ways though to force debsign to use gpg2:

  • Set -pgpg2 option of debsign.
  • Set DEBSIGN_PROGRAM=gpg2 in /etc/devscripts.conf or ~/.devscripts.
  • This answer is ace... now - where do we make bug reports on this. I'm assuming, if instead of making a symlink, you change debuild and debsign to point at gpg2 instead of gpg this works ? - Then were some way towards a patch ... – Stuart Axon Sep 8 '16 at 21:29
  • @StuartAxon debuild and debsign are part of the devscripts package, while dpkg-buildpackage is part of the dpkg-dev package. In Ubuntu distros, both devscripts and dpkg-dev are mantained by Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>, thus a good way to report bug on these packages is to run apport: apport-bug devscripts will help you create a bug report for devscripts on Launchpad, and apport-bug dpkg-dev will do the same for dpkg-dev on Launchpad. – Yuri Sucupira Sep 10 '16 at 1:42
  • Thank you so much! I spent a day trying to sort out exactly the same problem, but came only across answers suggesting to generate a new key. I with the world migrated to gpg2 and finally graved gpg. – Alexander Solovets Mar 21 '17 at 23:40
  • @AlexanderSolovets You're welcome. :) And thank you for your suggested edit. :) – Yuri Sucupira Mar 21 '17 at 23:55

Firstly, with every package revision, you have to edit the changelog. This is a requirement if you make changes to the package; you can add such changelogs with dch, as Seth suggests.

However, if you are simply trying to produce a package that has no additional changes, so you can just install the package, then you don't need to edit the changelog, you simply need to resolve the signing key issue.

I don't believe either of the answers here is 100% complete. Therefore, I will steal slightly from both, but add my own suggestion and solution here, as I do this with the nginx package merges quite often.

To quote Seth, debuild will determine the key based on what the last changelog editor was. This is automatic, and you will need to update the changelog to use your credentials in them at the end of the latest changelog entry.

As was stated by Florian, though, you can also use the -kKEYIDNUM option to debuild tell it which key to sign with, and enforce the use of that key.

And now, my solution to both issues, to make things automatically sign with the key I want to sign with...

For the longest time I ran into this issue whenever my old hard drives died on my previous system. I did not want to edit the changelog each time, really, nor did I really want to manually pass the -k option each time to debuild.

Finally, MOTUs helped me solve the problem by explicitly specifying what key to sign with, by introducing me to .devscripts, which debuild and others call upon environment variables with things defined in them; this permitted me to add options that dpkg-buildpackage, which debuild calls, will always append.

So, to make the -k option work automatically for every single debuild you run, you can add this to you ~/.devscripts file, and automatically add the -k option, like so:


This will make it persistently added to the debuild options; this is also a way to enforce that your key will always be used for signing.

This helps me for both Ubuntu uploads, but also for PPA uploads.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.