freebsd-update fetch | awk 'NF>1{print $NF}'

bitblt: there is a freebsd-ports channel

I assume there is no legitimate reason for Xorg to be resident for more than a gigabyte?

MelMalik: your desktop enviroment software selection for sure :)

badkat, did you just gloss over the word «legitimate»

I could see Xorg being resident for slightly more memory based on my decision to use or not use a certain programme, but that memory should be released when I stop using said programme (be it mpv, firefox, or anything else).

afaik, memory usage of Xorg depends on your screen resolution too

I remember many years ago running the old fglrx driver on Linux, and that made the Xorg process leak quite a bit of memory on my system

the usage gradually kept rising and never went down

do I remember you

also: that just tells us that the problem is prolonged, not that it's not a problem

hi folks! i installed a game and noticed the version was outdated (port doesn't have a maintainer), so i downloaded the latest version straight from github and built it with a few minor changes, what do i do now? do i sumbit a PR where i explain everything i did or do i try to modify the port by myself and the ask for a merge somehow? (I have no idea what I'm doing)

benjamino: perhaps have a look through docs.freebsd.org/en/books/porters-handbook/upgrading

ivy: thank you! i'll read it at once!

If you have successfully got the game going, perhaps consider becoming the port maintainer: docs.freebsd.org/en/articles/contributing/#ports-contributing

if you use the port yourself, you may also consider becoming its maintainer by editing MAINTAINER= in the makefile, but that isn't required to submit an update

What's that Plex replacement people are implementing?

CrtxReavr: Jellyfin for video and Navidrome for audio here

both are well maintained in ports (navidrome wasn't for a while but it has a maintainer now)

ahh - Jellyfin is the one I think was mentioned.

Thanks.

/usr/bin/cd annoys me every time i am reminded that it exists

that's really sad

heartbreaking, really

o_O

is there a way to permanently protect(1) daemons from rc.conf?

WTF even is that?

It doesn't even seem to work.

CrtxReavr: it "works" in that it changes the directory, then immediately exits, so it does nothing. it only exists because it's required by POSIX

phryk, you could probably follow the example of what you find when you look at: grep protect /etc/defaults/rc.conf

CrtxReavr: well, that cd script starts a shell, cds in that shell and then exits that shell, seems really useful

# This file is in the public domain.

Well, thank goodness for that.

wait, where does posix requires an executable cd? I only know about the shell built-in cd being required by posix

nimaje, there's gotta be some legacy kruft reason for it.

I can't say I've noticed that before.

CrtxReavr: oh neat, thanks for pointing out the obvious. seems like it's not a thing specifically implemented in rc.d/syslogd either. :)

Though. .. /usr/bin/[ generally bothers people more.

nimaje: there's some requirement that all the shell builtins have to be available as actual commands, i don't remember where off hand

phryk, it is useful to always remember that /etc/defaults/rc.conf is there.

CrtxReavr: yeah, every 3-4 years i stumble over /etc/defaults but then forget about it again ^^;

well, i've been looking for inspiration for a new tattoo, so… 🤔

CrtxReavr: well, [ is usually not a shell built

ivy: found it, but cd is excluded as it is an intrinsic (at least in posix 2024) pubs.opengroup.org/onlinepubs/97999…/utilities/V3_chap01.html#tag_18_07

interesting, i wonder if that changed at some point, i would love to get rid of these

(last time i asked i was told we can't, but that was a while ago)

sometimes doing the right thing gets in the way of posix compliance

mhh, i'm getting "protect: option requires an argument -- p" when trying to start services with _oomprotect="YES". but not reliably reproducable…

i have one service where it always happens. had 2 other ones where it just disappeared without further changes to rc.conf when restarting the service a second time.

the service where it always happens also has "service foo status" reporting it's not running, even tho the .pid file exists and points to the correct pid that's running.

okay, these issues seem to be independent. get the same issue with status claiming the service ain't running when i remove the _oomprotect and restart…

Mhh, the package wasn't in my poudriere package list and is still an ancient build with py39 flavor. Gonna ignore it for now and see if it resolves itself when I got a py311 build.

can i get ps or some other tool to show process flags in a *human readable* form?

phryk: ps has libxo support

phryk: try ps --libxo=json -auxw

er, you can probably drop the w

habit :)

ps --libxo=json -o flags 91843

{"process-information": {"process": [{"flags":"10100100"}]}}

oh, you asked for **human readable**

that's even less human-readable if anything^^

oops

in that case, ps auxwww should do?

unless by process flags you mean something differently than what i'm assuming it means

oh, you mean -o flags, i really should read. in my defence, it's really hot here :|

:P

i really thought procstat(1) would be able to do this, but it cannot

or at least if it can i cannot find it in the manual page

i never really understood why there's ps *and* procstat in the first place tbh. is this some historical thing like apt/aptitude/apt-get on debian?^^

procstat can do more things, it's more like a debugging utility than a system management thing like ps

also ps is kind of terrible

like, even allowing for the two completely different option syntaxes, the way the options interact with each other just makes no sense

phryk: i can't really find a way to print them in human-readable form through the man page and a skim through the code, sorry :(

dstolfa: no problem – thanks for looking into it and confirming it. :)

mhh, is there really no way to use procctl in a jail? would like to use *_oomprotect for a few services in there.

i assume i could protect those by using jail_oomprotect="ALL" on the host, but that would cast a much wider net and as poudriere jails are the only reason the oomkiller is ever triggered, i'm not sure if that isn't just a recipe for an immediate deadlock.

how do i split a make(1) variable definition over multiple lines without it inserting a space after each backslash?

ivy: Can you be more specific about what you're trying to accomplish? How are you attempting this now?

% printf 'FOO=bar\\\nbaz\n' | make -VFOO -f -

bar baz

i want the output to be "barbaz"

(the reason it's "bar baz" is that make(1) inserts a space after a line continuation using backslash)

dstolfa, FYI, auxwww does nothing different than auxww - no more than two w are recognized.

Is there a reason you can't printf simply "barbaz" instead of including the \\'s and \n's?

CrtxReavr: It was so ingrained in me to use "auxwww" over the years, I still find myself using it. Have to re-learn not to use the 3rd "w".

ivy: Is "printf 'FOO=barbaz' | make -VFOO -f -" not going to work?

ek: for context, reviews.freebsd.org/D50150 - i solved this another way but it would be neater if there was a way to do it directly in make

ivy: Ah. Gotcha'. Hrm... That does make it a little more intricate. Can't just pipe to sed or something to remove the whitespace.

ek, trying to save the world 10 ms at a time.

Well, I suppose you could, but you're looking for "cleaner"

Yep.

i think just fudging it in the lua is neater than using sed :-)

Yeah. I'm trying to fudge it via regex but I can't, for the life of me, think of a "clean" way to replace "\\\n" with a non-whitespace while still needing "\\\n" (or a replacement.)

To be fair, "printf 'FOO=bar\\\nbaz\n' | make -VFOO -f -" Isn't terribly readable or clean anyway. Running "printf 'FOO=bar\\\nbaz\n' | make -VFOO -f - | sed 's# ##'" wouldn't make much of a difference.

well, yeah, but we're not actually using printf here, that was just the shortest method to demonstrate the make behaviour i was trying to solve

Right. I see the code in there. That's what I'm trying to adhere to. I'm not sure what a cleaner way would be to remove that whitespace while following that same syntax for that for loop.

About EOL software link above.. I type this from EOL software.. Hexchat, lol. Yet to find suitable replacement :|

nullsector: Yep. For a desktop/GUI IRC client, Hexchat still works just dandy. Shame they haven't continued to maintain it (much.)

I'd imagine here in the next couple or so years, it'll start to choke due to GTK updates and such. Another end of an era.

May The Forth be with you. . . always.

CrtxReavr: May the 4th be with you!

may 7th next ethereum hardfork $>:)|--^<

is anyone here is using only keepassxc secrets provider integration in D-Bus?

maybe some hint to migrate th gnomekeyring to this one? :P