06:21:01 what is going on, the contents of this chat window keep randomly dissapearing 06:29:42 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. 07:43:13 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 07:43:47 ultimately the compilation fails because the LOCK_EX and LOCK_UN constants are undefined 07:44:36 I've tried defining _BSD_SOURCE and _POSIX_C_SOURCE prior to the includes, individually and in combination, the build still fails 07:45:16 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 07:45:22 it's this file specifically, if it matters: https://github.com/whatdoineed2do/gpod-utils/blob/master/src/gpod-cp.c 07:46:32 I'm wondering what defines I need to set in order to get flock and the LOCK_ defines to be visible on FreeBSD 08:20:36 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 08:21:14 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 08:23:39 I don't even care about this transcoding functionality, but I don't see any way to disable it. frustrating. 08:32:08 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 08:32:59 i know this is the most bias place to ask, but is freebsd the os considered to have the best tcpip stack? still? 08:33:25 and in this case, by ‘best’, i guess i mean most resilient to synflood and other ddos attacks 08:33:45 nimaje: well it wasn't set. no idea why 08:34:54 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' 08:34:56 tm512: hm, seems like gpod-utils limits itself to _XOPEN_SOURCE=500 (AM_CFLAGS in src/Makefile.am) 08:35:31 but with make V=1 I see in the linker invocation that the -L flag is not being passed 08:38:23 hm, is glibc not strict about _POSIX_C_SOURCE and _XOPEN_SOURCE? that seems to be against what those macros are for 08:39:32 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 08:40:57 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 08:41:49 for some reason src/Makefile.am explicitly includes those ´-l´s in AM_LDFLAGS 08:42:57 I guess I should remove those from there then? 08:44:09 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 08:47:39 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 08:49:20 https://termbin.com/4epmr 08:54:04 hm, where -o is doesn't matter, but I thought order of the object files doesn't matter as well with modern linkers 08:55:26 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 08:56:43 ffmpeg3 is actually too old 08:58:33 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? 08:59:47 what if you move FFMPEG_LDFLAGS as first element in AM_LDFLAGS? 09:06:02 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 09:06:31 switching LDFLAGS to LIBS got it to build 09:07:41 it's a bit frustrating that having an -L flag specifying a path directly before some -l flags doesn't give that path precedence 09:27:30 as said, no idea about autohell, would have expected it to be defined by PKG_CHECK_MODULES(FFMPEG, …) and AC_SUBST(FFMPEG_LIBS) 09:34:35 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 09:37:34 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 09:44:01 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 09:46:42 as you got it to work now, how about writing a port and becoming a ports maintainer? 10:21:51 ek: it's log rotation time. 10:23:59 ek: https://gist.github.com/dlangille/9b970ffc7c90ce76cda939a85570eea7 10:25:06 so.. just live with duplicate destinations and have rotation. 10:25:41 dvl: did you see my comment about using !-openvpn to remove it from daemon.log? 11:00:52 ek: I scrolled back and found a bird reference. Tried this: https://gist.github.com/dlangille/eca7a1d488b8cc34c025d6562a4a2155 15:41:51 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 15:45:09 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? 15:56:18 sig`: i didn't think rge(4) was in 15.0? 15:57:49 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. 15:59:32 wasn't rge out of base 16:00:07 ketas: the ports one is if_re_updated, rge is the one adrian ported from openbsd 16:01:01 but rge(4) isn't in 15.0, so i don't know how sig` has it... is there a port for it? 16:01:36 yes 16:01:46 but how sig` has it in base 16:02:08 in offical that is 16:02:09 it is in port called net/realtek-rge-kmod 16:02:18 oh right 16:02:32 it works perfect other than that "1" issue 16:02:57 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 16:05:44 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. 16:08:26 1 issue? 16:08:30 it has issue? 16:09:27 yeah, if you unplug it and plug it back in it is dead, doesn't renegotiate.... 16:09:46 and how to fix it? 16:09:58 unload or reboot? 16:10:09 nasty anyway 16:10:19 well it is headless so I had to reboot it. 16:11:04 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. 16:12:12 it was only nic eh? 16:13:01 this NIC in that server is the RTL8125 yeah 16:15:02 known bug? 16:15:14 the driver is experimental 16:15:21 oh 16:15:33 driver dev probably goes like those sick fuckers 16:15:52 rtl driver in base has comments like worst nic in the world 16:15:57 :) 16:16:01 LOL 16:16:16 or what was it 16:16:39 surely it had a reason to appear in it 16:16:57 oh iirc it had descriptions, why, too 16:17:18 well whoever is working on it is doing a good job 16:18:53 :) 20:17:19 dvl: Ah, yes! Did it end up working as expected? 20:39:45 ek: openvpen is still logging to three files. 20:46:10 _> /var/log/{daemon,messages,openvpn} 20:49:42 actually, that's: /var/log/{daemon.log,messages,openvpn.log} 21:01:18 What!? Even with the "!" settings in syslog.conf? 21:01:34 The stuff ivy recommended? 21:02:10 dvl: Oops. Forgot to address you. So, here's that. 21:23:54 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. 21:24:14 *DNS 21:27:05 ek: Something like that. 23:53:09 any ideas why sysutils/screen may not lock screen by "C-A,x" after upgrade ?