=== arnatious_ is now known as arnatious [04:43] PR snapd#7496 opened: tests: move "centos-7" to unstable systems [05:06] morning [05:18] mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/7475 ? [05:18] PR #7475: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package [05:18] mborzecki: sure [05:18] mborzecki: I pushed a PR to move centos-7 to unstable [05:18] mborzecki: if we do it we need to add a trello card too to re-enable it when we can [05:18] mvo: saw that and approved :) thank you! [05:19] mvo: we're not the only ones observing this problem: https://bugs.centos.org/view.php?id=16441#c35202 [05:19] mborzecki: nice [05:20] mborzecki: if its between ystemd-219-67.el7_7.1 -> systemd-219-67.el7) it should be easy to debug hopefully [05:23] mvo: well, they just import the latest source dump from rhel in a single commit https://git.centos.org/rpms/systemd/c/9ab0c50975feeee399ced5d356cc79b9c1a9ce69?branch=c7 :/ [05:25] mborzecki: uh, ok [05:25] mborzecki: still, "just" 15ish patches, should be easy to bisect [05:25] mborzecki: for them, not for us :) [05:26] mhm [05:27] mvo: centos 8 should be coming out today :) === juergh_ is now known as juergh [06:07] hey guys [06:07] small update, I'm going to take the swap day today [06:07] zyga: hey [06:07] lucy has a fever and I think I'm getting one too [06:07] hey zyga [06:08] zyga: uh, get well! [06:08] I'll talk to Gosia and get back to you soon [06:11] zyga: ok - quick Q did we get an update on the not-quite rebooting pi :/ ? [06:12] mvo: we only know fractions, it doesn't die all the time, the journalctl --list-boots showed it booting up several times a day (though we don't know if timestamps are true), I have a journal to go through and AFAIK it's still on older version of core18 and snapd [06:13] mvo: about fsck, there's some more information on https://forum.snapcraft.io/t/core18-shortcoming-missing-fsck-vfat-for-boot-fat-partition/13276 [06:13] mvo: at this point I'd like to clone the entire pi (I have the same model available now) [06:15] rogpeppe: ^^^ could you consider cloning the SD card of your pi for analysis? If so we can craft a script that will DD the card out while briefly re-mounting / to ro [06:15] zyga: sure, np [06:15] * mvo hugs rogpeppe [06:16] zyga, rogpeppe THANK YOU so much [06:16] mvo: I'll craft the script and share it with rogpeppe, testing it on my devices locally [06:16] mvo: depending on how I feel today that may be my "swap day" [06:16] zyga: it might take a while to fetch it though, as it's behind a crappy net connection [06:16] rogpeppe: I'll make sure to include compression :) [06:17] zyga: good plan. xz probably isn't worth it though, given the h/w :) [06:17] zyga: thanks, yeah, if you feel unwell, take time off :) [06:52] PR snapd#7464 closed: snapstate: add missing tests for checkGadgetOrKernel [07:04] mvo: i'm looking into why snap-run test sometimes works or gets stuck on arch, and it's really weird [07:05] mvo: /usr/lib/snapd/snap-exec test-snapd-tools.echo hello appears to be stuck [07:05] mvo: can't connect strace/perf trace nor gdb, /proc//status shows it's stuck in D state [07:06] mvo: afaik it's uninterruptible sleep on the kernel side [07:07] mborzecki: uh, so its a real issue? probably just manifests itself when we attach strace? [07:08] mvo: probably, wodnering if i can tigger kernel side task dump without bringing down the whole system [07:08] mborzecki: IDK, sry :/ [07:10] mborzecki: different topic, there was a "snap run --explain" mockup during the sprint. was this a gdoc and if so, do you have the link? [07:10] mvo: i think zyga added it in the sprint notes [07:12] mvo: https://paste.ubuntu.com/p/8nVzj8Sqfq/ kernel dump of blocked tasks, only strace and snap-exec, and have a bunch of those [07:12] mborzecki: right, what I see there is less detailed than what I remember seeing on the screen. *but* I was in some different meeting so I may be wrong [07:13] mvo: notice how snap exec with pid 245937 is stuck in do_execve.../load_elf_binary [07:13] mborzecki: interessting flush_old_exec seems to be a bit of a pattern [07:16] morning! [07:21] mvo: it was in the sprint notes [07:21] mvo: you probably remember the "EX:" prefix [07:21] mvo: it was later removed after review [07:22] mvo: it starts on page 19 [07:30] pstolowski: hey [07:31] zyga: look at the kernel task dump i pasted above ^^ [07:31] mvo: so i tried bind mounting /bin/true from the host over snap-exec in the core snap, and wasn't able to reproduuce this anymore, similarly no luch when i bind mounted true from the core snap [07:33] mborzecki: I'm out of sync, can you refresh my memory please [07:34] zyga: on arch, when running snap run --strace it'd sometimes get stuck, similarly snap run --trace-exec would not list snap-exec in theoutput [07:34] zyga: so i tried running the same command as we use in tests in a loop, and was able to see it getting stuck, apparently, in the process tree, snap-exec ends up in D state [07:35] D as in IOWAIT [07:35] yeah [07:37] zyga: aha, thanks, thats fine. I was wondering where the EX went to :) [07:40] mvo: it was removed during the review [07:42] zyga: thats fine, thanks for the explaination [08:07] https://lore.kernel.org/patchwork/patch/719314/ [08:07] strace lockup when tracing exec in go [08:13] heh, and tracing that trivial Go program gets stuck [08:14] * pstolowski quick errand, bbiab [08:16] mborzecki: that's why the recommended strace has a bunch of exceptions [08:16] mborzecki: the "-e !select,pselect6,_newselect,clock_gettime,sigaltstack,gettid,gettimeofday,nanosleep" thing is not just laziness :-) [08:19] Chipaca: strace -f -e execve gets stuck too [08:19] poor strace [08:27] PR snapd#7497 opened: tests: listing test, make accepted snapd/core versions consistent [08:30] mborzecki: nice, it even has a kernel patch - except its from 2016 :/ [08:31] mvo: yeah, i'll just skip the strace related parts of the test on arch, no need to break the whole spread run [08:31] mborzecki: did the patch got applied and we just happen to hit a new issue? [08:31] mvo: afaik, the patch was not applied [08:32] mvo: and don't really feel like debugging this any further is useful :/ [08:33] mborzecki: yeah, thats fine. I wonder if we could point our kernel people to the diff [08:34] I mean, if its really fixing the problem might be worthwhile to upstream it [08:34] mborzecki: our strace is only working because we do a bunch of !excludes [08:34] mborzecki: but not high priority I guess, but given that arch is usually ahead a bit we might seen it soon on ubuntu too :/ [08:35] mvo: unless it's magically patched, reading the lkml thread, there's some confusion about which change fixed or masked the problem, so the issue is probably more complex than it seems [08:36] mborzecki: ok, I did not read the full thread so yeah, lets ignore it for now :( === pedronis_ is now known as pedronis [08:38] mvo: (repeating in case, I got disconnected) well if it's in the end is a kernel problem and it hits ubuntu we would need to involve the kernel team [08:40] pedronis: eoan is on 5.3? [08:40] PR snapd#7498 opened: tests/main/snap-run: disable strace test cases on Arch [08:40] pedronis: yes [08:42] i'll do a quick run and check if it hapens on eoan too, if so i'll file a bug in PL [08:42] LP [08:42] in the meantime, 7498 should help with the failures [08:49] PR snapd#7496 closed: tests: move "centos-7" to unstable systems [08:50] pedronis: mvo: there's no going to be pre2.1 right? :D [08:50] mborzecki: unlikely - Samuele says NO :) [08:50] haha ok [08:51] PR snapd#7475 closed: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package [08:55] pedronis: your input would be appreciated on https://forum.snapcraft.io/t/feature-request-extend-length-of-version-string/13335?u=chipaca === pedronis_ is now known as pedronis [09:02] Chipaca: I put in my queue, there's no easy answer though [09:18] mvo: still red travis ? [09:18] pedronis: try merging master, the pr moving centos to unstable has landed [09:40] woo, parliament woo [09:40] * Chipaca watching the news [09:46] I think I need a drink, that was intense [09:46] * Chipaca gets a glass of water [09:49] Chipaca: what happened? [09:49] * zyga checks the guardian [09:50] Prorogation ruled unlawful, it never happened [09:50] zyga: 11 judges, unanimously, told the gov'mnt to stuff it [09:50] holly smokes [09:51] ikr [09:51] well, it's like adding anti-matter to a fire [09:51] it's helping to put it out, in a way [09:55] looks like a GE or a 2nd ref, with odds heavily on a GE [09:57] mvo: good news (?), strace gets stuck on eoan too [09:58] mborzecki: https://media.giphy.com/media/3o7abA4a0QCXtSxGN2/giphy.mp4 [09:58] haha :P [10:13] mborzecki: oh no [10:13] mborzecki: or yes [10:17] mvo: filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1845180 [10:17] Bug #1845180: strace deadlock when tracing a trivial Go program [10:23] ppisati, here is one for you ... https://forum.snapcraft.io/t/watchdog-soft-lockup/13375 [10:23] (has an lp bug at the end) [10:23] hmm https://media.ccc.de/v/ASG2019-145-distributing-freedesktop-sdk-applications-to-flatpak-snapd-and-docker [10:24] isn't that they guy who posted about freedesktop base snap in the forums? [10:26] sergiusens: is having the manifest the default in snapcraft now, or does it need a flag? [10:26] yes [10:30] ogra: I took and did , and now ! fix it! [10:31] * Chipaca stops forum'ing [10:38] Chipaca, haha [10:40] Saviq: woah @multipass on mac :). also, seems to be running fine alongside vmware fusion === pfsmorigo_ is now known as pfsmorigo [11:17] PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil [11:17] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51 [11:19] PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil [11:19] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51 [11:19] PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:19] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, [11:19] snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:19] Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137 [11:19] PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134 [11:20] PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build [11:20] PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:20] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, [11:20] snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:20] Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137 [11:20] PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134 [11:23] PR snapd#7416 closed: seed/seedwriter: start of Writer and internal policy16/tree16 [11:24] PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:24] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454, [11:24] snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:24] Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137 [11:24] PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134 [11:25] PR # closed: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729 [11:25] PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:25] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454, [11:25] snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:25] Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137 [11:25] PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134 [11:26] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51 [11:27] PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil [11:27] PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil [11:27] PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build [11:27] PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:27] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454, [11:27] snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:28] PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil [11:28] PR # opened: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729 [11:28] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51 [11:28] PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266, [11:28] snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454, [11:28] snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498 [11:29] PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil [11:29] PR core#38 opened: Add another pi-config option [11:29] PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build [11:33] mupping ... [11:38] mvo, pedronis, what was the conclusion WRT rebasing? is it now the Right Way? [11:38] Chipaca: I don't think there was a conclusion [11:38] tbh [11:38] Chipaca: I though we agreed to try the "merge-with-rebase" from GH? [11:38] pedronis: -^ [11:39] i.e. the automatic on click option ? [11:39] so, no force-pushing, but merge-with-rebase [11:39] ? [11:39] sgtm fwiw [11:39] do we know what happens when it doesn't work? [11:39] I expect it will not always work [11:41] pedronis: I'd expect github to block it if it doesn't work [11:41] but I don't know why a merge would work and a rebase-then-merge wouldn't [11:42] Chipaca: I'm just not sure what happens to the tweaks you need a merge to make the merge work along the way [11:43] do they get turned into extra commits? do they make the thing fail again? [11:43] not sure i understood your question [11:43] seem to have too many merges in it [11:43] Chipaca: usually you fix conflicts and that fix goes into the merge commit [11:44] Chipaca: I mean from experience rebase don't always work locally, so not sure why they would work on merge [11:44] I mean work without intervention [11:45] I'm sure I will learn soon enough [11:45] pedronis: https://github.com/isaacs/github/issues/1143 [11:45] fwiw [11:46] i'm going to have lunch and stick my head in a jar of git sand, like a git ostrich of some sort [11:48] Chipaca: mvo: anyway my point is that we'll see but when it will not work we will decide what to do === ricab is now known as ricab|lunch [11:51] mvo: #7434 should be ready for review [11:51] PR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code [11:54] mvo: also notice that "rebase and merge" says not enabled for this repository [12:05] PR snapd#7499 opened: many: move AppArmor probing code under sandbox/apparmor [12:05] zyga: ^^ something for you [12:06] thx [12:06] zyga: release/selinux*.go are mostly stubs now since we have the sandbox/selinux package, so they are next in line to be dropped [12:11] reviewed [12:11] morning folks [12:12] pedronis, Chipaca (and others) where should I put my unit tests for SetTaskSnapSetup? the function is defined in handlers.go, but it's not clear which handlers_*_test.go I should put my tests in [12:13] I could create a new "generic" handlers_test.go for this function which isn't specific to any kind of handler [12:13] this is my update to #7430 btw [12:13] PR #7430: overlord/snapstate: set snap-setup-task for first task in change [12:14] ijohnson: that seems ok [12:14] pedronis: handlers_test.go seems okay? [12:15] yes [12:15] ack, thanks [12:25] mvo: so I looked a bit, I'm not sure how switching to rebase will help, it will make the commits contiguous but not anchored, we would need to work hard on the quality of the messages of our single commits for it to make sense [12:25] or allow rebases on PRs [12:26] ok, #7430 is ready for re-review Chipaca and pedronis if y'all could review that would be great [12:26] PR #7430: overlord/snapstate: set snap-setup-task for first task in change [12:26] pedronis, what do you mean the commits wouldn't be anchored? do you mean you can't find the PR a commit was merged in? [12:27] ijohnson: where would a overall description fit in that case? [12:27] I'm not even sure how to make a changelog in that mode (maybe I'm missing something) [12:27] ah you mean rebase when you merge to master [12:28] yes agreed there's nowhere to describe the overall "here's what all these commits did" when you rebase instead of doing a merge commit I suppose [12:29] yea, so I don't see how it can fit our current style of PRs [12:29] there's probably something we could do to our PRs [12:29] to make it fit [12:29] but I think it would involve allowing some rebase in them [12:29] i fear for the rebase approach we'd have to move to rebasing everywhere, to keep things tidy [12:29] or do the squash thing [12:30] Chipaca: I still think that either squash or merge would fit our approach better [12:30] but still seems like we would need a bot to do either [12:30] because we are not very good at driving either [12:30] on average [12:31] anyway I don't think we have a conclusion here [12:33] I would be +1 to squashing and/or having a bot do the squash and/or regular merge to keep things consistent [12:35] there may already be github bot plugins to do this, the multipass team uses https://github.com/apps/bors [12:37] in view of recent developments, I'm wary of saying we give a bot commit [12:37] :) [12:37] PR snapd#7497 closed: tests: listing test, make accepted snapd/core versions consistent [12:39] fair :-) [12:51] pedronis: just read backlog and indeed, that seems like we have no solution yet :/ [12:51] Chipaca: yeah, I don't like the bot idea [12:58] store throwing 503? [13:00] mborzecki: pr'aps; line is stopped over there === ricab|lunch is now known as ricab [13:36] Chipaca: cool if I make a couple suggestions to your welcome.md gdoc thing? [13:36] (not edits, just suggestions) [13:36] I can also wait til you're done if you're still working on it [13:37] ijohnson: go for it [13:37] ack [13:41] mvo: in the bug triage policy, could you make the links say what they're to? (you can have the link text be different than the link target) [13:42] mvo: click the link, then the pencil, and you get to change things [13:42] mvo: or highlight text, ctrl+k → set a target [13:48] mvo: fwiw i did it for the last link which was easier to guess at :) [13:54] Chipaca: updated [15:27] anyone see a kill-timeout from a spread reboot request before like this ? https://pastebin.ubuntu.com/p/sGDkb43zrx/ [15:32] PR snapd#7498 closed: tests/main/snap-run: disable strace test cases on Arch [15:33] * cachio lunch [15:46] PR snapd#7500 opened: api,timings: report duration via Doing column for ensure/startup [15:47] pedronis: ^ was actually simple, but i got slightly confused initially [15:57] pstolowski: +1 with small comment [15:59] pedronis: for the auto-connect & mark-seeded order issue, it's because we don't sort tasks in snap debug timings, it's whatever order change.Tasks() reported. will fix [15:59] pedronis: ty [16:05] huh [16:05] https://travis-ci.org/snapcore/snapd/jobs/589008368#L6315 ← huh [16:06] https://www.youtube.com/watch?v=j08nLrO_T84 [16:10] in what case would snap-run --trace-exec print info about snap-exec and not snap-confine? [16:18] Chipaca: IIRC there is that raw thing [16:18] For strace [16:18] zyga: ? [16:18] But perhaps I misremember or misunderstand [16:18] zyga: https://api.travis-ci.org/v3/job/589008368/log.txt [16:18] zyga: look for 'error executing' [16:19] zyga: it's looking at the output of 'snap run --trace-exec' [16:19] snap run —strace=raw [16:19] Mmmmm [16:19] and it's a wee urd [16:19] I didn’t remember that one [16:20] I won’t be able to look from the phone now. I’ll make some tea and open the laptop again but this will take some time [16:20] Tomorrow ish [16:22] pstolowski: ah, so Tasks is in creation order, I suppose here we want start times order? [16:22] pedronis: yes. fwtw 'snap changes' orders them by spawn time, perhaps we should be consistent with that [16:23] so yeah [16:23] pstolowski: spawn time is not start time [16:23] to be clear [16:23] indeed snap changes tends also to be confusing from this POV [16:23] ah ok [16:24] pstolowski: basically with spawn times all dynamically created tasks ends up after the static ones [16:24] because spawn time is when NewTask happens [16:24] pedronis: indeed [16:24] but in timings we have actualy start times, no? [16:24] zyga: no worries, the log isn't going away (i think?) [16:26] pstolowski: we might need to think a bit though because sorting by start time is not useful for things that are parallel (usually different lanes) [16:35] pedronis: snap debug timings hits v2/changes/, i think we just need to sort those on the client side [16:42] pstolowski: we don't return lanes anywhere atm [16:42] (it's kind of an internal detail) [16:43] we don't return start time (vs spawn time) anywhere either atm [16:45] pedronis: wrt lanes we might want to start returning them [16:45] emphasis on might [16:46] pedronis: it's unclear whether we can build a good multi-progress bar without them, and we want to do that [16:46] Chipaca: mmh, I see [16:46] pedronis: (because when a snap pulls in another snap, currently the UX sucks) [16:46] we need a bit to think that through [16:47] explicitly installing multiple snaps also sucks, but less :) [16:47] anyway here we might just return something extra in the debug endpoints [16:47] for pstolowski stuff [16:47] k k [16:48] it's not like we have a timeline for the other thing :) [16:48] pstolowski: so my thinking was to sort by (min(lanes), start-time, task id), except lane 0 might need to be treated specially [16:50] pedronis: sounds good. i need to digest this and continue tomorrow morning [16:51] np, need/want to step away from keyboard as well === pstolowski is now known as pstolowski|afk [17:17] * Chipaca EODs [18:12] PR snapd#7501 opened: interfaces/kubernetes-support: allow use of /run/flannel [18:14] PR snapd#7502 opened: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 [18:21] degville: hey, I'd like to document system-usernames. I was thinking inserting it in some strategic location in the forum and linking out to a separate topic. I thought the name of the linked to topic would be 'system-usernames'. thoughts on this name and also where to link from? [18:29] jdstrand: I think to start with, the top-level system-username doc might be best linked to from one of the snapcraft.yaml pages (https://snapcraft.io/docs/snapcraft-format). But it also sounds like it may become important enough to have it's own top-level page - maybe mirroring something like your original `Multiple users' post under the docs category. But we can obviously change all this easily. Otherwise, I [18:29] think the name is good - thanks for doing this! [18:32] degville: I'll create https://forum.snapcraft.io/s/system-usernames in the forum under the 'doc' category, then come up with a blurb to insert into a snapcraft.yaml page and circle back to you. sound ok? [18:45] jdstrand: perfect, thank you! [19:05] * cachio afk [19:56] roadmr Hi! Can you take a look at https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364 ? I am the maintainer of both snaps albeit from two different orgs [19:56] O_o [19:57] om26er: em suuuure but cross-publisher auto-connects are tricky :/ [19:57] ^ that applies to https://forum.snapcraft.io/t/auto-connection-request-for-piconn/13368 and https://forum.snapcraft.io/t/auto-connection-request-for-deskconn/13367 as well :-) [19:58] roadmr tricket as in "conflict of interest" ? [19:58] *tricky [19:58] om26er: no, as in it needs somewhat complex assertion wrangling [19:58] om26er: if they come from the same publisher, it's easier [19:59] om26er: interest-wise, as long as both publishers are OK with it (and you're both in this case) it should be OK [19:59] hmm the provider comes from a snap that I publish for my employer and the peer snaps are my personal projects [20:00] roadmr need your eyes on the two other similar requests as well ^ [20:01] om26er: sure, I'll have a look in a bit - but I can't really action them unilaterally, need eyes from other reviewers [20:01] but at least it'll get the ball rolling :) thanks for your patience [20:03]