This feature can be refined, but I don’t want to get in the way of the utility of this change for folks like @kp, who need the debuggability. Let’s go forward with this change and refine things/sand down rough edges on GitHub.

Wow. I’m surprised that this kind of bug exists in this libcall..
Would it make sense to define ERRORs to include errno’s of some kind, e.g., EINVAL?

Fix CONFLICTS definition per the Porter's Handbook section on "Using CONFLICTS* With Globs."

Update CONFLICTS_INSTALL to handle the 1.x to 2.x hop cleanly, while forbidding
\*lint1 and \*lint from being installed together.

• Fork 1.x from 2.x
• Upgrade 1.x from 1.62.2 to 1.64.8

In D49723#1133959, @adamw wrote:

This is a good approach. I'm 👍 on behalf of the go team.

Thanks, Enji!

Oof... 2.0.2 really finds a lot more issues in code (for better or worse). containerd for instance passes on 1.65.x, but fails on 2.0.2.
Also, 2.0.2 required a config migration (like tox), so it might make more sense to split up the package into 2 different versions.

I'm in the same boat as @lwhsu : papering over this is fine, but it still doesn't fix the other 3 test cases I mentioned in that are failing though: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285826 .

Restore PORTEPOCH (feedback from bofh)

• Resolve comments from bofh by replacing USE_GITHUB with the static release artifact URL.
• Leverage CONFIGURE_ENABLE= instead of the handrolled equivalent with CONFIGURE_ON= and CONFIGURE_OFF=.

In D49502#1128880, @imp wrote:

In D49502#1128876, @ngie wrote:

In D49502#1128871, @imp wrote:

Do you need to mention the SIGSYS issue? Unless you have blocked SIGSYS, any system call that returns ENOSYS will generate that signal.

Good question. It looks like ENOSYS without SIGSYS is the standard in libsys:

% rg -l SIGSYS lib/libsys/*.2 | wc -l
       1
% rg -l ENOSYS lib/libsys/*.2 | wc -l
      24

Ok looks like intro covers it

In D49502#1128871, @imp wrote:

Do you need to mention the SIGSYS issue? Unless you have blocked SIGSYS, any system call that returns ENOSYS will generate that signal.

In D49463#1128242, @ngie wrote:

• Could you please verify that this doesn't regress Linux/MacOS?
• Something like using debugger_ptr_t = std::shared_ptr<debugger> then converting all of the code to use debugger_ptr_t (or maybe just debugger_ptr? I forget the style ATF/kyua uses since I flushed that out of my cache in favor of other garbage :D..) seems like a good idea for clarity/brevity.

I actually have a different proposal.. what if the "automatic cleanup" functionality was opt-out and enabled by default or by a custom policy, e.g.,

• I want the results from the passed test cases,
• I want the results from the failed test cases only, or
• I don't care, clean it up when you're done.

Also, I think that it's honestly better to get the process core and continue on personally. Otherwise you could have resources tied up waiting for a human to push a button.

• Could you please verify that this doesn't regress Linux/MacOS?
• Something like using debugger_ptr_t = std::shared_ptr<debugger> then converting all of the code to use debugger_ptr_t (or maybe just debugger_ptr? I forget the style ATF/kyua uses since I flushed that out of my cache in favor of other garbage :D..) seems like a good idea for clarity/brevity.

Update remaining version numbers I missed in prior revision.

Update the remaining version numbers/strings

Double-submitted as D49296.

Update with the changes in the tree instead of the vendor import commit