Some elements of this issue have changed in the last couple years, so
following up with a few updated points below...
On 2015-05-24, Stuart Prescott wrote:
>> > > I'd expect that setting DEB_BUILD_OPTIONS=nocheck on a package build
>> > > should not change the resulting binary packages. It might
Hi,
On Sonntag, 24. Mai 2015, Stuart Prescott wrote:
The check does not impose anything on package maintainers, like
migration blocking or similar. So even if there was a substantial
amount of packages that would fail that test, it would still be useful
information for the reproducible
Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: jenkins
I'd expect that setting DEB_BUILD_OPTIONS=nocheck on a package build
should not change the resulting binary packages. It might make the build
succeed despite being broken, but if it succeeds
Hi Helmut,
I'd expect that setting DEB_BUILD_OPTIONS=nocheck on a package build
should not change the resulting binary packages. It might make the build
succeed despite being broken, but if it succeeds without nocheck, it
should be no different when enabled.
Policy is, however, silent on
On Sun, May 24, 2015 at 11:42:31AM +1000, Stuart Prescott wrote:
Policy is, however, silent on whether that is the correct behaviour or not.
Clarifying policy as to what the correct behaviour should be seems to be a
necessary first step. I would expect that policy would end up saying
Hi!
On Sun, 2015-05-24 at 11:42:31 +1000, Stuart Prescott wrote:
I'd expect that setting DEB_BUILD_OPTIONS=nocheck on a package build
should not change the resulting binary packages. It might make the build
succeed despite being broken, but if it succeeds without nocheck, it
should be no
Hi Guillem,
I'd expect that setting DEB_BUILD_OPTIONS=nocheck on a package build
should not change the resulting binary packages. It might make the build
succeed despite being broken, but if it succeeds without nocheck, it
should be no different when enabled.
Policy is, however,
7 matches
Mail list logo
