what is going on, the contents of this chat window keep randomly dissapearing

That sounds like an IRC client thing. Note that a small number of user clients are continuously connecting and disconnecting due to some error in their client or network and it is flooding the channel with PARTs and JOINs.

so I'm trying to compile gpod-utils here, to manage my iPod since the gtkpod port on FreeBSD apparently wasn't built with mp4v2 support. I'm having problems with flock not being defined, even though sys/file.h is included in this file

ultimately the compilation fails because the LOCK_EX and LOCK_UN constants are undefined

I've tried defining _BSD_SOURCE and _POSIX_C_SOURCE prior to the includes, individually and in combination, the build still fails

you would think that but i’m connected to other channels including one on this very server, and this is only happening on this channel. Also my client hides join part messages. But they still exist so if its a major enough of a flood, maybe its filling the entire text buffer for this client, if thats even a thing

it's this file specifically, if it matters: github.com/whatdoineed2do/gpod-utils/blob/master/src/gpod-cp.c

I'm wondering what defines I need to set in order to get flock and the LOCK_ defines to be visible on FreeBSD

fixed that by defining __BSD_VISIBLE, which seems like a workaround and not something intended to be used like that. but now the build fails during the linking step, several ffmpeg functions are undefined symbols

figured maybe it's just that this code hasn't been updated in a while, and needs an older ffmpeg version, but it fails to build against ffmpeg4 as well

I don't even care about this transcoding functionality, but I don't see any way to disable it. frustrating.

you shouldn't set __BSD_VISIBLE yourself, it should get set if you don't request to be limited in what you can see, like with _POSIX_C_SOURCE

i know this is the most bias place to ask, but is freebsd the os considered to have the best tcpip stack? still?

and in this case, by ‘best’, i guess i mean most resilient to synflood and other ddos attacks

nimaje: well it wasn't set. no idea why

it seems like the ffmpeg issue, looking at the linker invocation, is due to the LDFLAGS getting mangled somehow. in config.log I see pkg_cv_FFMPEG_LIBS='-L/usr/local/ffmpeg4/lib -lavformat -lavcodec -lswresample -lswscale -lavutil'

tm512: hm, seems like gpod-utils limits itself to _XOPEN_SOURCE=500 (AM_CFLAGS in src/Makefile.am)

but with make V=1 I see in the linker invocation that the -L flag is not being passed

hm, is glibc not strict about _POSIX_C_SOURCE and _XOPEN_SOURCE? that seems to be against what those macros are for

oh wait, it actually is including the -L flag, but it's got -lavcodec et al twice in the invocation prior to the -L flag, and then twice after

weird. should I expect it to link against ffmpeg 8.0 in that case, or ffmpeg 4.4? I'm not sure whether flags early in the command line get precedence, with later duplicates being ignored

for some reason src/Makefile.am explicitly includes those ´-l´s in AM_LDFLAGS

I guess I should remove those from there then?

and then again later again for specific targets, I don't really know autohell, but I don't think that is how you should use it

I removed those, but get the same undefined symbol errors. now the only ffmpeg LDFLAGS are at the very end of the linker invocation, well after -o if that makes any difference

hm, where -o is doesn't matter, but I thought order of the object files doesn't matter as well with modern linkers

my understanding is that ffmpeg4 should be old enough to have these symbols that were since deprecated but I can try ffmpeg3 as well I guess

ffmpeg3 is actually too old

if ffmpeg4 didn't have those symbols then the compiler would complain earlier about an undefined function, like with flock, not only while linking, hm, but I think -L defines a order in which libs are searched, so maybe it finds the libs from ffmpeg8?

what if you move FFMPEG_LDFLAGS as first element in AM_LDFLAGS?

that didn't work, but I noticed that FFMPEG_LDFLAGS didn't actually seem to be a declared variable. everything else in Makefile.am uses FFMPEG_LIBS, and that's what's printed out in config.log

switching LDFLAGS to LIBS got it to build

it's a bit frustrating that having an -L flag specifying a path directly before some -l flags doesn't give that path precedence

as said, no idea about autohell, would have expected it to be defined by PKG_CHECK_MODULES(FFMPEG, …) and AC_SUBST(FFMPEG_LIBS)

does seem like gpod-cp can be used essentially like rsync where it skips existing files so I can just use this to keep my iPod synced with a directory of my transcodes

currently syncing it with my transcode library currently. I might've just caused myself some additional annoyance because there are some MP3 transcodes here, which I kinda intended on reencoding as AAC, but I guess I don't have ffmpeg set up with fdk-aac here on this machine

considering I gave this iPod a 16x storage upgrade maybe I don't really have to worry about some ~192kbit MP3s being here even though equivalent quality AAC would be smaller

as you got it to work now, how about writing a port and becoming a ports maintainer?

ek: it's log rotation time.

ek: gist.github.com/dlangille/9b970ffc7c90ce76cda939a85570eea7

so.. just live with duplicate destinations and have rotation.

dvl: did you see my comment about using !-openvpn to remove it from daemon.log?

ek: I scrolled back and found a bird reference. Tried this: gist.github.com/dlangille/eca7a1d488b8cc34c025d6562a4a2155

I'm trying to pinpoint why, if the Cat6 cable is unplugged from my headless server and then plugged back in, the NIC does not renegotiate/recover and I end up having to reboot. System is FreeBSD 15.0-RELEASE-p4. The NIC is a Realtek RTL8125 2.5GbE using the rge driver on interface rge0. In /etc/rc.conf I currently have: -rxcsum -txcsum -tso -lro. Under normal operation everything looks healthy: no input/output errors or drops in netstat, link is active, and it ne

and it negotiates as 2500Base-T full-duplex. The issue is specifically that after an unplug/replug event, it does not always come back up properly. Is this a known rge/RTL8125 issue on FreeBSD 15, and is there a recommended workaround other than rebooting?

sig`: i didn't think rge(4) was in 15.0?

It is on mine. I'm on FreeBSD 15.0-RELEASE-p4, the NIC is a Realtek RTL8125, and kldstat shows if_rge.ko loaded. The interface comes up as rge0 and normally negotiates at 2500Base-T full-duplex.

wasn't rge out of base

ketas: the ports one is if_re_updated, rge is the one adrian ported from openbsd

but rge(4) isn't in 15.0, so i don't know how sig` has it... is there a port for it?

yes

but how sig` has it in base

in offical that is

it is in port called net/realtek-rge-kmod

oh right

it works perfect other than that "1" issue

I mean I don't plan on unplugging it anymore but that was the only thing so far I've run into with it. and the tuning recommendation that works great

So my RTL8125 on 15.0-RELEASE-p4 is using the ports/package realtek-rge-kmod, not stock 15.0 base. I had to install that to get this new server’s NIC working, since stock 15.0 didn’t support it out of the box.

1 issue?

it has issue?

yeah, if you unplug it and plug it back in it is dead, doesn't renegotiate....

and how to fix it?

unload or reboot?

nasty anyway

well it is headless so I had to reboot it.

but it is working in other aspects fine and I don't plan on unplugging it anymore. Just something I noticed and went down the rabbit hole trying to see if there was a fix.

it was only nic eh?

this NIC in that server is the RTL8125 yeah

known bug?

the driver is experimental

oh

driver dev probably goes like those sick fuckers

rtl driver in base has comments like worst nic in the world

:)

LOL

or what was it

surely it had a reason to appear in it

oh iirc it had descriptions, why, too

well whoever is working on it is doing a good job

:)

dvl: Ah, yes! Did it end up working as expected?

ek: openvpen is still logging to three files.

_> /var/log/{daemon,messages,openvpn}

actually, that's: /var/log/{daemon.log,messages,openvpn.log}

What!? Even with the "!" settings in syslog.conf?

The stuff ivy recommended?

dvl: Oops. Forgot to address you. So, here's that.

I learned about nuageinit in FreeBSD base. First thing that came to mind is, does it support fetching the YAML configuration from an HTTP endpoint via DBS SRV discovery. Such a combo would be a powerful tool.

*DNS

ek: Something like that.

any ideas why sysutils/screen may not lock screen by "C-A,x" after upgrade ?