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


* Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> On Sun, 01 May 2011, Andreas Barth wrote:
> > However, to get that done right for multiple software is not so easy.
> > But please prove me wrong - as soon as 2. is done, I'm happy to help
> > setting up autobuilding (even if that happens this afternoon). It
> > needs however done in a way where buildds only pick up source packages
> > from one place, and upload to one place, independend whether the
> > source package is mozilla, ocaml, or something else.
> Another aspect is that the PPA in question must be activated in the buildd
> chroot so that build-dependencies can be solved in the PPA. Otherwise PPA
> can't be used to prepare important transitions.

Finding out how to specify dependencies was part of point 2, for a

> And you don't really want to mess up the build chroot, so it should really
> use one of the sbuild/schroot method that throw away all changes after a
> build.

That's obvious - same as experimental today. Don't worry about that

> How can we submit jobs to a buildd?

Have a list of packages with versions that need to be built. Or just a
list of source packges and binary packages and build anything missing,
like today for e.g. experimental. And have a common location where the
source packages are. That's basically. (One could specify additional
dependencies / conflicts that are not in the source package.)

> - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
>   build-dependencies not satisfiable in the target suite)

Why not just use one location - shouldn't be an issue unless you plan
to have the same packages and version numbers in multiple PPAs. And
that's something I recommend not to do.

> - requested architectures

All that are in the sources-file specified.

> - URL where the resulting files needs to be uploaded (if needed, otherwise
>   they could just be made available for a given amount of time)

One upload location per queue (or for multiple queues) - one could
always have a backend which changes things.

> For one-time builds, those job files could be signed by a DD key. For PPA,
> we might want some sort of indirection, i.e. a keyring where DD can add
> the key used by their PPA to submit buildd jobs.

Why not just upload packages, and build from there? As we do now?


Reply to: