Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Jan 2017 10:51:39 -0700
From:      Adam Weinberger <adamw@adamw.org>
To:        marino@freebsd.org
Cc:        Adam Weinberger <adamw@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
Subject:   Re: svn commit: r430981 - head/editors/vim
Message-ID:  <3C222198-383E-4705-BE5B-266096D34015@adamw.org>
In-Reply-To: <50df5703-a6da-e25f-5f48-6501dbc80ed0@marino.st>
References:  <201701091703.v09H3cEE082911@repo.freebsd.org> <50df5703-a6da-e25f-5f48-6501dbc80ed0@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 9 Jan, 2017, at 10:22, John Marino <freebsd.contact@marino.st> =
wrote:
>=20
> On 1/9/2017 11:03, Adam Weinberger wrote:
>> Author: adamw
>> Date: Mon Jan  9 17:03:37 2017
>> New Revision: 430981
>> URL: https://svnweb.freebsd.org/changeset/ports/430981
>>=20
>> Log:
>>  Re-add MAKE_JOBS_UNSAFE. =46rom mat:
>>    --- scratch ---
>>    cp config.mk.dist auto/config.mk
>>    --- clean ---
>>    make[2]: =
"/wrkdirs/usr/ports/editors/vim/work/vim-8.0.0149/src/po/Makefile" line =
4: Could not find ../auto/config.mk
>>    make[2]: Fatal errors encountered -- cannot continue
>>=20
>>  Install desktop files and icons when the GNOME, GTK2, or GTK3 knobs =
are turned
>>  on. Requested by Kevin Zheng. PORTREVISION bump for this.
>>=20
>=20
> Hi Adam,
> So I looked up the commit history since this message made me curious =
and this comes from 10 DEC 16:
> "Patch 129 was a fix for parallel make. It builds fine for me on
> FreeBSD with -j4, and on macOS with -j8, but that's the extent
> of what I can test on my own. I'm removing MAKE_JOBS_UNSAFE with
> this commit, but if one of you with your crazy 256-core machines
> encounters build failures then please let me know!"
>=20
> I've seen this kind of thing from time-to-time, where somebody like =
me, after being 100% sure and, marks a port jobs unsafe usually =
documenting why.  Then later, somebody tries to recreate it on some =
random machine, can't do it, and decides, "Hey, it must have magically =
fixed itself" and removes the label.  And then, of course, it's actually =
still broken and the original committer often has to relabel the port =
unsafe.
>=20
> What should happen is that the original cause for jobs unsafety has to =
be traced, and then either A) patched to fix to B) confirm concretely =
that upstream has identified and fixed the problem.  Without concrete =
proof that a port has been fixed, IMO it should remain unsafe =
indefinitely.
>=20
> I don't think this is written down anywhere, but it would be nice if =
it were documented in a guide, perhaps the do's/dont's for ports =
committers because incorrect reversion of MAKE_JOBS_UNSAFE happens much =
more often than it should.
>=20
> No, it's not the worst thing in the world, but I think as a group we =
can do better in this area.  Reproducing jobs unsafety is not always =
easy, nor is it a simple matter of -j number.
>=20
> John

You're totally right about this, and I can't disagree with anything you =
said here. I had some confidence that the build problem was fixed (I ran =
into the original problem 100% of the time, and with patch 129 it built =
successfully 100% of the time for me), but, as you noted, wishful =
thinking isn't concrete evidence, no matter how hard you cross your =
fingers.

I do urge you to produce an item for the PH.

# Adam


--=20
Adam Weinberger
adamw@adamw.org
https://www.adamw.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C222198-383E-4705-BE5B-266096D34015>