Bug 243272 - emulators/i386-wine-devel: Patch for NVIDIA driver does not work
Summary: emulators/i386-wine-devel: Patch for NVIDIA driver does not work
Status: Closed DUPLICATE of bug 244547
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Lorenzo Salvadore
Keywords: needs-patch, needs-qa
Depends on: 242177
  Show dependency treegraph
Reported: 2020-01-11 17:09 UTC by hardy.schumacher
Modified: 2020-03-02 10:25 UTC (History)
5 users (show)

See Also:
salvadore: maintainer-feedback+
koobs: merge-quarterly?


Note You need to log in before you can comment on or make changes to this bug.
Description hardy.schumacher 2020-01-11 17:09:52 UTC
Port "emulators/i386-wine-devel" provides script [files/nvidia.sh] to install the 32bit NVIDIA driver additionally to the already installed 64bit NVIDIA driver with same version number.

Latest version of NVIDIA driver is 440.44, latest available version in the ports is 440.31.
But latest NVIDIA driver for FreeBSD 32bit platform is 390.132.
See https://www.nvidia.com/en-us/drivers/unix/.

Therefore the patch on port "emulators/i386-wine-devel" does not work when the latest NVIDIA driver is used on a 64bit platform.
Comment 1 Alex S 2020-01-11 18:24:42 UTC
The script doesn't work because the necessary libraries are not provided for driver versions > 390.x && < 440.36.

Do note, though, while the 32-bit libraries were recently reintroduced with 440.36 as part of the amd64 package (https://devtalk.nvidia.com/default/topic/1065886/freebsd-solaris/request-include-32-bit-libraries-with-64-bit-drivers/post/5404691/#5404691), instead of updating nvidia.sh it would much more appropriate to pester the nvidia-driver maintainer about properly packaging them. See bug 242177.
Comment 2 Rene Ladan freebsd_committer 2020-02-03 20:05:06 UTC
Maintainer reset.
Comment 3 Lorenzo Salvadore freebsd_committer 2020-02-08 21:44:22 UTC
Hi, I am the new maintainer of i386-wine-devel.
I am currently studying the problem. Thanks to Alex for pointing to bug #242177.
Comment 4 Lorenzo Salvadore freebsd_committer 2020-02-08 22:16:57 UTC
I think the solution to this bug is to fix bug #242177 and then get rid of the nvidia.sh script altogether (assuming it does not do anything else than installing the 32-bit libraries). I am working on the bug #242177 side now. I will keep you informed.
Comment 5 Lorenzo Salvadore freebsd_committer 2020-02-09 07:52:54 UTC
I saw we support older nvdia-drivers (see /usr/ports/x11/), so we probably will have to keep nvidia.sh, but to apply it only in the older cases.
Comment 6 Alex S 2020-02-09 13:01:45 UTC
(In reply to Lorenzo Salvadore from comment #3)

> Hi, I am the new maintainer of i386-wine-devel.

Does that mean you are in charge of building i386-wine packages now? What to expect there?
Comment 7 Lorenzo Salvadore freebsd_committer 2020-02-09 13:27:20 UTC
(In reply to Alex S from comment #6)

Being a port maintainer means many things:
- create the packages (this is usually done automatically by the FreeBSD cluster, but in some cases, such as wine, it requires some manual work);
- update the port;
- make sure port follows FreeBSD style standards;
- fix port when changes to ports infrastructure requires it (e.g. dependencies are updated, moved, standard variables change name etc.);
- address bugs, such as this one;
- etc.

For a more complete description of the port maintainer role, please refer to

And, if you happen to want to become a port maintainer, refer to the porter's handbook as well:
You can also find help, if needed, on IRC: channels #freebsd-ports on Freenode and #bsdports on EFNet.
And of course, we have mailing lists. You can subscribe to the freebsd-ports mailing list here:
Comment 8 Alex S 2020-02-09 13:40:21 UTC
(In reply to Lorenzo Salvadore from comment #7)

I'm aware of all these things, thank you. My question is specifically about i386-wine/i386-wine-devel. Packaging i386-wine-devel involves _a lot_ of pointless busywork (it might not seem that way at first, but dbn@'s eventual burnout speaks for itself) and I'm interested in hearing how do you plan to handle that.
Comment 9 Lorenzo Salvadore freebsd_committer 2020-02-09 13:56:14 UTC
(In reply to Alex S from comment #8)

Yes, I suspected that it was a difficult port, but I wanted to give it a try anyway.
I've started studying the port and its dependencies through the existing bugs, I will soon clean the existing Makefiles (I think there is not much to be done aside from variables reordering) and finally I will go through the understanding of the process of package creation by also updating the port (I see on wine website we are now at versions 5.0 (stable) and 5.1 (development)).
If you want to see how things have started you might be interested in bug #238081 which is also about i386-wine-devel.

I will be glad to give you more details and to answer to more questions if you want, but in that case please contact me at my mail address: let's avoid to fill this bug report with lots of stuff not directly related.
Comment 10 Lorenzo Salvadore freebsd_committer 2020-02-26 16:48:41 UTC
Nvidia drivers have been updated to latest version in bug #242177. Now, when latest drivers version is installed, wine should run successfully without any need of the nvidia.sh script.

Any improvement on this bug? Is the issue still present?
Comment 11 Alex S 2020-02-26 17:03:39 UTC
(In reply to Lorenzo Salvadore from comment #10)

> Now, when latest drivers version is installed,
> wine should run successfully without any need of the nvidia.sh script.


> Is the issue still present?

No. If you feel like you haven't done enough, you might want to adjust nvidia.sh to print some "this is no longer necessary" message for newer drivers. But, please, close this issue.
Comment 12 Lorenzo Salvadore freebsd_committer 2020-03-02 10:25:56 UTC
We still have some work to do on nvidia drivers for i386-wine-devel. A new PR has been opened on the same topic: I will keep that one as it is more up to date and more complete.

*** This bug has been marked as a duplicate of bug 244547 ***