Any breakage is probably my fault - I need to pick this one up again and work on it some more.

Fix unneeded dependency on guile-cairo when CAIRO option is off.

Add flavors (full/lite).

Add build dependency on gettext-tools, to get some stuff (gnulib's lib-link.m4) that actually has nothing to do with gettext :-(

Ugh, build does break for some option combinations due to hidden dependency on gettext-tools (for aclocal/lib-link.m4). Will post new patch after next round of tests.

No, this change is wrong if LUA_PREFIX is something different from /usr/local, since in that case luaconf.h does indeed get modified.

In D14709#483062, @russ.haley_gmail.com wrote:

In D14709#483029, @andrew_tao173.riddles.org.uk wrote:

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You should ask about that on the mailing list. -O2 is specified twice, as well as -Os. Which option does the compiler take?

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You seem to have duplicated a patch? There should be no patch for lua.c other than the extra-patch-libedit-dl one.

• When the ASSERT option is selected, the extra-patch-assert file fails to apply cleanly. I tried to port it over but I there has been a change to lgc.c and I don't know enough about lgc to apply the patch (Help Andrew?).

Style fixes. Rebase.

Now that a 5.4.0-beta release has been made, and there are signs that features are actually stabilizing (there have been many changes since work2), perhaps we could pick this up again. The distinfo needs an update of course.

Further proposal (the patch doesn't do this yet): cron should not override PATH when reading a user crontab; whether it should use the user's path, or daemon's path, rather than the hardcoded default when processing the system crontab is a more open question.

I've been pondering whether limits(1) also needs an option to pick up the environment from the login class, or whether that's better addressed in rc.subr for the case of servicename_class="x" settings.

In D21402#467883, @pkubaj wrote:

In D21402#467690, @andrew_tao173.riddles.org.uk wrote:

Why isn't this just CFLAGS+=-fPIC ?

Because e.g. powerpc64 doesn't need it.

Why isn't this just CFLAGS+=-fPIC ?

I've been running this myself for a while and have done explicit tests as listed in the test plan, and as far as I'm concerned it's done unless anyone has feedback on comments or docs. Anyone up for committing it?

Add documentation. Update comments. Refine the wording a little.

In D21350#464589, @imp wrote:

OK. Other than the updating the comments, I'm convinced this is a good thing.

In D21350#464485, @imp wrote:

Nesting is there as a sanity check when you try to create an inner container at offset 0, you don't recurse with the outer container somehow... Does this run afoul of that?

ping?

Apologies for needing another review round. Changes:

Ugh. Hold off on committing, please; there's one more issue to fix.

Philip: are you taking it, or should I find someone else? (I'm not a committer and as far as I know tmunro is only a src committer)

This is my final version unless someone spots a problem with it.

Update PORTREVISION which I forgot before.

In D20646#450328, @tmunro wrote:

However, I wonder if the encoding situation is OK; the modern version is in UTF8, and for example, if you pick Asia -> Kazhakstan, you'll see some non-ASCII characters. I'm not sure I understand ncursesw's model of character encoding, but I can see that we are already showing UTF8 text directly from /usr/shared/misc/iso3166 ("Côte d'Ivoire", "Curaçao", ...), so maybe that's OK.

Use Dq Li in place of most Ql uses, and use Dq alone in place of some uses of Ql that were not in fact literals.

Qq? there are none of those, only Ql for inline literals (though on second reading some of those are wrong and should have been Dq - will fix).

The test case I've been using was posted to lua-l in Feb by Sascha Zelzer, but the archives aren't public so I can't just link to it.

Of course I have no objections (moving the license text from LICENSE into the source files is completely compatible with both the intent and the stated terms of the license).

I'm happy to pick up the flavors work again if there's any likelihood of it actually going anywhere.

While we're in here changing stuff, is it also worth adding a patch for the upvaluejoin bug? The bug in itself is a non-issue, but some prat filed a CVE for it.

I think in the short term there's no point in adding an option, and instead we should just append -lpthread to LIBS, since we ignore LIBS when building the .so anyway.

Russ, did you check whether that test actually failed without the patch? Because it works fine for me without changing a thing.

Update to 3.0.1.

So, once again, are we done here? I have nothing more to add.

I'm told there's a 3.0.1 release likely within a week or so that fixes both the bug and the build process issues discussed here.

Remove an unnecessary conditional as pointed out by mat.

Track changes requested by mat for the 5.3 port.

Include mat's latest requested changes.

Flavors stuff is up at D16494

In D14709#349874, @russ.haley_gmail.com wrote:

Hi @dbn, Lua 5.4 is still in a beta phase so my preference is to hold this port until the Lua 5.4 official release, then update and push it to the repository. @andrew_tao173.riddles.org.uk has already indicated his preference to hold the port until the Lua release (unless something has changed?)

So are we done here? I have nothing more to add.

So are we done here? I have nothing more to add.

Style/format fixes

• Rebase against current existing port rather than previous version.
  • Add USES+=gmake
  • Add Makefile patches to respect $(DESTDIR) so that make stage works.
  • Fix an upstream bug.
  • Regenerate pkg-plist to match new version's files.

No, seems there's lots more wrong with this - at least the install is broken (looks like it's not respecting the staging dir)

Looks like a missing USES+=gmake

Doesn't build for me. Trying to figure out why.

Changes in line with 5.3.5 patch:

• change DOCSDIR to lua53/lua so that lua53/${PORTNAME} could be used for lua module ports
  • reorganize DOCS install so that check-plist doesn't complain

Sync with 5.3.5 work.

New version to fix the libedit issue.

Use DISTVERSION. This corrects the package version too (now 5.4.0.w2)

Change OPTIONS_DEFAULT+= to just = in accordance with nitpicking on the 5.3.5 patch.

Remove use of ${PORTNAME} in line with discussions over on the 5.3.5 patch.

mat: like this?

This is now a diff against the result of 'svn cp lua53 lua54' as requested by mat.

Added ASSERT and APICHECK options.

In D14709#345221, @russ.haley_gmail.com wrote:

I may be mistaken, but the experimental (not expeditionary!) run only build packages so I'm hoping we can get the build output and see what needs upgrading. I see now that I can request an experimantal run on Bugzilla so I'll submit one today.

In D14709#345216, @russ.haley_gmail.com wrote:

In D14709#345215, @andrew_tao173.riddles.org.uk wrote:

Note that work2 is not ready for prime time yet (garbage collector bugs, at least)

I didn't see anything on the mailing list that would preclude adding it to the ports collection, or at the very least performing an expeditionary run (if that's possible). @mat, @dbn, I'm keen to get 5.3.5 or preferably 5.4 "build tested" against other packages because I've got a week off work right now with no kids.

Note that work2 is not ready for prime time yet (garbage collector bugs, at least)