eeby

Fixed my issue used Intel instead of Nvidia and modesetting

Using Intel

what's the link to the poudriere server that builds packages every Wednesday? I can't find it

Greetings

Greetings

a fellow scientist

Did you eat all the donuts?

antranigv: there isn't one specific server, it's a whole bunch of servers - there's a status page that links to them individually, on pkg-status.freebsd.org

hi, if i am mostly using bin packages but want a few ports installed is it recommended to stick those into a jail?

OwlWizard: i don't see the correlation

Hi folks. Trying to get DKIM going, and I understand it starts a daemon to keep the milter open (I'm using sendmail), but I don't see an rc.d file to handle starts. Am I supposed to run it manually? Is there some other tool that is recommended?

gh00p, Which DKIM daemon are you setting up?

OpenDKIM which I am familiar with has a port/pkg and it comes with /usr/local/etc/rc.d/milter-opendkim therefore I deduce you are using a different DKIM milter?

bugs.freebsd.org/bugzilla/show_bug.cgi?id=280303 , have you heard/read of any update of this one ?

neither of the two reports from this feel particularly credible

are you hitting this?

yes

what do you get from `readelf -n /lib/libcxxrt.so.1` and `readelf -n /lib/libc++.so.1`?

just the "ABI tag:" line, preferably

ABI tag: 1400097

ABI tag: 1401000

that would be a problem

your libcxxrt.so.1 is from a 14.0 build for some reason, while libc++.so.1 is from a 14.1 build

was this installed 14.0 then upgraded to 14.1?

yes pfctl -sr gives : Assertion failed: (elems <= maxelems), function pf_nvuint_32_array, file /usr/src/lib/libpfctl/libpfctl.c, line 147. Abort (core dumped)

but pf seems to be running

yes

ok, so for some reason the upgrade from 14.0 -> 14.1 was wrong

on this system , I was running 12.3-RR and import a raw image of 14.1p4 boot environment, but I checked on the source host that has been upgraded from 12.3, 13.3, 14.0, and 14.1, and I confirm the problem too

s/12.3-RR/12.3-R

from what I read 14.1p0 didn't have this problem

kevans: from a fresh install from 14.1 iso, we have the correct libs

i don't think it would be too surprising if the recent libc++ changes only just made the mismatch relevant

i.e. this was almost certainly just a ticking timebomb and people have gotten lucky

I'd be curious to see if there's anything else in /{,usr/}lib{,exec} /{,usr/}{s,}bin with a 14.0 ABI tag

this feels like a pretty clear freebsd-update problem, though

tbh, here the problem is considered seriously, as it rises pfctl result with nagios checks

kevans: in /lib only 4 lib*.so.* are in ABI tag 1401000

and 70 in 1400097

in /usr/lib 17 are in ABI tag 1401000

337 are in in 1400097

so the vast majority of your system libraries are still 14.0

do any of the binaries fare any better?

fare ?

are the majority of them 14.1, or 14.0?

majority is 14.0

by far

ok, thanks

i'm throwing this transcript into the PR

thank you very much

sidh: is it possible that this machine didn't complete the full freebsd-update procedure going to 14.1?

there's something like three install invocations needed for that kind of upgrade

rwp, sorry, my irc client disconnected. Thanks for taking an interest. I've installed opendkim, but I didn't see that startup script. I do now, thanks. :)  I also haven't configured sendmail to use it yet...