Bug#844431: Packages should be reproducible

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Packages should be reproducible

Chris Lamb-8
Package: debian-policy
Version: 3.9.8.0
X-Debbugs-Cc: [hidden email]

Dear Policy maintainers,

Whilst anyone can inspect the source code in Debian for malicious
flaws, we distribute pre-compiled to end users. The motivation behind
the Reproducible Builds effort is to permit verification that no flaws
have been introduced — either maliciously or accidentally — during this
compilation process by promising identical results are always generated
from a given source, thus allowing multiple third-parties to come to a
consensus on whether a build was compromised.

Debian has been making great strides to make itself reproducible,
contributing 100s patches, not only within Debian itself but also to
upstream projects. We have also been running a comprehensive and non-
trivial CI framework to test for reproducibility of packages for quite
some time.

However, the recent arrival of the final pieces of the toolchain into
unstable encourages me to propose that we add a recommendation that
packages in Debian should be reproducible.

This would be act both as documentation of a modern best practice, but
also act as a "placeholder" so that we can increase its severity at some
future date.

[As a mild suggestion to streamline this; we should probably come to some
consensus on principle of this addition to Policy first and only then
move to the more difficult topic of defining exactly what reproducibility
means in a technical sense.]


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Packages should be reproducible

Henrique de Moraes Holschuh
On Tue, 15 Nov 2016, Chris Lamb wrote:
> [As a mild suggestion to streamline this; we should probably come to some
> consensus on principle of this addition to Policy first and only then
> move to the more difficult topic of defining exactly what reproducibility
> means in a technical sense.]

I don't think there will be much of a contention about this.

Please propose wording (i.e. the diff to the policy text), but I
recommend that you do *not* use "should" or "must" to make such
reproducibility mandatory right now, only to define stuff like "*if* it
is built for reproducibility, it must do so in such a way that...", etc.

Enforcing package reproducibility (should/must in policy) has to wait
until a majority of the package is effectively being reproducibly built
for a small while (to shaken up any issues), and the tooling echosystem
is complete so that it is actually usable to verify things.  IMHO, this
would be best done only after stretch is released, even if we reach >85%
reproducibility levels *and* a full, working toolset before that.

As a suggestion, since a "may build reproducibly" policy is not going to
give the readers the desired idea, the policy text proposal could use
words to the effect that "it is recommended that", and "in the future,
this will become a requirement".

Any packages that absolutely cannot be built in a reproducible way[1],
can become oficially allowed exceptions -- and we could likely teach the
verification tools that specific regions of a package/file are to be
random, and ignore those when comparing for reproducibility, too.  But
this would be tackled on in the future, between an already implemented
policy of SHOULD is out, and >95% of the packages are being built
reproducibly and policy is about to be changed to MUST.  Therefore, the
initial proposal just needs to acknowledge that this fact could happen
and will be dealt with in time.

[1] Such as random noise added to kernel and firmware data structures
during local builds, to be used as a last defense to avoid the *herd
using same keys* effects, etc.

--
  Henrique Holschuh

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Packages should be reproducible

Chris Lamb-8
Henrique de Moraes Holschuh wrote:

> I don't think there will be much of a contention about this.

Great :)

> Please propose wording (i.e. the diff to the policy text), but
> I recommend that you do *not* use "should" or "must" to make such
> reproducibility mandatory right now.

Completely agreed. Any requirement would be counter-productive and
ultimately premature at this stage.

I've attached an initial wording to get us going. I'm not 100% convinced
with it myself but it should help start any discussion in this area.


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

debian-policy.diff.txt (766 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Packages should be reproducible

Daniel Shahaf
Chris Lamb wrote on Thu, Nov 17, 2016 at 12:30:44 +0100:
> +++ b/policy.sgml
> @@ -2503,6 +2503,20 @@ endif
> +      <sect id="readmesource">

Note that the id should be changed before applying, since there already
is a sect with this id value.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Sean Whitton
In reply to this post by Chris Lamb-8
control: user [hidden email]
control: usertag = normative proposal

Hello,

==== Proposal: ====

This is what Holger and I think we should add to Policy, after
readability tweaks:

    Packages should build reproducibly, which for purposes of this
    document means that given

    - a version of a source package unpacked at a given path;
    - a set of versions of installed build-dependencies; and
    - a build architecture,

    repeatedly building the source package on the architecture with those
    versions of the build dependencies installed will produce bit-for-bit
    identical binary packages.

==== Explanation: ====

The definition from the reproducible builds group[1] says:

    A build is reproducible if given the same source code, build
    environment and build instructions, any party can recreate
    bit-by-bit identical copies of all specified artifacts.

    The relevant attributes of the build environment, the build
    instructions and the source code as well as the expected
    reproducible artifacts are defined by ... distributors.

i.e. Debian has to define the build environment, source code and build
instructions.  I think that my wording defines these as Debian currently
understands them.

Later, we could narrow the definition of build environment by adding
more constraints, but we're not there yet.

[1]  https://reproducible-builds.org/docs/definition/

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Daniel Kahn Gillmor-7
Thanks for the proposal.  I like it!  A few nit-picks below:

On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:

>     - a version of a source package unpacked at a given path;

I don't like the idea of hard-coding a fixed build path requirement into
debian policy.  We're over 80% with variable build paths in unstable
already, and i want to keep the pressure up on this.  The build location
should not influence the binary output.


>     repeatedly building the source package on the architecture with

maybe s/on the architecture/on any machine of the same architecture/ ?

all the best,

    --dkg

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Chris Lamb-8
In reply to this post by Sean Whitton
Dear Sean & Holger,

Thank you so much for working on this at the end of a tiring DebConf!

> […]
> Later, we could narrow the definition of build environment by adding
> more constraints, but we're not there yet.

That makes sense. Indeed, that even feels like the optimal approach
as it allows flexibility and experimentation, probably more important
the closer and closer we get to to 100% reproducibility.

Thanks again :)


Best wishes,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Russ Allbery-2
In reply to this post by Sean Whitton
Sean Whitton <[hidden email]> writes:

> ==== Proposal: ====

> This is what Holger and I think we should add to Policy, after
> readability tweaks:

>     Packages should build reproducibly, which for purposes of this
>     document means that given

>     - a version of a source package unpacked at a given path;
>     - a set of versions of installed build-dependencies; and
>     - a build architecture,

>     repeatedly building the source package on the architecture with those
>     versions of the build dependencies installed will produce bit-for-bit
>     identical binary packages.

I think we need to add all environment variables starting with DEB_* to
the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
package, for instance.

I feel like there are a bunch of other environment variables that have to
be consistent, although I'm not sure how to specify that since other
environment variables shouldn't matter.  But, say, setting GNUTARGET is
very likely to cause weirdness by changing how ld works.  There are
probably more interesting examples.

How does the current reproducible build testing work with the environment?
Maybe we should just document that for right now and relax it later if
needed?

> ==== Explanation: ====

> The definition from the reproducible builds group[1] says:

>     A build is reproducible if given the same source code, build
>     environment and build instructions, any party can recreate
>     bit-by-bit identical copies of all specified artifacts.

>     The relevant attributes of the build environment, the build
>     instructions and the source code as well as the expected
>     reproducible artifacts are defined by ... distributors.

> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

> Later, we could narrow the definition of build environment by adding
> more constraints, but we're not there yet.

> [1]  https://reproducible-builds.org/docs/definition/

We should add a link to that page (maybe in a footnote).

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Russ Allbery-2
In reply to this post by Daniel Kahn Gillmor-7
Daniel Kahn Gillmor <[hidden email]> writes:
> On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:

>>     - a version of a source package unpacked at a given path;

> I don't like the idea of hard-coding a fixed build path requirement into
> debian policy.  We're over 80% with variable build paths in unstable
> already, and i want to keep the pressure up on this.  The build location
> should not influence the binary output.

It shouldn't, but my understanding is that it currently does.  If you can
fix that, that's great, but until that's been fixed, I don't see the harm
in documenting this as a prerequisite for a reproducible build.  If we can
relax that prerequisite later, great, but nothing about listing it here
should reduce the pressure on making variable build paths work.  It just
documents the current state of the world.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Johannes Schauer-3
In reply to this post by Russ Allbery-2
Hi,

Quoting Russ Allbery (2017-08-12 09:57:44)

> I think we need to add all environment variables starting with DEB_* to
> the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
> DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
> package, for instance.
>
> I feel like there are a bunch of other environment variables that have to
> be consistent, although I'm not sure how to specify that since other
> environment variables shouldn't matter.  But, say, setting GNUTARGET is
> very likely to cause weirdness by changing how ld works.  There are
> probably more interesting examples.
>
> How does the current reproducible build testing work with the environment?
> Maybe we should just document that for right now and relax it later if
> needed?
currently, dpkg-genbuildinfo records all environment variables in a .buildinfo
file which pass a whitelist check. The current whitelist is stored here:

https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Build/Info.pm#n50

I'm not proposing that this whole list should be added to policy. But the list
that ends up in policy must be a subset of the list of environment variables
that dpkg-genbuildinfo stores in the .buildinfo file. Thus:

 - this list from dpkg should give a number of good suggestions of which
   environment variables should be added to policy

 - if any additional variables are added, then they must be added to
   dpkg-genbuildinfo as well.

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Reproducibility in Policy

Bill Allombert-4
In reply to this post by Sean Whitton
On Fri, Aug 11, 2017 at 04:08:47PM -0700, Sean Whitton wrote:

> control: user [hidden email]
> control: usertag = normative proposal
>
> Hello,
>
> ==== Proposal: ====
>
> This is what Holger and I think we should add to Policy, after
> readability tweaks:
>
>     Packages should build reproducibly, which for purposes of this
>     document means that given
>
>     - a version of a source package unpacked at a given path;
>     - a set of versions of installed build-dependencies; and
>     - a build architecture,
>
>     repeatedly building the source package on the architecture with those
>     versions of the build dependencies installed will produce bit-for-bit
>     identical binary packages.
>
> ==== Explanation: ====
>
> The definition from the reproducible builds group[1] says:
>
>     A build is reproducible if given the same source code, build
>     environment and build instructions, any party can recreate
>     bit-by-bit identical copies of all specified artifacts.
>
>     The relevant attributes of the build environment, the build
>     instructions and the source code as well as the expected
>     reproducible artifacts are defined by ... distributors.
>
> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

This require policy to define the build environment and build
instruction much more precisely than it does now, which does not
seems to be practical. Unless maybe if a reference implementation
is provided.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Sean Whitton
In reply to this post by Chris Lamb-8
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 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 they think may be allowed to vary

  - we should wait until .buildinfo is properly documented in policy,
    and then we can refer to that file

- we don't require reproducibility when build paths vary

  This is because

  - since there is not a consensus on whether we should require this,
    and there is strong consensus on the requirement of reproducibility
    if the path does /not/ vary, this issue should not block this change.
    We should open a separate bug against debian-policy

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 same source multiple times to
 generate different binary packages).
 
+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 build dependencies;
+- a set of environment variable values; and
+- a build architecture,
+
+repeatedly building the source package on any machine of the same
+architecture with those versions of the build dependencies installed
+and exactly those environment variable values set will produce
+bit-for-bit identical binary packages.
+
 .. [#]
    See the file ``upgrading-checklist`` for information about policy
    which has changed between different versions of this document.
@@ -790,3 +806,7 @@ generate different binary packages).
    often creates either static linking or shared library conflicts, and,
    most importantly, increases the difficulty of handling security
    vulnerabilities in the duplicated code.
+
+.. [#]
+   This is Debian's precisification of the `reproducible-builds.org
+   definition <https://reproducible-builds.org/docs/definition/>`_.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Holger Levsen-2
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 reproducible builds team aren't yet totally clear on the
>     variables that they think may be allowed to vary
>
>   - we should wait until .buildinfo is properly documented in policy,
>     and then we can refer to that file
>
> - we don't require reproducibility when build paths vary
>
>   This is because
>
>   - since there is not a consensus on whether we should require this,
>     and there is strong consensus on the requirement of reproducibility
>     if the path does /not/ vary, this issue should not block this change.
>     We should open a separate bug against debian-policy
>
> 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 same source multiple times to
>  generate different binary packages).
>  
> +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 build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.
very happily seconded, many thanks to everyone who has contributed to this bug
directly or "indirectly" (I'm thinking specifically about Lunar here).


--
cheers,
        Holger (who watched http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/reproducible-builds-status-update.vp8.webm today and was equally happy when seeing the whole audience agreeing this should be in policy - and the applause after Russ's closing statement was also very very nice…!)

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Ondrej Novy-2
In reply to this post by Sean Whitton
Hi,

2017-08-12 14:23 GMT-04:00 Sean Whitton <[hidden email]>:
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 Nový
 
Email: [hidden email]
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Russ Allbery-2
In reply to this post by Sean Whitton
Sean Whitton <[hidden email]> 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 builds the same source multiple times to
>  generate different binary packages).
>  
> +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 build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.

Seconded.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Ximin Luo-5
In reply to this post by Sean Whitton
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 same source multiple times to
>  generate different binary packages).
>  
> +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 build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +

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, but it is intended that this stricter
+definition would replace the above one, when appropriate in the future.

If this type of "intent" wording is not appropriate for Policy then disregard what I'm saying, I don't wish to block this patch for this reason.

>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.
>

"precisification" -> "more precise version"

X

--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Russ Allbery-2
Ximin Luo <[hidden email]> 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, but it is intended that this stricter
> +definition would replace the above one, when appropriate in the future.

> If this type of "intent" wording is not appropriate for Policy then
> disregard what I'm saying, I don't wish to block this patch for this
> reason.

Oh, that's a good way to capture that.  This seems fine to me, and I have
no objections to adding this advice.  Seconded the original with or
without this addition.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Holger Levsen-2
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 intended that this stricter
> > +definition would replace the above one, when appropriate in the future.
>
> > If this type of "intent" wording is not appropriate for Policy then
> > disregard what I'm saying, I don't wish to block this patch for this
> > reason.
>
> Oh, that's a good way to capture that.  This seems fine to me, and I have
> no objections to adding this advice.  Seconded the original with or
> without this addition.
 
I'm also seconding the original with or without this addition.


--
cheers,
        Holger

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Johannes Schauer-3
In reply to this post by Sean Whitton
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 build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
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 build and host architecture are equal.

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#844431: Revised patch: seeking seconds

Russ Allbery-2
Johannes Schauer <[hidden email]> 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 build and
> host architecture are equal.

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.)

Thanks, good catch!

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

1234
Loading...