Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 11:44:54AM +0200, Luk Claes wrote:Wouter Verhelst wrote:On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote:Not? Was the originally uploaded package correct? Amazing. Hm. Then, it should be lintian errors that denote a build as a failure, indeed, and these should somehow be detected by the mechanism that uploads the packages ... not by the buildd admin.It's impossible to catch every issue in an automated way. There are things that can be caught (such as, /maybe/, this), but you have to deal with the fact that some things will still slip through the cracks. I'm also not at all sure whether sbuild runs lintian during the build. Perhaps that would be good, though.AFAIK the FTP Team is working on a system to prevent uploads which have lintian errors. The whole category of lintian errors has already been assessed and possible overrides are planned to arrive in the NEW queue at least once... Please do note that I'm talking about errors, not about warnings.Right. However, having sbuild run lintian would allow a buildd maintainer to assess issues with packages by looking at *warnings*, rather than 'just' errors. This isn't something an automated system can do.
Right, though that's why we expect maintainers to look at them. Although there may be architecture specific lintian warnings, they should be really rare.
Besides, we want to get some support for autosigning packages built on the buildds. So we improve the speed of buildd uploads and we make the job of buildd maintainer more attractive to porters so they could really investigate (architecture specific) build errors instead of spending time in downloading, checking and signing successful build logs.
Cheers Luk