Forgot to write that linux_set_cloned_tls needs an adjustment to work with these changes.

First, let's reference the PR in question: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247327.

Since this is apparently a somewhat confusing topic, let me clarify a few things:

1. nvidia-modeset.ko is required to be loaded in all drivers that contain it — it's not an optional component;
2. Xorg's "modesetting" driver doesn't work with Nvidia, it expects Mesa-specific kernel interfaces (DRI3);
3. nvidia-modeset.ko alone doesn't enable kernel modesetting, the documentation clearly tells us to set a parameter for nvidia-drm.ko, which is a Linux only kernel module at the moment (not counting an unofficial port).

So, is there any chance of this being done before one year anniversary of the patch? Libglvnd is a prerequisite for (real) Optimus support, among other things.

In D29982#675521, @iwtcex_gmail.com wrote:

…

In D29982#675506, @gerald wrote:

Note that Alex S, copied now, has argued for a while this port should go in favor of a much simpler solution. Alex, maybe you can share here?

In D16830#498207, @bapt wrote:

I think if we have lib32 things is should be a new kind of feature quite close to the debug packages I am working on.

In D16830#498205, @iwtcex_gmail.com wrote:

as an alternative "solution" I can only recommend making (as an option or a slave package) i386-wine-devel coinstallable with wine-devel by stripping all conflicting files from i386-wine-devel. That should enable wow64 functionality while preserving every single annoyance about the current system.

In D16830#498207, @bapt wrote:

I think if we have lib32 things is should be a new kind of feature quite close to the debug packages I am working on.

Well, assuming Phabricator notifications are not broken and this is indeed intentional silence, as an alternative "solution" I can only recommend making (as an option or a slave package) i386-wine-devel coinstallable with wine-devel by stripping all conflicting files from i386-wine-devel. That should enable wow64 functionality while preserving every single annoyance about the current system.

@mat Ok, pretty please with a direct mention on top. Specifically, since dbn@ has essentially abandoned this patch, what should we do with it? Does it make sense for me to resubmit an updated patch? (It's quite a bit larger, though.) Who is actually supposed to review, commit or decline this?

As a reminder to new subscribers, just to make sure we are on the same page: this review is dead. Period.

In D16830#466233, @gerald wrote:

portmgr@, can you please advise?

Regarding the recent bug tracker comment, I would actually appreciate this and https://reviews.freebsd.org/D14721 being closed. Right now for people glancing through this thread it's not clear that nothing here is being actively worked on. @dbn?

In D16830#457760, @gerald wrote:

I noticed that I was (still) listed as reviewer and want to clarify that this is way outside my comfort zone, both technically, in terms of what I can verify/test, and on top of those time plus what I could approve.

In D16830#455859, @iwtcex_gmail.com wrote:

I've yet to do some sanity checks to verify that Wine is actually buildable

Should be in reasonable shape now.

In D16830#455750, @theron.tarigo_gmail.com wrote:

Oh, hello Theron.

In D16830#358878, @iwtcex_gmail.com wrote:

made an attempt … according to the initial variant of this patch

Ok, this looks as good as dead. Was this proposal discussed elsewhere and put on hold? Anything else?

Any plans on doing something with this in 2019?

Oh, nice. I immediately got flamed for mentioning that version discrepancy on the FreeBSD forums (with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189180 closed as a consequence), so this patch is extremely welcome.

In D16830#372943, @theron.tarigo_gmail.com wrote:

In D16830#372919, @theron.tarigo_gmail.com wrote:

In D14721#362446, @rozhuk.im-gmail.com wrote:

chroot call can be allowed to non root user, I can write simple MAC module that do this.
Or just use mac_biba / mac_lomac.

@rozhuk.im-gmail.com You know the chroot approach is basically unmergable, right? Unless D16830: USES=lib32: add support for lib32- companion ports also fails review for some reason, it will not be used.

I've also made an attempt to modify some ports according to the initial variant of this patch (i.e., flavors). I will update my diff in a few days, but where exactly should I put proposed additions and/or changes? Not clear on the workflow.

Ok, this looks quite neat.

I am realizing that to resolve the need for i386-on-amd64 packages properly would require much cooperation, making this a large undertaking, as it was for the adoption of FLAVORS.
In the interest of improving Wine experience on FreeBSD for all, it is probably better to avoid such potentially controversial changes and to keep to the model of distributing all i386 Wine libs as a single package, despite the many drawbacks.

I feel a bit rude registering just to make a drive-by comment… Anyway, here are 3 semi-related points: