[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: buildd and experimental

On Mon, Feb 27, 2006 at 10:59:01PM -0800, Thomas Bushnell BSG wrote:
> I recently uploaded gnucash 1.9.1 to Debian experimental, but this
> doesn't seem to have affected buildd.debian.org.  Is this normal?

That question has already been adequately answered by other people in
this thread.

However, for clarity, I'll add that the experimental buildd network
behaves slightly different from the unstable buildd network, and this
may require some work from your end:

* First, there is no guarantee that the experimental buildd network will
  build your package. We do a best effort to successfully build as many
  packages as possible, but it is not possible to guarantee that every
  package will be built on all architectures for experimental. This is
  partially because of the other points, but also because some
  architectures simply do not have enough buildd power for experimental;
  m68k, for example, currently builds experimental with only one buildd
  host (quickstep.nixsys.be), a 25Mhz 68040, and cannot keep up (I do
  plan to add jazz.nixsys.be when I have the time; but that's not going
  to happen very soon, I'm afraid). This is not considered to be a
  problem, as experimental is not as important as unstable.
* If you need packages from experimental to build, you must specify your
  build-dependencies on those packages in more detail. For example, if
  there is a foo_0.1_all.deb in unstable, and a foo_0.2_all.deb in
  experimental; a bar_0.1_all.deb in unstable, and a bar_0.2_all.deb in
  experimental; your package requires the use of bar, and you want to
  build against packages in experimental; and bar depends on foo (with
  the bar version in experimental having a versioned depends on the foo
  version in experimental); then you need have a versioned build-depend
  on not only bar, but also foo for the buildd build to succeed. This is
  because apt cannot be set up to take packages from unstable by default
  but to take them from experimental if that is the only way to resolve
  a dependency that occurs in a case of something like "apt-get install
* The above currently isn't even true for many of the architectures; to
  my knowledge, only m68k and one other architecture that I can't
  remember off the top of my head currently behaves like that. Other
  architectures will simply fail to build a package that has versioned
  build-dependencies which can only be resolved with packages from
  This, however, is a bug, and AAUI one that is in the process of being

Note that this is all about the experimental buildd network, i.e., those
machines that actually build packages from experimental. That is not the
same thing as "machines that send their logs to experimental.ftbfs.de",
which includes machines who build for unstable only and (should) behave
like "regular" buildd machines.

Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4

Attachment: signature.asc
Description: Digital signature

Reply to: