[01:26] popey: the gtk-2-themes content interface should connect to the gtk-common-themes snap: not gtk2-common-themes === chihchun_afk is now known as chihchun [05:05] morning [05:26] PR snapd#6602 closed: cmd,interfaces: replace local helpers with cmd.InternalToolPath [05:56] good morning [05:56] mborzecki: I sent some goodie last night [05:56] zyga: hey, morning [05:57] obviously red [05:57] eh [05:57] https://github.com/snapcore/snapd/pull/6674 [05:57] PR #6674: tests: use apt via eatmydata [05:58] hmm, I will need to look [05:58] I install eatmydata but ... somehow not? [05:58] not sure [05:58] mborzecki: offtopic, I need a review for https://github.com/snapcore/snapd/pull/6675 - 2 lines of changes in code [05:59] PR #6675: cmd/snap-confine: allow using tools from snapd snap [06:01] wonder why it doesn't work on debian [06:04] eatmydata should end up in $PATH, not sure why the tests are getting eatmydata: command not found [06:06] 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] anyone https://github.com/snapcore/snapd/pull/6654 ? [06:18] PR #6654: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade [06:20] I will review shortly [06:30] doing now [06:31] PR snapd#6675 closed: cmd/snap-confine: allow using tools from snapd snap === mvo is now known as Guest61543 === Guest61543 is now known as mvo_ [06:40] zyga: hey, good morning - nice job on the eatmydata branch [06:40] hey [06:40] it doesn't pass yet [06:40] something wonky on debian [06:41] zyga: unrelated I suppose? [06:41] I'm reviewing maciej's branch and will get back to it [06:41] mvo_: related!, eatmydata is not on path somehow? [06:41] I will debug shortly [06:41] oh, interessting [06:41] mvo_: I used qemu all day yesterday, I have several more speed-up patches [06:41] mvo_: but providing quantitative data takes time so it will be a while for the next round [06:42] zyga: ok [06:44] mborzecki: reviewed [06:44] mvo_: can you please look at https://github.com/snapcore/snapd/pull/6673 [06:45] PR #6673: cmd,tests: forcibly discard mount namespace when bases change [06:45] mvo_: mainly to decide if the algorithm makes sense [06:45] mvo_: or if we should do something entirely different [06:45] zyga: yeah, I look in a wee bit, just looking at a bugreport about a potential mem leak [06:45] ooo [06:47] zyga: thanks [06:47] mvo_: morning [06:50] hey mborzecki [06:50] mvo_: https://github.com/snapcore/snapd/pull/6667 is +2 and green [06:50] PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 [06:52] zyga: I will comment, we probably want to wait with this until the sru is officially released === pstolowski|afk is now known as pstolowski [07:00] mornings [07:01] good morning pawel [07:03] pstolowski: hey, good morning [07:39] https://travis-ci.org/snapcore/snapd/jobs/514525874 [07:39] WAT? [07:39] ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME [07:39] that's a darwin build [07:40] did go just broke on us? [07:46] zyga: i hit something similiar with golang on Mac recently; some x/sys/unix stuff needed `go get` [07:46] hmm? [07:47] are you saying you had to update the version of something or ... ? [07:47] can you rephrase please [07:48] 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] anyone up for a simple review https://github.com/snapcore/snapd/pull/6672 ? [07:50] PR #6672: metautil, snap: extract yaml value normalization to a helper package [07:50] pedronis: btw. ^^^ use metautil pacakge name you suggested [07:52] mborzecki: thx, will look in aibt [07:52] *a bit [07:52] pedronis: thanks! [08:00] * zyga -> coffee, sorry still sleepy somehow [08:08] 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] Bug #1822738: memleak in 2.38+ ? [08:15] ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME heh, what zyga pasted before [08:16] anything we can do about that? [08:18] mborzecki: stubbing usually, but what new code bring that in? [08:18] pedronis: looks like it's from golang.org/x/sys/unix [08:19] but it's new? [08:19] and comes up when go getting it [08:19] we didn't see it yday [08:19] yea, so it's new [08:19] anyway Chipaca was the last one untangling that stuff [08:19] he might be able to help [08:19] * pedronis quick errands [08:21] hm govendor lists /x/sys/unix as external dep, we don't pin it to a specific revision [08:22] haha the last commit there is titled: 'unix: add SysctlClockinfo on darwin' [08:22] :P [08:24] PR snapd#6676 opened: travis: use Go 1.11 os OSX [08:25] hello everyone [08:25] let's see if 6676 helps [08:26] mborzecki: there is no SYS_CLOCK_GETTIME on macos [08:26] unless it is coming in a unreleased beta [08:27] sounds like we should pin /x/sys/unix [08:28] and it doesn't work [08:29] zyga: that's the change in /x/sys/unix https://go-review.googlesource.com/c/sys/+/170297 [08:30] looking [08:32] too bad it's not really explained [08:32] there's no SYS_CLOCK_GETTIME on any file in my macos install [08:32] (as spotlight can tell me in a fraction of a second) [08:33] heh, the change landed just today morning [08:33] I bet it must be coming from a test system with macos 10.15 [08:34] https://go-review.googlesource.com/c/sys/+/170297 [08:35] I left a comment === chihchun is now known as chihchun_afk [08:43] mvo_: pedronis: http://paste.ubuntu.com/p/yZkPWJ3FmH/ ← add this to snapd to test the memleak? [08:43] Chipaca: nice one [08:44] er [08:44] nil, not nul, but you get the idea [08:45] PR snapd#6677 opened: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX [08:46] ok, maybe 6677 will get us somewhere [08:46] PR snapd#6676 closed: travis: use Go 1.11 on OSX [08:48] mborzecki: ha [08:48] https://go-review.googlesource.com/c/sys/+/170297 [08:48] zyga: hm? [08:48] mborzecki: ^ [08:48] ^_^ [08:48] nice [08:49] I really like this about software [08:49] this would take a week conf call to untangle otherwise [08:50] https://go-review.googlesource.com/c/sys/+/170297 [08:50] https://go-review.googlesource.com/c/sys/+/170299/ sorry [08:51] zyga: mborzecki: what broke that's needing the pin? [08:51] ah [08:51] Chipaca: golang.org/x/sys/unix ^^ [08:51] it's almost solved now [08:51] somebody broke darwin i see :-) [08:52] mborzecki: I approved the fix in go now [08:52] perhaps it will land in a moment and we can just rebuild [08:52] it's funny that .. [08:52] you know [08:52] there's no CI that failed on this before [08:52] just saying [08:52] snapd ci is better than go's apparently ;) [08:53] maybe the don't care about darwin that much [08:53] crowdsourcing the CI effectively [08:53] before you get your hubris wound up, remember these interactions are tricky to get right [08:53] hmm? [08:54] go test on the tree picks this up [08:54] on which tree? [08:54] sys/unix [08:54] it just doesn't compile now === chihchun_afk is now known as chihchun [09:06] pedronis: what's a good message/code combo for 'hook present, did not fail, but did not call snapctl set-health'? [09:06] Chipaca: I'm not entirely sure we should set those [09:06] pedronis: just leave it at "unknown"? [09:06] for a start [09:07] ogra@anubis:~$ snap install freecad [09:07] error: snap "freecad" not found [09:07] HMMMM ... [09:07] * ogra looks at https://snapcraft.io/freecad ... [09:07] (i can install other snaps ... why not this one ?) [09:09] interestingly snap info freecad doesnt work either for me ... [09:10] my laptop got fixed [09:10] I will go and fetch it soon [09:11] hmm, interesting ... doesnt work on my laptop either [09:13] Chipaca: the other option is to set the code to something like snapd-hook-run or snapd-hook-ran [09:14] pedronis: snapd-hook-is-full-of-it [09:14] pedronis: snapd-hook-was-silly-banana [09:14] :-) [09:14] pedronis: I'd rather set it to something so we can tell the cases apart, yes [09:14] pedronis: but i'm not too bothered if you'd rather wait on that [09:15] PR snapd#6678 opened: cmd/snap, api: use DebugGet for timings [09:15] 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] snapd is ~20M here, snap ~15M that's 35M+ to run snap refresh, not mentioning the runtime stuff [09:16] Chipaca: addressed your suggestion from timings review in #6678 [09:16] PR #6678: cmd/snap, api: use DebugGet for timings [09:16] pstolowski: why 24 commits in that? [09:17] Chipaca: because it depends on the other PR [09:18] mborzecki: 6672 looks good, I would add a package doc comment though, made a suggestion. [09:18] Chipaca: it's really this: https://github.com/snapcore/snapd/pull/6678/commits/ef29d5563f677e0943088369fe92ad8b73bad867 [09:18] PR #6678: cmd/snap, api: use DebugGet for timings [09:18] pedronis: thanks [09:29] pstolowski: my last comment was because you don't really need the url key to have the right name [09:30] pstolowski: GET /v2/debug?aspect=change-timings&arg= works just as well [09:30] pstolowski: in fact I'm starting to prefer it to the other more magical one :-) [09:31] Chipaca: do you happen to have the package size breakdown graph for 'snap' too? [09:31] mborzecki: yes [09:31] mborzecki: read the message again [09:31] uhh ;) i'm getting blind [09:32] mborzecki: 's ok, we'll get you a dog [09:32] not a seeing eye dog, those are expensive [09:32] Chipaca: ty, +1 [09:32] Chipaca: haha :) [09:33] mborzecki: I'd like something like this but for the running thing [09:33] not holding my breath for it though [09:34] Chipaca: pprof maybe? though it'd be more live allocations [09:34] had a PR that would expose a pprof endpoint over the api [09:35] I just want to know how much RSS is added by just importing, say, godb [09:35] ah, there was a thing for this [09:36] s/godb/bolt/ i meant [09:36] * Chipaca needs more coffee === mvo is now known as Guest18430 === Guest18430 is now known as mvo_ [09:39] * zyga wonders why a particular test happens to behave in a particular way [09:39] debugging galore [09:40] 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] mborzecki: go clean -cache, and/or GODEBUG=gocacheverify=1 help with that? [09:43] mborzecki: also the -a flag to go build [09:52] 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] 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] and it assumed one is using C obviously [09:58] 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] mborzecki: Chipaca: put some notes of things you mentioned or I chatted about with mvo in the bug [10:09] pedronis: i'm checking out some curl queries to put there === chihchun is now known as chihchun_afk [10:10] mborzecki: added one more obvious thing there === chihchun_afk is now known as chihchun [11:03] Hi. Should I just ignore #snappy, #snapframework or are they reserved for specific topics? [11:04] 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] since the core snap is built from the ubuntu xenial archive, it wont be newer [11:08] ogra: I see. Thanks! [11:09] 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] pedronis: I agree, thank you for clarifying that === chihchun is now known as chihchun_afk [11:15] 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] 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] not my luckiest day [11:21] wait, where has the morning gone [11:21] staahp [11:21] Chipaca: what? :) [11:22] oh, making progress :) [11:24] zyga: my morning vanished in a flurry of unproductive nonsense [11:24] that's what :-/ [11:30] Chipaca: you didn't see my morning :) [11:31] Chipaca: I'm stumbling blind around parts I'm clueless to [11:31] trying to make some progress but slow at it [11:33] damn, #6677 travis job failed, desktop-portal-filechooser [11:33] PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX [11:35] can #6659 land? [11:35] PR #6659: snapcraft: build static fontconfig in the snapd snap === ricab is now known as ricab|lunch [11:53] pstolowski: as such yes, but it needs work somewhere else, I'm not sure how mvo is tracking that [11:54] pstolowski: I would let mvo deal with it [11:54] pedronis: ack.. i was trying to find something that can land.. our queue keeps growing [11:55] revived my branch to expose pprof over snapd api === chihchun_afk is now known as chihchun [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] mborzecki: commented in the bug that master has timings too, which 2.38 didn't have [12:02] Chipaca: no need, I have plenty at home [12:02] Chipaca: in both languages [12:03] zyga: I'll send you an empty box (cheaper!), that says harry potter in big letters on the outside then [12:03] Chipaca: it will be a magic box :) [12:03] obvs [12:03] Chipaca: it's a terrible world we live in but I think what happened is not representative of my broken country [12:03] luckily [12:03] zyga: I assumed as much [12:04] zyga: if it were, it wouldn't be news i guess? [12:04] smells like my lunch is ready, ttfn [12:04] unfortunately wit the current government we cannot see a strong signal either [12:04] I read that we should condemn that act, separate church and state more strongly and invite ms Rowing [12:04] but alas, that's a dream in current days [12:05] heap profile after running some install/remove cycles: https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/616b1b7f888f4dfac1ab1c5c6953b2c9080865b4/pprof001.svg [12:05] you' [12:05] you'll probably need to open that with eog or sth similar [12:05] idk why, but it doesn't load in ff as svg [12:06] off to pick up the kids [12:11] pprof001.svg:1930: parser error : Opening and ending tag mismatch: script line 7 and svg [12:11] pprof001.svg:1930: parser error : Premature end of data in tag svg line 6 [12:11] mborzecki: ^ [12:12] 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] mborzecki: (surprisingly similar errors … :-) ) [12:13] mborzecki: emacs hates it and crahsed === chihchun_afk is now known as chihchun [12:13] Chipaca: at least vim can open it and see text ;) (/me hides now) [12:14] zyga: emacs is doing what all the cool people do, and brexiting [12:14] hahahaha [12:14] eog says [12:14] (eog:22352): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. [12:14] This indicates a bug in someone's code. You must ensure an error is NULL before it's set. [12:14] 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] Chipaca: brexit the frog, waiting till the kettle boils [12:26] PR snapd#6679 opened: many: implement user removal [12:28] 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] PR snapcraft#2509 closed: build providers: initial support for LXD [12:39] Chipaca: hah, so the crash is reproducible then :) [12:42] mborzecki: also, also, memory use is probably arch-dependent (esp wrt 32 vs 64 bits) [12:45] gosh the ubuntu-core image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is ancient [12:46] mvo_: do you know what's up with that? ^ [12:47] mvo_: it comes with 2.33.1 [12:49] 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] mvo_: also that site's a mess, there are images in the directory above 'current' [12:51] hm should have dumped the svg directly from pprof [12:52] Chipaca: I put the update on the agenda for the meeting we have with foundations today [12:52] ok [12:53] Chipaca: idk if it's much better now https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/c51c7ba5970dc25888832fea251178ab56dd2ba0/profile001.svg [12:53] cmatsuoka: I reviewed https://github.com/snapcore/snapd/pull/6679 [12:53] PR #6679: many: implement user removal [12:53] mborzecki: much [12:54] zyga: thanks, I'm reading it right now [12:54] mborzecki: yeah the read state thing is yuge [12:55] I could have some fun in there [12:55] 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] Chipaca: oh, nice [12:56] mvo_: that is a great data point [12:57] Chipaca: -^ [12:57] nextcloud installed as well [12:57] mvo_: i asked a few q's in the bug, about this [12:57] now i need to go make tea before the standup [12:57] * Chipaca runs [13:00] uh [13:00] so [13:00] is there a video call URL today? [13:00] I cannot seem to find one [13:01] it seems that we don't have one [13:01] I can't find one either. [13:01] let's use the one from last week [13:02] https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel === ricab|lunch is now known as ricab [13:02] thanks zyga! [13:02] does that work for non canonicalites? just wondering whether sharing allows randoms to join your meeting :-p [13:03] diddledan: it doesn't work, you need to be allowed to enter [13:03] and we'd notice ;) [13:03] aha [13:03] teehee [13:03] * diddledan covers the camera [13:17] hmm, how do i use snap refresh ... --stable with a ansp using tracks ? [13:17] *with a snap [13:17] ogra@pocketbeagle:~$ snap list pc-kernel [13:17] Name Version Rev Tracking Publisher Notes [13:17] pc-kernel 4.15.0-47.50 199 18/edge canonical✓ kernel [13:17] ogra@pocketbeagle:~$ snap refresh pc-kernel --stable [13:17] error: cannot refresh "pc-kernel": cannot switch from kernel track "18" as specified for the [13:17] (device) model to "stable" [13:17] ogra@pocketbeagle:~$ [13:17] "I'm typing all the right letters. not necessarily in the right order" [13:18] yeah, i'm slowly becoming the king of dsylxeia :P [13:19] and yet, I read that correctly until I look closer [13:19] haha [13:20] it's weird that you can often read words that are misspelt without thinking about it [13:20] aand ... to answer myself ... [13:20] snap switch pc-kernel --channel=18/stable && snap refresh pc-kernel [13:22] does `snap refresh --channel` work too? [13:26] no idea, i refreshed to stable now ... [13:27] bah ... and i notice i shouldnt have ... forgot that avahi has issues with that kernel [13:31] ogra@pocketbeagle:~$ snap refresh --channel=18/edge pc-kernel [13:31] Setup snap "pc-kernel" (199) security profiles [13:31] 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] 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] PR snapd#6680 opened: [RFC] daemon: expose pprof endpoints [14:02] mvo_: Chipaca: ^^ if you want to play with it [14:02] i'll add some notes on how to set it up [14:02] the pprof tools don't know about unix sockets, so a proxy is needed === mvo_ is now known as mvo === mvo is now known as mvo_ [14:03] mborzecki: nice one === chihchun is now known as chihchun_afk [14:06] mvo_: fairly self contained, we could have it behind an env flag [14:21] 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] "error: too early for operation, device not yet seeded or device model not acknowledged" [14:22] When travis is trying to do a snap install [14:22] We're using trusty for CI there, maybe I should try switching to xenial again? [14:34] sil2100: we might need to add an extra command to .travis.yml, something like "snap wait system seed.loaded" [14:34] sil2100: before snap install [14:36] mvo_: oh, sounds fancy [14:36] Will try that [14:39] mborzecki: https://github.com/snapcore/snapd/pull/6677 [14:40] PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX [14:40] sil2100: good luck [14:41] zyga: hmm? [14:41] PR core18#124 opened: Switch travis CI to xenial, add a snap wait after installing snapd to… [14:41] mborzecki: the fix was merged upstream now [14:41] mborzecki: I wanted to let you know [14:41] ah, so maybe we can close it [14:41] or keep it [14:43] zyga: either way 6677 was timing out when running tests :/ [14:43] mborzecki: not our lucky day [14:44] solkku: o/ [14:44] solkku: what do you mean? [14:50] 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] solkku: when you say 'the snap', you mean the app in the snap? [14:52] solkku: what happens if you add 'daemon: simple' to your app in your snap? [14:54] solkku: (with 'daemon: simple', it will be started automatically when you install the snap -- you can see it in 'snap services') [14:54]