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