01:26:10 <FUZxxl> meena: just a suggestion, don't stress yourself
06:51:33 <al1r4d> Is it enough to host OpenVPN and DNS servers like Adguard and Pihole with 1 CPU, 0.5GB of RAM, and 10 GB of SSD on FreeBSD?
07:00:25 <Grell> raspberry pi 4 is back in stock
08:04:08 <Nixkernal> https://docs.pi-hole.net/main/prerequisites/ -> Min. 2GB free space, 4GB recommended, 512MB RAM
08:04:10 <VimDiesel> Title: Prerequisites - Pi-hole documentation
08:09:09 <parv> Could 13.2 read, write 14-CURRENT ZFS datasets created c late 2021?
08:10:33 <parv> (It shooould, & obligatory: There Is Only One Way To Find Out.)
08:26:39 <al1r4d> Thank you, Nixkernal
13:08:25 <Soni> how hard would it be to remove the ipv4 stack?
13:09:43 <Soni> we know freebsd has a CLAT so maybe there's some dependency between the v6 and v4 stacks...
13:18:19 <meena> Soni: WITHOUT_INET
13:19:02 <meena> Soni: see here https://man.freebsd.org/src.conf(5)
13:19:03 <VimDiesel> Title: src.conf(5)
13:23:06 <Soni> we see
15:40:55 <markmcb> I've got a first gen framework laptop that mostly collects dusts, so i tried installing 14 beta 2 on it. i can complete the installer no problem, but after reboot it's unusable. if i drop to a shell in the installer i can see 3 partitions, but fdisk can interpret and i can't say "mount_msdosfs /dev/nda0p1 /tmp/boot"
15:41:27 <markmcb> the laptop works fine. installed arch just to confirm it's not a hardware issue
15:41:44 <markmcb> *fdisk can't
15:42:21 <markmcb> did the install with geli and uefi
15:43:57 <markmcb> (and zfs)
15:46:21 <markmcb> i know that's limited troubleshooting, but i thought i'd mention it. i tried dd'ing the drive with zeroes too just in case, but that didn't help.
15:51:20 <dch> markmcb: I'm about to disappear, but I would make sure you've picked the combined UEFI+BIOS install flavour, and re-try the installer
15:51:44 <dch> I *guess* they're UEFI only but I don't know for sure.
15:51:54 <dch> does it work without geli in the way?
15:52:23 <dch> worth doing a `gpart show -l` and pasting that in the channel, along with whatever ended up in /etc/fstab
15:52:51 <markmcb> dch: i'll try that. was definitely doing UEFI only.
15:53:02 <dch> also when you say its unusable after reboot, be a bit more specific,
15:53:27 <dch> e.g. does it get as far as the loader prompt, does it get stuck trying to find the root partition, etc.
15:53:46 <dch> bbl
15:53:49 <markmcb> dch: unusable as in nothing happens. bios error message appears stating no bootable devices
15:54:20 <markmcb> i have to boot from usb to do anything
15:58:04 <markmcb> and once i've booted from usb, if i drop to a shell i can't mount the efi partition created by the installer
18:07:30 <psionic> Well Idk folks new FreeBSD14 mirror just keep dieing with some signature error after 10 minutes
18:07:38 <psionic> I try to install the xfce with pkg
18:07:51 <psionic> what kind of cdn is this :/
18:08:09 <rtprio> don't paste it or anything, everyone here is telepathic
18:11:21 <meena> I am so telepathic that i can tell — without consulting any documentation or searching the Web — that rtprio is being sarcastic
18:19:56 <concrete_houses> I just cant get the volume up
18:20:14 <concrete_houses> sysctl hw.snd.vpc_0db=1 did this and trying firefox
18:20:17 <concrete_houses> hmmm
18:21:16 <jauntyd> are you using OSS?
18:22:44 <RhodiumToad> concrete_houses: why are you ignoring what I've pointed out several times
19:16:00 <KingShark> Hi. Could i somehow start the ssh-agent and load my ssh private keys automatically? I got a pair for github, i need to run 'ssh-agent -s' and 'ssh-add <path-to-key>' every time before doing git pull / push
19:17:41 <RhodiumToad> running ssh-agent automatically is the intended method; the way to do it depends on how exactly you're logging in
19:18:34 <RhodiumToad> obviously running ssh-add requires interaction to specify a passphrase if the key is encrypted
19:18:44 <meena> KingShark: https://www.freshports.org/security/keychain/ helps with that, depending on… what RhodiumToad said
19:18:45 <VimDiesel> Title: FreshPorts -- security/keychain: User-friendly front-end to ssh-agent(1)
19:19:01 <meena> I source it in my shell startup.
19:19:03 <rtprio> i wrote something little in my .profile
19:20:03 <meena> https://codeberg.org/meena/dotfiles/src/branch/main/config/fish/conf.d/keychain.fish
19:20:05 <VimDiesel> Title: dotfiles/keychain.fish at main - dotfiles - Codeberg.org
19:20:09 <rtprio> https://projects.17es.net/elliot/dotfiles/src/branch/master/.ssh_agent
19:20:12 <VimDiesel> Title: dotfiles/.ssh_agent at master - dotfiles - projects.17es.net
19:20:12 * rtprio compares
19:20:40 <meena> I really need a new profile picture. that i one is older than my daughter
19:20:43 <Freaky> https://github.com/google/cpu_features/blob/main/src/impl_x86_freebsd.c well
19:20:44 <VimDiesel> Title: cpu_features/src/impl_x86_freebsd.c at main · google/cpu_features · GitHub
19:21:40 <Freaky> who needs any of that tricky CPUID instruction assembly stuff when you can just.. parse /var/run/dmesg.boot
19:22:36 <meena> that is the second worst code I've seen all day (that wasn't written by myself)
19:29:23 <Freaky> sigh, __attribute__((target="")) only works in C++ mode in gcc
19:29:53 <Freaky> "And the C programmers likely prefer an explicit way using `__attribute__((ifunc(...)))`  so nobody really wanted to spend time implementing this for C."
19:30:08 <Freaky> no, I'd like it to work as it does in clang, thanks
19:31:06 <Freaky> I love having order of magnitude performance improvements that never get used because someone might be using a 15 year old CPU
19:41:42 <meena> Freaky: is there any way to make this code less worse
20:08:47 <Freaky> meena: I'm sure that's as pretty as CPU feature detection gets
20:09:01 <Freaky> meena: the kernel probably works it out by parsing the same file from the previous boot tbh
20:09:43 <meena> Freaky: i… i want to doubt that
20:10:13 <meena> but i would think it's present in a sysctl
20:10:16 <RhodiumToad> the kernel certainly does not do that :-)
20:10:56 <RhodiumToad> afaik it's not in any sysctl.
20:12:23 <RhodiumToad> I think apps that care about cpu features are expected to do CPUID themselves
20:13:02 <Freaky> https://github.com/Freaky/fast-bytecount/blob/addcc5468cf664d68f9a9ece3add5987f298a93f/bytecount.c#L86-L104
20:13:04 <VimDiesel> Title: fast-bytecount/bytecount.c at addcc5468cf664d68f9a9ece3add5987f298a93f · Freaky/fast-bytecount · GitHub
20:15:30 <meena> RhodiumToad: well, it's in kern.msgbuf which gives you the same thing :D
20:18:01 <RhodiumToad> it might not be in kern.msgbuf since that's of limited size
20:18:17 <dch> using lldb on a program I compiled with `-g O0`,  but it seems not to be aware of the C sources it was built from
20:19:05 <dch> i.e. can't set a breakpoint to a given line, doesn't display C source of file
20:19:39 <RhodiumToad> what exact commands were used to compile and link?
20:19:56 <RhodiumToad> does `file` say that the executable is not stripped?
20:21:21 <dch> file says its not stripped, image <name> says it has a section (not entirely sure what that means)
20:22:04 <dch> https://www.irccloud.com/pastebin/bu9HSXf1/Makefile
20:22:06 <VimDiesel> Title: Snippet | IRCCloud
20:24:46 <RhodiumToad> and you're running it in the same dir you compiled in? what clang and lldb version?
20:25:27 <dch> yup, all in the same dir, default clang/lldb from CURRENT a few days ago
20:25:45 <RhodiumToad> also there generally won't be source info for libs that come from ports
20:26:35 <dch> this isnt a port, just local hacking
20:26:48 <dch> it's like cflags isn't being used here
20:26:52 <dch> let me do this by hand
20:27:20 <RhodiumToad> so e.g. a command like  'list main'  in lldb isn't working?
20:27:23 <dch> adding `-v` to CFLAGS should show more stuff, but its still silent
20:28:56 <dch> so maybe its not even being picked up
20:29:56 <dch> oh I see why
20:30:01 <dch> stupid me
20:30:28 <RhodiumToad> ah
20:30:39 <RhodiumToad> your second CFLAGS= is clobbering the first
20:31:14 <dch> ffs thats been there since day 1 of this project
20:34:49 <dch> ok, now lets see if we has the sources... nope
20:37:25 <dch> can't set any breakpoints either
20:37:41 <RhodiumToad> does 'list main' in lldb work
20:38:08 <dch> RhodiumToad: ok, that does
20:38:20 <RhodiumToad> so what did you try that didn't work
20:38:47 <dch> so I start `lldb -- ./zen ... args`
20:38:54 <dch> source list -> nothing
20:38:59 <dch> but `list main` does
20:39:28 <RhodiumToad> before you actually run the program there's no current location to list
20:40:37 <dch> sure, but I get that result even after starting the prog
20:40:44 <RhodiumToad> starting it how?
20:41:22 <dch> https://www.irccloud.com/pastebin/Wcaw3D46/out
20:41:23 <VimDiesel> Title: Snippet | IRCCloud
20:41:30 <dch> ok so this is unexpected
20:41:44 <dch> the first `source list` is blank
20:41:56 <RhodiumToad> you're still in the startup code
20:41:59 <dch> but if I do it again, we're suddenly showing L524
20:42:10 <dch> so I guess there's some libc init stuff that I *don't* see beforehand?
20:42:19 <dch> so I should breakpoint main, run it
20:42:27 <dch> then try to set more breakpoints
20:42:39 <RhodiumToad> yes
20:42:51 <dch> TIL all the things
20:42:56 <RhodiumToad> with shared libs there's a _lot_ of work done before main
20:43:19 <RhodiumToad> since it's the rtld that's responsible for finding all the shared libs and linking them into the program
20:46:23 <dch> huh
20:47:38 <dch> there is a "gui" command in lldb
20:47:42 <dch> this is pretty nice
20:48:51 <dch> so in the end, 1 error, CFLAGS being clobbered, and 1 unexpected behaviour, need to get to main before source works
20:49:22 <dch> RhodiumToad: thanks for the rtld(1) info, I'll look at that later
20:52:54 <RhodiumToad> if you have the base system -dbg files installed, you should be able to see the ld-elf.so sources
21:14:03 <meena> Freaky: that looks suspiciously like compile time, and not run-time.
21:15:37 <dch> https://www.moritz.systems/blog/lldb-support-for-fork-and-vfork/ how convenient
21:15:38 <VimDiesel> Title: LLDB support for fork(2) and vfork(2) | Moritz Systems
21:17:46 <kevans> > posix_spawn(3) triggers events depending on the implementation. On NetBSD, it is reported as a single event. On the two other platforms, it is reported as the underlying vfork(2) and exec(3) calls.
21:17:52 <kevans> that's interesting
21:18:29 <dch> I just used it, feeling very proud of my new skillz
21:19:23 <kevans> ah, ok, I see the table now
21:43:09 <Freaky> meena: the #if's are compile-time, the __builtin_cpu_supports() are run-time
21:43:23 <meena> Freaky: aye
21:43:39 <Freaky> meena: as evidenced by the same binary working on this Zen 3 and an old K8 I have lying about
21:43:41 <meena> Freaky: consequence of me reading commits every morning: https://reviews.freebsd.org/D41920
21:43:42 <VimDiesel> Title: ⚙ D41920 local-unbound: remove stray config.h.in backup
21:43:50 <meena> basically, this is your fault.
21:48:06 <Freaky> meena: I like how 3 people were asked to review it
21:48:15 <Freaky> you know, just in case someone liked it
21:48:31 <meena> Freaky: i asked all the people who have touched that code in the last two years lol