Quoting Alexander Leidinger via freebsd-stable
(from Mon, 23 Mar 2020 08:05:24 +0100):
Quoting tech-lists (from Mon, 23 Mar 2020
01:35:52 +):
Is it possible to use this with a cuda-compatible nvidia card and if so how
would one go about it?
First step would be to convince NVidia
Quoting Alex S (from Sun, 22 Mar 2020 17:53:47 +0300):
Alexander Leidinger wrote:
First step would be to get CUDA support in FreeBSD.
Ahem, I have a little patch, consisting of several functions
copy-pasted from the Linux driver, which is supposed to enable core
CUDA functionality:
https://g
I'm looking into this build error. I believe it's caused by
under-specified LIBADD entries (and the corresponding __DP entries) and
differing bfd vs lld behavior. Once I've got a failing powerpc build
(in progress) I should be able to fix this pretty quickly.
-- Brooks
On Mon, Mar 23, 2020 at 0
I just updated my /usr/ports on my 13.0-current system and after that completed
I tried to
run 'make fetchindex' and got a continuous stream of these errors written to
the display:
fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error
Certificate verification failed for /C=US/O
In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the
upcoming 11.4) back to use the legacy rule set. This means that once
you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should
work as normal, and the environment variable XKB_DEFAULT_RULES does not
need to be c
On 2020-03-23 22:00, Niclas Zeising wrote:
In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the
This should be r529003, sorry about that.
upcoming 11.4) back to use the legacy rule set. This means that once
you have installed libxkbcommon 0.10.0_2 on Fre
Nevermind. I found an email that I had received last month that explained that I
had to make install ca_root_nss. Did that and all is well with make fetchindex
now.
Bob
On Mon, Mar 23, 2020 at 03:57:30PM -0500, Bob Willcox wrote:
> I just updated my /usr/ports on my 13.0-current system and after
Alexander Leidinger wrote:
John-Mark Gurney wrote:
>>Rick Macklem wrote:
>>> to be the best solution. The server can verify that the certificate
>>> was issued by
>>> the local CA. Unfortunately, if the client is compromised and the
>>> certificate is copied
>>> to another client, that client
