t;
> > Sean Whitton writes ("Bug#846970: Patch to document
> > Build-Indep-Architecture field"):
> >> > +``Build-Indep-Architecture``
> >> > +
> >> > +
> >> > +Specification of architectures on which th
On Fri, 2018-06-15 at 19:05:17 +0100, Sean Whitton wrote:
> Sean Whitton writes ("Bug#846970: Patch to document Build-Indep-Architecture
> field"):
> > > +``Build-Indep-Architecture``
> > > +
> Zooming out a bit:
>
> We do n
Hello Steve,
On Fri, Jun 15 2018, Steve Langasek wrote:
> Both of the above are real-world examples that I've encountered where
> Build-Indep-Architecture would be useful. But I know of no packages
> that would benefit from '!amd64' as a specification.
>
> In the first example, instead of 'i386'
On Fri, Jun 15, 2018 at 07:05:17PM +0100, Sean Whitton wrote:
> Thank you for this analysis.
> My original expectation was that the most common use of the field would
> be of the form
> Build-Indep-Architecture: !amd64
I can't imagine why anyone would ever actually specify this.
A more real
On Fri, 15 Jun 2018 at 18:16:47 +0100, Ian Jackson wrote:
> > > +Specification of architectures on which the architecture-independent
> > > +binary packages are known to be buildable and/or not buildable. If
> > > +this field is not specified, it defaults to ``any``, matching all
> > > +Debian mac
Processing control commands:
> tag -1 -patch
Bug #846970 [debian-policy] debian-policy: Proposal for a
Build-Indep-Architecture: control file field
Removed tag(s) patch.
--
846970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846970
Debian Bug Tracking System
Contact ow...@bugs.debian.org
control: tag -1 -patch
[CCing those involved in the original discussion, and wanna-build team,
in case they object to my proposal below to just close this bug]
Hello,
On Fri, Jun 15 2018, Ian Jackson wrote:
> Sean Whitton writes ("Bug#846970: Patch to document Build-Indep-Architecture
Sean Whitton writes ("Bug#846970: Patch to document Build-Indep-Architecture
field"):
> > +``Build-Indep-Architecture``
> > +
> > +
> > +Specification of architectures on which the architecture-independent
> > +binary packa
Hello,
On Thu, Jun 14 2018, Jess Hall wrote:
> How about "You should not specify that the packages are buildable on
> only one architecture."?
This is better than what I wrote, thanks, Jess.
Here is the updated and rebased patch for seconding:
> policy/ch-controlfields.rst | 27 ++
UNSUBSCRIBE
On 06/14/2018 03:49 PM, Jess Hall wrote:
On Sat, 14 Oct 2017 Sean Whitton wrote:
On Sat, Oct 14 2017, Mattia Rizzolo wrote:
On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
+maintainer's control. The specification should entail that the
+architecture-independent pack
On Sat, 14 Oct 2017 Sean Whitton wrote:
> On Sat, Oct 14 2017, Mattia Rizzolo wrote:
> > On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
> >> +maintainer's control. The specification should entail that the
> >> +architecture-independent packages are buildable on at least two
> >> +ar
Hello,
On Sat, Oct 14 2017, Mattia Rizzolo wrote:
> On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
>> I am seeking seconds for the following patch.
>
> Thank you for working on this!
Thank you for the review, though I don't believe I need to update my
patch in light of your commen
On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
> I am seeking seconds for the following patch.
Thank you for working on this!
> - I've included the ability to specify the architectures on which the
> package is known /not/ to build. This seems useful because in many
> cases th
control: tag -1 +patch
Hello,
I am seeking seconds for the following patch.
Comments:
- I've made the two architecture requirement a 'should', because I agree
that we might otherwise end up with "amd64" being the only value
anyone uses for this field. But perhaps it should be a 'recommends
14 matches
Mail list logo
