[01:26] <jamesh> popey: the gtk-2-themes content interface should connect to the gtk-common-themes snap: not gtk2-common-themes
[05:05] <mborzecki> morning
[05:26] <mup> PR snapd#6602 closed: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
[05:56] <zyga> good morning
[05:56] <zyga> mborzecki: I sent some goodie last night
[05:56] <mborzecki> zyga: hey, morning
[05:57] <zyga> obviously red
[05:57] <zyga> eh
[05:57] <zyga> https://github.com/snapcore/snapd/pull/6674
[05:57] <mup> PR #6674: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
[05:58] <zyga> hmm, I will need to look
[05:58] <zyga> I install eatmydata but ... somehow not?
[05:58] <zyga> not sure
[05:58] <zyga> mborzecki: offtopic, I need a review for https://github.com/snapcore/snapd/pull/6675 - 2 lines of changes in code
[05:59] <mup> PR #6675: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
[06:01] <mborzecki> wonder why it doesn't work on debian
[06:04] <mborzecki> eatmydata should end up in $PATH, not sure why the tests are getting eatmydata: command not found
[06:06] <mborzecki> meanwhile, one of selinux branches is hitting this: https://paste.ubuntu.com/p/kZkFvkGzyp/ somehow there's a file named 'foo' that ended up as unlabeled_t
[06:18] <mborzecki> anyone https://github.com/snapcore/snapd/pull/6654 ?
[06:18] <mup> PR #6654: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6654>
[06:20] <zyga> I will review shortly
[06:30] <zyga> doing now
[06:31] <mup> PR snapd#6675 closed: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6675>
[06:40] <mvo_> zyga: hey, good morning - nice job on the eatmydata branch
[06:40] <zyga> hey
[06:40] <zyga> it doesn't pass yet
[06:40] <zyga> something wonky on debian
[06:41] <mvo_> zyga: unrelated I suppose?
[06:41] <zyga> I'm reviewing maciej's branch and will get back to it
[06:41] <zyga> mvo_: related!, eatmydata is not on path somehow?
[06:41] <zyga> I will debug shortly
[06:41] <mvo_> oh, interessting
[06:41] <zyga> mvo_: I used qemu all day yesterday, I have several more speed-up patches
[06:41] <zyga> mvo_: but providing quantitative data takes time so it will be a while for the next round
[06:42] <mvo_> zyga: ok
[06:44] <zyga> mborzecki: reviewed
[06:44] <zyga> mvo_: can you please look at https://github.com/snapcore/snapd/pull/6673
[06:45] <mup> PR #6673: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
[06:45] <zyga> mvo_: mainly to decide if the algorithm makes sense
[06:45] <zyga> mvo_: or if we should do something entirely different
[06:45] <mvo_> zyga: yeah, I look in a wee bit, just looking at a bugreport about a potential mem leak
[06:45] <zyga> ooo
[06:47] <mborzecki> zyga: thanks
[06:47] <mborzecki> mvo_: morning
[06:50] <mvo_> hey mborzecki
[06:50] <zyga> mvo_: https://github.com/snapcore/snapd/pull/6667 is +2 and green
[06:50] <mup> PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
[06:52] <mvo_> zyga: I will comment, we probably want to wait with this until the sru is officially released
[07:00] <pstolowski> mornings
[07:01] <zyga> good morning pawel
[07:03] <mvo_> pstolowski: hey, good morning
[07:39] <zyga> https://travis-ci.org/snapcore/snapd/jobs/514525874
[07:39] <zyga> WAT?
[07:39] <zyga> ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME
[07:39] <zyga> that's a darwin build
[07:40] <zyga> did go just broke on us?
[07:46] <pstolowski> zyga: i hit something similiar with golang on Mac recently; some x/sys/unix stuff needed `go get`
[07:46] <zyga> hmm?
[07:47] <zyga> are you saying you had to update the version of something or ... ?
[07:47] <zyga> can you rephrase please
[07:48] <pstolowski> zyga: i had to manually pull some x/sys packages on mac as apparently they were not shipped with default installation of go; that was a few months ago though when i first installed go on mac, don't remember the details
[07:50] <mborzecki> anyone up for a simple review https://github.com/snapcore/snapd/pull/6672 ?
[07:50] <mup> PR #6672: metautil, snap: extract yaml value normalization to a helper package <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6672>
[07:50] <mborzecki> pedronis: btw. ^^^ use metautil pacakge name you suggested
[07:52] <pedronis> mborzecki: thx, will look in  aibt
[07:52] <pedronis> *a bit
[07:52] <mborzecki> pedronis: thanks!
[08:00]  * zyga -> coffee, sorry still sleepy somehow
[08:08] <mvo_> mborzecki: hey, if you have some spare cycles it would be great if you could have a look athttps://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1822738
[08:08] <mup> Bug #1822738: memleak in 2.38+ ? <snapd (Ubuntu):New> <https://launchpad.net/bugs/1822738>
[08:15] <mborzecki> ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME heh, what zyga pasted before
[08:16] <mborzecki> anything we can do about that?
[08:18] <pedronis> mborzecki: stubbing usually, but what new code bring that in?
[08:18] <mborzecki> pedronis: looks like it's from golang.org/x/sys/unix
[08:19] <pedronis> but it's new?
[08:19] <mborzecki> and comes up when go getting it
[08:19] <mborzecki> we didn't see it yday
[08:19] <pedronis> yea, so it's new
[08:19] <pedronis> anyway Chipaca was the last one untangling that stuff
[08:19] <pedronis> he might be able to help
[08:19]  * pedronis quick errands
[08:21] <mborzecki> hm govendor lists /x/sys/unix as external dep, we don't pin it to a specific revision
[08:22] <mborzecki> haha the last commit there is titled: 'unix: add SysctlClockinfo on darwin'
[08:22] <mvo_> :P
[08:24] <mup> PR snapd#6676 opened: travis: use Go 1.11 os OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6676>
[08:25] <dot-tobias>  hello everyone
[08:25] <mborzecki> let's see if 6676 helps
[08:26] <zyga> mborzecki: there is no SYS_CLOCK_GETTIME on macos
[08:26] <zyga> unless it is coming in a unreleased beta
[08:27] <mborzecki> sounds like we should pin /x/sys/unix
[08:28] <mborzecki> and it doesn't work
[08:29] <mborzecki> zyga: that's the change in /x/sys/unix https://go-review.googlesource.com/c/sys/+/170297
[08:30] <zyga> looking
[08:32] <zyga> too bad it's not really explained
[08:32] <zyga> there's no SYS_CLOCK_GETTIME on any file in my macos install
[08:32] <zyga> (as spotlight can tell me in a fraction of a second)
[08:33] <mborzecki> heh, the change landed just today morning
[08:33] <zyga> I bet it must be coming from a test system with macos 10.15
[08:34] <zyga> https://go-review.googlesource.com/c/sys/+/170297
[08:35] <zyga> I left a comment
[08:43] <Chipaca> mvo_: pedronis: http://paste.ubuntu.com/p/yZkPWJ3FmH/ ← add this to snapd to test the memleak?
[08:43] <mvo_> Chipaca: nice one
[08:44] <Chipaca> er
[08:44] <Chipaca> nil, not nul, but you get the idea
[08:45] <mup> PR snapd#6677 opened: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
[08:46] <mborzecki> ok, maybe 6677 will get us somewhere
[08:46] <mup> PR snapd#6676 closed: travis: use Go 1.11 on OSX <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6676>
[08:48] <zyga> mborzecki: ha
[08:48] <zyga> https://go-review.googlesource.com/c/sys/+/170297
[08:48] <mborzecki> zyga: hm?
[08:48] <zyga> mborzecki: ^
[08:48] <zyga> ^_^
[08:48] <mborzecki> nice
[08:49] <zyga> I really like this about software
[08:49] <zyga> this would take a week conf call to untangle otherwise
[08:50] <zyga> https://go-review.googlesource.com/c/sys/+/170297
[08:50] <zyga> https://go-review.googlesource.com/c/sys/+/170299/ sorry
[08:51] <Chipaca> zyga: mborzecki: what broke that's needing the pin?
[08:51] <Chipaca> ah
[08:51] <mborzecki> Chipaca: golang.org/x/sys/unix ^^
[08:51] <zyga> it's almost solved now
[08:51] <Chipaca> somebody broke darwin i see :-)
[08:52] <zyga> mborzecki: I approved the fix in go now
[08:52] <zyga> perhaps it will land in a moment and we can just rebuild
[08:52] <zyga> it's funny that ..
[08:52] <zyga> you know
[08:52] <zyga> there's no CI that failed on this before
[08:52] <zyga> just saying
[08:52] <zyga> snapd ci is better than go's apparently ;)
[08:53] <mborzecki> maybe the don't care about darwin that much
[08:53] <mborzecki> crowdsourcing the CI effectively
[08:53] <Chipaca> before you get your hubris wound up, remember these interactions are tricky to get right
[08:53] <zyga> hmm?
[08:54] <zyga> go test on the tree picks this up
[08:54] <Chipaca> on which tree?
[08:54] <zyga> sys/unix
[08:54] <zyga> it just doesn't compile now
[09:06] <Chipaca> pedronis: what's a good message/code combo for 'hook present, did not fail, but did not call snapctl set-health'?
[09:06] <pedronis> Chipaca: I'm not entirely sure we should set those
[09:06] <Chipaca> pedronis: just leave it at "unknown"?
[09:06] <pedronis> for a start
[09:07] <ogra> ogra@anubis:~$ snap install freecad
[09:07] <ogra> error: snap "freecad" not found
[09:07] <ogra> HMMMM ...
[09:07]  * ogra looks at https://snapcraft.io/freecad ... 
[09:07] <ogra> (i can install other snaps ... why not this one ?)
[09:09] <ogra> interestingly snap info freecad doesnt work either for me ...
[09:10] <zyga> my laptop got fixed
[09:10] <zyga> I will go and fetch it soon
[09:11] <ogra> hmm, interesting ... doesnt work on my laptop either
[09:13] <pedronis> Chipaca: the other option is to set the code to something like snapd-hook-run or snapd-hook-ran
[09:14] <Chipaca> pedronis: snapd-hook-is-full-of-it
[09:14] <Chipaca> pedronis: snapd-hook-was-silly-banana
[09:14] <Chipaca> :-)
[09:14] <Chipaca> pedronis: I'd rather set it to something so we can tell the cases apart, yes
[09:14] <Chipaca> pedronis: but i'm not too bothered if you'd rather wait on that
[09:15] <mup> PR snapd#6678 opened: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
[09:15] <mborzecki> so if the host is short on memory to start with, snapd takes around snapd-binary-size + whatever runtime alloces, running 'snap foo' is making the situation even worse, because that'll load up another snap-binary-size blob into memory
[09:16] <mborzecki> snapd is ~20M here, snap ~15M that's 35M+ to run snap refresh, not mentioning the runtime stuff
[09:16] <pstolowski> Chipaca: addressed your suggestion from timings review in #6678
[09:16] <mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
[09:16] <Chipaca> pstolowski: why 24 commits in that?
[09:17] <pstolowski> Chipaca: because it depends on the other PR
[09:18] <pedronis> mborzecki: 6672 looks good, I would add a package doc comment though, made a suggestion.
[09:18] <pstolowski> Chipaca: it's really this: https://github.com/snapcore/snapd/pull/6678/commits/ef29d5563f677e0943088369fe92ad8b73bad867
[09:18] <mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
[09:18] <mborzecki> pedronis: thanks
[09:29] <Chipaca> pstolowski: my last comment was because you don't really need the url key to have the right name
[09:30] <Chipaca> pstolowski: GET /v2/debug?aspect=change-timings&arg=<chg id> works just as well
[09:30] <Chipaca> pstolowski: in fact I'm starting to prefer it to the other more magical one :-)
[09:31] <mborzecki> Chipaca: do you happen to have the package size breakdown graph for 'snap' too?
[09:31] <Chipaca> mborzecki: yes
[09:31] <Chipaca> mborzecki: read the message again
[09:31] <mborzecki> uhh ;) i'm getting blind
[09:32] <Chipaca> mborzecki: 's ok, we'll get you a dog
[09:32] <Chipaca> not a seeing eye dog, those are expensive
[09:32] <pstolowski> Chipaca: ty, +1
[09:32] <mborzecki> Chipaca: haha :)
[09:33] <Chipaca> mborzecki: I'd like something like this but for the running thing
[09:33] <Chipaca> not holding my breath for it though
[09:34] <mborzecki> Chipaca: pprof maybe? though it'd be more live allocations
[09:34] <mborzecki> had a PR that would expose a pprof endpoint over the api
[09:35] <Chipaca> I just want to know how much RSS is added by just importing, say, godb
[09:35] <mborzecki> ah, there was a thing for this
[09:36] <Chipaca> s/godb/bolt/ i meant
[09:36]  * Chipaca needs more coffee
[09:39]  * zyga wonders why a particular test happens to behave in a particular way
[09:39] <zyga> debugging galore
[09:40] <mborzecki> Chipaca: https://paste.ubuntu.com/p/FFbYCRk68N/ though i had trouble with newer versions of go as they changed where *.a are placed and the naming, and the sizes don't add up correctly
[09:42] <Chipaca> mborzecki: go clean -cache, and/or GODEBUG=gocacheverify=1 help with that?
[09:43] <Chipaca> mborzecki: also the -a flag to go build
[09:52] <mborzecki> Chipaca: i'd prefer to see a tool that's part of the go suite, which souds like an interesting little project itself
[09:53] <mborzecki> Chipaca: there was a tool like this in busybox tree, but it used objdump and friends to analyze and produce a per symbol breakdown
[09:54] <mborzecki> and it assumed one is using C obviously
[09:58] <popey> jamesh: tried that, still get old school looking stuff. Is your forum post in need of updating. As it doesn'r work here.
[10:08] <pedronis> mborzecki: Chipaca: put some notes of things you mentioned or I chatted about with mvo in the bug
[10:09] <mborzecki> pedronis: i'm checking out some curl queries to put there
[10:10] <pedronis> mborzecki: added one more obvious thing there
[11:03] <uebera||> Hi. Should I just ignore #snappy, #snapframework or are they reserved for specific topics?
[11:04] <uebera||> So, what's the easiest way (if any) to use /snap/core/current/usr/bin/gpg, presuming it's newer than the version shipped with Ubuntu Xenial?
[11:07] <ogra> since the core snap is built from the ubuntu xenial archive, it wont be newer
[11:08] <uebera||> ogra: I see. Thanks!
[11:09] <pedronis> zyga: for clarity I commented on 6502 that keeping the two functions (Soft,Hard) matches how we discussed things and should be kept
[11:10] <zyga> pedronis: I agree, thank you for clarifying that
[11:15] <zyga> Apr 02 13:14:29 fyke kernel: snapcraftctl[7576]: segfault at 2d ip 00007fd0131e1681 sp 00007ffdc8e9fe20 error 4 in ld-2.28.so[7fd0131d8000+20000]
[11:15] <zyga> Apr 02 13:14:29 fyke kernel: Code: 54 24 18 e8 71 72 00 00 4c 8b 54 24 18 85 c0 0f 85 d4 0a 00 00 0f 1f 40 00 48 83 c5 01 49 39 ea 0f 86 23 06 00 00 49 8b 04 ec <48> 8b 58 28 48 3b 9c 24 e8 00 00 00 74 e1 8b 34 24 85 f6 74 09 f6
[11:15] <zyga> not my luckiest day
[11:21] <Chipaca> wait, where has the morning gone
[11:21] <Chipaca> staahp
[11:21] <zyga> Chipaca: what? :)
[11:22] <zyga> oh, making progress :)
[11:24] <Chipaca> zyga: my morning vanished in a flurry of unproductive nonsense
[11:24] <Chipaca> that's what :-/
[11:30] <zyga> Chipaca: you didn't see my morning :)
[11:31] <zyga> Chipaca: I'm stumbling blind around parts I'm clueless to
[11:31] <zyga> trying to make some progress but slow at it
[11:33] <mborzecki> damn, #6677 travis job failed, desktop-portal-filechooser
[11:33] <mup> PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
[11:35] <pstolowski> can #6659 land?
[11:35] <mup> PR #6659: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/6659>
[11:53] <pedronis> pstolowski: as such yes, but it needs work somewhere else, I'm not sure how mvo is tracking that
[11:54] <pedronis> pstolowski: I would let mvo deal with it
[11:54] <pstolowski> pedronis: ack.. i was trying to find something that can land.. our queue keeps growing
[11:55] <mborzecki> revived my branch to expose pprof over snapd api
[11:58]  * cmatsuoka wonders what "duplicate the fake tar sleeps" means
[12:01]  * Chipaca reads the news and considers sending zyga a big box of harry potter books
[12:02] <pedronis> mborzecki: commented in the bug that master has timings too, which 2.38 didn't have
[12:02] <zyga> Chipaca: no need, I have plenty at home
[12:02] <zyga> Chipaca: in both languages
[12:03] <Chipaca> zyga: I'll send you an empty box (cheaper!), that says harry potter in big letters on the outside then
[12:03] <zyga> Chipaca: it will be a magic box :)
[12:03] <Chipaca> obvs
[12:03] <zyga> Chipaca: it's a terrible world we live in but I think what happened is not representative of my broken country
[12:03] <zyga> luckily
[12:03] <Chipaca> zyga: I assumed as much
[12:04] <Chipaca> zyga: if it were, it wouldn't be news i guess?
[12:04] <Chipaca> smells like my lunch is ready, ttfn
[12:04] <zyga> unfortunately wit the current government we cannot see a strong signal either
[12:04] <zyga> I read that we should condemn that act, separate church and state more strongly and invite ms Rowing
[12:04] <zyga> but alas, that's a dream in current days
[12:05] <mborzecki> heap profile after running some install/remove cycles: https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/616b1b7f888f4dfac1ab1c5c6953b2c9080865b4/pprof001.svg
[12:05] <mborzecki> you'
[12:05] <mborzecki> you'll probably need to open that with eog or sth similar
[12:05] <mborzecki> idk why, but it doesn't load in ff as svg
[12:06] <mborzecki> off to pick up the kids
[12:11] <Chipaca> pprof001.svg:1930: parser error : Opening and ending tag mismatch: script line 7 and svg
[12:11] <Chipaca> pprof001.svg:1930: parser error : Premature end of data in tag svg line 6
[12:11] <Chipaca> mborzecki: ^
[12:12] <Chipaca> mborzecki: that's from inkscape; google chrome says "error on line 1930 at column 12: Opening and ending tag mismatch: script line 0 and svg"
[12:12] <Chipaca> mborzecki: (surprisingly similar errors … :-) )
[12:13] <Chipaca> mborzecki: emacs hates it and crahsed
[12:13] <zyga> Chipaca: at least vim can open it and see text ;) (/me hides now)
[12:14] <Chipaca> zyga: emacs is doing what all the cool people do, and brexiting
[12:14] <zyga> hahahaha
[12:14] <Chipaca> eog says
[12:14] <Chipaca> (eog:22352): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
[12:14] <Chipaca> This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
[12:14] <Chipaca> The overwriting error message was: Error domain 1 code 76 on line 1930 column 12 of file:///tmp/pprof001.svg: Opening and ending tag mismatch: script line 0 and svg
[12:15] <zyga> Chipaca: brexit the frog, waiting till the kettle boils
[12:26] <mup> PR snapd#6679 opened: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
[12:28] <jamesh> popey: sorry, was out earlier for an event.  Try the gtk2-demo snap from the store (edge channel): it is themed correctly for me, and relies on gtk-common-themes/gtk2-common-themes for the theme data and engines
[12:35] <mup> PR snapcraft#2509 closed: build providers: initial support for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2509>
[12:39] <mborzecki> Chipaca: hah, so the crash is reproducible then :)
[12:42] <Chipaca> mborzecki: also, also, memory use is probably arch-dependent (esp wrt 32 vs 64 bits)
[12:45] <Chipaca> gosh the ubuntu-core image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is ancient
[12:46] <Chipaca> mvo_: do you know what's up with that? ^
[12:47] <Chipaca> mvo_: it comes with 2.33.1
[12:49] <mvo_> Chipaca: probably best to check with foundations, iirc they have a different cadance now and only update core images on point releases of the distro. but given that these images are 8 month old maybe that is not a good policy anymore
[12:49] <Chipaca> mvo_: also that site's a mess, there are images in the directory above 'current'
[12:51] <mborzecki> hm should have dumped the svg directly from pprof
[12:52] <mvo_> Chipaca: I put the update on the agenda for the meeting we have with foundations today
[12:52] <Chipaca> ok
[12:53] <mborzecki> Chipaca: idk if it's much better now https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/c51c7ba5970dc25888832fea251178ab56dd2ba0/profile001.svg
[12:53] <zyga> cmatsuoka: I reviewed https://github.com/snapcore/snapd/pull/6679
[12:53] <mup> PR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
[12:53] <Chipaca> mborzecki: much
[12:54] <cmatsuoka> zyga: thanks, I'm reading it right now
[12:54] <Chipaca> mborzecki: yeah the read state thing is yuge
[12:55] <Chipaca> I could have some fun in there
[12:55] <Chipaca> mvo_: I'm not seeing the OOMs on a i386 kvm with 256MB and no swap, fwiw
[12:56]  * Chipaca tries to install nextcloud on it
[12:56] <mvo_> Chipaca: oh, nice
[12:56] <mvo_> mvo_: that is a great data point
[12:57] <mvo_> Chipaca: -^
[12:57] <Chipaca> nextcloud installed as well
[12:57] <Chipaca> mvo_: i asked a few q's in the bug, about this
[12:57] <Chipaca> now i need to go make tea before the standup
[12:57]  * Chipaca runs
[13:00] <zyga> uh
[13:00] <zyga> so
[13:00] <zyga> is there a video call URL today?
[13:00] <zyga> I cannot seem to find one
[13:01] <cmatsuoka> it seems that we don't have one
[13:01] <degville> I can't find one either.
[13:01] <zyga> let's use the one from last week
[13:02] <zyga> https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel
[13:02] <degville> thanks zyga!
[13:02] <diddledan> does that work for non canonicalites? just wondering whether sharing allows randoms to join your meeting :-p
[13:03] <zyga> diddledan: it doesn't work, you need to be allowed to enter
[13:03] <zyga> and we'd notice ;)
[13:03] <diddledan> aha
[13:03] <diddledan> teehee
[13:03]  * diddledan covers the camera
[13:17] <ogra> hmm, how do i use snap refresh ... --stable with a ansp using tracks ?
[13:17] <ogra> *with a snap
[13:17] <ogra> ogra@pocketbeagle:~$ snap list pc-kernel
[13:17] <ogra> Name       Version       Rev  Tracking  Publisher   Notes
[13:17] <ogra> pc-kernel  4.15.0-47.50  199  18/edge   canonical✓  kernel
[13:17] <ogra> ogra@pocketbeagle:~$ snap refresh pc-kernel --stable
[13:17] <ogra> error: cannot refresh "pc-kernel": cannot switch from kernel track "18" as specified for the
[13:17] <ogra>        (device) model to "stable"
[13:17] <ogra> ogra@pocketbeagle:~$
[13:17] <diddledan> "I'm typing all the right letters. not necessarily in the right order"
[13:18] <ogra> yeah, i'm slowly becoming the king of dsylxeia :P
[13:19] <diddledan> and yet, I read that correctly until I look closer
[13:19] <ogra> haha
[13:20] <diddledan> it's weird that you can often read words that are misspelt without thinking about it
[13:20] <ogra> aand ... to answer myself ...
[13:20] <ogra> snap switch pc-kernel --channel=18/stable && snap refresh pc-kernel
[13:22] <diddledan> does `snap refresh --channel` work too?
[13:26] <ogra> no idea, i refreshed to stable now ...
[13:27] <ogra> bah ... and i notice i shouldnt have ... forgot that avahi has issues with that kernel
[13:31] <ogra> ogra@pocketbeagle:~$ snap refresh --channel=18/edge pc-kernel
[13:31] <ogra> Setup snap "pc-kernel" (199) security profiles
[13:31] <ogra> seems to work
[13:32] <__chip__> pedronis: would it be worth looking into always loading state on demand (as opposed to keeping it all in memory)? (all of it/ some of it (which?)/etc)
[13:33] <__chip__> pedronis: we can use mmap + json stream decoding to bring down memory usage a lot for that, if we want
[13:34] <__chip__> granted "a lot" is not going to be much bigger than state.json, but ¯\_(ツ)_/¯
[14:01] <solkku> hello! I was wondering if there's a way to run a snap in the background on ubuntu server 18.04? now when I run it, it keeps giving me logs and I'm unable to use the terminal window for anything else
[14:01] <mup> PR snapd#6680 opened: [RFC] daemon: expose pprof endpoints <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6680>
[14:02] <mborzecki> mvo_: Chipaca: ^^ if you want to play with it
[14:02] <mborzecki> i'll add some notes on how to set it up
[14:02] <mborzecki> the pprof tools don't know about unix sockets, so a proxy is needed
[14:03] <mvo_> mborzecki: nice one
[14:06] <mborzecki> mvo_: fairly self contained, we could have it behind an env flag
[14:21] <sil2100> Hey guys, I started noticing that the core18 CI started failing due to some snapd errors: https://travis-ci.org/snapcore/core18/jobs/512567447 <- for example here
[14:21] <sil2100> "error: too early for operation, device not yet seeded or device model not acknowledged"
[14:22] <sil2100> When travis is trying to do a snap install
[14:22] <sil2100> We're using trusty for CI there, maybe I should try switching to xenial again?
[14:34] <mvo_> sil2100: we might need to add an extra command to .travis.yml, something like "snap wait system seed.loaded"
[14:34] <mvo_> sil2100: before snap install
[14:36] <sil2100> mvo_: oh, sounds fancy
[14:36] <sil2100> Will try that
[14:39] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6677
[14:40] <mup> PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
[14:40] <mvo_> sil2100: good luck
[14:41] <mborzecki> zyga: hmm?
[14:41] <mup> PR core18#124 opened: Switch travis CI to xenial, add a snap wait after installing snapd to… <Created by sil2100> <https://github.com/snapcore/core18/pull/124>
[14:41] <zyga> mborzecki: the fix was merged upstream now
[14:41] <zyga> mborzecki: I wanted to let you know
[14:41] <mborzecki> ah, so maybe we can close it
[14:41] <mborzecki> or keep it
[14:43] <mborzecki> zyga: either way 6677 was timing out when running tests :/
[14:43] <zyga> mborzecki: not our lucky day
[14:44] <Chipaca> solkku: o/
[14:44] <Chipaca> solkku: what do you mean?
[14:50] <solkku> Chipaca: I'm trying to run the snap as a daemon/service, so it does it's thing in the background and I can use the terminal for other things. Also the snap only stays alive as long as the terminal window is open
[14:52] <Chipaca> solkku: when you say 'the snap', you mean the app in the snap?
[14:52] <Chipaca> solkku: what happens if you add 'daemon: simple' to your app in your snap?
[14:54] <Chipaca> solkku: (with 'daemon: simple', it will be started automatically when you install the snap -- you can see it in 'snap services')
[14:54] <solkku> Chipaca: I did "snap install sickgear", when I run it with "sudo sickgear" I get all kinds of logs: https://pastebin.com/61CgtWA9
[14:54] <Chipaca> solkku: is sickgear your snap?
[14:54] <mvo_> can we land 6660 btw? has two +1 afaict and everyone seems to be happy with the new UX
[14:54] <Chipaca> solkku: or is it somebody else's?
[14:55] <solkku> I can use "sudo sickgear &", but still get logs on screen once in a while :)
[14:56] <solkku> Chipaca: it's a snap I found at snapcraft.io
[14:56] <Chipaca> solkku: and is sickgear something that's meant to (a) run as root, and (b) run in the background ?
[14:58] <mvo_> pedronis: was 6660 something you wanted to double check before it goes in? iirc yes but I'm not sure anymore
[14:58] <Chipaca> solkku: looking at the website it seems to be a GUI app
[14:58] <Chipaca> solkku: why would you run this as root? and why would you start it from the terminal?
[14:58] <pedronis> mvo_: yes
[14:58] <solkku> Chipaca: you can run it in the background if you install it the "old fashioned" way, but couldn't tell you about a or b
[14:58] <pedronis> mvo_: I will get to those PRs by pstolowski today or tomorrow morning
[14:59] <solkku> Chipaca: it starts a webserver and I access it via the web browser
[14:59] <Chipaca> solkku: ohhh
[14:59] <Chipaca> solkku: then maybe reach out to the sickgear people (file an issue?), tell them to make it a daemon
[15:00] <Chipaca> solkku: if they need help, we're here (or forum.snapcraft.io)
[15:00] <mup> PR core18#125 opened: hooks: create snapd directory skeleton <Created by zyga> <https://github.com/snapcore/core18/pull/125>
[15:00] <mvo_> pstolowski: thanks, I added a tag
[15:01] <solkku> I said to the maker of sickrage that I'm trying to run it as a daemon, but he just said that "no where in the documentation does it say to run like that" and "if you want to run like that, then you must take apart the /snap folder and reconstruct yourself".. so I guess I'm on my own and came here for help next :)
[15:02] <zyga> solkku: you can create a systemd service that just runs the snap command
[15:03] <solkku> Chipaca: when I try to run it as a daemon "sudo snap start --enable sickgear.daemon", I get: "error: snap "sickgear" has no service "daemon""
[15:03] <zyga> solkku: you don't have to repackage the snap
[15:03] <zyga> solkku: just install it and create a systemd unit that runs it as a service
[15:03] <solkku> zyga: oh, is there a noob-friendly guide on this?
[15:04] <zyga> not sure :) just systemd docs
[15:04] <Chipaca> er
[15:05] <Chipaca> solkku: yeah, if the developer doesn't think you should run it like that … ¯\_(ツ)_/¯ maybe you shouldn't?
[15:06] <solkku> Chipaca: maybe, but I'm going to try it my way first ;)
[15:07] <MattJ> solkku, https://www.shellhacks.com/systemd-service-file-example/
[15:15] <solkku> MattJ: thanks, seems to have worked!
[15:20] <solkku> you learn something new every day
[15:37] <cwayne> mvo_: sil2100: heya, should we setup a call re: beta gating for core18?
[16:18] <mup> PR core18#124 closed: Switch travis CI to xenial, add a snap wait after installing snapd to… <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/124>
[17:12] <zyga> sil2100: hi
[17:12] <zyga> Could you please review https://github.com/snapcore/core18/pull/125
[17:12] <mup> PR core18#125: hooks: create snapd directory skeleton <Created by zyga> <https://github.com/snapcore/core18/pull/125>
[17:14] <sil2100> zyga: sure o/ It's a bit troublesome right now, since I can't do any test builds of the snap right now due to the archive slowness
[17:14] <sil2100> zyga: so I guess it'll have to wait till tomorrow
[17:14]  * sil2100 just tried building his own core18 snap but the archive was super slow and actually mismatching sizes
[17:15] <sil2100> zyga: it's on my plate anyway o/
[17:30] <zyga> sil2100: thank you
[17:40] <mup> PR snapd#6681 opened: misc: support system-global-ids for 'daemon' user <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
[18:56]  * zyga EODs
[18:56] <zyga> jdstrand: super nice, I will read in detail tomorrow
[18:56] <zyga> jdstrand: there are some interactions with snap-confine changes I have in the pipe
[18:56] <zyga> jdstrand: I will try to de-conflict it as things that are in progress are merged into master
[18:58] <zyga> jdstrand: gentle ping about mointinfo fix https://github.com/snapcore/snapd/pull/6605
[18:59] <mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
[18:59] <zyga> if you want I can merge as-is, you can always review post-factum later
[18:59] <zyga> it has two reviews and is green already
[19:00] <zyga> wow, today many things can get merged
[19:17] <jdstrand> zyga: 6605 is on my list. now that the daemon user PR low-level technical details are worked through, I'm going through my inbox/todo/etc again, which that pr is in
[19:22]  * jdstrand wonders if anyone uses the non-raw travis log in the snapd travis ci tests
[23:50] <mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
[23:50] <mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#120, core18#121, core18#122, core18#123, core18#125
[23:51] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
[23:51] <mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#120, core18#121, core18#122, core18#123, core18#125