This is a reply to a message from last May that I'd set aside at the time
because I wanted to think about it, and then it got buried in my to-do
list for all this time. Sorry about that. I've been thinking about it
off and on since then, at least.
Stefano Zacchiroli writes:
> This tension is c
On Thu, May 14, 2009 at 11:01:53PM +1100, Romain Beauxis wrote:
> > urrrmmm, not really. The point here is also the extra need of
> > some language-specific tool which do not appear as lintian
> > dependency. So, even if I've a sympathy for your proposal,
> > reproducibility will not be ensure
Le Thursday 14 May 2009 22:44:24 Stefano Zacchiroli, vous avez écrit :
> > Just to add my 2 cents: If the policy is one package + one lintian
> > version = deterministic checks, then why not adding a flag in the
> > package's control file that specifies which additional set of tests
> > should be r
On Thu, May 14, 2009 at 10:12:56PM +1100, Romain Beauxis wrote:
> Le Thursday 14 May 2009 06:47:48 Sylvain Le Gall, vous avez écrit :
> > This kind of "external plugin" architecture can be a very good way for
> > packaging team to enhance their policy and their QA.
>
> Just to add my 2 cents: If t
Le Thursday 14 May 2009 06:47:48 Sylvain Le Gall, vous avez écrit :
> This kind of "external plugin" architecture can be a very good way for
> packaging team to enhance their policy and their QA.
Just to add my 2 cents: If the policy is one package + one lintian version =
deterministic checks, th
Le Thursday 14 May 2009 06:47:48 Sylvain Le Gall, vous avez écrit :
> This kind of "external plugin" architecture can be a very good way for
> packaging team to enhance their policy and their QA.
Just to add my 2 cents: If the policy is one package + one lintian version =
deterministic checks, th
On 13-05-2009, Stefano Zacchiroli wrote:
> On Tue, May 12, 2009 at 11:08:37AM -0700, Russ Allbery wrote:
>
> However I see a difference on scope. We, Debian OCaml Maintainers,
> want a tool to run our own tests, use it for our own team-specific QA,
> and give it to our packagers as a tool to run p
On Tue, May 12, 2009 at 05:46:18PM +0100, Adam D. Barratt wrote:
> I'm not Russ, obviously, but fwiw with my Lintian co-maintainer hat
> on...
Thanks to both Adam and Russ for the clear answers.
> My initial thought is that doing so would break reproducibility of
> Lintian results. Maintaining th
Stefano Zacchiroli writes:
> That, to me, looks like *a* possible way of implementing that. Before
> going forward however, I'd like to have Lintian's maintainer approval
> on the strategy. What we are proposing is a conditional lintian check,
> to be implemented in Perl as usual, but relying on
Zack wrote:
[ replying to Russ' post, which contains the interesting part to
support Stephane's reply ]
I'm not Russ, obviously, but fwiw with my Lintian co-maintainer hat on...
In this particular case it will be /usr/bin/ocamlobjinfo. The lintian
test will do nothing, silently, if the exec
[ replying to Russ' post, which contains the interesting part to
support Stephane's reply ]
On Sun, Sep 07, 2008 at 10:02:27AM -0700, Russ Allbery wrote:
> > ... but I doubt that we can rely on external packages from lintian
> > checks (lintian maintainers: can we?). So I suggest implementing th
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Sun, Sep 07, 2008 at 04:51:07PM +0200, Stéphane Glondu wrote:
>> This check is quite easy using the ocamlobjinfo tool: it prints "Force
>> custom: YES" when given a faulty .cma.
> ... but I doubt that we can rely on external packages from lintia
12 matches
Mail list logo