hi all

x

What determines the default value of PORT_OPTIONS in general and PORT_OPTIONS:MSYSTEM_SCREENRC in particular?

When I run grep for MSYSTEM_SCREENRC in my ports tree only the check for it in Makefile turns up.

|cos|: M isn't part of the option name, it's a make variable modifier

default options are determined by OPTIONS_DEFAULT in the port's makefile: docs.freebsd.org/en/books/porters-h…andbook/makefiles/#makefile-options

ivy: Ah. Got it! Thanks! I had that exact page open, but sometimes one needs to ask to be able to understand.

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?

Dunno if I just started a disruptive art project or if bugs.freebsd.org/288214 will practically only be ignored.

|cos|: this seems to have been reported less than a day ago?

Remilia: another report or the linked one? the linked one i just posted, yes.

the one you linked

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?

my reports with port version updates usually took 1-8 weeks

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.

they all use screen

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)

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

switched to tmux instead

found a fun 15.0 bug: ifconfig bridge0 create; ifconfig bridge0.100 create; ifconfig bridge0 addm bridge0.100

(bug as in kernel panic, don't try it)

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)

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

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. :)

you've got some weird dreams, my dude

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

(he's dreaming about windows admin and malfunctioning printers..)

jmnbtslsQE: Sounds more like a nightmare to me.

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

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