00:02 <beerman> i feel like both commands have their place, I would rather have the docs spell it out for people more. runscripts is a bit different imo, but not too much. It could suffice with just a more clear warning about it in the docs - provided people read that. But its almost safe to say that you want scripts to run, and if not, you probably have read the manual and have a very special use case at hand

00:07 <farkuhar> Speaking of docs that people might not read, I recently noticed that the handbook says pkgadd.conf only supports UPGRADE directives, but people reading the manpage will learn something different.

00:13 <beerman> yeah there is a lot to do alright.

00:33 <jaeger> I would rather remove depinst entirely and make install do what depinst did. I see no reason to preserve the original install command

00:41 <farkuhar> jaeger: makes sense. Dropping support for `prt-get install` will mess with some people's muscle memory, but if the change takes place abruptly, they'll adapt soon enough.

00:48 <jaeger> Could leave the depinst command in as a transitional thing but tell people to use install instead over time

00:51 <beerman> if we plan to ditch it i'd just make it print "use install instead, this function will be removed" or w/e

00:52 <farkuhar> Or just keep supporting depinst but don't document it, like how bsdtar still accepts --lzip even though the manpage only mentions --lzma and --lzop.

00:54 <farkuhar> That way we don't mess with the muscle memory of any veteran users, but we don't confuse newbies with multiple commands that have the same target.

01:01 <beerman> i meant in addition to "do what it does" until it doesn't

01:02 <beerman> "fair warning" kind of thing

01:02 <beerman> it's fair to assume it will be around for at least a year between major CRUX updates

07:44 <jue> wrt depinst/install: if we do it like suggested we should have an option for install to _not_ install dependencies at all, I use install sometimes to reduce the number of installed ports if not all deps are really needed

07:44 <jue> not having such an option isn't CRUX like IMO

09:24 <beerman> agreed

11:02 <farkuhar> jue: "if not all deps are really needed" then the maintainer should have listed them as "Optional" or soft dependencies. Are there actually so many ports with erroneous hard dependency lists, that you find it necessary for `prt-get install` to behave as it does now?

11:07 <farkuhar> Besides, the current behaviour of `prt-get install` can be replicated by pkgmk and pkgadd. The change Matt proposes wouldn't restrict your freedom to _not_ install dependencies, it just makes that option less accessible from the convenience of prt-get.

11:15 <beerman> and thats a problem ;)

13:05 <farkuhar> http://ix.io/3Vr4 is one attempt at implementing Matt's proposal. It merges the depinst and install commands using argparser.cpp, but leaves in place the (now-unreachable) execution path of main.cpp line 86 (case ArgParser::INSTALL).

14:15 <beerman> i took the liberty to push pkgutils 5.40.9 to 3.7

17:29 <beerman> another day another python build system... for crying out loud

17:45 <beerman> jaeger: you use wine a lot, I just try something out and had to struggle with limits.conf being applied until I found the pam module - should we include it at least as a comment in the session file maybe? Would make it easier to spot if you never had to do it

17:45 <beerman> wine because it was never a problem until lutris forced me to up my nofile limit

17:47 <beerman> https://i.imgur.com/6RiPSbP.png btw: battle.net launcher looking promising on wayland? looks like it 8-)

19:19 <jaeger> I'm not quite understanding what you're asking for here... a new pam file or adding a comment to common-session?

19:21 <beerman> https://github.com/lutris/docs/blob/master/HowToEsync.md

19:22 <beerman> lutris will ask you to setup this before it will start battle.net, but this guide is not fully making it clear what to do. you need pam_limits.so in your session to be able to actually use whatever you configure in limits.conf, so it would be a new line in common-session, yes.

19:23 <beerman> its in neither wine ports README and it took me a minute to question what authority pam might have with it

19:24 <beerman> session required pam_limits.so does the trick

19:52 <groovy2shoes> i've had to do that for another game with lutris, too. i think it was Fallout.

19:54 <groovy2shoes> i imagine it wants to enable esync for most if not all games that run in wine

19:56 <farkuhar> beerman: it's interesting that your work on the Pipewire wiki never required you to mess with limits.conf. One of the cited references in your Wiki article was the Arch pipewire guide, where limits.conf is mentioned as a workaround to the warning "... consider increasing RLIMIT_MEMLOCK"

19:58 <beerman> lol.. maybe I did that and it didn't work but pipewire wasn't noisy as in REFUSES TO START without it and I never actually knew till now. ;)

22:49 <jaeger> So you mean that if you set nofile in /etc/security/limits.conf it doesn't take effect unless you also have the line in common-session?

23:05 <jaeger> ok, re-reading your comments I think that's the case

23:06 <beerman> yep thats the case :D

23:21 <jaeger> so lilo is definitely going away for 3.7? Everyone ok with that?

23:28 <beerman> i asked a few times, never heard anybody (that would maintain it) say no - from my understanding it was broken and/or unmaintained? I dropped that a while ago

23:29 <jaeger> Yeah, as far as I know it is unmaintained... I don't mind if it goes but I suspect some people may be surprised by it

23:32 <beerman> true, would make sense to mention that with the release notes