Re: git: 132f818ddbf4 - main - contrib/lutok: update from 0.4 to 0.6.2

> On Sep 4, 2026, at 4:11 PM, Benjamin Jacobs <freebsd@dev.thsi.be> wrote:
> 
> On Fri, 4 Sep 2026 10:33:30 -0700
> "Enji Cooper (yaneurabeya)" <yaneurabeya@gmail.com> wrote:
> 
>>> On Sep 4, 2026, at 3:32 AM, Benjamin Jacobs <freebsd@dev.thsi.be> wrote:
>>> 
>>> Hi,
>>> 
>>> I was meant to send this to you. I assume that including those
>>> build files was unintentional, wasn't it?  
>> 
>> Hi,
>> 	Thank you for following up — I meant to send out a reply to your earlier email.
>> 
>> 	tl;dr: including these files was actually semi-intentional, but their inclusion is temporary. If you feel like it’s a real problem which deserves fixing, please file an issue with bugs.freebsd.org <http://bugs.freebsd.org/>, or freebsd/atf, freebsd/kyua, and freebsd/lutok (on GitHub).
>> 
>> 	(If you’re satisfied with the above answer feel free to stop here)
>> 
>> 	As someone pointed out in https://github.com/freebsd/lutok/issues/37, the release tarballs were incorrectly generated for version 0.6, resulting in broken downstream installs where autotools were not expected to be preinstalled (and weren’t required in past releases). “make dist” doesn’t include the .gitignore files in EXTRA_DIST, so these autotools generated files get checked in to git repos (more easily), for better or worse.
>> 	This should be a relatively short-lived change though: the proposed goal originally was to move to cmake with the project, but after doing some research (thanks to prodding by bapt@ and siva@), I think moving to meson is the more sensible route for the projects. I’ll do a bit more research before committing to meson, but it seems like the better of the two popular build system alternatives to autotools (cmake being the other), which doesn’t rely on heavier weight tools like buck or bazel (which rely on Java/Nailgun).
> 
> Hello,
> 
> Thanks for answering me in detail.
> 
> My understanding is that those release artifacts are useless for
> building using FreeBSD's Mk, although necessary from the point of view
> of an upstream distribution. I'm also under the impression that it is
> customary for other "contrib" software that a bit of post-processing on
> the upstream release is done, sometimes from a vendor branch, to remove
> extraneous cruft or to merge some local patch before entering the src tree.
> 
> And because during the previous import (of version 0.4 thus, whose tarball
> on github does contain configure, config.guess, libtool helpers and
> whatnot), care was taken to remove them, I thought that this might be
> an oversight this time.
> 
> It is just a small oddity to see a 11k+ lines diff popping out when
> catching up on current... Not enough of a big issue for me, but still
> I'm glad to hear that switching from upstream build system will avoid
> such noisy change from happening in the future :-)


Yeah, you’re absolutely right. I nuked the autotools files in cfe443e1e63dd588fba7eabec553ed5e1c408d1f. They will conflict from here on out, achieving a desired result being: they won’t get as committed as blindly to the tree in the future.
-Enji