=== Eickmeyer[w] is now known as Eickmeyer
[02:10] <KGB-2> gnome-shell Daniel van Vugt 303653 * commented merge request !59 * https://deb.li/3laSh
[05:30] <jibel> Good morning 
[05:37] <oSoMoN> good morning desktoppers
[05:37] <jpnurmi> good morning jibel and oSoMoN
[05:38] <oSoMoN> hey jpnurmi 
[05:38] <oSoMoN> salut jibel 
[05:53] <duflu> Hi jibel, oSoMoN, jpnurmi 
[05:53] <oSoMoN> hey duflu 
[05:53] <jpnurmi> hey duflu
[07:10] <didrocks> good morning
[07:13] <duflu> Hi didrocks 
[07:14] <didrocks> hey duflu 
[07:23] <jibel> Salut didrocks 
[07:25] <didrocks> salut jibel 
[07:41] <Nafallo> morning from rainy gothenburg
[07:45] <duflu> Hi Nafallo 
[08:06] <ricotz> good morning desktopers! :)
[08:06] <didrocks> hey ricotz 
[08:06] <oSoMoN> good morning didrocks, Nafallo, ricotz 
[08:07] <didrocks> salut oSoMoN 
[08:07] <didrocks> tjaalton: mesa recommends mesa-amber, but I see no MIR for it?
[08:08] <didrocks> should it be dowgraded to suggests or do you want to file a MIR?
[08:08] <tjaalton> bug 1967086
[08:08] <ubottu> Bug 1967086 in mesa-amber (Ubuntu) "MIR: mesa-amber" [Undecided, New] https://launchpad.net/bugs/1967086
[08:08] <didrocks> ah, I see bug #1967086, was not picked up in the diagram, feel free to ignore me :)
[08:13] <duflu> tjaalton, will amber override crocus?
[08:13] <duflu> Hi ricotz 
[08:13] <tjaalton> duflu: no
[08:14] <duflu> Also great to see i915 will live on at least for jammy. So finally the software support should outlive the hardware
[08:15] <tjaalton> I'm fine making it Suggests
[08:15] <tjaalton> just the tradeoff is that the image won't have native dri driver for old hw then
[08:15] <tjaalton> also, I think Debian would have it Recommends anyway
[08:16] <duflu> That would be mostly really old Intel systems that need i915_dri: "Intel Core" branded systems and the original Atoms. They do exist so I would prefer they keep working or else where will be bug reports
[08:16] <tjaalton> r200 too
[08:16] <duflu> Because owners of those were logging bugs last year
[08:17] <tjaalton> and some nouveau
[08:17] <duflu> Forget nouveau. It causes more problems than it solves :(
[08:17] <tjaalton> those have no alternative
[08:18] <duflu> Fair enough
[08:18] <tjaalton> neither do many that mesa supports
[08:20] <duflu> The problem with not shipping those drivers is that such systems (Core Duo, Atoms) are really too slow to be usable on software rendering. So those systems might not get installed to the point of asking for support and being told to install amber
[08:22] <didrocks> tjaalton: I need to look at the MIR, but it should be fine, just being a rename
[08:23] <tjaalton> didrocks: right
[08:23] <tjaalton> thanks
[08:23] <didrocks> thanks for the feedback :)
[08:25] <seb128> hey didrocks Nafallo duflu ricotz tjaalton oSoMoN, how are you? had a nice weekend?
[08:27] <oSoMoN> Salut seb128! Week-end was good, I had some rest on Saturday as I was exhausted from the week, and spent all of Sunday gardening. How was your week-end?
[08:27] <duflu> seb128, an unfortunate series of events prevented me from getting enough sleep, but otherwise it was good. Friends and family
[08:28] <seb128> oSoMoN, it was alright, I managed to get some rest as well, though not as much as I would have liked. Also winter is back, I had already gotten used to the nice weather we had a week ago...
[08:30] <oSoMoN> yeah, the cold is back here too, we even had 2 minutes of snow yesterday, but it melted before even reaching the ground
[08:30] <oSoMoN> the forecast says temperatures will dramatically increase through the week though, we'll see…
[08:31] <seb128> duflu, sounds like busy but positive weeked at least and hopefully the week is quiet and you can catch up on sleep
[11:04] <rbasak> I'm finding this new theme in Jammy quite difficult. When I upgraded to a previous release (I forget which one exactly) the contrast between active and inactive title bars went down and I couldn't tell at a glance if a window was active without specifically comparing the title bars with other windows. But I noticed that only the active window had the title bar buttons in orange. So I started 
[11:05] <rbasak> looking for that. But now, that's gone, and so there's no immediately obvious cue for me to tell if a window is active just by looking at it.
[11:05] <rbasak> It's basically just on comparing greys. And I can't differentiate the absolute level of grey just by looking at it.
=== alan_g_ is now known as alan_g
[11:46] <seb128> rbasak, would be nice if you could report that as a bug on https://bugs.launchpad.net/ubuntu/+source/yaru-theme/+filebug , the yaru team is active but they are not on IRC
[12:02] <jbicha> good morning
[12:06] <bittin> afternoon
[12:08] <seb128> jbicha, bittin, hey, how are you? had a nice weekend?
[12:08] <bittin> not really, having headache/cold but hopefully i feel better soon, just installed the 22.04 Beta however and ran apt updates to get the updates until 3th April and worked good
[12:10] <jbicha> yeah, weekend went ok here 🙂
[12:12] <seb128> bittin, great! (for the beta and upgrade, not the headache and cold :-()
[12:25] <rbasak> seb128: thank you for the pointer! I filed https://bugs.launchpad.net/ubuntu/+source/yaru-theme/+bug/1967747
[12:25] <ubottu> Launchpad bug 1967747 in yaru-theme (Ubuntu) "Lack of visual distinction between active and inactive windows" [Undecided, New]
[12:28] <seb128> rbasak, thanks!
[12:29] <rbasak> It didn't occur to me that the bug tracker would be useful to raise this kind of thing!
[12:29] <rbasak> So thank you for pointing that out
[13:08] <seb128> jbicha, could you try to update paprefs? we need 1.2 to be compatible with the new pulseaudio it seems
[13:10] <jbicha> ok
[13:12] <ahasenack> hi #desktop,
[13:13] <ahasenack> samba 4.15.x dropped "-l" for "net usershare add", the short option, now it must be "--long": net:
[13:13] <ahasenack> -l is not available for --long anymore
[13:13] <ahasenack> the command that nautilus uses to share a folder is using -l regrettably
[13:13] <ahasenack> and now it fails
[13:13] <ahasenack> root@nsn7:~# net usershare add -l Public /home/andreas/Public somecomment Everyone:R,andreas:F guest_ok=y
[13:13] <ahasenack> [2022/04/04 10:00:33, 0] ../../lib/util/debug.c:1100(reopen_one_log)
[13:13] <ahasenack>   reopen_one_log: Unable to open new log file 'Public/log.net': No such file or directory
[13:13] <ahasenack> see how it's interpreting it as some log file parameter
[13:13] <ahasenack> with --long it works
[13:14] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1967245 was filed, I'm about to reassign it to nautilus, I was just checking the code out to see how easy it's to change
[13:14] <ubottu> Launchpad bug 1967245 in samba (Ubuntu) "'net usershare' returned error 255 on jammy-desktop-amd64" [Undecided, New]
[13:14] <ahasenack> hm, I don't see it in nautilus, even though that was the parent process of the "net usershare" command. Must be some library
[13:14] <seb128> ahasenack, hey, thanks, the source is nautilus-share 
[13:14] <ahasenack> aha
[13:16] <ahasenack> might be just this: src/shares.c:	argv[1] = "-l";
[13:16] <seb128> ahasenack, probably yes
[13:19] <ahasenack> seb128: do you know if nautilus-share is in https://gitlab.gnome.org ? I can't find it atm
[13:19] <ahasenack> if you also have to search, n/m then, I can continue
[13:19] <seb128> ahasenack, it's at https://gitlab.gnome.org/Archive/nautilus-share but archived so read only and you can't propose fixes
[13:19] <ahasenack> just if you happen to have it from the top of your head
[13:20] <seb128> just upload your fix to ubuntu
[13:20] <seb128> or maybe talk to jbicha about getting it in Debian
[13:20] <ahasenack> ok, I was checking if upstream had fixed it already
[13:20] <ahasenack> is this app dead-ish upstream?
[13:21] <seb128> yes, that's why it was archived
[13:21] <seb128> if you test your change we can add it to Debian and sync back the update
[13:22] <seb128> I need to step out for a bit but I will read the backlog once back and other should be to help you more if needed
[13:22] <jbicha> it's not a Debian GNOME package so we'll push the nautilus-share update to jammy first & I can work on upstreaming to Debian later
[13:26] <ahasenack> k
[13:32] <ahasenack> jbicha: https://code.launchpad.net/~ahasenack/ubuntu/+source/nautilus-share/+git/nautilus-share/+merge/418382
[13:32] <ahasenack> ppa building
[13:46] <ahasenack> jbicha: it worked, but I had to logout/login back again
[13:46] <jbicha> ok
[13:46] <ahasenack> expected I guess, since it's an extension (.so)
[13:47] <ahasenack> good to upload?
[13:48] <jbicha> yes, are you able to do the upload?
[13:48] <ahasenack> yes
[13:49] <ahasenack> done
[14:41] <seb128> jbicha, oh, sorry for the noise, I though it was a pkg-gnome one
[14:42] <seb128> ahasenack, thanks for the fix !
[14:42] <ahasenack> \o/
[14:59] <KGB-2> gedit-plugins pristine-tar d155503 Jeremy Bicha gedit-plugins_42.0.orig.tar.xz.delta gedit-plugins_42.0.orig.tar.xz.id * pristine-tar data for gedit-plugins_42.0.orig.tar.xz * https://deb.li/VKP7
[15:57] <juliank> seb128: Do you know (anyone who knows) if there's any work  going on to have gnome-shell pop up a notification if systemd-oomd killed an app? Currently it's a bit unexpected to some users :)
[15:58] <juliank> We got a bug basically saying "app was killed but system was not in swap hell with everything stuttering", which I find hilarious
[16:01] <ddstreet> you mean lp:#1966381? oomd definitely doesn't look like it's ready to be enabled by default, imho
[16:01] <ubottu> Launchpad bug 1966381 in systemd (Ubuntu Jammy) "applications crash that never crashed under Ubuntu-20.04" [High, New] https://launchpad.net/bugs/1966381
[16:04] <juliank> ddstreet: no it does exactly the right thing, preventing swap hell
[16:04] <ddstreet> juliank well no, it doesn't
[16:04] <juliank> ddstreet: it used 90% of RAM _AND_ 90% of swap
[16:04] <ddstreet> that's its intention, yes
[16:05] <juliank> ddstreet: That means it was about to enter swap hell
[16:05] <ddstreet> no it does not, actually
[16:06] <juliank> ddstreet: it means user had 100 MB of swap left
[16:06] <juliank> ddstreet: unrelated to the limit discussion, it seems the page cache issue is a bit overlooked and probably should be a separate bug?
[16:07] <juliank> ddstreet: Because I expect it to trigger when "available" in free falls below 10%
[16:07] <juliank> not "free"
[16:07] <juliank> in any case
[16:07] <juliank> > no sign of the "staggering" you normally get when the OS is heavily into swap.
[16:07] <juliank> this is precisely what we want
[16:07] <seb128> juliank, we don't have numbers of ram usage in those reports do we?
[16:08] <seb128> juliank, also is the 1G of swap by design, should we revisit to be higher?
[16:08] <juliank> seb128: It's 1GB by design, it's a performance optimization to make the kernel allocate memory faster, vs having no swap
[16:09] <seb128> an optimization that might not play nicely with the oomd logic?
[16:09] <juliank> The swap isn't really there for classic swap overcommitment use
[16:09] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638788 (build i386) stage: build, status: created
[16:09] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638787 (build) stage: build, status: created
[16:09] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638790 (test-build-any) stage: test, status: created
[16:09] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638791 (test-build-all) stage: test, status: created
[16:09] <juliank> it works fine IMO
[16:09] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638792 (test-crossbuild-arm64) stage: test, status: created
[16:09] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638793 (reprotest) stage: test, status: created
[16:09] <KGB-2> xdg-desktop-portal-gnome pipeline Jeremy Bicha 365470 * pending (reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; extract-source: pending; build i386: created; piuparts: created; blhc: created; autopkgtest: created; lintian: created; build: created)
[16:09] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638794 (lintian) stage: test, status: created
[16:09] <seb128> those reports suggest that it's confusing users and triggering in situation where the system usually didn't struggle
[16:09] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638797 (piuparts) stage: test, status: created
[16:10] <KGB-2> xdg-desktop-portal-gnome pipeline Jeremy Bicha 365470 * running (extract-source: running; reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; build i386: created; piuparts: created; blhc: created; autopkgtest: created; lintian: created; build: created)
[16:10] <juliank> not considering the issue where the page cache is being counted
[16:10] <juliank> seb128: I believe that's ddcache's issue with page cache being counted as used memory rather than available
[16:10] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638786 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 33 seconds
[16:10] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638789 (build source) stage: build, status: pending
[16:11] <seb128> juliank, sounds like a rls issue to me
[16:11] <juliank> seb128: but also you want to trigger oomd *before* the system struggles, that's the whole point of it
[16:11] <juliank> so that your system is not in swap hell
[16:11] <seb128> I feel like we are going to get users and PR slashback if the new LTS is seen as randomly killing applications on systems that users don't perceive as under load
[16:12] <seb128> juliank, well, those users have 16G memory and said they never had the system struggling
[16:13] <juliank> seb128: they should perceive that as "phew, oomd safed me from having to hard reset my system"
[16:13] <juliank> seb128: they were using 15.95 GB of their RAM and 925 MB of their swap file
[16:13] <juliank> seb128: they were struggling
[16:13] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638792 (test-crossbuild-arm64) stage: test, status: pending
[16:13] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638791 (test-build-all) stage: test, status: pending
[16:13] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638794 (lintian) stage: test, status: pending
[16:14] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638795 (autopkgtest) stage: test, status: pending
[16:14] <juliank> there was 50MB RAM left and 75MB swap when oomd first kicked in in the bug report
[16:14] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638791 (test-build-all) stage: test, status: running. Duration: no time
[16:14] <seb128> juliank, do we have record of those numbers or are you assuming from the logic?
[16:14] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638792 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[16:14] <juliank> seb128: It says right in the bug log
[16:14] <juliank>  due to memory used (15940579328) / total (16153944064) and swap used (925564928) / total (1023406080) being more than 90.00%
[16:14] <juliank>  due to memory used (15591993344) / total (16149745664) and swap used (927760384) / total (1023406080) being more than 90.00%
[16:14] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638796 (blhc) stage: test, status: running. Duration: no time
[16:14] <juliank> that was 2nd kill
[16:15] <juliank> something something GB vs GiB
[16:15] <seb128> juliank, and do we have any idea how much page cache is counting for?
[16:15] <KGB-0> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638792 (test-crossbuild-arm64) stage: test, status: failed. Duration: 2 minutes and 3 seconds
[16:16] <juliank> we don't but mine is at 9GB right now after 3 days with 24 GB of RAM
[16:16] <juliank> so you can see it's like half my memory is used for caching purposes
[16:16] <seb128> how do you check that number?
[16:17] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638793 (reprotest) stage: test, status: success. Duration: 3 minutes and 8 seconds
[16:17] <seb128> on my system from top
[16:17] <seb128> MiB Mem :  15695,8 total,   5501,8 libr,   2589,5 util,   7604,5 tamp/cache
[16:17] <seb128> with 6 hours uptime
[16:17] <seb128> if that's those 7.6G that's making quite a difference
[16:17] <seb128> should we retitle the report to focus on that part?
[16:18] <KGB-2> GNOME / xdg-desktop-portal-gnome builds Jeremy Bicha * Build #2638797 (piuparts) stage: test, status: success. Duration: 4 minutes and 19 seconds
[16:18] <KGB-0> xdg-desktop-portal-gnome pipeline Jeremy Bicha 365470 * [8 minutes and 52 seconds] failed (piuparts: success; reprotest: success; test-build-any: success; autopkgtest: success; test-crossbuild-arm64: failed; lintian: failed; test-build-all: success; blhc: success; build: success; build i386: success; build source: success; extract-source: success)
[16:19] <juliank> seb128: check your oomctl what that says on memory use
[16:19] <juliank> so mine says Current Memory Usage: 10.5G
[16:19] <juliank> ah no
[16:19] <juliank> Memory: Used: 21.3G Total: 23.3G
[16:19] <juliank> for MiB Mem :  23937,4 total,   2051,0 free,  12448,1 used,   9438,3 buff/cache
[16:19] <schopin> FYI the free(1) command might be more appropriate to check the state of your memory :)
[16:19] <juliank> schopin: harder to paste though
[16:20] <juliank> so yes, eek, it should report the "used" figure there and not total-free
[16:20] <schopin> hmm, true.
[16:20] <juliank> or used + 0.5 * buff/cache or something
[16:20] <juliank> as you do want to prevent all page cache being purged for memory use, otherwise you enter swap hell?
[16:21] <seb128> schopin, juliank, I would appreciate if foundations could taget it for 22.04 because I feel like we have an issue that might trigger some users heat at release time otherwise
[16:22] <seb128> plan B would be to remove systemd-oomd from the default install again
[16:22] <seb128> @kenvandine, ^ opinion? 
[16:22] <juliank> seb128: that'S work for enr0n 
[16:23] <juliank> seb128: enr0n: I believe in https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/src/oom/oomd-util.c?h=ubuntu-jammy&id=771fee9e73316c92e065e93946ec64c578b43706#n406, MemFree needs to be changed to MemAvailable and then we're good
[16:25] <juliank> ddstreet: ^ agreed?
[16:26] <ddstreet> juliank sorry i'm chairing another mtg, hard to pay attention here too
[16:26] <enr0n> juliank: looking
[16:26] <schopin> I'm surprised nobody raised this upstream?!
[16:26] <juliank> probably worth doing so
[16:27] <seb128> schopin, it's probably because other distros that use it have a much higher swap space than us by default
[16:28] <seb128> like fedora apparently creates 16G when we do 1G
[16:28] <seb128> so they probably don't hit the issue as easily
[16:29] <juliank> so long running machines accumulate swap use despite not needing it
[16:30] <juliank> like I had 3 MB of swap used
[16:30] <juliank> because the kernel won't remove the swapped bits if you don#t need them
[16:30] <juliank> seb128: enr0n: I could just send a PR upstream and see what they see
[16:31] <enr0n> juliank: I don't mind doing so since I was supposed to be looking into this. But you did find it so up to you.
[16:32] <juliank> enr0n: ddstreet found it, so I don't need the fame and glory but do CC me if you want to send one
[16:32] <juliank> enr0n: I want to watch :)
[16:33] <juliank> enr0n: I think there are nicer fixes that take some % of the page cache in account, but not sure. Such that we don't need to evict all pages before triggering OOM, which would then lead to the whole swap hell I think
[16:34] <juliank> So technically one would want to parse Buffers and Cached lines, and then add them to the used memory with a factor of 20% or so
[16:34] <juliank> enr0n: It's better if you do it, fwiw, I'd just send it totally untested :)
[16:35] <schopin> juliank: we could just reduce the %age to allow for triggering before all page cache is flushed out.
[16:35] <juliank> that too
[16:35] <juliank> but also maybe 10% is fine
[16:35] <enr0n> juliank: haha alright I will do it in that case
[16:54] <KGB-2> gnome-shell-extension-bluetooth-quick-connect pipeline Simon McVittie 365489 * pending (autopkgtest: created; lintian: created; reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; build i386: created; extract-source: pending; piuparts: created; blhc: created; build: created)
[16:54] <KGB-2> gnome-shell-extension-bluetooth-quick-connect pipeline Simon McVittie 365489 * running (extract-source: running; autopkgtest: created; lintian: created; reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; build i386: created; piuparts: created; blhc: created; build: created)
[17:01] <KGB-2> xdg-desktop-portal-gnome Sebastien Bacher 303825 * commented merge request !1 * https://deb.li/3C1Mj
[17:03] <KGB-2> gnome-shell-extension-bluetooth-quick-connect pipeline Simon McVittie 365489 * [8 minutes and 16 seconds] success (piuparts: success; autopkgtest: success; reprotest: success; test-build-all: success; lintian: success; test-crossbuild-arm64: success; test-build-any: success; blhc: success; build i386: success; build: success; build source: success; extract-s
[17:03] <KGB-2> shell-extensionsource: success)
[17:04] <ddstreet> juliank enr0n sorry was in another mtg, re: the commit, no you also need to adjust how crgoup 'used' memory is calculated by oomd
[17:05] <ddstreet> since all systemd-controlled processes will be running in a cgroup (as well as other stuff, too)
[17:06] <ddstreet> also, 'swap hell' isn't just as simple as 'lots of swap and not much free memory', you can be in swap hell with very little swap used
[17:06] <ddstreet> if you want to engage upstream to improve oomd it might be worth reviewing how the kernel oom-killer works
[17:06] <ddstreet> since it does the same thing, but maybe less agressively
[17:07] <juliank> ddstreet: I think you misunderstand the purpose of oomd
[17:07] <ddstreet> maybe yeah, what's the purpose?
[17:09] <juliank> ddstreet: I don't think I understand the ins and outs either, but a start would be to read the facebook oomd docs https://github.com/facebookincubator/oomd - which the systemd one is derived from
[17:09] <ddstreet> so neither of us understand the purpose? ;-)
[17:10] <ddstreet> does someone from foundations at least understand its purpose? enr0n or slyon?
[17:10] <ddstreet> or maybe i'm misunderstanding what you mean by saying i misunderstand its purpose?
[17:11] <juliank> ddstreet: well the purpose we know is that it kicks in earlier and has better control over what to kill
[17:11] <juliank> ddstreet: like it kills at cgroup level and stuff
[17:11] <juliank> ddstreet: it can be more easily configured
[17:12] <ddstreet> ok, but the kernel oom-killer is configurable and as i said the kernel oom-killer is 'less aggressive' than oomd
[17:12] <ddstreet> if that's all you mean, then im not sure how i don't understand oomd's purpose
[17:12] <juliank> there's more rationale https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
[17:12] <ddstreet> also the kernel can oom-kill inside cgroups
[17:12] <juliank> ddstreet: basically people wanted to improve oom, but didn't want to bother working in the kernel
[17:13] <ddstreet> lol
[17:13] <ddstreet> read: systemd didn't want to bother working in the kernel xD
[17:13] <ahasenack> slippery slope
[17:13] <ddstreet> don't get me wrong, i actually like systemd and do quite a lot of work in it
[17:13] <juliank> ddstreet: well, it's facebook's project 
[17:13] <juliank> Provide a better experience for Fedora users in out-of-memory (OOM) situations by enabling systemd-oomd by default. Actions taken by systemd-oomd operate on a per-cgroup level, aligning well with the life cycle of systemd units. systemd-oomd primarily uses Linux pressure stall information (PSI) to make decisions based on wasted productivity due to resource shortages; in addition to that, it
[17:13] <juliank> also supports swap based actions.
[17:14] <ddstreet> lol i'm not arguing against using oomd
[17:14] <ahasenack> I wonder if it will ever kill itself :)
[17:14] <ddstreet> rofl
[17:14] <ddstreet> i'd like to see that
[17:14]  * ahasenack thinks of the bridge crossing in Monty Python Holy Grail
[17:14] <ddstreet> what? i don't know that... AAAAAHHHHHH
[17:14] <KGB-2> xdg-desktop-portal-gnome ubuntu/master 5b8c379 Jeremy Bicha debian/patches/ (5 files) * Add patches to revert using libadwaita * https://deb.li/ix1BF
[17:14] <KGB-2> xdg-desktop-portal-gnome ubuntu/master 9b9c9dc Jeremy Bicha debian/ control control.in * debian/control.in: Drop libadwaita-1-dev from Build-Depends * https://deb.li/ki4E
[17:15] <juliank> ddstreet: but the design assumed that swap >= ram, which is not what we want as we don't really want systems to use swap in the first place
[17:15] <ddstreet> juliank re: your earlier comment that 1gb swap is intentional, was there discussion on that? it seems like a really bad default to me, honestly
[17:16] <juliank> ddstreet: yes, lots of
[17:16] <juliank> ddstreet: a long time ago
[17:16] <juliank> ddstreet: in 17.04 that was decided
[17:16] <ddstreet> wow
[17:16]  * ahasenack has 8Gb of swap
[17:16] <ddstreet> yeah 1gb swap is basically insane
[17:16] <ddstreet> but...if it's done, then ok
[17:16] <ahasenack> bug the fresh jammy install does have 1Gb of swap
[17:17] <ddstreet> i think a lot of people think *any* swap is bad, unfortunately
[17:17] <ddstreet> swap is greatly misunderstood
[17:17] <juliank> ddstreet: xnox implemented that back then
[17:17] <juliank> ddstreet: neasurements were done
[17:17] <ddstreet> okey dokey :)
[17:18] <juliank> ddstreet: I'm trying to find the details for you
[17:18] <ddstreet> hey, you dont have to convince me (because you wont ;-)
[17:19] <KGB-0> xdg-desktop-portal-gnome signed tags 6089537 Jeremy Bicha ubuntu/42.0.1-1ubuntu1 * xdg-desktop-portal-gnome Debian release 42.0.1-1ubuntu1 * https://deb.li/3WCze
[17:19] <KGB-0> xdg-desktop-portal-gnome ubuntu/master b54bd23 Jeremy Bicha debian/changelog * releasing package xdg-desktop-portal-gnome version 42.0.1-1ubuntu1 * https://deb.li/e7DI
[17:19] <KGB-2> xdg-desktop-portal-gnome pipeline Jeremy Bicha 365491 * running (extract-source: running; blhc: created; autopkgtest: created; lintian: created; reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; build i386: created; piuparts: created; build: created)
[17:20] <juliank> ddstreet: somewhere https://lists.ubuntu.com/archives/ubuntu-devel/2016-November/039538.html and https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1566129
[17:20] <ddstreet> unfortunately, lots of people think reducing/eliminating swap will 'improve performance', but in reality reducing swap simply reduces the system's memory elasticity
[17:20] <ubottu> Launchpad bug 1566129 in debian-installer (Ubuntu) "server installer partitioning suggestions need refinement" [Undecided, Confirmed]
[17:20] <ddstreet> it changes the system's response to (actual) memory pressure from a slope to sharp cliff
[17:20] <juliank> ddstreet: basically I want a sharp cutoff when I have an app with a bug that fast allocates a lot of memory
[17:21] <juliank> ddstreet: rather than dragging this out for hours
[17:21] <juliank> ddstreet: which then usually ends up in a hard reset
[17:21] <juliank> (if you have large swap)
[17:22] <ddstreet> an app with a bug allocating lots of memory (but just the right amount of lots of memory, not too much to get malloc failures) is hardly the common situation that uses swap
[17:22] <ddstreet> anyway, there is obviously no need for us to convince each other
[17:22] <juliank> I don't see it obviously
[17:23] <juliank> Personally I just buy insane amounts of RAM I only use 50% of
[17:23] <KGB-0> xdg-desktop-portal-gnome pipeline Jeremy Bicha 365490 * [8 minutes and 59 seconds] failed (piuparts: success; reprotest: failed; autopkgtest: success; test-build-any: success; test-crossbuild-arm64: failed; lintian: failed; blhc: success; test-build-all: success; build i386: success; build: success; build source: success; extract-source: success)
[17:24] <juliank> When I only had 16GB of RAM I remember having to hard reset stuff because it was swapping forever
[17:24] <juliank> don't judge me I was running Chrome + Android Studio + an Android VM
[17:25] <juliank> At the moment I have 24 GB RAM and 8GB swap, with zswap enabled for lolz
[17:27] <juliank> also it would be nice if it put swap hoggers on slowdown, like chrome slows down JS execution in background tabs and eventaully pauses them entirely
[17:28] <juliank> I guess hogger is not really a word for "someone who hogs"?
[17:28] <juliank> I wonder if the cgroup reports memory used without counting cache
[17:30] <ddstreet> juliank just fyi, zswap can lead to a very, very sharp cliff of swapping once its configured limit is reached...or at least, it used to have that cliff back when i was zswap maintainer
[17:30] <juliank> enr0n: another place https://github.com/systemd/systemd/blob/main/src/basic/procfs-util.c#L245
[17:31] <ddstreet> cgroup reports all specific memory use, yes
[17:31] <juliank> ddstreet: do they?
[17:31] <juliank> ddstreet: ah memory.stat
[17:33] <juliank> ddstreet: but also that doesn't make much sense with memory.max and memory.min throttling/not reclaiming flags including page count
[17:33] <juliank> s/page count/page cache/
[17:36] <juliank> ddstreet: so for the cgroup you have to consider page cache (as memory.current), otherwise you end up inconsistent with the limits set via memory.min and memory.max
[17:36] <juliank> whether this all maeks sense or not, idk
[17:37] <juliank> "you program cached too pages, so you get throttled" I feel sounds hilarious
[17:37] <ddstreet> juliank i'd have to review the specifics of the kernel mm/memcontrol, but i think including pagecache in the calculated value (re: max) makes total sense, it means mallocs from that specific cgroup will start evicting pagecache from that specific cgroup under memory pressure
[17:37] <ddstreet> it container-izes memory use, including pagecache, just like un-cgrouped processes are handled for the larger system
[17:38] <ddstreet> and no, programs don't get throttled for too much pagecache, what happens is the pagecache is evicted as needed
[17:39] <juliank> ddstreet: well if the eviction failed, they would as they'd be over their max?
[17:39] <ddstreet> how would pagecache eviction fail?
[17:39] <juliank> ddstreet: I don't know, but like those are unrelated things
[17:39] <ddstreet> lol pagecache eviction doesn't ever fail for 'clean' pagecache pages
[17:40] <ddstreet> if the cgroup has a lot of dirty pagecache, that means they're doing a lot of writes to actual files
[17:40] <ddstreet> so while those are cached for performance, under memory pressure they have to be synced back to disck
[17:40] <ddstreet> disc
[17:40] <juliank> but the problem is if we want the memory pressure of the cgroup we need to use memory.current to stay consistent with the other stuff we read from the kernel
[17:40] <ddstreet> i hate disc/disk :)
[17:41] <ddstreet> of course, you should use the kernel's values of used memory
[17:41] <ddstreet> the point is under memory pressure the kernel will automatically 1) evict clean pagecache and then 2) flush (and evict) dirty pagecache, and then 3) turn to swap
[17:42] <ddstreet> speaking *broadly* of course, the specifics are that it will do a little of all of them all the time
[17:43] <juliank> I guess you want to prevent things from getting to 2 
[17:43] <ddstreet> no you really, really don't
[17:43] <ddstreet> i mean sure, if everyone had unlimited budgets for infinite ram
[17:43] <juliank> also you want to kill entire containers if a process in them ooms
[17:44] <ddstreet> that's entirely configurable with the normal kernel oom killer
[17:44] <ddstreet> but again...we don't need to convince each other :)
[17:44] <juliank> earlyoom was easier than oomd
[17:46] <juliank> (https://fedoraproject.org/wiki/Changes/EnableEarlyoom)
[17:47] <juliank> this used processes, resident memory and "total - avaialble" instead of "total - used"
[19:27] <seb128> jbicha, you might want to try to proposed something similar to https://github.com/snapcore/snapd/pull/11615 for gtk-doc
[19:27] <ubottu> Pull 11615 in snapcore/snapd "interfaces/system-packages-doc: allow read-only access to /usr/share/xubuntu-docs (LP: #1967109)" [Open]
[19:28] <seb128> jbicha, I'm unsure how much that's a request but I saw you edited the bug 
[19:28] <jbicha> seb128: I just did :) https://github.com/snapcore/snapd/pull/11626
[19:28] <ubottu> Pull 11626 in snapcore/snapd "interfaces/system-packages-doc: allow ready-only access to /usr/share/gtk-doc" [Open]
[19:30] <jbicha> I was waiting for Olivier's libreoffice merge proposal to be accepted first since we were editing the same code area & it was easy to copy his work
[20:13] <seb128> jbicha, nice, shotwell upstream is reading launchpad reports still and did https://gitlab.gnome.org/GNOME/shotwell/-/commit/cfd42493
[20:13] <ubottu> Commit cfd4249 in GNOME/shotwell "Also set dark wallpaper uri"
[20:14] <sarnold> cool :D