[06:14] o/ [06:14] morning [06:15] zyga-x240: maciek@galeon:~ sudo apparmor_parser --version <<< 1 ↵ [06:15] AppArmor parser version 3.0.0 [06:15] updades :) [06:15] let's see if anything is broken [06:15] upgrades* [06:16] zyga-x240: hmm apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/proc/4598/attr/apparmor/current" pid=4598 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [06:16] I saw that but I'm not sure when it happens [06:16] and apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=4598 comm="snap-confine" capability=4 capname="fsetid" [06:16] that's documented on the forum [06:18] zyga-x240: did we fix taht in master? [06:18] I have a vague memory someone did (the 1st one), let me look [06:19] edda21d7b2b [06:19] but that's an old patch [06:19] well [06:19] maybe not released [06:19] it's from September [06:19] Ian fixed it [06:22] rogpeppe: hello [06:22] rogpeppe: if you have a moment we could really use your help to obtain a few more logs [07:51] brb, logging back to X11 [07:53] re [07:59] eh, x11 has gpu issues [07:59] wayland is ok but has wayland issues [07:59] man [08:05] hahah [08:05] zyga-x240: btw. what wayland issues? screen sharing? [08:06] mborzecki: 150% zoom makes every non-native wayland thing entirely blurry [08:06] code, hexchat all look like garbage [08:06] btw, I learned why macos handles this better recently [08:06] they scale down [08:06] not up [08:06] it's such a silly thing [08:06] they render at the higher resolution and scale down for fractional scaling [08:07] it seems we do the opposite [08:07] anyway, X is tearing and leaving glitches everywhere lately [08:07] but has different fractional scaling that works better [08:07] but is unusable while scrolling anything (garbage on screen) [08:07] waland doesn't have that but makes everything blurry [08:09] mborzecki: my x240 has a 1080 panel that needs 125%-150% scaling to be sensible [08:11] zyga-x240: hexchat is still gtk2 right? [08:11] and code is electon & gtk2 as well? [08:12] no idea, don't care, it's just broken [08:13] mborzecki: hexchat links to 76 libraries [08:14] zyga-x240: yeah, hexchat is gtk2, i mean it's not going to be better if you use old toolkit, same way old apps on windows look blurry [08:16] mborzecki: on macos all the apps render sensibly because of what I said [08:16] just little annoyances [08:16] let alone that nobody uses old toolkits there [08:16] mborzecki: I can ssh -X to this machine and get nicely looking gitk [08:18] mborzecki: hi, does this make sense https://github.com/snapcore/snapd/pull/9474#issuecomment-706041940 ? or should we chat about it [08:18] mborzecki: I take that back, x11 has tearing as well, just maybe less frequently [08:19] hello pedronis [08:20] pedronis: hi, yes, that sounds fine, i'll add some comments around (Managed|Truted)Assets that one can call them without rootdir too [08:21] pedronis: do you have an opinion on the need to access the backend in doInstall? [08:21] pedronis: should I forfeit that specific refactor or should I go ahead and make that possible? [08:22] zyga-x240: first of all backend is two things, a package and an almost stateless object that exist mostly for mocking convenience (at least originally) [08:23] zyga-x240: so we have some options [08:23] pedronis: right [08:23] zyga-x240: can you point me at which bits is called form doInstall, is that the soft check? [08:23] I think we could construct the backend in doInstall or create a 2nd object that is 100% stateless and only used by doInstall for that single request [08:23] yes, correct [08:24] specifically the snap run lock is acquired around the cgroup scan [08:25] zyga-x240: is this comment we are talking about: https://github.com/snapcore/snapd/pull/8573#discussion_r497444927 ? [08:26] pedronis: yes [08:27] zyga-x240: that bit respect dirs.GlobalRootDir right? so it wouldn't really need a lot of mocking? [08:27] indeed they do [08:27] both of them [08:28] (locking and scanning) [08:28] anyway to me it mess that WithSnapLock could be simply a function the backend package [08:28] s/mess/seems/ (that is a weird typo) [08:29] haha [08:29] ok, let me try that quickly, I think this is fine [08:30] we could create a concept of an early request backend if we have more methods that need to be called when constructing tasks [08:30] but for now I think that's not required [08:51] pedronis: do you think you'll be able to take a look at https://github.com/snapcore/snapd/pull/9443 ? [08:52] mborzecki: maybe, it also needs a 2nd review [08:53] pedronis: yeah, i'll poke claudio about it [09:23] 2re [09:38] hi pedronis good morning! do you think you will be able to give a quick look at #9418 today? [09:41] hey ijohnson [09:44] Hey zyga-x240 [09:49] ijohnson: I didn't do a proper review but left some comments [09:50] ijohnson: I also answered maybe your question about how postponent work [09:51] ijohnson: I made a comment also in the fakestore one [09:51] Thanks! [09:51] I'll look now [10:07] zyga-x240: little something for you https://github.com/snapcore/snapd/pull/9484 (cc ijohnson, you have a beefy machine iirc too) [10:07] mborzecki: oh [10:07] nice [10:07] I'll check perf shortly [10:07] it's run as part of run-checks --static now, so every second matters xD [10:08] mborzecki: the biggest bottleneck is seccomp tests [10:08] those are sequential [10:08] due to how the test is written [10:08] zyga-x240: and they have system wide side effects too :/ [10:08] mborzecki: do they? [10:08] bulk of the cost is compilation of C [10:09] I really doubt they do [10:09] they run as user [10:09] not as root [10:09] zyga-x240: they do on my system, apaprently some weird address faimilies are tried what triggers modules to be loaded [10:10] let me grab a log [10:10] ah [10:10] that's one time [10:10] but wierd still [10:10] *weird [10:11] IIRC most of those are just compile time costs [10:11] and can be ran in parallel with some changes to the test [10:11] it'd be nice if check supported that [10:11] IIRC testing supports sub-tests and parallelism [10:11] but it's not surfaced to check [10:11] zyga-x240: lsmod and ip a before and after: https://paste.ubuntu.com/p/qymsZGcMqH/ [10:12] mborzecki: sure but the only question is: do those matter for speed [10:12] they run either way [10:12] zyga-x240: idk, it's just annoying, that's why i don't run snap-seccomp unit tests often [10:12] doesn't happen here, probably not blacklisted on arch and blacklisted in ubuntu [10:13] mborzecki: hmm [10:13] the patch is not doing much for concurrency, does it? [10:14] it's still sequential shellchcek [10:14] ah [10:14] there's a thread executor hidden [10:14] that makes sense now [10:14] it's always surprising that python list.append does not require locking [10:15] implicit mutex at the granularity of several micro-ops [10:15] anyway, looks good [10:15] cuts down the execution on my system a bit too [10:15] mborzecki: btw, is findfiles change actually useful? [10:16] ah, I misread the diff [10:16] man I'm useless today [10:16] zyga-x240: heh tell me about it, i got up at 5am :P [10:16] brb [10:16] cold and tired [10:17] fun, shaves off 1m off the unit tests run on github [10:17] off of [10:17] off from? [10:21] mborzecki: nice, I do see somewhat of a speedup as well, real time of 72s -> 62s [10:21] ijohnson: cool, thanks for checking [10:22] that's amazing that it shaves off 1m from the github changes [10:23] re [10:23] brought a lot of hot tea [10:23] maybe I won't spill it today [10:23] it's cold so I might as well boot my desktop [10:23] it's a small heater after all [10:24] I'll post my numbers in a moment [10:24] mborzecki: nice on in 9484! [10:24] hey mvo, good morning [10:24] hey zyga-x240 [10:24] (well, so-so morning for me but that's not a general statement) :D [10:25] (lots of frustrating things in the morning) [10:25] (before work) [10:25] zyga-x240: oh, sad to hear that [10:31] mborzecki: how do you measure time? [10:31] with time [10:31] zyga-x240: /usr/bin/time -v [10:31] my baseline was real 49s, user 2m19s [10:33] with your branch real 34s (same user value) [10:34] ah wait [10:34] stupid vm [10:36] mborzecki: I think there's something sequential still [10:36] mborzecki: cpu load that's actually parallel is pretty short, bulk of the work is not concurrent [10:36] zyga-x240: yes, the sections in a file are processed sequentially [10:36] mborzecki: 42 seconds [10:36] worse than before? [10:36] user 3m8s [10:38] zyga-x240: hm? [10:38] there's an all-core load for about 2 seconds [10:38] then lots of sequential work [10:39] as in, really most of the time [10:39] 40 seconds on 2nd run [10:39] it's not important, just wondering what's going on [10:40] zyga-x240: right, you can run ./sprad-shellcheck --verbose, my bet is it's still processing the sections of spread.yaml while the reset of the files is already done [10:41] zyga-x240: so it'd be nice to call checksection() in parallel too [10:42] zyga-x240: feel free to play with it ;) it's a nice distraction [10:47] fixed process pool to work [10:55] mborzecki: made some improvements we discussed, 9seconds [10:55] :D [10:55] now all cores do light up [10:56] 49 seconds down to 9 [10:56] haha nice [10:56] zyga-x240: the sections now run in parallel right? [10:56] i mean suites [10:57] yes [10:57] uh [10:57] i rm'd the file! [10:57] fck [10:57] one moment [10:57] cp wrong way [10:58] ok restored [10:58] thank god for good undo in code [10:59] hahah [11:00] mborzecki: can I push back to your PR? [11:00] zyga-x240: i'll land 9484 and we can iterate on top [11:01] zyga-x240: landed, open a PR please [11:01] ok [11:02] mborzecki: 9485 [11:02] I have black re-format stashed as well [11:02] thx [11:04] ijohnson: could you run my version as well [11:04] I wonder how that improves things on your machine [11:04] where is your version [11:04] oh 9485 ? [11:05] yes [11:07] zyga-x240: nice, 28s here [11:07] haha Percent of CPU this job got: 1241% [11:08] that's down from what? [11:08] 59 [11:10] nice! [11:10] good enough for now [11:10] :) [11:10] done [11:10] very nice [11:11] all my cpu utilization's light up bright red :-) [11:16] poor chaps with systems having only 2 cores [11:17] zyga-x240: have you tried running it on x240? :P [11:17] mborzecki: ope [11:18] 2 cores [11:19] hah my i7 x250 hit thermall throttling right away [11:19] unfortunately idle power usage is so low it's not a good room heater [11:19] haha [11:19] oh intel [11:20] still 73s total [11:21] mborzecki: what's a better upgrade, 8core 4800u amd laptop or 16 core amd desktop (5950x) [11:23] zyga-x240: not sure about the laptop, from what i read the last series of mobile apus had driver issues [11:28] mborzecki: really? I heard only good stuff about this lineup [11:28] (we had those thinkpads in cert lab for months) [11:29] mborzecki: maybe 3000 series had issues, don't know about htose [11:29] zyga-x240: haven't had one myself, mostly following /r/Amd [11:29] mborzecki: as kissiel, he has one at home [11:30] mborzecki: not sure if 4800u or 4700 or other [11:30] * zyga-x240 ran away from the office [11:30] too cold, need to turn on heating [12:34] cmatsuoka: silly question, do we ever call UnlockVolumeIfEncrypted() with "lockKeysOnFinish != true"? or is there a use-case for this :) ? [12:35] mvo: currently not because we only have one encrypted partition, but with ubuntu-save things can be different [12:35] mvo: not right now, but it's a complicated question [12:36] depends on the final api and how we do save [12:36] cmatsuoka, pedronis thank you! [12:37] hmm [12:37] * zyga-x240 looks at unexpected test outcome [12:41] oh [12:41] I found a real bug :) [12:41] (real bugs are the best) [12:43] fixed [12:43] zyga-x240: nice [12:49] pedronis: https://github.com/snapcore/snapd/pull/8573 is ready for review again [12:49] I will pick up the next branch now [12:50] ok, I put it beack in my queue [12:51] thank you [12:51] I'll follow up with this plan now: https://github.com/snapcore/snapd/pull/7700#issuecomment-706162240 [12:52] oh standup is soon [13:28] mvo: are you going to the resource utilization session? [13:28] zyga-x240: when is that? now? [13:29] zyga-x240: aha, the limit snap resource usage? [13:29] zyga-x240: definitely will be in this one [13:42] mvo 16:30 [13:43] sorry, I was in the kitchen [13:43] great, see you there [15:08] degville: I made a couple edits to the system options page again, could you take a look when you get a chance? I added the system.watchdog.{runtime,shutdown}-timeout and system.journal.persistent options there [15:08] ijohnson: yes, of course - thanks for adding them! I'll look now. [15:11] thanks degville I had difficulty finding good docs upstream about the watchdog ones, I mostly used the language from https://manpages.debian.org/jessie/systemd/systemd-system.conf.5.en.html because that came up first in my google searches [16:14] ijohnson: thanks for the man page link - that was super helpful. [16:15] nice, yeah it's not super well documented and actually the option name might have been changed to something else in newer systemd releases I think [16:40] * zyga just got a note that his imac is fixed, 5 working days and they kept that, wow :) [16:40] brand new screen, free of charge [16:41] need to pick it up tomorrow [16:43] if youo're sill allowed to go outsde by then at least [16:43] *you're still [16:49] ogra I can just put some cloth on the imac and make a tent [16:50] and read greek philosophy to dogs that want to eat me [16:54] haha [19:07] ijohnson: I asked a question in your SU notes [19:07] pedronis: looking now [19:08] pedronis: yeah sorry meant ubuntu-boot [19:08] ah ok [19:08] that makes more sense :) [19:08] haha yes indeed [19:14] ijohnson: anyway we store model and we need to store encrypted keys there possibly [19:14] so we might need one, though it could be quite tiny [19:15] pedronis: ah ok actually that makes things a lot easier if we need to store something there === genii is now known as genii-o-lantern === genii-o-lantern is now known as genii