[00:53] Hi there, anybody up? [02:33] PR snapcraft#2094 closed: storeapi: better handle network errors and retries === sergiusens_ is now known as sergiusens [05:00] morning [05:56] PR snapd#5085 closed: many: fix false negatives reported by vet [05:56] Good morning [05:56] hey zyga [05:58] Man, what a terrible night [05:58] mvo: zyga: hey [05:58] Both kids stormed our bed at night [05:59] We slept like sardines in a can [06:00] hey mborzecki [06:04] mvo: google images are out of date again [06:04] we need to bump 18.04 snapshot date [06:05] zyga: aha, yes. are you already on it? if not I push something in 1min [06:05] yes, on it [06:05] ta [06:06] zyga: can you take a look at https://github.com/snapcore/spread-images/pull/10 i think cachio has addressed most of the issues [06:06] PR spread-images#10: New task to add debian-sid as a gce image [06:08] PR snapd#5093 opened: spread: bump bionic snapshot date [06:11] does anyone have access to edit other people's posts on the forum? [06:11] mvo: maybe you? :) [06:11] zyga: maybe, I can try. what post would that be? [06:12] I would love if someone would add ``` around the big chunk here: https://forum.snapcraft.io/t/problem-with-network-access-in-strict-confinment/5059/4 [06:12] the seccomp profile is hard to read when it's full of OMG HEADER [06:12] wow, that's one awkwardly formatted post [06:13] zyga: please reload [06:15] mvo: thank you very much! [06:20] mborzecki: man, that's a long PR still [06:20] mborzecki: did you spellcheck it? [06:20] reading it quickly I suspect it's not fully clean yet [06:20] but maybe shell is tricky on me [06:20] mvo: https://github.com/snapcore/snapd/pull/5093 [06:20] PR #5093: spread: bump bionic snapshot date [06:27] zyga: non yamls parts looked fine, although i don't like how global variables come into play, but it's either that or sprinkling more checks around the code making it even less readable [06:28] zyga: as for yaml, it'd be nice to have tool (niemeyer?) that extracts keys, dump that into temp files and run them through shellcheck, something we could use in our tests too [06:28] yeah [06:28] did you run spellcheck on the .sh parts? [06:28] spellcheck? thought you meant shellcheck :) [06:28] shellcheck [06:29] sorry, spellchecker "corrects" things [06:29] hahaha [06:31] zyga: no i did not shellcheck it myself, but this commit looked like it's making shellcheck shut up https://github.com/snapcore/spread-images/pull/10/commits/ab849c9f1f8cb91cde4395fcf69e245c9e377b56 and those are legit issues flagged by the checker [06:31] PR spread-images#10: New task to add debian-sid as a gce image [06:37] zyga: hmm `yq -r < spread.yaml .prepare | shellcheck -` [06:37] oooooh [06:37] man [06:37] can we do that for all our jobs? [06:38] yup, why not ;) there's only a handfull of keys that take shell scripts [06:38] mborzecki: can you do it? :) [06:38] find -name task.yaml -exec ... [06:38] I would suggest to write spread-shellcheck helper [06:39] zyga: yup, let me play with it a bit [06:40] cool stuff! [06:40] * mvo hugs mborzecki [07:08] PR snapd#5094 opened: tests: testrun with debug to get to the bottom of the 18.04 failure === pstolowski|afk is now known as pstolowski [07:10] morning [07:20] hmm [07:20] mvo: why do we need the -extra package anyway? [07:20] is it for squashfs? I hope not [07:20] moin moin [07:22] zyga: let me check [07:26] zyga: so i have the script https://paste.ubuntu.com/p/2QWv85s5bG/ but fixing everything will be an arduous task [07:30] mborzecki: let's add it but make it optional [07:30] mborzecki: we can fix things little by little [07:34] * zyga would love a review for https://github.com/snapcore/snapd/pull/5081 [07:34] PR #5081: interfaces/apparmor: add chopTree [07:35] apw: hey, quick question - what happened to linux-image-extra-$(uname -r) in bionic? is that gone for good and should we use linux-image-extra-$(uname -r) now if we need this? the kernel package changelog is a bit sparse on details about this [07:36] mvo, i assume you mean linux-modules-extra-* ... and yes that is the new name, and there should be no circumstance where you need to know its name [07:37] hmm :D [07:37] reality disagrees but I will look from the side and listen [07:37] mborzecki: I have two super long train rides in front of me in the next few days (4 actually in total). so fixing the scripts sounds prefect? [07:37] mvo: 4 in total!? [07:37] apw: oh, it is a normal dependency now? [07:37] zyga: well, 2 trips with one inbound, one outbound [07:38] ah, you have to change trains? [07:38] zyga, was that for me? [07:38] apw: for me [07:38] mvo, it is a normal dependency of the right meta package [07:39] apw: cool, I will see if our tests are happy without and if it gets pulled in automatically. t [07:39] apw: this is GCE so things might be a bit different [07:39] maybe indeed, but regardless that is the new naw [07:39] name if you need it [07:43] apw: thank you! [07:44] zyga: I was suspecting we need -extra for the broadcom asic test but it seems it is not in there (at least not under linux-kernel-bde.ko) [07:44] ahhh [07:45] makes sense [07:46] zyga: anyway, test is running, we will know shortly :) [07:46] mvo: i think i can automate some/most of the simple fixes [07:46] mborzecki: cool [07:46] it's basically adding #shellcheck source=tests/lib/ when sourcing, and quoting "$TESTSLIB" in redirects [07:46] mborzecki: that is even better [07:47] mborzecki: yeah, that sounds pretty good [07:47] mborzecki: it would be nice if spread -shellcheck would be a thing [07:53] mvo: what I find odd is that it worked before [07:53] is that rename a thing that happened just now? [07:57] PR snapd#5093 closed: spread: bump bionic snapshot date [07:58] zyga: it happend some days ago but I suspect is that gce kernenls packages are updated less often maybe [07:58] aha [08:18] zyga: 5094 was run without errors but for some reason the machine discard hung. I will restart, but it looks like this fixes the 18.04 issues [08:19] fingers crossed, thank you for pursuing that === chihchun_afk is now known as chihchun [08:26] * zyga is super sleepy today [08:26] sorry folks, last night was not very good [08:57] #5075 looks like a trivial PR, needs 2nd review [08:57] PR #5075: snap/env: fix env duplication logic [09:06] 5094 is even more trivial and needs a review (with the added bonus of unblocking tests!) [09:07] done === chihchun is now known as chihchun_afk [09:07] PR snapd#5094 closed: tests: drop `linux-image-extra-$(uname -r)` install in 18.04 [09:07] * mvo hugs zyga [09:08] irccloud supports slack === chihchun_afk is now known as chihchun [09:25] zyga: in 5075 you write: "it does not seem to work in practice". how did you test? [09:25] I opened a terminal with dash in it [09:25] echo'ed the expression [09:26] PR snapd#5095 opened: snapstate: support getting new bases/default-providers on refresh [09:26] and got an empty string [09:26] and then confirmed that I have the desired value in the full variable already [09:28] PR snapd#4750 closed: store: getStructFields now take pointers [09:29] PR snapd#4443 closed: [RFC] snap: improve error for snaps not available in the given context === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:44] mvo: 4750 was too old, I think merging it broke master [09:44] I mean it was green but from too long ago [09:44] afaict it other things need fixing now [09:45] mvo: I get a panic on master trying to run store tests [09:46] (another issue of PRs being around forever) === chihchun is now known as chihchun_afk [09:58] pedronis: uh, ok. let me have a look === chihchun_afk is now known as chihchun [10:05] mvo: the fix is trivial probably, mostly pointing out that we need to be a bit careful with old green stuff :/ [10:08] pedronis: indeed, we should probably ask the old PRs to remerge master [10:21] * Chipaca on a very flaky connection rn [10:25] mvo, hmm, on core installs my /snap dir carries fragments from the core snap build recently (not sure when this started) ... is that wanted ? [10:25] ogra@localhost:~$ ls /snap/ [10:25] README bin XXXXXX XXXXXX-kernel core manifest.yaml snapcraft.yaml [10:26] (the XXXXXX snaps are customer snaps (kernel/gadget) ... i'm referring to the yaml files) [10:26] ogra_: is that core getting built with snapcraft? [10:26] Chipaca, thats just core from the store [10:27] edge channel [10:27] Chipaca, ogra_ - it is, I think the new snapcraft is dropping those files now [10:27] looks odd [10:27] yeah, looks like we need some cleanup there [10:27] you might want to add info about these files to the README perhaps [10:27] (if they are wanted to be kept there) [10:27] I don't know why, but yes, if it does the manifest thing snapcraft puts it in /snap in the snap [10:28] yeah [10:28] which in the core snap becomes /snap [10:28] yes [10:28] which is probably fine [10:28] well [10:28] a little surprising, but having manifest.yaml is nice [10:29] ogra@localhost:~$ ls /snap/core/current/snap/ [10:29] manifest.yaml snapcraft.yaml [10:29] you haven them twp levels down as well :) [10:29] *two [10:29] ogra_: d'oh [10:29] (though indeed they are the same files effectively) [10:29] ogra_: so it's writable-paths copying them over [10:30] well ... [10:30] ogra_: all your problems are initramfs-tools' fault [10:30] writable paths mounts core as / first [10:30] then bind-mounts writable on top and populated [10:30] *populates [10:30] so they *are* the same files [10:31] ogra_: I think you're agreeing with me [10:32] no, i wasnt initially ... but after a test i do now :P [10:32] gra@localhost:~$ sudo touch /snap/manifest.yaml [10:32] ogra@localhost:~$ sudo touch /snap/core/current/snap/manifest.yaml [10:32] touch: cannot touch '/snap/core/current/snap/manifest.yaml': Read-only file system [10:32] so yeah, somehow they are copied around [10:33] ogra_: so it's probably set to sync or compat or whatever and we don't want it to be [10:33] well, you want /snap/bin synced [10:33] ogra_: you do? [10:33] and you want to have all the mountpoints and README too [10:33] well, you want it writable at least [10:33] ogra_: /snap needs to be writable [10:34] right [10:34] ogra_: because that's where we create /snap/ogras-killer-snap/ [10:34] ogra_: snapd creates the README i think (but i'm not certain), and /bin [10:34] ogra_: i mean /snap/bin [10:35] yeah and the symlinks in there [10:35] ogra_: so it _should_ just work if it's mounted to writable without any fanciness [10:35] ogra_: the symlinks are created on snap install [10:35] ogra_: they won't be in core [10:35] /snap auto persistent transition none [10:35] not synced ... only persistent [10:36] ogra_: wasn't "transition" the one that copied things over? [10:36] oh, right [10:36] so we want that dropped [10:37] ogra_: i think we should try :-) wouldn't be surprised if people depended on it at this point ¯\_(ツ)_/¯ [10:37] (well, set to none effectively= [10:37] * zyga needs to take a break, back pain sucks today [10:37] I cannot concentrate on anything [10:38] * Chipaca hugs zyga [10:44] mvo, bug 1766845 [10:44] Bug #1766845: /snap/snapcraft.yaml and /snap/manifest.yaml in rootfs on ubuntu-core installs [11:04] ogra_: ta [11:04] PR snapd#5096 opened: snap: improve error for snaps not available in the given context [11:04] (i'd have coocked a patch but i'm super busy with customer stuff) [11:17] PR snapd#5097 opened: store: getStructFields takes pointers now === sergiusens_ is now known as sergiusens === pstolowski is now known as pstolowski|lunch [12:07] off to pick up the kids [12:08] i'm down to 95 tests that still raise shellcheck errors [12:17] PR core-build#27 opened: config/etc/system-image/writable-paths: do not transition /snap [12:19] ogra_, zyga: ^- this is hopefully all we need [12:19] ack [12:20] yeah [12:20] (acked) [12:20] mvo: looks good, do you know why it was transitional to begin with? [12:21] zyga: I don't, I suspect cargo-culted [12:24] or it comes still from when building images really installed snaps? [12:24] pedronis: yeah, I was thinking about this, it might be but that was really a long time ago. could still be a leftover === Kamilion|ZNC is now known as Kamilion [12:26] PR snapd#5097 closed: store: getStructFields takes pointers now [12:32] PR core-build#28 opened: new ubuntu-core-config 0.6.40+ppa49 upload [12:51] * kalikiana out for a break, back in a bit [12:55] mvo: i'm skipping the standup today: half my face is asleep, and the other half is in moderate pain [12:56] mvo: i hope to be feeling better before eod though :-) [12:57] Chipaca: uhh, ok. good luck and get well! [12:57] niemeyer: about the tempfile thing we discussed yesterday, no can do (i just need the name, not an os.File). I might need to land it as is and then in a followup move it to use renameat2(2) [12:58] Chipaca: I think as long as we're using something less predictable, it should be okayish [12:58] mvo: getting well was the reason of the exercise, it's just painful the first few hours post [12:58] niemeyer: k [12:59] Chipaca: I'm not sure about how to do that and still some of the logic in there tho [12:59] Chipaca: I mean, IIRC it's actually reading left-behinds [12:59] niemeyer: it does a sanity check on the filename, which can still be done [12:59] Chipaca: Cool [13:00] niemeyer: in fact i can probably keep that bit the same [13:00] niemeyer: just that instead of it adding .~N~ to the filename, with N sequential, it can be a 9-digit random thing === pstolowski|lunch is now known as pstolowski [13:01] Chipaca: Yeah, it's fine if it's known.. I wasn't sure if it was actually trying to read from disk, but I recall you mentioned follow ups actually use the state now [13:22] PR core-build#27 closed: config/etc/system-image/writable-paths: do not transition /snap [13:22] re [13:50] favourite piece from our tests so far: echo "Ensure `snap advise-snap --command` lookup works" [13:50] notice the backticks [13:55] PR core-build#28 closed: new ubuntu-core-config 0.6.40+ppa49 upload [14:06] mborzecki: NICE :) [14:07] mborzecki: I think having shellcheck on tests has been long overdue [14:07] kudos for figuring out a smart way to implement it [14:15] PR snapcraft#2087 closed: ci: setup AppVeyor [14:19] hey folks, an announcement, snap store downloads are failing intermittently, we're investigating [14:20] roadmr, my automated review is taking an abnormally long time as well, getting " [14:20] Task c0daed77-5616-4837-9e5f-e7d972405a0f is waiting to be retried." [14:20] roadmr: ack, thank you for sharing [14:20] kyrofa: yes, automated reviews require downloading the snap from the service that's having trouble. [14:21] roadmr, makes sense, thank you === chihchun is now known as chihchun_afk [14:27] kyrofa: fwiw I cleared the queue for snapcraft by discarding the offending snap with the task fail [14:27] sergiusens, yeah this is DPL stuff [14:28] ah [14:33] Issue snapcraft#2029 closed: Proper error for apt hash sum mismatches [14:33] Issue snapcraft#2030 closed: Properly invalidate the cache if sources change [14:33] PR snapcraft#2079 closed: repo: catch error updating the package cache [14:44] mborzecki: hey [14:44] mborzecki: do you have `entr` command on your system? [14:46] zyga: nope [14:47] is it available in arch? [14:48] zyga: it's in aur [14:48] can you grab it please? :-) [14:48] zyga: ok, got it now [14:49] ok, [14:49] can you fetch my remote please [14:49] then checkout zyga/tweak/make-live-check [14:49] and run make live-check [14:50] hello folks, (kyrofa) we believe the snap store download situation is under control, please do report any slowness/timeout issues you see [14:50] Thanks roadmr [14:51] roadmr: what was the issue? [14:51] zyga: the same as yesterday's :) only this time we got it under control much faster because we'd seen it yesterday [14:51] oh, and what was broken yesterday? [14:52] roadmr, downloads seem to be hovering around 150-200k, where typically they're like 8M [14:52] kyrofa: which snap are you looking at? [14:52] Nextcloud [14:53] Takes forever to get started, too [14:53] zyga: soma load balancing issues with our CDN which was slamming one of our origin servers [14:53] kyrofa: oh you mean when you do "snap install/download" it takes a moment to actually start? hmm. [14:53] Yeah, just shows the snapd .oOo.oOo... ah, and now " Download snap "nextcloud" (6519) from channel "beta/pr-519" (received an unexpected http response code (503) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/njObIbGQEaVx1H4nyWxchk1i8opy4h54_6519.snap?t=2018-04-25T18:00:00Z&h=82184e2ff20695f22f99c8093efdc6c7086e970e)" [14:54] roadmr: aha, interesting, thanks for sharing [14:54] mborzecki: how do you like it? [14:54] mborzecki: I'd like to propose it [14:54] we'd have a skeleton makefile where we could again propose changes [14:55] kyrofa: oh wow... sorry about that, we're fiddling some knobs now, hang on [14:56] PR snapd#5098 opened: Makefile: add initial makefile with live-check command [14:57] oho [14:58] I think mborzecki's machine didn't like running unit tests that much [15:11] pstolowski: how about you [15:12] zyga: is it about zyga/tweak/make-live-check ? [15:12] yep [15:12] zyga: will give it a go in a moment [15:12] thanks [15:12] I have it set to half of my 2nd screen [15:14] hmm [15:14] and somehow I get this [15:14] panic in store.go getStructFields https://www.irccloud.com/pastebin/KjSWfVjC/ [15:14] mvo: ^ does this ring any bells? [15:14] zyga: yes, please merge master [15:14] yes, that's the thing that was broken on master for a bit [15:15] should be fixed now [15:15] mvo: ah perfect [15:16] yep, works now, thank you === chihchun_afk is now known as chihchun [15:21] Issue snapcraft#1707 closed: Implement deploy keyword for travis [15:22] zyga: what is entr there? i don't have that [15:23] pstolowski: install it, it's a small helper that uses inotify [15:23] invaluable tool once you know it :) [15:23] zyga: allright, got it, running [15:26] pstolowski: how do you like it? [15:33] zyga: it's interesting idea and I can see how it may be useful for some; i personally prefer to run tests on request only, not on save - I save very often but only run tests when I know the code is more less ready [15:33] pstolowski: the idea here is that you can save anytime you want but just glance at the other screen to see where you are [15:33] and by the time you glance the tests may have finished [15:34] (if we neuter the insanely slow seccomp test that dominates the whole test suite) [15:34] we have a lot of slow tests [15:34] mvo: is there a way to tag that specific test (the one that compiles 10s of C files) as slow? [15:34] from some point of view [15:34] pedronis: no, really, that's the slowest by far [15:34] I find any suite that takes more than 1s kind of slow [15:34] ah [15:35] yeah but the general trend is that seccomp is slowest of the tree [15:35] then other things are slower than they should be [15:35] but not that terrible [15:35] time to run tests per package https://www.irccloud.com/pastebin/Ps05PFvs/ [15:35] anyway I tend to often write tests first and be intersted only in the new ones [15:35] and then more in all [15:36] oh, apparmor tests are slow [15:36] they probably do something foolish [15:36] like run real programs [15:37] hmm [15:37] odd, when I run apparmor tests alone they are not that lsow [15:38] at least here quite a few packates takes >10s [15:43] what was that command that shows executables as they are started [15:43] using netlink [15:45] ha [15:45] got it [15:55] hmm [15:55] no luck actually [15:55] I don't know why that test is that much slower [15:55] running the test (with prior compilation) https://www.irccloud.com/pastebin/ckQ1afb5/ [15:56] monitored processes/tasks during said test execution https://www.irccloud.com/pastebin/uPMQuQTe/ [16:01] pedronis: is there a nice way to profile go code? === Lukewh_ is now known as Lukewh === AndyWojo_ is now known as AndyWojo [16:23] I tried using go tool pprof and go test -cpuprofile but it doesn't show anything sane [16:23] the profile is 350~ bytes long usually [16:23] and top10 shows nothing [16:27] I also looked at https://bieker.ninja/go/2015/01/22/profiling-go.html but that confirms what I just did [16:27] for the record: [16:27] https://www.irccloud.com/pastebin/PJnCF5dM/ === pstolowski is now known as pstolowski|afk [16:30] zyga: I don't think we have a concept of slow tests currently [16:30] mvo: yeah but golang does I think [16:30] mvo: anyway, I think the goal is to fix the slow tests [16:30] but maybe the seccomp one is more special [16:30] I don't understand why tests are not showing up in any of the bechmark results [16:32] mvo: offtopic, do you have time for a simple code review? https://github.com/snapcore/snapd/pull/5086 [16:32] PR #5086: osutil,interfaces,cmd: use fewer hardcoded strings [16:38] zyga: no response on the factory list either, I think we should just run the osc command to submit to factory, there are automated checks and that will give us some things to do [16:38] Caelum: ack [16:38] let's do that and let's see what happens [16:38] thank you for trying [16:38] it's sad that those MLs are so dad [16:38] no problem [16:38] dead [16:42] PR snapcraft#2086 closed: tests: update metadata store integration test, no previous push required [17:43] PR snapcraft#2105 opened: project_loader: recursively process after of remote parts [17:45] * kalikiana wrapping up for the day === Guest92578 is now known as devil === devil is now known as Guest47087 === Guest47087 is now known as devil_ [18:07] kenvandine: I did and will circle back around to it. note, there is a one week voting period so it isn't late yet [18:08] kenvandine: oh heh, I answered your question from the other channel here :) [18:08] lol [18:08] that's cool :) === fireclaw_pi is now known as pi_fireclaw [18:49] Issue snapcraft#2099 closed: Issues building snap from my favorite and best GUI RSS reader, Feedreader [19:06] PR snapd#5099 opened: testutil: rename UNMOUNT_NOFOLLOW to umountNoFollow [19:07] PR snapd#5100 opened: testutil: document all fake syscall/os functions [19:09] PR snapd#5101 opened: testutil: don't dot-import check.v1 [19:09] * zyga wonders if anyone is up for three super trivial reviews [19:28] Issue snapcraft#1689 closed: Implement "on to" selectors (statements) in project_loader [19:28] PR snapcraft#2088 closed: grammar: support compound on..to statement [20:12] sergiusens (cc sbeattie): hey, I've been working on the snap usn stuff. we noticed that libssl is in stage-packages for a ton of stuff. libssl is in the core snap. can you remind me why snapraft isn't defaulting to using the libs in core if they are there (excepting glibc, which I know snapcraft doesn't stage) [20:13] jdstrand: we might not be cutting off the chain for stage-packages deps sooner than desired [20:14] jdstrand: want us to have a sit next week and try things out to get to a better place? [20:14] sergiusens: sure, we can chat about that [20:15] Might be nice to have a solid contract about what is in the core snap/what we can rely on staying there [20:15] I seem to remember things being removed in the past [20:17] rsyslog? [20:20] As I recall, we really have no idea what's in there. No manifest [20:39] kyrofa, sergiusens: it was, then it was put back. there is a file in the core snap that cnapcraft could look at: /snap/core/current/usr/share/snappy/dpkg.list [20:39] No way [20:39] That's nice to see [20:40] jdstrand, but what guarantee do we have that things won't be removed? [20:40] Especially the way we need to stop apt's dependency crawling... it's kinda hard-coded and difficult to override [20:40] kyrofa: that is a question for the snapd team, in particular mvo [20:41] kyrofa: my understanding is that nothing is supposed to be removed [20:41] That _was_ mine as well, until rsyslog [20:42] If the snapd folks agree, then we're good [20:42] I can't speak for them, but they put it back. I think it is understood that they can't just remove stuff once it is there [20:42] I mean, not everyone uses snapcraft [20:43] and people can 'organize' things away so they use the core stuff too [20:43] so, we shouldn't be removing stuff anyway [20:43] Yeah I agree [20:44] iirc, rsyslog was a learning opportunity. it hasn't come up again [21:11] jdstrand: hey [21:11] jdstrand: how are preparations for next week? [21:17] zyga: I think I have one in the bag (snap usns). the resquash with electron-builder I'll look at tomorrow [21:18] woot, USN will certainly improve the ecosystem [21:18] yes. looking at how many things are out of date, that is *definitely* true [21:19] what's step two? mass mailing? [21:19] jdstrand: if you feel like taking a 3 minute break I made some super short and trivial PRs and labelled them as "simple": https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+author%3Azyga+label%3ASimple === devil is now known as Guest418 [21:59] PR snapcraft#2106 opened: nodejs plugin: lazy load the required tarballs [21:59] jdstrand: oh yeah, I am happy to see that USNs are coming along! [22:07] * zyga EODs [22:19] popey or Wimpress: https://forum.snapcraft.io/t/request-to-allow-classic-confinement-on-the-mget-snap/4999 [22:19] (I don't think ev is in here is he?) [22:23] zyga: not today. I'll try for tomorrow [22:24] jdstrand: is this user correct? they posit that /dev/stdout and /dev/stderr are blocked.. https://forum.snapcraft.io/t/how-do-i-get-service-logs-of-a-failing-ot-install-snap/3875/3 [22:26] diddledan: that's correct. we can probably allow that [22:26] * jdstrand adds a todo [22:26] \o/ [22:27] I totally think we should pronounce todo as toedoe. then my teenage self would have been reading it correctly all along [22:27] heh [23:37] kalikiana: thankyou for fixing this one: https://github.com/snapcore/snapcraft/pull/2105 [23:37] PR snapcraft#2105: project_loader: recursively process after of remote parts