test-rebuilds can't rebuild packages requiring udebs due to GPG setup

Bug #628414 reported by Loïc Minier
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

Hi

In a test-rebuild, debian-installer failed to build:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707/+build/1857116

 /usr/bin/fakeroot debian/rules binary-arch
dh_testdir
dh_testroot
dh_prep
dh_installdirs
debian/rules build-images
make[1]: Entering directory `/build/buildd/debian-installer-20100211ubuntu11'
/usr/bin/make -C build all_build stats release \
  USE_UDEBS_FROM=maverick BUILD_DATE=20100211ubuntu11 \
  USE_PROPOSED_UPDATES=0 \
  TRANSSTATUS=translation-status BOOTMENU_BEEP=y
make[2]: Entering directory `/build/buildd/debian-installer-20100211ubuntu11/build'
Using generated sources.list.udeb:
   deb copy:/build/buildd/debian-installer-20100211ubuntu11/build/ localudebs/
   deb http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu maverick main/debian-installer
   deb http://ftpmaster.internal/ubuntu maverick main/debian-installer
make[7]: `sources.list.udeb' is up to date.
Ign copy: localudebs/ Release.gpg
Ign copy: localudebs/ Release
Ign copy: localudebs/ Packages
Get:1 copy: localudebs/ Packages [20B]
Get:2 http://ppa.launchpad.net maverick Release.gpg [307B]
Get:3 http://ftpmaster.internal maverick Release.gpg [189B]
Get:4 http://ppa.launchpad.net maverick Release [57.3kB]
Get:5 http://ftpmaster.internal maverick Release [57.3kB]
Ign http://ppa.launchpad.net maverick Release
Get:6 http://ppa.launchpad.net maverick/main/debian-installer Packages [14B]
Get:7 http://ftpmaster.internal maverick/main/debian-installer Packages [54.7kB]
Fetched 170kB in 0s (417kB/s)
Reading package lists...
W: GPG error: http://ppa.launchpad.net maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1E9377A2BA9EF27F
Reading package lists...
Building dependency tree...
dh_testroot
get-packages udeb anna archdetect bogl-bterm-udeb busybox-udeb cdebconf-newt-detect-keys cdebconf-newt-terminal cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb choose-mirror choose-mirror-bin console-setup-fonts-udeb console-setup-pc-ekmap console-setup-udeb dhcp3-client-udeb di-utils di-utils-reboot di-utils-shell di-utils-terminfo download-installer env-preseed ethdetect gpgv-udeb hw-detect initrd-kickseed initrd-preseed installation-locale kbd-udeb kernel-image-2.6.32-204-dove-di kickseed-common libblkid1-udeb libdebconfclient0-udeb libdebian-installer4-udeb libfribidi0-udeb libiw30-udeb libnss-dns-udeb libtextwrap1-udeb libuuid1-udeb localechooser lowmemcheck lsb-release-udeb main-menu module-init-tools-udeb nano-udeb net-retriever netcfg network-preseed oem-config-check pciutils-udeb preseed-common rescue-check rootskel save-logs ubuntu-keyring-udeb udev-udeb udpkg util-linux-udeb zlib1g-udeb
make[8]: `sources.list.udeb' is up to date.
Ign copy: localudebs/ Release.gpg
Ign copy: localudebs/ Release
Ign copy: localudebs/ Packages
Get:1 http://ppa.launchpad.net maverick Release.gpg [307B]
Get:2 copy: localudebs/ Packages [20B]
Get:3 http://ppa.launchpad.net maverick Release [57.3kB]
Hit http://ftpmaster.internal maverick Release.gpg
Hit http://ftpmaster.internal maverick Release
Ign http://ppa.launchpad.net maverick Release
Hit http://ppa.launchpad.net maverick/main/debian-installer Packages
Hit http://ftpmaster.internal maverick/main/debian-installer Packages
Fetched 328B in 0s (1763B/s)
Reading package lists...
W: GPG error: http://ppa.launchpad.net maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1E9377A2BA9EF27F
Reading package lists...
Building dependency tree...
make[7]: *** [stamps/get_udebs-dove_netboot-stamp] Error 1
make[6]: *** [_build] Error 2

I suspect the test-rebuild archive's GPG key is missing from the chroot?

Thanks,

Revision history for this message
Julian Edwards (julian-edwards) wrote :

That should not affect things, it's only a warning. I don't know much about d-i but these lines:

make[7]: *** [stamps/get_udebs-dove_netboot-stamp] Error 1
make[6]: *** [_build] Error 2

look suspicious. What's it doing there?

Changed in soyuz:
status: New → Incomplete
Revision history for this message
Loïc Minier (lool) wrote :

debian-installer/build/Makefile has this target:

# Get all required udebs and put them in UDEBDIR.
$(STAMPS)get_udebs-$(targetstring)-stamp: sources.list.udeb
        dh_testroot
        @rm -f $@
        get-packages udeb $(UDEBS)
        @touch $@

this step fails, obviously at the get-packages step, get-packages is in debian-installer/build/util/get-packages.

This script defaults to ONLINE mode and only passes --allow-unauthenticated if there's a local udebs repo, of in offline mode.

So I think apt-get is failing with unauthenticated sources

Not sure how we can arrange to avoid this

Changed in soyuz:
status: Incomplete → New
Revision history for this message
Julian Edwards (julian-edwards) wrote :

Thanks for the explanation Loïc. I have no idea either :(

It looks like it's happening because you're depending on:
deb http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu maverick main
in the sources.list.

A couple of things come to mind:
1. Change the buildd code so that it downloads the keys for all relevant PPAs before starting.
2. You change your package to do it.

Both have heavy cons:
1. This will massively increase the load on the keyserver, which is already under tremendous strain (so I am told).
2. While this works for PPA packages, it's pretty nasty for rebuilds.

More ideas would be good here.

Changed in soyuz:
status: New → Triaged
importance: Undecided → Low
tags: added: derivation
Revision history for this message
Loïc Minier (lool) wrote :

The first thing I thought of was to create a new chroot file for each test-rebuild, which I think was a decent solution, but since you mention PPAs, I think it would make more sense to import all needed APT GPG keys from the keyserver to the librarian whenever archive setup changes, and pull the key bundle from librarian in the buildd code (aka use librarian as key cache).

Revision history for this message
Julian Edwards (julian-edwards) wrote :

That might be workable, although not quite that simple because you could change the dependencies to point at a PPA that doesn't have a key yet. For simplicity the first solution above is the best, and I'll pursue that one first as long as the keyserver admins agree that it's ok. Maybe we just do it for rebuilds initially, since most PPAs won't need it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.