00:43:25 Clarification: Wayland already is entirely ready for regular desktop usage. It is not yet ported to be ready for regular (simple, stable) desktop usage on any BSD operating system; FreeBSD has the most of the bunch. 00:44:07 (No comment about any of this being good, bad, etc. -- just a clarification) 03:09:22 cjs: there are some folks showing off hyprland screenshots in the FreeBSD Discord 03:09:40 It looks slick 08:32:19 i used wayland (via sway, on amdgpu) on freebsd 15.0 for a few months and had no issues, it seemed very stable 08:35:33 <[tj]> Isaac from rivervm is contracting at the foundation 10:03:20 finally, a useful Kerberos implementation in base: https://cgit.freebsd.org/src/commit/?id=7f2fe78b9dd5f51c821d771b63d2e096f6fd49e9 10:34:23 dmesg 'linux: jid 0 pid 96821 (***): syscall arch_prctl not implemented', can you make dmesg ignores it? 10:57:34 how should I do so I can close my lid and still use my external monitor, as it is now, when I close the lid it´s going to sleep mode, but I still want that functionality.. 11:26:47 nwe: try sysctl hw.acpi.lid_switch_state=NONE 11:27:33 regis: then I need to change it each time I dont have external monitor plugged in right? 11:27:53 I can't test it now and it's a default setting iirc so it should work like that out-of-the box though. 11:28:20 nwe: nah, /etc/sysctl.conf 11:29:08 nwe: But honestly, I'm not sure if it'll work and can't test it at the moment. 11:52:08 regis: ended up with devd and script, and set hw.acpi.lid_switch_state=NONE 11:59:01 https://pastebin.com/jZdCuT7P 12:07:31 i am not finding much useful documentation on using blacklistd + postfix... i want to blacklist SMTP clients which are listed in RBLs or attempt relaying, how/where do i configure this? 12:09:12 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284444 suggests this might just work by default 12:10:09 I use Postscreen for that 12:10:32 i use postscreen as well, but how do i configure it? does it just work magically? 12:11:26 I have the following: https://gist.github.com/silenius/e84f3f83a818af8bcda3a0142d1d016d 12:12:20 mage: and this make postscreen add addresses to blacklistd? i don't see any blacklist-specific configuration there so i assume it does just work by default 12:13:04 no, I don't use blacklistd as I have HAProxy in front and blacklistd doesn't work with remote hosts 12:14:16 blacklistd is pretty useless as it works with socket files only 12:16:07 so i have this in maillog: Jun 5 12:13:29 fuchsia postfix/postscreen[34966]: DNSBL rank 4 for [80.94.92.152]:50674 12:16:18 which is higher than postscreen_dnsbl_threshold (2), but blacklistctl dump does not show an entry for it 12:17:48 ah, i wonder if this is because i run smtpd in a chroot 12:18:56 probably 12:26:46 there we go, with blacklistd_flags="-s /var/spool/postfix/var/run/blacklistd.sock" it works 12:29:45 +1 on mage postscreen approach. I'm happy to share my postscreen settings and RBLS which work for me 12:30:13 i already use postscreen, my question is how to make postscreen talk to blacklistd 12:30:37 and the answer is indeed "it works by default", but only if you manually create the socket in the postscreen chroot 12:31:02 which does not seem to be documented anywhere, but i'm also not sure where it could reasonably be documented... 12:31:22 ivy: https://sysartist.com/tmp/postscreen.txt 12:31:56 ivy: What would you use blacklistd for? I understand some kind of abuse like brute-force or bots? 12:32:26 regis: to drop connections from hosts which attempt to repeatedly connect, to avoid spamming maillog and creating unnecessary load on RBL servers 12:34:06 ivy: I really only needed to do it on shared hosting (and we also had to implement web panel option for people to whitelist themselves in case they got blocked after unsuccessful dovecot login auth attempts etc) but I seriously don't bother fith blacklistsd or fail2ban on my private MTA. You do you of couse. 12:45:39 regis: blacklistd is a bit faster than fail2ban, it can break connection upon failure, but software support is very limited 12:55:14 mzar: I'm not arguing around blacklistd/fail2ban comparison but just asked if any of these is really needed. That being said, I have little experience with blacklistd and never had issues with fail2ban's performance on environments like shared hosting - blocking addresses after several IMAP or SSH auth failures, bots scanning websites for vulns and getting given number of 404 responses during some 12:55:16 timespan, etc 12:57:51 I am sorry, I didn't follow 12:58:11 it's not "really needed" since postscreen will drop these connections anyway, but it avoids generating 10MB+ of /var/log/maillog per day on a system that processes < 500 actual emails per day, which wastes CPU cycles and makes it harder to notice actual issues 13:21:54 huh, when did abuseat.org get swallowed by spamhaus? 14:04:26 lines missing? always need plain? https://imgur.com/9RY3pcA 14:13:55 If creating a little utility, should I be storing state in /var/db/ or /usr/local/var/db/ ? 14:16:46 tk: /usr/local/var/db/ is nonexistent 14:17:13 Sure, but I can create it. 14:17:45 I assume you mean to imply that its non-existence suggests everything should be using /var/db regardless of whether it's installed to /bin or /usr/local/bin ? 14:18:23 tk: I don't know, can't judge, but never seen /usr/local/var/db/ 14:18:23 <|cos|> tk: /opt/tk-rulez/, but make the path easily configurable in case your utility ever gets included in FreeBSD or ports? 14:19:29 I doubt anyone will ever include my utility in anything. Would it be /opt///var/db then? 14:19:39 <|cos|> typically the buildsystem resolves $PREFIX or something to /usr, /usr/local or whatever floats your boat 14:20:36 The question is not where to put the binaries, I already understand the idea behind /opt and /usr and /usr/local, I was asking specifically about "database" type of data 14:20:45 tk: /var/db/ looks reasonable with regard to anothe db 14:22:41 tk: don't use /opt, that's an SVR4 thing, BSD doesn't use it. don't use /usr/local/var, ports specifically recommends against this because /usr/local is not meant to contain volatile data. use /var/db/ which is the standard path for this. 14:22:57 thanks ivy 14:23:11 Yes. I agree with: /var/db/ 14:23:12 security/krb5 puts its data in /usr/local/var but this is wrong and it shouldn't do that 14:23:26 <|cos|> Since its personal software on personal systems, the question really becomes what you desires to achieve? 14:24:08 also even *if* you want to use /opt, you don't use /opt/myprogram/var/db, you use /opt/myprogram/bin, /etc/opt/myprogram and /var/opt/myprogram 14:24:38 but again this is SVR4, not BSD 14:29:48 <|cos|> ek: You've read `man hier`. I'm uncertain if it answers your question. 14:30:04 <|cos|> ek: sorry. tk was the intended recipient. 14:30:29 Yeah I think hier(7) combined with what ivy said seems to answer what I needed 14:34:15 |cos|: All good! 15:20:30 ivy: [tj]: Well, it is great to know that the next -RELEASE will have some daily driver ready Wayland :) 15:24:34 That will make FreeBSD the first of the BSDs to have Wayland for someone who is not trying to write code for Wayland. 15:25:09 er, is there actually anything specific to 15 for Wayland? wouldn't really think so 15:25:15 -/20 15:25:43 not that i'm aware of, other than having a newer drm version 15:26:15 i was mainly responding to the person who said Wayland won't be stable for 10 years, which seems... inaccurate 15:49:12 adrian: are you going to land D50111 or do you want me to nag kevans for approval and do it myself? 15:49:21 er, wrong channel 16:23:55 ivy: Have you ad issues with "never drm" versions? 16:24:00 s/ad/had/ 16:25:14 regis: i don't know what "never drm" means 16:25:44 ivy: Apologies - s/never/newer/ 16:26:29 ivy: quoting you. I refer to: not that i'm aware of, other than having a newer drm version 16:27:18 regis: ah. the reason i mentioned that was that 15.0 has newer versions of drm-kmod than stable/release versions. so it's possible someone using 14.x might have encountered problems that i didn't. 16:27:45 i have no idea about specific versions of drm-kmod and i'm not currently using freebsd on desktop 16:28:24 ivy: Got it. I switched from 14-CURRENT directly to 15-CURRENT. 16:30:33 That being said, drm-kmot is a port and you can you can switch to 'latest' (HEAD) ports on 14. 16:30:40 s/kmot/kmod/ 16:30:57 yes, but the 14.x "latest" version is older than the 15.0 "latest" version 16:31:14 the port makefile contains conditional code to build an older version on 14.x since it's missing KBI features that are in 15.0 16:31:33 (mostly related to LinuxKBI, aiui) 16:31:47 ivy: Are drm-kmod and amdgpu from HEAD working differently on 14? 16:32:04 regis: they don't "work differently" but they are different versions of amdgpu 16:32:24 By HEAD here, I mean latest ports and compiling from ports, not pulling pkg. 16:33:08 each new release of drm-XX-kmod typically requires new features from the Linux kernel being added to LinuxKBI, and those features are added in -CURRENT first, so it's typicaly that e.g. 15.0 has drm-66-kmod while 14.x only has drm-55-kmod, or whatever 16:33:32 ('66' and '55' are made up version numbers, but you get the idea) 16:33:33 ivy: Ports HEAD is the same for release/stable and current iirc. 16:33:45 no, you're misunderstanding my point 16:33:52 lol 16:34:15 'drm-kmod' is a meta-port that depends on a specific port which is called drm-XX-kmod, where 'XX' is the version of the Linux kernel the drivers were taken from 16:34:39 ivy: Ah, so you mean that 14 is missing some linux features from linuxkbi to make this stuff work. Got it. 16:34:41 the metaport almost always chooses a higher 'XX' (Linux kernel version) for 15.0 than it does for 14.x 16:35:14 this means people using drm-kmod on 14.x have an older version of the DRM drivers than people on 15.0, even if they're both using drm-kmod from the ports main branch 16:35:31 ivy: I know what drm-kmod is. I was pulling it from github and testing different branches based on different Linux kernel versions before it was merged to ports. 16:36:09 regis: ok, then perhaps you weren't aware that this changed when the driver was added to ports. i'm not insulting you, i'm trying to explain why people on 14.x have an older version of the DRM drivers. 16:37:49 ivy: Thanks. I was under the impression that since you can install it on 15 from ports, you could do it on 14 from HEAD ports as well. 16:38:15 that is true, you can install drm-kmod on both 14.x and 15.0. however, on 14.x, you will get an older version of the drm-XX-kmod driver. 16:38:47 because drm-kmod is a metapackage which depends on the specific version of drm-XX-kmod for the version of freebsd it was built for 16:39:11 But the 'specific version' is the same from HEAD ports for 14 and 15 16:39:35 no, it's not 16:39:44 Unless there are some Makefile if/or 16:40:00 please look at graphics/drm-kmod/Makefile to understand this 16:40:49 https://cgit.freebsd.org/ports/tree/graphics/drm-kmod/Makefile 16:41:31 right now, freebsd 15.0 gets drm-66-kmod, while 14.x gets drm-61-kmod 16:42:08 unless you're on arm64 or i386 in which case you only get drm-510-kmod... 16:42:20 ivy: OK, I understand that there some established defaults. But have you tried: git clone https://github.com/freebsd/drm-kmod; cd drm-kmod; branch -a and compiling from different branches? 16:43:03 these are not "defaults", this is the *only* supported drm-XX-kmod version on each release 16:43:33 regis: do that, give it a shot, then have a look at the code and see why it fails ;) 16:43:36 ivy: clone above repo, git checkout origin/6.6-lts 16:43:39 unless you have an example of a 14.x system running drm-66-kmod, which i would certainly be interested in 16:44:22 ivy: I have a TON of builds going, but I could try drm-66-kmod build with a pourdriere 14.2-RELEASE jail for lolz 16:44:28 SponiX: I'm the one suggesting, not the one requiring a hint ;) 16:44:40 SponiX: i recommend not wasting time to respond to someone on IRC, but it's up to you :-) 16:45:03 ivy: but I think even if it did manage to build properly it would likely kernel panic when it attempts to load 16:45:43 this discussion is fairly bizarre tbh, anyone who's actually used drm-kmod on freebsd is aware that newer freebsd versions have newer drm-kmod versions 16:45:44 regis: I'm on the old "try it and see" stance 16:45:53 i'm not sure why someone would try to argue this is not true, other than trolling 16:47:04 SponiX: Sure but I thought that you directed your comment not the right person. You wrote "give it it a shot" to me when I'm a guy here, telling someone how to do something. 16:47:54 ivy: You got your hints. Work on them. 16:48:01 lol 16:49:31 ivy: Not that I like responding to "lol" but tl;dr: pull the official repo and compile this fucking thing from proper branch on your 14 16:50:12 O my 16:53:54 root@bareMetalFreeBSD:/usr/ports # poudriere testport -j 142amd64 -p latest graphics/drm-66-kmod 16:54:33 =================================================== 16:54:33 ===== env: DEVELOPER_MODE=yes DEVELOPER=1 STRICT_DEPENDS=yes USER=nobody UID=65534 GID=65534 16:54:33 ===> drm-66-kmod-6.6.25.1402000_3 not supported on older than 1500031, no 16:54:33 kernel support. 16:54:33 *** Error code 1 16:54:46 It literally says to "check your sanity" lol 16:55:01 OK, my mistake. I was unaware of this. 16:55:03 SponiX: this person is obviously trolling, i suggest /ignore ... 16:55:05 ivy: you are correct, it for sure will not build 16:55:37 ivy: Its okay, I'm new to FreeBSD, and don't mind the extra time to confirm ;) 17:13:48 mason: have you seen this? https://github.com/openzfs/zfs/pull/17340 -- apparently, they may have actually fixed the long-standing data corruption bug in ZFS native encryption 17:26:50 I stated that I switched direction from 14 CURRENT to 15 CURRENT. Sucks to be called a troll. 17:41:58 Yeah, its okay to just not know something. It happens 17:42:46 I've been doing Linux since roughly 1995. And only recently got into FreeBSD. So the "try it and see" was my honest recommendation. I wasn't trying to be an ass or anything 17:43:41 That does remind me though, I probably need to make another bectl snapshot in case I do jack up my OS 17:46:11 ivy: I haven't. Reading now - thanks! It would be extremely convenient for native encryption to be reliable. 17:46:38 mason: right? although aiui, they aren't quite sure why this actually fixes the problem. but apparently it does 17:54:48 ivy: Yeah, the commentary near the end makes me think I want to wait to see the test suite updated, a reliable root cause identified, and then for some time to pass with people happily encrypting away before I migrate. 17:56:21 this also doesn't change that they continued to ship ZFS encryption for years with a known data corruption bug and felt no need to informs users about it 17:56:33 apparently i am being told off in another channel for going on about this, but i find this very concerning 17:57:01 Oh? =looks= 17:57:34 anything related to data corruption should be taken seriously 18:12:02 the last episode of 2.5 Admins seemed to give it a decent explanation (the ZFS encryption bug/fix on raw sends) 18:36:27 finally got around to opening an issue for my weird poudriere bug: https://github.com/freebsd/poudriere/issues/1225 19:20:53 ivy: might not be needed, but your jail OS version isn't filled out on that post 19:32:18 SponiX: yeah i wasn't sure what to put there 19:32:33 the poudriere jail is the same version as the host 19:37:02 also filed my first BIND bug: https://gitlab.isc.org/isc-projects/bind9/-/issues/5361 19:37:05 apparently today is bug day 20:00:12 > the poudriere jail is the same version as the host 20:00:15 version of? 20:37:03 regis: Version of the host. 15.0-CURRENT 22:30:24 how's 14.3 RC1 looking? 22:48:13 things seem to be going smoothly 23:00:15 nice