| mup | PR snapcraft#2738 opened: mypy: add coverage to tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2738> | 00:48 |
|---|---|---|
| zyga | Good morning | 05:57 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:02 |
| zyga | re | 07:32 |
| zyga | sorry, baby watch duty | 07:32 |
| zyga | back now | 07:32 |
| zyga | hey pawel, good morning :) | 07:33 |
| 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> | 07:54 |
| mup | PR snapd#7549 opened: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549> | 09:24 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 09:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:14 |
| zyga | tests failed with "unable to contact the snap store" | 10:16 |
| zyga | https://status.snapcraft.io/ says all good | 10:16 |
| * Chipaca breaks all the policy tests and weeps | 10:27 | |
| Chipaca | pedronis: I'm starting to suspect this last change doesn't make sense, but i need to take a break | 10:42 |
| Chipaca | pedronis: but checking for model before checking rev.Unset means you can't ever remove even a single revision of the model kernel | 10:43 |
| pedronis | Chipaca: you need to invert the condition | 11:00 |
| pedronis | of course | 11:00 |
| pedronis | if not model kernel: can remove if in use: cannot remove | 11:01 |
| pedronis | Chipaca: am I making sense, the flow is more complicated with the change (but more consistent) | 11:07 |
| pedronis | ? | 11:07 |
| Chipaca | pedronis: currently it's: if !unset { if in_use { bzzzt } else { ok } } else if is_model { bzzt } else { ... } | 11:11 |
| 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:12 |
| 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:13 |
| pedronis | I can if it helps | 11:14 |
| 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:15 |
| Chipaca | do we care about the error, about it being a model kernel? | 11:17 |
| pedronis | Chipaca: this: https://pastebin.ubuntu.com/p/bJ6trqPcn3/ | 11:18 |
| 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:19 |
| zyga | and it's green :) | 11:20 |
| 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:23 |
| 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:24 |
| pedronis | *things | 11:25 |
| Chipaca | pedronis: yes i'm changing all three | 11:25 |
| pedronis | Chipaca: thx | 11:25 |
| pstolowski | zyga: sure | 11:25 |
| zyga | thanks! | 11:26 |
| 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:31 |
| zyga | pedronis: thanks! | 11:32 |
| * zyga goes for lunch | 11:37 | |
| === ricab is now known as ricab|lunch | ||
| 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:06 |
| 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:07 |
| zyga | I'll untangle that | 12:08 |
| cmatsuoka | cachio: seen this in tests? dial tcp 91.189.92.41:443: connect: connection refused | 12:35 |
| cachio | cmatsuoka, hi let me check | 12:42 |
| cachio | cmatsuoka, I can't see that, do yoiu have a log? | 12:48 |
| cmatsuoka | cachio: yes, https://api.travis-ci.org/v3/job/592790683/log.txt | 12:50 |
| cmatsuoka | cachio: look for connection refused | 12:50 |
| cachio | cmatsuoka, seems to be related to the store, let me talk to them | 12:52 |
| zyga | one sec | 13:01 |
| pedronis | cachio: zyga: standup? | 13:01 |
| 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:22 |
| 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:24 |
| blake_r | sergiusens: its the other way | 13:26 |
| blake_r | sergiusens: "maas" plugs into "maas-cli", so installing "maas" will install "maas-cli", correct? | 13:27 |
| 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:31 |
| 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:33 |
| === ricab|lunch is now known as ricab | ||
| sergiusens | it can try and satisfy interfaces | 13:34 |
| 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:37 |
| 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 | 13:41 |
| Chipaca | "Kindly correct this anomaly." | 14:01 |
| * Chipaca hmms | 14:01 | |
| roadmr | Chipaca: well at least they asked nicely, right? 🤷 | 14:02 |
| Chipaca | true, true | 14:02 |
| * diddledan blows up the anomoly with a photon torpedo and some inversed polarities | 14:09 | |
| diddledan | a tachyon beam is probably worth while, too | 14:10 |
| Chipaca | diddledan: just don't cross the tachyon beams, or sth | 14:10 |
| diddledan | and make sure you're travelling faster than 88 jiggerwatts | 14:11 |
| * 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:50 |
| roadmr | zyga: congrats to her! 🎂 | 14:51 |
| zyga | roadmr: thank you :) | 14:51 |
| zyga | I'll let her know | 14:51 |
| zyga | store still wonky | 14:52 |
| zyga | yeah, I'll take a nap now | 14:52 |
| zyga | ttyl | 14:52 |
| * Chipaca sharpens his hunting knife an goes for a cuppa | 14:58 | |
| 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:06 |
| * cachio lunch | 15:12 | |
| 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> | 15:49 |
| === pstolowski is now known as pstolowski|afk | ||
| 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:11 |
| 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:20 |
| ondra | sergiusens I know I can do wrapper script, but I wonder is there is way to do it without wrapper script | 16:22 |
| ondra | sergiusens I guess even is snapcraft allows it. snapd will probably refuse it? | 16:23 |
| 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:30 |
| ondra | sergiusens yep I realised so | 16:31 |
| mup | PR snapd#7552 opened: tests: add new option "invert" to retry-tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7552> | 16:37 |
| 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:40 |
| Chipaca | zyga: go sing happy birthday | 17:45 |
| zyga | Chipaca: we did that already | 17:45 |
| 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:46 |
| 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:47 |
| zyga | dire :) | 17:51 |
| zyga | maybe I should go and have cake instead | 17:51 |
| zyga | ;-) | 17:51 |
| zyga | Chipaca: are you still working? | 17:58 |
| Chipaca | no | 17:58 |
| Chipaca | i retired | 17:58 |
| mup | PR snapcraft#2738 closed: mypy: add coverage to tests <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2738> | 19:14 |
| 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:10 |
| 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:22 |
| 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:23 |
| 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:24 |
| joedborg | sergiusens: okay thanks, I'll try now with adding rsync to build-packages | 20:25 |
| 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:36 |
| joedborg | Chipaca: mines to do with buildign only | 20:37 |
| Chipaca | joedborg: ok :) | 20:37 |
| Chipaca | strange coincidence then | 20:37 |
| 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:38 |
| roadmr | Chipaca: he did say "trying to rsync *to* a newly created" :P | 20:41 |
| Chipaca | roadmr: s/he/they/ | 20:42 |
| Chipaca | roadmr: and, curiouser and curiouser | 20:42 |
| joedborg | working now thanks sergiusens ! | 21:06 |
| 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> | 21:29 |
| mup | PR snapd#7554 opened: recovery: update fde-utils calls <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7554> | 22:07 |
| mup | PR core-build#54 opened: initramfs: update unlock keyfile parameter <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/54> | 23:00 |
| mup | PR snapcraft#2734 closed: SnapcraftError refactoring <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2734> | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!