[00:53] sure thanks kyrofa. if you are around [00:53] will get back and look through it === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:53] beuno, jdstrand: Just uploaded a tiny fix for LXD 2.0.0 to the store (use the old lxcbr0 bridge as we don't have lxdbr0 on snappy yet) [03:53] folks upgrading didn't have any issue with rc9 or 2.0 final, but folks doing a clean install would have got broken networking, this will fix new installs [03:53] cyphermox: ^ [05:09] stgraber: thanks === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:31] Hi snappers, when using the snap find command, I don't see the fully qualified app name, how can I install apps without it? [09:59] Anyone, zyga maybe? ^ [09:59] "when using the snap find command, I don't see the fully qualified app name, how can I install apps without it?" [10:00] davidcalle: store bug [10:00] davidcalle: and it's snaps, not apps [10:04] zyga =) ty [10:13] davidcalle: beuno mentioned the other day they are working on automating this, for now we may need to set aliases for the store apps (worst case manually until this is automated). but I'm not sure what the status is, maybe its fixed already, beuno will know [10:16] ubuntu@localhost:~$ snap install webdm [10:16] error: access denied [10:16] mvo, can we make that message a bit more user friendly ? [10:17] (it used to tell me i should use sudo etc) [10:17] Any idea why this doesn't compile on arm? https://github.com/kyrofa/mdns-publisher/blob/master/main.go [10:18] mvo: thanks [10:18] Actually, that's wrong, it compiles, but fails in the stripping phase [10:27] ogra_: yes, I think we should [10:29] Building dependency tree... [10:29] E: Unable to locate package ubuntu-core-libs [10:29] P: Begin unmounting filesystems... [10:30] mvo, s390x and ppc64el fail with that ^^^ [10:30] do we not build that package there ? [10:35] https://bugs.launchpad.net/snappy/+bug/1569280 [10:35] Launchpad bug 1569280 in Snappy "Snapcraft fails to strip go binaries on arm" [Undecided,New] [10:36] ogra_: I'm surprised by that, I think that worked before :/ [10:36] mvo, did we ever buikld images for them ? [10:36] (i just added both arches and started a testbuild) [10:38] OH ! [10:38] * ogra_ wasnt aware it is a meta package :P [10:40] ogra_: I don't think we did images for them [10:40] right [10:44] where the heck do the seeds live for that package ? [10:46] ah, found them [10:51] kyrofa: hi sorry for the noise, store question : if i have rev1 of v1.0 of my snap that's have been automatically rejected, i need to upload v1.0.1(for ex) ? [11:25] is there a reason the names of the binaries in /snaps/bin don't match the ones in the snaps themselves? [11:27] attente, got an example ? [11:27] ogra_: ubuntu-calculator-app for example [11:27] * ogra_ never used that [11:28] i meant an example of the binary names :) [11:28] vs what you expect [11:28] ogra_: maybe a better question is what is the canonical way of launching a snap [11:28] packagename.binary-name [11:28] i.e. in my nethack snap i defined "run" ... to start my game i now need to exec nethack.run [11:29] ogra_: so in ubuntu-calculator-app, i think the Exec line of the desktop file is incorrect possibly [11:29] well, i thought dpm has tested that [11:30] ogra_: it just has the line 'Exec=ubuntu-calculator-app [11:31] and there is no binary of that name in the snap ? [11:31] (not sure if .desktop files are simply handled differently) [11:31] i never used them :) [11:32] ogra_: no, there's only /snaps/ubuntu-calculator-app.ubuntucoredev/current/usr/bin/ubuntu-calculator-app [11:32] then thats fine i guess [11:32] ogra_: but /snaps/*/current/usr/bin isn't in the user's path [11:32] only /snaps/bin is [11:33] so it finds /snaps/bin/ubuntu-calculator-app.calculator instead [11:33] well, i dont exactly know how ,.desktop files are operated in snappy ... but i guess it is only run inside the confined env ... where that path will be exported by the launcher [11:34] * ogra_ assumes /snaps/bin/ubuntu-calculator-app.calculator is a script [11:34] yes [11:35] then it will likely set the path correctly [11:37] ogra_: so i should probably not be using the desktop file at all and just using the script in /snaps/bin directly? [11:37] since it seems like the desktop file refers to the binary in the snap itself and not /snaps/bin [11:38] you should use the ,.desktop files from GUIs obviously ... :) [11:39] no idea how the integration works with that though [11:39] from commandline you shoudl always just run ubuntu-calculator-app.calculator [11:58] ogra_: can you make metapackages with Snappy or does it have to all be in the package? [11:59] whoops, snap, not package :) [11:59] tsimonq2, whats the difference ? [11:59] :) [11:59] heheheh [11:59] a snap *is* essentially a metapackage :) [11:59] well [11:59] oh I see [11:59] containing all the bits and pieces [12:00] so let's say I want to make the bob metapackage, and include like 20 deb dependencies, would that work smoothly? [12:00] ooh, could I get it from upstream instead if I wanted to? [12:01] sure, you would just define all the debs in your snapcraft.yaml and snapcraft would include them [12:01] and yes, you could as well use the upstream source [12:01] are the debs only from Ubuntu or can they be from Debian as well? [12:01] for one or even for all your deps [12:01] only from ubuntu [12:01] oic [12:01] is there a tutorial I could follow to do this? [12:02] or is it really simple? [12:02] there are examples in the snapcraft-examples package [12:02] is that a deb package that I could install now, or a snappy package? :D [12:02] snapcraft is a deb package ... note though that you need xenial if you build for xenial snappy [12:03] I'm on Xenial :) [12:03] good [12:03] well, "sudo apt install snapcraft" [12:03] ;) [12:03] * tsimonq2 does sudo apt update && sudo apt -y install snapcraft snapcraft-examples [12:04] :) [12:04] create a workdir ... create a snapcraft.yaml file ... run "snapcraft" in the workdir and if your yasml file is correct you get a working snap ;) [12:04] *yaml [12:04] where are the examples then? :) [12:04] i guess in /usr/share7doc [12:05] also, can I upload snaps to PPAs? [12:05] dpkg -L snapcraft-examples will tell you as usual ;) [12:05] no [12:05] that would be an awesome feature [12:05] you can use launchpad to build snaps from a snapcraft.aml in a bzr branch [12:05] and you can upload them to the store [12:06] snaps *are* PPAs ... like they are metapackages ;) [12:06] oh okay :) [12:06] so let's say I have my snap built and all ready to go, how do I test it? [12:07] in xenial you shoudl actually be able to install it directly on your system ... [12:07] at least after release, not sure what bugs are still there [12:07] it would replace packages and cause a big huge mess, I would prefer a VM :) [12:07] alternatively you can run a complete snappy in kvm or on i.e. a raspberry pi [12:07] no, it wouldnt cause any mess [12:08] KVM? I thought there was a guide somewhere for that... [12:08] snappy on classic installs is a feature of xenial :) [12:08] installing a snap will "just work" ... snaps live in their own filesystem space, they wont mess up anything [12:09] (it shoudl already work if your xenial system is up to date, ubuntu-snappy-cli should be installed) [12:10] ogra_: What's the strategy when we need to ship a firewall, log rotater, etc. It's not really efficient to add it to every single snap part of a solution [12:11] you would creater a library snap that all your other snaps (only yours though) can consume [12:11] ogra_: Ah, good. Is there doc on that already? [12:11] not sure [12:13] ogra_: if I create a snappy package from upstream, will it automatically pull in updates from there? [12:13] for example GitHub [12:13] if you re-build it [12:15] that seems a bit tedious :| [12:15] is it easy to rebuild and reupload? [12:16] if your snapcraft.yaml is correct it should be one click in launchpad [12:16] (modulo build failures that the upstream changes introduce indeed ...) [12:16] can you set up daily builds? [12:17] i think launchpad receipes are supported ... not sure though [12:18] I'll try later today :) [12:18] then to update everything is sudo snappy update? [12:19] sudo snap update [12:19] the "snappy" command is dead [12:19] why? [12:19] 2 extra letters? :P [12:19] dunno [12:20] * ogra_ wasnt involved in that discussion :) [12:21] alright, thank you ogra_, I'm off for a few hours, have a nice day. :) [12:21] you too [12:36] kyrofa, sergiusens: can you maybe advise on https://bugs.launchpad.net/click-reviewers-tools/+bug/1569226? [12:36] Launchpad bug 1569226 in click-reviewers-tools (Ubuntu) "click-review crashed with KeyError in check_apps_plugs_mapped_oldsecurity(): 'plugs'" [Medium,New] [12:36] I don't know what the right fields and stuff are [12:36] Hey dholbach! [12:36] hey hey - how are things? [12:37] morning [12:53] eeek ! [12:53] sergiusens, ! [12:54] sergiusens, all our initrds use lzma now ... seems the kernel plugin has no check about the compression method and just assumes gzip [12:58] ogra_, well, not really; it said we only supported that for now [12:58] lzma or lzma2 or xz? [12:58] bug 1569337 [12:59] bug 1569337 in Snapcraft "snapcraft kernel plugin needs to check compression method of the initrd before trying to unpack it" [Undecided,New] https://launchpad.net/bugs/1569337 [12:59] ogra_, thanks [12:59] ogra_, probably an EOW thing [13:00] yeah [13:07] dholbach, things are frantic, haha [13:07] dholbach, any chance that bug relates to the removal of old-security from snappy? [13:07] kyrofa, I don't know which fields are current and which old fiels should still be allowed [13:07] but this breaks store reviews right now [13:08] dholbach, join the club, things are changing fast :( [13:08] dholbach, I believe old-security is gone and one needs to use the actual interface names now. But then I heard maybe that would come back [13:08] dholbach, zyga would know more on that one [13:09] old-security is gone now [13:09] but we'll probably bring it back later, for now use real interfaces [13:09] they are listed in docs/interfaces.md [13:09] note that only auto-connecting interfaces really work as connection/disconnection commands are not wired to the backend yet [13:09] that will land today though so all the interfaces will be fully functional [13:09] ok... I guess I need to talk to jdstrand to find out what policy should be in this case... reject snaps which don't have proper interface names? [13:10] dholbach, I guess so. I thought we had old-security as a migration plan, but I guess not? [13:11] dholbach: snappy validates that internally [13:11] kyrofa: it's all crazy :) [13:12] zyga, I've noticed :) [13:12] kyrofa: I want to add old-security back but that's not top-priority [13:12] top priority is fully functional REST api for managing interfaces [13:12] zyga, I'm not sure it's necessary since everyone is broken now-- everyone will have to move to interfaces if they want stuff to work [13:12] kyrofa: true [13:13] kyrofa: but some edge cases need old security [13:13] zyga, right... but the store needs to check it too [13:13] sergiusens: can you release snapcraft that allows something other than old security today? [13:13] dholbach: no [13:13] dholbach: the store doesn't have to check it in any way [13:13] zyga there is no docs/interfaces.md in snapcraft [13:13] dholbach: we'll add some checks via assertions but that's not today [13:13] oparoz, that's snappy [13:13] ppisati, fwiw ogra_ logged a bug about the gzip issue [13:13] oparoz: sorry, look at snappy [13:13] oparoz: github.com/ubuntu-core/snappy/ docs/interfaces.md [13:13] zyga, what if somebody uploads an old style app to the store [13:14] zyga, today? wow [13:14] Thanks guys [13:14] zyga, with no plugs defined [13:14] dholbach: nothing [13:14] dholbach: it will just run without any extra permissions, fully confined [13:14] dholbach: snappy ignores unknown or invalid interfaces [13:14] zyga, we can, but we need old-security replacements for our examples [13:15] sergiusens: I'd be fine with a half-broken release that lets people snapcraft non-broken snaps without old-security [13:15] sergiusens: I suspect that most of those can just use normal interfaces but I didn't check [13:15] zyga, right, but we won't be able to know if snapcraft itself is working [13:15] or doing the right thing [13:16] sergiusens: ideas welcome, right now you cannot build a snap that uses unity7 + x11 plugs [13:16] sergiusens: I don't know snapcraft as well as you do, what would be the best way forward? [13:16] zyga, 1st; is there an os image in edge that works already? [13:17] sergiusens: mvo built a package, the image is soon after that I bet [13:17] zyga, 2nd; do we have replacements for everything in `examples` wrt interfaces? [13:17] sergiusens: I don't know what's in all the examples [13:17] zyga, 3rd; is old-security coming back or gone forever? [13:18] if it is gone, I'd rather have it gone forever [13:18] sergiusens: 3 not sure, I can implement it but if powers that be demand it gone, what can we do? [13:18] sergiusens: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md [13:18] sergiusens: that is what we have today [13:18] thanks... I'll just catch the error if no plug is defined [13:18] think that should be fine [13:19] zyga, create a snapcraft bug and I'll work on a branch; kyrofa heads up, we might release today [13:20] sergiusens, thanks for the heads up [13:20] sergiusens, though that probably means we need to do the examples as well [13:27] sergiusens: sure; I'll open the bug in a moment [13:28] has something changed with the /run/snapd.socket api in the past day? i seem to only be getting 404 errors now [13:28] attente: many things were removed [13:28] attente: look at docs/rest.md (it has been updated AFAIK) === chihchun is now known as chihchun_afk [13:29] attente: which endpoints were you calling [13:30] zyga: for example GET /2.0/snaps?sources=local [13:31] zyga: docs/rest.md was removed too? [13:32] zyga: ok, i'll take a look, thanks for the pointer [13:33] attente: no, it is still there? [13:33] https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#v2snaps [13:33] attente: the prefix changed so you just have to update your client code [13:35] zyga: ok, thanks. is the api going to be frozen at some point? [13:35] attente: when we release 1.0 I suspect [13:35] attente: though there will be less changes made now [13:35] attente: you can expect additions rather than changes [13:39] zyga: fyi, there are checks that the review tools need to do in the absence of assertions [13:40] jdstrand: perhaps but I don't know what the plan is for that [13:40] zyga: I will handle the review tools [13:40] dholbach: ^ [13:40] jdstrand: thank you! [13:41] but there is no point in changing them atm until we have a working system [13:41] so, perhaps later this week [13:41] jdstrand: do you know where we are today? [13:41] not yet [13:42] jdstrand: we got auto-connection feature landed, also for x11 and unity7 [13:42] jdstrand: I'm working on some tweaks to connection control so that it persistst properly and that users are in control [13:43] zyga: x and unity7 are autoconnecting? can you explain what you mean by autocontrol? [13:43] jdstrand: x11 (it was renamed) [13:43] jdstrand: it gets connected to os snap on install [13:43] I understand what that means [13:44] that also is a security hole [13:44] so we had the idea that there would be some sort of prompting [13:44] what happened with that? [13:44] beuno: ^ ? [13:46] jdstrand: there's no propmpting for that as there's no UI for install [13:46] I didn't mean an install prompt [13:46] jdstrand: oh? [13:47] what I suggested was no autoconnect on install. then on first use, prompt the user somehow, letting them know the app wants privileged access to the user's session. the user says yes or no. if yes, there is an interface connect [13:47] this prompt could be done via zenity, or anything really. mvo was in agreement on the approach [13:47] there is a card on the idea, but I think beuno was shopping it around [13:48] jdstrand: that's not realistic today [13:48] jdstrand: we'll improve it with SRUs [13:48] maybe not 'today' but interface connect is surely something for 16.04 release? [13:48] jdstrand: yes [13:49] jdstrand: quick question, we don't need ubuntu-core-security-{apparmor,seccomp,utils} anymore, correct? [13:49] so it should be realistic for 16.04 release [13:49] mvo: correct [13:49] ta [13:49] mvo: they should be removed from the archive too [13:49] jdstrand: there will be no prompting for 16.04 [13:49] jdstrand: we can explore that after the release [13:50] zyga: why? who decided that? we are making announcements for this. where was this discussion? [13:50] jdstrand, mvo: FYI we only run apparmor_parser but templates seem to refer to included files [13:50] zyga: the prompt can be as simple as updated the shell script [13:50] zyga: the includes don't come from ubuntu-core-security. they come from apparmor [13:50] jdstrand: there are no APIs to implement the prompt [13:50] we don't need it [13:51] jdstrand: it's not just the UI [13:51] all we need is interface connect foo unity7 [13:51] or whatever the api is [13:52] jdstrand: yes and that's not ready yet [13:52] jdstrand: I'm trying to get it ready [13:52] zyga: but you said a moment ago it would be for 16.04 release [13:52] jdstrand: auto connect is internal [13:52] jdstrand: connect/disconnect requires an API [13:52] I don't care about *today* so much as when someone tries to use this thing on release day, people see the choice [13:53] jdstrand: I'm trying to implement the API so that we can use it but it's not working as of this second yet [13:53] jdstrand: the goal is to get it working today (API) but I don't think we can manage a GUI at this stage [13:59] a gui is a zenity prompt [13:59] snappy sees if x11 or unity7 interface (or home) is requested. oh, it is, insert this zenity prompt in the shell script [13:59] jdstrand: can you implement one quickly? perhaps we can manage that? [14:00] jdstrand: note that there's a REST API there [14:00] I need beuno to confirm it is ok [14:00] jdstrand: so it's not a simple sequential client [14:00] zyga: where is the rest api? [14:00] jdstrand: you'd have to install the snap, inspect available plugs [14:00] jdstrand: deamon/api.go, the docs are in docs/rest.md [14:01] jdstrand: then see if your new snap has x11 or unity7 plug [14:01] jdstrand: and then offer a quick prompt (even without zenity, just a simple stdin prompt) [14:01] jdstrand: and then call .Connect() [14:01] jdstrand: note that there are GO bindings for the api (look at client/interfaces.go) [14:01] jdstrand: I think someone could look at doing that but I need to finish connect/disconnect first [14:04] jdstrand: also note that you need to work with cmd/snap/cmd_ops.go (AFAIR) because that's where install is [14:04] jdstrand, mvo: can tell you more [14:04] when I spoke to mvo before he said that he thought this was all managable. that was a few weeks ago [14:05] jdstrand: I thnk that explains it [14:05] jdstrand: there were many things that got us busy [14:06] sure, I understand [14:06] I'm not upset about that or anything-- I just want to make sure this is handled in some way [14:08] jdstrand: I understand, I'm sorry if I seem defensive :-) I'm just tired and we're all racing to get bits in place [14:08] no worries [14:28] mvo: can you ping me when you adjust the seeds for ubuntu-core-security? [14:34] jdstrand, thanks [14:34] jdstrand, I'll follow up on the notify-when-x [14:34] thanks! [15:06] ogra_: any news about the new archs? I'm digging all the emails from yesterday but haven't seen anything. [15:08] elopio, well i got no mails (probably olli forgot to forward something) ... but i have the rootfs snaps building (sadly they arent published yet because i still need to teach livecd-rootfs to not try to build kernel snaps for them) [15:09] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ both fail right after creating the ubuntu-core os snap [15:17] the image PPA is still not building for s390x. mvo: can you enable that? or do you know who can? [15:21] noise][: can you help me with spi? I'm getting 401 checking for the results of the run I launched. https://paste.ubuntu.com/15793410/ [15:28] cjwatson: who should I talk to about s390x builds for https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages ? is that something you could enable or do I need to ask IS? or can I do it myself if I find the right knob :) ? [15:28] elopio: I ask someone who knows everything ;) [15:29] elopio: I think I can not do it myself [15:29] elopio: hey.. that's odd [15:29] you can't do it yourself because s390x has no virtualised builders yet, so it lacks sandboxing [15:30] but I see that PPA is already devirtualised [15:30] mvo: done [15:30] * ogra_ cureses about livecd-rootfs code .... [15:31] mvo: new builds aren't auto-created, but if you want to create new builds of an existing source in that PPA without reuploading, you can copy the source over itself including existing binaries and that has the side-effect of creating missing builds [15:31] feels like i painted myself into a corner, skipping kernel creation for one arch is really hard now :/ [15:31] mvo: (also obviously only xenial, since s390x didn't exist before that) [15:32] cjwatson: \o/ [15:32] cjwatson: thanks a bunch [15:34] np [15:34] cjwatson: mvo: thanks! [15:35] sergiusens: saw it [15:35] noise][: here in the dragonboard section is all I did, in case it helps: http://pad.ubuntu.com/spi [15:35] sergiusens: i'm a bit nervous about the 'snappy login' step, i bet there's no way to skip it [15:36] ppisati: snap login, snappy is gone [15:36] zyga: snapcraft login i mean [15:36] ah [15:36] zyga: what does it do btw? [15:36] ppisati: I'm not quite sure [15:36] sergiusens: ^ [15:41] * ogra_ guesses it logs you in [15:42] :P [15:43] ogra_: ok, but why it needs to log me into UU build a kernel/snap? [15:43] heh, no idea ... i was just stating the obvious :P [15:44] * ogra_ doesnt even know where to it logs you in [15:44] ah ok [15:45] i assume "snapcraft snap" should still work without login though [15:45] (it does on the livefs builders ... and we wouldnt be able to use any kind of login there( === shuduo is now known as shuduo-afk [15:46] elopio: can you try to query the results w/o the test opp query param? [15:47] just https://spi.canonical.com/products/$PRODUCT_ID/tests/events [15:47] ogra_: nope, it requires the login [15:47] http://pastebin.ubuntu.com/15794106/ [15:47] btw i thought 'snap' was the default target [15:47] ppisati, well, it has to be skippable, else we cant build images [15:48] zyga, sergiusens ^^^ [15:48] there is no way we can add credentials on the image builders, nor can they see the store [15:49] ogra_, ppisati the login is to download the os.snap. I wasn't sure it was possible to download without being logged in [15:49] sergiusens, just grab it from cdimage :P [15:49] * zyga doesn't know what login is for in the long term, cannot comment [15:50] sergiusens: does it store my credentials somewhere? [15:51] ppisati, yes, in the form of oauth; not the password [15:52] ppisati, ~/.config/snapcraft/snapcraft.cfg [15:52] sergiusens, how would that work for i.e. a launchpad based build ? [15:52] it is only the kernel plugin [15:52] where you simply dont have these credentials [15:52] ogra_, ^ [15:53] only the kernel plugin [15:53] kernel plugin is experimental [15:53] sure, but what stops me from using the kernel plugin ibn an LP build [15:53] nothing is set on stone [15:53] and as I said multiple multiple multiple multiple times [15:53] this download thing goes away as soon as snappy does the initrd dance the correct way [15:54] ogra_, ^ what stops you is the fact that you need to login [15:54] (i doubt that will happen before next LTS :P ) [15:54] * ogra_ is obviously very pessimistic wrt the SRU process of massive architectural changes :) [15:58] noise][: same result. [16:00] elopio: hmm, and is that repeatable? starting w/a new product? [16:26] noise][: let me try that. [16:33] noise][: I can't create it anymore. Now I get 401 on the first step. [16:33] oh, wait, no there was a typo. [16:33] going on... === qengho_ is now known as qengho [16:35] zyga, I logged https://bugs.launchpad.net/snapcraft/+bug/1569452 since I am impatient [16:35] Launchpad bug 1569452 in Snapcraft "Update snapcraft to use new interfaces" [Undecided,New] [16:36] noise][: reproduced again, I created everything from scratch, made a POST on the images endpoint and got 201. But when I query the tests/events, I get 401. [16:46] elopio: ok, I don't have time to dig at the moment, but can try to repro later this afternoon [17:16] jdstrand, zyga can you check if I made as "an accurate as possible" translation of things here https://github.com/ubuntu-core/snapcraft/pull/441/files [17:16] I am aware some things will just not work [17:17] like busybox which would need a read_path of / at least [17:17] looking [17:18] not sure what `network-management` was for, I hope it was covered by `network-bind` and also not sure I need `network` if I have `network-bind` [17:18] sergiusens, I was just about to ask that question :P [17:18] nor if `network-service` is covered in any way [17:19] network-service is now network-bind, I believe [17:19] my gut says it would [17:19] or anything needing network-bind would need network [17:20] * sergiusens is sad for removing all those tests though [17:20] sergiusens: network-management is more like "I want to be network-manager" [17:20] network == client; network-bind == server) [17:21] zyga, ok, so for something that listens on a port and also talks to the network I need both? [17:21] it won't hurt [17:21] but I suspect network-bind gives you network [17:21] jdstrand: can clarify [17:21] zyga, I'll wait for your first pass [17:21] we should add those kind of FAQs to the docs :/ [17:21] sergiusens: I reviewed it already [17:22] oh; yeah, the docs aren't really all that complete ;-) [17:23] zyga, the mosquitto one, elopio can you look ^ [17:23] zyga, if you look at how the listener plug is defined it seems to indicate it needs `network` and not `network-bind` [17:23] sergiusens: sorry, I'm so drained today I feel like I'm about to fall asleep right here; [17:24] my comments were based purely on the names [17:29] sergiusens: network-management was network-admin on 15.04 [17:29]