Bill,
> > > Now compare with reproducible build. You get some error report you
> > > cannot reproduce, do some change following the help provided and
> > > hope for the best. Then some day later you get the same error
> > > report.
> >
> > I'd dearly love to know when/where this occurred if you c
On Wed, Aug 16, 2017 at 05:40:23PM -0700, Chris Lamb wrote:
> Hi Bill,
>
> > Now compare with reproducible build. You get some error report you
> > cannot reproduce, do some change following the help provided and
> > hope for the best. Then some day later you get the same error
> > report.
>
> I'
Hi Bill,
> Now compare with reproducible build. You get some error report you
> cannot reproduce, do some change following the help provided and
> hope for the best. Then some day later you get the same error
> report.
I'd dearly love to know when/where this occurred if you can provide a
referenc
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.
>
>> The sentence I amende
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 system is not the one t
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 use
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.
> The sentence I amended said "most environment
Bill Allombert writes:
> I am still concerned that there will be no reliable way for maintainers
> to check whether a package is reproducible according to policy before
> uploading it to the archive.
Ximin answered this, but I also wanted to note that while having such a
tool would be ideal, we
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
Adrian Bunk:
> 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 gue
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
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 were
>> thinking similar things. Well, lesson learnt, I will be more f
On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote:
> Adrian Bunk:
> > 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 reproduci
Adrian Bunk:
> 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 p
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 policy: it's stori
Bill Allombert:
> 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.
>>
>>> Anoth
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 the mdds package, th
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 not reproducible,
>
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.
>
> > Another example is that
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 really makes sense:
>
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 four
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 a package that is
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 definition must no
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
> bullseye+
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 pa
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 that this is not re
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 the planned next s
On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
>...
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of version
On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
>...
> - for now, we only require reproducibility when the set of environment
> variable values set is exactly the same
>
> This is because
>
> - the reproducible builds team aren't yet totally clear on the
> variables that t
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 definitio
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
Reproducible-builds@lists
On Sunday, 13 August 2017 06:23:15 AEST Mattia Rizzolo wrote:
> On Sun, 13 Aug 2017, 6:15 a.m. Stuart Prescott, wrote:
> > Policy is not a stick but policy can document where we want to be,
> > particularly when we are talking about standard practice. It is already
> > standard practice that packa
On Sun, 13 Aug 2017, 6:15 a.m. Stuart Prescott, wrote:
> Policy is not a stick but policy can document where we want to be,
> particularly when we are talking about standard practice. It is already
> standard practice that packages build reproducibly with things like build-
> path variation -- we
Hi,
I have a some of misgivings about this "reproducibility light" definition in
policy.
- it's not where we actually want to be, meaning that we will want to
ratchet up that definition over time to allow more variation (environment,
cwd etc). That means we already consider packages to be bugg
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
>
Hello,
On Sat, Aug 12 2017, Russ Allbery wrote:
> I suspect we want to say build and host architecture for right now.
> (Maybe we can later aspire to making the build architecture not
> matter.)
On Sat, Aug 12 2017, Ximin Luo wrote:
> To echo dkg and others' comments, it would be nice if we cou
Johannes Schauer writes:
> Policy §4.9 defines "build architecture" in the context of
> dpkg-architecture already and I think what you mean here is either "host
> architecture" or at least "build and host architecture" or you need to
> mention that you are only talking about native builds where b
Hi,
Quoting Sean Whitton (2017-08-13 03:23:14)
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed buil
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 intende
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 at the time of writing,
Sean Whitton:
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or
> build system (for
> example, a package that builds the s
Sean Whitton writes:
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or
> build system (for
> example, a package that bui
Hi,
2017-08-12 14:23 GMT-04:00 Sean Whitton :
> control: tag -1 +patch
>
> This patch incorporates the feedback given on the proposal I sent
> yesterday, both in this bug and in person from Russ and Holger (thank
> you to all).
>
seconded, thanks for working on this.
--
Best regards
Ondřej No
On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
> I am seeking formal seconds for this patch, from any DD.
>
> In particular:
>
> - for now, we only require reproducibility when the set of environment
> variable values set is exactly the same
>
> This is because
>
> - the re
control: tag -1 +patch
This patch incorporates the feedback given on the proposal I sent
yesterday, both in this bug and in person from Russ and Holger (thank
you to all).
I am seeking formal seconds for this patch, from any DD.
In particular:
- for now, we only require reproducibility when the
46 matches
Mail list logo
