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