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