I believe there is a control field for autopkgtest for this purpose.
gregor herrmann wrote:
> On Thu, 21 Jul 2016 11:19:46 +0200, Chris Lamb wrote:
>
> > > - by disabling them, even if they fail gracefully, in order to follow
> > > policy, we effectively castrate the tests, which doesn't seem
On Thu, 21 Jul 2016 11:19:46 +0200, Chris Lamb wrote:
> > - by disabling them, even if they fail gracefully, in order to follow
> > policy, we effectively castrate the tests, which doesn't seem right
> > from a QA POV.
> Mm, agreed. Moving these tests to the autopkgtest infrastructure is one
>
Thanks :)
> - by disabling them, even if they fail gracefully, in order to follow
> policy, we effectively castrate the tests, which doesn't seem right
> from a QA POV.
Mm, agreed. Moving these tests to the autopkgtest infrastructure is one
fix but it's not "that" clean a solution..
Regard
On Thu, 21 Jul 2016 10:33:35 +0200, Chris Lamb wrote:
> > PS1: I can't say that I'm 100% convinced by this policy change.
> This may not be the appropriate venue for a protracted discussion as
> it's liable to get hidden but can you briefly outline why?
My experience with perl packages shows that
> I won't defend this argument too much, but I'd be curious to know.
Same here. Alas I'm not a Policy "wonk" (and try to avoid being one as
it tends to devolve technical discussions into ones of intepretative
legal-like arguments that focus on the minutae of language rather than
on, well, what is
Le 21/07/2016 à 10:41, Chris Lamb a écrit :
> Oh, now /that's/ a very cute argument :)
I'm fine with fixing the package so I won't defend this argument too
much, but I'd be curious to know. Because if the compliance level
declared by the package doesn't matter, it would mean the
Standards-Version
Le 21/07/2016 à 10:24, gregor herrmann a écrit :
> In my understanding, this has changed in 3.9.7 (emphasis mine):
>
> * Policy: [4.9] debian/rules: required targets _must not attempt_ network
> [..]
> Closes: #770016
Interesting, thank you for the reference. libcommons-codec-java
currently
> Interesting, thank you for the reference. libcommons-codec-java
> currently declares a compliance to the version 3.9.6 of the policy. Does
> it mean the new rule doesn't apply to it yet? :)
Oh, now /that's/ a very cute argument :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `
On Thu, 21 Jul 2016 10:00:06 +0200, Emmanuel Bourg wrote:
> My understanding of the "no network access" rule was that the build must
> not require a network connection to complete, nor pull into the package
> external elements not found in the source tarball at build time. I guess
> the intent is
> PS1: I can't say that I'm 100% convinced by this policy change.
This may not be the appropriate venue for a protracted discussion as
it's liable to get hidden but can you briefly outline why?
> PS2: I'm surprised that it took so long after the release of policy
> 3.9.7 before someone start
> the javadoc tool merely checks the existence of the remote
> documentation to add href links in the generated files.
Mm. This also happens with Python's "Sphinx" documentation framework.
> This is optional and doesn't break the build if it doesn't work.
Builds may not even _attempt_ access IM
Le 21/07/2016 à 09:12, Chris Lamb a écrit :
> Whilst libcommons-codec-java builds successfully on unstable/amd64, according
> to
> Debian Policy 4.9 packages may not attempt network access during
> a build.
Hi Chris,
Thank you for reporting this issue. This happens because the Javadoc is
linked
Source: libcommons-codec-java
Version: 1.10-1
Severity: serious
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access
Dear Maintainer,
Whilst libcommons-codec-java builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access dur
13 matches
Mail list logo
