=== Elliot is now known as Guest3774 [06:35] morning [07:36] re [07:36] hate the morning traffic === pstolowski|afk is now known as pstolowski [08:04] morning [08:06] pstolowski: hey [08:08] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7702 ? maybe we could land it [08:08] PR #7702: tests: adding fedora 31 [08:08] mborzecki: sure, will do [08:08] pstolowski: thanks! [10:11] quick errand, brb [10:39] hmm something is not right with tumbleweed [10:54] re [10:55] pstolowski: got logs? [10:59] mborzecki: https://paste.ubuntu.com/p/PkdyMvHYjT/ [10:59] home/gopath/src/github.com/snapcore/snapd/tests/lib/quiet.sh: line 30: 993 Segmentation fault (core dumped) "$@" &> "$tf" [11:00] duh, zypper segfaulted? [11:01] mborzecki: happened on 2 independent PRs and now when run manually [11:02] although i have no proof it was the same error; but they were definaltely tumbleweed prepare failures [11:47] popey ping! re: building close-source project's snaps with launchpad, did you get a chance to make a video for that ? [11:47] or popey_ ^ [11:59] PR snapd#7731 opened: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) [12:51] o/ [12:51] good morning [13:00] hey zyga! [13:00] hey guys, how's the day going? [13:02] mborzecki: can we chat here [13:03] zyga: call would be quicker ;) unless you're in pyjamas or whatnot [13:03] mborzecki: yes but yes :) [13:03] ok, let's use meet [13:04] https://meet.google.com/mym-ngpj-ynj === ricab is now known as ricab|lunch [13:46] * zyga goes for breakfast [13:50] morning folks [14:02] hey ijohnson [14:02] morning zyga [14:02] zyga: no breakfast yet 😢 [14:02] (unless you go out?) [14:03] roadmr: yeah, I had a call with my family; I think brekfast starts later [14:03] oh [14:03] shiny [14:03] https://www.apple.com/macbook-pro-16/ [14:03] zyga: yep need to wait 27 min :) [14:04] zyga: haha magic keyboard ?? I anticipate the "yes, magic - press a key, who knows what'll come out on screen 🤣 " memes [14:05] * zyga sells his 15" [14:05] 🤑 [14:06] 64GB ram maximum, wow [14:08] pstolowski: ^ [14:09] zyga: uhm, your predictions were right [14:09] pstolowski: I will call it the vim macbook [14:09] pstolowski: it has physical escape key :) [14:10] pstolowski: but geez, if the keyboard is now "regular" this is a super shiny machine [14:10] pstolowski: 8TB SSD max, 64GB RAM max [14:10] zyga: wooot, esc? no way :D [14:10] pstolowski: (obviously $$$$ but still) [14:10] pstolowski: yep, physical escape key + rest of touchbar as before [14:10] pstolowski: but the base model is not unlike other laptops from dell / lenovo [14:11] pstolowski: 11-14K PLN for a really nice setup === mborzeck1 is now known as mborzecki [14:13] zyga: i see it replaced 15' in the store, only 13 & 16 now [14:15] Yes, it seems so [14:15] I wonder what the GPU is [14:20] zyga: huh, going with 32GB and ssd >1TB makes the price skyrocket [14:21] cachio: is there a more recent tumbleweed image that we could use by any chance? [14:22] mborzecki, so, we are creating tumbleweed based on the leap 15.0 [14:22] cachio: re install slowness, please grab 'snap debug timings ' [14:22] mborzecki, and then we update it weekly [14:23] pstolowski, sure [14:23] mborzecki, which is the problem with the current one? [14:23] perhaps we could create a new one [14:24] cachio: this failed for instance https://api.travis-ci.org/v3/job/611337121/log.txt [14:24] cachio: this is the relevant part https://paste.ubuntu.com/p/VGYvRc2wG4/ [14:25] cachio: looks like there's a segfault in zypper (?) [14:25] cachio: although when i run a shell manually, i don't seem to be able to reproduce it with the same zypper command on a clean image [14:25] mborzecki, mborzecki I could create a new one based on leap 15.1 latest image [14:26] mborzecki, not sure if it is gonna help [14:26] cachio: do you create a new image from scratch each time, or do you rather keep updating the same image? [14:27] * ijohnson drools over the new macbook [14:27] I initially created a tumbleweed image from leap 15.0 [14:27] this is called base image [14:27] then every week I update that and install all the test dependencies [14:27] in a new image [14:27] the final image [14:28] this is the image we use for snapd [14:28] mborzecki, sometimes I create new base images or update the base image [14:30] mborzecki, what I see is that opensuse-cloud added an image for leap 15.1 that we could use [14:31] pstolowski: the important part is what the baseline has [14:31] No more 256GB 8GB model [14:31] It is a great upgrade! [14:32] cachio: can you maybe try and update the current image to the latest TW snapshot? [14:32] mborzecki, sure [14:32] cachio: hmm looks like we're using 20191109 already [14:33] * ijohnson stops drooling after looking at prices and gets back to work [14:33] mborzecki, yes [14:34] mborzecki, I updated 2 days ago [14:34] zyga: for the gpu it apparently has AMD Radeon Pro 5300M and 5600M with 4GB DDR6 [14:36] zyga: looks like tehre's some updates, i think it's worth trying the latest snapshot anyway [14:37] pstolowski: still i9 cpu booo [14:38] pstolowski: zyga: wonder is i9 is vulnerable https://mdsattacks.com/#ridl-ng [14:39] pstolowski: not sure how that GPU compares to consumer models [14:39] zyga: i'm sure it's not as hot [14:39] pstolowski: i9 -> no zen 2nd gen mobile yet, also very unlikely apple would move to amd on a laptop still [14:39] mborzecki: well, apple store is 200 m away [14:40] I'll check it out :) [14:40] hahah [14:40] zyga: :) [14:41] i can sense zyga returning from the sprint with a new laptop ;) [14:41] pstolowski: never, I want to get it back home as proper purchase with vat and stuff [14:41] pstolowski: here it'd be just more complex [14:41] zyga: for sure it's gonna hit the new split payment regulations :) [14:41] mborzecki: mhm [14:42] mborzecki: I really really wonder how that works now [14:42] yeah it's confusing [14:44] I cannot deny that it is tempting though [14:44] it looks like great piece of hardware [14:44] degville: hey, i think https://snapcraft.io/docs/hotplug-support needs a minor update, the feature is still behind experimental flag and not made widely available with 2.39 as indicated there [14:45] pstolowski, https://paste.ubuntu.com/p/Y6TY4WMYXG/ [14:45] zyga: my santa is not reach enough ;). maybe next year.. [14:45] pstolowski: thanks for letting me know -I'll update it now. [14:45] *rich [14:45] pstolowski: my santa is the same, it would depend on selling the 15" first [14:48] pstolowski, id: 25 [14:48] and 24 [14:49] cachio: thanks, looking [14:54] cachio: it takes 1.5s on my local VM. i'm not sure there is anything wrong there. great chunk of that is seccomp profiles compiler. note this snap has 9 apps in it [14:55] cachio: not sure why copy-snap-data took 1.7s though. was there any old data? [14:55] pstolowski, yes, but it takes more than 2 seconds [14:55] seems to be so much compared with the other times [14:56] cachio: what do you mean by other times? [14:56] pstolowski, compared with the other steps and with apparmor [14:57] cachio: ah, sure. yes, seccomp compiler got very slow a few months ago with a new version [14:57] apparmor= 725ms seccomp=2201ms [14:57] cachio: a few weeks ago i presented some tests on the standup, seccomp got a few times slower afair [14:59] cachio: so yes, setup-profiles is one of the most expensive tasks, a few seconds is normal, unfortunately [15:00] pstolowski, https://paste.ubuntu.com/p/yYnDCPpm7m/ [15:00] degville: thanks for updating hotplug doc! [15:00] in this case I installed over [15:00] pstolowski: np! [15:00] and didnt setup seccomp [15:01] but did the setup for apparmor [15:01] pstolowski, do you know why? [15:07] cachio: seccomp backend computes new profiles and compares them with what's already on the disk, if there is no change then they are not reloaded. same logic applies to apparmor, i suppose they were reloaded because they have snap paths (specific to snap revision) in them === ricab|lunch is now known as ricab [15:13] pstolowski, still weird that if it computes the new profiles it makes that super fast [15:13] and also it does not appear in the timings [15:14] cachio: we don't save timings if something is faster than 5ms [15:14] pstolowski, we have some stuff with 4ms [15:14] cachio: computing profiles is fast, loading them with seccomp profiles is slow [15:15] pstolowski, ahh [15:16] cachio: sorry, i wasn't precise: we will still record times of individual tasks (like 4ms with post refresh hook), but we don't store detailed timing breakdown (nested timings) underneath [15:16] pstolowski, ah, ok [15:16] pstolowski, thanks for the explanation [15:17] cachio: if we compute a profile and find it's the same, we don't invoke seccomp or apparmor parser at all [15:19] pstolowski, perhaps we could see why we are calling apparmot [15:19] it I am installing the same snap twice [15:20] cachio: but it ends up with different revision, no? [15:21] pstolowski, ye [15:21] s [15:21] cachio: so, paths are differnt in the aa profiles [15:21] pstolowski, ah, ok [15:22] makes sense [15:27] pstolowski, so seccomp takes more time depending on the number of apps the snap has? [15:28] pstolowski, for example the snap test-snapd-framebuffer with 2 apps and 1 interface takes 493ms on seccomp [15:28] and 0ms to copy snap data [15:31] pstolowski, and first time I saw: 1791ms - Copy snap "test-snapd-tools" data [15:31] perhaps we could update the snap to make it faster to be installed [15:32] because it is being used on many tests [15:34] cachio: what is the data of this snap? it seems we're copying data over to the new revision in the test, maybe it makes no sense [15:35] cachio: i mean, maybe we should simply rm -rf .. on snap data to avoid copying [15:39] pstolowski, I think in the test there is something weird [15:39] I ran the samein the pi3 and got 2212ms - setup security backend "seccomp" for snap "test-snapd-tools-core18" [15:39] seccom takes same time on pi3 than in the vm [15:39] hhehe [15:41] pstolowski, take a look to this please https://paste.ubuntu.com/p/MKD5MCTtxn/ [15:42] pstolowski, do we use different seccomps for core than classic? [15:46] cachio: is it a fast vm? [15:50] pstolowski, it is same we use for tests on google [15:51] pstolowski, but it should be faster then the pi3 [15:52] in fact in the pi3 apparmor takes more than 2 seoncds [15:52] compared with 700ms on the vm [15:52] but seccomp is the same time in both [15:55] cachio: i see. i don't know why. this the time of seccomp compiler itself. maybe mborzecki or zyga know what is it doing that explains no difference on pi3 vs vm [15:55] pstolowski: hm? why it's so slow? [15:56] mborzecki, well, in pi3 is slow as in a vm [15:56] mborzecki: why it takes same time on pi3 vs vm [15:56] mborzecki, https://paste.ubuntu.com/p/MKD5MCTtxn/ [15:56] mborzecki: where it should in theory be faster on vm [15:57] pstolowski, but apparmor is much faster in the vm [15:57] mborzecki, ~ [15:57] pstolowski: iirc it's cpu bound and single threaded [15:57] mborzecki: aah, here you go [15:57] mborzecki, ahh, that explains it [15:58] mborzecki, pstolowski thanks for the explanations [15:58] cachio: pstolowski: we could run the compiler in parallel, but you'd only benefit when there's more than 1 app [15:59] setting up security backends in parallel would give more gains i believe [15:59] mborzecki, for testing that should be really usefull [15:59] yep.. test-snapd-tools has 9 apps ;) [15:59] is it possible to so it by configuration? [15:59] cachio: no, needs coding [15:59] pstolowski, :( [15:59] cachio, pstolowski: snap-seccomp needs a cache layer [15:59] virtually all snaps use the same seccomp profile in the end [15:59] pstolowski: cachio: i had the patches somewhere, iirc i pointed pawel to the commits at some point [16:00] there is far less variability compared to apparmor [16:00] cachio: if you feel like it i can try to revive the branch with paralell compilation of seccomp profiles and we can try to benchmark that [16:00] brb [16:00] mborzecki, that should be really nice [16:01] on tests we have many snaps with more than 1 app and reviewing times I see most of the time it is installing snaps [16:01] and most of that time it is creating seccomp profiles [16:02] mborzecki, if you have a branch I could try it [16:02] and see the time improvement === pstolowski is now known as pstolowski|afk [21:06] ijohnson: hi, still around? [21:06] hey mborzecki [21:06] PR snapd#7732 opened: [PoC] many: extracted snaps mode [21:06] ijohnson: opened a branch for you ^^ [21:06] thanks mborzecki, will give it a spin [21:07] ijohnson: i think it should mostly work, but you may see some issues with layouts, iirc some logic depends on statfs()ing some paths and observing squashfs magic there [21:08] ijohnson: and you'll need to set SNAPD_EXTRACT_SNAPS in your environment [21:08] right I see that from the patch [21:08] that's interesting about layouts needing to introspect the squashfs [21:08] I'll see what I can find in any case [21:10] ijohnson: if you see bugs or issues feel free to patch it ofc :P [21:10] sounds good [21:12] ijohnson: thanks! really looking forward to the numbers, i suppose next thing we could try afterwards is repacking the squashfs locally [21:13] yeah I don't want to get too far into repacking without Samuele's blessing however :-) [21:15] ijohnson: yup, agreed, this should give us some insight though [21:15] indeed [21:16] all right, wrapping it up, till tomorrow [22:11] PR snapd#7733 opened: tests: disable nova from install-snaps test [22:28] PR snapcraft#2786 closed: cli: add support for 'http-proxy' and 'https-proxy' parameters [22:46] PR snapcraft#2769 closed: extensions: skip icon cache creation for theme and runtime snaps === alan_g_ is now known as alan_g