[00:01] <sil2100> Fingers crossed that this time we're good!
[00:50] <cachio> sil2100, +1
[00:53] <sil2100> \o/
[01:06] <pedronis> good
[01:06] <cachio> sil2100, pedronis double checked
[01:07] <cachio> good night for you :)
[01:07] <sil2100> cachio: goodnight!
[01:07] <sil2100> I'll still stick around to see the builds finishing and then handing over the images further
[01:08] <pedronis> sil2100: thanks
[01:08] <cachio> sil2100, me too, just ping me in case
[01:08] <cachio> you need something
[01:11] <pedronis> sil2100: please do send a quick mail with the state of things
[01:12] <sil2100> pedronis: sure thing
[01:26]  * sil2100 EODs
[01:26] <sil2100> o/
[02:41] <mup> PR snapcraft#2429 opened: cli: fix usage string in help command <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/2429>
[02:58]  * cachio EOD
[07:36] <zyga> o/
[08:04] <pstolowski> mornings
[08:04] <pstolowski> hey zyga
[08:08] <zyga> I’m going to pick up the car now :-)
[08:08] <pstolowski> pedronis: heh, locomote ceasing operations (see the announcement email)
[08:08] <pstolowski> zyga: wooah, the new car?
[08:08] <zyga> Are you working today?
[08:08] <zyga> Yes
[08:08] <pstolowski> zyga: yes, last day before holidays
[08:08] <pstolowski> zyga: awesome :)
[08:08] <zyga> What is locomotoe?
[08:08] <pstolowski> zyga: the tool we were supposed to use to book travel
[08:09] <zyga> Whaaaat
[08:09] <pstolowski> zyga: so now it's email/phone booking, until something new is set uo
[08:09] <pstolowski> *up
[08:09] <zyga> Lol
[08:09] <pstolowski> which is fine
[08:10] <zyga> What a joke
[08:10] <zyga> Took forever to se up
[08:10] <pstolowski> yeah..
[08:10] <zyga> Well fun days
[08:10] <zyga> I will work a little after picking up the car
[08:11] <zyga> Some rpm things to finish
[08:11] <zyga> Then some more rpm
[08:23] <pedronis> pstolowski: morning, I saw that (the irony), I ended up making larger changes to #6306 promted by your request for more tests
[08:24] <mup> PR #6306: release: use locking around lazy intialized state <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
[08:24] <pstolowski> pedronis: k, thanks
[08:24] <pstolowski> yes, it's irony indeed
[08:25] <pedronis> pstolowski: please take a look at it when you can, there is more structures on the other end the Mock* methods are easier to follow I think
[08:34] <pstolowski> yes
[08:37] <pstolowski> pedronis: i'm playing with a potential fix for the retry slowness on remove; it's very fast now, although i need to think a bit still if not's looping too often now or something
[08:38] <pedronis> pstolowski: I'm looking a bit at your other PRs, otoh I was up working until quite late, so bit of a slow day I expect
[08:39] <pstolowski> pedronis: sure, i'm not ready to discuss the fix just yet, just sharing the observation :), i think it looks very promising
[09:02] <pedronis> pstolowski: does getInterfaceSetting  (it's in ctlcmd.go) has the same bug about not merging as the get config code?  the code look similar
[09:03] <pedronis> sorry, ctlcmd/get.go
[09:03] <pstolowski> pedronis: hmm good question, i didn't think of it, will need to check
[09:04] <pstolowski> pedronis: probably not becausause it doesn't use transactions, there is just one map in play, but i need to double check
[09:07] <pedronis> pstolowski: I left some notes in the hotplug ones,  one seems to be missing tests
[09:07] <pstolowski> ok, thanks
[09:23] <pedronis> pstolowski: I looked at #6322, the change is simple enough, but it seems the unit test situation is complicated, because we lose unit test coverage of GetFromChange
[09:23] <mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
[09:24] <pstolowski> pedronis: hmm i see, fair point. that method is now only used by interfaces i think. and btw getFromChange / getFromPristine names are probably not very accurate anymore
[09:25] <pedronis> yea
[09:25] <pedronis> also not sure what's the exact difference
[09:25] <pedronis> pstolowski: anyway it's good to have test elsewhere but we also need a unit test about the change itself
[09:26] <pedronis> the behavior is quite different
[09:26] <pedronis> there should be something that failed/was different before, works now even at that level
[09:42] <jamesh> zyga: hi.  If you've got time, do you have any thoughts about https://github.com/snapcore/snapd/pull/6258#issuecomment-448490796 ?
[09:43] <mup> PR #6258: interfaces: support D-Bus activation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6258>
[09:43] <jamesh> I've got things working on 14.04, but only by using different paths for the system service files compared to other distros
[10:31] <zyga> jamesh: hey, I'm on holidays for the next many days
[10:31] <zyga> but I will look anyway :)
[10:33] <pedronis> jamesh: hi, I should also very likely review your open PRs, unlikely to happen before the break at this point tough
[10:34] <zyga> jdstrand: interesting
[10:34] <zyga> er
[10:34] <zyga> jamesh: interesting problem
[10:35] <jamesh> zyga: fair enough.  Have fun!
[11:30]  * pstolowski lunch
[11:45] <mup> PR snapd#6323 opened: snap: give Epoch an Equal method <Created by chipaca> <https://github.com/snapcore/snapd/pull/6323>
[12:49] <pstolowski> pedronis: another question to 6306
[12:53] <pedronis> pstolowski: I don't understand the question, the equivalent now is appArmorProbe or mockAppArmorProbe kernelError
[12:54] <pedronis> pstolowski: whis is returned here:  https://github.com/snapcore/snapd/pull/6306/files#diff-a807fe2d471c632368aaab69caa1d77aR261
[12:54] <mup> PR #6306: release: use locking around lazy intialized state <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
[12:57] <pedronis> pstolowski: anyway I tried to answer also in the PR
[12:58] <pstolowski> pedronis: thanks, i misunderstood the code
[12:59] <pedronis> pstolowski: tbh all those globals were a bit confusing, I suppose the struct are confusing in a different way :)
[12:59] <pstolowski> pedronis: yeah
[13:10] <pedronis> pstolowski: :) about Simple, it was false already with the previous iteration by maciej, maybe the first iteration witht he lock was simple
[13:12] <pedronis> Chipaca: hi,  could you look at #6306 as well?
[13:12] <mup> PR #6306: release: use locking around lazy intialized state <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
[13:12] <pstolowski> heh, sure
[13:17] <pstolowski> pedronis: slow snap removal scenario - with a tentative fix - down to <40seconds from a few minutes
[13:17] <Chipaca> pedronis: 's nice
[13:18] <pstolowski> pedronis: and there's just 1 or 2 retries in that period, so it's basically down individual connects/disconnects now (there are lots of them due to number of interfaces)
[13:48] <mup> PR snapd#6306 closed: release: use locking around lazy intialized state <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6306>
[13:48] <pedronis> Chipaca: pstolowski: thanks, merged
[13:58] <mup> PR snapcraft#2429 closed: cli: fix usage string in help command <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2429>
[14:07] <om26er> Hi! I have a snap that runs a background service `daemon: simple` my process also starts a subprocess but seems that subprocess gets killed instantly
[14:08] <om26er> So systemd doing that or is there something missing inside snapd ?
[14:09] <om26er> relevant config here: https://github.com/om26er/screen-brightness-server/blob/master/snap/snapcraft.yaml#L35
[14:13] <om26er> zyga, ^^
[14:14] <zyga> om26er: hey
[14:14] <zyga> om26er: when you say it gets killed instantly
[14:14] <zyga> how do you know, what do you measure?
[14:14] <zyga> om26er: snapd is not doing that for sure
[14:14] <zyga> I suspect it may be systemd
[14:14] <zyga> do you have any apparmor or seccomp denials?
[14:14] <om26er> zyga, I see journalctl logs
[14:15] <zyga> om26er: (disclaimer: I'm on holidays, but  you know how things are sometimes :)
[14:15] <om26er> zyga, its currently in devmode so I assume apparmor isn't doing something bad
[14:15] <zyga> that's correct
[14:15] <zyga> can you reproduce that outside of snapd context?
[14:15] <zyga> with a service file and your code as is
[14:15] <om26er> zyga, I haven't tried that, I should probably do that.
[14:16] <om26er> ...and enjoy your holidays, its not urgent, I'll eventually find a solution
[14:16] <zyga> Ping me with the logs if you have them
[14:16] <zyga> I’ll be back in 15 minutes
[14:16] <zyga> Doing some house work now
[14:28] <zyga> om26er: looking at your yaml
[14:28] <zyga> om26er: what is the current working directory?
[14:29] <zyga> not sure if run is running as subprocess
[14:29] <zyga> but perhaps it cannot find "start" on path/
[14:31] <om26er> zyga, here is the log https://paste.ubuntu.com/p/WRBDSDGg5t/
[14:31] <zyga> Dec 20 19:26:19 X1C6 screen-brightness-server[9149]: 2018-12-20T19:26:19+0500 [Guest        9193] RuntimeError: Event loop stopped before Future completed.
[14:31] <zyga>  
[14:32] <zyga> Dec 20 19:26:19 X1C6 screen-brightness-server[9149]: 2018-12-20T19:26:19+0500 [Router       9184] Native worker received SIGTERM - shutting down ..
[14:32] <om26er> its correctly started line 103 and 104 indicate that
[14:32] <zyga> so, is your main process exiting?
[14:32] <om26er> yes that exists as well
[14:32] <zyga> exits or exists?
[14:32] <om26er> *exits, sorry
[14:32] <zyga> my question is this: if you fork, do something in child and exit in the parent
[14:32] <zyga> then you cannot do this with daemon: simple
[14:33] <zyga> read on systemd units and service types in particular
[14:33] <zyga> my recommendation:
[14:33] <zyga> simplify your code, don't fork
[14:33] <zyga> just run in the main process
[14:33] <om26er> from here https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335
[14:33] <om26er> I tried simple it gives me above error
[14:33] <zyga> I don't know your code but I don't believe your issue to be related to snaps in any way
[14:33] <om26er> I tried forking and notify seems the snap keeps on starting the service
[14:33] <zyga> I suspect you misuse systemd service units
[14:34] <zyga> you cannot use notify easily
[14:34] <zyga> I would recommend to see how your code runs with systemd services first
[14:34] <zyga> simplify it, as most of the time forking is a legacy concept
[14:34] <zyga> (forking daemons)
[14:34] <zyga> may I ask why your code forks?
[14:35] <zyga> is it for python multiprocessing?
[14:35] <zyga> (note that multiprocessing, AFAIK, requires a small tweak to work with snap confinement, I believe there's a forum thread about this)
[14:35] <om26er> generally the crossbar router is run on a different machine and its "clients" run on different. In this case the router and one of the client is running on the same machine.
[14:35] <zyga> ok
[14:35] <om26er> so I configured my router to start that client, so hence its forking
[14:35] <zyga> if the router keeps running
[14:36] <zyga> then systemd will be happy
[14:36] <zyga> the main point is that the process that is started must not exit
[14:36] <zyga> or systemd will consider the unit to have failed and will "restart" it
[14:36] <om26er> the router indeed keeps running its maybe a bug somewhere inside the router that isn't able to communicate that to crossbar
[14:36] <zyga> perhaps
[14:36] <om26er> *communicate that to systemd
[14:36] <zyga> did you get any interesting stuff in journald?
[14:36] <zyga> well, systemd just observes the process
[14:37] <zyga> I don't believe you can fool it this way
[14:37] <om26er> nothing interesting in journald, I'll the crossbar team regarding that
[14:37] <om26er> *ask (freaking typos)
[14:38] <om26er> or may need to re-architect my app
[14:38] <om26er> creating two different services may also work
[14:39] <zyga> om26er: nothing at all in journald or nothing just in the service unit of your snap?
[14:39] <om26er> one starts the router, the other starts the client.
[14:39] <zyga> denials would go to a different place (just curious if you hit any)
[14:39] <zyga> om26er: how do the apps communicate?
[14:40] <om26er> that above paste.ubuntu was from journalctl
[14:40] <om26er> zyga, over localhost (I may consider using a sock file though)
[14:40] <zyga> over network sockets?
[14:40] <zyga> that would work, yeah
[14:40] <om26er> yeah
[14:40] <om26er> the client-router in this case talk through websocket btw
[14:42] <om26er> so ultimately my chrome extension which is also another "client" connects to the router and makes a RPC to increase laptop's screen brightness when Netflix.com goes fullscreen
[14:42] <zyga>   lol
[14:42] <zyga> that's some elaborate software :D
[14:42] <zyga> nice
[14:44] <om26er> I was initially doing that over http ( was much simpler and worked as well ) but that was too boring and had limits, because I will ultimately enhance this daemon just do a lot more than just increase screen brightness.
[14:45] <om26er> move laptop cursor using Android app: Check
[14:46] <om26er> increase/decrease laptop screen brightness using Android app (requested a snapd interface for that already), lock laptop screen (snapd actually have an interface for that) using Android app.
[14:48] <om26er> You'd say most of those things are done by KDE Connect already, that's true but we (Crossbar.io) wanted to experiment those things using our technology stack.
[14:49]  * cachio lunch
[15:11] <popey> Chipaca: where is the source for https://snapcraft.io/test-snapd-complexion ?
[15:11] <Chipaca> popey: right here
[15:11] <Chipaca> popey: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-complexion
[15:12] <zyga> this is an internal test snap for snapd
[15:12] <popey> i see no snapcraft.yaml
[15:12] <zyga> it's not built with one
[15:12] <zyga> just "snap pack"
[15:12] <popey> ok, the reason I am asking is because an external developer is asking about completion
[15:12] <zyga> popey: most of our test snapd are built without snapcraft
[15:12] <popey> https://forum.snapcraft.io/t/tab-completion-for-snaps/2261
[15:12] <zyga> Chipaca: ^ ?
[15:12] <Chipaca> popey: on it
[15:12] <popey> this documentation refers to it but it's opaque
[15:12] <zyga> ohai
[15:12] <Chipaca> oh that's not the developer
[15:12] <popey> impossible to find the way you as a developer would create a yaml
[15:13] <popey> what the developer wants is some docs for how to setup completion
[15:13] <popey> and that doc gives half a story
[15:13] <Chipaca> popey: you point the 'completer' attribute of the app to the completer
[15:13] <zyga> (we should merge snapd and snapcraft teams)
[15:13] <Chipaca> popey: i'm not sure what rest-of-the-story there is
[15:14] <popey> (I'm after online docs, not answers to questions in irc) :)
[15:14] <Chipaca> popey: i was quoting from the docs you linked
[15:14] <popey> right, but people want a whole example
[15:14] <popey> and that doc links to something that doesnt use the way we usually recommend building snaps (snapcraft.yaml)
[15:14] <popey> so it's a bit fuzzy to pick up
[15:19] <Chipaca> popey: if it helps, snapcraft  uses snapcraft to build snapcraft and it has completion
[15:23] <Chipaca> does http_proxy=http://:8080 work?!?
[15:24] <Chipaca> looks like yes
[15:24] <Chipaca> wow
[15:24] <popey> https://github.com/digitalocean/doctl/blob/hholz/fix-snap-build/snap/snapcraft.yaml
[15:24] <popey> That's what they're currently doing (line 27/28) does that look sane?
[15:29] <zyga> I'm intrigued
[15:29] <zyga> I will add completion support to my app
[15:29] <zyga> and snap it
[15:35] <Chipaca> popey: looks like it
[15:35] <Chipaca> popey: but i don't know enough snapcraft to offer you certainty
[15:35] <zyga> reinforcing my desire to merge the teams
[15:35] <zyga> nobody outside of our team looks at snapcradt and snapd as separate things
[15:36] <Chipaca> zyga: ?
[15:37] <zyga> that we don't know snapcraft like the back of our hand
[15:37] <zyga> (is that the right phrase?)
[15:37] <Chipaca> zyga: how would merging the teams make me use snapcraft to the degree that I'd be able to know if something works just by inspecting the yaml?
[15:38] <zyga> we'd certainly know it more over time
[15:38] <Chipaca> zyga: keeping in mind that I'm reviewing snapcraft pull requests every week
[15:38] <zyga> and we'd ship features in sync more?
[15:38] <zyga> (woot, that's great)
[15:38] <zyga> (I'm not)
[15:38] <Chipaca> popey: is it not working for them?
[15:38] <popey> no
[15:40] <pedronis> zyga: I think it would make sense to have somebody that does a bit of both (depends which bits in snapd), merging the teams overall doesn't sound a great idea to me
[15:41] <Chipaca> popey: why?
[15:41] <popey> tab does nothing
[15:41] <popey> i need to debug it further after this meeting
[15:41] <Chipaca> popey: https://forum.snapcraft.io/t/debugging-tab-completion/4198 fwiw
[15:42] <Chipaca> popey: is the snap in the store?
[15:42] <popey> no, we're fixing a bunch of things
[15:42] <popey> ooh, thats neat, thank you
[15:42] <Chipaca> popey: I could take a quick look for the usual suspects if you have access to it
[15:42] <Chipaca> popey: if you do follow the debugging doc, feedback much appreciated
[15:43] <popey> passed that on, really great thanks
[16:40] <om26er> How can a snap "wait" for an interface to connect ?
[16:41] <om26er> I have daemon in my snap, which is useless if a specific interface is not connected, how can I make my daemon wait for that interface to connect ?
[16:41] <om26er> does snapd provide some sort of helpers for that or is that something I should take care of with my code
[16:49] <pstolowski> pedronis: pushed missing tests to #6113
[16:49] <mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
[16:50] <pedronis> pstolowski: thx
[16:55] <Chipaca> pstolowski: do you have any insight for om26er ^?
[16:59] <om26er> currently I am toying with this idea: i.e. retrying every 5 seconds to check if that specific interface was connected. https://paste.ubuntu.com/p/7VP2DZdjM9/
[17:01] <pstolowski> om26er: you can use interface hooks to notify you deamon about interface getting connected
[17:02] <pstolowski> om26er: https://docs.snapcraft.io/interface-hooks/8214
[17:03] <om26er> reading into that
[17:05] <pstolowski> om26er: i hope that helps
[17:08] <om26er> pstolowski, thanks for the link :-)
[17:08] <pstolowski> roadmr: hey, u there?
[17:08] <roadmr> hi pstolowski
[17:08] <pstolowski> roadmr: hey, i've completely missed your email from a few days ago, sorry about that!
[17:09] <roadmr> pstolowski: oh! hey, not a problem
[17:10] <roadmr> pstolowski: I did some experimentation yesterday and have responded to the customer. Things do work and auto-connect the moment the two snaps are in the system; i.e. installation order doesn't matter
[17:10] <pstolowski> roadmr: now, i don't know all the answers, some of that is not possible for sure, some stuff i need to check/discuss internally. can this wait till after holidays?
[17:10] <roadmr> pstolowski: yes, not a problem, we can check again once back from EOY
[17:11] <pstolowski> roadmr: ok, great, thanks, i'll get back to you on that
[17:12] <roadmr> thanks pstolowski.
[17:12] <pstolowski> roadmr: np, and sorry i didn't respond earlier
[17:12] <roadmr> pstolowski: hehe no worries, we all get tons of e-mail,it does happen
[17:15] <pstolowski> ok, with that i'm gonna wrap up this year, all the best to everyone and have great holidays!
[17:17] <pstolowski> o/
[17:43] <cachio> zyga, hey
[17:43] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/468916546#L3283
[17:43] <cachio> I am updating the opensuse images and still see errors
[17:44] <cachio> previously updated and refreshed using zypper
[17:44] <cachio> any idea if something is missing?
[17:59] <Chipaca> pedronis: I'll be working a little bit tomorrow morning to try to get this into a PR, it's that close :-)
[17:59] <Chipaca> EODing now, ttfn
[19:00] <cachio> zyga, found the problem
[19:45]  * cachio afk
[22:26]  * cachio EOD