Sam Hartman writes ("Re: Use of the Build-Conflicts field"):
> Especially when I was doing both NFS and Moonshot builds, it really
> helped me avoid shooting myselfg in the foot.
> It also helped others.
Right.
Your example seems perfect to me because it demonstrates ni
So, I've only had a desire to use the build-conflicts field once in my
time doing Debian packaging, but that one time it was such the right
answer that I was really glad the field is there.
I was packaging Moonshot, a GSS-API mechanism based on EAP.
It depends heavily on the underlying
On Sat, 16 Feb 2019 10:54:25 -0800, Russ Allbery wrote:
> Tollef Fog Heen writes:
>
>> I think we should (over time) aim towards non-reproducible builds being
>> release critical bugs, and I think «builds differently in an unclean
>> chroot» is a class of non-reproducibleness we need to tackle
Hello,
On Fri 15 Feb 2019 at 08:59PM -0700, Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
>
>
]] Andrey Rahmatullin
> If "support" means "allow in the archive" then I think for we support only
[…]
> If "support" means "guarantee that a package will be able to build" then I
[…]
> If "support" means "guarantee that a package will be able to build and
I don't think guarantees are
On Sun, Feb 17, 2019 at 07:44:29AM +0100, Tollef Fog Heen wrote:
> I think it boils down to the question of «Are builds outside of a
> minimal + build-essential + build-deps» supported?». If they're not, we
> can just ignore the problem and deprecate the Build-Conflicts field
> (since it has no
]] Russ Allbery
> Tollef Fog Heen writes:
>
> > I think we should (over time) aim towards non-reproducible builds being
> > release critical bugs, and I think «builds differently in an unclean
> > chroot» is a class of non-reproducibleness we need to tackle («fails to
> > build» is really just
Tollef Fog Heen wrote:
> ]] Sean Whitton
>
> > There are two cases which we think that everyone would agree that there
> > is a bug, but we are not sure that the bug would be considered to be RC.
> > We are posting to -devel to see if, in fact, we do have a consensus that
> > these bugs would be
Tollef Fog Heen writes:
> I think we should (over time) aim towards non-reproducible builds being
> release critical bugs, and I think «builds differently in an unclean
> chroot» is a class of non-reproducibleness we need to tackle («fails to
> build» is really just a subset of «builds
]] Sean Whitton
> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.
>
> (1) a package
On Fri, Feb 15, 2019 at 08:59:41PM -0700, Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
>
>
On Sat, Feb 16, 2019 at 12:00 PM Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
Personally, the ma
On 2/16/19 7:08 AM, Scott Kitterman wrote:
> On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote:
>> Hello,
>>
>> Use of the Build-Conflicts field is currently mostly optional, but Ian
>> Jackson and I have been working on text for Debian Policy that would
&g
Sean Whitton writes:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
>
> There are two cases which we think that every
On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote:
> Hello,
>
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for
Hello,
Use of the Build-Conflicts field is currently mostly optional, but Ian
Jackson and I have been working on text for Debian Policy that would
require its use in certain cases. See #824495 for the discussion.
There are two cases which we think that everyone would agree that there
is a bug
16 matches
Mail list logo
