Re: svn commit: r350550 - head/share/mk
Glen Barber wrote: > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). I track stable. I had no need to complain because I could edit src.conf and add WITHOUT_REPRODUCIBLE_BUILD=YES Please don't remove this ability thinking no-one minds reproducible builds.. I personally think they are pointless. Cheers, Jamie ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
> On 07/08/2019 15:12, Rodney W. Grimes wrote:
> >> On 07/08/2019 11:00, John Baldwin wrote:
> >>> On 8/6/19 9:56 AM, Glen Barber wrote:
> On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote:
> > Author: jhb
> > Date: Sat Aug 3 01:06:17 2019
> > New Revision: 350550
> > URL: https://svnweb.freebsd.org/changeset/base/350550
> >
> > Log:
> > Flip REPRODUCIBLE_BUILD back to off by default in head.
> >
> > Having the full uname output can be useful on head even with
> > unmodified trees or trees that newvers.sh fails to recognize as
> > modified.
> >
> > Reviewed by:emaste
> > Differential Revision: https://reviews.freebsd.org/D20895
> >
> I would like to request this commit be reverted. While the original
> commit message to enable this knob stated the commit would be reverted
> after stable/12 branched, I have seen no public complaints about
> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see
> the benefit of disabling it by default -- why wouldn't we want
> reproducibility?).
>
> To me, this feels like a step backwards, with no tangible benefit.
> Note, newvers.sh does properly detect a modified tree if it can find
> the VCS metadata directory (i.e., .git, .svn) -- I know this because
> I personally helped with it.
>
> In my opinion, those that want the non-reproducible metadata included in
> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their
> src.conf. Turning off a sane default for the benefit of what I suspect
> is likely a short list of use cases feels like a step in the wrong
> direction.
> >>> My arguments for flipping this in head (and head only) are that the data
> >>> provided in uname -a when this is disabled is useful for development, and
> >>> that in head we do tailor settings towards development (e.g. GENERIC in
> >>> head vs GENERIC in stable).
> >>>
> >>> The logic to handle modified trees has an inherent assumption that I think
> >>> is false, at least for my workflow and I suspect many others. I do builds
> >>> and tests of kernels on separate machines (VMs or bare metal) from where I
> >>> use VCS to manage sources so that a kernel crash doesn't toast my source
> >>> tree. The trees are then shared to the build/test machines via NFS. As
> >>> a result, the build/test machines are not always able to detect that the
> >>> tree is modified either because a subset of the checkout is exported via
> >>> NFS, or the VCS tool isn't installed on the build/test machines because
> >>> they are generally barebones systems with only a base installed. This
> >>> does mean that flipping the knob off doesn't provide all of the same info,
> >>> but it does provide the path, and the path matters because 'kgdb -n last'
> >>> uses it, and because if you use separate directories for separate projects
> >>> (e.g. git worktrees), then the path tells you which test kernel you
> >>> booted.
> >>> (It is not uncommon for me to have several test projects in flight on a
> >>> single test machine for different branches.)
> >>>
> >>> In the original discussion on arch, we collectively recognized that
> >>> developer builds vs release builds were different and needed different
> >>> defaults. The compromise reached at that time was to depend on the VCS
> >>> to detect developer builds to choose the policy. What I have found is
> >>> that
> >>> in practice for at least my workflow that doesn't actually work. I posit
> >>> that the majority of kernels built from head are developer builds, not
> >>> releases, and that the default should cater to that. You could also
> >>> always
> >>> patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I
> >>> think would give a more accurate sense of when builds are releases or not.
> >>>
> >>> However, I will yield to whatever the consensus is.
> >> +1 keeping metadata in head.
> > I am conflicted on this one, and I think there is a reasonable argument
> > on both sides, but from what I have read here this appears to be mostly
> > the kernel that is at issue, loss of the meta data from newvers.sh in
> > the kernel is infact a PITA, even on stable or production release
> > systems.
> >
> > I propose a compromise, add 2 knobs:
> > WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname)
> > WITH_REPRODUCIBLE_USERLAND (aka reproducible userland)
> >
> > WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat,
> > and neither should be defined by default.
> Too complex IMHO. Either the system is reproducible or it isn't.
> > Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC
> > for releases/snapshots, but do not ship the system with it
> > set (I can here a growl from Glen on this) Thus we build
> > a reproducible kernel and ship it with the system but if
> > the user builds a kernel it
Re: svn commit: r350550 - head/share/mk
On 07/08/2019 15:12, Rodney W. Grimes wrote:
On 07/08/2019 11:00, John Baldwin wrote:
On 8/6/19 9:56 AM, Glen Barber wrote:
On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote:
Author: jhb
Date: Sat Aug 3 01:06:17 2019
New Revision: 350550
URL: https://svnweb.freebsd.org/changeset/base/350550
Log:
Flip REPRODUCIBLE_BUILD back to off by default in head.
Having the full uname output can be useful on head even with
unmodified trees or trees that newvers.sh fails to recognize as
modified.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D20895
I would like to request this commit be reverted. While the original
commit message to enable this knob stated the commit would be reverted
after stable/12 branched, I have seen no public complaints about
enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see
the benefit of disabling it by default -- why wouldn't we want
reproducibility?).
To me, this feels like a step backwards, with no tangible benefit.
Note, newvers.sh does properly detect a modified tree if it can find
the VCS metadata directory (i.e., .git, .svn) -- I know this because
I personally helped with it.
In my opinion, those that want the non-reproducible metadata included in
output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their
src.conf. Turning off a sane default for the benefit of what I suspect
is likely a short list of use cases feels like a step in the wrong
direction.
My arguments for flipping this in head (and head only) are that the data
provided in uname -a when this is disabled is useful for development, and
that in head we do tailor settings towards development (e.g. GENERIC in
head vs GENERIC in stable).
The logic to handle modified trees has an inherent assumption that I think
is false, at least for my workflow and I suspect many others. I do builds
and tests of kernels on separate machines (VMs or bare metal) from where I
use VCS to manage sources so that a kernel crash doesn't toast my source
tree. The trees are then shared to the build/test machines via NFS. As
a result, the build/test machines are not always able to detect that the
tree is modified either because a subset of the checkout is exported via
NFS, or the VCS tool isn't installed on the build/test machines because
they are generally barebones systems with only a base installed. This
does mean that flipping the knob off doesn't provide all of the same info,
but it does provide the path, and the path matters because 'kgdb -n last'
uses it, and because if you use separate directories for separate projects
(e.g. git worktrees), then the path tells you which test kernel you booted.
(It is not uncommon for me to have several test projects in flight on a
single test machine for different branches.)
In the original discussion on arch, we collectively recognized that
developer builds vs release builds were different and needed different
defaults. The compromise reached at that time was to depend on the VCS
to detect developer builds to choose the policy. What I have found is that
in practice for at least my workflow that doesn't actually work. I posit
that the majority of kernels built from head are developer builds, not
releases, and that the default should cater to that. You could also always
patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I
think would give a more accurate sense of when builds are releases or not.
However, I will yield to whatever the consensus is.
+1 keeping metadata in head.
I am conflicted on this one, and I think there is a reasonable argument
on both sides, but from what I have read here this appears to be mostly
the kernel that is at issue, loss of the meta data from newvers.sh in
the kernel is infact a PITA, even on stable or production release
systems.
I propose a compromise, add 2 knobs:
WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname)
WITH_REPRODUCIBLE_USERLAND (aka reproducible userland)
WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat,
and neither should be defined by default.
Too complex IMHO. Either the system is reproducible or it isn't.
Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC
for releases/snapshots, but do not ship the system with it
set (I can here a growl from Glen on this) Thus we build
a reproducible kernel and ship it with the system but if
the user builds a kernel it gets meta data to indicate it
is no longer a stock kernel.
FYI, upon finding I could not figure out what kernel I was running
after installing 12.0 release I turnd off REPRODUCIBLE on my kernel
build VM for 12.0. I do leave it on if I am building userland.
Thoughts?
Among other things, reproducible builds implies that pkg upgrades are
smaller. I see it makes sense to make releases, and in fact -stable,
completely reproducible. For -current I am fine with it not being
reproducible,
All just IMHO.
Pedro.
Re: svn commit: r350550 - head/share/mk
> On 07/08/2019 11:00, John Baldwin wrote:
> > On 8/6/19 9:56 AM, Glen Barber wrote:
> >> On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote:
> >>> Author: jhb
> >>> Date: Sat Aug 3 01:06:17 2019
> >>> New Revision: 350550
> >>> URL: https://svnweb.freebsd.org/changeset/base/350550
> >>>
> >>> Log:
> >>>Flip REPRODUCIBLE_BUILD back to off by default in head.
> >>>
> >>>Having the full uname output can be useful on head even with
> >>>unmodified trees or trees that newvers.sh fails to recognize as
> >>>modified.
> >>>
> >>>Reviewed by: emaste
> >>>Differential Revision: https://reviews.freebsd.org/D20895
> >>>
> >> I would like to request this commit be reverted. While the original
> >> commit message to enable this knob stated the commit would be reverted
> >> after stable/12 branched, I have seen no public complaints about
> >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see
> >> the benefit of disabling it by default -- why wouldn't we want
> >> reproducibility?).
> >>
> >> To me, this feels like a step backwards, with no tangible benefit.
> >> Note, newvers.sh does properly detect a modified tree if it can find
> >> the VCS metadata directory (i.e., .git, .svn) -- I know this because
> >> I personally helped with it.
> >>
> >> In my opinion, those that want the non-reproducible metadata included in
> >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their
> >> src.conf. Turning off a sane default for the benefit of what I suspect
> >> is likely a short list of use cases feels like a step in the wrong
> >> direction.
> > My arguments for flipping this in head (and head only) are that the data
> > provided in uname -a when this is disabled is useful for development, and
> > that in head we do tailor settings towards development (e.g. GENERIC in
> > head vs GENERIC in stable).
> >
> > The logic to handle modified trees has an inherent assumption that I think
> > is false, at least for my workflow and I suspect many others. I do builds
> > and tests of kernels on separate machines (VMs or bare metal) from where I
> > use VCS to manage sources so that a kernel crash doesn't toast my source
> > tree. The trees are then shared to the build/test machines via NFS. As
> > a result, the build/test machines are not always able to detect that the
> > tree is modified either because a subset of the checkout is exported via
> > NFS, or the VCS tool isn't installed on the build/test machines because
> > they are generally barebones systems with only a base installed. This
> > does mean that flipping the knob off doesn't provide all of the same info,
> > but it does provide the path, and the path matters because 'kgdb -n last'
> > uses it, and because if you use separate directories for separate projects
> > (e.g. git worktrees), then the path tells you which test kernel you booted.
> > (It is not uncommon for me to have several test projects in flight on a
> > single test machine for different branches.)
> >
> > In the original discussion on arch, we collectively recognized that
> > developer builds vs release builds were different and needed different
> > defaults. The compromise reached at that time was to depend on the VCS
> > to detect developer builds to choose the policy. What I have found is that
> > in practice for at least my workflow that doesn't actually work. I posit
> > that the majority of kernels built from head are developer builds, not
> > releases, and that the default should cater to that. You could also always
> > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I
> > think would give a more accurate sense of when builds are releases or not.
> >
> > However, I will yield to whatever the consensus is.
>
> +1 keeping metadata in head.
I am conflicted on this one, and I think there is a reasonable argument
on both sides, but from what I have read here this appears to be mostly
the kernel that is at issue, loss of the meta data from newvers.sh in
the kernel is infact a PITA, even on stable or production release
systems.
I propose a compromise, add 2 knobs:
WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname)
WITH_REPRODUCIBLE_USERLAND (aka reproducible userland)
WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat,
and neither should be defined by default.
Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC
for releases/snapshots, but do not ship the system with it
set (I can here a growl from Glen on this) Thus we build
a reproducible kernel and ship it with the system but if
the user builds a kernel it gets meta data to indicate it
is no longer a stock kernel.
FYI, upon finding I could not figure out what kernel I was running
after installing 12.0 release I turnd off REPRODUCIBLE on my kernel
build VM for 12.0. I do leave it on if I am building userland.
Thoughts?
--
Rod Grimes
Re: svn commit: r350550 - head/share/mk
On 07/08/2019 11:00, John Baldwin wrote: On 8/6/19 9:56 AM, Glen Barber wrote: On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: Author: jhb Date: Sat Aug 3 01:06:17 2019 New Revision: 350550 URL: https://svnweb.freebsd.org/changeset/base/350550 Log: Flip REPRODUCIBLE_BUILD back to off by default in head. Having the full uname output can be useful on head even with unmodified trees or trees that newvers.sh fails to recognize as modified. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D20895 I would like to request this commit be reverted. While the original commit message to enable this knob stated the commit would be reverted after stable/12 branched, I have seen no public complaints about enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see the benefit of disabling it by default -- why wouldn't we want reproducibility?). To me, this feels like a step backwards, with no tangible benefit. Note, newvers.sh does properly detect a modified tree if it can find the VCS metadata directory (i.e., .git, .svn) -- I know this because I personally helped with it. In my opinion, those that want the non-reproducible metadata included in output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their src.conf. Turning off a sane default for the benefit of what I suspect is likely a short list of use cases feels like a step in the wrong direction. My arguments for flipping this in head (and head only) are that the data provided in uname -a when this is disabled is useful for development, and that in head we do tailor settings towards development (e.g. GENERIC in head vs GENERIC in stable). The logic to handle modified trees has an inherent assumption that I think is false, at least for my workflow and I suspect many others. I do builds and tests of kernels on separate machines (VMs or bare metal) from where I use VCS to manage sources so that a kernel crash doesn't toast my source tree. The trees are then shared to the build/test machines via NFS. As a result, the build/test machines are not always able to detect that the tree is modified either because a subset of the checkout is exported via NFS, or the VCS tool isn't installed on the build/test machines because they are generally barebones systems with only a base installed. This does mean that flipping the knob off doesn't provide all of the same info, but it does provide the path, and the path matters because 'kgdb -n last' uses it, and because if you use separate directories for separate projects (e.g. git worktrees), then the path tells you which test kernel you booted. (It is not uncommon for me to have several test projects in flight on a single test machine for different branches.) In the original discussion on arch, we collectively recognized that developer builds vs release builds were different and needed different defaults. The compromise reached at that time was to depend on the VCS to detect developer builds to choose the policy. What I have found is that in practice for at least my workflow that doesn't actually work. I posit that the majority of kernels built from head are developer builds, not releases, and that the default should cater to that. You could also always patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I think would give a more accurate sense of when builds are releases or not. However, I will yield to whatever the consensus is. +1 keeping metadata in head. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
In message , Scott Long writes : > > > > On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: > > > > On 8/6/19 9:56 AM, Glen Barber wrote: > >> On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: > >>> Author: jhb > >>> Date: Sat Aug 3 01:06:17 2019 > >>> New Revision: 350550 > >>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>> > >>> Log: > >>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>> > >>> Having the full uname output can be useful on head even with > >>> unmodified trees or trees that newvers.sh fails to recognize as > >>> modified. > >>> > >>> Reviewed by: emaste > >>> Differential Revision: https://reviews.freebsd.org/D20895 > >>> > >> > >> I would like to request this commit be reverted. While the original > >> commit message to enable this knob stated the commit would be reverted > >> after stable/12 branched, I have seen no public complaints about > >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >> the benefit of disabling it by default -- why wouldn't we want > >> reproducibility?). > >> > >> To me, this feels like a step backwards, with no tangible benefit. > >> Note, newvers.sh does properly detect a modified tree if it can find > >> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >> I personally helped with it. > >> > >> In my opinion, those that want the non-reproducible metadata included in > >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >> src.conf. Turning off a sane default for the benefit of what I suspect > >> is likely a short list of use cases feels like a step in the wrong > >> direction. > > > > My arguments for flipping this in head (and head only) are that the data > > provided in uname -a when this is disabled is useful for development, and > > that in head we do tailor settings towards development (e.g. GENERIC in > > head vs GENERIC in stable). > > Iâm in favor of how this works at the moment. It was a bit jarring to me w > hen > the reproducible build flag was turned on and I lost all of the metadata that > I subconsciously use during development. I think that what John has done > is an appropriate compromise and is in line with how weâve treated similar > development-facilitating features in the past, i.e. WITNESS/INVARIANTS, > malloc-debug. Agreed. As with John, I have a combination of git and svn trees on various machines. Some install to different partitions on physical hardware while others are tested in VMs. The extra information is handy in keeping track of what is installed where. End users who are concerned about reproducible builds in what we might call pseudo-production will probably not use WITNESS or INVARIANTS either. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
On Wed, Aug 7, 2019 at 10:01 AM John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: > > On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: > >> Author: jhb > >> Date: Sat Aug 3 01:06:17 2019 > >> New Revision: 350550 > >> URL: https://svnweb.freebsd.org/changeset/base/350550 > >> > >> Log: > >> Flip REPRODUCIBLE_BUILD back to off by default in head. > >> > >> Having the full uname output can be useful on head even with > >> unmodified trees or trees that newvers.sh fails to recognize as > >> modified. > >> > >> Reviewed by: emaste > >> Differential Revision: https://reviews.freebsd.org/D20895 > >> > > > > I would like to request this commit be reverted. While the original > > commit message to enable this knob stated the commit would be reverted > > after stable/12 branched, I have seen no public complaints about > > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > > the benefit of disabling it by default -- why wouldn't we want > > reproducibility?). > > > > To me, this feels like a step backwards, with no tangible benefit. > > Note, newvers.sh does properly detect a modified tree if it can find > > the VCS metadata directory (i.e., .git, .svn) -- I know this because > > I personally helped with it. > > > > In my opinion, those that want the non-reproducible metadata included in > > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > > src.conf. Turning off a sane default for the benefit of what I suspect > > is likely a short list of use cases feels like a step in the wrong > > direction. > > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. > I'm with John here: the dirty tree stuff is too fragile for the diversity of development environments that are typical on -current, but not typical on -stable. We should not revert this. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
> On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: > > On 8/6/19 9:56 AM, Glen Barber wrote: >> On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: >>> Author: jhb >>> Date: Sat Aug 3 01:06:17 2019 >>> New Revision: 350550 >>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>> >>> Log: >>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>> >>> Having the full uname output can be useful on head even with >>> unmodified trees or trees that newvers.sh fails to recognize as >>> modified. >>> >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D20895 >>> >> >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >> >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >> >> In my opinion, those that want the non-reproducible metadata included in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >> src.conf. Turning off a sane default for the benefit of what I suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. > > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). I’m in favor of how this works at the moment. It was a bit jarring to me when the reproducible build flag was turned on and I lost all of the metadata that I subconsciously use during development. I think that what John has done is an appropriate compromise and is in line with how we’ve treated similar development-facilitating features in the past, i.e. WITNESS/INVARIANTS, malloc-debug. Scott ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
On 8/6/19 9:56 AM, Glen Barber wrote: > On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 3 01:06:17 2019 >> New Revision: 350550 >> URL: https://svnweb.freebsd.org/changeset/base/350550 >> >> Log: >> Flip REPRODUCIBLE_BUILD back to off by default in head. >> >> Having the full uname output can be useful on head even with >> unmodified trees or trees that newvers.sh fails to recognize as >> modified. >> >> Reviewed by: emaste >> Differential Revision: https://reviews.freebsd.org/D20895 >> > > I would like to request this commit be reverted. While the original > commit message to enable this knob stated the commit would be reverted > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). > > To me, this feels like a step backwards, with no tangible benefit. > Note, newvers.sh does properly detect a modified tree if it can find > the VCS metadata directory (i.e., .git, .svn) -- I know this because > I personally helped with it. > > In my opinion, those that want the non-reproducible metadata included in > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > src.conf. Turning off a sane default for the benefit of what I suspect > is likely a short list of use cases feels like a step in the wrong > direction. My arguments for flipping this in head (and head only) are that the data provided in uname -a when this is disabled is useful for development, and that in head we do tailor settings towards development (e.g. GENERIC in head vs GENERIC in stable). The logic to handle modified trees has an inherent assumption that I think is false, at least for my workflow and I suspect many others. I do builds and tests of kernels on separate machines (VMs or bare metal) from where I use VCS to manage sources so that a kernel crash doesn't toast my source tree. The trees are then shared to the build/test machines via NFS. As a result, the build/test machines are not always able to detect that the tree is modified either because a subset of the checkout is exported via NFS, or the VCS tool isn't installed on the build/test machines because they are generally barebones systems with only a base installed. This does mean that flipping the knob off doesn't provide all of the same info, but it does provide the path, and the path matters because 'kgdb -n last' uses it, and because if you use separate directories for separate projects (e.g. git worktrees), then the path tells you which test kernel you booted. (It is not uncommon for me to have several test projects in flight on a single test machine for different branches.) In the original discussion on arch, we collectively recognized that developer builds vs release builds were different and needed different defaults. The compromise reached at that time was to depend on the VCS to detect developer builds to choose the policy. What I have found is that in practice for at least my workflow that doesn't actually work. I posit that the majority of kernels built from head are developer builds, not releases, and that the default should cater to that. You could also always patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I think would give a more accurate sense of when builds are releases or not. However, I will yield to whatever the consensus is. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
In message <20190806165614.ga41...@freebsd.org>, Glen Barber writes: >In my opinion, those that want the non-reproducible metadata included in >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >src.conf. Turning off a sane default for the benefit of what I suspect >is likely a short list of use cases feels like a step in the wrong >direction. Seconded. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350550 - head/share/mk
On Sat, Aug 03, 2019 at 01:06:18AM +, John Baldwin wrote: > Author: jhb > Date: Sat Aug 3 01:06:17 2019 > New Revision: 350550 > URL: https://svnweb.freebsd.org/changeset/base/350550 > > Log: > Flip REPRODUCIBLE_BUILD back to off by default in head. > > Having the full uname output can be useful on head even with > unmodified trees or trees that newvers.sh fails to recognize as > modified. > > Reviewed by:emaste > Differential Revision: https://reviews.freebsd.org/D20895 > I would like to request this commit be reverted. While the original commit message to enable this knob stated the commit would be reverted after stable/12 branched, I have seen no public complaints about enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see the benefit of disabling it by default -- why wouldn't we want reproducibility?). To me, this feels like a step backwards, with no tangible benefit. Note, newvers.sh does properly detect a modified tree if it can find the VCS metadata directory (i.e., .git, .svn) -- I know this because I personally helped with it. In my opinion, those that want the non-reproducible metadata included in output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their src.conf. Turning off a sane default for the benefit of what I suspect is likely a short list of use cases feels like a step in the wrong direction. Glen signature.asc Description: PGP signature
svn commit: r350550 - head/share/mk
Author: jhb Date: Sat Aug 3 01:06:17 2019 New Revision: 350550 URL: https://svnweb.freebsd.org/changeset/base/350550 Log: Flip REPRODUCIBLE_BUILD back to off by default in head. Having the full uname output can be useful on head even with unmodified trees or trees that newvers.sh fails to recognize as modified. Reviewed by: emaste Differential Revision:https://reviews.freebsd.org/D20895 Modified: head/share/mk/src.opts.mk Modified: head/share/mk/src.opts.mk == --- head/share/mk/src.opts.mk Sat Aug 3 01:02:52 2019(r350549) +++ head/share/mk/src.opts.mk Sat Aug 3 01:06:17 2019(r350550) @@ -162,7 +162,6 @@ __DEFAULT_YES_OPTIONS = \ QUOTAS \ RADIUS_SUPPORT \ RBOOTD \ -REPRODUCIBLE_BUILD \ RESCUE \ ROUTED \ SENDMAIL \ @@ -208,6 +207,7 @@ __DEFAULT_NO_OPTIONS = \ LOADER_VERIEXEC_PASS_MANIFEST \ OFED_EXTRA \ OPENLDAP \ +REPRODUCIBLE_BUILD \ RPCBIND_WARMSTART_SUPPORT \ SHARED_TOOLCHAIN \ SORT_THREADS \ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
