[00:11] <linggao> zyga_, sorry, I just want to mention that we are using Ubuntu 16.04 on rpi2/rpi3.
[00:11] <linggao> then we installed snapd.
[00:16] <linggao> Hi ogra_, zyga_ told me that you are using on-board wifi on rpi3. Can you let me know what is your os  and kernel version?  I am using Ubuntu 16.04.
[02:02] <mup> PR snapcraft#1155 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1155>
[02:25] <Son_Goku> why the hell is a bot opening up PRs?!
[05:02] <f_fox> Anyone know why snapctl would hang during a hook/when run inside a snap? Nothing shows up on dmesg and it doesn't seem to matter what the context is.
[05:03] <f_fox> It happens during the configure hook of the core snap, for instance, but if I skip that task by editing state.json manually everything else seems to work fine.
[05:06] <f_fox> actually scratch that, I just tried it on a fresh image and it seems to work now
[05:16] <wxl> anyone have a clue where to file a bug against a particular snap?
[05:17] <wxl> in this case, speaking specifically of vlc
[05:23] <mup> Bug #1666386 opened: Snap apps do not work on Lubtuntu <Snappy:New> <https://launchpad.net/bugs/1666386>
[05:32] <wxl> yeah i'm fixing that
[06:20] <jjohansen> zyga: the kernels with the fixes are publishing, I'm not sure when these kernels will get rolled into all snaps
[07:37] <zyga> jjohansen: hey, thank you for noticing the question earlier, is that -62 or -63 that should have the fix?
[07:44] <zyga> f_fox: hey, known issues
[07:44] <zyga> f_fox: we disabled the configure hook while we untangle everything
[07:46] <f_fox> zyga: that explains it, thanks
[07:49] <zyga> f_fox: we experienced a sequence of bugs when we introduced the configure hook on the core
[07:49] <zyga> f_fox: a portion of devices did not update successfuly
[07:50] <zyga> f_fox: we're investigating and trying to understand and fix the issue but for now we disabled the configure hook to let devices update
[07:57] <jjohansen> zyga: good question so far only zesty has published, and the bug update is reporting as fixed in 4.10.0-8.10 but my tree is saying its in 4.10.0-9.11
[07:57] <jjohansen> I am going to have to pull down the kernel and test
[07:59] <zyga> jjohansen: what is 8.10 and 9.11?
[08:00] <jjohansen> zyga: zesty kernels, the only ones that have published yet, the new kernels are publishing but it will take a while for all the releases
[08:01] <jjohansen> I expect they will finish some time tonight, zesty obviously goes first as it doesn't have the regression and USN work that xenial and yakkety kernels have
[08:01] <zyga> jjohansen: I see, thanks
[08:01] <zyga> jjohansen: I'll run a check to see that the bug is fixed on zesty images
[08:06] <mup> PR snapd#2889 closed: errtracker: add support for error reporting via daisy.ubuntu.com <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2889>
[08:33] <zyga> ogra_: hey
[08:35] <zyga> ogra_: I was wondering about the joule board
[08:35] <zyga> ogra_: do you know who supports that at canonical?
[08:35] <zyga> ogra_: I would like to publish the gadget snap to github
[08:35] <zyga> ogra_: and to see if we can build
[08:36] <mup> PR snapd#2897 opened: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/2897>
[08:42] <mup> PR snapd#2897 closed: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2897>
[09:13] <mup> PR snapd#2898 opened: many: merge 2.22.5 back to master <Created by zyga> <https://github.com/snapcore/snapd/pull/2898>
[09:57] <ogra_> zyga, JohnAgosta can get you in contact with the right people
[10:01] <zyga> ogra_: thanks!
[10:01] <zyga> ogra_: how are you?
[10:02] <ogra_> okayish ...
[10:02] <ogra_> :)
[10:02] <ogra_> trying to keep up with 600 telegram messages atm :P
[10:02] <_prasen_> hi
[10:03] <_prasen_> why does snap install try to download the core snap
[10:03] <_prasen_> nub
[10:03] <_prasen_> pls hlp
[10:04] <ogra_> _prasen_, all snaps are executed in context of the core snap, that is how snaps get distro and release independent
[10:06] <_prasen_> using 16.04
[10:06] <_prasen_> doesnt it already have a snappy core?
[10:06] <ogra_> no
[10:07] <_prasen_> if i want to develop for ubuntu core without any h/w
[10:07] <_prasen_> i need to install core using kvm
[10:07] <_prasen_> ?
[10:08] <_prasen_> the core snap which gets installed isnt the Ubunbtu Core right?
[10:08] <_prasen_> I need to install Ubuntu Core on a pi.
[10:08] <_prasen_> so was trying to run ubuntu core inside kvm
[10:08] <_prasen_> but on the ubuntu host of 16.04
[10:09] <_prasen_> I am stuck at snap install trying to "get" due to corporate proxy
[10:11] <_prasen_> running on kvm till i get hands on the pi
[10:15] <ogra_> _prasen_, well, if you only want to develop snap packages you can do that directly on your desktop without kvm
[10:16] <_prasen_> yes
[10:16] <_prasen_> @oga
[10:16] <nothal> _prasen_: No such command!
[10:16] <_prasen_> oga : did not knew about the core snap usage
[10:17] <_prasen_> was thinking of ssh into the kvm running core and installing snaps developed at the host
[10:17] <_prasen_> nothal : which cmd
[10:20] <_prasen_> even my host is a vm :(((
[10:23] <mup> PR snapd#2899 opened: Kmod use spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2899>
[10:45] <zyga> _prasen_: hey
[10:45] <zyga> _prasen_: with the way snappy works you don't need any separate VM
[10:45] <zyga> _prasen_: just develop snaps locally
[10:45] <zyga> _prasen_: using snapcraft
[10:45] <zyga> _prasen_: and install them on your own system
[10:48] <ogra_> zyga, but what if the company proxy doesntz let you though :)
[10:48] <zyga> ogra_: I snapd can respect proxy settings for a while now
[10:48] <zyga> _prasen_: if that's the problem for you I can show you how to proxy your stuff
[10:49] <ogra_> zyga, depedns wehat the proxy blcks ;)
[10:49] <zyga> ogra_: true
[10:49] <_prasen_> my proxy is blocking
[10:50] <zyga> _prasen_: I think you need to work with your IT to open up the *.ubuntu.com part and the CDN that snappy uses to distribute snaps
[10:50] <ogra_> _prasen_, did you configure your machine properly for the proxy ?
[10:50] <_prasen_> search.apps.ubuntu
[10:50] <_prasen_> yes
[10:50] <_prasen_> i am on iy
[10:50] <_prasen_> it*
[10:50] <zyga> _prasen_: there are plenty of domains under *.ubuntu
[10:50] <zyga> _prasen_: or just cheat and tether your phone ;-)
[10:50] <zyga> (you can get fired for that though)
[10:50] <_prasen_> yes I did that once
[10:50] <_prasen_> ;D
[10:51] <_prasen_> tethered and ran
[10:51] <_prasen_> yes
[10:51] <_prasen_> would need to get permissions for tat
[10:51] <_prasen_> can i download the core snap from any diiferent location other than *.ubuntu
[10:51] <ogra_> well, ifg you have to ask for that you can as well just ask for proxy opening for your machine to the respective urls
[10:51] <_prasen_> launchpad doesnt have it
[10:52] <zyga> _prasen_: no, and you also need assertions
[10:52] <zyga> _prasen_: techically snapd talks to the store at *.ubuntu.com and then gets redirected to a CDN
[10:52] <zyga> _prasen_: so the core snap is really elsewhere
[10:53] <_prasen_> okay
[10:53] <_prasen_> the link really specifies a whole lot
[10:53] <zyga> _prasen_: but hey, they opened IRC for you
[10:53] <zyga> _prasen_: please do let us know, it is an intereting problem to solve
[10:53] <zyga> _prasen_: which URLs are needed to use snapd behind a corporate proxy
[10:54] <_prasen_> html which I dont understand
[10:54] <zyga> _prasen_: ?
[10:55] <_prasen_> okay
[10:55] <_prasen_> wait
[10:55] <_prasen_> I'll try to share the link here
[10:55] <_prasen_> yes it is interesting to solve
[10:56] <_prasen_> but the main work that  i have to do
[10:56] <_prasen_> i am stuck there
[10:56] <_prasen_> xP
[11:01] <_prasen_> Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: x509:
[11:02] <_prasen_> this is the error i get
[11:02] <_prasen_> mozzilla prompts me to add exception
[11:02] <_prasen_> to this
[11:03] <_prasen_> if i do
[11:03] <_prasen_> it shows 405 Method not allowed
[11:12] <mup> PR snapd#2862 closed: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2862>
[11:21] <_prasen_> ogra : should I able to see interfaces before the core snap is present on 16.04
[11:21] <_prasen_> ?
[11:21] <ogra_> i dont think so, no
[11:22] <_prasen_> knowing that helps a lot
[11:22] <_prasen_> ty
[11:22] <_prasen_> nowhere in the official doc
[11:23] <_prasen_> it is said that the first time eecution of snap install will get the core snap first
[11:23] <_prasen_> or the docker snap
[11:23] <_prasen_> tis weird
[11:26] <_prasen_> or any other online resource fails to mention that
[11:26] <ogra_> it shouldnt get rthe docker snap for sure, only the core snap
[11:27] <_prasen_> okay..
[11:27] <ogra_> (unless you did snap install docker indeed)
[11:27] <ogra_> (then it would try to get both)
[11:27] <_prasen_> oh some guy in the office said it would do both
[11:27] <_prasen_> he seems pretty unreliable though
[11:27] <_prasen_> ;p
[11:46] <didrocks> stgraber: hey! I don't find the images:ubuntu-core/16 image and getting an error: not found, was the image removed?
[11:51] <didrocks> stgraber: so, after listing images, I noted that I have 2 available (x86 and i386). I did lxc launch images:ubuntu-core/16/amd64, but getting a download error "Retrieving image: 100% (961.30MB/s)error: multipart: NextPart: EOF" (getting that constantly)
[12:38] <mup> PR snapcraft#1156 opened: python plugin: use stage headers if applicable <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1156>
[12:42] <ogra_> jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
[12:42] <ogra_> or am i wrong here
[12:44] <sergiusens> morphis: hey, mind doing a bit of verification for LP: #1665759 ?
[12:44] <mup> Bug #1665759: [SRU] New stable micro release 2.27.1 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Committed> <snapcraft (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1665759>
[12:45] <morphis> sergiusens: sure, is that already available on the launchpad builders?
[12:45] <morphis> or still in proposed?
[12:46] <sergiusens> morphis: in proposed
[12:46] <morphis> ok
[12:46] <sergiusens> morphis: you could try and enable proposed on launchpad builders and build if you wanted to
[12:46] <sergiusens> but you get all of it
[12:50] <morphis> yes
[13:24] <hangun> jdstrand: hi,  I have a namespaces issue which is similar to this one ( https://bugs.launchpad.net/snappy/+bug/1665590). With zyga suggestion, I upgraded snap to the latest version(2.22.3), but the issue still be there.
[13:24] <mup> Bug #1665590: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1665590>
[13:26] <hangun> jdstrand:   run "dmesg | grep DENIED"  http://pastebin.com/2xJZv3YF
[13:29] <mup> PR snapcraft#1153 closed: contribution guide: add commit message template <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1153>
[13:30] <hangun> jdstrand:  I try to disable apparmor option in linux kernel config and re-build it.  but still have the namespace issue. (http://pastebin.com/PvixSWNr)
[13:38] <jdstrand> hangun: you need to load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine. This is part of https://github.com/snapcore/snapd/pull/2810
[13:38] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[13:39] <jdstrand> hangun: do: sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine.
[13:39] <jdstrand> err
[13:39] <jdstrand> sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine
[13:39] <jdstrand> hangun: if that works for you, feel free to 'sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/
[13:41] <jdstrand> ogra_: hi! would you mind running your machinery for linux-generic-bbb?
[13:41] <ogra_> jdstrand, on it
[13:41] <jdstrand> ogra_: thanks! :)
[13:58] <ogra_> jdstrand, btw, did you see my ping about the ppp interface above ?
 jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
 or am i wrong here
[14:02] <jdstrand> ogra_: I hadn't yet. you are correct-- that is the intent of the rules
[14:02] <ogra_> k
[14:02] <jdstrand> (and that's what they say)
[14:03] <jdstrand> I think morphis wrote/uses this somewhere. if it isn't working right, should file a bug
[14:04] <liuxg> sergiusens, ping
[14:05] <zyga> jdstrand: hey, how are you
[14:06] <zyga> jdstrand: we have some fire-fighting to do this week but I'd like to re-focus on update-ns when that is done
[14:08] <ogra_> jdstrand, well, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/ppp.go#L34 we might perhaps wnat to also allow ttyS[0-9], after all it is likely that pppd uses serial modems
[14:10] <morphis> ogra_, jdstrand: yeah it is a bit mixed in our case between the network-manager, modem-manager and ppp interface
[14:11] <morphis> needs some cleanup at a future point
[14:11] <morphis> ogra_: what about her using modem-manager instead of ppp directly?
[14:11] <ogra_> morphis, yeah, looks like jenny murphy uses pppd directly from her management snap
[14:11] <ogra_> ask in the mail thread :)
[14:11] <ogra_> (or on rocket, where she is too)
[14:11] <ogra_> (in the snapcraft channel)
[14:11] <morphis> rocket .. too many communication channels .-)
[14:12] <ogra_> yes
[14:12] <ogra_> i'm slowly running out of workspaces :) everything plastered with chat tools
[14:12] <ogra_> telegram, rocket, irc email ...
[14:13] <jdstrand> mvo: hey, where is SNAP_REEXEC set? I see with 2.22.3 "cmd.go:59: DEBUG: re-exec disabled by user" but I don't see it in /etc/environment. I don't remember setting this. this is on xenial
[14:14] <mvo> jdstrand: what version do you get with "snap version"
[14:15] <morphis> ogra_: :-)
[14:15] <mvo> jdstrand: might be a red-herring
[14:15] <jdstrand> $ snap version
[14:15] <jdstrand> snap    2.22.5
[14:15] <jdstrand> snapd   2.22.5
[14:15] <jdstrand> series  16
[14:15] <jdstrand> ubuntu  16.04
[14:15] <mvo> jdstrand: that looks good, so the message is wrong. iirc we fixed this in master
[14:18] <sergiusens> morphis: well read /topic ;-)
[14:18] <jdstrand> mvo: ok, thanks
[14:19] <ogra_> sergiusens' favorite sentence in here recently :)
[14:19] <morphis> sergiusens: yeah :-)
[14:26] <zyga> jdstrand: actually, one tiny review: https://github.com/snapcore/snapd/pull/2881
[14:26] <mup> PR snapd#2881: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available <Created by zyga> <https://github.com/snapcore/snapd/pull/2881>
[14:34] <jdstrand> zyga: ack
[14:39] <bulldog> hi guys what package should i ship in my snap to allow my Qt app open external links in system's applications
[14:39] <bulldog> mhall119, hi
[14:40] <bulldog> ogra_, its been long , holla :)
[14:40] <bulldog> xdg-open ??
[14:41] <hangun> jdstrand:  there is only  a "bin" folder in /snap directory, no "core" folder.
[14:42] <bulldog> lol barry
[14:44] <hangun> jdstrand: how I load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine?
[14:51] <bulldog> help
[14:57] <jdstrand> hangun: it seems you don't have a core snap installed. can you do 'sudo snap install core' ?
[14:57] <jdstrand> hangun: this is on classic, right? (not all snaps?)
[15:02] <sergiusens> ogra_: I;ve never been so eager to tell people to read topic ;-)
[15:02] <ogra_> haha
[15:03] <hangun> jdstrand: what does the "classic" mean?
[15:05] <zyga> bulldog: hey,
[15:05] <zyga> bulldog: you should not need to do anything anymore
[15:05] <zyga> bulldog: but on the host you need to apt-get install snapd-xdg-open
[15:05] <zyga> bulldog: don't put xdg-open into your snap, it will be just useless there
[15:05] <jdstrand> hangun: you are running snappy on a traditional distribution, like Ubuntu, Debian, Arch, etc
[15:05] <zyga> jdstrand: I believe so
[15:05] <zyga> jdstrand: I was working with hangun earlier
[15:06] <zyga> jdstrand: this is xenial userspace + custom kernel + snapd
[15:06] <jdstrand> hangun: as opposed to 'Ubuntu Core', which is a minimal image that can work with only snaps
[15:06] <zyga> jdstrand: the kernel is based off 3.10 with apparmor enablement from some time ago
[15:06] <zyga> jdstrand: I had a look at the error hangun reported where snap confine cannot perform the bind mount capture from the child process
[15:06] <jdstrand> zyga: hangun gave me a paste: http://pastebin.com/2xJZv3YF
[15:06] <zyga> jdstrand: I'm not sure if apparmor changed in the last year that would only make the snap-confine profile work with the more current version of kernel code
[15:07] <zyga> jdstrand: right, that's what I saw
[15:07] <hangun> jdstrand:  I just upgraded snap version to 2.22.5.  I see there are some folders " bin , core, bubblegum96-gadget ,bubblegum96-kernel"
[15:07] <mardy_> jdstrand: hi! I just wanted to make sure you are aware of bug 1664155, to know if it makes sense to you :-)
[15:07] <mup> Bug #1664155: Interface hooks slots should know the name of the client snap <snapd:New> <https://launchpad.net/bugs/1664155>
[15:07] <jdstrand> zyga: I don't have any idea what's going wrong, but it seemed like perhaps the snap-confine profile on disk was wrong, which I thought was because https://github.com/snapcore/snapd/pull/2810 wasn't merged
[15:07] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[15:08] <jdstrand> zyga: but based on all this new info, it seems different
[15:08] <zyga> jdstrand: I think that snap-confine is used from the package (still)
[15:08] <zyga> jdstrand: also hangun rebuilt snapd (by hand) so I'm not sure what is on the system now
[15:09] <jdstrand> zyga: there is no rule in the profile for this: apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/core.mnt" pid=3902 comm="snap-confine" srcname="/proc" flags="rw, bind"
[15:09] <jdstrand> we have mount options=(rw rbind) /proc/ -> /tmp/snap.rootfs_*/proc/,
[15:09] <jdstrand> but that is rbind, not bind
[15:11] <jdstrand> hangun: to unblock yourself, add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine, then do 'sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine'
[15:11] <jdstrand> hangun: once you get farther along, feel free to file a bug that /etc/apparmor.d/usr.lib.snapd.snap-confine doesn't have everything you need, with all the info to reproduce
[15:13] <hangun> jdstrand:  and zyga:  just following jdstrand's instruction:  1)sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine 2) sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/   ( it doesn't work  read-only file system)
[15:14] <hangun> 3) snap install hello-world
[15:15] <jdstrand> hangun: well, forget the cp. you seem to be porting to a new device/kernel. this isn't my area of expertise, but if you edit /etc/apparmor.d/usr.lib.snapd.snap-confine directly in the way I suggested, you might get farther along
[15:17] <zyga> (dinner)
[15:18] <jdstrand> mardy_: I think oa needs to be a consideration in the design for trust in snappy, which is something that tvoss is spear-heading. that said, afaik, a) interface hooks don't yet exist and b) you are trying to add ACLs into OA outside of snapd
[15:18] <jdstrand> mardy_: it seems that in unity8 panel when you enable shotwell for the facebook account, that might perform a 'snap connect'
[15:18] <mardy_> jdstrand: interface hooks have landed :-)
[15:20] <mardy_> jdstrand: didn't we say that such interfaces should auto-connect, and the trusted prompt will take care of actually granting the permissions?
[15:20] <jdstrand> mardy_: I'm also not sure if that ACL should live in OA-- trust-store is moving it to snapd. if you moved it to snapd, then you could rearrange things
[15:20] <jdstrand> mardy_: well, if the trusted helper is doing the mediating, yes that's true
[15:21] <jdstrand> mardy_: that then gets to my bit about storing your acls in snapd. again, this is something that should be considered with the trust discussions
[15:21] <mardy_> jdstrand: I think that OA is quite a special case, it's not granting access to a system resource, but to some data which the user has entered into OA itself
[15:22] <EEight> jdstrand: hi, someone told me you are the right person for this question: my snap doesn't connect automagically to the camera interface. I need to run sudo snap connect myapp:camera for it to works.
[15:23] <jdstrand> mardy_: it may be different, but I'm not sure it needs to be treated specially
[15:23] <EEight> jdstrand: I cannot ask my users to run this command after installing the application, is there a way to make it works out-of-the-box?
[15:23] <jdstrand> EEight: what is your application?
[15:23] <EEight> jdstrand: bayam
[15:24] <EEight> jdstrand: an electron application using electron-builder to build the snap
[15:24] <zyga> jdstrand: while that is the case how does it work in ubuntu all the time?
[15:24] <mup> Bug #1666553 opened: snap try works, but executing the application doesn't work in some directories like /tmp <Snappy:New> <https://launchpad.net/bugs/1666553>
[15:24] <EEight> jdstrand: reported here: https://bugs.launchpad.net/snapcraft/+bug/1609577
[15:24] <mup> Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed <Snapcraft:New> <https://launchpad.net/bugs/1609577>
[15:26] <didrocks> zyga: you are quick :)
[15:26] <zyga> didrocks: haha, I just got lucky
[15:26] <jdstrand> EEight: the camera interface is considered privileged in that a malicious or misbehaving app could spy on the user when the interface is connected. this is why the user is given a say as to whether the interface should be connected
[15:26] <zyga> didrocks: I know about this bug, I was wondering what to do in that case
[15:27] <hangun> jdstrand: trouble you again.   How I add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine ?
[15:27] <jdstrand> EEight: it is technically possible to have the interface autoconnected on install using a snap declaration, but then the user doesn't necessarily know what is happening
[15:27] <didrocks> zyga: yeah, I wonder how hackish a temporary mount point accessible on both side would work
[15:27] <didrocks> zyga: that or at least failing in snap try with some reasoning
[15:27] <didrocks> as we have the list of directories that are shadowed inside the snap
[15:28] <jdstrand> EEight: aiui, there is work to make this more discoverable for users. what some people do is create a small wrapper such that tries to use the resource, notices it cannot, and then tells the user what to do: eg, "Camera not available. Please run: sudo snap connect myapp:camera'
[15:29] <jdstrand> EEight: I suggest bringing this up on the snapcraft@ mailing list and asking about the progress to make interface connections easier for end users
[15:29] <mardy_> jdstrand: regardless of where the ACL lives, do you agree that the snap providing the slot needs to be able to get the name of the client (plug) snap, in order to get its name and icon?
[15:29] <hangun> jdstrand: the /etc folder is read only fs
[15:30] <EEight> jdstrand: does it means that even the final "solution" for this will be to ask the users to run a command line?
[15:30] <jdstrand> EEight: I might also mention that gadget snaps are able to influence auto-connect. so if this snap is part of a device you are creating, you can control the auto-connect yourself
[15:31] <jdstrand> EEight: not necessarily. aiui, snap install will help guide the user
[15:31] <jdstrand> EEight: but I'm not designing that and not up to date on it. I suggest asking on the list
[15:32] <_prasen__> its says ubuntu 16.04 comes with a snappy core but during the first execution of snap install it firsts installs the snap core after downloading it
[15:32] <jdstrand> hangun: I'm a bit confused by your system setup. it sounds like a traditional distro, but /etc is read-only. did it not boot correctly and the boot put / as readonly?
[15:32] <_prasen__> core snap*
[15:32] <EEight> jdstrand: well the instruction on how to install my application on ubuntu is to use software center. don't know how it will help my users.
[15:32] <_prasen__> so that snaps get a reference to be built
[15:33] <jdstrand> hangun: you can cp /etc/apparmor.d/usr.lib.snapd.snap-confine somewhere else, then modify that file, then run apparmor_parser -r on it. that will not survive a reboot
[15:33] <_prasen__> or installed
[15:33] <_prasen__> so that they could be shipped across various distros and versions
[15:33] <_prasen__> *confused*
[15:33] <jdstrand> EEight: re software-center, aiui, that is supposed to tie into snap install
[15:33] <zyga> didrocks: I'll think of something
[15:33] <jdstrand> EEight: again, I'm not designing that so not up to date
[15:33] <_prasen__> *confused*
[15:33] <_prasen__> why isnt 16.04 shipped with the core snap
[15:34] <jdstrand> mardy_: I'm not sure I agree with that. if the design is what you laid out in the bug, probably, but if the design is you calling snap rest api to do things/whatever, maybe not
[15:35] <ogra_> _prasen__, because that would most likely be outdated
[15:35] <EEight> jdstrand: ok i understand (not up to date) but question so that i can ask a good one: if my users install via the command line or via the software center - either way they will need to run eventually sudo snap myapp:camera?
[15:35] <_prasen__> hi ogra
[15:35] <jdstrand> EEight: yes
[15:35] <EEight> damn
[15:35] <jdstrand> EEight: *today*
[15:35] <_prasen__> this is _prasen_ only
[15:35] <_prasen__> left myself logged in
[15:35] <jdstrand> EEight: but there is planned work to make that better. I just don't know the priority or the designs
[15:36] <ogra_> _prasen__, like you should not keep the original kernel on a fresh install but apply all security updates on a classic 16.04 installation when using it in production the same applies to the snappy system
[15:36] <hangun> jdstrand: I copy it into home directory which can be modified.  How I modified this file? I can't understand how to add "mount" to mount-namespace-capture-helper section
[15:37] <ogra_> so when invoking snap for the first time the core snap is pulled freshly from the store
[15:37] <ogra_> sincer that has all the latest fixes and security updates
[15:37] <_prasen__> okay
[15:37] <_prasen__> that clears it
[15:37] <_prasen__> ty
[15:38] <_prasen__> but what about users
[15:38] <ogra_> (and as i said, all yourr snaps are executed in context of the core snap, so you really dont want to have any security holes in that one as it could break the snap confinement of the apps)
[15:38] <_prasen__> who would want to develop locally?
[15:38] <_prasen__> without having any internet access
[15:38] <jdstrand> hangun: open the file in a text editor. put 'mount,' (don't forget the comma) anywhere within the '^mount-namespace-capture-helper (attach_disconnected) { ... }' stanza
[15:38] <ogra_> you would still have to pull the core snap once
[15:39] <_prasen__> though that would never practically happen
[15:39] <jdstrand> hangun: then use 'sudo apparmor_parser -r /path/to/file'
[15:40] <_prasen__> ogra : the classic confinement is related to this ?
[15:40] <ogra_> the classic confinement just means its a deb in a snap dress :)
[15:40] <_prasen__> that breaks the snap confinement tho, doesnt it
[15:40] <_prasen__> ?
[15:41] <ogra_> it behaves like a deb and has the same access to the system a deb has but you can use the advantage of snap packaging for it
[15:41] <ogra_> well, you declare it as "confinement: classic" in the snap metadata
[15:41] <_prasen__> yes
[15:41] <ogra_> so you told it to not use any of the actual confinement
[15:41] <_prasen__> yes
[15:42] <ogra_> it doesnt *break* it ... but you chose to not use it :)
[15:42] <_prasen__> even then it requires the context of snap core ?
[15:42] <_prasen__> ^ignore this then
[15:42] <ogra_> yes, it does
[15:42] <_prasen__> your last statement cleared that up
[15:42] <_prasen__> total nub at this.
[15:42] <ogra_> we all were once, no worries ;)
[15:43] <_prasen__> that gives me a boost
[15:43] <_prasen__> :D
[15:43] <ogra_> :)
[15:44] <ogra_> mvo, do we actually allow sideloading of the core snap for people without any internet access that just want to develop and test their own snaps locally ?
[15:45] <_prasen__> hey
[15:45] <_prasen__> how do we do that?
[15:45]  * ogra_ has never tried to sideload it before snapd initially installed it
[15:46] <ogra_> _prasen__, well, i dont know if your system would be set up properly afterwards, there is likely more store communication involved than just installing the core snap to have a proper setup ... which is why i pinged mvo
[15:47] <_prasen__> yes
[15:48] <ogra_> lets just wait til he finds time to answer and sees the ping :)
[15:49] <hangun> jdstrand:  following your guide, I added "mount" to snap-confine and then reload it.  snap install hello-world, then run hello-world, an error outputs: seccomp_load failed with -22 , abouting: invaild argument
[15:50] <_prasen__> it tries to "get" some more too
[15:50] <hangun> jdstrand: have to go to bed. it's midnight here
[15:51] <jdstrand> hangun: sounds like you maybe don't have seccomp enabled in your kernel or you have a too old libseccomp? again, this isn't really my area of expertise. You might want to send these questions to the devices@ mailing list (or use the porting guide (I don't have the url, perhaps someone here does?))
[15:51] <jdstrand> hangun: mailing list: https://lists.snapcraft.io/mailman/listinfo/devices
[15:52] <jdstrand> hangun: goodnight and good luck! :)
[15:52] <ogra_> hangun, jdstrand https://docs.ubuntu.com/core/en/guides/build-device/image-building
[15:53] <_prasen__> in the snapd.service file we have to set the path to the environment file
[15:53] <_prasen__> where we will set the env variables we want to export
[15:54] <jdstrand> ogra_: noted, thanks
[15:54] <_prasen__> ogra : any doc/resource where I can know more about it?
[15:54] <ogra_> _prasen__, you mean the environment (for a proxy) ? http://askubuntu.com/questions/764610/how-to-install-snap-packages-behind-web-proxy-on-ubuntu-16-04
[15:55] <_prasen__> talking precisely about tis link ;D
[15:56] <ogra_> _prasen__, note that this already points to "EnvironmentFile=/etc/environment"
[15:56] <ogra_> _prasen__, so whatever you add to /etc/environment will be used by snapd
[15:56] <_prasen__> where do I get to learn more about this?
[15:56] <_prasen__> currently i do this to set my https_proxy and http_proxy variables
[15:57] <ogra_> i guess the bug linked in the question above is the best you can get
[15:57] <_prasen__> okay
[15:57] <_prasen__> ty
[15:57] <_prasen__> ogra : savior man _/\_
[15:58] <ogra_> heh
[16:00] <mvo> ogra_: installing a core snap without internet should work if you ack the assertion for the core snap first and then install it
[16:00] <ogra_> how would he do that ack'ing ?
[16:00] <ogra_> is there anything interactive ?
[16:01]  * ogra_ would just have said --dangerous --devmode 
[16:01] <ogra_> though i guess that would still try to access the store and install core frome there first ...
[16:01] <ogra_> *from
[16:03] <_prasen__> i guess --dangerous option is invalid with --devmode
[16:04] <ogra_> well, i think you dont need --devmode if using --dangerous, iirc --dangerous automatically sets --devmode nowadays
[16:04] <ogra_> (i'm a bit behind using snaps locally, i tebnd to use everything from the store nowadays)
[16:05] <_prasen__> I think --devmode pnly has to used if confinement is devmode
[16:05] <_prasen__> only*
[16:05] <stgraber> didrocks: hmm, could be a problem with the mirrors or maybe some kind of proxy between you and the server
[16:05] <stgraber> didrocks: is it still failing now?
[16:05] <_prasen__> if confinement is changed to strict
[16:06] <stgraber> (I'm trying on my laptop and it seems happy with images:ubuntu-core/16, currently downloading the image)
[16:06] <_prasen__> then we need to use the dangerous flag if our locally created snap isnt verified by the store
[16:06] <didrocks> stgraber: let me try
[16:07] <didrocks> stgraber: yes: images:ubuntu-core/16 still fails with the fingerprint thingy and images:ubuntu-core/16/amd64 gives Retrieving image: 100% (614.64MB/s)error: multipart: NextPart: EOF
[16:09] <stgraber> didrocks: oh, I didn't read your error too closely, it could actually be a problem with the legacy protocol for the image server. We actually have a change coming in the next LXD release to force change that protocol for everyone.
[16:09] <stgraber> didrocks: lxc remote remove images ; lxc remote add images http://images.linuxcontainers.org --protocol simplestreams
[16:10] <didrocks> stgraber: error: flag needs an argument: --protocol
[16:10] <stgraber> oh, oops
[16:10] <didrocks> ah error: Only https URLs are supported for simplestreams
[16:10] <didrocks> hum
[16:11] <stgraber> didrocks: oh, oops, that was meant to be https://
[16:11] <stgraber> didrocks: lxc remote remove images ; lxc remote add images https://images.linuxcontainers.org --protocol simplestreams
[16:12] <mup> PR snapd#2822 closed: interfaces: add a linux framebuffer interface <Created by femdom> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2822>
[16:12] <didrocks> stgraber: perfect! images:ubuntu-core/16 is now downloadable, thanks! :)
[16:12] <didrocks> stgraber: do you need a bug report for handling the transition if not already?
[16:12] <stgraber> didrocks: nah, the commit was already merged yesterday
[16:13] <stgraber> didrocks: I'll look into why the old protocol doesn't work though, you indeed would have needed to use images:ubuntu-core/16/amd64 for that, but it should still have worked...
[16:13] <didrocks> stgraber: ah ok, that's weird. Good hunt! Thanks for the help on unblocking me
[16:33] <zyga> re
[16:34] <mup> PR snapd#2871 closed: overlord/hookstate/ctlcmd: helper function for creating a deep copy of interface attributes <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2871>
[16:45] <jdstrand> roadmr: hi! can you sync r840 whenever it is convenient?
[16:47] <roadmr> jdstrand: sure! hello :)
[16:51] <zyga> roadmr: hey, long time no see
[16:51] <roadmr> hello zyga  :) how's it going?
[16:51] <roadmr> you've been super busy :)
[16:51] <zyga> roadmr: me? no I just work on night shifts ;-)
[16:52] <roadmr> you vampire :)
[16:52] <zyga> roadmr: it's been good, preparig to move back to Polad this summer, otherwise all good
[16:52] <roadmr> zyga: temporary move or for good?
[16:52] <zyga> roadmr: I may be in Canada this spring
[16:52] <zyga> roadmr: the only permanent move is when I go to the cementary ;)
[16:52] <zyga> roadmr: not sure, for now we need to move
[16:53] <roadmr> zyga: hehe :) ok, hope the move goes well, and the trip to Canada too! spring is nice if you manage to arrive after all the ice melts heh
[16:54] <genii> Not much ice this year so far
[16:54] <zyga> roadmr: I'm not sure if I'll go, or where the sprint is going to be even
[16:54] <roadmr> zyga: well, it'll all become clearer in the coming weeks :)
[16:55] <roadmr> genii: true, I've seen worse. I expect a quick thaw this year
[16:57] <genii> roadmr: In fact, it's like 9C out right now here in Toronto, Wed-Thur up to 15C
[16:57] <roadmr> genii: really? wow, thanks to climate change Toronto is now a tropical city
[16:57] <genii> Heh, almost
[16:58] <roadmr> genii: we're *just* below zero in Montreal.
[17:00] <jdstrand> roadmr: thanks!
[17:12] <noise][> FYI, we are experiencing an outage of the snap download service, see http://status.snapcraft.io/ for status updates
[17:19] <EEight> jdstrand: I didn't want to involve the application name of the company in the mailing-list discussion...
[17:19] <jdstrand> davidcalle: ping re https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/> html is rc5 but pdf is rc6
[17:19] <EEight> I guess it is not possible to modify your post?
[17:20] <jdstrand> EEight: I'm sorry :( the name is an important part of the conversation so I referenced it
[17:20] <jdstrand> niemeyer: ^
[17:20] <jdstrand> niemeyer: is there anything we can do to the mailing list archive (I'm not an admin of the list)
[17:21] <niemeyer> Let me see
[17:22] <EEight> niemeyer: the actual post is: https://lists.ubuntu.com/archives/snapcraft/2017-February/003363.html
[17:23] <niemeyer> There's apparently no way.. I'll have to reach out to our internal support so they can edit the offending post manually
[17:24] <EEight> Is there a form to do that, because there is a risk that Google will show this post when people look for Bayam and security + children = bad
[17:26] <jdstrand> EEight: no form. niemeyer is reaching out now
[17:27] <EEight> niemeyer: thank you very much for this
[17:27] <EEight> jdstrand: I now understand why it's not connected (camera) out-of-the-box
[17:27] <jdstrand> I apologize again. I didn't think it was a problem since it was discussed here
[17:27] <niemeyer> EEight: Done, should be done in the next 24h
[17:27] <EEight> you guys rocks!
[17:28] <niemeyer> EEight: Sorry for the trouble
[17:28] <jdstrand> niemeyer: thanks for taking care of that
[17:28] <niemeyer> EEight: As a side note, you just associated the company name with security in the public logs of this channel
[17:28] <EEight> And lost my job
[17:29] <EEight> I have a plan B, making breads
[17:29] <EEight> No worries for me
[17:29] <niemeyer> :)
[17:29] <niemeyer> It's not a bad plan :)
[17:30] <EEight> Well I should begin to work on it...
[17:33] <EEight> And for the record (and public log) I was talking about the leaf: http://chiap-hup.com/bayam-bulat-0501/ ;)
[18:06] <zyga> Pharaoh_Atem: hey
[18:07] <zyga> Pharaoh_Atem: any chance you use a 16.10 machine to develop base snaps?
[18:53] <joedborg> hey all
[18:53] <joedborg> I'm getting `unusual mode 'rwxr-xr-x' for symlink` errors from ubuntu store when i push a snap build
[18:53] <joedborg> not sure what's unusual about that?
[18:55] <jdstrand> nessita: hey, several hours ago I rejected https://myapps.developer.ubuntu.com/dev/click-apps/6203/rev/6/, but r7 never underwent auto-review and is in 'Task state unknown'
[18:55] <nessita> jdstrand, checking
[18:59] <nessita> still checking
[19:01] <qengho> joedborg: sounds fishy. symlinks don't have their own modes, iirc.  $ find snap prime stage -type l -ls
[19:02] <joedborg> qengho: yeah, i've looked at them in the prime dir, because the full output lists each one
[19:03] <nessita> jdstrand, I rerun the review task, is Manual review pending
[19:03] <joedborg> qengho: and they all look legit, as expected all of the permissions are inherited
[19:03] <jdstrand> nessita: thanks!
[19:04] <nessita> jdstrand, thanks for reporting!
[19:04] <jdstrand> np :)
[19:05] <qengho> joedborg: If you have a URL someone can look at, at https://myapps.developer.ubuntu.com/ , then that might help someone who knows.
[19:06] <joedborg> qengho: https://myapps.developer.ubuntu.com/dev/click-apps/6896/rev/2/
[19:06] <joedborg> qengho: I've submitted for manual review - but I don't understand why symlinks are a build failure - perhaps it's a bug
[19:55] <Pharaoh_Atem> zyga: I don't have a 16.10 machine on hand, but I can set up one, why?
[19:56] <zyga> Pharaoh_Atem: no, just curious
[19:56] <zyga> (no need to set one up)
[20:05] <mup> PR snapcraft#1157 opened: repo: support versioned stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1157>
[20:50] <jdstrand> ogra_: hey, just noticed that pc-kernel is way out of date too in all channels
[20:51] <jdstrand> ogra_: and thank you for the bbb update!
[21:27] <cory_fu> elopio: Can you take a look at https://github.com/travis-ci/travis-ci/issues/7318#issuecomment-279860608 and tell me if that's feasible?  Could we fix the snap issue in travis using root inside whatever container they're using?
[21:28] <cory_fu> It seems to me like it would depend on the kernel of the host system?
[21:30] <devil> anyone has a hint for some documentaion on snap security measures?
[21:31] <jdstrand> devil: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
[21:31] <jdstrand> devil: but read the PDF instead of the html. the html is out of date for some reason
[21:31] <jdstrand> davidcalle: ping ^
[21:31] <devil> jdstrand: thanks. writing an article on security of flatpak and snap
[21:31] <davidcalle> jdstrand: looking
[21:32] <jdstrand> davidcalle: html says rc5 but pdf is rc6
[21:32] <jdstrand> davidcalle: google doc is also rc6
[21:33] <mup> Bug #1666690 opened: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
[21:33] <davidcalle> jdstrand: sorry I missed your pings earlier, I think we need to get rid of the HTML version and stick to the PDF, the CMS is not maintained anymore (we are moving out of it page by page) and I'm having issues with publications
[21:33] <davidcalle> jdstrand: how would you feel about only publishing the PDF?
[21:34] <jdstrand> davidcalle: that is fine with me since it means it is easier to be up to date, but, like before, I'm not the main consumer of this
[21:34] <jdstrand> davidcalle: iirc, people wanted the pdf, then they didn't, then now they do
[21:35] <davidcalle> jdstrand: PDF it is then, I'll fight some more with the page to replace the content by an introduction to the whitepaper, then the link. Tomorrow, though.
[21:38] <jdstrand> devil: in addition to that whitepaper (which has a slant towards Ubuntu Core as opposed to classic distributions), you might also want to look at https://github.com/snapcore/snapd/wiki/Interfaces, https://github.com/snapcore/snapd/wiki/Security and https://github.com/snapcore/snapd/wiki/snap-confine-Overview
[21:38] <jdstrand> devil: there is a lot of stuff in https://github.com/snapcore/snapd/wiki
[21:39] <devil> jdstrand: thanks again
[21:39] <jdstrand> np
[21:39] <jdstrand> davidcalle: thanks
[21:39] <devil> what I am particularly interested in is the sandboxing mechanisms
[21:40] <jdstrand> devil: the whitepaper gets into that and so do the specific wiki pages
[21:41] <devil> jdstrand: ok, that'll keep me busy for a while
[21:41] <jdstrand> but there is other info that is related or may give context in the other parts of the wiki
[21:43] <AlbertA> Hi snappy team :) so we've been playing around with content interface as a way to share libraries among snaps, however there are issues concerning dependencies.
[21:43] <AlbertA> we've outlined the problems in the bug: https://bugs.launchpad.net/snappy/+bug/1666690
[21:43] <mup> Bug #1666690: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
[21:43] <AlbertA> has there been any talk about potential solutions to those problems?
[21:59] <bdmurray> Is bug 1665756 fixed in snappy core?
[21:59] <mup> Bug #1665756: environment variable setting issue <Snappy:Fix Committed> <https://launchpad.net/bugs/1665756>
[22:00] <bdmurray> Or would it be fixed in snapcraft?
[22:01] <ogra_> bdmurray, likely snapcraft
[22:01] <ogra_> bdmurray, did you see my ping in #ubuntu-bugs from today btw ?
[22:02] <bdmurray> ogra_: How can I run the latest snapcraft? I did see your ping.
[22:03] <ogra_> not sure if the latest did already make it to proposed
[22:03] <ogra_> in any case you can clone the branch from github and just run ./snapcraft in there i think
[22:06] <ogra_> jdstrand, pc-kernel is kind of kernel team's thing to release, i pinged bjf before about them only releasing to beta, not sure how we can fix that (note that we cant release pi kernels at all to stable since we cant update /boot from the gadget snaps yet)
[22:06] <jdstrand> ogra_: ok, thanks
[22:07] <ogra_> jdstrand, (teh pi kernels depend on having the devicetrees in the gadget ... and also usually require new bootloader blobs for major version bumps of the kernel)
[22:07] <ogra_> i'm bumping the bbb kernel now though, thanks for the ping :)
[22:19]  * zyga EODs
[22:19] <zyga> good night everyone
[22:27] <mhall119> devil: ping
[22:27] <devil> mhall119: pong
[22:29] <mhall119> devil: hey, I just wanted to offer to answer any questions you had, or help with your article when it comes to the snaps part (I'm not as familiar with the flatpak side)
[22:30] <mhall119> I'm a community manager here at Canonical
[22:31] <devil> mhall119: thanks for the offer, I will come back to it if I have questions
[22:31] <mhall119> no problem, I look forward to reading it :)
[22:32] <devil> it's gonna be in German and international linux print mags in ~2-3 months. I can point you to it when it hits market
[22:36] <mhall119> ah, thanks. In that case I can answer any questions, but I won't be any help reviewing the german text :)
[22:37] <mhall119> we do have people who can, if you'd like a review before it goes to print
[22:37] <mhall119> but sadly, I myself am mono-lingual
[22:38] <devil> mhall119: I am pretty well informed, because I wrote on the topic before, as these projects are in rapid developement, I just want to get an as recent as possible look on the security models