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

Re: The wider implications of debhelper/dbus breakage

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

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.



Reply to: