gpg key not matching

[Pangercic Dejan (CR/RTC1.1-NA)]

Hi there, 

we are currently running an import_upstream job to import ROS packages from the official ROS distro. The script fails on not being able to find the matching gpg key: 

"""

Could not find any key matching 'E5944336'!

ERROR: Could not finish exporting 'trusty'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)
Changes will also get visible when something else changes the same file and
thus creates a new export of that file, but even changes to other parts of the
same distribution will not!
There have been errors!

"""

We created a new gpg pair (FD5DA7FD) on the repo machine and provided the public part in the /root/buildfarm_deployment_config/repo/common.yaml file on the master machine.

The job still finishes as green but we are not sure if that is all right. Also at the very end of the console output there is another error that pops up:

"""

Error 13 opening file /var/repos/ubuntu/main/dists/trusty/main/binary-amd64/Packages.new for writing: Permission denied
ERROR: Could not finish exporting 'trusty'!
Warning: database 'trusty|main|source' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
There have been errors!
"""

Any hint would be appreciated.

D.

[Tully Foote]

Did you update the gpg_key_id as well as the public and private keys in repo/common.yaml? I suspect that gpg_key_id is being used to create the template for the export, and if you changed the gpg key that example key_id is not in the keyring.

Tully

--
You received this message because you are subscribed to the Google Groups "ros-sig-buildfarm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildf...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-buildfarm/8412aac9-29a9-4b3c-aefe-16ef733e3e98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pangercic Dejan (CR/RTC1.1-NA)]

Hi Tully, 

if I run 

"gpg --list-keys" as build user on b3-repo (repo machine) I see this output:

"""

/home/build/.gnupg/pubring.gpg
------------------------------
pub   4096R/FD5DA7FD 2014-12-20
uid                  Bosch_Robotics

"""

The question - is this the right user?

We update the repo/common.yaml to contain this very same key. Now the question is, did we update it in the right repository? Our buildfarm_deployment_config is clone in /root/buildfarm_deployment_config on master machine - is this where import_upstream is reading the configuration from?

thx, D.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildfarm+unsubscribe@googlegroups.com.
To post to this group, send email to ros-sig-buildfarm@googlegroups.com.

[Daniel Di Marco]

Hi all,

to clarify: we are running the import-upstream jenkins job. The main problem seems to be that the 'E5944336' key is inserted in the /var/repos/ubuntu/main/conf/distributions file each time the job is re-run, even though we have replaced the key in the buildfarm_deployment_config repo. Could it be that this key id is hard-coded somewhere? We were grepping through the whole system without finding it in a config file.

Best,

Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildf...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.

[Tully Foote]

Hi Daniel and Dejan,

The distributions file is regenerated from this file:
root@ip-172-31-0-76:/home/jenkins-slave/.buildfarm# cat reprepro-updater.ini

 Where I think you've renamed the user to build so look at /home/build/.buildfarm/reprepro-updater.ini on your machine.

That should be coming from the reprepro_updater_config section: https://github.com/ros-infrastructure/buildfarm_deployment_config/blob/master/repo/common.yaml#L110

I would expect that file to be overwritten each time puppet reruns: https://github.com/ros-infrastructure/buildfarm_deployment/blob/master/repo/manifests/site.pp#L154

Did you change the gpg key since you started. And do you have the autoreconfigure enabled?

Tully

[Pangercic Dejan (CR/RTC1.1-NA)]

Hi Tully, 

it turns out we did not really change the user. We still have jenkins-slave on our master, slave and repo machines.

So what I now did is (on repo machine) deleted :/home/jenkins-slave/.buildfarm and reran ./reconfigure.bash repo but the /home/jenkins-slave/.buildfarm is empty after that???

Another issue that I've encountered is that puppet-concat 2.0.1 is not available anymore. In repo/Puppetfile.lock I now replaced it 1.2.3 (current version) instead.

However it seems that repo/Puppetfile.lock is autogenerated - where does the specification of puppet/concat then come from?

D.

[mathias...@ipa.fraunhofer.de]

Hi,

I have an update on the puppetlabs-concat issue:

puppetlabs-concat 2.0.x was deleted 6 days ago (https://groups.google.com/forum/#!topic/puppet-users/4_Sxrfl4uUY).

It is still listed on puppetforge, but marked as deleted. However, librarian-puppet does not handle this properly (https://github.com/rodjek/librarian-puppet/issues/310

).

For now this problem can be resolved by freezing puppetlabs-concat to version 1.2.3 in Puppetfile (e.g. https://github.com/ipa-mdl/buildfarm_deployment/blob/master/master/Puppetfile).

Best,

Mathias