On Sun, Jul 16, 2006 at 04:47:12PM +1000, Anthony Towns wrote: > Hi all, > > At https://wiki.ubuntu.com/NoMoreSourcePackages is a description of > the new world order for Ubuntu packages -- which will simplify making > changes to Ubuntu packages to a matter of simply committing the change > to the source repository with bzr, and running a new command something > like "src publish edgy" to instruct the autobuilders to grab the source > from the bzr repository, create a traditional source package, and start > building it for all architectures. > > We've recently seen an example of someone using some general features of > the bug tracking system to mirror LaunchPad's features wrt tracking the > status on other BTSes [0] -- what I'm wondering is if we can't manage to > hack up a similar feature to that one for Debian with our current tools. > > The idea would be, I guess, to be able to setup pbuilder on a server > somewhere,
Why pbuilder? It's a great tool to check build-deps, and it's a great tool to casually build packages from time to time; but if you're really going to get rid of binaries in uploads, I think the more efficient way to do so would be to hack sbuild and buildd to do so. > have it watch for a build instruction -- and then automatically > check out the source, run a build with pbuilder, make the build log > available, and if the build was successful, make the .changes file, the > source and the binary packages available, so that they can be checked by > hand, and uploaded to the archive. > > For bonus points, have the server be able to automatically do the upload > by the maintainer downloading the changes, signing it, and sending the > signed changes file somewhere. [...] buildd already has all that. * wanna-build has lists of packages that need to be built, and buildd grabs packages out of those lists. The wanna-build database is currently fed by some scripts that are part of dak, but there's nothing preventing anyone from writing different scripts and/or modifying wanna-build slightly. * build logs are on buildd.d.o. * .changes files are part of the build log, and are clearly marked so they can be mechanically extracted by a sed one-liner (possibly a perl one-liner too, not sure about that bit). * uploads are done by sending signed .changes files to the buildd host (the exact mail address to be used depends on the exact buildd host in use, obviously). You would only need to create some scripts to populate the wanna-build database, plus modify sbuild so that it knows how to fetch a source package from a version control system rather than from a Debian mirror. The rest would probably work as is. All that being said, I'm not convinced doing sourceless uploads is actually a good idea. It's been proposed in the past, but I've never seen arguments that convinced me it would be a good idea. The difference with this idea is that you could set it up so that the original binary upload would be done out of your source repository, which would then do a sourceful upload to ftp-master which in turn would trigger builds on other architectures; that way, you wouldn't bother other architectures with untested builds. But we'll still have issues. For starters, we'd need a *lot* of hardware to be able to do all these builds. Many of them will fail, because there *will* be people who will neglect to test their builds, and they will hog the machine so that other people (who do test properly) have to wait a long time for their build to happen. Ubuntu has a lot more money behind them than Debian does, so they can mitigate this problem by simply buying more hardware. How do you suggest Debian would tackle this problem? -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
