[05:16] <mup> PR snapd#2256 opened: overlord/ifacestate: fix missing security setup for connected slot <Created by albaguirre> <https://github.com/snapcore/snapd/pull/2256>
[05:22] <sergiusens> Saviq hey there, can you help me in triaging LP: #1638405 ?
[05:22] <mup> Bug #1638405: libunity not added to LD_LIBRARY_PATH <Snapcraft:Incomplete> <Snappy:Invalid> <https://launchpad.net/bugs/1638405>
[05:28] <mup> Bug #1638796 opened: mir clients that use cpu renderable surfaces don't work under confinement <Snappy:New> <https://launchpad.net/bugs/1638796>
[05:34] <mup> Bug #1638798 opened: mir server process goes defunct when a mir client attaches under confinement <Snappy:New> <https://launchpad.net/bugs/1638798>
[06:38] <zyga> jdstrand: ack, thank you (for the policy comment)
[07:17] <foxmask> bonjello
[07:19] <mup> PR snapd#2257 opened: debian: golang is not installable on powerpc <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/2257>
[08:32] <mup> PR snapd#2257 closed: debian: golang is not installable on powerpc <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2257>
[08:40] <tsdgeos> am i right in assuming snapcraft makes a local copy of my sources file?
[08:40] <didrocks> tsdgeos: if the source is remote, indeed
[08:40] <tsdgeos> if so any reason it doesn't make so of my /etc/apt/preferences one?
[08:40] <didrocks> otherwise, it's using symlinks
[08:41] <didrocks> I think that was planned to support that
[08:41] <tsdgeos> because it's complaining abotu packages being broken
[08:41] <tsdgeos> when they're fine
[08:41] <didrocks> but they are creating their own local repo
[08:41] <tsdgeos> it's snapcraft that broke them
[08:41]  * didrocks got that you told sources file as apt source, wasn't obvious at the start
[08:41] <didrocks> but yeah, IIRC, there is a bug (or you should open one) about it
[08:42] <didrocks> note though that wouldn't help building from launchpad
[08:42] <mup> PR snapd#2258 opened: docs: move to github.com/snapcore/snapd/wiki <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2258>
[08:43] <tsdgeos> didrocks: ok, will try to open a bug
[08:44] <didrocks> thanks!
[08:51] <mup> PR snapd#2258 closed: docs: move to github.com/snapcore/snapd/wiki <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2258>
[08:52] <niemeyer> Docs mooooved
[08:52] <niemeyer> Well, some docs anyway
[08:59] <mup> PR snapd#2259 opened: tests: /dev/ptmx also broken on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/2259>
[08:59] <mup> PR snapcraft#886 opened: Support for gadget snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/886>
[09:10] <sergiusens> didrocks tsdgeos we never planned to support /etc/apt/preferences
[09:11] <didrocks> sergiusens: oh, didn't you tell you wanted to support ppas?
[09:11] <didrocks> and use host apt sources.list?
[09:11] <didrocks> (and so I guess host apt, which is supporting apt pinning and such)
[09:12] <sergiusens> didrocks yeah, but never discussed /etc/apt/preferences at all
[09:12] <didrocks> sergiusens: well, if you use host apt, you will get those options supported automatically :)
[09:12] <tsdgeos> sergiusens: i don't know how half of this thing works, but if you're copying the sources file (that it seems you are at ./parts/unity8/ubuntu/etc/apt/sources.list) it only makes sense to copy the preferneces file
[09:13] <tsdgeos> otherwise you're going to end up packaging the .deb file i didn't expec
[09:13] <tsdgeos> t
[09:13] <sergiusens> tsdgeos it makes sense to you maybe; but sure, log a bug against the project
[09:13] <tsdgeos> i already did
[09:14] <sergiusens> tsdgeos that's why you clean build ;-)
[09:14] <sergiusens> tsdgeos where? It never reached me, did you log it against the project?
[09:14] <tsdgeos> https://bugs.launchpad.net/snapcraft/+bug/1638840
[09:14] <mup> Bug #1638840: snapcraft copies /etc/apt/sources but ignores /etc/apt/preferences <Snapcraft:New> <https://launchpad.net/bugs/1638840>
[09:14] <Saviq> sergiusens, you probably want pstolowski to help with bug #1638405
[09:14] <mup> Bug #1638405: libunity not added to LD_LIBRARY_PATH <Snapcraft:Incomplete> <Snappy:Invalid> <https://launchpad.net/bugs/1638405>
[09:15] <sergiusens> tsdgeos oh, 15 minutes ago
[09:15] <tsdgeos> yes
[09:15] <sergiusens> tsdgeos how will you solve launchpad builds with your setup btw?
[09:15] <tsdgeos> i don't understand the question
[09:16] <tsdgeos> i'm a total snapcraft newbie
[09:17] <sergiusens> Saviq he mentioned unity7 (yeah, wrong person), just want to figure out how this is in his LD_LIBRARY_PATH...
[09:17] <sergiusens> but yeah, no worries
[09:21] <pstolowski> sergiusens, $SNAP/usr/lib/x86_64-linux-gnu/libunity should be added to a part / wrapper script, no?
[09:30] <sergiusens> pstolowski yes, but not as part of the base
[09:31] <sergiusens> we will be adding `build-environment` for parts to solve this per part
[10:37] <mup> PR snapd#2259 closed: tests: /dev/ptmx also broken on powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2259>
[10:37] <mup> PR snapd#2260 opened: tests: add test that ensures the right content for /etc/os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/2260>
[10:56] <Son_Goku> oh dear
[10:56] <Son_Goku> the Cubs won
[10:56] <Son_Goku> who knows what could happen now?!
[11:04] <kalikiana_> stgraber: jdstrand I can't install the lxd snap I built... It fails on 'installation not allowed by "lxd" slot rule of interface "lxd"' if I add slots:[lxd] to it, or without it the same with lxd-support
[11:06] <kalikiana_> The error isn't very descriptive unfortunately... it doesn't even say exactly what part of it is the blocker. Not even --devmode makes a difference
[11:08] <kalikiana_> Nothing in the logs
[11:23] <Chipaca> kalikiana_, what error? (not sure if you're talking to somebody, in which case ignore me)
[11:25] <kalikiana_> Chipaca: installation not allowed by "lxd" slot rule of interface "lxd" - I used lxd: allow-installation: false deny-connection: true deny-auto-connection: true in basedeclaration.go for the lxd interface and added slots: [lxd] to the lxd snap
[11:26] <kalikiana_> This was what was suggested I do in the review for https://github.com/snapcore/snapd/pull/2225/files
[11:26] <mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <Conflict> <https://github.com/snapcore/snapd/pull/2225>
[11:26] <kalikiana_> The idea being, snapd can pull in the lxd snap when it's needed
[11:27] <kalikiana_> Alas, I can't install that "providing" snap in the first place
[11:41] <jdstrand> kalikiana_: yes, that is a development rough edge that I brought up on the list recently. for now, temporarily adjust the base declaration so you can install it
[11:43] <kalikiana_> jdstrand: Hmm which means what exactly? How can I "adjust" without changing the interface I want to have?
[11:43] <kalikiana_> devmode doesn't work
[11:45] <jdstrand> kalikiana_: just make it look like 'bluetooth-control' but use 'app' instead of 'core'
[11:45] <jdstrand> kalikiana_: in other words, just have it not autoconnect, but otherwise it is installable and connectable
[11:45] <jdstrand> kalikiana_: when you are satisified with testing your snapd, undo that bit and submit the PR
[11:46] <jdstrand> kalikiana_: you'll need to do that for both lxd and lxd-support
[11:55] <tsdgeos> can i remount the snap mounts as read/write?
[11:55] <tsdgeos> i tried
[11:55] <tsdgeos> sudo mount -o remount,rw /var/lib/snapd/snaps/unity8-session_x1.snap /snap/unity8-session/x1
[11:55] <tsdgeos> but didn't work
[11:56] <ogra_> tsdgeos, indeed you can remount anything you like as readwrite ... but in case of a squashf img file that wont gain you anything ;)
[11:56] <zyga> tsdgeos: squashfs doens't support writing at all
[11:56] <jdstrand> tsdgeos: no. squashfs files are not writable
[11:56] <jdstrand> heh
[11:56] <tsdgeos> meh
[11:57] <Chipaca> tsdgeos, what're you trying to do?
[11:58] <valve> hi. Is this the correct channel to ask for advices on writing my snap.yaml (and packaging in general) ?
[11:58] <tsdgeos> Chipaca: i'm trying to debug stuff, basically why unity8 snap doesn't start, by adding debugs, given how debug unfriendly this whole snap thing is
[11:58] <kalikiana_> tsdgeos: snap try?
[11:58] <Chipaca> valve, probably :-) although writing the snap.yaml by hand is discouraged
[11:58] <valve> Chipaca: how should I do ?
[11:59] <Chipaca> tsdgeos, what kalikiana_ said; don't create the snap, stage it and then snap try on the directory
[11:59] <Chipaca> valve, what're you trying to do?
[11:59] <jdstrand> tsdgeos: there is a trick you can do with overlayfs though to aid in debugging, etc. http://paste.ubuntu.com/23420437/
[11:59] <Chipaca> valve, for most things, snapcraft is the way to do it
[12:00] <tsdgeos> i guess i can try the try thing
[12:00] <tsdgeos> tx
[12:00] <valve> Chipaca: but have to start from a snap.yaml anyway (afaik)
[12:00] <Chipaca> valve, snapcraft.yaml
[12:01] <valve> Chipaca: yes yes sorry
[12:01] <ogra_> tsdgeos, "snap run --shell unity8-session" will spawn a shell inside your snap env ...
[12:01] <ogra_> tsdgeos, and if you want to tyr our single chnages you can bind-mount writable files on top of the files inside the snap
[12:01] <ogra_> *try out
[12:01] <valve> My current problem is the following: I'm trying to pack a python application into a snap. The problem I've right now is that the app wants to access /etc/<its-config-file>.cfg
[12:01] <Chipaca> valve, it has no way of overriding that?
[12:02] <Chipaca> valve, (what app, btw?)
[12:02] <valve> Chipaca: that's true, might give it a different path (via a parameter).
[12:05] <valve> but
[12:09] <valve> What's the correct procedure to pack a "daemon" (general question) that assumes a configuration in <prefix>/etc (just as an example) ?
[12:11] <tsdgeos> kalikiana_: how does the snap try thing work? what directory do i have to pass it?
[12:14] <tsdgeos> because if i pass the dir the snapcraft yaml file is, it doesn't like it
[12:17] <tsdgeos> so it seems it needs the "prime" folder
[12:18] <tsdgeos> very explanatory
[12:22] <valve> the point is: the application brings in its dependencies and these assume files in <prefix>/etc (just to get to my point)
[12:23] <valve> I can change my application settings but have no (or just few) controls over the dependencies
[12:23] <valve> I was assuming that the plugines were doing the maginc (just changing the prefix) underway
[12:23] <valve> But while running the application (daemon to be correct) it cannot access /etc and thus doesn't work
[12:24] <valve> I'm surely wrong somewhere (bad assumptions and/or understanding). The snapcraft.io documentation doesn't help me.
[12:25] <valve> Where should I dig for mode documentation ?
[12:53] <zyga> valve: I don't think the plugins do prefix changing magic
[13:02] <valve> zyga: the whole thing does use prefixes since (AFAIK: it builds and pack things accordingly). My point (due to ignorance - mostly) is: bringing things into a snap is process that tends to be bloody. I.e. I can change my app, I can delve into the details of some app. If I have a huge chain of dependencies ... the problems could be many
[13:03] <valve> I supposed (probably wrong assumption) to have an "internal mapping" to let the code see a (sort of) container FS as a chroot-ed thing (please try to get me)
[13:06] <valve> (Assuming that a package resolves to an environment variable to get a correct prefix ... works in - probably - just an handful of times))
[13:06] <valve> However: is there a point where to grab fresh / more complete documentation ? At the moment what I'm using is snapcraft.io
[13:19] <zyga> valve: we're cooking a feature that will make it easier, right now if you can pass various switches to make it ignore /etc it is much better/eaier
[13:19] <zyga> easier*
[13:22] <valve> zyga: will do that using HOME (SNAP_DATA) at build and running phases
[13:22] <valve> zyga: thanks
[13:29] <mup> PR snapcraft#886 closed: Support for gadget snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/886>
[13:33] <mup> PR snapd#2261 opened: release: os-release on core has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2261>
[13:34] <sergiusens> renato replied on telegram
[13:39] <valve> Is there a timing for the jhbuild plugin (https://github.com/snapcore/snapcraft/pull/812) ?
[13:39] <mup> PR snapcraft#812: New plugin: jhbuild <Created by attente> <Conflict> <https://github.com/snapcore/snapcraft/pull/812>
[13:40] <attente> valve: there's some issues with that PR that i need to work through...
[13:40] <attente> valve: i'm trying to remove the use of lxc in that plugin
[13:41] <attente> it's a substantial re-write...
[13:41] <valve> attente: thank you
[14:00] <steve___> Hi All, I'm new here. Just started working on snapping some neuroimaging tools.
[14:00] <steve___> Is there a way to create a "local" store so we can test everything out entirely without polluting the Ubuntu store with half baked packages?
[14:02] <cwayne> steve___: hiya, welcome :)  generally I'd say that's the purpose of the edge channel on the store, those packages aren't meant to be stable and could very well be half-baked
[14:02] <steve___> perfect!
[14:38] <cellash> Hi all, Im currently have a working .snap on Unity 7 on 16.04 and 16.10 however when I try to run it on Unity 8 (16.10) I get this error: https://pastebin.ubuntu.com/23420077/. Does anyone know what this means or knows a way to fix this? Any hep would be appreciated.
[14:45] <Mirv> qt-ubuntu^Wubuntu-qt-runtime^W long live ubuntu-app-runtime!
[14:46] <didrocks> renato__: Mirv: so, indeed, I think we should have the desktop launcher as part of the runtime content-shared snap
[14:46] <renato__> didrocks, hi
[14:46] <qengho> Hi all. How is snap set/get supposed to work?
[14:46] <didrocks> or… hum, I wonder if the remote parts is after: another remote one, if that would work?
[14:46] <didrocks> sergiusens: did you already try to test this: ^ ?
[14:47] <Mirv> didrocks: so I was thinking about a launcher as part of a cloud part that is combined with the content shared snap use
[14:47] <didrocks> yeah, either we combine, or we chain them
[14:47] <sergiusens> didrocks I did add logic for this to work in one of the latest releases; is it failing bad?
[14:47] <Mirv> yeah chaining if possible
[14:47] <didrocks> sergiusens: no, I was just curious, let's see if we can break it then! :-)
[14:48] <sergiusens> didrocks I am basically resolving the whole build chain before trying to even load a plugin now
[14:48] <renato__> didrocks, we will need a combination of gtk and qt launch, since some of our apps uses glib and qt
[14:48] <didrocks> Mirv: ok, so to avoid repetition, let's have the 2 chaining each other, and adding a new part refering your work
[14:48] <Mirv> so after: [ubuntu-app-runtime], which pulls in the ubuntu-app-runtime and the app plugs into it and uses ubuntu-app-launch (or some other name) to launch the app
[14:48] <didrocks> renato__: but everything is shipped in ubuntu-app-runtime, correct? (gtk/glib and qt?)
[14:50] <didrocks> Mirv: FYI, the launchers are https://github.com/ubuntu/snapcraft-desktop-helpers, adding a new built one isn't an issue, we just need to ensure the paths are correct and we ship in the runtime what we need
[14:50] <renato__> didrocks, I think so, Mirv can confirm that
[14:50] <Mirv> there's a lot yes planned at the moment to be included
[14:50] <qengho> How is a snap supposed to get values set from the outside with "snap set"?
[14:50] <didrocks> qengho: snapctl set/get from the hook itself
[14:51] <didrocks> qengho: snapd has an example in the tests for this + the hook documentation
[14:52] <didrocks> Mirv: so, yeah, let's add another flavor for it. Look at the current built-in helper (like the one used in the vlc snap) and tell me what paths needs to change. Then, we can revisit
[14:52] <didrocks> and I think we'll "force" apps using this runtime to bindmount it in a well-known location
[14:53] <didrocks> like $SNAP/snap-platform maybe
[14:54] <Mirv> didrocks: right, after we have something (not really started on the cloud part / launcher yet, just have custom launchers for apps), it could live there too instead of own repo
[14:54] <renato__> didrocks, Mirv, we need to mount the share content in a fixed dir to get it working right?
[14:54] <renato__> right now the app can mount it whatever it want
[14:54] <Mirv> renato__: yes well the launcher would want it to be in the known dir, like we now have it mounted under the app's ubuntu-app-runtime dir
[14:54] <Mirv> didrocks: do you think a custom interface would be then better than content interface where we need to actually specify the directory?
[14:56] <didrocks> Mirv: it would be better to reuse the same launcher structure directly, there is a common file and we try to share as much code between launchers as possible (which is the goal of this repo)
[14:56] <didrocks> rather than each one having his own repo. We saw what happened then (broken in some place, not sure what people took)
[14:56] <didrocks> there are makefiles to build them dynamically
[14:57] <didrocks> (and so, they all have a common part, and a specific/dedicated one)
[14:57] <didrocks> renato__: Mirv: for mounting, I would really force to mount them in a directory for the launcher to know where to look for (or add an option to the launcher to specify if default doesn't work for them)
[14:57] <Mirv> didrocks: makes sense indeed
[14:57] <didrocks> but best practice is to agree on a path
[14:57] <didrocks> and use the same for all runtime
[14:58] <didrocks> so content-share interface, and specifying a path (I would avoid runtime though for confusion with flatpak)
[14:58] <didrocks> as they are not exactly the same thing
[14:58] <renato__> will be nice if the interface could create the path if that does not exists, right now the app need to install a empty dir
[14:58] <didrocks> we agreed 3 months ago to use the term "platform"
[14:58] <didrocks> renato__: yeah, it's because we are using bindmount… and the path is RO
[14:58] <didrocks> so you can't create the dir dynamically to bindmount to it
[14:59] <Mirv> didrocks: we agreed this week against platform and framework, and agreed today on ubuntu-qt-runtime -> ubuntu-app-runtime :)
[14:59] <didrocks> (and we don't use overlayfs or something similar)
[14:59] <didrocks> Mirv: hum, you should have talked to us, runtime was voted against by executive decision
[14:59] <didrocks> so really, don't use it :)
[15:00] <renato__> the name again :D
[15:00] <Mirv> oh this bikeshedding :)
[15:01] <didrocks> classical, isn't it! :)
[15:01] <Mirv> didrocks: yeah we've the content interface working now as described, renato__ is running calendar on it
[15:01] <didrocks> Mirv: let's call it -foo for now :)
[15:01] <didrocks> ok, so you only need to integrate to the launcher
[15:02] <Mirv> yes renato just copy-pasted the launcher from my test app
[15:02] <didrocks> do you want to have a first look? I think we can then amend the existings one to add more options if needed
[15:02] <seb128> should building snaps that pull a git repo work on launchpad?
[15:02] <seb128> I've a simple one that fails to build on
[15:02] <seb128> "git.gnome.org: Name or service not known"
[15:02] <renato__> Mirv, no I was using gtk-launcher and this consumes 50MB on the package
[15:02] <Mirv> yeah I plan to take an actual first look really-soon-now, it's just all this bikeshedding that gets in front of it :)
[15:03] <didrocks> seb128: I got some issues on some domains as well. It's pulled as source:, correct?
[15:03] <renato__> Mirv, didrocks we need a launcher that make uses of the library on the content share instead install new ones
[15:03] <Mirv> renato__: oh, ok, I thought you copy-pasted from the timostestapp3 that would have the correct paths already
[15:03] <seb128> didrocks, yes, http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/snapcraft.yaml
[15:03] <Mirv> renato__: that's what the launcher on timostestapp3 does, yes :)
[15:03] <renato__> Mirv, I did a mix of both
[15:03] <didrocks> seb128: I guess for the launchpad team, but yes, it's supposed to work
[15:04] <didrocks> Mirv: creating a complete launcher respecting themes and such is really complex (with gsettings…)
[15:04] <didrocks> I guess that's why renato__ pulled from both :)
[15:04] <Mirv> didrocks: so indeed this https://github.com/tjyrinki/timostestapp3/blob/master/launcher is basically copy-pasting + sed from desktop-helpers
[15:04] <didrocks> Mirv: ok, do you want me to work on this? (in this case, it will be on Monday), or do you want to have a go?
[15:05] <seb128> cjwatson, hey, should launchpad be able to pull a source from git.gnome.org to build a snap? I don't know if I do something wrong/stupid but my build fails on "git.gnome.org: Name or service not known"
[15:05] <didrocks> seb128: git:// is using ssh IIRC, did you try the http:// version?
[15:05] <seb128> didn't, that could be it
[15:06] <didrocks> if you use http:// postfix with .git
[15:06] <seb128> I think I changed it to git: because snapcraft is not smart enough to figure out that http://git is a git type source
[15:06] <didrocks> (if gnome git doesn't support that, try with source-type: git instead)
[15:06] <didrocks> yeah, it doesn't
[15:06] <didrocks> so either gnome git support .git suffix on http url
[15:06] <didrocks> or source-type
[15:06] <didrocks> that should fix it
[15:07] <cjwatson> yes, you must use http://
[15:07] <cjwatson> (or https://)
[15:07] <seb128> didrocks, I reported https://bugs.launchpad.net/snapcraft/+bug/1590797 on snapcraft about that btw just for the record
[15:08] <mup> Bug #1590797: "no handler to manage source" is not an helpful error <bitesize> <Snapcraft:Triaged> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590797>
[15:08] <cjwatson> but it's not about git:// using ssh (which it doesn't)
[15:08] <cjwatson> it's that builds currently go through a proxy that doesn't proxy the git:// protocol
[15:08] <renato__> didrocks, Monday is ok for me I will be off tomorrow :)
[15:08] <didrocks> seb128: I did the .git suffix for detecting it, but yeah, I think if you have https://git.<something>, it should be considered as git
[15:08] <Mirv> didrocks: I'll check tomorrow how does it look, but it's basically down to "use Qt and other libs primarily from $SNAP/ubuntu-app-foo" so let's check on Monday
[15:08] <didrocks> renato__: ahah, ok :)
[15:08] <seb128> cjwatson, didrocks, thanks
[15:09] <didrocks> Mirv: ok, let's do this!
[15:09] <renato__> Mirv, didrocks in case you need a app to try: https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/snappy-runtime
[15:10] <didrocks> great! that will be of a great help
[15:12] <Mirv> didrocks: or the simple QML case https://github.com/tjyrinki/timostestapp3 :)
[15:13] <sergiusens> niemeyer this is the link that is needed https://hub.docker.com/add/automated-build/github/form/snapcore/snapcraft/ but the sad thing is, you need r/w https://forums.docker.com/t/cant-access-new-github-organization-for-automated-builds/1080/16
[15:13] <sergiusens> niemeyer I'll keep it manual for now
[15:13] <didrocks> Mirv: ok, please have a look tomorrow and let's sync up on Monday! :)
[15:15] <niemeyer> sergiusens: This is what I get when I try to create it: The repository name `snapcore/snapcraft` is already taken.
[15:15] <niemeyer> sergiusens: Did you create it?
[15:15] <sergiusens> let me delete it
[15:16] <sergiusens> niemeyer it is deleted now
[15:17] <niemeyer> sergiusens: "Could not find github repo `snapcore/snapcraft`"
[15:17] <niemeyer> sergiusens: Ah, wait
[15:17] <niemeyer> sergiusens: Maybe GitHub is preventing Docker from seeing it.. let me check the config on GH's side
[15:25] <Mirv> renato__: didrocks: now with more bikeshedding :) https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9019
[15:28] <didrocks> Mirv: ahah! well done :)
[15:33] <mup> PR snapd#2262 opened: tests: disable autorefresh for the external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2262>
[15:38] <mup> Bug #1638320 changed: remove core snap via snapweb fails but it still removes from the web interface <snapweb:New> <https://launchpad.net/bugs/1638320>
[16:53] <pachulo> Hi all! Is there any way of cleaning old versions of a snap in Ubuntu desktop other than removing the old revisions one by one?
[17:01] <mup> PR snapd#2261 closed: release: os-release on core has changed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2261>
[17:17] <mup> Bug #1638988 opened: Cannot run spread hello world on all-snaps image <Snappy:New> <https://launchpad.net/bugs/1638988>
[17:24] <mup> PR snapd#2263 opened: tests: check that gpio device nodes are exported after reboot <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2263>
[17:45] <mup> Bug #1638995 opened: lslogins displays user and email info <Snappy:New> <https://launchpad.net/bugs/1638995>
[18:08] <swaveck> QUESTION: I've just installed Ubuntu Core on my Pi3, authenticated on UbuntuOne; what is my password? UbuntuOne pass isn't working.
[18:19] <ogra_> swaveck, there is no local login ... use ssh
[18:19] <ogra_> (like the config tool told you on the last page)
[18:19] <ogra_> you can ssh and run "sudo passwd $USER" to set a password, that will also allow console logins then
[18:22] <swaveck> thanks for help, I'll try it
[18:44] <qengho> Should I be able to run "snap set ..." and get a configure hook script called in a snap? When I add a configure file in meta/hooks/, "snap set" fails with  error: cannont perform the following tasks:\n- cannot find hook "configure" in "snapname"
[18:44] <qengho> snap    2.16+16.10ubuntu1.2
[20:18] <mup> PR snapcraft#880 closed: Remove license concepts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/880>
[20:42] <nottrobin> How can I switch the channel of a snap?
[20:43] <nottrobin> If I was following "candidate" but now I want to follow "stable"?
[20:52] <noise][> nottrobin: snap refresh foo —stable
[20:53] <nottrobin> ah ha!
[20:53] <nottrobin> thanks
[22:03] <zyga> Pharaoh_Atem: thank you for helping on the release
[22:03] <zyga> Pharaoh_Atem: next week I'll look at what I can do to get the last few bits fixed
[22:03] <Pharaoh_Atem> zyga: you're welcome
[22:03] <zyga> Pharaoh_Atem: tomorrow is wrap up and travel home (finally!) for me
[22:03] <Pharaoh_Atem> well, at least we have the presets in Fedora 25
[22:04] <Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e
[22:04] <zyga> Pharaoh_Atem: yes, and I'm sure we'll crack that last permission with fresh minds next week
[22:05] <zyga> nice :)
[22:06] <vagpag_> hi, could you pls help me on how to connect on ubuntu core 10 as loclahost?
[22:07] <qengho> vagpag_: You said "how to connnect on" and "10", and neither of those make any sense to me. Maybe say that another way.
[22:08] <vagpag_> Sorry! Let me try again.
[22:12] <vagpag_> After installing ubuntu core 16 on my pi 3 and first boot, I can't login as localhost. Hope that helps...
[22:16] <zyga> vagpag_: did you create the user account>?
[22:18] <qengho> vagpag_: That "localhost" part makes no sense still. After you initialize and give it an email address in Launchpad, it listens for incoming ssh. If you ssh to that from another place, with your username equal to your launchpad id, then you should be able to log in. That's the normal path. Did you do all that, or something else?
[22:18] <qengho> If something else, where did you differ?
[22:19] <qengho> $ ssh -l vagpag raspberrypiIPddress
[22:20] <qengho> Assuming https://launchpad.net/~vagpag is you
[22:28] <vagpag_> gengho: after entering my Ubuntu SSO credentials (step three in first boot), my screen says Ubuntu Core 16 on <my ip> (tty1) / localhost login:.
[22:30] <zyga> vagpag_: ssh into that ip from a machine that has corresponding SSH keys
[22:30] <zyga> vagpag_: the username is your launchpad user ID (not email)
[22:37] <valve> sorry. Can I pass parameters to a daemon such as:  'command: bin/fcd -d -c $SNAP/etc/fcd.cfg' (simple daemon) ?
[22:38] <qengho> valve: Sure!
[22:39] <valve> supposed so BUT got 'fcd: error: unrecognized arguments: /snap/...'
[22:39] <vagpag_> zyga: how do i do that? ssh and ip of the machine?
[22:40] <qengho> valve: I should distinguish here, that snapcraft will let you do that. I'm not saying your command you are providing will like it. You're running "fcd" there. It complaining. Fix that.
[22:40] <zyga> vagpag_: like this
[22:40] <qengho> $ ssh -l vagpag raspberrypiIPddress
[22:40] <zyga> vagpag_: ssh zyga@1.2.4.4
[22:40] <zyga> vagpag_: assuming zyga is the username on launchpad
[22:41] <zyga> vagpag_: and the box that runs the ssh command has ssh keys set and uploaded to launchpad under the account "zyga"
[22:42] <mup> PR snapcraft#887 opened: Cache apt related files (config, packages) in 'apt' parent directory <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/887>
[22:43] <qengho> Just to brag, I made a snapcraft yaml that reads params from a config file (that is previously written by a snap-set hook) and optionally sets args for a daemon, without a wrapper. http://bazaar.launchpad.net/~cmiller/+junk/sshesame-snap/view/head:/snapcraft.yaml
[22:44] <valve> qengho: thanks
[22:44] <valve> qengho: thanks
[22:44] <zyga> qengho: nice :)
[22:45] <zyga> qengho: there's a feature in snappy that's not yet available through snapcraft that will let you do that in a way that's even cleaner than that
[22:45] <qengho> zyga: really?!
[22:45] <zyga> qengho: there's a hook system and a way to run a special "app" (hook) on install
[22:45] <zyga> qengho: you can us it now but there's no way to express that in snapcraft yet
[22:46] <qengho> zyga: What's the new hook name?
[22:46] <zyga> qengho: configure
[22:46] <vagpag_> zyga: from a mac's terminal i run ssh -l vagpag and pi ip and know asks for a password
[22:46] <zyga> qengho: I hope it will be docuented soon at https://github.com/snapcore/snapd/wiki
[22:46] <qengho> zyga: Er, that's what I'm using. Walk back up that tree. ^
[22:46] <zyga> vagpag_: do you have ssh keys on your launchpad account?
[22:46] <zyga> hmm :)
[22:47] <zyga> ohhh
[22:47] <zyga> nice!
[22:47] <zyga> qengho: this line, you can simplify it
[22:47] <zyga>     command: sh -c "'test ! -f $SNAP_DATA/configuration || . $SNAP_DATA/configuration; $SNAP/bin/sshesame ${port:+-port $port} ${listen_address:+-listen_address $listen_address} 2>&1 |$SNAP/usr/bin/logger -t $SNAP_NAME'"
[22:47] <qengho> zyga: How?
[22:47] <zyga> qengho: configure runs before we start services AFAIR
[22:47] <vagpag_> zyga: yes. I have it on my ubuntu one account
[22:48] <zyga> vagpag_: do you have that ssh key on your mac?
[22:48] <vagpag_> zyga: No!
[22:48] <qengho> zyga: I guess i could put or "code" in the configuration file, but I'd rather not.
[22:48] <zyga> vagpag_: user account setup doesn't use passwords, you have to use ssh keys to log in
[22:49] <qengho> zyga: I don't know how to get optional params in the command:... otherwise.
[22:49] <zyga> vagpag_: afer that you can use 'sudo passwd' to set a password if you want
[22:49] <zyga> qengho: I mean you can just do any initial setup in the hook itself
[22:50] <qengho> zyga: I don't see it, but I'm happy with this anyway.
[22:53] <qengho> zyga: Is it up to me to poke at systemd to restart the service on config change?
[22:53] <qengho> me=user?
[22:54] <zyga> qengho: the hook can send it a signal to restart the service / reload it
[22:54] <zyga> qengho: the service can observe a config file
[22:54] <zyga> qengho: you can do many things
[22:57] <qengho> zyga: Hmm, is that in a "machines can theoretically do that"-sense, or a "hooks can sighup their process group to signal the services attached should reload and that's what we expect snap packagers to do" or something?
[22:58] <qengho> I have a simple daemon. No pidfile. systemd manages it, but I don't know the process name, and I'd be surprised if confinement lets me to a lot.
[23:01] <zyga> qengho: you can do that to your process from your own hook
[23:01] <zyga> qengho: the daemon can use inotify to look at the config file
[23:01] <zyga> qengho: and you can write a pidfile if that helps
[23:01] <zyga> qengho: or use any form of IPC to push new data into the sevice
[23:01] <zyga> qengho: snappy dosen't help or get in the way much
[23:02] <qengho> zyga: is this after we get a patches: object in snapcraft yaml so I can add inotify watching to somebody's code?
[23:02] <zyga> qengho: ?
[23:03] <zyga> qengho: no, why?
[23:03] <zyga> qengho: the service can inotify observe a config file
[23:03] <zyga> qengho: (or dir or something)
[23:03] <qengho> Oh, a wrapper can? I see.
[23:03] <zyga> qengho: and the config hook can just write to those files
[23:03] <zyga> perhaps I'm missing something and I didn't understand your question
[23:07] <qengho> zyga: I'll tell you my wishlist. The "configure" hook has an environment variable set that contains a list of the process IDs or service names of all the daemons snapd started, and the configure hook can maybe send some signal to those.
[23:07] <AlbertA> qengho: zyga: I was able to put a configure hook by "organize: configure: meta/hooks/configure" seems to work for me for now :)
[23:07] <qengho> AlbertA: I think that will fail when you try to "snap set"
[23:08] <AlbertA> qengho: worked fine for me :)
[23:08] <qengho> AlbertA: Not for me. :\ The nightly snapcraft PPA supports hooks too.
[23:09] <zyga> qengho: interesting though it would always be racy I'm afraid
[23:09] <zyga> AlbertA: nice!
[23:09] <zyga> qengho: though the hook might detect that and just fail
[23:10] <zyga> qengho: (if the user happens to concurrently restart services and use set"
[23:10] <zyga> )
[23:10] <zyga> qengho: I need to get some rest, good night
[23:11] <qengho> zyga: Good night!