Hi Mattia,
> So, is this commit challenging the idea of dpkg-buildpackage being
> optional
No. This change attempts to make no comment on whether dpkg-buildpackage
should be mandatory or optional. As you imply from the question, Lintian
would not be the place to push that. :)
It intends that dev
On Sun, Feb 18, 2018 at 03:49:13PM +, Chris Lamb wrote:
> Fixed in Git, pending upload:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d46ed44144b71558fc4288da13f276c38e4ec1ba
So, is this commit challenging the idea of dpkg-buildpackage being
optional?
If I read it co
tags 832099 + pending
thanks
Fixed in Git, pending upload:
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d46ed44144b71558fc4288da13f276c38e4ec1ba
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Mattia Rizzolo:
> though, using dpkg-buildpackage is not mandatory, a package should be
> able to build with just `debian/rules binary`. In such case SDE
> wouldn't be exported.
>
To be honest, I am largely considering dpkg-buildpackage being optional
(for mandatory targets) as a great misfeatur
Daniel Kahn Gillmor writes:
> On Fri 2016-07-22 17:31:15 -0400, Russ Allbery wrote:
>> I do think we should support reproducible builds for all packages, and
>> that our default build should be reproducible. I'm just not sure that
>> we should rule out allowing packages to be configured to use d
On Fri 2016-07-22 17:31:15 -0400, Russ Allbery wrote:
> I do think we should support reproducible builds for all packages, and
> that our default build should be reproducible. I'm just not sure that we
> should rule out allowing packages to be configured to use default upstream
> behavior for time
Mattia Rizzolo writes:
> On Fri, Jul 22, 2016 at 12:14:56PM -0700, Russ Allbery wrote:
>> I think that's fine in this case, since not setting that variable
>> doesn't break the build. It just means the build isn't reproducible,
>> which is an optional feature.
> 1/ it's an optional feature *for
On Fri, Jul 22, 2016 at 12:14:56PM -0700, Russ Allbery wrote:
> I think that's fine in this case, since not setting that variable doesn't
> break the build. It just means the build isn't reproducible, which is an
> optional feature.
1/ it's an optional feature *for now*. I'd really love to see i
Mattia Rizzolo writes:
> On Fri, Jul 22, 2016 at 11:55:46AM +0200, Chris Lamb wrote:
>> Attached is the following:
>>
>> commit 3b10f7dbaecedb0a458c25cc0b8615b489d424af
>> Author: Chris Lamb
>> Date: Fri Jul 22 10:54:02 2016 +0100
>>
>> c/rules: Check for unnecessary SOURCE_DATE
On Fri, Jul 22, 2016 at 11:55:46AM +0200, Chris Lamb wrote:
> Attached is the following:
>
> commit 3b10f7dbaecedb0a458c25cc0b8615b489d424af
> Author: Chris Lamb
> Date: Fri Jul 22 10:54:02 2016 +0100
>
> c/rules: Check for unnecessary SOURCE_DATE_EPOCH assignments
>
>
Source: lintian
Version: 2.5.45
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
Attached is the following:
commit 3b10f7dbaecedb0a458c25cc0b8615b489d424af
Author: Chris Lamb
Date: Fri Jul 22 10:54:02 2016 +0100
c/rules: Check for unn
11 matches
Mail list logo