Hi Mattia, On Sun, May 15, 2016 at 03:55:04PM +0000, Mattia Rizzolo wrote: > So, I was about to upload, but it failed to build: > > dh_auto_test -O--buildsystem=golang > cd obj-x86_64-linux-gnu > go test -v github.com/hlandau/acme/acmeapi > github.com/hlandau/acme/acmeapi/acmeendpoints > github.com/hlandau/acme/acmeapi/acmeutils > github.com/hlandau/acme/cmd/acmetool github.com/hlandau/acme/fdb > github.com/hlandau/acme/hooks github.com/hlandau/acme/interaction > github.com/hlandau/acme/redirector github.com/hlandau/acme/responder > github.com/hlandau/acme/solver github.com/hlandau/acme/storage > github.com/hlandau/acme/storageops … > === RUN TestOCSP > --- FAIL: TestOCSP (0.00s) > ocsp_test.go:80: ocsp error: Get > http://ocsp.staging-x1.letsencrypt.org//MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ55F6w46hhx/o6OXOHa+Yfe32YhgQU+3hPEvlgFYMsnxd/NBmzLjbqQYkCEwD69zi1DRRe9pEhERQvpXm9NBw=: > dial tcp: lookup ocsp.staging-x1.letsencrypt.org on [::1]:53: read udp > [::1]:39826->[::1]:53: read: connection refused
Thanks for catching this. I built the package in an sbuild chroot, which by default does not block network connections. The test is trying to contact the Let’s Encrypt staging server. The easiest solution is to disable the test for now, but in the long term it would be good to package boulder for Debian and use it for offline testing. How are you currently testing the other Let’s Encrypt clients? Would you be interested in packaging boulder together? > In the meantime I did 3 more trivial commits, that I pushed. > > (hope you don't mind the extra commits, but imho that's the main > advantage of keeping packages in a team, have the team mates being able > to do such sillyness! ;)) Yes, your commits are very welcome. Which repository did you push to? master is still at 771996d: https://anonscm.debian.org/cgit/letsencrypt/acmetool.git Regards, Peter
