Re: Head build unsafe for /etc today

2017-11-04 Thread Cy Schubert
In message <201711041723.va4hnanj001...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. 
Gri
mes" writes:
> > On 11/2/2017 8:58 PM, Warner Losh wrote:
> > > FreeBSD has grown too big to test every possible thing before you commit.
> 
> I would say that it has always been too big to test every possible
> thing before a commit.  Breakage is just going to happen, we make
> great efforts to minimize it, but like all risks sooner or later
> your gona have a failure.
> 
> > 
> > The build itself is massive.  I usually forget about release/ and the
> > new 'make packages', external toolchain, "old style" kernel builds, etc.
> Good starting list for "make build-regresion" ?
> 
> > 
> > Steve's concerns have validity.   I do think it's time we have an
> > automated suite to test most build cases for things like bmake upgrades
> > or other high risk changes like META_MODE.
> > 
> > 
> > I'll think about this and add to my list of things to implement.
> 
> I would even go so far as to say this may be what we should be
> running in (a) Jenkins.  Or perhaps a deeper exp-run?

Yes.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Head build unsafe for /etc today

2017-11-04 Thread Rodney W. Grimes
> On 11/2/2017 8:58 PM, Warner Losh wrote:
> > FreeBSD has grown too big to test every possible thing before you commit.

I would say that it has always been too big to test every possible
thing before a commit.  Breakage is just going to happen, we make
great efforts to minimize it, but like all risks sooner or later
your gona have a failure.

> 
> The build itself is massive.  I usually forget about release/ and the
> new 'make packages', external toolchain, "old style" kernel builds, etc.
Good starting list for "make build-regresion" ?

> 
> Steve's concerns have validity.   I do think it's time we have an
> automated suite to test most build cases for things like bmake upgrades
> or other high risk changes like META_MODE.
> 
> 
> I'll think about this and add to my list of things to implement.

I would even go so far as to say this may be what we should be
running in (a) Jenkins.  Or perhaps a deeper exp-run?

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Head build unsafe for /etc today

2017-11-04 Thread Pete Wright



On 11/03/2017 13:14, Bryan Drewery wrote:

On 11/2/2017 8:58 PM, Warner Losh wrote:

FreeBSD has grown too big to test every possible thing before you commit.

The build itself is massive.  I usually forget about release/ and the
new 'make packages', external toolchain, "old style" kernel builds, etc.

Steve's concerns have validity.   I do think it's time we have an
automated suite to test most build cases for things like bmake upgrades
or other high risk changes like META_MODE.


I'll think about this and add to my list of things to implement.

hey Bryan - this sounds like a pretty awesome task to take on, i'd be 
willing to help out with this effort as well.  if/when you come up with 
a plan would it be possible to ping freebsd-current@ so that i can see 
if there is anything i'll be able to help out with (assuming there isn't 
already a wiki or list somewhere i can reference to see where i may be 
able to chip in)?


cheers!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Head build unsafe for /etc today

2017-11-02 Thread Mark Millard

On 2017-Nov-2, at 8:50 PM, Steve Kargl  
wrote:

> On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
>> 
>> Are you accusing me of lying?
>> 
> 
> Nope.  I'm stating the obvious.  If you are using
> META_MODE and you do "make buildwould" that is 
> equivalent to "make -DNO_CLEAN buildworld", which
> means you did not rebuild the *world*. 

Also from a prior message of this sequence:

> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> in whatever jail you use, then you're not properly testing 
> your changes to the build infrastructure.

With or without META_MODE, a rm -fr /usr/obj/*
before the build attempt forces a rebuild as far
as I know. It may be more that cleaning was
effectively not tested then rebuilding was
not tested. But always doing rm -fr /usr/obj/*
first establishes a very limited context for
testing cleaning.

WITH_META_MODE and WITHOUT_META_MODE still
might not be strictly equivalent after the
rm -fr /usr/obj/* for some other properties
in such an "empty" context. So testing those
combinations makes sense but would be
insufficient.

> When I see a commit message of the form (and I've
> haven't seen one like this in 25+ years of using
> FreeBSD (aka 386BSD+patchkit))
> 
> Author: bdrewery
> Date: Thu Nov  2 22:23:00 2017
> New Revision: 325347
> URL: https://svnweb.freebsd.org/changeset/base/325347
> 
> Log:
>  Something is very wrong
> 
> Modified:
>  head/Makefile
> 
> Modified: head/Makefile
> ==
> --- head/Makefile Thu Nov  2 21:58:18 2017(r325346)
> +++ head/Makefile Thu Nov  2 22:23:00 2017(r325347)
> @@ -1,3 +1,4 @@
> +.error Bad revision, please wait for a fix in head
> 
> It suggests that whomever did the commit did not properly test
> the patch.  The use of META_MODE (or any other shortcut) when
> testing simply isn't proper testing.

I think I understand the intended point but the
actual wording for "the use of . . ." and
"[i]f your first step isn't . . ." is wrong from
what I can tell.

The testing of WITH_META_MODE is a proper form of test
but is not a sufficient category of test overall. But
omitting all tests of WITH_META_MODE would be poor
procedure in my view.

Some testing needs to be done without rm -fr /usr/obj/*
after a prior build as well. Some testing of
WITH_META_MODE after a prior build needs to be done.
Some testing of WITHOUT_META_MODE after a prior build
needs to be done. And so on. At least that would be
my view.

Any and all mistakes checked-in are examples of
insufficient testing --but always doing sufficient
testing requires establishing a much simpler, more
limited, context. To my knowledge FreeBSD is not
trying to scale back like that. (It is not under
the direction of an Edsger W. Dijkstra.)

I do not know if something might be able to be done
to make such a specific type of "clean test" mistake
less likely to happen again. Could a test context
be established where attempts to delete outside the
build tree would be rejected, with notifications of
the attempts? Could running such a test be automatic
(part of something that is run systematically) and
fast enough to not want to skip it? (Just being
illustrative. The details involved are well outside
my background knowledge. There may be nothing
easy or reasonable.)

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Head build unsafe for /etc today

2017-11-02 Thread Steve Kargl
On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
> 
> Are you accusing me of lying?
> 

Nope.  I'm stating the obvious.  If you are using
META_MODE and you do "make buildwould" that is 
equivalent to "make -DNO_CLEAN buildworld", which
means you did not rebuild the *world*. 

When I see a commit message of the form (and I've
haven't seen one like this in 25+ years of using
FreeBSD (aka 386BSD+patchkit))

Author: bdrewery
Date: Thu Nov  2 22:23:00 2017
New Revision: 325347
URL: https://svnweb.freebsd.org/changeset/base/325347

Log:
  Something is very wrong

Modified:
  head/Makefile

Modified: head/Makefile
==
--- head/Makefile   Thu Nov  2 21:58:18 2017(r325346)
+++ head/Makefile   Thu Nov  2 22:23:00 2017(r325347)
@@ -1,3 +1,4 @@
+.error Bad revision, please wait for a fix in head

It suggests that whomever did the commit did not properly test
the patch.  The use of META_MODE (or any other shortcut) when
testing simply isn't proper testing.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Head build unsafe for /etc today

2017-11-02 Thread Bryan Drewery
On 11/2/2017 7:46 PM, Warner Losh wrote:
> 
> 
> On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery  > wrote:
> 
> 
> 
> > On Nov 2, 2017, at 19:23, Steve Kargl  > wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> >>
> >>
>  On Nov 2, 2017, at 18:49, Steve Kargl 
>  > wrote:
> 
>  On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
>  On Nov 2, 2017, at 15:44, Mark Millard  > wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> 
> >>
> >>
> >> Log:
> >> Something is very wrong
> 
> 
>  Unfortunately I only test with META_MODE these days which implies 
> -DNO_CLEAN.
> >>>
> >>> You're making changes to the build infrastructure and you're
> >>> not properly testing it before committing?  This is beyond
> >>> pointyhat material.
> >>
> >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
> installworld and installkernel, several xdev and native-xtools, several full 
> DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
> tested several targets together, ran various special case tests for submakes, 
> played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
> symlinked objdirs special, ran it through my work repro a few times, did 
> special testing in rescue/, and had a volunteer test release.  In the process 
>  I found a bmake bug, GPL_DTC build bug and several others I don’t recall 
> from the bus.
> >>
> >> What I missed was the “clean” buildworld because I forgot it even 
> exists. I’ve wanted to remove it for a year. I also forgot to test buildenv.
> >>
> >
> > If you did all the above under META_MODE, then no you did not
> > buildworld and buildkernel and all the other stuff you claim.
> 
> Are you accusing me of lying?
> 
> 
> > If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> > in whatever jail you use, then you're not properly testing
> > your changes to the build
> 
> I did that probably 100 times. And that isn’t even “the proper
> test”. Both clean and incremental are needed which I did. zfs
> snapshots help a lot there. I just never ran “_cleanobj” which does
> a full tree walk of clean. But I ran make clean in some subdirs many
> times.
> 
> > infrastructure.  As you have demonstrated,
> > Makefile, Makefile.inc1, and the *.mk files are sufficiently
> > complicated that proper testing
> 
> > should be done, and proper
> > testing means one doesn't takes shortcuts.
> 
> I took 0 shortcuts. As I said I *forgot* that case, among hundreds
> of cases.
> You’re welcome to do this work if you want. I guarantee you would
> not have tested even half of what I tested.
> 
> Hey can you fix universe to only build clang once please? I’ve been
> working up to that but I think you’re best to do it.
> 
> 
> Given the hundreds of commits to the build system and its complexity,
> I'm in awe this doesn't happen more often. Heck, I've done an order of
> magnitude fewer commits to the build system and broken it more often
> than you have, and that's when it was a much simpler beast than it is today.
> 
> Steve's just being overly grumpy imho.  Accidents happen despite one's
> best efforts. This is -current after all...

Sorry I became grumpy too...

I am truly sorry for anyone bit by this. I understand being angry about
it. I too was bitten by it and scrambled to get a fix in on a random
system I had up without much information on what the root cause was. At
first I thought it was the last minute bmake update which came in after
my change since I had no seen anything like this in my testing.  The
commit which caused the problem was reviewed, but the bug was dormant in
unchanged code.

The bug is fixed now, but I am going to keep the AUTO_OBJ feature off
for a few days until I add a few more seatbelts to prevent this again.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: Head build unsafe for /etc today

2017-11-02 Thread Warner Losh
On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery  wrote:

>
>
> > On Nov 2, 2017, at 19:23, Steve Kargl 
> wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> >>
> >>
>  On Nov 2, 2017, at 18:49, Steve Kargl  edu> wrote:
> 
>  On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
>  On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> >>
> >>
> >> Log:
> >> Something is very wrong
> 
> 
>  Unfortunately I only test with META_MODE these days which implies
> -DNO_CLEAN.
> >>>
> >>> You're making changes to the build infrastructure and you're
> >>> not properly testing it before committing?  This is beyond
> >>> pointyhat material.
> >>
> >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of
> installworld and installkernel, several xdev and native-xtools, several
> full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir
> cleans, tested several targets together, ran various special case tests for
> submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and
> tested symlinked objdirs special, ran it through my work repro a few times,
> did special testing in rescue/, and had a volunteer test release.  In the
> process  I found a bmake bug, GPL_DTC build bug and several others I don’t
> recall from the bus.
> >>
> >> What I missed was the “clean” buildworld because I forgot it even
> exists. I’ve wanted to remove it for a year. I also forgot to test buildenv.
> >>
> >
> > If you did all the above under META_MODE, then no you did not
> > buildworld and buildkernel and all the other stuff you claim.
>
> Are you accusing me of lying?
>
>
> > If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> > in whatever jail you use, then you're not properly testing
> > your changes to the build
>
> I did that probably 100 times. And that isn’t even “the proper test”. Both
> clean and incremental are needed which I did. zfs snapshots help a lot
> there. I just never ran “_cleanobj” which does a full tree walk of clean.
> But I ran make clean in some subdirs many times.
>
> > infrastructure.  As you have demonstrated,
> > Makefile, Makefile.inc1, and the *.mk files are sufficiently
> > complicated that proper testing
>
> > should be done, and proper
> > testing means one doesn't takes shortcuts.
>
> I took 0 shortcuts. As I said I *forgot* that case, among hundreds of
> cases.
> You’re welcome to do this work if you want. I guarantee you would not have
> tested even half of what I tested.
>
> Hey can you fix universe to only build clang once please? I’ve been
> working up to that but I think you’re best to do it.


Given the hundreds of commits to the build system and its complexity, I'm
in awe this doesn't happen more often. Heck, I've done an order of
magnitude fewer commits to the build system and broken it more often than
you have, and that's when it was a much simpler beast than it is today.

Steve's just being overly grumpy imho.  Accidents happen despite one's best
efforts. This is -current after all...

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Head build unsafe for /etc today

2017-11-02 Thread Bryan Drewery


> On Nov 2, 2017, at 19:36, Glen Barber  wrote:
> 
>> On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote:
>> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
 On Nov 2, 2017, at 18:49, Steve Kargl  
 wrote:
 You're making changes to the build infrastructure and you're
 not properly testing it before committing?  This is beyond
 pointyhat material. 
>>> 
>>> I ran 2 universes, dozens of buildworlds and buildkernels,
>>> dozens of installworld and installkernel, several xdev and
>>> native-xtools, several full DIRDEPS_BUILD builds and bootstraps,
>>> ran subdir builds, ran subdir cleans, tested several targets together,
>>> ran various special case tests for submakes, played around with a
>>> ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs
>>> special, ran it through my work repro a few times, did special
>>> testing in rescue/, and had a volunteer test release.  In the process
>>> I found a bmake bug, GPL_DTC build bug and several others I don’t
>>> recall from the bus.
>>> 
>>> What I missed was the “clean” buildworld because I forgot it
>>> even exists. I’ve wanted to remove it for a year. I also forgot to
>>> test buildenv.
>>> 
>> 
>> If you did all the above under META_MODE, then no you did not 
>> buildworld and buildkernel and all the other stuff you claim.
>> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
>> in whatever jail you use, then you're not properly testing 
>> your changes to the build infrastructure.
> 
> I did test this, personally, and missed it.

To be fair you didn’t test the AUTO_OBJ piece but did test the much more 
riskier changes to objdir handling. Thanks for that.


>> As you have demonstrated,
>> Makefile, Makefile.inc1, and the *.mk files are sufficiently 
>> complicated that proper testing should be done, and proper 
>> testing means one doesn't takes shortcuts.
>> 
> 
> Mistakes happen.  Things sometimes get accidentally missed.
> 
> Glen
> 

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Head build unsafe for /etc today

2017-11-02 Thread Glen Barber
On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote:
> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> > > On Nov 2, 2017, at 18:49, Steve Kargl  
> > > wrote:
> > > You're making changes to the build infrastructure and you're
> > > not properly testing it before committing?  This is beyond
> > > pointyhat material. 
> > 
> > I ran 2 universes, dozens of buildworlds and buildkernels,
> > dozens of installworld and installkernel, several xdev and
> > native-xtools, several full DIRDEPS_BUILD builds and bootstraps,
> > ran subdir builds, ran subdir cleans, tested several targets together,
> > ran various special case tests for submakes, played around with a
> > ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs
> > special, ran it through my work repro a few times, did special
> > testing in rescue/, and had a volunteer test release.  In the process
> > I found a bmake bug, GPL_DTC build bug and several others I don’t
> > recall from the bus.
> > 
> > What I missed was the “clean” buildworld because I forgot it
> > even exists. I’ve wanted to remove it for a year. I also forgot to
> > test buildenv.
> > 
> 
> If you did all the above under META_MODE, then no you did not 
> buildworld and buildkernel and all the other stuff you claim.
> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> in whatever jail you use, then you're not properly testing 
> your changes to the build infrastructure.

I did test this, personally, and missed it.

> As you have demonstrated,
> Makefile, Makefile.inc1, and the *.mk files are sufficiently 
> complicated that proper testing should be done, and proper 
> testing means one doesn't takes shortcuts.
> 

Mistakes happen.  Things sometimes get accidentally missed.

Glen



signature.asc
Description: PGP signature


Re: Head build unsafe for /etc today

2017-11-02 Thread Steve Kargl
On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> 
> 
> > On Nov 2, 2017, at 18:49, Steve Kargl  
> > wrote:
> > 
> >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> >> 
> >> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> >> 
>  Author: bdrewery
>  Date: Thu Nov  2 22:23:00 2017
>  New Revision: 325347
>  URL: 
>  https://svnweb.freebsd.org/changeset/base/325347
>  
>  
>  Log:
>  Something is very wrong
> >> 
> >> 
> >> Unfortunately I only test with META_MODE these days which implies 
> >> -DNO_CLEAN.
> > 
> > You're making changes to the build infrastructure and you're
> > not properly testing it before committing?  This is beyond
> > pointyhat material. 
> 
> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
> installworld and installkernel, several xdev and native-xtools, several full 
> DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
> tested several targets together, ran various special case tests for submakes, 
> played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
> symlinked objdirs special, ran it through my work repro a few times, did 
> special testing in rescue/, and had a volunteer test release.  In the process 
>  I found a bmake bug, GPL_DTC build bug and several others I don’t recall 
> from the bus.
> 
> What I missed was the “clean” buildworld because I forgot it even exists. 
> I’ve wanted to remove it for a year. I also forgot to test buildenv.
> 

If you did all the above under META_MODE, then no you did not 
buildworld and buildkernel and all the other stuff you claim.
If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
in whatever jail you use, then you're not properly testing 
your changes to the build infrastructure.  As you have demonstrated,
Makefile, Makefile.inc1, and the *.mk files are sufficiently 
complicated that proper testing should be done, and proper 
testing means one doesn't takes shortcuts.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Head build unsafe for /etc today

2017-11-02 Thread Bryan Drewery


> On Nov 2, 2017, at 18:49, Steve Kargl  
> wrote:
> 
>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
>> 
>> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
>> 
 Author: bdrewery
 Date: Thu Nov  2 22:23:00 2017
 New Revision: 325347
 URL: 
 https://svnweb.freebsd.org/changeset/base/325347
 
 
 Log:
 Something is very wrong
>> 
>> 
>> Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN.
> 
> You're making changes to the build infrastructure and you're
> not properly testing it before committing?  This is beyond
> pointyhat material. 

I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
installworld and installkernel, several xdev and native-xtools, several full 
DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
tested several targets together, ran various special case tests for submakes, 
played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
symlinked objdirs special, ran it through my work repro a few times, did 
special testing in rescue/, and had a volunteer test release.  In the process  
I found a bmake bug, GPL_DTC build bug and several others I don’t recall from 
the bus.

What I missed was the “clean” buildworld because I forgot it even exists. I’ve 
wanted to remove it for a year. I also forgot to test buildenv.

By the way the bug ran into here was 3-4 years old and I avoided the exact case 
in some new code but missed that the problem was already existing subtly in 
bsd.obj.mk.

Having said all of that, I certainly don’t do so much testing normally but 
these changes warranted the time I put in.

> 
> -- 
> Steve

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Head build unsafe for /etc today

2017-11-02 Thread Steve Kargl
On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL: 
> >> https://svnweb.freebsd.org/changeset/base/325347
> >> 
> >> 
> >> Log:
> >> Something is very wrong
> 
> 
> Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN.

You're making changes to the build infrastructure and you're
not properly testing it before committing?  This is beyond
pointyhat material. 

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"