[00:48] PR snapcraft#2738 opened: mypy: add coverage to tests [05:57] Good morning === pstolowski|afk is now known as pstolowski [07:02] mornings [07:32] re [07:32] sorry, baby watch duty [07:32] back now [07:33] hey pawel, good morning :) [07:54] PR snapd#7532 closed: interfaces/openvswitch: allow access to other openvswitch sockets [09:24] PR snapd#7549 opened: cmd/libsnap: use cgroup.procs instead of tasks [09:53] settle not converging https://www.irccloud.com/pastebin/qfxvW2Qh/ [09:53] pedronis: can we change settle for tests so that it has no timeout [09:54] and instead it just does more as long as a handler ran [09:54] I think it's incredibly fragile that our *unit* test suite is riddled with millisecond quantities [09:54] this is now blocking 2.42 release to opensuse [09:56] zyga: it's not that simple because we do have retries [09:56] it's fine if a test fails forever [09:56] zyga: how are you running the unit tests on opensuse? [09:56] as in, code us buggy [09:56] and loops forever [09:56] go's test stack catches that [09:56] I think the only problem would be tests that want to see failure [09:57] zyga: you say that because you haven't had to debug that [09:57] pedronis: I have to debug this :) [09:57] pedronis: I think it is not a unit tests if it has timing-sensitive concurrent operation [09:57] Chipaca: go test [09:57] anyway, as I said is not that simple [09:57] Chipaca: same as anywhere [09:57] pedronis: nothing is simple, what we have is just broken randomly [09:57] zyga: try 'go test -short' [09:57] pedronis: I want to get to deterministic [09:57] zyga: those are more likely to be unit tests [09:58] Chipaca: I don't see how this is a solution, should we switch to "go test -short" for all unit tests across distributions? [09:58] zyga: there is nothing that prevent us to use long settle on traviss [09:59] zyga: do you want solutions, or do you want to vent? [09:59] Chipaca: I want solutions, this is not one IMO [09:59] pedronis: is there a place where we cannot? [10:00] it's a timeout is set low just to fail fast locally [10:00] AIUI it's not about travis, is it? [10:00] it is not about travis [10:00] it's actually failing on my workstation right now [10:00] really ? [10:00] which one [10:00] yes [10:00] * Chipaca hands zyga a nickel [10:00] ? [10:00] which test? [10:00] yes, which test [10:01] mgrsSuite.TestRemodelSwitchToDifferentKernel [10:01] that is recent and might have a real bug [10:01] don't know [10:01] or be too slow [10:01] to start with [10:01] it has some comments that expand settle time 4 times [10:01] "because buildds are slow" [10:01] well, the test is problematic [10:01] anyway, since it affects me, I'll look [10:02] but I haven't looked at details [10:02] pedronis: problematic in which sense? [10:02] that it might be buggy for real [10:02] not just slow [10:02] aha [10:03] I'll look [10:03] anyway consider that Ian made this: https://trello.com/c/foU3iOrs/321-investigate-testremodelswitchtodifferentkernel-failure [10:03] thanks, this is useful! [10:04] what is this sorcery [10:04] a trello card created before work is done?!? [10:04] * Chipaca is so bad at trello [10:04] it might never get done [10:04] though [10:04] upcoming is like that [10:04] to be fair [10:14] PR snapd#7550 opened: spread.yaml: exclude automake cache [10:14] https://github.com/snapcore/snapd/pull/7550 <- trivial cleanup for build issues [10:14] PR #7550: spread.yaml: exclude automake cache [10:16] tests failed with "unable to contact the snap store" [10:16] https://status.snapcraft.io/ says all good [10:27] * Chipaca breaks all the policy tests and weeps [10:42] pedronis: I'm starting to suspect this last change doesn't make sense, but i need to take a break [10:43] pedronis: but checking for model before checking rev.Unset means you can't ever remove even a single revision of the model kernel [11:00] Chipaca: you need to invert the condition [11:00] of course [11:01] if not model kernel: can remove if in use: cannot remove [11:07] Chipaca: am I making sense, the flow is more complicated with the change (but more consistent) [11:07] ? [11:11] pedronis: currently it's: if !unset { if in_use { bzzzt } else { ok } } else if is_model { bzzt } else { ... } [11:12] Chipaca: that's not the question, is it? [11:12] I can try to write it down, but does that make sense [11:13] i'm trying to understand what exactly you're proposing [11:13] Chipaca: I'm not proposing "exactly" anything [11:13] I don't want to be proposing extact things [11:14] I can if it helps [11:15] Chipaca: the essence of the change is: don't care about revision if the kernel is not the model kernel [11:15] that's my understanding [11:17] do we care about the error, about it being a model kernel? [11:18] Chipaca: this: https://pastebin.ubuntu.com/p/bJ6trqPcn3/ [11:19] (not promising it makes sense, it does still pass the tests though) [11:19] can I get a review for https://github.com/snapcore/snapd/pull/7550 [11:19] PR #7550: spread.yaml: exclude automake cache [11:19] it's a one liner [11:20] and it's green :) [11:23] pedronis: I do think that makes sense, although it wasn't obvious to me. But I could blame the painkillers for that, today. [11:24] pstolowski: perhaps you can look [11:24] it's just a cache exclusion from spread.yaml [11:24] Chipaca: and we want something like this for bases/core too I suspect (if we do the change), well for the other thing using boot.InUse [11:25] *things [11:25] pedronis: yes i'm changing all three [11:25] Chipaca: thx [11:25] zyga: sure [11:26] thanks! [11:31] PR snapd#7550 closed: spread.yaml: exclude automake cache [11:32] pedronis: thanks! [11:37] * zyga goes for lunch === ricab is now known as ricab|lunch [12:06] pedronis: quick question: release app awareness was so far only implemented for strict snaps [12:06] pedronis: but there's nothing that holds us to this design, should we expand it to cover classic confinement? [12:07] zyga: I don't even remember why? [12:07] why yes or why not? [12:07] why we didn't cover classic? [12:07] I'm just not sure it was a design [12:07] because the code adding tracking was in close proximity to other "strict" setup logic [12:07] but I think it's not meant to be this way [12:07] it feels like we didn't notice [12:07] yea, that's not a design [12:07] it's a bug [12:07] I added a todo for it [12:07] yeah, thanks for confirming that [12:08] I'll untangle that [12:35] cachio: seen this in tests? dial tcp 91.189.92.41:443: connect: connection refused [12:42] cmatsuoka, hi let me check [12:48] cmatsuoka, I can't see that, do yoiu have a log? [12:50] cachio: yes, https://api.travis-ci.org/v3/job/592790683/log.txt [12:50] cachio: look for connection refused [12:52] cmatsuoka, seems to be related to the store, let me talk to them [13:01] one sec [13:01] cachio: zyga: standup? [13:22] blake_r (in case it was not answered, seems not) if maas-cli plugs into a slot in maas, then installing maas-cli would pull in the default provider but installing maas alone would not pull in every snap declaring a plug for it (I suspect that is how this is how these two snaps interact) [13:24] oSoMoN: is the chromium vaapi work mentioned in https://discourse.ubuntu.com/t/monday-21st-january-2019/9434/8 now merged in normal chromium snaps? [13:26] sergiusens: its the other way [13:27] sergiusens: "maas" plugs into "maas-cli", so installing "maas" will install "maas-cli", correct? [13:31] oSoMoN: at least I'm getting somewhat lower CPU use with snap versus native package of my distro (same video, full screen, drop from 30-40% to 20-30%). hmm, if only there was a way to query directly whether VAAPI is currently being used by software. [13:33] blake_r if you declare a default provider, yes [13:33] ohhh so snapd can now resolve dependencies? snapian.io here we gooooo 💪 [13:33] /snap/gnome-calculator/current/meta/snap.yaml can be used for insipiration === ricab|lunch is now known as ricab [13:34] it can try and satisfy interfaces [13:37] oh, I forgot to mention one thing [13:37] over weekend (I realize that's a late recollection) I played with a static analyzer [13:37] Mirv, no it's not, but thanks for asking, it had slipped off my radar, I will test again and if everything still works I'll merge it [13:37] while somewhat fiddly to setup I found the results useful [13:37] it's not coverity [13:41] ok, thanks oSoMoN! and it seems intel_gpu_top is a good tool to check whether video hardware is being used - I can see a clear distinction between eg a browser and mpv [14:01] "Kindly correct this anomaly." [14:01] * Chipaca hmms [14:02] Chipaca: well at least they asked nicely, right? 🤷 [14:02] true, true [14:09] * diddledan blows up the anomoly with a photon torpedo and some inversed polarities [14:10] a tachyon beam is probably worth while, too [14:10] diddledan: just don't cross the tachyon beams, or sth [14:11] and make sure you're travelling faster than 88 jiggerwatts [14:50] * zyga is tired, needs a break/nap [14:50] also, my daughter is 11 today [14:50] so perhaps time to EOD [14:51] zyga: congrats to her! 🎂 [14:51] roadmr: thank you :) [14:51] I'll let her know [14:52] store still wonky [14:52] yeah, I'll take a nap now [14:52] ttyl [14:58] * Chipaca sharpens his hunting knife an goes for a cuppa [15:06] PR snapd#7551 opened: tests: fix the how the systemd-journald.service is restarted during the prepare [15:12] * cachio lunch [15:49] sergiusens, hi, any chance https://github.com/sergiusens/snapcraft-preload/pull/37 could be merged? [15:49] PR sergiusens/snapcraft-preload#37: add option to only redirect paths for /dev/shm/* === pstolowski is now known as pstolowski|afk [16:11] PR snapcraft#2736 closed: cli: prompt for login if required [16:20] sergiusens how do I create app in snap calling "pkill" which I have access to from 'process-control' without actually shipping pkill in my snap? [16:22] sergiusens I know I can do wrapper script, but I wonder is there is way to do it without wrapper script [16:23] sergiusens I guess even is snapcraft allows it. snapd will probably refuse it? [16:30] ondra snapd for some reason does not allow command entries that start with / even though it allows it in shebangs (or wrappers), so all your enquiries are for the snapd team [16:31] sergiusens yep I realised so [16:37] PR snapd#7552 opened: tests: add new option "invert" to retry-tool [17:40] zxre [17:40] re [17:40] hey ondra [17:40] how are you doing [17:40] the nap worked, I feel so much better now [17:45] zyga: go sing happy birthday [17:45] Chipaca: we did that already [17:46] I prefer to avoid granpas and grammas that had some event-booze [17:46] kids are off upstairs already [17:46] I'm here to ... [17:46] merge this https://github.com/snapcore/snapd/pull/7421 [17:46] PR #7421: cmd/snap-confine: unmount /writable from snap view [17:46] whee :) [17:47] now what's the state of https://github.com/snapcore/snapd/pulls/zyga [17:47] PR snapd#7421 closed: cmd/snap-confine: unmount /writable from snap view [17:51] dire :) [17:51] maybe I should go and have cake instead [17:51] ;-) [17:58] Chipaca: are you still working? [17:58] no [17:58] i retired [19:14] PR snapcraft#2738 closed: mypy: add coverage to tests [20:10] When trying to rsync to a newly created ubuntu core instance I get a "Permission denied" from mkdir. I'm guessing it's an apparmor thing. Is there any good reading on this? [20:22] hi all, i'm seeing an issue where my snap isn't building on the snapcraft.io servers, but builds fine locally (with the command given from the site) [20:22] HEAD is now at 2bd9643cee Add/Update CHANGELOG-1.16.md for v1.16.0-rc.2. [20:22] +++ [1003 19:50:48] Building go targets for linux/amd64: [20:22] ./vendor/k8s.io/code-generator/cmd/deepcopy-gen [20:22] find: ‘rsync’: No such file or directory [20:22] find: ‘rsync’: No such file or directory [20:22] ./hack/run-in-gopath.sh: line 33: _output/bin/deepcopy-gen: Permission denied [20:22] make[1]: *** [gen_deepcopy] Error 1 [20:22] Makefile.generated_files:152: recipe for target 'gen_deepcopy' failed [20:22] Makefile:559: recipe for target 'generated_files' failed [20:22] make: *** [generated_files] Error 2 [20:22] Failed to run 'override-build': Exit code was 2. [20:22] ^ sorry, I meant to send that as a snippet [20:22] ijohnson are you around? Maybe you can answer https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258/5 [20:23] joedborg add rsync to build-packages [20:23] if using multipass, this should be addressed soon. [20:23] if using --use-lxd, it will take a bit longer [20:23] sergiusens: locally, it works fine with both multipass and lxd [20:23] it's only on the snapcraft io servers that it fails [20:24] we are moving to the common denominator for building, and that is the same env used by the builders [20:24] joedborg yeah, build servers are more minimal than minimal and we are going to be aligning with that [20:25] sergiusens: okay thanks, I'll try now with adding rsync to build-packages [20:36] pokk: what are you rsync'ing? [20:36] pokk: joedborg: are you looking at the same issue, or is it a coincidence? [20:37] Chipaca: mines to do with buildign only [20:37] joedborg: ok :) [20:37] strange coincidence then [20:38] looks like it :) [20:38] pokk: 'trying to rsync a newly created ubuntu core instance' sounds like a fascinating exploration of a terribly bad idea, but do tell me more [20:41] Chipaca: he did say "trying to rsync *to* a newly created" :P [20:42] roadmr: s/he/they/ [20:42] roadmr: and, curiouser and curiouser [21:06] working now thanks sergiusens ! [21:29] PR snapd#7553 opened: cmd/snap: update 'snap find' help because it's no longer narrow [22:07] PR snapd#7554 opened: recovery: update fde-utils calls [23:00] PR core-build#54 opened: initramfs: update unlock keyfile parameter [23:18] PR snapcraft#2734 closed: SnapcraftError refactoring