• Revise UPDATING entry to account for another use case.

• Update to latest git revision
• Fix UPDATING message

• Minor correction to UPDATING entry

• Added an UPDATING entry
• Updated port version to latest git revision

As discussed on Slack, your changes are okay.

In D21524#469200, @jrm wrote:

In D21524#469184, @ashish wrote:

Hi,

In D21524#468847, @jrm wrote:

Also remove EMACS_VER since it's only used once

I think you meant EMACS_REV here ?

Yup.
As an aside, the garbage collection bug was not completely fixed and Paul E. submitted another patch. See messages #72 and later at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37006

In D21524#468847, @jrm wrote:

Also remove EMACS_VER since it's only used once

Thank you for working on this update. For my part of testing, net-im/ejabberd built with it is running fine.

Sorry for the delay in follow-up. Latest changes also look good to me.

Also, I guess when we publish 26.2, we'll need to remember to set appropriate headers for merge to the quarterly branch.

Thanks for working on it. Changes look good to me. I built the port with couple of permutations of various OPTIONs, and running it (12-amd64), and so far no problems. I've not tried building any dependent ports though.

Alright, looks good to me too. I don't see emacs linking to liblockfile being linked to, if it's installed, and MAILUTILS is off, and everything else is fine too.

Thanks for working on this. Your changes look good in theory. I'm running a test build, and it'll take me few hours (courtesy: webkit2-gtk3 ) to confirm they're good indeed.

Just realized that since this update involves a new Emacs release, are you also planning to update Mk/Uses/emacs.mk and PORTREVISION bump all emacs-dependent ports ?

Thanks, looks good to me.

In D15472#327069, @meta wrote:

Add NO_ARCH=yes

Changes look good. Also, could you please also add NO_ARCH=yes as it's architecture neutral port ?

Sorry for the delay in follow-up. Looks good to me.

Hi Joseph,

Looks good now.

Looks good to me. Can be committed.

In D13506#292150, @mat wrote:

Adding a DEFAULT_VERSIONS+=emacs=xxx seems like the best idea.

In D13506#291664, @mat wrote:

In D13506#291612, @ashish wrote:

I'm not super familiar with ports flavors, and learning as I review stuff, I'll post questions:

1. In pre-flavors (or before D13506 gets committed) era, if I use/install emacs-devel port (non-default emacs port) on my computer, and would like to use a port foobar which provides .el files and therefore specifies dependency on emacs port. Which emacs port it needs to depend on was decided by EMACS_PORT_NAME variable which is to be defined by user in make.conf(5), in case they're using non-default emacs port (like emacs-nox11, or emacs-devel as in my case). What is the solution for this situation in post-flavors era ? If I am not a packages user, and I do, make -C foobar install, what will I get, foobar-emacs25, foobar-emacs27, or what ?

I'm not super familiar with ports flavors, and learning as I review stuff, I'll post questions: