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 a écrit :
>> 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 lintian
> checks (lintian maintainers: can we?). So I suggest implementing the
> test in p
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
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 lintian
checks (lintian maintainers: can we?). So I suggest
Stefano Zacchiroli wrote:
> As such, we would like to add a lintian check to warn against OCaml
> custom mode executable. They can easily detected by looking for a magic
> number at the end of the file, as described in the forwarded mail from
> upstream.
Libraries can force custom mode executables
Package: lintian
Severity: wishlist
The OCaml compiler enables linking code in various ways: most notably
bytecode and nativecode. The bytecode executables though can be linked
together with the interpreter (the so called "custom mode"), generating
ELF executables which can not be stripped. Since
16 matches
Mail list logo
