Comment 37 for bug 2039873

>What are your thoughts on (a) and (b)?

>being marked as superficial won't block a migration if it fails (IIRC: at least, it's definitely not a hard error). And we do want this to "stop the line" if it fails, right?

Ideally, it's better to block upload of package if this fails, yes. Because it's really bad to have LXC_DEVEL = 1 in the production release.

>b) it's checking something from the source code, which could be later changed via d/rules during build. What I mean is that this is not the place users will get the value of LXC_DEVEL from.

Yeah, ideally, yes. But I have just gone with the simplest possible solution to check this.

>A DEP8 test is awesome, thanks for that. But it might too close to a release for such a check. Imagine an SRU gets sponsored, then reviewed, then accepted, and then we get the DEP8 result that says "oops, LXC_DEVEL=1 is leaking again". How about also checking it during package build? I won't block the upload on this, though, but it would be good to have I think, even if later.

Ah, to be honest I was sure that this check will be performed before uploading this change to the Ubuntu package repositories. Can you give me a hint or send me to the manual about how to make this check during the package build?

>I won't block the upload on this, though, but it would be good to have I think, even if later.

Thanks for that. Yeah, I think that if everything seems generally fine to you to upload this as it is I can do this further improvements and modification in a later patches. As we anyways want (ideally) to rebase this on top of debian/sid.