/srv/irclogs.ubuntu.com/2016/11/17/#snappy.txt

mupPR snapcraft#912 opened: Add a gradle demo and test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/912>00:17
mupPR snapcraft#652 closed: Demo/gradle <Created by ZenHarbinger> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/652>00:20
mupPR 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>00:41
=== chihchun is now known as chihchun_afk
mupPR snapcraft#871 closed: Remove XXX comment from stage-packages <Created by nhandler> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/871>02:08
mupPR snapcraft#913 opened: help: update stage-packages and build-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/913>02:08
mupPR snapcraft#914 opened: meta: icon is now dedeprecated <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>02:29
mupPR snapcraft#761 opened: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761>02:38
HOAIhello 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 snappy03:11
zygagood morning07:38
dholbachhey hey07:43
foxmaskbonjello07:47
mupBug #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:11
zygatvoss: I think I understand it now09:56
zygatvoss: testing a simple fix09:56
tsdgeosis there a difference in what happens between09:58
tsdgeossudo snap install --devmode --force-dangerous mysnap.snap09:58
tsdgeosand09:58
tsdgeossudo snap try path/to/mysnap/prime --devmode09:58
tsdgeos?09:58
zygayes09:59
zygatsdgeos: the difference is as follows:09:59
zygatsdgeos: 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
zygatsdgeos: 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_REVISION09:59
zygatsdgeos: you cannot remove that directory (rename it, break meta/snap.yaml) without some consequences10:00
zygatsdgeos: the content is also live, you can change it and observe effects immediately10:00
tsdgeosbecause i'm seeing what i think is a runtime difference,10:00
tsdgeosdo you think that's possible?10:00
zygatsdgeos: at runtime, perhaps still, the directory might be writable10:00
zygatsdgeos: I think we didn't fix that yet10:00
zygatsdgeos: what do you observe?10:00
Chipacamatteo`: ping10:01
matteo`Chipaca: pong10:01
tsdgeoszyga: i think i'm seeing some dbus calls succeed in the install case and not in the try case10:01
Chipacamatteo`: what happened to docs/interfaces.md in your #2193 ?10:01
zygatsdgeos: dbus is interesting, it is usually not affected by anything, can you show me the apparmor denial (journalctl | grep DENIED) please10:01
zygaChipaca: isn't that moved to the wiki now?10:02
Chipacaah!10:02
Chipaca:-)10:02
Chipacazyga: and how is that kept in sync with the code?10:02
zygaironically editing the wiki with git is nice :)10:02
zygaChipaca: manually but the process is lighter10:02
zygaChipaca: we should just poke people to edit it10:02
Chipacazyga: so should there be a PR for the wiki for every PR that needs to update docs?10:02
tsdgeoszyga: 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 noise10:03
Chipacatsdgeos: no denials but things not working usually means seccomp10:03
Chipacatsdgeos: but I have no context other than what you said just there10:04
zygatsdgeos: do you have an encrypted home directory, or home directory in some non standard location10:04
matteo`Chipaca: I found this? https://github.com/snapcore/snapd/blob/master/docs/MOVED.md10:04
zygatsdgeos: I'm happy to help, bugs like this always show insight into what the real system is doing10:04
Chipacamatteo`: yep! sorry, i forgot about that move (see my conversation with zyga)10:04
Chipacamatteo`: but you're still on the hook for having the docs for this be in place once your branches land10:05
zygamatteo`: the up side is that you just hit the edit button and type away :)10:05
zygamatteo`: you can use git if you prefer10:05
matteo`zyga: I wanted to edit the wiki only after the PR merge10:06
matteo`otherwise I'll have documentation for a non existing feature10:06
zygamatteo`: that's fine, it's a wiki :D10:06
=== matteo` is now known as matteo
zygamatteo: just edit (you can say  "PENDING merge" or something)10:07
matteook10:07
zygamatteo: it'd be nice to indicate "since snapd 1.2.3" actually10:07
zygamatteo: so you can just use the future version there10:07
matteook10:07
Chipacamatteo: rawusb is going to land in a few more minutes, unless i386 hates you10:08
zygaChipaca: raw usb interface?10:08
Chipacausb-raw10:08
matteoyes, direct usb access, eg. for sane10:08
zygaChipaca: woot, I could use that for my test farm to drive some tools I have10:08
zyga(now if only 14.04 wasn't so mysteriously failing on the upgrade test)10:09
Chipacazyga: woot at matteo; i'm just pushing it10:09
zygathank you matteo :)10:09
matteobtw I have an example snap that uses it10:09
matteoit contains lsusb10:09
Chipacazyga: and it might get renamed; jdstrand did ask niemeyer about the name, but that was 21 days ago10:09
Chipacain snapd time that's past the statute of limitations110:10
zygamatteo: perfect, I was thinking about a libusb based flash tool for STM devices10:10
zygaChipaca: that's like eternity ;010:10
matteohttps://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/usb-utils/snapcraft.yaml10:10
Chipacaprecisely10:10
matteodo you have an STM MCU? Like STM324F?10:10
Chipacazyga: this thing about me being able to push branches at PRs to unbreak them is terrible10:11
zygamatteo: yes, a few actually10:11
zygamatteo: I briefly worked on the lm4tools that can flash them10:11
matteonice, I have some too10:11
zygaChipaca: terrible or terrific?10:11
matteodid you flash them with gdb and openocd?10:11
zygamatteo: no, just lm4tools, it was way easier and I think, at the time, the only supported way10:11
matteoChipaca: I alphabetizet everything in all.go and all_test.go, but you put NewAvahiObserveInterface after NewCupsControlInterface10:16
matteohow much time the autopkgtest need to run?10:16
Chipacamatteo: I don't think I did that?10:17
ChipacaNewAlsaInterface(),10:17
Chipaca  NewAvahiObserveInterface(),10:17
Chipaca +NewBluetoothControlInterface(),10:17
Chipaca +NewCameraInterface(),10:17
Chipaca +NewCupsControlInterface(),10:17
Chipaca  NewDcdbasControlInterface(),10:17
matteoin all_test10:18
matteohttps://github.com/snapcore/snapd/pull/2193/commits/1b9586330a2bbdf7e3534fe3d511a86fa8871da310:18
mupPR snapd#2193: add usb-raw iterface <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2193>10:18
Chipacamatteo: gah10:18
matteomaybe you did indirectly, while merging10:18
Chipacamatteo: I noticed and fixed it in all.go, but missed it in all_tests.go10:18
Chipacawhen merging, yes10:19
Chipacamatteo: I'll wait for all green, then fix this and wait for just spread green and land10:19
Chipacamatteo: unless you'd rather do it yourself10:19
Chipacaactually, this is strange10:20
Chipacain all_tests locally i have it ordered10:20
Chipacaah, no, wrong branch10:20
* Chipaca is tracking too many right now10:20
matteozyga: done the wiki10:22
matteoChipaca: I'm for the "wait just for spread and merge" thing10:22
Chipacazyga: you looked at 2249 before, could you +1 it if appropriate?10:24
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:25
zygaChipaca: checking10:28
Chipacagerry_: the snap store doesn't have a web interface accessible from a non-snap system10:29
Chipacagerry_: (you could install snapweb)10:29
Chipacagerry_: the snap store is what `snap find foo` talks to10:29
Chipacamvo: https://travis-ci.org/snapcore/snapd/jobs/17665672710:30
Chipacamvo: :-D10:30
Chipacamvo: but also :-/10:30
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:33
didrocksgerry_: yeah, "sofware" (not ubuntu software center) displays snaps and deb packages10:34
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:35
didrocksgerry_: I'm not particularly familiar with java based snap, but you sohuld give a look at the jdk snapcraft plugin IMHO10:41
gerry_ok thank you very much for your help10:41
didrocksyw! keep us posted :)10:43
zygatvoss: found one more issue, fixed it, trying10:47
zygatvoss: we didn't enable the mount unit10:47
zygatvoss: I switched the snapd-mount.sevice to a real snap.mount unit10:48
zygatvoss: fingers crossed, it also mkdirs the /snap directory for free ;)10:48
zygatvoss: ha, I think I begin to have something11:01
zygatvoss: 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 loop11:01
zygatvoss: that's a lie, mtab is garbage11:01
zygatvoss: I'll patch the test setup to rm /etc/mtab and use a symlink to see if that changes11:01
tvosszyga, +1, I'll another version of snapd into the ppa11:10
tvosszyga: did you push your most recent changes?11:10
zygatvoss: no, none of them improve the state yet11:41
tvosszyga: ack, I'll push a new snapd package nevertheless11:42
* zyga -> break11:56
Odd_Blokeogra_: Could you give me an update on where we are with https://bugs.launchpad.net/snappy/+bug/1639878?11:57
mupBug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:New for ogra> <https://launchpad.net/bugs/1639878>11:57
mupPR 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>11:59
zygatvoss: trying one more thing now12:05
zygatvoss: I think systemd and /etc/mtab being a real file don't work12:05
tvosszyga: uploaded to ppa, waiting for accept/reject message12:05
tvosszyga: aha12:06
zygatvoss: the rshared on / hides the issue somehow but not sure how12:06
zygatvoss: 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
zygatvoss: it's all a bit shoot-in-the-dark though :/12:06
tvosszyga: okay, let me find some help12:06
zygatvoss: nope, didn't help - still digging12:12
zygaqemu:ubuntu-14.04-64 .../tests/upgrade/basic# systemctl status snap-core.mount12:12
zyga   Loaded: error (Reason: No such file or directory)12:12
tvosszyga: I'm grabbing lunch, let's jump on a hangout with pitti right after that12:19
zygatvoss: ok12:23
zygatvoss: ah, silly me, the escaping causes my queries to systemd to give confusing messages12:26
=== hikiko is now known as hikiko|ln
zygatvoss: let's talk here so that pitti can be in the loop12:28
tvossv+112:28
zygatvoss: testing that new util-linux from ppa:pitti/systemd-semaphore12:29
tvossack12:29
tvossokay, grabbing a quick bite12:32
zygatvoss: no change12:34
mvoChipaca: haha, thank you!12:47
zygatvoss: thinking about what I'm seeing12:49
zygatvoss: across restart we just lose all the .mount units12:49
zygatvoss: is there anything that would keep them mounted?12:49
tvosszyga: across restart?12:50
tvosszyga: so that's snapd restart, correct?12:50
zygatvoss: across snapd update12:50
zygatvoss: that updates the package and runs some of the scripts12:50
zygatvoss: (presumably the postrm / prerm ones12:50
zygatvoss: I don't see anything starting mount units there12:50
tvosszyga: so snapd.postrm purge removes everything12:51
tvosshmmm, let me take a look at the actual test case12:51
zygatvoss: I see a clear failure12:51
zygathe mount units are all stopped12:51
zygahmm, but we don't purge, do we?12:52
zygatvoss: is there an easy way to see the list of maintainer scripts / arguments across dpkg/apt transaction?12:52
zygamvo: ^^ perhaps you know12:53
tvosszyga: /var/lib/dpkg/info has got all the scripts of all currently installed versions12:53
mvozyga: I'm not sure I understand the question? do you want to see how they are called and in what order?12:54
zygamvo: yes12:54
zygamvo: something like that12:54
zygamvo: when a package update occurs, what gets called and with what arguments12:55
zygamvo: I understand some of the old scripts are called, then some of the new scripts are called12:55
zygamvo: but details elude me12:55
mvozyga: https://wiki.debian.org/MaintainerScripts has a flow diagram12:57
mvozyga: the interessting one is "upgrading"12:57
zygathanks12:58
zygatvoss: I pushed my local patches, have a look12:58
zygatvoss: some of those should be removed later (HACK)12:58
tvosslooking12:58
zygamvo: I see, it is quite "interesting"12:58
zygatvoss: standup time for me13:00
tvosszyga: ack13:00
tvosszyga: probably makes sense if I join, too13:01
tvossdo you have a link handy?13:01
zygatvoss: sent13:01
tvosszyga: thx13:02
=== JanC_ is now known as JanC
zygapitti: http://pastebin.ubuntu.com/23490458/ <- is this indicating the thing is mounted or not?13:16
=== hikiko|ln is now known as hikiko
=== jhodapp_ is now known as jhodapp
jhodappAnybody 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:23
sergiusensjhodapp from what I read mvo mentioning; your db got migrated so you cannot go back13:26
jhodappsergiusens, is there a way I can start over? I don't care what's installed13:27
mvojhodapp: yeah, sorry for that, please use the version of snapd in xenial-proposed that should be fine and compatible13:27
mvojhodapp: starting over is also possible with "apt purge snapd" but its not really needed13:27
sergiusensjhodapp you misunderstand, I only said mvo mentioned, not that I can help you further than that ;-)13:27
jhodappmvo, I tried apt purge snapd but that didn't seem to do it13:27
jhodappsergiusens, heh :)13:28
mvojhodapp: oh? what is leftover? did it fail?13:28
jhodappmvo, let me try it again and get you the output13:28
mvothank you13:28
mvojhodapp: 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:28
zygatvoss: that didn't change anything (not touching snap.mount in prerm)13:29
jhodappmvo, here's the whole session: http://pastebin.ubuntu.com/23490516/13:29
zygainterestingly13:29
zygathis is the journal for the core snap's mount unit13:29
zygaqemu:ubuntu-14.04-64 .../tests/upgrade/basic# journalctl -u snap-core-394.mount13:29
zyga-- Logs begin at Thu 2016-11-17 14:23:33 CET, end at Thu 2016-11-17 14:28:51 CET. --13:29
zygaNov 17 14:28:35 autopkgtest mount[19811]: mount: warning: /snap/core/394 seems to be mounted read-only.13:30
zygathat's it!, it's not unmounted here13:30
himanshub16I 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
zygaah, unmount doesn't generate any logs, bummer13:30
tvosstotally unrelated: I think I will snap up icq13:31
zygais that still a thing? reminds me of windows 2000 and "I have a modem" days13:31
zygatvoss: I patched the mount unit to be read only, inclined to add something to them to just see when it is being mounted/unmonted13:32
zygaunmounted*13:32
zygapitti: anything I can add to a .mount unit to make it verbose?13:33
tvosszyga: it's actually open-source, and available for linux13:34
tvosszyga: distributed as a tar.xz containing a single executable13:35
tvosszyga: code is here: https://github.com/mailru/icqdesktop13:35
zygatvoss: wow, is that the same "flower-logo" icq from two decades ago?13:35
tvosszyga: precisely that ;)13:36
tvosszyga: come on, install it, I wanna check if there is still the "uh-oh" sound :)13:36
zygalol :)13:36
jhodappmvo, any thoughts?13:36
zygalet's fix stuff to run on 14.04 first13:36
zygathen we can use icq as a trophy13:36
mvojhodapp: yes13:37
mvojhodapp: but sorry, was distracted by a meeting13:37
tvosszyga: sure13:37
zygatvoss: I think I will follow niemeyer's advice and build a small test case to experiment and repdocude the behavior13:37
jhodappmvo, np13:37
mvojhodapp: could you please do a "ls -al ~/.snap" and pastebin that?13:37
jhodappsure13:37
zygatvoss: I still don't get what stops those units and why this happens on 14.04 but not on 16.0413:37
tvosszyga: okay, I will instrument the maintainer scripts to be verbose and tell us what is actually called13:37
zygatvoss: thanks13:37
jhodappmvo, ls: cannot access '/home/jhodapp/.snap': No such file or directory13:38
* mvo scratches head13:38
jhodapplol13:39
mvojhodapp: is there anything unusal about the system? coudl I get the output of "id ; env" please?13:40
zygajhodapp: congratulations, welcome to the snappy team, you have just passed the secret test13:40
zyga;)13:40
pittizyga: no, inactive/dead says "not mounted"13:40
mvojhodapp: welcome on board!13:40
zygapitti: thanks!13:40
jhodappzyga, hahaha13:40
zygapitti: is there a way to see when systemd stops/starts mount units? (or just one for experiment)13:40
pittizyga: 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
mvojhodapp: the code tries to do a lookup of the current user but for some reason this fails here and I wonder how that could happen13:41
zygapitti: I'm looking for "this is where that unit was stopped and something got unmounted"13:41
pittizyga: sure, it's all in the journal; journalctl -f is useful13:41
pittiStarting Mount unit for core13:41
pittiStopping Mount unit for core13:41
jhodappmvo, http://pastebin.ubuntu.com/23490552/13:41
jdstrandChipaca: I see you talking about docs and git, etc. where is that branch? I need to add some stuff13:41
zygapitti: hmm, is the 14.04 systemd doing that, I cannot see it13:42
jdstranddoesn't seem to be in https://github.com/snapcore13:43
zygajdstrand: snapd wiki is a git repo, it's a github thing13:43
jdstrandoh I see the link now13:43
* zyga tries and gets a quick coffee 13:43
jdstrandfunny, I just edited the wiki manually the other day13:44
jdstrandChipaca: nm13:45
* tvoss has test running with verbose maintainer scripts13:46
Chipacajdstrand: sorry, was in a hangout13:46
Chipacajdstrand: and then fixing a bug wrt resource consumption13:46
Chipaca(IOW getting lunch)13:47
zygatvoss: first one that cracks this and fixes it gets a beer :)13:47
jdstrandno worries at all :)13:47
tvosszyga: ;)13:47
mvojhodapp: 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
mvojhodapp: an strace -f -s1024 snap list would be nice as well, but I suspect the sudo you need for this will alter the behavior13:49
jhodappmvo, nope, it's just my laptop running 16.0413:49
jhodappmvo, that requires sudo?13:50
Chipacajhodapp: no13:51
mvojhodapp: no, sorry13:51
mvo(too much stuff going on at the same time)13:51
=== ben_r_ is now known as ben_r
jhodappmvo, http://pastebin.ubuntu.com/23490606/13:51
jhodappmvo, no prob13:51
mvojhodapp: 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
mvojhodapp: on your system?13:52
jhodappmvo, -rw-r--r-- 1 root root 2954 Jul  7 09:17 /etc/passwd13:53
zygajdstrand: any chance your are over ssh13:53
zygaer13:53
zygajhodapp: ^13:53
zygajhodapp: and ssh is confining all the sessions with apparmor like jdstrand does13:53
mvojhodapp: hmm, that looks fine, do you see something in "dmesg|grep DENIED"13:53
jhodappzyga, nope, I'm at the keyboard...no ssh13:54
mvojhodapp: its interessting, if I set it to 600 I get exactly the same error as you get13:54
zygajhodapp: any evil maids with hypervisor malware in sight?13:54
jhodappmvo, journalctl -f output for snap list: http://pastebin.ubuntu.com/23490617/13:55
zygapitti: 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
jhodappzyga, lol, I have kvm and virtualbox installed on this system, but neither are running13:55
mvojhodapp: 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:55
zygajhodapp: waaat13:56
zygaprofile="/usr/bin/snap"13:56
zygathat's not something we confine13:56
mvozyga: exactly13:56
zygajhodapp: can you look at /etc/apparmor.d/ and grep for /usr/bin/snap13:56
zygajdstrand: ^ ?13:56
jhodappyeah, one sec13:56
mvojhodapp: sudo grep -r /usr/bin/snap /etc/apparmor.d13:57
zygayou have that evil maid somewhere13:57
zygasecuring your snaps13:57
jhodappI feel so protected13:57
mvoor the opposite, someone trying to make the system more secure :)13:57
jhodapplol13:57
jhodappmvo, http://pastebin.ubuntu.com/23490626/13:57
zygajdstrand: dpkg -S /etc/apparmor.d/cache/usr.bin.snap13:58
zygaer13:58
zygasorry jdstrand, I hate irssi's tab completion13:58
zygajhodapp: dpkg -S /etc/apparmor.d/cache/usr.bin.snap13:58
zygamaybe a missing conflicts with some other package13:59
mvojhodapp, zyga: probably without the /cache/ ?13:59
zygaor missing maintainer script that removes that file when the package is removed13:59
jhodappzyga, dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.bin.snap13:59
zygaoh, I totally didn't see the cache part13:59
zygahmmm13:59
zygayep13:59
zygajhodapp: which release are you on?14:00
zygahttp://packages.ubuntu.com/search?searchon=contents&keywords=usr.bin.snap&mode=exactfilename&suite=yakkety&arch=any <- no hits14:00
zygajhodapp: can you please pastebin that file14:00
mvojhodapp: dpkg -S /etc/apparmor.d/usr.bin.snap please14:00
mvozyga: I can't find anything in apt-file on xenial or yakkety14:01
zygasame here14:01
zygacurious14:01
jhodappmvo, dpkg-query: no path found matching pattern /etc/apparmor.d/usr.bin.snap14:01
mvo:(14:01
jhodappzyga, pastebin which file?14:01
mvojhodapp: could you please pastebin /etc/apparmor.d/usr.bin.snap ?14:01
zygayep14:01
mvojhodapp: this is a really interessting issue you found!14:02
jdstrandsince when is /usr/bin/snap confined?14:02
jhodapplol, I didn't do anything fancy14:02
zygajdstrand: it's not, something else is at play here and assumes the same name, perhaps one of the packages that conflict with snapd14:02
mvojdstrand: this is what we are trying to figure out :)14:02
jhodappmvo, http://pastebin.ubuntu.com/23490647/14:03
zyga# Last Modified: Mon Oct 24 13:21:22 201614:03
mvojdstrand, zyga -^14:03
zygawhat did you do on oct 24?14:03
mvosuper strange14:03
mvoalso the content is… very bare14:03
zygadid you write that file? who's the owner14:03
mvoI guess its root:root ;)14:04
jdstrand/etc/apparmor.d/cache/usr.bin.snap isn't going to be shipped by anything14:04
jdstrand/etc/apparmor.d/usr.bin.snap would be the thing that was shipped14:04
zygajdstrand: apt-file knows about neither14:04
jhodappmvo, -rw------- 1 root root 141 Oct 24 13:22 /etc/apparmor.d/usr.bin.snap14:04
zygaso weird14:04
zyga600 is not typical14:05
mvojhodapp: do you have anything in /var/log/apt/history.log* around that time?14:05
jdstrandwhat are the contents of /etc/apparmor.d/usr.bin.snap?14:05
mvojhodapp: anything that got installed on that date/around this time?14:05
zygajhodapp: anyway, fire your maid, remove that file, unload the profile with apparmor_parser -R usr.bin.snap # AFAIR14:05
mvojdstrand: http://pastebin.ubuntu.com/23490647/14:05
* jhodapp checks14:05
jdstrandthat looks like a test profile14:05
jdstrandnot as in something we ship, but as in, what one might start with to see what it needed14:06
zygapitti: any advice on journal / systemd on 14.0414:07
jhodappmvo, I installed apparmor-utils14:08
mvojdstrand: could apparmor-utils have created profiles somehow? is there a command to auto-generate such profiles?14:08
jhodappmvo, also dh-apparmor got pulled in from that14:09
jdstrandmvo: no, it wouldn't have done any magic like that14:09
jdstrandit too14:09
jdstranddid you run aa-genprof?14:10
zygatvoss: I don't see any starting/stopping messages in syslog/journal on 14.0414:10
jhodappjdstrand, nope14:10
zygatvoss: do you know how I can get that wired so that we have diagnostics?14:10
jdstrandjhodapp: apt-cache policy apparmor-utils14:11
jhodappjdstrand, http://pastebin.ubuntu.com/23490677/14:12
pittizyga: indeed, seems the start/stop of mount units isn't logged by that backport; but you can see it in e. g. forkstat14:14
pitti$ cat /etc/systemd/system/opt2.mount14:14
pitti[Mount]14:14
pittiWhat=/opt14:14
pittiWhere=/opt214:14
pittiOptions=bind14:14
pittisudo systemctl start opt2.mount14:14
pitti15:14:16 exit  1130      0    0.009 /bin/mount /opt /opt2 -t auto -o bind14:14
zygaforkstat14:14
pittigosh, this whole thing is *such* a bloody hack14:15
zygawhat is that?14:15
pittizyga: global monitoring of forks/execs that happen14:15
pittigreat to track down "why is my system going mad" or finding what certain actions (like hotkeys etc.) do14:15
zygapitti: wow :)14:16
zygathanks, that's a gem and a keeper14:16
* pitti hands cking a ♥ for this nice tool14:16
jhodappjdstrand, thoughts on that?14:16
pittizyga: of course the second-best debugging tool is always to just attach strace to systemd :)14:16
ckingthanks pitti :-)14:16
zyganetlink14:16
zygathe source of magic and wonder on linux14:16
* zyga has to learn more about netlink14:17
pittiit's like magic14:17
zygapitti: any quick advice on how to embed forkstat into a test to see what is going on14:17
pittiit's everywhere, but nobody really understands it14:17
zygapitti: I can install it early on but I don't know what to run to see activity in a window14:17
pittizyga: run forkstat first, then your test?14:17
pittibut it really depends what you are actaully looking for14:17
zygapitti: can I run forkstat in the background or something like t14:17
zygaand have it dump stuff to a log14:17
zygapitti: I want to see all mount / unmount calls first14:18
pittiit 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 namespace14:18
zygapitti: my problem is that something stops a .mount unit14:18
jdstrandjhodapp (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.snap14:18
zygapitti: and I'm not sure what, I want to corelate that to other logs14:18
mvoforkstat goes crazy when you run go ;)14:19
zygajdstrand: I bet it 's the maid, all reasonable explanations are now exhausted14:19
mvobut its a wonderful tool14:19
zygadoh :/14:19
pittizyga: so to answer "what is calling umount", forkstat is actaully an excellent tool, as that tells you14:19
* mvo hugs cking14:19
jdstrandjhodapp (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 perms14:20
cking:-)14:20
jhodappjdstrand, mvo, zyga: here's my entire history.log for that day: http://pastebin.ubuntu.com/23490708/14:20
pittizyga: I thought your woes were related to trusty still having an /etc/mtab?14:20
pittizyga: systemd uses libmount's monitor, and I think in trusty that still parses /etc/mtab14:20
pitti(which of course is utterly and hopelessly broken for anything that snappy or systemd want to do)14:20
jhodappjdstrand, oh I was running aa-genprof!14:20
zygapitti: 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
jdstrandbingo14:20
jhodappjdstrand, I was trying to create a profile for media-hub14:20
zygajdstrand: nice!14:20
jdstrandjhodapp: 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.snap14:21
jdstrandjhodapp: that will set you straight14:21
mvojhodapp: excellent! I'm happy we found the root cause and even more happy that its not a general problem. thank you14:21
jhodappjdstrand, better! :)14:21
jhodappjdstrand, mvo, zyga thank you much!14:22
jdstrandjhodapp: you probably noticed the typo in my rm -f command14:22
jhodappjdstrand, so...we might want to caution people from using that tool when trying to do a interface14:22
jhodappjdstrand, yes14:22
jdstrandjhodapp: well... a) we don't say to use it and b) you used it on the wrong command14:23
jhodappjdstrand, what do you mean on the wrong command?14:23
jdstrandsudo aa-genprog /usr/bin/snap14:23
jdstrandmeh14:23
jhodappjdstrand, I was following some examples from the apparmor wiki14:23
jdstrandsudo aa-genprof /usr/bin/snap14:23
jdstrandyes, but you told genprof to profile 'snap', not media-hub14:24
jhodappjdstrand, hmm I don't see why I would have run that...must have been a fluke14:24
jdstrandthat's what I'm getting at14:24
jhodappjdstrand, would it install it into that spot under /etc/apparmor.d/ though?14:24
jdstrandyes14:24
pittizyga: ah, that should help then14:24
jhodappthat's weird...why wouldn't it just generate a profile and put it in '.' ?14:24
jdstrandgenprof is an apparmor tool, not a snappy one so it knows about /etc/apparmor.d, not /var/lib/snapd/apparmor/profiles14:25
jdstrandjhodapp: 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 logprof14:25
jdstrandgranted, the tooling isn't as nice as it could be-- but it is like a decade old14:26
jhodappjdstrand, yeah...I discovered that tool doesn't even work well with snappy14:26
jhodapperr, snaps14:26
jdstrandno, it wouldn't14:26
jdstrand(it wasn't written or updated for snappy)14:26
jhodappapparmor tools need some doc love14:26
jdstrandjhodapp: you mean for snappy?14:27
jhodappjdstrand, yeah14:27
jhodappcentered around creating an interface from scratch14:27
jhodappgeared towards someone not experienced with apparmor14:27
jdstrandso that would be snappy documentation, not apparmor documentation14:27
jdstrandbut yes14:28
jhodappright :)14:28
jhodappI'm just saying in geneneral14:28
jhodapp*general14:28
zygapitti: after snapd I want to work on kernel and plumbing :)14:28
* jdstrand nods14:28
zygapitti: forkstat is awesome14:28
jdstrandnormal snap developers shouldn't be fiddling with the guts of the sandboxing mechanism (apparmor, seccomp, etc). interface writers will need that of course14:29
jhodappjdstrand, 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 experience14:30
jhodapplike myself...and it's a frustrating experience14:30
jhodappjdstrand, so I definitely get where you're coming from, just stating my experience14:31
jdstrandjhodapp: 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 review14:31
jhodappjdstrand, we had talked about this before as well14:31
=== cpaelzer_ is now known as cpaelzer
jhodappjdstrand, that's a very good point!14:31
jhodappjdstrand, appreciate your thorough reviews14:31
jdstrandI can add something to https://github.com/snapcore/snapd/wiki/Security in the debugging section14:32
jdstrandthat will point in the right direction14:32
jhodappjdstrand, that'd be fantastic!14:32
tedgjdstrand: So the store blocks uploads with interfaces that it doesn't know about.14:49
tedgjdstrand: Would it be possible to disable that check for snaps that are in devmode?14:49
zygatedg: http://paste.ubuntu.com/23490892/15:06
zygatvoss: ^15:07
zygaor http://paste.ubuntu.com/23490903/15:07
zygafor the full log15:07
zygatvoss: interesting observation, umount is only called twice15:08
zygatvoss: and not on any of the snaps :/15:08
zygatvoss: only on /snap itself (mount -l) aka detach15:08
tvosszyga yup15:08
zygatvoss: this might explain what we're seeing15:08
zygatvoss: _might_15:08
zyganot sure it does15:08
zygatvoss: ah, I now see both the snapd-mount.service and snap.mount15:09
tvosszyga: 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 again15:09
tvosszyga: for that experiment, if I remove systemctl stop/disable snapd.mount from snapd.prerm, the snap remains mounted15:10
* zyga wonders what mandb is doing15:11
tvosszyga: however, the rbind/rshared setup is altered, let me pastebin error msg15:12
didrockskgunn: 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
tvosszyga: http://pastebin.ubuntu.com/23490920/15:12
zygatvoss: that looks like the core snap is empty15:13
zygatvoss: look at /snap/core/current, there's no /dev there, right?15:13
tvosszyga: nope15:14
zygatvoss: so that's snap-confine giving up, earlier it was snap-run15:15
zygatvoss: I think the difference is that snap-confine sees the real NS and sets a new NS15:15
zygatvoss: while snap-run (either run (before) or exec (after) ) sees the vanilla / confined namespace respectively15:16
zygatvoss: and because we only set up ns once, after that we just join it15:16
zygatvoss: you may see different error15:16
zygatvoss: thsi error says the core snap is not mounted in the outer namespace for sure15:16
tvossokay15:16
didrocksjdstrand: zyga: do we have any known workaround for snaps using alsa in core 16?15:26
didrocksAs I'm getting:15:26
didrocksALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf15:26
didrocksALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default15:26
didrockspeople used to patch it directly on the image in 15.04, but I'm unsure how we can tackle this in 1615:27
didrocksthis leads of course to:15:27
zygadidrocks: patch alsa to be snap-aware?15:27
didrocksCan't open pcm device 'default'.15:27
didrocksCouldn't open ALSA pcm device (`s')15:27
didrockszyga: not an option, deadline is next week15:27
matteoniemeyer: refactored15:27
zygadidrocks: I don't know of any other workaround15:27
zygadidrocks: maybe bind mount /usr/share/alsa to something in your snap as a test15:28
zygadidrocks: but that's not sustainable15:28
tvosszyga: I fail to see where snap-specific mount units get unmounted in the upgrade case15:28
zygatvoss: it gets detached15:28
zygatvoss: with all of /snap15:29
didrockszyga: yeah, I was thinking about doing something like that, but it means I need to have a wrapper to do this bindmount in devmode thus15:29
zygatvoss: a bit unfortunate :/15:29
tvosszyga: I removed that #15:29
zygatvoss: what did you remove? in the tree I pushed I use a mount unit and that's done internally now15:29
mupPR 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
tvosszyga: prerm does not need to stop/disable snapd.mount15:29
zyga(apparently)15:29
zygaah15:29
zygahmm hmm hmm15:29
didrocks(hoping I can bindmount in devmode)15:29
zygado we ever stop snap.mount (not snapd.mount)15:29
zygadidrocks: you might15:29
zygadidrocks: I don't know if anything else happens if you do that though15:30
zygadidrocks: or if you can even do that15:30
zygadidrocks: is /usr/share/alsa in the core snap? if not then sorry :/15:31
tvoss\o/15:31
zygatvoss: do I owe you a beer?15:32
tvosshang on, let me rerun this again15:32
zygatvoss: are you in sync with master/15:32
jdstranddidrocks: the alsa interface was just committed15:33
zygajdstrand: alsa looks at /usr/share/alsa, is that handled by the interface?15:33
jdstranddidrocks: oh, you need to see my comment in the bug15:33
jdstrandthere is a way to do it15:33
didrocksjdstrand: oh nice! even on a core image. I guess it might be tight for next release though15:34
jdstrandzyga, didrocks: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/515:34
mupBug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1598309>15:34
zygaALSA_CONFIG_PATH15:34
jdstrandzyga, didrocks: alsa could use a snapcraft part15:34
tvosszyga, yup15:34
zygawe're in environment hell :/15:34
zygatvoss: ok, then I'm opening popcorn :)15:34
jdstrandzyga: note that I have a snap that works15:35
jdstrandzyga: see the above comment15:35
didrocksjdstrand: oh nice! I guess that will unblock it15:35
didrocksjdstrand: I need to look if there is alsa though on the ubuntu core rpi2 image first15:36
jdstranddidrocks: between the interface and the technique I sketched out, yes, it can be unblocked without patching alsa or doing weird mount tricks15:36
didrocksjdstrand: well, without the interface, devmode for next week will be enough15:37
didrocksjust need to ensure now that the core image has it15:37
jdstranddidrocks: but the technique is somewhat error prone. a snapcraft part would be the way to go15:37
jdstranddidrocks: right, devmode next week almost certainly. 2.17.1 isn't even in xenial yet and this would be 2.1815:37
didrocksjdstrand: yeah, I guess though as a first rough approach, that would work15:37
didrocksyeah15:37
didrocksah, no alsa on core15:39
nuclearbobogra_: when you have a minute, can you  help me with info on connecting a serial console on the dragonboard?15:40
zyganuclearbob: do you have the small daugther board?15:41
nuclearbobzyga: I don't. I can get that if I need to15:41
zyganuclearbob: no, it's just easier this way15:42
zyganuclearbob: all 96 boards have the serial pins in the same spot15:42
nuclearbobzyga: I'm hoping it's somewhere in the j8 connector, since that'd be easiest :)15:43
nuclearbobI guess that's the low speed expansion15:45
zyganuclearbob: if you need this urgently I can probe the board I have working locally15:46
zyganuclearbob: I have the header but it's not populated now, usually I was using the daughter board that does everything15:46
zyganuclearbob: (incl board reset)15:46
nuclearbobzyga: 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 yet15:46
zyganuclearbob: feel free to ping me if you change your mind15:47
* zyga was hoping for some scope and serial action ;)15:47
nuclearbobzyga: 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 all15:47
tvosszyga: no logic analyzer fun for you today ;)15:48
didrockshum, even on classic server image, no alsa15:48
zygatvoss: there's always that scope bed-time real-life story with kids ;)15:49
zygatvoss: so what was the magic ingredient you found15:50
tvosszyga: oh yeah, once upon time, when your dad grabbed the scope and went out to fight all the low-level transport bugs ;)15:50
zygatvoss: tell me!15:50
zygatvoss: now hold the probe ... here15:50
tvosszyga: no spoilers until I can pastebin15:50
zyga;D15:50
zygaok15:50
zygatvoss: I'll switch to snap-confine for a sec then15:50
didrocksjdstrand: 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
didrocksjdstrand: like, if I'm using your snap, I have a device busy error message, because it doesn't use the proper id I guess15:59
didrocks(I can play the same file with using aplay directly)15:59
didrocks(listing the cards sound correct though)16:00
=== JanC is now known as Guest90855
=== JanC_ is now known as JanC
qenghojdstrand: 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:13
didrockskgunn: hey, unsure you saw my previous ping about MIR/rpi2?16:21
jdstrandjhodapp: https://github.com/snapcore/snapd/wiki/Security#interface-development-and-security-policy16:23
mterryWhat is the word on policykit support?  u8 snap wants to use it to talk to SnapdLoginService16:41
boriseto-workHello, 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:44
OerHeksi'd like to know the answer too, boriseto-work :-)16:45
zygaboriseto-work: just run the command name, look at /snap/bin16:47
boriseto-workzyga: 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:48
jdstrandqengho: sorry I missed your question. it might be a bug. what is the package?16:49
tvosszyga, mild optimism: upgrade/basic is green16:49
qenghojdstrand: one of the browsers. I put it in the review queue because it's so hard to link.16:51
tvosszyga: kicked the full test suite again16:52
kgunndidrocks: i might've fell of the internet....what was the ques again?16:52
zygaboriseto-work: not sure what you mean by binding, I'll be back laster16:53
zygalater*16:53
jdstrandqengho: I don't see it in the review queue. is it the one I helped you with before?16:53
zygatvoss: tell me what was broken if you can, I'll gladly check it out in the evening16:53
boriseto-workzyga: 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
tvosszyga: simple thing: prerm must not stop snapd.mount (specifically not with snaps installed)16:54
tvosszyga: a fixed up version is in the ppa16:54
didrockskgunn: 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:56
qenghojdstrand: yes. ah! It took two presses of request-review button. First saves destination but doesn't submit. Weird.16:57
jdstrandok, I found it on my own16:57
kgunndidrocks: sorry, answered on the mail.... and short answer, need a new kernel snap with relevant gfx kernel patches integrated16:57
tvosszyga: I'm grabbing dinner, back after that17:05
jdstrandqengho: 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 ready17:05
qenghojdstrand: thank you!17:07
jdstrandnp17:07
qenghojdstrand: Does my snapcraft.yaml need updating?17:07
jdstrandqengho: no. it was a problem in the snap declaration parsing17:07
jdstrandqengho: 'declaration malformed'. you don't have anything to do with declarations so you are all good17:08
mupBug #1642669 opened: Can't connect to SnapdLoginService from a snap <Snappy:New> <https://launchpad.net/bugs/1642669>17:08
didrocksjdstrand: hum, I don't find what could be wrong in the way I built your alsa snap, install in devmode…17:10
jdstrandniemeyer: hi!18:46
niemeyerjdstrand: Heya18:46
jdstrandniemeyer: 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 holiday18:47
niemeyerjdstrand: Sure.. how about right now?18:47
jdstrandniemeyer: this comment I think is the starting off point: https://github.com/snapcore/snapd/pull/1613#issuecomment-25405004718:47
mupPR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>18:47
jdstrandniemeyer: that would be great :)18:47
jdstrandnote my last comment for store uploads: https://github.com/snapcore/snapd/pull/1613#issuecomment-26105616418:48
mupPR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>18:48
niemeyerjdstrand: Ok, so this interface is supposed to encapsulate the decisions we make inside apparmor for read/write access to particular services18:49
jdstrandniemeyer: 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 want18:51
jdstrandniemeyer: ie, they are binding for a reason, to interact. this allows them to do so18:51
niemeyerjdstrand: Right, and which I think was the best path as we discussed earlier18:52
jdstrandok, good18:52
jdstrandI do too18:52
jdstrandoff to a good start! :)18:52
niemeyerjdstrand: My main concern now is whether this language is enough and proper to address the problem18:52
niemeyerjdstrand: There are two unrelated issues I can see in the language used there.. the first related to that "api" parameter18:53
jdstrandniemeyer: the apparmor policy would essentially be 'the slot with this label can talk to the plug with that label over dbus'18:53
jdstrandis, slot side gets 'dbus peer=(label=plugside),'18:53
niemeyerjdstrand: Where "label" is "api"?18:53
jdstrandand the plug gets 'dbus peer=(label-slotside),'18:54
jdstrand(we'd add the com.example. stuff too of course18:54
jdstrand)18:54
jdstrandniemeyer: no, those are apparmor rules so label means the security label. ie snap.foo.bar18:54
niemeyerjdstrand: Okay, that's cool18:54
jdstrandI would want to add interface=org.gnome.Rhythmbox{.*} as well to those rules18:55
jdstrandand whether it is 'session' or 'system' of course18:56
niemeyerjdstrand: That sounds misnamed18:56
jdstrandniemeyer: as for 'api', yes, that I just tossed that out there for discussion18:56
jdstrandniemeyer: before we name it, do we want something like that at all?18:57
jdstrandniemeyer: there is precedence for something like that-- 'content' in the content interface18:57
jdstrandbut with content, it makes sense to have a tighter coupling18:57
jdstrandI'm less sure here (I'm on the fence)18:58
niemeyerjdstrand: Maybe.. we need a way to tell that we're connecting the proper plug to the proper slot18:58
jdstrandthat's true18:58
niemeyerjdstrand: This may be done either explicitly, as in content, or it may be done implicitly based on existing metadata18:59
niemeyerjdstrand: dbus already has such a concept internally18:59
jdstrandwith this for plugs:19:00
jdstrandplugs:19:00
jdstrand  rhythmbox:19:00
jdstrand    interface: dbus-app19:00
jdstrandif rhythmbox had two dbus-app slots, I don't think there is enough implicitly19:00
jdstrandnow, the plugs side doesn't have to be that simple19:01
jdstrand(but that is how it is in my comment)19:01
jdstrandso that is getting me to like this explicit name19:02
jdstrandwere you thinking of something else for implicit?19:02
niemeyerjdstrand: Yes, dbus itself has resolution logic19:03
niemeyerjdstrand: It has exactly the same problem internally, right?19:03
niemeyerjdstrand: The client needs to talk to the server and they both need to know what they're talking about19:03
jdstrandyes19:04
niemeyerjdstrand: As there are many objects and many interfaces under the same endpoint19:04
jdstrandniemeyer: so thinking maybe plugs side also has session and system?19:04
niemeyerjdstrand: 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 mismatching19:05
jdstrandniemeyer: and we just use the intersection?19:05
niemeyerjdstrand: 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 other19:05
jdstrandniemeyer: it does seem natural for someone that wants to talk over dbus to declare what they want to talk to, yes19:05
jdstrandniemeyer: yes, that makes sense19:06
jdstrandniemeyer: are you then advocating for having session and system on both slots and plugs, or something else?19:06
niemeyerjdstrand: There's also a related issue: we're not allowing the interfaces to specify a "path"19:06
jdstrandpath is tricky19:07
niemeyerWhy?19:07
jdstrandbecause people don't always use it consistently19:07
jdstrandI've seen a lot of applications just pick '/' as the path19:07
jdstrandmy goal is to not reinvent the apparmor language or dbus semantics in this area. maybe we have to, but ideally not19:08
niemeyerjdstrand: Ok, but that means the client needs to use that path too if it expects to interact, right?19:08
niemeyerjdstrand: Well, exactly.. I'm wondering if we can map it more closely instead of reinventing19:08
jdstrandniemeyer: I was thinking simply omit the path and rely on interface, bus name and security label19:08
niemeyerjdstrand: The code currently is doing "obj.path" => "obj/path", which is not what dbus does.. that's reinventing it19:09
niemeyerjdstrand: It's not omitting the path.. it's guessing it19:09
jdstrandeg: dbus bus=session interface=org.gnome.Rhythmbox{,.*} peer=(label=<the other side>)19:09
jdstrandwe just allow any path and member19:09
niemeyerjdstrand: Can the client tell what the remote path is?19:10
jdstrandwhich I think is fine. we want to allow the connection and not worry about carving out the apis19:11
niemeyerjdstrand: To some degree, yes19:11
jdstrandniemeyer: 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
niemeyerjdstrand: Can the client tell what the remote path is?19:11
niemeyerjdstrand: Ok.. so just to be clear, that's not what is being done ATM, right?19:12
jdstrandso, the client either has to know or there is dbus introspection19:12
jdstrandniemeyer: re done ATM> the code in the PR does not reflect any discussiosn after the initial submission as dbus-app, if that is your question19:13
niemeyerjdstrand: Ack19:13
niemeyerjdstrand: So.. brainstorming idea:19:14
jdstrandso, hoping to get the yaml nailed done and what that represents, then I can run with it19:14
jdstrands/done/down/19:14
niemeyerjdstrand: What if we stripped out the snap "dbus" (not dbus-app) interface to *one* interface19:14
jdstrandI'm not following19:15
niemeyerslots:19:16
niemeyer    my-dbus-interface:19:16
niemeyer        interface: dbus19:16
niemeyer        name: org.my.dbus.Interface19:16
niemeyer        bus: session19:16
niemeyerjdstrand: Consider the consequences..19:17
jdstrandin 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
mupBug #1642669 changed: Can't connect to SnapdLoginService from a snap <snapd-glib:Confirmed> <https://launchpad.net/bugs/1642669>19:18
jdstrandthen we have a clean way of connecting19:18
jdstranda thick snap could offer 10 things, and a plug could use just one of them19:19
jdstrand(if it wanted)19:19
jdstrandor 5 or all 1019:19
niemeyerjdstrand: Right, exactly19:19
niemeyerjdstrand: It also means we can have more fine-grained decisions about what is okay to auto-connect or not19:20
jdstrandthis could also be used to ease slot development in general for cases where we want to offer the entire api for a particular interface19:20
niemeyerjdstrand: and we don't need "api", as dbus already tells us that via these fields19:20
jdstrandeg, 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
jdstrandniemeyer: re not needing api> yes19:21
jdstrandniemeyer: I like it19:21
niemeyerjdstrand: 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:22
niemeyerjdstrand: Ah.. interestingly, these fields might be on the plug side only19:23
niemeyerjdstrand: The slot of course doesn't care19:23
niemeyerjdstrand: In the sense it offers it all19:23
jdstrandniemeyer: possible, yes (for all of this). I suspect if we are carving out bits like that we can continue to do a dedicated interface19:23
jdstrandbut, it is possible to move everything out to this once we learn more how people want to use it19:24
niemeyerjdstrand: 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 feature19:24
niemeyerjdstrand: I can imagine people wanting to simply keep using this for dbus, instead of having to create custom interfaces19:25
jdstrandI 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
jdstrandniemeyer: re imagine> yes, me too. I think it would be helpful19:26
niemeyerYeah, sound good19:26
niemeyerjdstrand: Okay, I think we have a plan19:26
jdstrandok, I'll summarize it and get this going19:27
jdstrand(summarize in the PR)19:27
jdstrandniemeyer: thanks!19:27
niemeyerjdstrand: np, and thanks as well19:28
SciVisionI 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:33
SciVisionSorry 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:34
zygaSciVision: 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) account19:40
SciVisionok19:41
SciVisionthe keys not user name19:41
SciVisionzyga: Sorry on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ it says "ssh <Ubuntu SSO user name>@<device IP address>"19:45
SciVisionand I get Permission denied when I use my Ubuntu one account login id19:46
SciVisionzyga: Got it. Thanks19:48
jdstrandniemeyer: fyi, https://github.com/snapcore/snapd/pull/1613#issuecomment-261350004. I'm running with it. please let me know if I got something wrong19:49
mupPR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>19:49
Damianhi 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" error20:05
Damianany ideas on how to get past this?20:06
ahoneybunthanks for that update jdstrand20:21
jdstrandahoneybun: you're welcome20:22
ahoneybunjdstrand: I know Pithos will hit that issue later once I found out how to tell it to look in a space for a file20:22
ahoneybun*place20:22
* jdstrand nods20:23
cwaynehey guys, is there a way to allow a snap to auto-connect to an interface (in this case, log-observe)?20:43
ahoneybuncan I use filesets to fix this issue? : http://pastebin.ubuntu.com/23477531/21:45
ahoneybunGLib.Error: g-file-error-quark: Failed to open file '/share/pithos/pithos.gresource': open() failed: No such file or directory (4)21:45
ahoneybunthe .gresource is in /share/pithos21:45
ahoneybunso I need something like $SNAP I guess21:45
linuxhikerI 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)21:49
mupPR snapcraft#905 closed: Snap revision prune <Created by seawaywen> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/905>23:02
mupPR snapcraft#914 closed: meta: icon is now dedeprecated <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>23:05
mupPR snapcraft#915 opened: cache: cleanup logic to pass project name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/915>23:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!