09:04:09 hi all 09:22:39 x 14:09:01 <|cos|> What determines the default value of PORT_OPTIONS in general and PORT_OPTIONS:MSYSTEM_SCREENRC in particular? 14:10:05 <|cos|> When I run grep for MSYSTEM_SCREENRC in my ports tree only the check for it in Makefile turns up. 14:21:04 |cos|: M isn't part of the option name, it's a make variable modifier 14:22:03 default options are determined by OPTIONS_DEFAULT in the port's makefile: https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-options 14:28:47 <|cos|> ivy: Ah. Got it! Thanks! I had that exact page open, but sometimes one needs to ask to be able to understand. 15:04:37 my thinkpad has a elantech touchpad, libinput show it as such and so does my wayland vm, but just like mousedin tty, it does not work. Any ideas of where to start or should I just do a bug report? 15:11:09 <|cos|> Dunno if I just started a disruptive art project or if https://bugs.freebsd.org/288214 will practically only be ignored. 15:31:03 |cos|: this seems to have been reported less than a day ago? 15:35:16 <|cos|> Remilia: another report or the linked one? the linked one i just posted, yes. 15:35:28 the one you linked 15:36:02 I'm unsure if there's a policy for maintainers to respond to reports within an hour but you could wait a day or two and see? 15:36:33 my reports with port version updates usually took 1-8 weeks 15:41:06 <|cos|> my fear is that the suggested fix is too pragmatic, and was hoping someone smarter than me would suggest a better path forward. i believe there are more people on this channel than the ports maintainers. 15:42:31 they all use screen 15:51:24 fwiw i'm not very fond of this sort of non-default config files anyway, but i wonder if existing screen users will complain it's gone (although presumably it will still be installed as a .sample file) 15:58:08 I stopped using screen in 2010 I think since it was driving me mad with 'segmentation fault, core dumped' when attaching to a session if my terminal size did not match exactly what it was when I detached 15:58:55 switched to tmux instead 15:59:12 found a fun 15.0 bug: ifconfig bridge0 create; ifconfig bridge0.100 create; ifconfig bridge0 addm bridge0.100 15:59:22 (bug as in kernel panic, don't try it) 16:03:00 <|cos|> I did start trying to patch screen sources to bring back functionality as documented, but realized that would be quite a project and gave up. Hence the more pragmatic approach. (and yeah noone loves screen, but tmux is a compliment not a replacement) 17:18:47 Yes! Now, after several weeks of googling, experimenting and struggling, I could finally set up my system so that it boots into an unencrypted dataset from which I can unlock an encrypted dataset in the same pool, mount it, and do "reboot -r" into it. After finding a post in a forum (which bookmark I can't find), I learned that the error messages about devd and the /dev directory in the encrypted 17:18:49 dataset during reroot could be because I had set canmount=on instead of canmount=noauto on my two root datasets, which would make the system trying to mount both datasets at the same mountpoint (/). Finally, I dream came true. :) 17:30:35 you've got some weird dreams, my dude 17:41:50 meanwhile, our colleague rtprio is dreaming about, let's see.....wow OK..not sure if it's allowed to talk about that on IRC ;-P 17:45:17 (he's dreaming about windows admin and malfunctioning printers..) 17:47:33 jmnbtslsQE: Sounds more like a nightmare to me. 18:05:36 just updated to 14.3, as well as all ports and lost graphic on the i915 and was greeted with a nice vga classic terminal only. removed drm-61 and went with drm-515. Not a big issue, haven't done any troubleshooting yet 23:22:51 did you reinstall drm-kmod in the upgrade process? as a kernel module it needs to much the kernel and drm uses some KBIs that aren't stable on a -STABLE branch afaik