Russ Allbery:
> Ximin Luo writes:
>
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar things. Well, lesson learnt, I will be more forceful
>> next time.
>
Bill Allombert writes:
> On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote:
>> Note that, for most developers, this is pretty much equivalent to the
>> current situation with FTBFS on, say, s390 architectures. Or even
>> issues with running under whichever init
On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote:
> Note that, for most developers, this is pretty much equivalent to the
> current situation with FTBFS on, say, s390 architectures. Or even issues
> with running under whichever init system is not the one the maintainer
> personally
Bill Allombert:
> On Tue, Aug 15, 2017 at 07:49:55PM +, Holger Levsen wrote:
>> Also what you are saying ("a package that is reproducible according to the
>> policy definition must not show up as non-reproducible in tracker/DDPO based
>> on results from the reproducible infrastructure") doesnt
On Wed, Aug 16, 2017 at 03:43:00PM +, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote:
> >> [..]
> >>
> >> Fair enough. I actually spotted that but thought it was better to get
> >> "something" into Policy rather than nitpick. I guess other people
On Wed, Aug 16, 2017 at 10:24:07AM +, Mattia Rizzolo wrote:
> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk wrote:
>
> > Tracker:
> > https://tracker.debian.org/pkg/hsqldb1.8.0
> > "Does not build reproducibly during testing"
>
> And indeed it's not reproducible according to
On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk wrote:
> Tracker:
> https://tracker.debian.org/pkg/hsqldb1.8.0
> "Does not build reproducibly during testing"
>
And indeed it's not reproducible according to policy: it's storing the
build user at the very least.
>
> Let's look at
Adrian Bunk writes:
> This is not about experimenting for raising the bar in the future.
> This is about the reproducible builds team not using policy as a stick
> for claiming a bar higher than what policy actually defines.
> Is it really allowed to claim that a package is
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Future policy versions might change this definition, but whatever latest
> > policy states has to be the definition used by both packages and the
> > reproducible builds team.
>
> >
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
>...
> This in absolutely no way constrains the reproducible build team from
> working on raising the bar in the future, just as the absence of this
> language from Policy did not prevent them from starting to work on this
> problem
Hello,
On Tue, Aug 15 2017, Russ Allbery wrote:
> Adrian Bunk writes:
>
>> Future policy versions might change this definition, but whatever
>> latest policy states has to be the definition used by both packages
>> and the reproducible builds team.
>
>> Another example is that
Adrian Bunk writes:
> Future policy versions might change this definition, but whatever latest
> policy states has to be the definition used by both packages and the
> reproducible builds team.
> Another example is that a package that is reproducible according to the
> policy
On Tue, Aug 15, 2017 at 09:05:29PM +0300, Adrian Bunk wrote:
> Is identical building on any kernel required (and tested)?
no and no.
it's only required that the results is reproducible, that is bit by bit
identical…
> Will every reproducible package in buster build identical on the
>
On Tue, Aug 15, 2017 at 10:09:30PM +0300, Adrian Bunk wrote:
> > > I would expect the reproducible builds team to not submit any bugs
> > > regarding varied environment variables as long as as the official
> > > definition of reproducibility in policy states that this is not required
> > > for a
On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > I would expect the reproducible builds team to not submit any bugs
> > regarding varied environment variables as long as as the official
> > definition of reproducibility in policy states
Adrian Bunk writes:
> I would expect the reproducible builds team to not submit any bugs
> regarding varied environment variables as long as as the official
> definition of reproducibility in policy states that this is not required
> for a package to be reproducible.
I believe
On Sat, 12 Aug 2017 15:34:35 -0700, Sean Whitton wrote:
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or
> build system
On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
> Here is an updated patch addressing these. I reworded it to use
> 'recommended' and changed the tone to better suit policy.
>
> Thank you Ximin, Russ and Johannes!
>
> > "precisification" -> "more precise version"
>
> Our
On Sat, Aug 12 2017, Ximin Luo wrote:
> Thanks! Seconded.
Just to be clear, we are waiting on one more second for the version
that refers to build and target architecture.
--
Sean Whitton
___
Reproducible-builds mailing list
Sean Whitton:
> [..]
>
> Here is an updated patch addressing these. I reworded it to use
> 'recommended' and changed the tone to better suit policy.
>
> Thank you Ximin, Russ and Johannes!
>
>> "precisification" -> "more precise version"
>
> Our definition is not actually a /version/ of the
>
On Sat, Aug 12, 2017 at 01:18:23PM -0700, Russ Allbery wrote:
> > +Packages are encouraged to produce bit-for-bit identical binary packages
> > even
> > +if most environment variables and build paths are varied. This is
> > technically
> > +more difficult at the time of writing, but it is
Ximin Luo writes:
> To echo dkg and others' comments, it would be nice if we could add here:
> +Packages are encouraged to produce bit-for-bit identical binary packages even
> +if most environment variables and build paths are varied. This is technically
> +more difficult
22 matches
Mail list logo