Page MenuHomeFreeBSD

theron.tarigo_gmail.com (Theron Tarigo)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 18 2018, 5:17 PM (92 w, 5 d)

Recent Activity

Apr 20 2020

theron.tarigo_gmail.com added a comment to D24510: [new port] devel/mingw-w64 - LLVM MingGW cross compilation toolchain for Windows Executables.

Thank you for working on this. You are welcome to claim maintainership if you'd like but that it also is not necessary as I do not wish to abandon this project.

The package uses mingw64 and Clang10

Does this pertain to planned work? The patch still shows

DISTVERSION= 9.0.1

etc.

Apr 20 2020, 4:28 PM

Mar 10 2020

theron.tarigo_gmail.com updated the diff for D23881: Mk/Uses/kmod.mk: add FLAVORS to USES=kmod for building the kernel module for each minor release kernel..

Added missing plists

Mar 10 2020, 6:59 PM

Mar 7 2020

theron.tarigo_gmail.com updated the diff for D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).
Mar 7 2020, 7:21 PM
theron.tarigo_gmail.com updated the diff for D23881: Mk/Uses/kmod.mk: add FLAVORS to USES=kmod for building the kernel module for each minor release kernel..
Mar 7 2020, 4:16 PM

Feb 28 2020

theron.tarigo_gmail.com added inline comments to D23881: Mk/Uses/kmod.mk: add FLAVORS to USES=kmod for building the kernel module for each minor release kernel..
Feb 28 2020, 11:29 PM
theron.tarigo_gmail.com created D23881: Mk/Uses/kmod.mk: add FLAVORS to USES=kmod for building the kernel module for each minor release kernel..
Feb 28 2020, 6:33 PM

Feb 18 2020

theron.tarigo_gmail.com added inline comments to D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).
Feb 18 2020, 1:31 PM

Nov 26 2019

theron.tarigo_gmail.com added a comment to D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).

I let it get lost in switch from 390.x to 440.x patches.
I thought that getting the updated nvidia-headless-driver port to work with the 3xx versions would be more involved because of changed structure, but I just tried it and it works. Thanks!

Nov 26 2019, 8:01 PM
theron.tarigo_gmail.com updated the diff for D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).

Fix nvidia-driver pkg-plist. Create nvidia-headless-driver-390 (supports oldest generation of Nvidia GPUs used in hybrid graphics configuration).

Nov 26 2019, 7:59 PM
theron.tarigo_gmail.com added a comment to D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).

For the pkg-plist of x11/nvidia-driver, there should be this:

So that nvidia-driver-headless could build (package phase) with legacy driver : 390, 340, 304 .

You're absolutely right. I let it get lost in switch from 390.x to 440.x patches.

Nov 26 2019, 5:37 PM
theron.tarigo_gmail.com updated the diff for D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).

Use %%EXTENSIONSDIR%%/libglx.so in nvidia-driver/pkg-plist

Nov 26 2019, 5:27 PM

Nov 23 2019

theron.tarigo_gmail.com created D22521: new ports: Nvidia headless/hybrid graphics ("Optimus" support).
Nov 23 2019, 5:59 PM

Jul 20 2019

theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

How are libGL dependencies handled right now for other ports?

No idea. They likely depend on Mesa and that's it.

I answered my own question here:

After some investigation: /usr/ports/Mk/Uses/gl.mk has hardcoded dependencies on graphics/mesa-libs - ideally this can be fixed, but as part of some other review.

Jul 20 2019, 3:12 AM

Jul 19 2019

theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

This comment concerns Mesa drivers, and libGL in general, but not much else:

Jul 19 2019, 3:34 AM

Oct 9 2018

theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

Some of us [FreeBSD users] specifically dislike Debian and their way of doing things. Just so you know. This proposal should be discussed on the appropriate mailing list (or maybe IRC channel, I'm not sure).

It is not any sort of attempt to follow Debian. After a little more research, I see how my proposal could be seen as being similar to Debian's approach to this particular situation, which raises skepticism. I will bring it up on hackers@ once I am more prepared.

Oct 9 2018, 6:10 AM
theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

Adding so many slave ports seems very messy. This would introduce many architecture-specific slaves to ports which are otherwise not at all architecture-specific in most cases. Fully-functional Wine requires perhaps more libraries than you anticipate: depending on graphics vendor, all of Mesa, and therefore LLVM as well, must be compiled for i386. At least some i386 LibGL is needed for full functionality.^1

Oct 9 2018, 1:14 AM

Aug 22 2018

theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

Although amd64 and i386 are Tier-1 and freebsd32 compat is a part of base, adding support for lib32 in ports has similarities to porting FreeBSD Ports collection to a new architecture. What is different in this case is that the "new architecture" would be a "slave architecture" to amd64.

Aug 22 2018, 5:36 PM
theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.

Yes, using FLAVORS does not seem quite right. What if one of the dependencies already uses FLAVORS? Regardless of whether this presents a real conflict, FLAVORS is intended for handling varying configurations of ports themselves, not for selecting the manner in which ports are built and installed. The only reason use of FLAVORS is helpful in the present case is that it is an already established way in which one port can generate multiple packages.

Aug 22 2018, 4:49 PM
theron.tarigo_gmail.com added a comment to D16830: USES=lib32: add support for lib32- companion ports.
In D14721#358258, @dbn wrote:

Thank you all for the useful ideas. I think the first price approach is to create 'lib32-' companion packages for the 32-bit libraries we need. To this end I have created a patch that adds this functionality: https://reviews.freebsd.org/D16830. Luckily the approach is minimally invasive and often involves:

  1. Adding lib32 to USES
  2. Sometimes replacing uses of ${PREFIX}/lib} with ${LIBDIR}, however lib32 already handles CFLAGS, CPPFLAGS, and CONFIGURE_ARGS (this can be extended as needed)
  3. Sometimes adding USE_LDCONFIG=yes

If anyone has some time to convent and test the other library dependencies of Wine that will be a great help :-).

Aug 22 2018, 4:52 AM

Aug 19 2018

theron.tarigo_gmail.com added a comment to D14721: emulators/wine-devel: add WOW64.

Hm, so building the "Arch style lib32" packages on-the-fly? That's interesting, but I'm not sure how that would work with official packages. Will poudriere add them to the built package set?

Aug 19 2018, 9:19 PM

Aug 18 2018

theron.tarigo_gmail.com added a comment to D14721: emulators/wine-devel: add WOW64.
In D14721#348739, @mat wrote:

Side note.

All ports MUST build as a regular user.

We spent a lot of time making sure they all do, DO NOT add new ports that require being root, they will get removed at one point in the very near future.

Aug 18 2018, 6:22 PM