Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Feb 2020 20:57:31 +0000
From:      bugzilla-noreply@freebsd.org
To:        x11@FreeBSD.org
Subject:   [Bug 243649] [patch] devel/libepoll-shim: Update to 0.0.20191117 version to unbreak re-plugging input devices
Message-ID:  <bug-243649-7141-Q7Tw96gbiy@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-243649-7141@https.bugs.freebsd.org/bugzilla/>
References:  <bug-243649-7141@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243649

--- Comment #18 from Jan Beich <jbeich@FreeBSD.org> ---
(In reply to Michael Gmelin from comment #16)
> I left a comment in the patch. I didn't want to rely on the hash
> of a commit that might not get merged exactly like it is/end up
> somehow butchered in github for the build.

GitHub allows referencing commits disconnected from all branches. I use it =
all
the time in my ports to pull random patches: upstreamed or not, even from
deleted repos. Besides, your comment also refers to a commit "that might not
get merged exactly".

Nevermind then. How to format patches varies by maintainer.

> Like in "${SETENV} ${TEST_ENV} ctest..."?

Yep. I suspect ${SETENV} is more declarative than functional. Maybe in the =
past
it allowed to use C shell to run commands from a target but nowadays a lot =
of
ports rely on Bourne syntax with some Almquist/FreeBSD additions. Porter's
Handbook doesn't cover ${SETENV} while portlint doesn't warn if
${CONFIGURE_ENV}, ${MAKE_ENV}, ${TEST_ENV}, etc. are used without ${SETENV}.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243649-7141-Q7Tw96gbiy>