[00:36] <wililupy> how do I delete a user from a device?
[00:52] <wililupy> Figured it out. I had to remove them from the files located in /writable/system-data/var/lib/extrausers and then delete their home directory and then I could re-add them with the snap create-user account.
[06:33] <mup> PR snapd#2429 opened: snap-confine,debian: disable XDG_RUNTIME_DIR support, package snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2429>
[06:54] <mup> PR snapd#2380 closed: debian: add missing ca-certificates dependency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2380>
[06:55] <mup> PR snapd#2365 closed: interfaces: fix system-observe interface to work with ps_mem <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2365>
[07:13] <mup> PR snapd#2430 opened: cmd/snap-confine: disable support for XDG_RUNTIME_DIR <Created by zyga> <https://github.com/snapcore/snapd/pull/2430>
[07:16] <mup> PR snapd#2431 opened: cmd/snap-confine: don't use __attribute__((nonull)) <Created by zyga> <https://github.com/snapcore/snapd/pull/2431>
[07:20] <mup> PR snapd#2414 closed: store: switch default delta format from xdelta to xdelta3 <Created by wgrant> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2414>
[07:22] <mup> PR snapd#2394 closed: snap: show last refresh time <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2394>
[07:50] <mup> PR snapd#2412 closed: snap: add description to `snap info` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2412>
[07:51] <mup> PR snapd#2432 opened: cmd/snap-confine/tests: fix stale path after move to snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/2432>
[08:03] <dholbach> hey hey
[08:10] <mvo> ogra_: good morning. I noticed pc-kernel has new stable versions, do you know how those got promoted? is the kernel team taking care of this?
[08:31] <seb128> hey dholbach mvo
[08:32] <mup> PR snapd#2431 closed: cmd/snap-confine: don't use __attribute__((nonull)) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2431>
[08:32] <seb128> sergiusens, hey, sorry you reply when I was already away yesterday ... is there any way to snapcraft to not try to be clever? I don't include the librairies because I want to use them over content sharing
[08:33] <dholbach> hey seb128
[08:33] <mup> PR snapd#2432 closed: cmd/snap-confine/tests: fix stale path after move to snapd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2432>
[08:35] <seb128> sergiusens, is that behaviour also documented somewhere? I can see how it can be useful but also it's not obvious which means confusing (especially if you know what you are doing and don't expect the tool to try to outsmart you)
[08:36] <mup> PR snapd#2433 opened: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
[09:04] <didrocks> cjwatson: hey! It seems that launchpad builders for snapcraft can't download from people.canonical.com. Do you think this could be easily fixed or should I host the tarball somewhere else? https://launchpadlibrarian.net/297163330/buildlog_snap_ubuntu_xenial_amd64_christmas-music-carousel_BUILDING.txt.gz
[09:14] <ogra_> mvo, yeah, bjf and ppisati do that now
[09:18] <bzoltan> ogra_:  may I ask what kernel the latest Core has?
[09:27] <ogra_> bzoltan, always the latest from updates/security
[09:41] <mvo> ogra_: ok, so we can remove the trello card that we need to sync kernels snap updates, thats good news
[10:01] <ogra_> mvo, yeah, there are still some bits open with QA i think, but they own the main branches .... we can go on using the old bzr branches for edge builds though, so that we can develop initrd stuff etc
[10:01] <ogra_> (and i guess we'll move these too to github eventually)
[10:28] <mup> PR snapd#2430 closed: cmd/snap-confine: disable support for XDG_RUNTIME_DIR <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2430>
[10:29] <mup> PR snapd#2429 closed: snap-confine,debian: disable XDG_RUNTIME_DIR support, package snap-confine <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2429>
[11:02] <cjwatson> didrocks: fixable, but might take a little while because we have a complicatedly-broken CI job in the way of making changes to that
[11:02] <cjwatson> didrocks: could you file a bug against the "rutabaga" project (don't ask ...) requesting that?
[11:26] <kalikiana_> ogra_: Do you know if anyone is investigating bug 1647333?
[11:26] <mup> Bug #1647333: adduser misses extrausers support for group management <Snappy:New> <adduser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1647333>
[11:27] <mup> Bug #1648427 opened: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:New> <https://launchpad.net/bugs/1648427>
[11:30] <ogra_> kalikiana_, are you volunteering ? :)
[11:31] <mup> PR snapd#2434 opened: tests: cherry-pick spread test fixes for 2.18.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2434>
[11:36] <mup> Bug #1648431 opened: Allow snaps to shadow mounts from core <Snappy:In Progress by kalikiana> <https://launchpad.net/bugs/1648431>
[11:56] <kalikiana_> ogra_: Depends... I seem to be touching lots of "random" bits and pieces these days without knowing what I'm getting into :-D
[11:56] <kalikiana_> It's blocking snappy lxd so I am kinda interested in getting it fixed
[12:12] <didrocks> cjwatson: sure, doing!
[12:32] <mup> PR snapd#2435 opened: store: retry assertions <Created by stolowski> <https://github.com/snapcore/snapd/pull/2435>
[12:36] <moritz_> I have a little problem with dbus activation. The app feedreader starts feedreader-daemon via dbus calls. Problem is dbus runs the daemon installed on my system not the daemon packaged in my snap. Any ideas?
[12:50] <cjwatson> didrocks: ...?  (preparing a commit to fix it, would like to have a bug number)
[12:52] <didrocks> cjwatson: oh sorry, was in some HO, doing it now, one sec
[12:53] <didrocks> cjwatson: bug #1648451
[12:53] <mup> Bug #1648451: people.canonical.com not accessible from builders <Rutabaga:New> <https://launchpad.net/bugs/1648451>
[12:54] <cjwatson> ta
[13:32] <jdstrand> mvo: I see you marked 1648427 as 'high'. what is a simple reproducer? I'd like to investigate a simple fix
[13:32] <jdstrand> bug 1648427
[13:32] <mup> Bug #1648427: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
[13:38] <didrocks> it's a duplicate btw
[13:38] <didrocks> I did write about it on my feedback emails a week ago
[13:38] <didrocks> (I see they were read :/)
[13:38] <didrocks> mvo: ^
[13:38] <didrocks> bug #1644573
[13:38] <mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
[13:40] <mup> Bug #1644573 changed: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
[13:42] <jdstrand> mvo, zyga: I'd like to look at bug #1644573 (bug #1648427) for a simple fix. what is a simple reproducer? snapctl ...what... within a shell without networking?
[13:42] <mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
[13:42] <mup> Bug #1648427: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
[13:43] <didrocks> jdstrand: just create a configure hook calling snapctl
[13:43] <didrocks> the configure hook with no plug
[13:43] <didrocks> I have one snap for you if you want
[13:43] <jdstrand> that'll work too
[13:43] <mup> Bug #1648427 changed: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
[13:43] <mup> Bug #1644573 opened: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
[13:43] <zyga> jdstrand: hey, anything using the client package (e.g. snapctl) that doesn't have the right to talk to snapd over the full socket AFAIK
[13:44] <jdstrand> zyga: I know. just snapctl without args? assume for just a moment I don't know how to use snapctl :)
[13:44] <didrocks> jdstrand: you can install snow-on-me snap
[13:44] <didrocks> in stable channel
[13:44] <jdstrand> ok, that'll be good enough
[13:44] <didrocks> jdstrand: remember that on 16.04, snapd is too old to work well with configure hooks
[13:45] <didrocks> (desktop)
[13:45] <jdstrand> didrocks: I'm running 2.17 from proposed. is that new enough?
[13:45] <didrocks> jdstrand: I think, do you run as well a newer ubuntu-core with snapctl inside?
[13:45] <jdstrand> I can
[13:45] <didrocks> (as the core snap)
[13:46] <didrocks> otherwise, you will see quickly, you will miss snapctl inside core
[13:46]  * jdstrand runs sudo snap refresh core --edge
[13:47] <mup> PR snapd#2436 opened: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2436>
[13:47] <jdstrand> oh, that's neat
[13:47] <moritz_> was the snap.second-command syntax changed? I got an error yesterday and it worked when i changed to snap-second-command. (v2.16)
[13:47] <jdstrand> snap run --shell snap.hello-world.env
[13:47] <jdstrand> error: cannot find current revision for snap snap: readlink /snap/snap/current: no such file or directory
[13:47]  * jdstrand drops snap.
[13:48] <mvo> didrocks: sorry, but look at it from the bright side, your bug gets attention :)
[13:48] <didrocks> mvo: for once, yeah :p
[13:48] <didrocks> mvo: still frustrating TBH
[13:50] <mvo> didrocks: :(
[13:50] <mvo> didrocks: sorry
[13:52] <mvo> didrocks: on the bright side, snap info will be able to look into edge now too, not quite snap search but still.
[13:53] <didrocks> great
[13:53] <jdstrand> ah, just 'snapctl' is enough
[13:55] <mup> Bug #1648478 opened: 'snap run --shell snap.hello-world.env' tries to read /snap/snap/current <Snappy:New> <https://launchpad.net/bugs/1648478>
[13:56] <kalikiana_> zyga: I wonder if you could have a look at https://github.com/snapcore/snapd/pull/2436/files and see what I might be doing wrong - it doesn't create the .fstab file that the "content" interface creates. Also I half-hard-coded the path since I wasn't sure how to get a map from the yaml
[13:56] <mup> PR snapd#2436: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2436>
[14:05] <moritz_> Has nobody an idea about my dbus problem?
[14:14] <jdstrand> zyga: where did README.md from snap-confine go?
[14:14] <jdstrand> zyga: I don't see it in the wiki
[14:31] <mup> PR snapd#2437 opened: misc: fix crash when $v is not set (set -u) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2437>
[14:32] <renato__> jdstrand, hey, is this a valid policy? http://paste.ubuntu.com/23598590/
[14:33] <elopio> ping kgunn. When is a good time for you tomorrow, for the ubuntu testing day?
[14:36] <kgunn> 10:30? elopio
[14:37] <kgunn> elopio: atm i'm thinkingn to walk through the setup instructions, have another hangout stream showing the current state of unity8 snap
[14:37] <kgunn> on another machine
[14:38] <kgunn> maybe highlight some bugs/hurdles we have...then take questions
[14:38] <kgunn> does that sound reasonable
[14:40] <elopio> kgunn: that sounds perfect. Do you think it will take you around 30 minutes to go over all that? I need to see if I should talk less or more.
[14:40] <elopio> kgunn: 10:30, of which time zone?
[14:40] <kgunn> eh...i would think prolly 15-20 min to maybe get through that
[14:41] <kgunn> but...maybe i'm too optimistic on being quick :)
[14:41] <kgunn> elopio: i'm in US central timezone
[14:41] <kgunn> it's 8:40 am now
[14:41] <elopio> kgunn: ok, I'll set up the calendar. Thank you!
[14:44] <jdstrand> mvo, zyga: the quick fix I was thinking of won't work. I commented in the bug
[14:44] <jdstrand> renato__: no
[14:46] <jdstrand> renato__: 'name' is use in two places, with 'bind' and with 'send/receive' as part of peer=(name=...)
[14:46] <jdstrand> renato__: you can do: peer=(name=org.gnome.evolution.dataserver.Subprocess.Backend.Calendar*, label=###PLUG_SECURITY_TAGS###)
[14:46] <renato__> jdstrand, ok nice, thanks
[14:47] <renato__> jdstrand, we can say that in most of the cases *ConnectedSlotAppArmor and *ConnectedPlugAppArmor will be the same value?
[14:48] <jdstrand> renato__: no. send and receive are flipped, peer label is flipped and you won't specify name= on the plugs side since it is not a well-known name
[14:48] <jdstrand> renato__: I recommend you profile each side separately to understand how they interact
[15:05] <pmcgowan> renato__, can you reference bzr or git revno inside the snapcraft.yaml
[15:06] <nacc> pmcgowan: git certainly -- let me look it ups
[15:06] <mup> PR snapd#2437 closed: misc: fix crash when $v is not set (set -u) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2437>
[15:08] <renato__> pmcgowan, looks like you can only specify a tag: http://snapcraft.io/docs/reference/plugins/source
[15:09] <nacc> hrm, snapcraft on my system says there is also source-commit
[15:09] <nacc> renato__: pmcgowan --^
[15:10] <cjwatson> yeah, it's just not in the web docs for some reason
[15:10] <nacc> http://paste.ubuntu.com/23598751/
[15:11] <pitti> tvoss: do you have an opinion about whether we should release the systemd trusty SRU now, or wait longer?
[15:11] <pitti> it's otherwise ready by policy)
[15:11] <tvoss> pitti: I think we are good to releasing now, no point in waiting. if we encounter issues, we will have to SRU again anyway
[15:11] <pitti> true
[15:14] <mup> PR snapd#2438 opened: release: 2.18.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2438>
[15:18] <pmcgowan> renato__, nacc what I want to do is use @BZR_REVNO@ in the version
[15:18] <nacc> pmcgowan: how would that work? you mean your maintaining your snapcraft.yaml in a bzr repo?
[15:18] <renato__> pmcgowan, I do not think this is possible since cmake will run after
[15:18] <pmcgowan> nacc, no sorry I want to dymanically set the version string
[15:19] <pmcgowan> like we were doing for clicks
[15:19]  * nacc doesn't know anything about clicks :)
[15:19] <renato__> pmcgowan, to get this the cmake will need to run before the snapcraft command.
[15:19] <pmcgowan> ah
[15:20] <renato__> pmcgowan, or maybe you can pass arguments to snapcraft command. But I do not think this is supported
[15:21] <pmcgowan> renato__, seems a limitation to need to hard code the version
[15:28] <mhall119> zyga: what's the status of snapd on fedora? I haven't heard anything in a while
[15:28] <mup> PR snapd#2439 opened: vendor: update tomb package fixing context support <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2439>
[15:54] <kalikiana_> pmcgowan: You need to modify the yaml before running snapcraft atm
[15:55] <pmcgowan> kalikiana_, ack
[15:59] <mup> PR snapd#2439 closed: vendor: update tomb package fixing context support <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2439>
[16:00] <SamYaple> /win/win 22
[16:01] <t1mp> Trevinho: hello
[16:02] <t1mp> Trevinho: I merged your MR that removes the deprecated plugins from the ubuntu-app-platform snap
[16:02] <t1mp> Trevinho: now I'm looking at https://code.launchpad.net/~3v1n0/ubuntu-app-platform/+git/ubuntu-app-platform/+merge/311953
[16:03] <t1mp> Trevinho: would adding after: -indicator-qt have the same effect in the platform snap as when adding it to each app snap individually?
[16:09] <t1mp> I'm also wondering for the apps that use the app platform snap, why do we still need after: [desktop-ubuntu-app-platform]. Couldn't we simply include that in the ubuntu-app-platform snap?
[16:12] <t1mp> Trevinho: I added a comment on https://code.launchpad.net/~3v1n0/ubuntu-app-platform/+git/ubuntu-app-platform/+merge/311953
[16:13] <t1mp> maybe I am not understanding how it works yet
[16:13] <t1mp> kalikiana_: ^do you have an opinion/answer on my question on that MR?
[16:15] <kalikiana_> t1mp: The "after" seems odd. Is that part part of the platform snap yet?
[16:16] <t1mp> kalikiana_: no, there is no after: in the platform snap yet. It was proposed in the MR.
[16:16] <t1mp> so that made me wonder why to add it, and if we add the indicator-qt5 there then why not add desktop-ubuntu-app-platform
[16:17] <t1mp> I don't know if there is a good/bad approach here, or it is a matter of policy, or I just don't understand it yet ;)
[16:18] <kalikiana_> t1mp: Ah, stupid question, the after pulls it in because it's a remote part
[16:18] <kalikiana_> Indicators certainly make sense as part of the platform snap to me
[16:19] <t1mp> and what do you think about desktop-ubuntu-app-platform? Do I get it right that when I just add that to the ubuntu-app-platform, we don't need to pull it in for the app snaps any more?
[16:19] <kalikiana_> You can use them separately, but really, when you're using the platform snap you kind of expect the "usual suspects" to be in there
[16:20] <kalikiana_> t1mp: That's the launcher, right? Is there any use case that conflicts with that?
[16:20] <kalikiana_> At some point we had this pile of half a dozen different ones
[16:21] <t1mp> yes, it is the launcher.
[16:21] <t1mp> ah, I see now, https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml there are a bunch of launchers
[16:21] <t1mp> it pulls in the build packages for qt5.
[16:22] <t1mp> perhaps leaving those out can break building of some snaps
[16:23] <t1mp> maybe this is being used a some kind of replacement for the "build tarball" that we discussed a while ago
[16:24] <kalikiana_> What makes you think so? All I see is qtbase5-dev
[16:28] <mup> PR snapd#2434 closed: tests: cherry-pick spread test fixes for 2.18.1 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2434>
[16:35] <Trevinho> t1mp: yeah, it's the same of adding it to each app
[16:39] <t1mp> kalikiana_: oops. What I meant is maybe we can use a construction like this as a replacement for the build tarball.
[16:39] <t1mp> but then obviously we'd have to include a lot more than just qtbase5-dev
[16:48] <kalikiana_> t1mp: The tarball could just sit in a remote part, no? We just need to make sure the libs won't be automatically staged as well
[16:51] <t1mp> right
[17:22] <pmcgowan> popey, mhall119 do you have a snap store account for core app developers or some such
[17:27] <mup> PR snapd#2440 opened: release: 2.19 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2440>
[17:27] <popey> pmcgowan: depends what you want to upload, things are a bit all over the place
[17:28] <ogra_> you should do the same we are doing with the canonical account ...
[17:29] <ogra_> sharing maintenance with snaps is so much easier than with clicks
[17:30] <ogra_> (same -> set up a central core-apps account and then share the snap ownership with individuals as needed from that)
[17:30] <popey> yes
[18:07] <mup> PR snapd#2436 closed: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2436>
[18:08] <mup> PR snapcraft#949 closed: project: support building classic snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/949>
[18:14] <cholcombe> i've uploaded a new version of my snap that resolves an issue but it seems that the store is stuck waiting on my old version to pass or fail review
[18:14] <cholcombe> can anyone help with that?
[18:44] <mup> PR snapd#2441 opened: debian: add split ubuntu-core-launcher and snap-confine packages <Created by zyga> <https://github.com/snapcore/snapd/pull/2441>
[18:47] <mup> PR snapd#2426 closed: spread.yaml: run dmesg -c with sudo and log the id before running it <Created by plars> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2426>
[20:43] <mup> Bug #1648615 opened: Apps hit apparmor denial trying to connect to unity8's mir_socket <Canonical System Image:New> <Snappy:New for ted> <https://launchpad.net/bugs/1648615>
[21:05] <iliv> how do you guys handle applicaiton configuration files? as in, how should (can?) I install /etc/application.cfg that also has some settings that reference filesystem paths like log and pid file, etc. location under /var/log /var/run etc.
[22:46] <JaBaZ> Can anyone help me with problem installing webdm Ubuntu snappy core on Rpi 2?
[22:48] <JaBaZ> I got error Mount snap "webdm" (24) (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
[22:58] <JaBaZ> Anyone
[23:10] <kyrofa> JaBaZ, how are you installing it?
[23:10] <kyrofa> JaBaZ, as "webdm" was renamed to "snapweb" long ago
[23:11] <kyrofa> alex-abreu, do we intend to unpublish webdm?
[23:12] <kyrofa> JaBaZ, try `snap install snapweb` instead
[23:12] <JaBaZ> Okay, i tried it
[23:12] <JaBaZ> try it
[23:13] <JaBaZ> That installed succesfully
[23:14] <JaBaZ> Thanks!