[00:17] <mup> PR snapcraft#912 opened: Add a gradle demo and test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/912>
[00:20] <mup> PR snapcraft#652 closed: Demo/gradle <Created by ZenHarbinger> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/652>
[00:41] <mup> PR snapcraft#911 closed: Remove the outdated all snaps image set up for snaps tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/911>
[02:08] <mup> PR snapcraft#871 closed: Remove XXX comment from stage-packages <Created by nhandler> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/871>
[02:08] <mup> PR snapcraft#913 opened: help: update stage-packages and build-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/913>
[02:29] <mup> PR snapcraft#914 opened: meta: icon is now dedeprecated <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>
[02:38] <mup> PR snapcraft#761 opened: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761>
[03:11] <HOAI> hello everyone, I just installed Ubuntu Snappy in Raspberry Pi3, However, I cannot build any packet such as apache2, sql, can someone help me please ??, I'm new in snappy
[07:38] <zyga> good morning
[07:43] <dholbach> hey hey
[07:47] <foxmask> bonjello
[09:11] <mup> Bug #1620560 changed: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released by stolowski> <https://launchpad.net/bugs/1620560>
[09:56] <zyga> tvoss: I think I understand it now
[09:56] <zyga> tvoss: testing a simple fix
[09:58] <tsdgeos> is there a difference in what happens between
[09:58] <tsdgeos> sudo snap install --devmode --force-dangerous mysnap.snap
[09:58] <tsdgeos> and
[09:58] <tsdgeos> sudo snap try path/to/mysnap/prime --devmode
[09:58] <tsdgeos> ?
[09:59] <zyga> yes
[09:59] <zyga> tsdgeos: the difference is as follows:
[09:59] <zyga> tsdgeos: snap install copies the snap (across the connection) and installs it just as any other snap from the store (dangerous option means that some assertion are ignored)
[09:59] <zyga> tsdgeos: try on the other hand copies nothing and uses the directory indicated directly, ther'es a bind mount from that directory to /snap/$SNAP_NAME/$SNAP_REVISION
[10:00] <zyga> tsdgeos: you cannot remove that directory (rename it, break meta/snap.yaml) without some consequences
[10:00] <zyga> tsdgeos: the content is also live, you can change it and observe effects immediately
[10:00] <tsdgeos> because i'm seeing what i think is a runtime difference,
[10:00] <tsdgeos> do you think that's possible?
[10:00] <zyga> tsdgeos: at runtime, perhaps still, the directory might be writable
[10:00] <zyga> tsdgeos: I think we didn't fix that yet
[10:00] <zyga> tsdgeos: what do you observe?
[10:01] <Chipaca> matteo`: ping
[10:01] <matteo`> Chipaca: pong
[10:01] <tsdgeos> zyga: i think i'm seeing some dbus calls succeed in the install case and not in the try case
[10:01] <Chipaca> matteo`: what happened to docs/interfaces.md in your #2193 ?
[10:01] <zyga> tsdgeos: dbus is interesting, it is usually not affected by anything, can you show me the apparmor denial (journalctl | grep DENIED) please
[10:02] <zyga> Chipaca: isn't that moved to the wiki now?
[10:02] <Chipaca> ah!
[10:02] <Chipaca> :-)
[10:02] <Chipaca> zyga: and how is that kept in sync with the code?
[10:02] <zyga> ironically editing the wiki with git is nice :)
[10:02] <zyga> Chipaca: manually but the process is lighter
[10:02] <zyga> Chipaca: we should just poke people to edit it
[10:02] <Chipaca> zyga: so should there be a PR for the wiki for every PR that needs to update docs?
[10:03] <tsdgeos> zyga: the thing is there's no denials, but i see code going further in one case than in the other, i think i'm wasting your time, let me do some more debugging, sorry for the noise
[10:03] <Chipaca> tsdgeos: no denials but things not working usually means seccomp
[10:04] <Chipaca> tsdgeos: but I have no context other than what you said just there
[10:04] <zyga> tsdgeos: do you have an encrypted home directory, or home directory in some non standard location
[10:04] <matteo`> Chipaca: I found this? https://github.com/snapcore/snapd/blob/master/docs/MOVED.md
[10:04] <zyga> tsdgeos: I'm happy to help, bugs like this always show insight into what the real system is doing
[10:04] <Chipaca> matteo`: yep! sorry, i forgot about that move (see my conversation with zyga)
[10:05] <Chipaca> matteo`: but you're still on the hook for having the docs for this be in place once your branches land
[10:05] <zyga> matteo`: the up side is that you just hit the edit button and type away :)
[10:05] <zyga> matteo`: you can use git if you prefer
[10:06] <matteo`> zyga: I wanted to edit the wiki only after the PR merge
[10:06] <matteo`> otherwise I'll have documentation for a non existing feature
[10:06] <zyga> matteo`: that's fine, it's a wiki :D
[10:07] <zyga> matteo: just edit (you can say  "PENDING merge" or something)
[10:07] <matteo> ok
[10:07] <zyga> matteo: it'd be nice to indicate "since snapd 1.2.3" actually
[10:07] <zyga> matteo: so you can just use the future version there
[10:07] <matteo> ok
[10:08] <Chipaca> matteo: rawusb is going to land in a few more minutes, unless i386 hates you
[10:08] <zyga> Chipaca: raw usb interface?
[10:08] <Chipaca> usb-raw
[10:08] <matteo> yes, direct usb access, eg. for sane
[10:08] <zyga> Chipaca: woot, I could use that for my test farm to drive some tools I have
[10:09] <zyga> (now if only 14.04 wasn't so mysteriously failing on the upgrade test)
[10:09] <Chipaca> zyga: woot at matteo; i'm just pushing it
[10:09] <zyga> thank you matteo :)
[10:09] <matteo> btw I have an example snap that uses it
[10:09] <matteo> it contains lsusb
[10:09] <Chipaca> zyga: and it might get renamed; jdstrand did ask niemeyer about the name, but that was 21 days ago
[10:10] <Chipaca> in snapd time that's past the statute of limitations1
[10:10] <zyga> matteo: perfect, I was thinking about a libusb based flash tool for STM devices
[10:10] <zyga> Chipaca: that's like eternity ;0
[10:10] <matteo> https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/usb-utils/snapcraft.yaml
[10:10] <Chipaca> precisely
[10:10] <matteo> do you have an STM MCU? Like STM324F?
[10:11] <Chipaca> zyga: this thing about me being able to push branches at PRs to unbreak them is terrible
[10:11] <zyga> matteo: yes, a few actually
[10:11] <zyga> matteo: I briefly worked on the lm4tools that can flash them
[10:11] <matteo> nice, I have some too
[10:11] <zyga> Chipaca: terrible or terrific?
[10:11] <matteo> did you flash them with gdb and openocd?
[10:11] <zyga> matteo: no, just lm4tools, it was way easier and I think, at the time, the only supported way
[10:16] <matteo> Chipaca: I alphabetizet everything in all.go and all_test.go, but you put NewAvahiObserveInterface after NewCupsControlInterface
[10:16] <matteo> how much time the autopkgtest need to run?
[10:17] <Chipaca> matteo: I don't think I did that?
[10:17] <Chipaca> 	NewAlsaInterface(),
[10:17] <Chipaca>   	NewAvahiObserveInterface(),
[10:17] <Chipaca>  +	NewBluetoothControlInterface(),
[10:17] <Chipaca>  +	NewCameraInterface(),
[10:17] <Chipaca>  +	NewCupsControlInterface(),
[10:17] <Chipaca>   	NewDcdbasControlInterface(),
[10:18] <matteo> in all_test
[10:18] <matteo> https://github.com/snapcore/snapd/pull/2193/commits/1b9586330a2bbdf7e3534fe3d511a86fa8871da3
[10:18] <mup> PR snapd#2193: add usb-raw iterface <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2193>
[10:18] <Chipaca> matteo: gah
[10:18] <matteo> maybe you did indirectly, while merging
[10:18] <Chipaca> matteo: I noticed and fixed it in all.go, but missed it in all_tests.go
[10:19] <Chipaca> when merging, yes
[10:19] <Chipaca> matteo: I'll wait for all green, then fix this and wait for just spread green and land
[10:19] <Chipaca> matteo: unless you'd rather do it yourself
[10:20] <Chipaca> actually, this is strange
[10:20] <Chipaca> in all_tests locally i have it ordered
[10:20] <Chipaca> ah, no, wrong branch
[10:20]  * Chipaca is tracking too many right now
[10:22] <matteo> zyga: done the wiki
[10:22] <matteo> Chipaca: I'm for the "wait just for spread and merge" thing
[10:24] <Chipaca> zyga: you looked at 2249 before, could you +1 it if appropriate?
[10:25] <gerry_> Hi I am thinking of making a snap of a java program I have written where would it be available I read something about a snappy strore but I can not find a trace of that?
[10:28] <zyga> Chipaca: checking
[10:29] <Chipaca> gerry_: the snap store doesn't have a web interface accessible from a non-snap system
[10:29] <Chipaca> gerry_: (you could install snapweb)
[10:29] <Chipaca> gerry_: the snap store is what `snap find foo` talks to
[10:30] <Chipaca> mvo: https://travis-ci.org/snapcore/snapd/jobs/176656727
[10:30] <Chipaca> mvo: :-D
[10:30] <Chipaca> mvo: but also :-/
[10:33] <gerry_> ok so I am using ubunutu it has a new menu item called software as well as the ubuntu software center would it become available in that?
[10:34] <didrocks> gerry_: yeah, "sofware" (not ubuntu software center) displays snaps and deb packages
[10:35] <gerry_> ok thank you for your help one more question at the moment I have a jar with all dependencies (one library) contained in it would this be the best way to make a snappy package with the jar ?
[10:41] <didrocks> gerry_: I'm not particularly familiar with java based snap, but you sohuld give a look at the jdk snapcraft plugin IMHO
[10:41] <gerry_> ok thank you very much for your help
[10:43] <didrocks> yw! keep us posted :)
[10:47] <zyga> tvoss: found one more issue, fixed it, trying
[10:47] <zyga> tvoss: we didn't enable the mount unit
[10:48] <zyga> tvoss: I switched the snapd-mount.sevice to a real snap.mount unit
[10:48] <zyga> tvoss: fingers crossed, it also mkdirs the /snap directory for free ;)
[11:01] <zyga> tvoss: ha, I think I begin to have something
[11:01] <zyga> tvoss: Nov 17 11:59:20 autopkgtest mount[20017]: mount: according to mtab /var/lib/snapd/snaps/core_394.snap is already mounted on /snap/core/394 as loop
[11:01] <zyga> tvoss: that's a lie, mtab is garbage
[11:01] <zyga> tvoss: I'll patch the test setup to rm /etc/mtab and use a symlink to see if that changes
[11:10] <tvoss> zyga, +1, I'll another version of snapd into the ppa
[11:10] <tvoss> zyga: did you push your most recent changes?
[11:41] <zyga> tvoss: no, none of them improve the state yet
[11:42] <tvoss> zyga: ack, I'll push a new snapd package nevertheless
[11:56]  * zyga -> break
[11:57] <Odd_Bloke> ogra_: Could you give me an update on where we are with https://bugs.launchpad.net/snappy/+bug/1639878?
[11:57] <mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:New for ogra> <https://launchpad.net/bugs/1639878>
[11:59] <mup> PR snapcraft#891 closed: repo: apt-mark new build-packages as automatically installed <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/891>
[12:05] <zyga> tvoss: trying one more thing now
[12:05] <zyga> tvoss: I think systemd and /etc/mtab being a real file don't work
[12:05] <tvoss> zyga: uploaded to ppa, waiting for accept/reject message
[12:06] <tvoss> zyga: aha
[12:06] <zyga> tvoss: the rshared on / hides the issue somehow but not sure how
[12:06] <zyga> tvoss: the message I got was that systemd didn't do something it usually does (mount something) because it was apparently mounted (in the stale mtab file)
[12:06] <zyga> tvoss: it's all a bit shoot-in-the-dark though :/
[12:06] <tvoss> zyga: okay, let me find some help
[12:12] <zyga> tvoss: nope, didn't help - still digging
[12:12] <zyga> qemu:ubuntu-14.04-64 .../tests/upgrade/basic# systemctl status snap-core.mount
[12:12] <zyga>    Loaded: error (Reason: No such file or directory)
[12:19] <tvoss> zyga: I'm grabbing lunch, let's jump on a hangout with pitti right after that
[12:23] <zyga> tvoss: ok
[12:26] <zyga> tvoss: ah, silly me, the escaping causes my queries to systemd to give confusing messages
[12:28] <zyga> tvoss: let's talk here so that pitti can be in the loop
[12:28] <tvoss> v+1
[12:29] <zyga> tvoss: testing that new util-linux from ppa:pitti/systemd-semaphore
[12:29] <tvoss> ack
[12:32] <tvoss> okay, grabbing a quick bite
[12:34] <zyga> tvoss: no change
[12:47] <mvo> Chipaca: haha, thank you!
[12:49] <zyga> tvoss: thinking about what I'm seeing
[12:49] <zyga> tvoss: across restart we just lose all the .mount units
[12:49] <zyga> tvoss: is there anything that would keep them mounted?
[12:50] <tvoss> zyga: across restart?
[12:50] <tvoss> zyga: so that's snapd restart, correct?
[12:50] <zyga> tvoss: across snapd update
[12:50] <zyga> tvoss: that updates the package and runs some of the scripts
[12:50] <zyga> tvoss: (presumably the postrm / prerm ones
[12:50] <zyga> tvoss: I don't see anything starting mount units there
[12:51] <tvoss> zyga: so snapd.postrm purge removes everything
[12:51] <tvoss> hmmm, let me take a look at the actual test case
[12:51] <zyga> tvoss: I see a clear failure
[12:51] <zyga> the mount units are all stopped
[12:52] <zyga> hmm, but we don't purge, do we?
[12:52] <zyga> tvoss: is there an easy way to see the list of maintainer scripts / arguments across dpkg/apt transaction?
[12:53] <zyga> mvo: ^^ perhaps you know
[12:53] <tvoss> zyga: /var/lib/dpkg/info has got all the scripts of all currently installed versions
[12:54] <mvo> zyga: I'm not sure I understand the question? do you want to see how they are called and in what order?
[12:54] <zyga> mvo: yes
[12:54] <zyga> mvo: something like that
[12:55] <zyga> mvo: when a package update occurs, what gets called and with what arguments
[12:55] <zyga> mvo: I understand some of the old scripts are called, then some of the new scripts are called
[12:55] <zyga> mvo: but details elude me
[12:57] <mvo> zyga: https://wiki.debian.org/MaintainerScripts has a flow diagram
[12:57] <mvo> zyga: the interessting one is "upgrading"
[12:58] <zyga> thanks
[12:58] <zyga> tvoss: I pushed my local patches, have a look
[12:58] <zyga> tvoss: some of those should be removed later (HACK)
[12:58] <tvoss> looking
[12:58] <zyga> mvo: I see, it is quite "interesting"
[13:00] <zyga> tvoss: standup time for me
[13:00] <tvoss> zyga: ack
[13:01] <tvoss> zyga: probably makes sense if I join, too
[13:01] <tvoss> do you have a link handy?
[13:01] <zyga> tvoss: sent
[13:02] <tvoss> zyga: thx
[13:16] <zyga> pitti: http://pastebin.ubuntu.com/23490458/ <- is this indicating the thing is mounted or not?
[13:23] <jhodapp> Anybody on the snappy team seen this issue? Generally this resulted from me building my own snapd/snap and running that but now I want to use the system one installed via apt: http://pastebin.ubuntu.com/23490401/
[13:26] <sergiusens> jhodapp from what I read mvo mentioning; your db got migrated so you cannot go back
[13:27] <jhodapp> sergiusens, is there a way I can start over? I don't care what's installed
[13:27] <mvo> jhodapp: yeah, sorry for that, please use the version of snapd in xenial-proposed that should be fine and compatible
[13:27] <mvo> jhodapp: starting over is also possible with "apt purge snapd" but its not really needed
[13:27] <sergiusens> jhodapp you misunderstand, I only said mvo mentioned, not that I can help you further than that ;-)
[13:27] <jhodapp> mvo, I tried apt purge snapd but that didn't seem to do it
[13:28] <jhodapp> sergiusens, heh :)
[13:28] <mvo> jhodapp: oh? what is leftover? did it fail?
[13:28] <jhodapp> mvo, let me try it again and get you the output
[13:28] <mvo> thank you
[13:28] <mvo> jhodapp: fwiw, we use purge in our tests to clean stuff up, so it should work in general, but maybe you hit some corner case (or we have another bug)
[13:29] <zyga> tvoss: that didn't change anything (not touching snap.mount in prerm)
[13:29] <jhodapp> mvo, here's the whole session: http://pastebin.ubuntu.com/23490516/
[13:29] <zyga> interestingly
[13:29] <zyga> this is the journal for the core snap's mount unit
[13:29] <zyga> qemu:ubuntu-14.04-64 .../tests/upgrade/basic# journalctl -u snap-core-394.mount
[13:29] <zyga> -- Logs begin at Thu 2016-11-17 14:23:33 CET, end at Thu 2016-11-17 14:28:51 CET. --
[13:30] <zyga> Nov 17 14:28:35 autopkgtest mount[19811]: mount: warning: /snap/core/394 seems to be mounted read-only.
[13:30] <zyga> that's it!, it's not unmounted here
[13:30] <himanshub16> I tried creating a sample snap using the tutorial on snapcraft.io (gnu-hello). On installing the snap created, it tried to connect to network ?
[13:30] <zyga> ah, unmount doesn't generate any logs, bummer
[13:31] <tvoss> totally unrelated: I think I will snap up icq
[13:31] <zyga> is that still a thing? reminds me of windows 2000 and "I have a modem" days
[13:32] <zyga> tvoss: I patched the mount unit to be read only, inclined to add something to them to just see when it is being mounted/unmonted
[13:32] <zyga> unmounted*
[13:33] <zyga> pitti: anything I can add to a .mount unit to make it verbose?
[13:34] <tvoss> zyga: it's actually open-source, and available for linux
[13:35] <tvoss> zyga: distributed as a tar.xz containing a single executable
[13:35] <tvoss> zyga: code is here: https://github.com/mailru/icqdesktop
[13:35] <zyga> tvoss: wow, is that the same "flower-logo" icq from two decades ago?
[13:36] <tvoss> zyga: precisely that ;)
[13:36] <tvoss> zyga: come on, install it, I wanna check if there is still the "uh-oh" sound :)
[13:36] <zyga> lol :)
[13:36] <jhodapp> mvo, any thoughts?
[13:36] <zyga> let's fix stuff to run on 14.04 first
[13:36] <zyga> then we can use icq as a trophy
[13:37] <mvo> jhodapp: yes
[13:37] <mvo> jhodapp: but sorry, was distracted by a meeting
[13:37] <tvoss> zyga: sure
[13:37] <zyga> tvoss: I think I will follow niemeyer's advice and build a small test case to experiment and repdocude the behavior
[13:37] <jhodapp> mvo, np
[13:37] <mvo> jhodapp: could you please do a "ls -al ~/.snap" and pastebin that?
[13:37] <jhodapp> sure
[13:37] <zyga> tvoss: I still don't get what stops those units and why this happens on 14.04 but not on 16.04
[13:37] <tvoss> zyga: okay, I will instrument the maintainer scripts to be verbose and tell us what is actually called
[13:37] <zyga> tvoss: thanks
[13:38] <jhodapp> mvo, ls: cannot access '/home/jhodapp/.snap': No such file or directory
[13:38]  * mvo scratches head
[13:39] <jhodapp> lol
[13:40] <mvo> jhodapp: is there anything unusal about the system? coudl I get the output of "id ; env" please?
[13:40] <zyga> jhodapp: congratulations, welcome to the snappy team, you have just passed the secret test
[13:40] <zyga> ;)
[13:40] <pitti> zyga: no, inactive/dead says "not mounted"
[13:40] <mvo> jhodapp: welcome on board!
[13:40] <zyga> pitti: thanks!
[13:40] <jhodapp> zyga, hahaha
[13:40] <zyga> pitti: is there a way to see when systemd stops/starts mount units? (or just one for experiment)
[13:41] <pitti> zyga: verbose> a mount unit is just a wrapper around bin/mount, so you'll see its output in the journal; mount itself isn't very chatty, but you should certainly be able to see the effects of it?
[13:41] <mvo> jhodapp: the code tries to do a lookup of the current user but for some reason this fails here and I wonder how that could happen
[13:41] <zyga> pitti: I'm looking for "this is where that unit was stopped and something got unmounted"
[13:41] <pitti> zyga: sure, it's all in the journal; journalctl -f is useful
[13:41] <pitti> Starting Mount unit for core
[13:41] <pitti> Stopping Mount unit for core
[13:41] <jhodapp> mvo, http://pastebin.ubuntu.com/23490552/
[13:41] <jdstrand> Chipaca: I see you talking about docs and git, etc. where is that branch? I need to add some stuff
[13:42] <zyga> pitti: hmm, is the 14.04 systemd doing that, I cannot see it
[13:43] <jdstrand> doesn't seem to be in https://github.com/snapcore
[13:43] <zyga> jdstrand: snapd wiki is a git repo, it's a github thing
[13:43] <jdstrand> oh I see the link now
[13:43]  * zyga tries and gets a quick coffee 
[13:44] <jdstrand> funny, I just edited the wiki manually the other day
[13:45] <jdstrand> Chipaca: nm
[13:46]  * tvoss has test running with verbose maintainer scripts
[13:46] <Chipaca> jdstrand: sorry, was in a hangout
[13:46] <Chipaca> jdstrand: and then fixing a bug wrt resource consumption
[13:47] <Chipaca> (IOW getting lunch)
[13:47] <zyga> tvoss: first one that cracks this and fixes it gets a beer :)
[13:47] <jdstrand> no worries at all :)
[13:47] <tvoss> zyga: ;)
[13:49] <mvo> jhodapp: I traced through the source and it looks like you get an EPERM in getpwuid_r() which is super strange. anything unusal about this system you are using? inside some container or anything else that might give a clue?
[13:49] <mvo> jhodapp: an strace -f -s1024 snap list would be nice as well, but I suspect the sudo you need for this will alter the behavior
[13:49] <jhodapp> mvo, nope, it's just my laptop running 16.04
[13:50] <jhodapp> mvo, that requires sudo?
[13:51] <Chipaca> jhodapp: no
[13:51] <mvo> jhodapp: no, sorry
[13:51] <mvo> (too much stuff going on at the same time)
[13:51] <jhodapp> mvo, http://pastebin.ubuntu.com/23490606/
[13:51] <jhodapp> mvo, no prob
[13:52] <mvo> jhodapp: aha, there you go: "[pid  4186] open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)", what is "ls -al /etc/passwd"?
[13:52] <mvo> jhodapp: on your system?
[13:53] <jhodapp> mvo, -rw-r--r-- 1 root root 2954 Jul  7 09:17 /etc/passwd
[13:53] <zyga> jdstrand: any chance your are over ssh
[13:53] <zyga> er
[13:53] <zyga> jhodapp: ^
[13:53] <zyga> jhodapp: and ssh is confining all the sessions with apparmor like jdstrand does
[13:53] <mvo> jhodapp: hmm, that looks fine, do you see something in "dmesg|grep DENIED"
[13:54] <jhodapp> zyga, nope, I'm at the keyboard...no ssh
[13:54] <mvo> jhodapp: its interessting, if I set it to 600 I get exactly the same error as you get
[13:54] <zyga> jhodapp: any evil maids with hypervisor malware in sight?
[13:55] <jhodapp> mvo, journalctl -f output for snap list: http://pastebin.ubuntu.com/23490617/
[13:55] <zyga> pitti: since I don't get any of the stopping/starting messages on 14.04 does that mean I just don't have some journal glue to see this?
[13:55] <jhodapp> zyga, lol, I have kvm and virtualbox installed on this system, but neither are running
[13:55] <mvo> jhodapp: so we know now why it happens :) "Nov 17 08:54:51 smith audit[4327]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/snap" name="/etc/passwd" pid=4327 comm="snap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0"
[13:56] <zyga> jhodapp: waaat
[13:56] <zyga> profile="/usr/bin/snap"
[13:56] <zyga> that's not something we confine
[13:56] <mvo> zyga: exactly
[13:56] <zyga> jhodapp: can you look at /etc/apparmor.d/ and grep for /usr/bin/snap
[13:56] <zyga> jdstrand: ^ ?
[13:56] <jhodapp> yeah, one sec
[13:57] <mvo> jhodapp: sudo grep -r /usr/bin/snap /etc/apparmor.d
[13:57] <zyga> you have that evil maid somewhere
[13:57] <zyga> securing your snaps
[13:57] <jhodapp> I feel so protected
[13:57] <mvo> or the opposite, someone trying to make the system more secure :)
[13:57] <jhodapp> lol
[13:57] <jhodapp> mvo, http://pastebin.ubuntu.com/23490626/
[13:58] <zyga> jdstrand: dpkg -S /etc/apparmor.d/cache/usr.bin.snap
[13:58] <zyga> er
[13:58] <zyga> sorry jdstrand, I hate irssi's tab completion
[13:58] <zyga> jhodapp: dpkg -S /etc/apparmor.d/cache/usr.bin.snap
[13:59] <zyga> maybe a missing conflicts with some other package
[13:59] <mvo> jhodapp, zyga: probably without the /cache/ ?
[13:59] <zyga> or missing maintainer script that removes that file when the package is removed
[13:59] <jhodapp> zyga, dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.bin.snap
[13:59] <zyga> oh, I totally didn't see the cache part
[13:59] <zyga> hmmm
[13:59] <zyga> yep
[14:00] <zyga> jhodapp: which release are you on?
[14:00] <zyga> http://packages.ubuntu.com/search?searchon=contents&keywords=usr.bin.snap&mode=exactfilename&suite=yakkety&arch=any <- no hits
[14:00] <zyga> jhodapp: can you please pastebin that file
[14:00] <mvo> jhodapp: dpkg -S /etc/apparmor.d/usr.bin.snap please
[14:01] <mvo> zyga: I can't find anything in apt-file on xenial or yakkety
[14:01] <zyga> same here
[14:01] <zyga> curious
[14:01] <jhodapp> mvo, dpkg-query: no path found matching pattern /etc/apparmor.d/usr.bin.snap
[14:01] <mvo> :(
[14:01] <jhodapp> zyga, pastebin which file?
[14:01] <mvo> jhodapp: could you please pastebin /etc/apparmor.d/usr.bin.snap ?
[14:01] <zyga> yep
[14:02] <mvo> jhodapp: this is a really interessting issue you found!
[14:02] <jdstrand> since when is /usr/bin/snap confined?
[14:02] <jhodapp> lol, I didn't do anything fancy
[14:02] <zyga> jdstrand: it's not, something else is at play here and assumes the same name, perhaps one of the packages that conflict with snapd
[14:02] <mvo> jdstrand: this is what we are trying to figure out :)
[14:03] <jhodapp> mvo, http://pastebin.ubuntu.com/23490647/
[14:03] <zyga> # Last Modified: Mon Oct 24 13:21:22 2016
[14:03] <mvo> jdstrand, zyga -^
[14:03] <zyga> what did you do on oct 24?
[14:03] <mvo> super strange
[14:03] <mvo> also the content is… very bare
[14:03] <zyga> did you write that file? who's the owner
[14:04] <mvo> I guess its root:root ;)
[14:04] <jdstrand> /etc/apparmor.d/cache/usr.bin.snap isn't going to be shipped by anything
[14:04] <jdstrand> /etc/apparmor.d/usr.bin.snap would be the thing that was shipped
[14:04] <zyga> jdstrand: apt-file knows about neither
[14:04] <jhodapp> mvo, -rw------- 1 root root 141 Oct 24 13:22 /etc/apparmor.d/usr.bin.snap
[14:04] <zyga> so weird
[14:05] <zyga> 600 is not typical
[14:05] <mvo> jhodapp: do you have anything in /var/log/apt/history.log* around that time?
[14:05] <jdstrand> what are the contents of /etc/apparmor.d/usr.bin.snap?
[14:05] <mvo> jhodapp: anything that got installed on that date/around this time?
[14:05] <zyga> jhodapp: anyway, fire your maid, remove that file, unload the profile with apparmor_parser -R usr.bin.snap # AFAIR
[14:05] <mvo> jdstrand: http://pastebin.ubuntu.com/23490647/
[14:05]  * jhodapp checks
[14:05] <jdstrand> that looks like a test profile
[14:06] <jdstrand> not as in something we ship, but as in, what one might start with to see what it needed
[14:07] <zyga> pitti: any advice on journal / systemd on 14.04
[14:08] <jhodapp> mvo, I installed apparmor-utils
[14:08] <mvo> jdstrand: could apparmor-utils have created profiles somehow? is there a command to auto-generate such profiles?
[14:09] <jhodapp> mvo, also dh-apparmor got pulled in from that
[14:09] <jdstrand> mvo: no, it wouldn't have done any magic like that
[14:09] <jdstrand> it too
[14:10] <jdstrand> did you run aa-genprof?
[14:10] <zyga> tvoss: I don't see any starting/stopping messages in syslog/journal on 14.04
[14:10] <jhodapp> jdstrand, nope
[14:10] <zyga> tvoss: do you know how I can get that wired so that we have diagnostics?
[14:11] <jdstrand> jhodapp: apt-cache policy apparmor-utils
[14:12] <jhodapp> jdstrand, http://pastebin.ubuntu.com/23490677/
[14:14] <pitti> zyga: indeed, seems the start/stop of mount units isn't logged by that backport; but you can see it in e. g. forkstat
[14:14] <pitti> $ cat /etc/systemd/system/opt2.mount
[14:14] <pitti> [Mount]
[14:14] <pitti> What=/opt
[14:14] <pitti> Where=/opt2
[14:14] <pitti> Options=bind
[14:14] <pitti> sudo systemctl start opt2.mount
[14:14] <pitti> 15:14:16 exit  1130      0    0.009 /bin/mount /opt /opt2 -t auto -o bind
[14:14] <zyga> forkstat
[14:15] <pitti> gosh, this whole thing is *such* a bloody hack
[14:15] <zyga> what is that?
[14:15] <pitti> zyga: global monitoring of forks/execs that happen
[14:15] <pitti> great to track down "why is my system going mad" or finding what certain actions (like hotkeys etc.) do
[14:16] <zyga> pitti: wow :)
[14:16] <zyga> thanks, that's a gem and a keeper
[14:16]  * pitti hands cking a ♥ for this nice tool
[14:16] <jhodapp> jdstrand, thoughts on that?
[14:16] <pitti> zyga: of course the second-best debugging tool is always to just attach strace to systemd :)
[14:16] <cking> thanks pitti :-)
[14:16] <zyga> netlink
[14:16] <zyga> the source of magic and wonder on linux
[14:17]  * zyga has to learn more about netlink
[14:17] <pitti> it's like magic
[14:17] <zyga> pitti: any quick advice on how to embed forkstat into a test to see what is going on
[14:17] <pitti> it's everywhere, but nobody really understands it
[14:17] <zyga> pitti: I can install it early on but I don't know what to run to see activity in a window
[14:17] <pitti> zyga: run forkstat first, then your test?
[14:17] <pitti> but it really depends what you are actaully looking for
[14:17] <zyga> pitti: can I run forkstat in the background or something like t
[14:17] <zyga> and have it dump stuff to a log
[14:18] <zyga> pitti: I want to see all mount / unmount calls first
[14:18] <pitti> it shouldn't be that hard to see whether some mount worked or failed, as at any point in time you can see /proc/self/mounts in your namespace
[14:18] <zyga> pitti: my problem is that something stops a .mount unit
[14:18] <jdstrand> jhodapp (cc mvo and zyga): I just installed apparmor-utils (and dh-apparmor, which wasn't pulled in with apparmor-utils) and it did not create /etc/apparmor.d/usr.bin.snap
[14:18] <zyga> pitti: and I'm not sure what, I want to corelate that to other logs
[14:19] <mvo> forkstat goes crazy when you run go ;)
[14:19] <zyga> jdstrand: I bet it 's the maid, all reasonable explanations are now exhausted
[14:19] <mvo> but its a wonderful tool
[14:19] <zyga> doh :/
[14:19] <pitti> zyga: so to answer "what is calling umount", forkstat is actaully an excellent tool, as that tells you
[14:19]  * mvo hugs cking
[14:20] <jdstrand> jhodapp (cc mvo and zyga): if I run 'sudo aa-genprof /usr/bin/snap' and immediately press 'f' (finish), it generates a file exactly like the one on your system, with 600 perms
[14:20] <cking> :-)
[14:20] <jhodapp> jdstrand, mvo, zyga: here's my entire history.log for that day: http://pastebin.ubuntu.com/23490708/
[14:20] <pitti> zyga: I thought your woes were related to trusty still having an /etc/mtab?
[14:20] <pitti> zyga: systemd uses libmount's monitor, and I think in trusty that still parses /etc/mtab
[14:20] <pitti> (which of course is utterly and hopelessly broken for anything that snappy or systemd want to do)
[14:20] <jhodapp> jdstrand, oh I was running aa-genprof!
[14:20] <zyga> pitti: not sure what the woes are, I symlnked mtab to proc mounts but I'm still seeing something unexpected (not happening on 16.04)
[14:20] <jdstrand> bingo
[14:20] <jhodapp> jdstrand, I was trying to create a profile for media-hub
[14:20] <zyga> jdstrand: nice!
[14:21] <jdstrand> jhodapp: please do: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.snap ; sudo rm -f /etc/apparmor.d/sur.bin.snap /etc/apparmor.d/cache/usr.bin.snap
[14:21] <jdstrand> jhodapp: that will set you straight
[14:21] <mvo> jhodapp: excellent! I'm happy we found the root cause and even more happy that its not a general problem. thank you
[14:21] <jhodapp> jdstrand, better! :)
[14:22] <jhodapp> jdstrand, mvo, zyga thank you much!
[14:22] <jdstrand> jhodapp: you probably noticed the typo in my rm -f command
[14:22] <jhodapp> jdstrand, so...we might want to caution people from using that tool when trying to do a interface
[14:22] <jhodapp> jdstrand, yes
[14:23] <jdstrand> jhodapp: well... a) we don't say to use it and b) you used it on the wrong command
[14:23] <jhodapp> jdstrand, what do you mean on the wrong command?
[14:23] <jdstrand> sudo aa-genprog /usr/bin/snap
[14:23] <jdstrand> meh
[14:23] <jhodapp> jdstrand, I was following some examples from the apparmor wiki
[14:23] <jdstrand> sudo aa-genprof /usr/bin/snap
[14:24] <jdstrand> yes, but you told genprof to profile 'snap', not media-hub
[14:24] <jhodapp> jdstrand, hmm I don't see why I would have run that...must have been a fluke
[14:24] <jdstrand> that's what I'm getting at
[14:24] <jhodapp> jdstrand, would it install it into that spot under /etc/apparmor.d/ though?
[14:24] <jdstrand> yes
[14:24] <pitti> zyga: ah, that should help then
[14:24] <jhodapp> that's weird...why wouldn't it just generate a profile and put it in '.' ?
[14:25] <jdstrand> genprof is an apparmor tool, not a snappy one so it knows about /etc/apparmor.d, not /var/lib/snapd/apparmor/profiles
[14:25] <jdstrand> jhodapp: because of how it works-- it creates a profile and loads it into the kernel so then you can use other tools on it, like logprof
[14:26] <jdstrand> granted, the tooling isn't as nice as it could be-- but it is like a decade old
[14:26] <jhodapp> jdstrand, yeah...I discovered that tool doesn't even work well with snappy
[14:26] <jhodapp> err, snaps
[14:26] <jdstrand> no, it wouldn't
[14:26] <jdstrand> (it wasn't written or updated for snappy)
[14:26] <jhodapp> apparmor tools need some doc love
[14:27] <jdstrand> jhodapp: you mean for snappy?
[14:27] <jhodapp> jdstrand, yeah
[14:27] <jhodapp> centered around creating an interface from scratch
[14:27] <jhodapp> geared towards someone not experienced with apparmor
[14:27] <jdstrand> so that would be snappy documentation, not apparmor documentation
[14:28] <jdstrand> but yes
[14:28] <jhodapp> right :)
[14:28] <jhodapp> I'm just saying in geneneral
[14:28] <jhodapp> *general
[14:28] <zyga> pitti: after snapd I want to work on kernel and plumbing :)
[14:28]  * jdstrand nods
[14:28] <zyga> pitti: forkstat is awesome
[14:29] <jdstrand> normal snap developers shouldn't be fiddling with the guts of the sandboxing mechanism (apparmor, seccomp, etc). interface writers will need that of course
[14:30] <jhodapp> jdstrand, yes indeed, but even though it's slightly more niche, there are a number of people who will write interfaces who have little to no apparmor experience
[14:30] <jhodapp> like myself...and it's a frustrating experience
[14:31] <jhodapp> jdstrand, so I definitely get where you're coming from, just stating my experience
[14:31] <jdstrand> jhodapp: in the meantime, if you have questions, just ask. also, the interface writer can go very general and then we fine tune in the PR review
[14:31] <jhodapp> jdstrand, we had talked about this before as well
[14:31] <jhodapp> jdstrand, that's a very good point!
[14:31] <jhodapp> jdstrand, appreciate your thorough reviews
[14:32] <jdstrand> I can add something to https://github.com/snapcore/snapd/wiki/Security in the debugging section
[14:32] <jdstrand> that will point in the right direction
[14:32] <jhodapp> jdstrand, that'd be fantastic!
[14:49] <tedg> jdstrand: So the store blocks uploads with interfaces that it doesn't know about.
[14:49] <tedg> jdstrand: Would it be possible to disable that check for snaps that are in devmode?
[15:06] <zyga> tedg: http://paste.ubuntu.com/23490892/
[15:07] <zyga> tvoss: ^
[15:07] <zyga> or http://paste.ubuntu.com/23490903/
[15:07] <zyga> for the full log
[15:08] <zyga> tvoss: interesting observation, umount is only called twice
[15:08] <zyga> tvoss: and not on any of the snaps :/
[15:08] <zyga> tvoss: only on /snap itself (mount -l) aka detach
[15:08] <tvoss> zyga yup
[15:08] <zyga> tvoss: this might explain what we're seeing
[15:08] <zyga> tvoss: _might_
[15:08] <zyga> not sure it does
[15:09] <zyga> tvoss: ah, I now see both the snapd-mount.service and snap.mount
[15:09] <tvoss> zyga: okay, so I did the following experiment: in a debug shell for upgrade/basic, purge snapd, install the local deb with dpkg -i, then snap install hello-world, verify that snap works, dpkg -i local deb again
[15:10] <tvoss> zyga: for that experiment, if I remove systemctl stop/disable snapd.mount from snapd.prerm, the snap remains mounted
[15:11]  * zyga wonders what mandb is doing
[15:12] <tvoss> zyga: however, the rbind/rshared setup is altered, let me pastebin error msg
[15:12] <didrocks> kgunn: hey! I have a small question on https://developer.ubuntu.com/en/snappy/guides/mir-snaps/. Do we have any Mir snap example that we could use to showcase Mir on the rpi2?
[15:12] <tvoss> zyga: http://pastebin.ubuntu.com/23490920/
[15:13] <zyga> tvoss: that looks like the core snap is empty
[15:13] <zyga> tvoss: look at /snap/core/current, there's no /dev there, right?
[15:14] <tvoss> zyga: nope
[15:15] <zyga> tvoss: so that's snap-confine giving up, earlier it was snap-run
[15:15] <zyga> tvoss: I think the difference is that snap-confine sees the real NS and sets a new NS
[15:16] <zyga> tvoss: while snap-run (either run (before) or exec (after) ) sees the vanilla / confined namespace respectively
[15:16] <zyga> tvoss: and because we only set up ns once, after that we just join it
[15:16] <zyga> tvoss: you may see different error
[15:16] <zyga> tvoss: thsi error says the core snap is not mounted in the outer namespace for sure
[15:16] <tvoss> okay
[15:26] <didrocks> jdstrand: zyga: do we have any known workaround for snaps using alsa in core 16?
[15:26] <didrocks> As I'm getting:
[15:26] <didrocks> ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
[15:26] <didrocks> ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
[15:27] <didrocks> people used to patch it directly on the image in 15.04, but I'm unsure how we can tackle this in 16
[15:27] <didrocks> this leads of course to:
[15:27] <zyga> didrocks: patch alsa to be snap-aware?
[15:27] <didrocks> Can't open pcm device 'default'.
[15:27] <didrocks> Couldn't open ALSA pcm device (`s')
[15:27] <didrocks> zyga: not an option, deadline is next week
[15:27] <matteo> niemeyer: refactored
[15:27] <zyga> didrocks: I don't know of any other workaround
[15:28] <zyga> didrocks: maybe bind mount /usr/share/alsa to something in your snap as a test
[15:28] <zyga> didrocks: but that's not sustainable
[15:28] <tvoss> zyga: I fail to see where snap-specific mount units get unmounted in the upgrade case
[15:28] <zyga> tvoss: it gets detached
[15:29] <zyga> tvoss: with all of /snap
[15:29] <didrocks> zyga: yeah, I was thinking about doing something like that, but it means I need to have a wrapper to do this bindmount in devmode thus
[15:29] <zyga> tvoss: a bit unfortunate :/
[15:29] <tvoss> zyga: I removed that #
[15:29] <zyga> tvoss: what did you remove? in the tree I pushed I use a mount unit and that's done internally now
[15:29] <mup> PR snapcraft#913 closed: help: update stage-packages and build-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/913>
[15:29] <tvoss> zyga: prerm does not need to stop/disable snapd.mount
[15:29] <zyga> (apparently)
[15:29] <zyga> ah
[15:29] <zyga> hmm hmm hmm
[15:29] <didrocks> (hoping I can bindmount in devmode)
[15:29] <zyga> do we ever stop snap.mount (not snapd.mount)
[15:29] <zyga> didrocks: you might
[15:30] <zyga> didrocks: I don't know if anything else happens if you do that though
[15:30] <zyga> didrocks: or if you can even do that
[15:31] <zyga> didrocks: is /usr/share/alsa in the core snap? if not then sorry :/
[15:31] <tvoss> \o/
[15:32] <zyga> tvoss: do I owe you a beer?
[15:32] <tvoss> hang on, let me rerun this again
[15:32] <zyga> tvoss: are you in sync with master/
[15:33] <jdstrand> didrocks: the alsa interface was just committed
[15:33] <zyga> jdstrand: alsa looks at /usr/share/alsa, is that handled by the interface?
[15:33] <jdstrand> didrocks: oh, you need to see my comment in the bug
[15:33] <jdstrand> there is a way to do it
[15:34] <didrocks> jdstrand: oh nice! even on a core image. I guess it might be tight for next release though
[15:34] <jdstrand> zyga, didrocks: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
[15:34] <mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1598309>
[15:34] <zyga> ALSA_CONFIG_PATH
[15:34] <jdstrand> zyga, didrocks: alsa could use a snapcraft part
[15:34] <tvoss> zyga, yup
[15:34] <zyga> we're in environment hell :/
[15:34] <zyga> tvoss: ok, then I'm opening popcorn :)
[15:35] <jdstrand> zyga: note that I have a snap that works
[15:35] <jdstrand> zyga: see the above comment
[15:35] <didrocks> jdstrand: oh nice! I guess that will unblock it
[15:36] <didrocks> jdstrand: I need to look if there is alsa though on the ubuntu core rpi2 image first
[15:36] <jdstrand> didrocks: between the interface and the technique I sketched out, yes, it can be unblocked without patching alsa or doing weird mount tricks
[15:37] <didrocks> jdstrand: well, without the interface, devmode for next week will be enough
[15:37] <didrocks> just need to ensure now that the core image has it
[15:37] <jdstrand> didrocks: but the technique is somewhat error prone. a snapcraft part would be the way to go
[15:37] <jdstrand> didrocks: right, devmode next week almost certainly. 2.17.1 isn't even in xenial yet and this would be 2.18
[15:37] <didrocks> jdstrand: yeah, I guess though as a first rough approach, that would work
[15:37] <didrocks> yeah
[15:39] <didrocks> ah, no alsa on core
[15:40] <nuclearbob> ogra_: when you have a minute, can you  help me with info on connecting a serial console on the dragonboard?
[15:41] <zyga> nuclearbob: do you have the small daugther board?
[15:41] <nuclearbob> zyga: I don't. I can get that if I need to
[15:42] <zyga> nuclearbob: no, it's just easier this way
[15:42] <zyga> nuclearbob: all 96 boards have the serial pins in the same spot
[15:43] <nuclearbob> zyga: I'm hoping it's somewhere in the j8 connector, since that'd be easiest :)
[15:45] <nuclearbob> I guess that's the low speed expansion
[15:46] <zyga> nuclearbob: if you need this urgently I can probe the board I have working locally
[15:46] <zyga> nuclearbob: I have the header but it's not populated now, usually I was using the daughter board that does everything
[15:46] <zyga> nuclearbob: (incl board reset)
[15:46] <nuclearbob> zyga: I wouldn't call it urgent, so don't worry about messing with yours. There's someone on my team that I'm pretty sure can help, she just won't be on for a few hours yet
[15:47] <zyga> nuclearbob: feel free to ping me if you change your mind
[15:47]  * zyga was hoping for some scope and serial action ;)
[15:47] <nuclearbob> zyga: awesome, thanks. If you want to check out which pins I need to use, I can complain about how the hdmi isn't giving me anything, and this dragonboard is useless until I get something working, oh the wasted time, save us all
[15:48] <tvoss> zyga: no logic analyzer fun for you today ;)
[15:48] <didrocks> hum, even on classic server image, no alsa
[15:49] <zyga> tvoss: there's always that scope bed-time real-life story with kids ;)
[15:50] <zyga> tvoss: so what was the magic ingredient you found
[15:50] <tvoss> zyga: oh yeah, once upon time, when your dad grabbed the scope and went out to fight all the low-level transport bugs ;)
[15:50] <zyga> tvoss: tell me!
[15:50] <zyga> tvoss: now hold the probe ... here
[15:50] <tvoss> zyga: no spoilers until I can pastebin
[15:50] <zyga> ;D
[15:50] <zyga> ok
[15:50] <zyga> tvoss: I'll switch to snap-confine for a sec then
[15:59] <didrocks> jdstrand: hum, I'm unsure how to we could use that as a part btw, as the alsa config will defer depending on hw, wouldn't it?
[15:59] <didrocks> jdstrand: like, if I'm using your snap, I have a device busy error message, because it doesn't use the proper id I guess
[15:59] <didrocks> (I can play the same file with using aplay directly)
[16:00] <didrocks> (listing the cards sound correct though)
[16:13] <qengho> jdstrand: for store automated review, """declaration malformed (wrong type 'true' for attribute 'allow-sandbox') declaration-snap-v2_valid_plugs (browser-support, allow-connection_plug-attributes)""". Is it something other than boolean, or deprecated, or something?
[16:21] <didrocks> kgunn: hey, unsure you saw my previous ping about MIR/rpi2?
[16:23] <jdstrand> jhodapp: https://github.com/snapcore/snapd/wiki/Security#interface-development-and-security-policy
[16:41] <mterry> What is the word on policykit support?  u8 snap wants to use it to talk to SnapdLoginService
[16:44] <boriseto-work> Hello, how can I execute a snap from terminal (lets say VLC for example)? Can I bind it with other apps for opening directly a file or link? I have both the ppa version and the snap version.
[16:45] <OerHeks> i'd like to know the answer too, boriseto-work :-)
[16:47] <zyga> boriseto-work: just run the command name, look at /snap/bin
[16:48] <boriseto-work> zyga: oh so it's that simple. So for binding it from another app (let's say I want to open a video from there), instead of "vlc" I should use "/snap/bin/vlc"
[16:49] <jdstrand> qengho: sorry I missed your question. it might be a bug. what is the package?
[16:49] <tvoss> zyga, mild optimism: upgrade/basic is green
[16:51] <qengho> jdstrand: one of the browsers. I put it in the review queue because it's so hard to link.
[16:52] <tvoss> zyga: kicked the full test suite again
[16:52] <kgunn> didrocks: i might've fell of the internet....what was the ques again?
[16:53] <zyga> boriseto-work: not sure what you mean by binding, I'll be back laster
[16:53] <zyga> later*
[16:53] <jdstrand> qengho: I don't see it in the review queue. is it the one I helped you with before?
[16:53] <zyga> tvoss: tell me what was broken if you can, I'll gladly check it out in the evening
[16:54] <boriseto-work> zyga: it's okay, made it work as I wanted now. Was trying to tell other apps that use the video player to use the snap vlc instead of the ppa one. Didn't even think of checking the /snap/bin folder. Thank you very much.
[16:54] <tvoss> zyga: simple thing: prerm must not stop snapd.mount (specifically not with snaps installed)
[16:54] <tvoss> zyga: a fixed up version is in the ppa
[16:56] <didrocks> kgunn: the question was regarding https://developer.ubuntu.com/en/snappy/guides/mir-snaps/. Do we have any Mir snap example that we could use to showcase Mir on the rpi2? (on core)
[16:57] <qengho> jdstrand: yes. ah! It took two presses of request-review button. First saves destination but doesn't submit. Weird.
[16:57] <jdstrand> ok, I found it on my own
[16:57] <kgunn> didrocks: sorry, answered on the mail.... and short answer, need a new kernel snap with relevant gfx kernel patches integrated
[17:05] <tvoss> zyga: I'm grabbing dinner, back after that
[17:05] <jdstrand> qengho: there is a bug in the review tools. it is easily worked around by adjusting the snap declaration. I've done that. I reran the checks and it passed. you may push the publish button whenever you are ready
[17:07] <qengho> jdstrand: thank you!
[17:07] <jdstrand> np
[17:07] <qengho> jdstrand: Does my snapcraft.yaml need updating?
[17:07] <jdstrand> qengho: no. it was a problem in the snap declaration parsing
[17:08] <jdstrand> qengho: 'declaration malformed'. you don't have anything to do with declarations so you are all good
[17:08] <mup> Bug #1642669 opened: Can't connect to SnapdLoginService from a snap <Snappy:New> <https://launchpad.net/bugs/1642669>
[17:10] <didrocks> jdstrand: hum, I don't find what could be wrong in the way I built your alsa snap, install in devmode…
[18:46] <jdstrand> niemeyer: hi!
[18:46] <niemeyer> jdstrand: Heya
[18:47] <jdstrand> niemeyer: I'm off W-F of next week. I was wondering if we could chat soonish to talk about dbus-app, ideally so that I could implement it for merging before my holiday
[18:47] <niemeyer> jdstrand: Sure.. how about right now?
[18:47] <jdstrand> niemeyer: this comment I think is the starting off point: https://github.com/snapcore/snapd/pull/1613#issuecomment-254050047
[18:47] <mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[18:47] <jdstrand> niemeyer: that would be great :)
[18:48] <jdstrand> note my last comment for store uploads: https://github.com/snapcore/snapd/pull/1613#issuecomment-261056164
[18:48] <mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[18:49] <niemeyer> jdstrand: Ok, so this interface is supposed to encapsulate the decisions we make inside apparmor for read/write access to particular services
[18:51] <jdstrand> niemeyer: the simplest form it could take is allowing the bind to a well-known name. however, this PR goes beyond that and allows connects to that well known name, which now that kde has weighed in, they want
[18:51] <jdstrand> niemeyer: ie, they are binding for a reason, to interact. this allows them to do so
[18:52] <niemeyer> jdstrand: Right, and which I think was the best path as we discussed earlier
[18:52] <jdstrand> ok, good
[18:52] <jdstrand> I do too
[18:52] <jdstrand> off to a good start! :)
[18:52] <niemeyer> jdstrand: My main concern now is whether this language is enough and proper to address the problem
[18:53] <niemeyer> jdstrand: There are two unrelated issues I can see in the language used there.. the first related to that "api" parameter
[18:53] <jdstrand> niemeyer: the apparmor policy would essentially be 'the slot with this label can talk to the plug with that label over dbus'
[18:53] <jdstrand> is, slot side gets 'dbus peer=(label=plugside),'
[18:53] <niemeyer> jdstrand: Where "label" is "api"?
[18:54] <jdstrand> and the plug gets 'dbus peer=(label-slotside),'
[18:54] <jdstrand> (we'd add the com.example. stuff too of course
[18:54] <jdstrand> )
[18:54] <jdstrand> niemeyer: no, those are apparmor rules so label means the security label. ie snap.foo.bar
[18:54] <niemeyer> jdstrand: Okay, that's cool
[18:55] <jdstrand> I would want to add interface=org.gnome.Rhythmbox{.*} as well to those rules
[18:56] <jdstrand> and whether it is 'session' or 'system' of course
[18:56] <niemeyer> jdstrand: That sounds misnamed
[18:56] <jdstrand> niemeyer: as for 'api', yes, that I just tossed that out there for discussion
[18:57] <jdstrand> niemeyer: before we name it, do we want something like that at all?
[18:57] <jdstrand> niemeyer: there is precedence for something like that-- 'content' in the content interface
[18:57] <jdstrand> but with content, it makes sense to have a tighter coupling
[18:58] <jdstrand> I'm less sure here (I'm on the fence)
[18:58] <niemeyer> jdstrand: Maybe.. we need a way to tell that we're connecting the proper plug to the proper slot
[18:58] <jdstrand> that's true
[18:59] <niemeyer> jdstrand: This may be done either explicitly, as in content, or it may be done implicitly based on existing metadata
[18:59] <niemeyer> jdstrand: dbus already has such a concept internally
[19:00] <jdstrand> with this for plugs:
[19:00] <jdstrand> plugs:
[19:00] <jdstrand>   rhythmbox:
[19:00] <jdstrand>     interface: dbus-app
[19:00] <jdstrand> if rhythmbox had two dbus-app slots, I don't think there is enough implicitly
[19:01] <jdstrand> now, the plugs side doesn't have to be that simple
[19:01] <jdstrand> (but that is how it is in my comment)
[19:02] <jdstrand> so that is getting me to like this explicit name
[19:02] <jdstrand> were you thinking of something else for implicit?
[19:03] <niemeyer> jdstrand: Yes, dbus itself has resolution logic
[19:03] <niemeyer> jdstrand: It has exactly the same problem internally, right?
[19:03] <niemeyer> jdstrand: The client needs to talk to the server and they both need to know what they're talking about
[19:04] <jdstrand> yes
[19:04] <niemeyer> jdstrand: As there are many objects and many interfaces under the same endpoint
[19:04] <jdstrand> niemeyer: so thinking maybe plugs side also has session and system?
[19:05] <niemeyer> jdstrand: Adding a high-level label means we can match them both by just comparing that label, but that also means we're reinventing the same mechanism, and creating the potential for mismatching
[19:05] <jdstrand> niemeyer: and we just use the intersection?
[19:05] <niemeyer> jdstrand: E.g. if you and me create two different snaps with different "api" fields and a different selection of interfaces, our snaps cannot interact, although the thing we're abstracting away could in fact talk to each other
[19:05] <jdstrand> niemeyer: it does seem natural for someone that wants to talk over dbus to declare what they want to talk to, yes
[19:06] <jdstrand> niemeyer: yes, that makes sense
[19:06] <jdstrand> niemeyer: are you then advocating for having session and system on both slots and plugs, or something else?
[19:06] <niemeyer> jdstrand: There's also a related issue: we're not allowing the interfaces to specify a "path"
[19:07] <jdstrand> path is tricky
[19:07] <niemeyer> Why?
[19:07] <jdstrand> because people don't always use it consistently
[19:07] <jdstrand> I've seen a lot of applications just pick '/' as the path
[19:08] <jdstrand> my goal is to not reinvent the apparmor language or dbus semantics in this area. maybe we have to, but ideally not
[19:08] <niemeyer> jdstrand: Ok, but that means the client needs to use that path too if it expects to interact, right?
[19:08] <niemeyer> jdstrand: Well, exactly.. I'm wondering if we can map it more closely instead of reinventing
[19:08] <jdstrand> niemeyer: I was thinking simply omit the path and rely on interface, bus name and security label
[19:09] <niemeyer> jdstrand: The code currently is doing "obj.path" => "obj/path", which is not what dbus does.. that's reinventing it
[19:09] <niemeyer> jdstrand: It's not omitting the path.. it's guessing it
[19:09] <jdstrand> eg: dbus bus=session interface=org.gnome.Rhythmbox{,.*} peer=(label=<the other side>)
[19:09] <jdstrand> we just allow any path and member
[19:10] <niemeyer> jdstrand: Can the client tell what the remote path is?
[19:11] <jdstrand> which I think is fine. we want to allow the connection and not worry about carving out the apis
[19:11] <niemeyer> jdstrand: To some degree, yes
[19:11] <jdstrand> niemeyer: the client necessarily has to know it, yes, so it is possible to declare it. but I'm not sure how worthwhile that is since we are really just wanting to say "let these guys talk over this dbus interface"
[19:11] <niemeyer> jdstrand: Can the client tell what the remote path is?
[19:12] <niemeyer> jdstrand: Ok.. so just to be clear, that's not what is being done ATM, right?
[19:12] <jdstrand> so, the client either has to know or there is dbus introspection
[19:13] <jdstrand> niemeyer: re done ATM> the code in the PR does not reflect any discussiosn after the initial submission as dbus-app, if that is your question
[19:13] <niemeyer> jdstrand: Ack
[19:14] <niemeyer> jdstrand: So.. brainstorming idea:
[19:14] <jdstrand> so, hoping to get the yaml nailed done and what that represents, then I can run with it
[19:14] <jdstrand> s/done/down/
[19:14] <niemeyer> jdstrand: What if we stripped out the snap "dbus" (not dbus-app) interface to *one* interface
[19:15] <jdstrand> I'm not following
[19:16] <niemeyer> slots:
[19:16] <niemeyer>     my-dbus-interface:
[19:16] <niemeyer>         interface: dbus
[19:16] <niemeyer>         name: org.my.dbus.Interface
[19:16] <niemeyer>         bus: session
[19:17] <niemeyer> jdstrand: Consider the consequences..
[19:18] <jdstrand> in terms of the problem this is trying to solve, that would work. you need one slot per org.my.dbus.Interface. the plugs side would also need 'name' and 'bus'
[19:18] <mup> Bug #1642669 changed: Can't connect to SnapdLoginService from a snap <snapd-glib:Confirmed> <https://launchpad.net/bugs/1642669>
[19:18] <jdstrand> then we have a clean way of connecting
[19:19] <jdstrand> a thick snap could offer 10 things, and a plug could use just one of them
[19:19] <jdstrand> (if it wanted)
[19:19] <jdstrand> or 5 or all 10
[19:19] <niemeyer> jdstrand: Right, exactly
[19:20] <niemeyer> jdstrand: It also means we can have more fine-grained decisions about what is okay to auto-connect or not
[19:20] <jdstrand> this could also be used to ease slot development in general for cases where we want to offer the entire api for a particular interface
[19:20] <niemeyer> jdstrand: and we don't need "api", as dbus already tells us that via these fields
[19:21] <jdstrand> eg, network-manager could move to this if desired since we know that its api can't effectively be carved (that is a more farther out thing)
[19:21] <jdstrand> niemeyer: re not needing api> yes
[19:21] <jdstrand> niemeyer: I like it
[19:22] <niemeyer> jdstrand: The problem is finer grained access is a bit unclear to me.. we might add read and write fields with lists of methods in the future, I guess, and make auto-connection conditional on their content.. I suppose.
[19:23] <niemeyer> jdstrand: Ah.. interestingly, these fields might be on the plug side only
[19:23] <niemeyer> jdstrand: The slot of course doesn't care
[19:23] <niemeyer> jdstrand: In the sense it offers it all
[19:23] <jdstrand> niemeyer: possible, yes (for all of this). I suspect if we are carving out bits like that we can continue to do a dedicated interface
[19:24] <jdstrand> but, it is possible to move everything out to this once we learn more how people want to use it
[19:24] <niemeyer> jdstrand: Well, yes, but we can't be too confident we know where this will go ahead of time.. sometimes design takes its own direction when people love a feature
[19:25] <niemeyer> jdstrand: I can imagine people wanting to simply keep using this for dbus, instead of having to create custom interfaces
[19:26] <jdstrand> I just mean that if we have so much knowledge about a dbus api, eg, for location-service, we just offer an interface call location-observe and location-control, etc rather than making location-service use the dbus interface. that is still a viable approach while we learn how people use the dbus interface with just 'bus' and 'interface'
[19:26] <jdstrand> niemeyer: re imagine> yes, me too. I think it would be helpful
[19:26] <niemeyer> Yeah, sound good
[19:26] <niemeyer> jdstrand: Okay, I think we have a plan
[19:27] <jdstrand> ok, I'll summarize it and get this going
[19:27] <jdstrand> (summarize in the PR)
[19:27] <jdstrand> niemeyer: thanks!
[19:28] <niemeyer> jdstrand: np, and thanks as well
[19:33] <SciVision> I started Ubuntu Core on a Raspi 3 . Could run the setzp. Now I am prompted for localhost login. tried Ubuntu so key from another machine, tried 'ubuntu, but nothing worked. How can I login?
[19:34] <SciVision> Sorry typos: I tried to login from another machine in the network with ssh and Ubuntu name@ip address. Did not work. How can I login?
[19:40] <zyga> SciVision: you can login only over ssh, ther'es no password, you must use the ssh keys that are published in your sso (launchpad or ubuntu one) account
[19:41] <SciVision> ok
[19:41] <SciVision> the keys not user name
[19:45] <SciVision> zyga: Sorry on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ it says "ssh <Ubuntu SSO user name>@<device IP address>"
[19:46] <SciVision> and I get Permission denied when I use my Ubuntu one account login id
[19:48] <SciVision> zyga: Got it. Thanks
[19:49] <jdstrand> niemeyer: fyi, https://github.com/snapcore/snapd/pull/1613#issuecomment-261350004. I'm running with it. please let me know if I got something wrong
[19:49] <mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[20:05] <Damian> hi everyone. I am trying to get core running on a raspberry pi 3, loaded the image on the card and booted up, configured the wifi if and it connected and got an ip address, then I get "Network configuration timed out; please verify your settings" error
[20:06] <Damian> any ideas on how to get past this?
[20:21] <ahoneybun> thanks for that update jdstrand
[20:22] <jdstrand> ahoneybun: you're welcome
[20:22] <ahoneybun> jdstrand: I know Pithos will hit that issue later once I found out how to tell it to look in a space for a file
[20:22] <ahoneybun> *place
[20:23]  * jdstrand nods
[20:43] <cwayne> hey guys, is there a way to allow a snap to auto-connect to an interface (in this case, log-observe)?
[21:45] <ahoneybun> can I use filesets to fix this issue? : http://pastebin.ubuntu.com/23477531/
[21:45] <ahoneybun> GLib.Error: g-file-error-quark: Failed to open file '/share/pithos/pithos.gresource': open() failed: No such file or directory (4)
[21:45] <ahoneybun> the .gresource is in /share/pithos
[21:45] <ahoneybun> so I need something like $SNAP I guess
[21:49] <linuxhiker> I am trying to improve the postgresql snap packages and have run into an issue.  On compilation we can call world which will make the contents of the contrib directory. However, I can't figure out how to get the finalized contents of the contrib directory to be properly installed into the snap packages (postgresql proper, without contrib works)
[23:02] <mup> PR snapcraft#905 closed: Snap revision prune <Created by seawaywen> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/905>
[23:05] <mup> PR snapcraft#914 closed: meta: icon is now dedeprecated <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>
[23:20] <mup> PR snapcraft#915 opened: cache: cleanup logic to pass project name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/915>