On Sun, Jan 01, 2017 at 05:40:44PM +0100, Guillem Jover wrote:
> The only correct "solution" I see while keeping the current mess, would
> be to declare binNMU versions a globally shared resource across all
> architectures (in and out of archive!), trigger them globally for all
> architectures (or
[ Had this half-drafted, but had not found the time to finish it up
until now. ]
Hi!
On Mon, 2016-11-14 at 13:52:18 +, Ian Jackson wrote:
> Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
> misleading timestamps in binnmus"):
> > Instead, f
On Thu, Dec 01, 2016 at 04:51:39PM +0100, Johannes Schauer wrote:
> Hi,
>
> Quoting Wouter Verhelst (2016-12-01 16:24:16)
> > On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > > But maybe to talk about this option: what would speak against changing the
> > > "nmu" command of wa
Hi,
Quoting Wouter Verhelst (2016-12-01 16:24:16)
> On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > But maybe to talk about this option: what would speak against changing the
> > "nmu" command of wanna-build to also add an option that allows setting a
> > timestamp, or even l
Hi,
(Sorry for piping in so late to the party here)
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> But maybe to talk about this option: what would speak against changing the
> "nmu" command of wanna-build to also add an option that allows setting a
> timestamp, or even let wa
Ian Jackson wrote:
[...]
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve looking
> in the archive to see what the previous binnmu timestamp was.
[...]
The reference point would be the last source change accor
Hi,
thanks for having this discussion!
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-11-14 17:33:55)
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
>
> I found Guillem's suggestion the most s
Hi,
Quoting Ian Jackson (2016-11-14 17:33:55)
> Unless the timestamp is of the binnmu request, plumbing to try to get
> the same timestamp will be difficult.
>
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> I want to understand why passing the same timestamp to all
> architectures is an inferior solution to your proposal.
This is a sensible question. Thanks for helpin
Hi,
Quoting Ian Jackson (2016-11-14 14:52:18)
>I don't think it is possible to make the binnmu timestamp the same
>across architectures. For example, a package might be rebuilt only
>on some architectures. I don't think we want to change that. In
>particular, even if we were pre
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> Instead, file conflicts might be created from files with
> content that depends on SOURCE_DATE_EPOCH.
tl;dr:
Analysis. Revised proposal:
Introduce BUILD_DATE_
Hi,
Quoting Ximin Luo (2016-11-10 18:13:00)
> Holger Levsen wrote:
> > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> > > binNMU to a package.
> > >
> > > Any other ideas?
> > set SOURCE_DATE_EPOC
12 matches
Mail list logo
