Ticket #725 (closed defect: worksforme)

Opened 14 years ago

Last modified 10 years ago

do-build: package uploads and downloads should share a lock

Reported by: geofft Owned by: jdreed
Priority: normal Milestone: Current Semester
Component: documentation Keywords:
Cc: Fixed in version:
Upstream bug:


While building for Maverick we ran into a bunch of builds that failed for hash sum mismatches or unauthenticated-package errors while trying to download Debathena packages. Presumably this is because of a race condition between reprepro uploading packages and apt-get in the build chroots downloading them. We already have a global lock for all reprepro invocations within do-build; it would be nice to get apt-get inside the chroot to share this lock (although somewhat hard, since that's inside the chroot, and run by sbuild).

I'm also a bit confused here, because we use approx, which should 1) insulate us from this by caching and 2) not work, since we may need new packages as soon as they're uploaded.

Change History

comment:1 Changed 13 years ago by geofft

It looks like sbuild might already use /var/lib/sbuild/srcdep-lock inside the chroot when installing build-dependencies. Can we integrate that with do-build's upload lock?

comment:2 Changed 11 years ago by jdreed

  • Owner set to jdreed
  • Status changed from new to accepted
  • Milestone changed from The Distant Future to Current Semester

I haven't seen this with modern sbuild, but we also haven't run make -j in a while. I don't particularly feel like testing it now, but we should keep this in mind for achernya/vasilvv's new build thingy.

comment:3 Changed 10 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to worksforme

Closing this. I did not see it in Natty, Precise, Quantal, or Raring builds. We did see hash sum mismatches for upstream, and tracked it down to approx being dumb, and kicked approx's cache settings. approx-gc always fixed it. Modern sbuild now also installs everything in a single transaction. And Victor's build system does reasonable locking.

So if someone can consistently reproduce this, and track it down to something that's our fault, reopen it.

Note: See TracTickets for help on using tickets.