00:03:29 <ixmpp> 'pkgconf' damn that's an annoying name, in every other os i've used it's either pkg-config or pkgconfig
00:09:45 <feurig>  tobias: did somebody point you at /boot/loader.conf?
00:10:29 <feurig> add 'boot_serial': '"YES"', 'comconsole_speed': '"115200"', and  'console': '"comconsole,
00:11:33 <feurig> I do think its odd that its not a default. Especially given that most remote management gives you access to one.
00:11:50 <feurig> but then you know if your here you're sysadmining like its 1999
00:11:54 <feurig> :)
00:15:24 <meena> feurig:  I'm pretty, and sure you can use packer / ansible / puppet / etc… to write such a loader.conf these days
00:16:20 <feurig> I actually had to look up my bootstrap freebsd ansible script for that.
00:17:02 <feurig> wait was that a damned ai?
00:17:43 <feurig> That seems like the kind of junk gpt would say.
00:18:27 <feurig> welcome to the ai spam appocolypse.
00:27:51 <feurig> but meena: you are correct the appropriate syntax would be boot_serial=yes
00:28:26 <meena> feurig: i have it with ="YES"
00:28:43 <meena> i think loader is pretty lax about the actual spelling
02:38:19 <RoyalYork> How do I report an error in a specific MAN page and a separate error in the FreeBSD Handbook?
02:39:06 <ox1eef_> https://bugs.freebsd.org/bugzilla/
02:39:07 <VimDiesel> Title: FreeBSD Bugzilla Main Page
02:39:13 <RoyalYork> Thanks
02:39:28 <ox1eef_> You can also submit the fix there if you have one.
02:59:33 <Reinhilde> HardenedBSD's version of the ports tree cannot build librsvg2-rust for HardenedBSD's version of 13-S. Is the mainline ports tree and mainline FreeBSD 13-S currently suffering the same plight, or is its librsvg2-rust building fine?
03:00:08 <Reinhilde> ("Idk mate, fire up mainline on your own PC and figure it out" is a valid answer, though one that will be met with grumbling.)
04:31:23 <ox1eef_> https://pkg-status.freebsd.org/builds?type=package - you can check there. There seems to be a few failures across the board.
05:15:40 <trev> how do you usually automatically add ssh keys to the agent? i am starting the agent in xinitrc. should i just do `ssh-add...` after that?
05:50:40 <ox1eef_> trev: In .ssh/config, where you map keys to hosts, you can add 'AddKeysToAgent yes' and when after first use they're remembered.
05:51:49 <trev> ox1eef_: nice, thank you
05:53:48 <ox1eef_> No worries.
06:07:11 <parv> There are also Control{Master,Path,Persist} options
06:12:11 <trev> under Host ?
06:12:50 <parv> Yes
06:12:54 <Lovis_IX> hello folks, upgrade to 13.2-RELEASE done. Is it me or not? It seem faster.
06:15:00 <Lovis_IX> trev: you can also put it before any host to make it available for all the hosts.
06:15:52 <parv> A small portion of ~/.ssh/config : https://termbin.com/1fqp
06:22:16 * parv has long forgotten the derivation of sum-of-n-numbers formula
06:23:23 <parv> Sorry, wrong channe;
07:35:11 <yourfate> I'm trying to have a freebsd server of mine compile a new rpi64 image for my rpi4 which uses ZFS for the rootfs. I've found this article: https://wiki.freebsd.org/arm/Build_image_using_release_building_infrastructure
07:35:13 <VimDiesel> Title: arm/Build_image_using_release_building_infrastructure - FreeBSD Wiki
07:35:36 <yourfate> now i'm looking at /usr/src/release/arm64/RPI.conf, but i have so far not found where the file system setup magic for the SD card happens
08:00:31 <eoli3n> Hi
08:00:57 <eoli3n> syncthing package on latest freebsd has known bug, which produces a lot of sync conflicts
08:01:27 <eoli3n> i sent a mail to the maintainer but he seems not available
08:01:43 <eoli3n> does anybody have the ability to upgrade the package ?
08:01:53 <eoli3n> 13.1 latest
08:02:03 <eoli3n> the problematic syncthing version is 1.22.0
08:07:50 <RypPn> The way to sanity is to file a bug... https://www.freebsd.org/support/bugreports/
08:07:52 <VimDiesel> Title: Bug Reports | The FreeBSD Project
08:14:06 <eoli3n> ok, thanks
08:57:39 <meena> if you send an email to an unresponsive maintainer, you have sent an email to an unresponsive maintainer. if you create a bug report at least there's something you and other people can refer to
11:55:37 <debdrup> specifically, the maintiner timeout only starts from when the bug is filed, because the bug being filed is how the project keeps track of maintainer timeouts.
12:26:58 <rubin55> Hey all, running 12.4, uptodate, I'm seeing regular all-core cpu spikes on a process called zfskern. I don't use zfs; what can I do to make this go away?
12:35:19 <debdrup> zfskern is the light weight process/thread in the kernel, but it shouldn't be present unless you've loaded the zfs kernel module, so check if you've done that with `kldstat -vv`, unload with kldunload(8), and remove it from wherever it's being loaded.
12:44:02 <rubin55> I'm definitely not loading it explicitly (i.e., in /boot/loader.conf)
12:44:25 <rubin55> I can blacklist zfs.ko? but I wonder why I'd need to go to such measures
12:47:02 <nimaje> you don't have  zfs_enable="YES"  in your /etc/rc.conf for some reason?
12:54:55 <rubin55> No, I just discovered something mad.. MAD
12:55:04 <rubin55> I am using 'btop'
12:55:40 <rubin55> When I start btop it actually (indirectly? why? no zfs used! only ufs!) loads the zfs module
12:56:34 <rubin55> That sounds highly strange to me, why and how could btop decide to just load a kernel module?!
12:56:35 <debdrup> just use top in the freebsd base system
12:56:38 <debdrup> it's much better
12:57:04 <rubin55> I like btop. Should I file a bug for this?
12:57:17 <debdrup> not with freebsd.
12:57:22 <rubin55> obviously.
12:57:28 <rubin55> I'll have a look upstream
12:58:03 <dkeav> a utility like a top modifying kernel modules o.0 thats not great
12:58:19 <debdrup> it's actively hostile.
12:58:41 <debdrup> it either means it requires suid or to be run as root, both of which shouldn't be necessary
12:59:14 <debdrup> the only thing that should require root for something like top is renicing it to -20 in situations where a system is so bogged down, even rendering top is gonna be a huge task
12:59:30 <debdrup> (which is what top -q does)
13:04:13 <dkeav> yea something like that just willingly jamming kernel modules in could easily be used for malicious purposes
13:04:20 <dkeav> do not want
13:05:23 <rubin55> https://github.com/aristocratos/btop/issues/515
13:05:26 <VimDiesel> Title: [BUG] btop loading zfs kernel module on FreeBSD, even when no filesystems with ZFS exist · Issue #515 · aristocratos/btop · GitHub
13:05:26 <VimDiesel> 515 – Info command has no tutorial https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=515
13:06:35 <rubin55> I suspect he's doing some hackery to be able to show details about zfs filesystems. Agreed, should not just load kernel modules, that's madness
13:08:08 <nimaje> can you try with  zpool list -H -o name  https://github.com/aristocratos/btop/blob/main/src/freebsd/btop_collect.cpp#L539
13:08:09 <VimDiesel> Title: btop/btop_collect.cpp at main · aristocratos/btop · GitHub
13:10:06 <debdrup> rubin55: you mean the details included in freebsds top, without the need to load kernel modules if they're not present?
13:11:20 <debdrup> it also doesn't look like btop understands freebsds vm classes, so you're losing out on a bunch of fairly relevant information
13:12:00 <rubin55> What are "vm classes"?
13:12:15 <debdrup> https://wiki.freebsd.org/Memory
13:12:16 <VimDiesel> Title: Memory - FreeBSD Wiki
13:19:53 <nimaje> maybe https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256147 but there it seems to be zpool itself using one cpu core fully
13:19:56 <VimDiesel> Title: 256147 – zpool list -P causes high cpu load while using ufs
13:21:46 <nimaje> but one would hope that  zpool list  exits when zfs.ko is not loaded and not load it itself
13:34:19 <debdrup> I don't have a system without ZFS to test on, but I can't think how zpool list can load the module if it's not run as a privileged user.
13:39:51 <msiism> I'm trying to script unmounting all of the file systems I have mounted to /media/$LOGNAME. But somehow, umount(8) isn't able to work with that: http://paste.debian.net/plainh/18cbdef6
13:57:00 <rubin55> nimaje: no, it (zpool list) causes zfs.ko to be loaded, also on a system without zfs mountpoints and/or modules_blacklist=zfs in loader.conf
13:57:51 <rubin55> I noticed mainly because at load, zfskern seems to spike for about 10? seconds on all cores (i.e., 100% cpu usage)
14:01:17 <nimaje> ok, then that is a freebsd bug (I think only zpool import has a valid reason to load zfs.ko, but maybe more in any case not list and get), but how can it even do that? it needs a privileged user for that as debdrup already pointed out
14:05:14 <titou> hey, is there an alternative to synth or poudriere in order to compile multiple packags?
14:05:22 <titou> (good alternative)
14:17:28 <rubin55> nimaje: well, in my case, I'm running btop as root, which in turn seems to unconditionally execute a zpool list (for which I filed a bug upstream at the btop repository). In such a case, zpool list would run with enough privileges to do the kldload. I would just not expect it to do so I guess (I would expect it to error out because zfs interface is not available in the kernel)
14:19:17 <nimaje> I consider it a bug that it does and that it has enough privileges doesn't really matter
14:20:11 <msiism> Okay, I've found the problem: `umount /dev/da0p1 /dev/da1s1 ` breaks because of a trailing space.
14:20:39 <msiism> That's not supposed to happen, is it?
14:21:44 <msiism> With only one argument supplied, umount does ignore trailing whitespace.
14:22:58 <rubin55> nimaje: shall I file a bug (bugs.freebsd.org)?
14:23:10 <nimaje> yes
14:23:18 <msiism> Oh, wait, it just didn't work again, and no trailing space involved…
14:23:26 <CrtxReavr> umount probably doesn't care, but the shell may be doing something wierd with it.
14:24:00 <msiism> Okay, let me use /bin/sh.
14:24:06 <CrtxReavr> 'Course. . . I'm not sure why you're running umount against a device. . . normally you'd run it against a mount point.
14:24:28 <msiism> I'm doing that because the names are predictable.
14:24:53 <CrtxReavr> And your mount point isn't?
14:25:11 <msiism> In the sense that they are not freely choosable, not user input that could contain spaces, newlines, etc.
14:26:24 <CrtxReavr> Why not script something that grabs the mountpoint?
14:26:39 <msiism> Because the moinpoint is not a constant.
14:27:08 <CrtxReavr> Exactly my point.
14:27:35 <msiism> My script works like this: qmnt <device> <label>. And things will be mounted to /media/$LOGNAME/<label>.
14:27:44 <msiism> That label could be anything.
14:28:15 <CrtxReavr> mount_point = $(mount -p | grep <device> | awk '{print $2}')
14:28:16 <msiism> I don't want the script to break because of a weird directory name.
14:29:24 <neirac> is there a way to search using pkg which package contains a file, not just the currently installed packages, the use case is that I don't know which package to install to fix a dependency
14:29:48 <msiism> CrtxReavr: Well, yeah, the script does grab all the lines from `mount` that have `/media/$LOGNAME/` dir as their mountpoint prefix.
14:30:41 <msiism> But it does not rely on those names for unmounting because I see no way to safeguard that against weird directory names.
14:30:45 <CrtxReavr> neirac, yes. . . though I don't remember the syntax offhand.
14:31:19 <nimaje> neirac: pkg provides (you have to install pkg-provides first, no idea if it needs any more setup)
14:32:00 <neirac> nimaje awesome thanks!
14:32:08 <msiism> Okay, /bin/sh has the same problem.
14:32:10 <nimaje> msiism: and if your mountpoints (or even the label) contains a newline?
14:32:35 <nimaje> what shell did you try?
14:32:40 <msiism> Yeah, the way I do it, this won't be a problem.
14:32:53 <msiism> FreeBSD's /bin/sh and Bash.
14:33:14 <nimaje> newlines will likely break your grep and cut
14:34:02 <msiism> Well, the mountpoint prefix that I grep for is constant.
14:34:24 <msiism> And then I cut the first field from the line, which is always the device name followed by a space.
14:34:40 <nimaje> (mount doesn't seem to have libxo support :()
14:34:51 <msiism> And there are no funny characters in device names.
14:35:02 <CrtxReavr> neirac,
14:35:03 <CrtxReavr> $ pkg which /usr/local/bin/screen
14:35:03 <CrtxReavr> /usr/local/bin/screen was installed by package screen-4.9.0_6
14:35:21 <nimaje> CrtxReavr: not installed packages
14:35:48 <debdrup> pkg which `which binary` is always a fun command to run
14:35:59 <rubin55> nimaje: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270789
14:36:02 <VimDiesel> Title: 270789 – zpool list loads zfs.ko, even on systems that don't use zfs
14:36:25 <CrtxReavr> Wroks for non-executables too:
14:36:26 <CrtxReavr> $ pkg which /usr/local/share/cows/jkh.cow
14:36:26 <CrtxReavr> /usr/local/share/cows/jkh.cow was installed by package cowsay-3.04_2
14:36:37 <msiism> Though, the actual question now is: Why is `umount` not able to handle more than one device name now and then?
14:37:06 <CrtxReavr> msiism, then iterate over a list of devices. . . this isn't that hard.
14:37:07 <nimaje> rubin55: neither irc nor bugzilla are twitter
14:37:21 <rubin55> you mean because of the @?
14:37:42 <msiism> CrtxReavr: You mean like `for t in $target; do…`?
14:37:51 <nimaje> yes, put it at the end if anywhere
14:37:58 <rubin55> lol sure
14:38:25 <CrtxReavr> for t in thing ; do umount $t ; done
14:38:33 <msiism> Right.
14:38:35 <CrtxReavr> You just gotta figure out where you're getting "thing"
14:38:48 <msiism> I already got that sorted.
14:39:36 <msiism> Still, I wonder what causes this behavior in umount.
14:40:06 <CrtxReavr> I'm pretty sure if you read the manpage, you'll see it was never designed to umount more than one thing at once.
14:40:18 <CrtxReavr> Sometimes unix gives you lots of rope to hang yourself with.
14:40:31 <CrtxReavr> Sometimes, it tires to keep a little sanity.
14:41:07 <msiism> Well, the synopsis says otherwise. But reading the whole thing might offer a different picture.
14:42:13 <CrtxReavr> Maybe look at the `umount -F` option.
14:42:47 <CrtxReavr> Build yourself a /tmp/usr.fstab file, then run `umount -F /tmp/usr.fstab`
14:43:01 <msiism> Okay, I will.
14:43:37 <CrtxReavr> mount -p | grep whatevs > /tmp/usr.fstab
14:44:11 <CrtxReavr> (mount -p produces syntax in /etc/fstab format.)
14:44:52 <msiism> oh
14:45:01 <msiism> Well, I see what you mean now.
14:45:13 <msiism> I guess, I'll just go with the for loop, though.
14:45:25 <nimaje> CrtxReavr: for me pkg which says "… was not found in the database" for stuff that is not installed (did you maybe have cowsay-3.04_2 installed at some point in time?)
14:45:52 <CrtxReavr> You might even get away with some fancy shit like: mount -p | grep whatevs | umount -F -
14:46:34 <CrtxReavr> nimaje, yes. . .  it's only going to show you info on what pkg installed. . . you can't expect it to tell you things about random shit you installed by hand.
14:47:12 <CrtxReavr> And yes, I do have cowsay installed. . .
14:47:24 <CrtxReavr> Don't make me start piping cowsay into the channel!
14:48:18 <CrtxReavr>  /ex figlet debdrup? | cowsay -n -f jkh
14:48:42 <nimaje> ah, you wrote non-executables there, the question was still about stuff that isn't installed
14:49:01 <debdrup> I put on my wizards hat and robe.
14:49:17 <debdrup> I really don't see why you had to hilight me there.
14:49:17 <mason> heh
14:49:19 <CrtxReavr> debdrup, a classic!
14:49:42 <mason> (order's reversed, but whatver)
14:50:38 <CrtxReavr> https://trioptimum.com/~crtxreavr/cybersex.txt
14:50:38 <debdrup> How is SysV banner different from BSD banner, though?
14:51:01 <debdrup> Nope, not clicking that link.
14:51:16 <CrtxReavr> Just the text of that thing you quoted.
14:51:59 <mason> CrtxReavr: Canonical link, will put people off less: http://bash.org/?104383
14:52:00 <VimDiesel> Title: QDB: Quote #104383
14:52:37 <CrtxReavr> mason, that's just a small portion of it though.
14:52:50 <mason> Oh? Interesting. It's all I've ever seen.
14:53:27 <CrtxReavr> I used to hang in an EFnet channel with the bash.org guys. . . in its heyday, they auto-rejected about 80% of submissions at random, 'cause there was no way they could field them all.
14:53:47 <mason> Wow, there's a bunch more. Thanks for sharing it. Heh.
14:54:09 <CrtxReavr> When that first came out, it was funny AF.
14:54:39 <mason> Gah, bits of it are horrid. I think I see why I've only ever seen the subset. :P
14:55:03 <CrtxReavr> You take that bake!
14:55:06 <CrtxReavr> back
15:01:29 <moonshine> bake
15:02:23 <debdrup> a mojibake?
15:44:52 <Beladona> Thunar cannor remember list/icon/detail layout display settings. Got message: Cannot spawn a message bus without a machine-id: Unable to load /var/local/lib/dbus/machine-id or /etc/machine-id: Failed to open file “/var/local/lib/dbus/machine-id”: No such file or directory
16:05:22 <CrtxReavr> nimaje, I just grocked what you meant by not installed. ..
16:05:41 <CrtxReavr> If you have a ports tree installed/downloaded, you an do like: for i in /usr/ports/*/*/pkg-plist ; do grep -H screen $i ; done
16:06:39 <CrtxReavr> 'Course, if you have a ports tree installed, you can also do: cd /usr/ports && make search key=foo
16:06:46 <CrtxReavr> or make search name=bar
16:09:56 <nimaje> CrtxReavr: some stuff isn't listed in a pkg-plist file in the ports tree and sometimes that stuff gets even generated automatically (e.g. (most?) py- ports)
16:10:59 <rani> hi, i am having some issues with xorg
16:11:17 <CrtxReavr> nimaje, like which, for instance?
16:11:37 <rani> it's refusing to start with nv/modesetting drivers (the other drivers work but they don't have the correct screen resolution and i don't have the ablity to change that)
16:12:42 <CrtxReavr> rani, been a while since I ran a FreeBSD workstation/laptop.
16:13:50 <CrtxReavr> I'd use the nvidia binary blob drivers, kldload those. . . then run something like: sudo xorg -configure > /tmp/xorg.conf
16:13:52 <nimaje> stuff listed in PLIST_FILES, e.g. math/glucose has  PLIST_FILES= bin/glucose bin/glucose-syrup
16:14:08 <CrtxReavr> Usually had to hand edit that file a little but, then move it into /etc/X11/xorg.conf
16:14:21 <CrtxReavr> Then test with startx
16:14:47 <CrtxReavr> Once satisfied, I'd finish setting up login manager, window manager/environment, etc.
16:15:19 <rani> the proprietary nvidia driver requires me to install an old version of xorg since my gPU is ancient
16:15:52 <rani> the main issue i'm having I think is that nv states that a kernel module is already claiming my GPU, although I don't see anything that would be doing this
16:17:33 <CrtxReavr> pastebin your /var/run/dmesg.boot and the output of pciconf -lv
16:17:44 <CrtxReavr> Oh - no gui.
16:18:13 <CrtxReavr> alias tb='ncat termbin.com 9999'
16:18:39 <CrtxReavr> Then: cat /var/run/dmesg.boot | tb
16:18:46 <CrtxReavr> pciconf -lv | tb
16:19:09 <yo9fah> Hi all
16:19:18 <CrtxReavr> (Yah, you'll need to have ncat installed.
16:19:19 <CrtxReavr> )
16:19:48 <last1> is it possible to just download/fetch a package without installing it ?
16:19:57 <CrtxReavr> nimaje, I dable in python myself. . . and very much not a fan of how we handle py-* ports/packages. ..
16:20:18 <CrtxReavr> We should better leverage pip
16:20:45 <CrtxReavr> I have ideas on how to handle that. . . I need to bring them up up with some ports developers I know.
16:21:02 <CrtxReavr> last1, sure.
16:21:03 <rani> this is dmesg: http://0x0.st/HXnF.txt
16:21:50 <rani> this is pciconf: http://0x0.st/HXnC.txt
16:22:40 <ElectricJozin> I am trying to code a simple utility that will get the CWD of a process, (I dont want to use any high level lib like procstat or sysctl) so my plan is: get struct kinfo_proc *processes from kvm_getprocs
16:22:40 <ElectricJozin> get struct kinfo_file by using kinfo_getfile(PID, kfiles) which returns all open file descriptors
16:22:40 <ElectricJozin> check if kinfo_file.kd_fd == KF_FD_TYPE_CWD
16:22:40 <ElectricJozin> if yes then read kinfo_file -> kf_un -> kf_file -> kf_file_fileid, to get INODE number
16:22:40 <ElectricJozin> Convert INODE number into file (somehow)
16:22:42 <ElectricJozin> . Is this the "optimal" way to do it?
16:23:37 <CrtxReavr> rani, kldstat
16:25:02 <rani> http://0x0.st/HX5r.txt
16:25:17 <CrtxReavr> ElectricJozin, you might want to ask that kinda question in #bsdcode on EFnet.
16:25:47 <ElectricJozin> CrtxReavr, Ok thanks
16:26:21 <ElectricJozin> Problem is I cant connec t to EFnet for some reason
16:26:41 <CrtxReavr> ElectricJozin, actually - you could try #freebsd-dev on here too I suppose.
16:27:23 <CrtxReavr> Seems more of the oldskool devs are on EFnet th ough.
16:28:33 <ElectricJozin> EfNET has a invalid ssl certificate, thats why it wasnt working
16:28:53 <CrtxReavr> last1, I think what you're looking for is: pkg fetch <package name>
16:29:17 <CrtxReavr> Um. ..
16:29:48 <CrtxReavr> irc.efnet.org:6667 shoudl work in clear text.
16:30:52 <rani> this xorg thing is very annoying
16:31:03 <rani> modesetting doesn't work either but that's because no drm support
16:31:09 <rani> i have no idea why nv is mad though
16:31:30 <CrtxReavr> "mode setting" isnt' a driver.
16:31:33 <CrtxReavr> What driver have you tried?
16:31:49 <rani> xcfb & vesa work, modesetting & nv do not
16:32:03 <rani> scfb*
16:32:36 <CrtxReavr> Try one of these: nvidia-driver-304/ nvidia-driver-340/ nvidia-driver-390/ nvidia-driver-470/
16:32:49 <rani> the proprietary driver (304) requires an old version of xorg
16:33:32 <rani> i tried compiling from ports but it failed at the patching phase and i didn't really feel like manually patching xorg
16:33:36 <CrtxReavr> Try a newer one then.
16:33:48 <rani> the newer ones aren't compatible with my GPU
16:34:12 <CrtxReavr> Stickwith VESA then.
16:34:23 * CrtxReavr shrugs.
16:35:10 <rani> ugh vesa resolution caps out too low
16:35:17 <rani> xorg sucks
16:41:20 <CrtxReavr> heheh
16:41:29 <CrtxReavr> That's not xorg. . . that's VESA.
16:42:03 <CrtxReavr> Try your scfb (whatever the fuck that is) then. .
16:42:08 <CrtxReavr> then try xorg -configure
16:44:58 <ElectricJozin> CrtxReavr, Do you know of any other populous BSD IRC's?
16:45:26 <CrtxReavr> I think you've found 'em.
16:45:57 <CrtxReavr> You're aware that lsof has been ported?
16:57:37 <ElectricJozin> CrtxReavr, yes and I used their source code
16:57:42 <ElectricJozin> But this is a first for me
16:58:31 <ElectricJozin> I couldnt really find where some of the definitions were coming from and it all just got kind of confusing
16:59:06 <ElectricJozin> and if you meant: Why dont I use lsof, is because where is the fun in that
17:02:50 <skered> There's also checkrestart which I think does a better job.
17:06:13 <CrtxReavr> ElectricJozin, the upstream lsof code, or the post-patch port code?
17:06:58 <CrtxReavr> Hmm - maybe we dont' patch it that much.
17:07:30 <ElectricJozin> yep the upstream contains a lib->dialect->freebsd directory
17:08:55 <ElectricJozin> where most of the important stuff happens once the function the function process_file_descriptors is called
17:43:15 <meena> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270789 this is a cool bug
17:43:17 <VimDiesel> Title: 270789 – zpool list loads zfs.ko, even on systems that don't use zfs
17:47:19 <parv> Watch out for ZFS "block_cloning" option in -CURRENT: https://lists.freebsd.org/archives/freebsd-current/2023-April/003440.html
17:47:21 <VimDiesel> Title: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing)
17:52:00 <nimaje> ah, yeah, for  zpool create  loading zfs.ko is fine too
18:48:15 <ElectricJozin> Where should I push ports patches?
18:48:25 <ElectricJozin> Or should I email the maintainer with the diff patch
18:48:33 <meena> nimaje: I see no issue https://github.com/openzfs/zfs/issues here yet
18:48:34 <VimDiesel> Title: Issues · openzfs/zfs · GitHub
18:49:00 <meena> ElectricJozin: open a bugzilla bug with origin/port:
18:49:05 <meka> ElectricJozin, bugs.freebsd.org
18:49:17 <ElectricJozin> its not a bug its a simple change
18:49:56 * CrtxReavr much preferred the workflow of filing a bug with an attached patch, vs. the whole github/PR routine.
18:50:11 <ElectricJozin> Ok, then
18:50:17 <debdrup> You can still use bugzilla.
18:50:58 <meka> ElectricJozin, it's not only for bugs, but the name does suggest otherwise. It's for tracking changes and some of them are bugs :o)
18:51:57 <meena> if a maintainer goes missing, we won't know you've been mailing them diffs. but bugzilla will
18:52:24 <debdrup> https://docs.freebsd.org/en/articles/problem-reports/ has a good description of how things work when they work best.
18:52:25 <VimDiesel> Title: Writing FreeBSD Problem Reports | FreeBSD Documentation Portal
18:52:28 <ElectricJozin> ok and for example if I were to patch a base system dependency like sysctl
18:53:10 <ElectricJozin> Under the system there is no way to highlight the command at question
18:53:56 <ElectricJozin> soo.... git?
18:54:03 <debdrup> https://bugs.freebsd.org/bugzilla/describecomponents.cgi?product=Base%20System describes the components
18:54:05 <VimDiesel> Title: Components for Base System
18:54:22 <debdrup> patches to sysctl would go in the bin component
18:54:48 <ElectricJozin> Right ok
18:54:51 <ElectricJozin> Thanks
19:01:59 <debdrup> as a follow-up to the thing parv posted, https://github.com/openzfs/zfs/pull/14739/
19:02:01 <VimDiesel> Title: Fix data corruption when cloning embedded blocks. by pjd · Pull Request #14739 · openzfs/zfs · GitHub
19:44:35 <meena> exciting stuff here, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270796
19:44:37 <VimDiesel> Title: 270796 – [exp-run] Enable -Warray-parameter for clang
19:44:53 <meena> debdrup: nice! i was wondering how long that's gonna take…
20:53:04 <dvl> Brand new url parsing code now in FreshPorts. Please report any oddities. https://bsd.network/web/@dvl/110187747070886865
20:53:08 <VimDiesel> Title: Dan Langille: "New URL parsing code into FreshPorts soon. Major …" - BSD Network