[01:05] <numa> hola! how to install snapd on centos-7 ?
[01:06] <sergiusens> elopio do we have a bug for register
[01:07] <Son_Goku> numa, you don't yet
[01:08] <Son_Goku> zyga didn't enable EL7 in his Copr: https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
[01:08] <numa> Son_Goku: womp womp... thanks :)
[01:09] <elopio> sergiusens: we have one for upload without register. That's what I was trying to say in the standup. I'll file a new one.
[01:36] <sergiusens> elopio to late, but feel free to make it bug sru friendly
[01:56] <ddellav> im having an issue running the snapcraft tour. I installed the hello snap i created but the "hello" command is not available. I get command not found in zsh and in bash it suggests I install hello or hello-traditional
[01:56] <ddellav> im running xenial
[02:00] <elopio> ddellav: hello. What if you run /snap/bin/hello ?
[02:00] <ddellav> elopio i get: failed to create user data directory. errmsg: Permission denied
[02:00] <ddellav> should i use sudo?
[02:02] <elopio> ddellav: no, you shouldn't. Maybe, your user directory is not in /home ?
[02:02] <ddellav> elopio pwd = /home/david/snapcraft-tour/00-SNAPCRAFT/01-easy-start
[02:03] <elopio> ddellav: so, maybe your home is encrypted ?
[02:04] <ddellav> elopio hmm, i may have selected that when I first installed months ago but right now it's in use so it's not currently encrypted or doesn't that matter
[02:05] <elopio> ddellav: I'm asking those questions because those are the two bugs open that print your error. The encrypted home is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
[02:06] <qengho> Hmm. I have ecryptfs home.
[02:06] <elopio> ddellav: can you check your /var/log/syslog to confirm that?
[02:07] <ddellav> elopio yes i see in the bug report there's a workaround for apparmor
[02:07] <ddellav> and this is in my syslog: Jun 21 22:00:22 loki kernel: [ 1626.709398] audit: type=1400 audit(1466560822.050:49): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/david/.Private/" pid=17745 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[02:07] <elopio> ddellav: the bug says fix released, so maybe first try to upgrade before applying the workaround
[02:07] <ddellav> elopio i actually just installed snap and snapcraft less than an hour ago
[02:07] <ddellav> so perhaps it's not published yet
[02:08] <ddellav> or maybe i need to modify my repos
[02:08] <elopio> ddellav: the bug is not in snapd, it's in ubuntu-core-launcher. So there's still a chance that you have an old one. Or it hasn't been published. Or the bug is still open :)
[02:09] <ddellav> elopio gotcha, well thanks for the direction, at least i know im not crazy now :)
[02:11] <elopio> ddellav: np. Welcome to the snappy world. Please let us know if you have any other problems.
[02:11] <ddellav> will do
[02:12] <qengho> ddellav: If you're feeling brave, you can work around it pretty easily and not wait for the release that fixes it for everyone.
[02:12] <ddellav> qengho yea, im messing with the apparmor stuff now heh
[02:12] <ddellav> i might just disable it entirely if this doesn't work
[02:17] <qengho> ddellav: In /etc/apparmor.d/usr.bin.ubuntu-core-launcher, near "@{HOME}/snap/{,*/,*/*/} rw,", add a new line "/home/.ecryptfs/david/.Private rw," and then "apparmor_parser -r /etc/..." to reload it.
[02:17] <qengho> It's not the Right Way, but it will get you to a place you can play.
[02:22] <ddellav> qengho for some reason that didn't work but i just copied and pasted the apparmor changes from the bug report and that seemed to do it
[02:22] <ddellav> and now i get: Hello, world!
[02:22] <ddellav> woot
[02:29] <ddellav> now I have to figure out why it wont run when i just to use the command
[02:29] <ddellav> i guess somewhere along the line my path wasn't updated or something
[02:34] <qengho> Hrm. I have a snap with a service that has been installed many times. Runs well. Just installed on new 2.0.9 armhf machine. There is no systemd "service" for it. $ systemctl |grep tor-middle-relay.*service  #shows nothing on new machine
[02:36] <tsimonq2> elopio: you said you would look at my PR again?
[02:36] <qengho> ddellav: On snapd install, log-in profile is updated, so no visible until next shell init. Try "bash -l".
[02:36] <ddellav> qengho yea, no dice :(
[02:37] <qengho> ddellav: Try ". /etc/profile"
[02:37] <ddellav> i dont see any modifications to .profile or .bashrc so maybe it failed because of the apparmor problem
[02:37] <qengho> ddellav: it would never touch personal files. :)
[02:38] <ddellav> qengho . /etc/profile works but it puts me into a prompt with only a $
[02:39] <qengho> ddellav: What shell do you use?  $ echo $SHELL
[02:39] <ddellav> qengho zsh
[02:39] <qengho> ddellav: you alien!
[02:40] <ddellav> lol
[02:40] <ddellav> i tried it with bash too and it didn't work. When i did bash -l it still didn't include the path
[02:41] <ddellav> this is obviously a config issue on my side. I must not be including the system wide config somehow
[02:41] <qengho> ddellav: $ grep PATH= ~/.??*
[02:42] <ddellav> ah ha
[02:42] <ddellav> that was it
[02:42] <ddellav> the .zshrc was not including the existing $PATH
[02:43] <ddellav> eh, now i've got a bunch of duplicated directories in my $PATH
[02:43]  * ddellav sighs
[02:44] <ddellav> ok, i did away with setting the path in zsh altogether
[02:44] <ddellav> thanks qengho for getting me squared away
[02:44] <qengho> Welcome!
[02:57] <qengho> (Incidentally, I found my problem is same as LP: #1584456)
[02:57] <ddellav> i may be asking this too quickly, im still going through the tour and learning but it looks like  snaps have built-in plugs for things like make, node, python, etc. Is there any way to add plugins? For something like composer perhaps?
[02:58] <qengho> ddellav: A plugin is only for building things. And you can add your own, yes, in parts/plugins/x-ddellavsomething.py
[02:59] <ddellav> qengho yes, i want to try to build a snap package for a project i run which is currently using composer so it would be awesome to package that together as a composer install is an annoying process
[02:59] <ddellav> requiring a curl bang
[02:59] <qengho> I don't know "composer".
[02:59] <ddellav> it's npm for php
[02:59] <qengho> tld?
[03:00] <qengho> tla. Ugh.
[03:00] <ddellav> sorry, node package manager
[03:00] <ddellav> composer is a package manager for php apps
[03:00] <ddellav> similar to pip as well. instead of requirements.txt you have a composer.json
[03:01] <qengho> ddellav: okay. Sure. Beware that it might not make sense, unless it's installing packages inside its $SNAP_DATA dir. Snap programs can't write just anywhere.
[03:02] <ddellav> qengho i think it will work as intended but we shall see
[03:02] <qengho> :)
[03:02] <ddellav> eventually I want to try to get snaps working for openstack packages as well
[03:02] <ddellav> though that will be a much larger job lol
[06:33] <slangasek> zyga: FYI snap-confine 1.0.33-1 has been uploaded to the Debian NEW queue now (will at some point show up at https://ftp-master.debian.org/new.html); Vcs-Git moved to git://anonscm.debian.org/collab-maint/snap-confine.git
[07:05] <zyga> slangasek: \o/ thank you
[07:05] <zyga> slangasek: did you do the dpkg-vendor thing you mentioned?
[07:05] <zyga> mvo: ^^ FYI
[07:08] <mvo> zyga: in what way are we using a different configuration? just curious
[07:09] <hamiltino> i have a .snap file, any know how to install it?
[07:11] <zyga> hamiltino: sudo snap install ./path/to/that/snap
[07:11] <zyga> mvo: debian doesn't have all the confinement bits enabled
[07:12] <zyga> mvo: but snap-confine unlike snapd does a compile-time decision
[07:12] <zyga> mvo: slangasek propsed using dpkg-vendor to configure snap-confine differently on ubuntu
[07:13] <hamiltino> i get: cannot read snap file: cannot open snap: unknown header: "!<arch>\ndebian-binar
[07:13] <zyga> hamiltino: that's a snap from 15.04
[07:13] <zyga> hamiltino: that snap won't run on 16.04 system, you have to rebuild it
[07:15] <zyga> dholbach: good morning
[07:20] <hamiltino> can a 16.04 snap work on a 15.04 system?
[07:20] <zyga> hamiltino: no
[07:21] <zyga> hamiltino: you would have to rebuild it from source
[07:21] <zyga> hamiltino: the format changed significantly
[07:30] <dholbach> hey zyga
[08:33] <tsimonq2> mvo: could you take a minute to test my Mutt snap please?
[08:44] <mvo> tsimonq2: I get http://paste.ubuntu.com/17686195/ at the end - i woder if a fakeroot somewhere is missing
[08:46] <mvo> tsimonq2: i.e. I think "chmod 2755 /tmp/mutt/parts/mutt/install/bin/mutt_dotlock" needs to be run via fakeroot, maybe its fine to run the entire build with fakeroot even
[08:48] <tsimonq2> mvo: what's fakeroot? :)
[08:50] <mvo> tsimonq2: its a clever program that makes build systems believe they are running as root :)
[08:51] <mvo> tsimonq2: "apt show fakeroot" has some more info
[08:51] <mvo> tsimonq2: ha! fakeroot snapcraft makes it work
[08:52] <mvo> tsimonq2: and it works, how neat!
[08:53] <mvo> tsimonq2: hm, almost
[08:55] <tsimonq2> 03:51:24 AM < mvo> tsimonq2: ha! fakeroot snapcraft makes it work
[08:55] <tsimonq2> 03:52:15 AM < mvo> tsimonq2: and it works, how neat!
[08:55] <tsimonq2> 03:53:47 AM < mvo> tsimonq2: hm, almost
[08:55] <tsimonq2> whoops
[08:55]  * tsimonq2 kicks his terminal
[08:56] <mvo> tsimonq2: it does work
[08:56] <mvo> tsimonq2: it is just a bit confused because ubuntu-core-launcher changes HOME
[08:56] <tsimonq2> Qterminal has this nice "Paste selection" function that is really awesome, except in IRC :P
[08:56] <tsimonq2> anyways
[08:57] <mvo> tsimonq2: so yeah, run `fakeroot snapcraft` and its there :)
[08:57] <zyga> tyhicks`, jdstrand: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1595092
[08:58] <tsimonq2> mvo: so I should leave a note that snapping it should be done with fakeroot?
[09:00] <didrocks> I think you need to change the build system to have it running under fakeroot
[09:00] <didrocks> or you will never be able to get it build under builders
[09:00] <didrocks> for instance
[09:01] <didrocks> so, I think it's something about have "make" replaced with "fakeroot make" and adding a build-packages: [fakeroot]
[09:04] <tsimonq2> didrocks: so I might just write a custom plugin that just takes the autotools plugin and puts fakeroot in front of make and make install, that might work
[09:04] <tsimonq2> right?
[09:06] <didrocks> tsimonq2: yeah, if you can inherit from the autotools plugin, and even, maybe patch is to make is more generic so that your custom plugin is just a 3 or so lines… :)
[09:07] <tsimonq2> :)
[09:11] <mvo> tsimonq2: yeah
[10:18] <ePierre> didrocks, hi!
[10:18] <ePierre> didrocks, I saw your e-mail on the snapcraft ML quoting https://lists.ubuntu.com/archives/snapcraft/2016-June/000235.html
[10:18] <ePierre> didrocks, so the Ubuntu store will support devmode-snaps?
[10:19] <zyga> ePierre: yes
[10:20] <didrocks> indeed
[10:20] <ePierre> zyga, didrocks but isn't devmode... well, for developers/testers only? :D
[10:20] <didrocks> be aware about the restriction on the stable channel
[10:20] <didrocks> and people will have some warnings if installing devmode snaps from another channel
[10:21] <didrocks> this will help you to distribute to testers :)
[10:21] <ePierre> didrocks, ok I see! Thanks
[10:21] <didrocks> yw ;)
[10:49] <willcooke> didrocks, should I be able to write to $SNAP_DATA if I run bash in my launcher script instead of the actual application binary?
[10:51] <willcooke> e.g. qt5-launch bash
[10:51] <willcooke> $ touch $SNAP_DATA/hello
[10:52] <joc_> willcooke: pretty sure SNAP_DATA is only writable by root
[10:52] <willcooke> joc_, that ties in with what I'm seeing, thanks
[10:54] <didrocks> yep, only root can write to it
[10:58] <ogra_> willcooke, you want $SNAP_USER_DATA
[10:59] <willcooke> got it
[10:59] <ogra_> also use /bin/sh ... there is no guarantee that bash will stay in the core snap
[10:59] <willcooke> ack
[11:01] <matteo> zyga: it was a CDN issue!
[11:46] <gouchi> hi
[11:46] <zyga> hey
[11:46] <gouchi> any update on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860 ?
[11:47] <gouchi> To make some test I can try to edit snapd interface rules ?
[11:49] <gouchi> https://github.com/snapcore/snapd/tree/master/interfaces/builtin in here ?
[11:54]  * zyga looks
[11:54] <zyga> gouchi: you can help, for sure :)
[11:55] <zyga> what is the actual device that is being accessed?
[11:55] <zyga> is that a GPU or some other thing?
[11:59] <gouchi> zyga: same as /run/udev/data/cXX so related to gamepad and joystick
[12:00] <jdstrand> zyga: I'm pretty sure that was an active decision (setgroups). I'll let tyhicks` comment cause I think he and sarnold reviewed that code
[12:01] <jdstrand> qengho: you mentioned bug #1584456 as your problem. Can you sync with tyhicks` when he comes online (he was looking at that)
[12:01] <ogra_> hmm, wasnt the /dev/shm fix in snapd 2.0.9 ?
[12:02]  * ogra_ still sees it with the package from proposed
[12:02] <jdstrand> what fix are you referring to?
[12:02] <zyga> jdstrand: thanks
[12:02] <ogra_> jdstrand, chromium based apps need it
[12:02] <zyga> jdstrand: please keep this in the bug report there, it will be referenced by other packaging systems
[12:03] <ogra_> i thought there was a fix in the works for it
[12:03] <jdstrand> ogra_: not for chrome
[12:03] <ogra_> to treat it like /tmp
[12:03] <jdstrand> not for chrome
[12:03] <ogra_> hmm, k
[12:03] <jdstrand> there was a fix that allows snaps to have access to stuff in /run/shm
[12:03] <ogra_> olli__, pinging again for putting back the bug links into the topic :)
[12:04] <jdstrand> but chrome needs to modify its path to do that
[12:04] <ogra_> right, but i only have a binary for the app
[12:04] <jdstrand> or someone needs to write the preload library that is in the bug
[12:04] <jdstrand> olli__: hence the 'not for chrome' :)
[12:04] <ogra_> and by default all chromium wrapped apps use /dev/shm/.XXXXX
[12:05] <jdstrand> I've talked to upstream. there is a bug on this. there is a plan if upstream doesn't change. I don't think anyone is assigned to that bug
[12:05] <ogra_> jdstrand, well, the app is based on chromium, not chrome ...
[12:05] <jdstrand> same difference
[12:05] <ogra_> (i dont have the source for the wrapper bit thoough)
[12:05] <ogra_> ok
[12:06] <jdstrand> there appears to not be consensus if snapcraft should own that library or snapd. so no one is working on it. iirc, zyga has some poc code
[12:06]  * jdstrand is just reporting the issue and is not working on that
[12:06] <ogra_> yeah
[12:06] <jdstrand> mvo: hi, are you in charge of snapd 2.0.10 release? I ask cause I think it is very important that mpris interface is in 2.0.10
[12:09] <mvo> jdstrand: I can wait for this to land
[12:09] <mvo> jdstrand: 2.0.9 is not in updates yet, I am chasing this right now
[12:11] <jdstrand> zyga: do you have a moment to talk about your mpris comment?
[12:13] <jdstrand> pindonga (cc noise][1): hey, can you sync r680 to the store for home autoapprove? (fyi niemeyer1)
[12:14] <jdstrand> morphis, nessita: hey-- I see a bunch of bluez packages in the store. 4 from 20 days ago and 2 from 5 months ago. nessita since you are up on this issue, would you mind handling the store review?
[12:15] <nessita> jdstrand, the bluez package was moved from a private store to the public store, maybe that's why is showing now?
[12:17] <jdstrand> nessita: that's my guess, but I'd rather not guess in the review and let someone close to the issue have a look :)
[12:18] <jdstrand> nessita: unless you tell me its fine, then I'll just push approve
[12:19] <nessita> jdstrand, let me check
[12:22] <morphis> jdstrand, nessita: the ones from 20 days ago should be the current ones
[12:22] <morphis> jdstrand, nessita: but maybe we should drop those and let me redo the upload process to get everything into a sane state
[12:22] <zyga> jdstrand: yes
[12:23] <zyga> jdstrand: let's talk about mpris
[12:23] <nessita> morphis, I was going to ask, the failures i was seeing from the review process do not seem harmless
[12:23] <zyga> jdstrand: we can also talk about the shm thing next
[12:23] <zyga> jdstrand: I'd like someone to own that thing
[12:24] <nessita> morphis, if you confirm
[12:24] <nessita> reserved interface 'bluez' for vetted applications only security-snap-v2_plug_safe (client, bluez)
[12:24] <zyga> attente_: hey, where are the patches required for gnome-software to install snaps?
[12:24] <nessita> morphis, is OK I can approve those
[12:24] <jdstrand> nessita: that's fine. it came from Canonical
[12:24] <morphis> nessita: let me have a quick look
[12:25] <jdstrand> zyga: I left a comment in the mpris PR for you
[12:25] <nessita> jdstrand, right, so your doubt was mainly about those appearing now (all the sudden)
[12:25] <jdstrand> nessita: yes
[12:26] <morphis> jdstrand, nessita: https://myapps.developer.ubuntu.com/dev/click-apps/3595/rev/9/ should be the latest one
[12:27] <attente_> zyga: it's on this branch at git.gnome.org: https://git.gnome.org/browse/gnome-software?h=wip/ubuntu-xenial
[12:28] <morphis> nessita: just one quick thing, can I migrate a snap in the store to another channel?
[12:28] <zyga> attente_: is that heading upstream?
[12:29] <nessita> morphis, yes, just click the "Edit" link next to the channels line in a revision details page
[12:29] <morphis> nessita: ok, done
[12:30] <nessita> morphis, so we should approve revision 9 and reject 3 to 8?
[12:30] <morphis> nessita: for bluez, yes
[12:30] <nessita> on it
[12:30] <mvo> jdstrand: if you could have a look at https://github.com/snapcore/snap-confine/pull/43 that would be great! part of the new content-sharing work
[12:31] <jdstrand> mvo: my plan was to move to content sharing after mpris. mpris is almost done. does that work for you? iirc, both of these are for 2.0.10///
[12:31] <morphis> nessita: and for network-manager it is https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/
[12:32] <jdstrand> mvo: oh, actually, I think tyhicks` may want to look at that particular PR. iirc, he had some thoughts on parsing mountpoints
[12:32] <zyga> jdstrand: we've used his idea (glibc parser)
[12:33] <zyga> jdstrand: FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=986050
[12:33] <zyga> jdstrand: that bug is about auditing snap-confine so that it can be setuid root
[12:33]  * jdstrand nods
[12:34] <jdstrand> zyga: did you see my comment in the mpris PR?
[12:34] <zyga> jdstrand: no, let me refresh
[12:34] <jdstrand> zyga: also, the continuous integration test is failing for something unrelated to the PR AFAICS
[12:34] <nessita> morphis, this is the final mapping https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/
[12:35] <attente_> zyga: i don't think robert proposed it yet, but i assume it'll apply upstream
[12:35] <zyga> attente_: is robert going to work on that?
[12:35] <nessita> jdstrand, so bluez is no handled. For network-manager, I'm unsure about approving https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/
[12:35] <nessita> a couple of unknown interfaces there
[12:36] <zyga> jdstrand: ok, let's talk about mpris now; my reasoning was that since unity provides one of the mpris elements (the controller) it would gain an implicit slot so that players could auto-connect to it (on classic)
[12:37] <jdstrand> nessita:  i can do the nm review. there might be a tooling issue
[12:37] <zyga> jdstrand: the actual sides are somewhat arbitrary IMHO (unless I'm missing something) and it could be either a plug or a slot equally well
[12:37] <zyga> jdstrand: for the slot it would be easier to support since the code in snap/implicit.go only adds implicit slots today
[12:37] <morphis> nessita: now I see what I did, we have to publish rev 5-8 for bluez too, those are the other architectures
[12:37] <zyga> jdstrand: but if you feel strongly about it I could extend it to handle implicit plugs as well
[12:38] <jdstrand> zyga: my mental map is that a slot provides something for things to use. flipping it in this manner is confusing to me. also, I allow, on classic, for unconfined to control the player
[12:38] <jdstrand> I think it sounds weird to connect to a remote
[12:38] <jdstrand> I think a remote connects to a player
[12:39] <nessita> morphis, ok, let me see if I can approve the one I already rejected ;-)
[12:39] <zyga> jdstrand: you assume people know what mpris is :)
[12:39] <zyga> jdstrand: for me it is the thing in the top-right corner, in the sound menu
[12:39] <morphis> nessita: :-)
[12:39] <jdstrand> I read the spec-- I picked the sides that seemed to best work with it
[12:39] <zyga> jdstrand: while I simplify, I doubt many people know what that stands for and which side is which
[12:39] <zyga> jdstrand: but users will be used to connecting plugs to slots on the classic core snap
[12:40] <zyga> jdstrand: again, this is all a "feeling" observation, I'm fine with it being a plug too, it just needs more work
[12:40] <jdstrand> zyga: note that vlc doesn't show up in indicator sound at this time. also note, that people don't have to do anything on classic for it to work. on classic, I add rules that let's unconfined connect
[12:40] <jdstrand> actually, I may need to adjust where I do that now that we are talking about it
[12:40] <zyga> jdstrand: hmm
[12:41] <zyga> jdstrand: I think it should still be a connection, let me check what you wrote there again
[12:41] <nessita> morphis, does this look OK? https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/
[12:41] <zyga> jdstrand: (so that when you disconnect it shouldn't be possible to control)
[12:42] <jdstrand> zyga: I think this is the main point-- how to let unconfined control the player
[12:42] <morphis> nessita: checking
[12:42] <jdstrand> zyga: in my mind, unconfined should be able to control it without a connection (it is unconfined)
[12:42] <zyga> jdstrand: hmmm
[12:42] <zyga> jdstrand: I think this is not intuitive though perhaps this is just my pov
[12:42] <jdstrand> zyga: this is not about giving vlc something, it is about giving something else access to vlc
[12:43] <zyga> jdstrand: it would be more interesting if we had two snaps here
[12:43] <zyga> jdstrand: (controller and player)
[12:43] <jdstrand> the player side just screams slot to me
[12:43] <jdstrand> zyga: I implemented that locally
[12:43] <jdstrand> mpris-client is a controller
[12:43] <zyga> jdstrand: so dbus-wise, the player is a dbus service that stuff talks to
[12:43] <jdstrand> zyga: yes
[12:43] <jdstrand> like bluez
[12:44] <jdstrand> like location-service
[12:44] <zyga> jdstrand: still, with this I would expect to have control over which controller can actually talk to my player
[12:44] <jdstrand> therefore, it seemed naturally a slot
[12:44] <jdstrand> zyga: you do :)
[12:44] <zyga> jdstrand: but perhaps this is a gray area
[12:44] <zyga> jdstrand: (including unconifned unity)
[12:44] <jdstrand> snap connect mpris-client:mpris vls:mpris
[12:44] <jdstrand> that is the point
[12:44] <zyga> jdstrand: but I cannot disconnect the classic one
[12:44] <morphis> nessita: hm, rev 8, 7, 6, 5 should be published for all channels
[12:45] <jdstrand> if we want to put unconfined into that limitation
[12:45] <jdstrand> I would argue we do not
[12:45] <jdstrand> on classic we let snaps talk to unconfined. no reason we can't let unconfined talk to snaps on classic
[12:46] <zyga> jdstrand: why cannot that be explicit rather than implicit?
[12:46] <jdstrand> it could be. I just don't think that is particularly useful
[12:46] <zyga> jdstrand: btw, can a single player be sensibly controlled by many controllers?
[12:47] <jdstrand> zyga: I don't see why not. It is just hitting dbus API
[12:47] <jdstrand> play/pause
[12:47] <jdstrand> ff
[12:47] <jdstrand> rew
[12:47] <jdstrand> it is simple
[12:47] <zyga> jdstrand: ok
[12:47] <zyga> jdstrand: so we don't need a plug on the core snap
[12:48] <jdstrand> zyga: I'll put this another way. let me move the classic code to a permanent plug for now, with comment saying we may revisit this in the future?
[12:48] <zyga> jdstrand: as there's no connection really
[12:48] <jdstrand> we do on the core snap
[12:48] <jdstrand> we need a controller snap
[12:48] <zyga> hmm
[12:48]  * zyga is tired, sorry let me re-read the code
[12:48] <zyga> jdstrand: if there's a plug we have to patch snapd to create the plug
[12:48] <zyga> jdstrand: currently it only creates slots
[12:49] <jdstrand> zyga: note that as written, the unconfined OnClassic bit is in the wrong place. I am describing here that it should be in permanent plug conditionally OnClassic
[12:49] <jdstrand> zyga: on core, this operates exactly like bluez
[12:49] <jdstrand> zyga: if a player that slots mpris is not installed, nothing to connect to
[12:51] <jdstrand> zyga: it just happens that it operates very similarly on classic. there is no implicit slot. a remote must control a player. the only difference is that what I'm proposing is that on classic we allow unconfined to control the player snap unconditionally
[12:51] <jdstrand> zyga: as implemented, we do not handle a snap that is a remote to control an unconfined player. that could be a future improvement
[12:52] <nessita> morphis, you can edit that yourself
[12:52] <zyga> jdstrand: ah, ok
[12:52] <morphis> nessita: without republishing? let me check ..
[12:52]  * zyga reads the diff carefully
[12:54] <nessita> morphis, when you change the channels the update propagates automatically to the index
[12:54] <morphis> nessita: I see, thanks
[12:54] <nessita> np
[12:55] <jdstrand> meh, I said I need to move mprisConnectedSlotAppArmorClassic to connected plug earlier here. I meant conditionally add it to mprisPermanentSlotAppArmor
[12:55] <morphis> nessita: did you approve network-manager too?
[12:55] <jdstrand> zyga: ^
[12:55] <nessita> morphis, jamie is with that one
[12:56] <morphis> nessita: aye!
[12:56] <nessita> o/
[12:56] <jdstrand> morphis: there are a number of weird errors with nm. not sure if that is a review tools bug or something else.
[12:57] <jdstrand> nessita: if we assume that those are review tools bugs, nm would be ok to approve? (ie, you've confirmed this is just a normal review and not something to treat special?)
[12:57]  * zyga goes to a meeting
[12:57] <zyga> jdstrand: let's continue this soon
[12:57] <jdstrand> zyga: let me move mprisConnectedSlotAppArmorClassic while you are in the meeting
[12:58] <zyga> OK
[12:58] <zyga> Thank you
[12:58] <jdstrand> then you can see what I actually mean
[12:58] <nessita> jdstrand, hum, no, I haven't confirmed anything other than I moved the existing nm from a private store to the ubuntu store
[12:58] <morphis> jdstrand: what exactly?
[12:58] <nessita> jdstrand, let me run the review tools again, with the latest version
[12:59] <jdstrand> nessita: that is the bit I'm talking about. that move is all correct, right?
[12:59] <jdstrand> nessita: ah, if you run the review tools again, it might look better
[12:59] <nessita> yeah, let me try
[13:00] <nessita> jdstrand, just ran it for revision 10, using
[13:00] <nessita> 678 click-reviewers-tools version
[13:00] <nessita> the same 3 failures
[13:00] <nessita> jdstrand, the move from one store to the other is as correct as I can possibly make it :-)
[13:01] <jdstrand> nessita: all I need answered is that the move worked right and it is in the right spot
[13:01] <jdstrand> ok, cool
[13:01] <jdstrand> then I'll look at that in a moment
[13:02] <nessita> jdstrand, the move worked right and is in the right spot. Thank you!
[13:09] <jdstrand> morphis: ok, this is what you have:
[13:09] <jdstrand> apps:
[13:09] <jdstrand>   networkmanager:
[13:10] <jdstrand>     slots:
[13:10] <jdstrand>     - service
[13:10] <jdstrand> slots:
[13:10] <jdstrand>   service: network-manager
[13:10] <jdstrand> morphis: (and you do something similar for plugs)
[13:10] <morphis> jhodapp: yeah, whats wrong with that?
[13:10] <jdstrand> morphis: based on the specification, that should be:
[13:10] <jdstrand> slots:
[13:11] <jdstrand>   service:
[13:11] <jdstrand>     interface: network-manager
[13:11] <jdstrand> unless the code has evolved beyond the spec
[13:11] <morphis> jdstrand: service: network-manager is the short form of this which snapcraft allows you
[13:12] <jdstrand> why do we have so many short forms...
[13:12] <jdstrand> morphis: I'm curious why you chose this format over:
[13:12] <jdstrand> apps:
[13:12] <jdstrand>   networkmanager:
[13:12] <jdstrand>     slots: [ network-manager ]
[13:12] <jdstrand> and skip the toplevel slots and plugs
[13:13] <morphis> because that would then not give the user any hint of what he connects
[13:13] <morphis> with this he knows he connects "service" to "nmcli"
[13:15] <jdstrand> zyga: can you confirm that the top-level plugs and slots declaration here is valid: http://paste.ubuntu.com/17695654/
[13:15] <jdstrand> morphis: the other bit is: lib64/ld-linux-x86-64.so.2, usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service lint-snap-v2_external_symlinks
[13:16] <jdstrand> morphis: those are going to dangle and may indicate a problem with the snap
[13:16] <jdstrand> zyga: nm, I see it now in the spec
[13:17] <jdstrand> morphis: I'll fix the tools for that abbreviated format
[13:18] <zyga> almost done with the meeting
[13:26] <jdstrand> zyga: ok, refresh and you can more easily see what I'm talking about
[13:34] <morphis> jdstrand: I have a MP for that one to fix, can we upload with or should I push the fix first?
[13:41] <jdstrand> morphis: if it is in progress, I'll just approve for now and you can fix in your next upload
[13:42] <jdstrand> morphis: can you request a manual review?
[13:42] <sergiusens> kyrofa the ros test fails consistently now :-/
[13:42] <kyrofa> sergiusens, what the heck...
[13:43] <kyrofa> elopio, have you managed to make any progress in downloading that stuff?
[13:43] <sergiusens> kyrofa I say consistently in a 2 out of 2 test, I am not lying but my population is too small for it to be meaningful ;-)
[13:44] <kyrofa> sergiusens, hahaha
[13:44] <sergiusens> kyrofa is this the error you see http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1153/testReport/junit/demos_tests.test_ros/ROSTestCase/test_ros/
[13:44] <sergiusens> kyrofa that comes out of this btw https://github.com/ubuntu-core/snapcraft/pull/574 which cannot be related :-P
[13:45] <kyrofa> sergiusens, yeah that's it
[13:45] <kyrofa> ROS, you sadden me
[13:46] <kyrofa> sergiusens, I'll investigate as soon as elopio is able to pull stuff off of it. Tests pass locally, manual tests pass on the jenkins machines... something must be going on in the test infrastructure somewhere
[13:46] <sergiusens> kyrofa I bet we just run out of RAM
[13:46] <morphis> jdstrand: will do
[13:46] <kyrofa> sergiusens, that's an interesting theory. What makes you say that?
[13:47] <kyrofa> sergiusens, it doesn't look like an enomem, it looks like a garbled file
[13:47] <sergiusens> kyrofa it only happens sometimes, it is either RAM or load; running out of files to create is another one; not sure how performant these machines are. But I've seen many random errors happen when RAM gets low
[13:48] <sergiusens> kyrofa you know how people do those malloc checks, right? ;-)
[13:48] <kyrofa> sergiusens, heh, fair point
[13:48] <kyrofa> sergiusens, admittedly the only time I did was for ubuntu core launcher :P
[13:55] <morphis> jdstrand: requested for rev 8, 9 and 10
[13:58] <dholbach> davidcalle, mhall119, popey: I started work on https://github.com/ubuntu/snappy-playpen/wiki/Examples - what do you generally think? more detail? better overview of chapters? (I'll add much more content to it...)
[14:00] <jdstrand> nessita: fyi, I approved the nm snaps, but there was a server error for each of r8, r9 and r10. Eg, for r8: OOPS ID: OOPS-26f562e1911f49328a44c89c8924d65c
[14:01] <jdstrand> Sentry ID: 9c66fdb409bf4131985225e707017749
[14:01] <jdstrand> morphis: fyi, I approved all of them. I think you have to manually publish (at least for r10)
[14:02] <nessita> jdstrand, let me check
[14:03] <morphis> nessita, jdstrand: clicking publish gives me an "Server Error"
[14:03] <nessita> morphis, yeah, there are issues in our code with the interfaces
[14:03] <nessita> something is not right, let me follow up
[14:03] <jdstrand> the web interface indicates it was published
[14:03] <jdstrand> (now, it didn't before)
[14:03] <nessita> jdstrand, but that may not be true, actual publishing is in an async task
[14:04] <jdstrand> nessita: also, I'm looking at the comment history and I left comments in all three, but I don't see them
[14:05] <nessita> jdstrand, that was before the oops?
[14:06] <nessita> jdstrand, I mean, did you write the comment, hit approve and you got the oops?
[14:06] <jdstrand> nessita: yes
[14:06] <jdstrand> nessita: that was what I did for all three. same thing each time
[14:07] <nessita> jdstrand, so the comment was not stored because of the crash, let me unapprove those
[14:07] <jdstrand> nessita: if it helps, this is the comment for each: http://paste.ubuntu.com/17697843/
[14:07] <nessita> morphis, please hold publishing the revisions for nm until we debug server side
[14:08] <jdstrand> nessita: ok, at this point I'll hand off to you. feel free to approve with that pastebin comment
[14:08] <nessita> jdstrand, will do, thank you!
[14:08] <jdstrand> np
[14:10] <popey> dholbach: i like
[14:10] <morphis> nessita: aye!
[14:12] <dholbach> popey, so nothing you'd change apart from adding more stuff to it?
[14:12] <popey> yeah, that's exactly the kind of thing I'd be looking for
[14:12] <dholbach> cool
[14:13] <kyrofa> sergiusens, I have a python question
[14:14] <kyrofa> sergiusens, I have a PYTHONPATH that contains two packages. I can import one, but not the other. How do I figure out what's wrong?
[14:17] <jdstrand> mvo: fyi, tyhicks` will look at https://github.com/snapcore/snap-confine/pull/43/files
[14:17] <mvo> ta
[14:18] <jdstrand> mvo: would you mind looking at https://travis-ci.org/snapcore/snapd/jobs/139481053 ?
[14:18] <jdstrand> mvo: this is a spread testsuite failure that seems unrelated to my mpris PR
[14:19] <elopio> sergiusens: do you want to give this a try? https://github.com/elopio/snapcraft/blob/launchpad_scripts1/scripts/launchpad/add_series.py
[14:19] <jdstrand> mvo: mostly I just want to know if this issue is known
[14:20] <kyrofa> jdstrand, yes, it's known
[14:21] <kyrofa> jdstrand, https://github.com/snapcore/snapd/pull/1382/files/7ceced8912257c2468003c1eb7554f4018e3ea81#r68051608
[14:21] <kyrofa> jdstrand, looks like some PRs landed in the wrong order
[14:22] <jdstrand> mvo: beyond that mpris PR testsuite failure, I looked through all the content sharing stuff and it makes sense to me. using bind mounts means don't have to worry about updating the apparmor policy
[14:22] <kyrofa> Morning elopio!
[14:22] <jdstrand> kyrofa: ack, I'll merge again and see if it is resolved
[14:23] <jdstrand> hrmm, up to date
[14:23] <sergiusens> elopio thanks! Will try it soon
[14:23] <kyrofa> jdstrand, it's not fixed :(
[14:23] <jdstrand> ah, 1367 is not merged
[14:23] <jdstrand> gotcha
[14:23] <kyrofa> jdstrand, https://github.com/snapcore/snapd/pull/1367 needs to be... yeah
[14:24] <kyrofa> jdstrand, the PR page is a sea of red right now
[14:24] <sergiusens> kyrofa are your python packages properly setup?
[14:24] <elopio> hello kyrofa.
[14:25] <kyrofa> sergiusens, I assumed so. This is using the launchpadlib as a stage package, which pulls in lazr.restfulclient. I'm getting import errors for lazr
[14:25] <elopio> sergiusens: I tried on staging, but I don't have permission to try on production. If it works for you I will capture the milestone from an argument, and deduplicate. Then let me know what else you would like to have in the script.
[14:25] <jdstrand> mvo: it may also mean that binaries will just work since we have ix rules in apparmor policy for where the bind mounts are going to, assuming that the slot side is written to look for libraries in the right places
[14:26] <jdstrand> mvo: I made a couple teensy comments in the spec. with tyhicks looking at the PR, is there anything else you need to expedite this?
[14:27] <mvo> jdstrand: the spread failure looks like something for fgimenez :)
[14:27] <mhall119> sergiusens: have you had a chance to play anymore with my pantheon-mail snap?
[14:28] <mvo> jdstrand: thanks, I have a look into the spec now, I this work is on a good track, the review for snap-confine and then hopefully in the next couple of days this can land
[14:28] <sergiusens> mhall119 no sorry, rushing with commitments after a week of flu
[14:28] <jdstrand> mvo: cool, thanks! holler if you need me :)
[14:28] <mvo> jdstrand: will do, thanks !
[14:28] <jdstrand> ratliff: fyi, ^
[14:28] <mhall119> dholbach: I think it could use some more explanation of what the use case is that the example is showing, and how the individual parts of the example support it
[14:28] <sergiusens> mhall119 I will need to spend a complete evening on this one (pkg-config)
[14:28] <kyrofa> sergiusens, here: http://pastebin.ubuntu.com/17698671/
[14:28] <jdstrand> ratliff: (content sharing)
[14:29] <mhall119> sergiusens: when you do, give me a ping and I'll go through it with you
[14:29] <kyrofa> sergiusens, both folders have an __init__.py, both are in the pythonpath
[14:30] <kyrofa> sergiusens, or does the lazr directory also require an __init__.py?
[14:30] <sergiusens> kyrofa can you import lazr directly?
[14:30] <sergiusens> kyrofa all packages require one
[14:30] <kyrofa> sergiusens, no, same problem with `import lazr` or `import lazr.restfulclient.resource`
[14:31] <kyrofa> sergiusens, ah! On my system lazr contains an __init__.py... staged, it does not
[14:31] <mhall119> oh god, not lazr
[14:31] <dholbach> mhall119, like?
[14:31] <kyrofa> sergiusens, that must be the issue
[14:32] <kyrofa> But how...
[14:32] <dholbach> mhall119, could you make up an example? so I know what you're talking about?
[14:32] <jdstrand> zyga: hey, are you ready to talk about mpris again?
[14:32] <mhall119> dholbach: let me think on it and I'll propose something
[14:32] <dholbach> thanks
[14:32] <dholbach> just add it to the wiki
[14:33] <sergiusens> kyrofa btw, xnox wrote python3 bindings for launchpad a while back iirc
[14:34] <kyrofa> sergiusens, good to know
[14:34] <sergiusens> elopio can you help me out with http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1050/console
[14:34] <sergiusens> not sure what the problem is
[14:37] <kyrofa> sergiusens, looks like it sets that stuff up in postinst, argh
[14:37] <kyrofa> I'll try using pip
[14:38] <zyga> jdstrand: re, yes
[14:41] <elopio> sergiusens: yes, look in #ubuntu-devel. I asked Martin, he gave me ideas of how to get more information about the error.
[14:43] <matteo> anyone ever compiled snapd with gccgo?
[14:44] <zyga> matteo: ppc uses gccgo AFAIR
[14:44] <zyga> matteo: there are some issues that we whack-a-mole fix
[14:44] <matteo> how to do it? go build -compiler gccgo or gccgo directly?
[14:44] <zyga> matteo: I'd suggest looking at the ubuntu/debian packaging
[14:44] <zyga> matteo: that's how it is built there
[14:45] <matteo> thanks
[14:45]  * ogra_ would grab the source pakcge from the archive and take a look at debian/rules ;) 
[14:45] <zyga> matteo: I don't have the hardware to experiment so I cannot help more
[14:45] <sergiusens> elopio I'll add a no_proxy fixture to those tests. We already saw this which is why I asked you and you jogged my memory :-)
[14:45] <zyga> jdstrand: could you add a docs/interfaces.md entry for mpris please
[14:45] <matteo> https://packages.debian.org/sid/snapd
[14:45]  * ogra_ notes thaat this could run snaps with a xenial install ;) https://www.raptorengineering.com/TALOS/prerelease.php
[14:46] <ogra_> 12 core 256GB ram ... i guess you dont need any disks anymore on a workstation like this :)
[14:46] <ogra_> (just for copying your OS to a ramdisk on boot)
[14:46] <zyga> ogra_: 190TDP, it is good to know power stands for "I still suck power'
[14:47] <zyga> ;)
[14:47] <ogra_> :)
[14:47] <ogra_> saves heating in winter at least
[14:47] <jdstrand> zyga: well, that is an interesting point. we don't have anything in docs/interfaces.md for bluez, network-manager, etc (ie, things that aren't implicit slots). this isn't an implicit slot, so I didn't add it
[14:47] <zyga> ogra_: not applicable to spain
[14:47] <jdstrand> zyga: should explicit slots be documented in there?
[14:47] <zyga> jdstrand: I'd document it because all the interfaces should be, the ones you mentioned are just omissions
[14:47] <ogra_> well, you could attach a sterling engine that powers your AC
[14:48] <jdstrand> I see
[14:48] <zyga> jdstrand: I mean we should document all interfaces
[14:48] <zyga> jdstrand: their purpose, type, etc
[14:48] <zyga> jdstrand: ideally how to use them later on
[14:48] <jdstrand> I was thinking the same thing, but it seemed like an implicit vs explicit, so...
[14:55] <mhall119> sergiusens: is there a bug report for the snapcraft pkg-config not being able to find .pc files in different locations?
[14:56] <mhall119> if not, I can create one
[14:56] <matteo> zyga: you know that if you use gccgo on x86 the binary is half the size?
[15:00] <zyga> matteo: I didn't try to use gccgo yet but perhaps it is because of the supprt for shared libraries?
[15:02] <matteo> zyga: /usr/lib/x86_64-linux-gnu/libgo.so.9, damn
[15:02] <mhall119> sergiusens: is my problem related to https://bugs.launchpad.net/snapcraft/+bug/1531481 or is it different?
[15:03] <sergiusens> mhall119 maybe, a new bug might be better though
[15:04] <sergiusens> matteo zyga there is shared library support for gc-go for x86 fwiw
[15:07] <elopio> congrats tsimonq2! I see your svn branch made it for 2.12.
[15:11] <jdstrand> zyga: note, I need to prepare for and attend a meeting now. I'll check backscroll
[15:11] <zyga> jdstrand: ack, I'll merge your interface shortly
[15:25] <sergiusens> tsimonq2 yup as elopio said, it will make it to 2.12; thanks for putting up with our quality standards!
[15:26] <sergiusens> josepht hey, have you had a chance to look into OrderedDicts?
[15:42] <slangasek> zyga: yes, that was using dpkg-vendor
[15:42] <ogra_> mvo, so looking at the PPA build, what from the go packages from https://launchpad.net/~snappy-dev/+archive/ubuntu/image do i need to copy over to the edge PPA, are any of them used in the image build ?
[15:42] <ogra_> mvo, so far i would copy
[15:43] <sergiusens> elopio this might need a rebase/merge https://github.com/ubuntu-core/snapcraft/pull/591
[15:43] <ogra_> initamfstools-ubuntu-core ... livecd-rootfs, squashfs-tools (is that still needed ?), ubuntu-core-config
[15:43] <ogra_> (plus your last shadow upload)
[15:43] <mvo> ogra_: most should not be needed, the go stuff should be in sync
[15:44] <mvo> ogra_: aha, please do copy the shadow bit, I tripped over this
[15:44] <ogra_> mvo, right, i think only these four are needed ... what about squashfs-tools ?
[15:44] <mvo> ogra_: uploaded to the wrong ppa
[15:44] <ogra_> did that get SRUed already
[15:45] <ogra_> mvo, no, you didnt ... livecd-rootfs hanst moved to the edge one yet
[15:45] <mvo> ogra_: that is in xenial too
[15:45] <mvo> ogra_: I guess I will just delete the ones that have identical version in xenial and the ppa to avoid further confusion
[15:45] <ogra_> and since you are fiddlign with builds i'll keep the switch for toomorrow so i dont step on your toes with livecd-rootfs changes
[15:46] <ogra_> that would help
[15:47] <mvo> ogra_: yeah, I need an image with a new passwd
[15:48] <ogra_> mvo, right, build system is all yours then, i'll do the switch tomorrow
[15:51] <mvo> ta
[15:51] <josepht> sergiusens: not yet, I'll see if I can get that done today.
[15:55] <slangasek> elopio, mvo: snapd 2.0.9 is still missing verification-done on bug #1593201; is this SRU good to release?
[15:55] <jdstrand> zyga: thanks!
[15:55] <elopio> fgimenez: ^
[15:55] <jdstrand> zyga: fyi, I'm incorporating tyhicks feedback on arg filtering, will merge with trunk and hopefully this can be part of the next upload
[15:56] <fgimenez> elopio, slangasek i'm about to post a comment and change the tag, the verification is done
[15:57] <zyga> jdstrand: fantastic
[15:57] <zyga> jdstrand: btw, we'll release 1.0.34 soon :)
[15:57] <zyga> jdstrand: release early and often as they say :>
[15:58] <jdstrand> zyga: working on it as we speak
[16:00] <slangasek> fgimenez: thanks, publishing then!
[16:01] <fgimenez> slangasek, thank you :)
[16:12] <mhall119> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1595243
[16:15] <slangasek> zyga, mvo: how should I upstream bug reports filed in Debian about the snappy packaging? (I.e. for cases where I'm not just submitting an MP because I don't immediately know the correct fix)
[16:17] <mvo> slangasek: just report here https://bugs.launchpad.net/snappy and let me know
[16:17] <slangasek> mvo: got it, thanks
[16:17] <mvo> yw
[16:20] <jdstrand> zyga: dude, I think every change I made has a conflict :|
[16:43] <sergiusens> elopio ok, so I got pass the no_proxy issue, now wrt integration tests, do I need some specific proxy setup http://pastebin.ubuntu.com/17704844/ ?
[16:48]  * jdstrand scratches head and wonders why the snap-confine tests aren't running on i386
[17:13] <roadmr> hey jdstrand . Am I correct in assuming we need a new click-reviewers-tools to auto-approve packages using the serial-port interface?
[17:18] <jdstrand> roadmr: yes. I just added it in r681. note I pinged pindonga and noise][ earlier about pulling r680
[17:20] <roadmr> jdstrand: ah, added minutes ago ;) pindong-a is out sick today, I'll take care of this then :)
[17:25] <jdstrand> roadmr: I added it when I saw your ping :)
[17:25] <roadmr> jdstrand: sneaky you ;)
[17:25] <jdstrand> hehe
[17:43] <jdstrand> tyhicks: dang it-- you're too good :)
[17:43] <elopio> sergiusens: yes, let me ask IS for the exception in the firewall.
[17:44] <tyhicks> jdstrand: regarding the disabled tests for snap-confine on !amd64 architectures?
[17:44] <jdstrand> yes
[17:44] <tyhicks> :)
[17:44] <jdstrand> I looked and missed it
[17:45] <tyhicks> I saw that PR go by a few days ago and disabling tests caught my eye
[17:46] <jdstrand> tyhicks: they used to be disabled in common.sh. this is better, but I fixed common.sh to work with i386...
[17:47] <jdstrand> anyway, I'll see if I can adjust that
[18:07] <jdstrand> zyga: fyi, https://github.com/snapcore/snap-confine/pull/7#issuecomment-227828658
[18:15] <palasso> mhall119: in the geany snapcraft you forgot to place 2 dashes in -disable-html-docs in the configflags
[18:31] <zyga> jdstrand: looking
[18:31] <zyga> jdstrand: I saw mvo merged mpris
[18:42] <jdstrand> \o/
[18:42] <jdstrand> zyga: this would be nice to merge for 2.0.10: https://github.com/snapcore/snapd/pull/1387
[18:42] <jdstrand> especially for socketcall
[18:42] <jdstrand> (trivial PR)
[18:44] <tedg> zyga: Looking at the interfaces rest call, and it looks like to me that the connection should have an "apps" field with the apps from the snap. But I'm not seeing that.
[18:44] <tedg> Is there some case where that gets dropped that I'm not seeing?
[18:44] <jdstrand> zyga: you said "just install the package on your system". what package? the new ubuntu-core-launcher? it will work without an updated snapd?
[18:45] <zyga> yes
[18:45] <zyga> it's designed to be an upgrade
[18:45] <zyga> it ships ubuntu-core-launcher symlink
[18:45] <jdstrand> ok, I'll try that real quick
[18:45] <zyga> tedg: mmmm
[18:45]  * jdstrand tried to symlink manually be it didn't work. I probably missed something
[18:45] <zyga> tedg: not sure, maybe just an omission
[18:45] <zyga> jdstrand: just dpkg-buildpackage
[18:46] <zyga> jdstrand: and debi
[18:46] <jdstrand> yeah, I understand. doing that now
[18:46] <tedg> zyga: It looks there to me, https://github.com/snapcore/snapd/blob/master/interfaces/json.go#L48
[18:46] <tedg> zyga: Is there somewhere else I should be looking?
[18:47] <zyga> tedg: that's not what is being sent, look at daemon/api.go please
[18:53] <zyga> tedg: do you see the mapping?
[18:54] <tedg> zyga: Yeah, the mapping seems fine. I wonder if the flattening code is somehow effecting it. Looking there now.
[18:56] <tedg> zyga: So I think the repo is putting a "slot ref" in there and then the api.go isn't dereferencing it.
[18:56] <jdstrand> zyga: ok, confirmed the deb worked as expected
[18:57] <tedg> zyga: So then the JSON only has the snap name and snap instead of providing more information.
[19:00] <zyga> jdstrand: I saw, great news
[19:00] <zyga> tedg: I think that was the intent of the interfaces call, maybe the docs are stale
[19:00] <zyga> tedg: another call should profile all the information about apps
[19:02] <MichaelTunnell> You can have your own repo/ store. snapd just manages the snaps it's given. The snap client does the store integration, but someone could patch that or make their own store or their own client to poke snapd with snaps. - so question: is there any documentation on this so that I can learn more about this?
[19:02] <tedg> zyga: It seems then that I can't distinguish between an interface for the whole snap and one for an individual app.
[19:03] <croepha> TIL/ pro tip for debugging purposes, you can just add bash to your .snap, and then you can use that to get a shell to test things in your snap environment
[19:06] <tedg> zyga: I think I can use the plugs object for what I need though.
[19:06] <tedg> I still need revision info, but that's a smaller issue.
[19:08] <tedg> MichaelTunnell: You can use the REST inteface to install snaps or otherwise manage snapd: https://github.com/snapcore/snapd/blob/master/docs/rest.md#v2snaps
[19:09] <jdstrand> morphis: hey, can you comment on bug #1583057?
[19:13] <MichaelTunnell> tedg: lets say someone from another distro wanted to make their own "repo" of snaps, would that be the link to provide them?
[19:16] <tedg> MichaelTunnell: It depends a lot on the architecture of what they want to build. So, I'd have a conversation with them, not provide a link :-) That is how to manage snaps in snapd from an external service. It applies to some solutions, specifically the one you asked about.
[19:22] <mhall119> palasso: thanks, upstream already pointed that out to me, and in fact I'm removing that config flag completely now
[19:22] <palasso> nice
[19:37] <greentea_> within a snap, is there a way to modify command-<snap>.wrapper ??
[19:39] <tedg> greentea_: It is built by snapcraft by the parts that you're using. So, kinda, but by using snapcraft parts, not directly. You can insert another wrapper though if you want to add variables.
[19:41] <greentea_> tedg: do you know I could modify pythonpath so it could find packages?
[19:41] <tedg> greentea_: If you use the python part it'll install pip packages and adjust the path to find them.
[19:41] <sergiusens> greentea_ that wrapper thing is an implementation detail for snapcraft
[19:43] <tedg> greentea_: For info: $ snapcraft help python3
[19:46] <greentea_> tedg: ahh, yes. I specified a list of packages using python3 plugin, but since I'm using a different python runtime, its path is short of sight
[20:47] <greentea_> how to set destdir using autotools plugin?
[20:50] <zyga> greentea_: it's set by snapcraft, why do you want to change it?
[20:51] <greentea_> ohhh, I see
[20:52] <greentea_> zyga: oops, I meant how do we include it in .yaml under autotools part
[20:52] <greentea_> I'm confused with the specs and keep getting errors
[20:53] <greentea_> never mind - got it
[23:06] <example6> Any advice on available packages / workarounds for getting any sort of lite desktop on snappy core?
[23:06] <example6> Say, on a raspberry pi