[00:05] <olympionex> I really like snapcraft and would like to use it to setup my development environment (automatically fetching and building dependencies and source).  Essentially I want what gets put into the stage directory although I would like everything to be located in standard directories relative to root (/usr/lib, /usr include, etc...).  I'd like to spawn a new computer and use the snapcraft recipe to get everything.  I don't see anyway to do this with snapcraft
[00:05] <olympionex>  as such.  Am I missing an easier solution than either just copying stage to the root of a container or forking snapcraft and changing the stage directory to root?
[00:06] <olympionex> *new computer = new container
[06:08] <shuduo> morning
[06:32] <shuduo> question: where is $SNAP_APP_DATA_PATH point to in recent image?
[06:49] <popey> shuduo: I don't think that's used
[06:49] <popey> SNAP_DATA is
[06:54] <shuduo> popey: hmm, i need use a snap which uses SNAP_APP_DATA_PATH to point a file out of snap. sounds like I need rewrite code to use SNAP_DATA to point to that file instead of SNAP_APP_DATA_PATH. then where is SNAP__DATA point to? i see hello-world use /var/snap but i should not have permission to add a new file there, right?
[06:57] <popey> shuduo: SNAP_USER_DATA is probably what you want, which points to $HOME/snap/<snapname>/<revision>
[06:59] <shuduo> popey: great. may i know $HOME/snap/<snapname>/<revision> need extra code to generate? right now there is no such directory although the snap be installed and running as a service.
[07:13] <popey> shuduo: i think it gets made when the snap is installed
[07:13] <popey> I don't think I made it
[07:13] <popey> yes, looking at my system, I have lots of directories in $HOME/snap/* which match the snap names, and I didnt make them
[07:17] <shuduo> popey: since the original code is against old snappy. i ask Pedro Coca's favor to build by an old version snapcraft. do you think it may lead that not making directory in $HOME/snap?
[07:24] <popey> shuduo: not sure, I'd certainly keep up to date with snapd/snapcraft
[07:24] <popey> things move fast, and you're likely to be fighting to use old versions
[07:30] <shuduo> popey: yes. i have to. :(
[10:16] <popey> dholbach: have you made any snaps with multiple parts where one depends on the other, like foo needs libfoo?
[10:16] <popey> I have one where i have foo making sure it builds after libfoo, and libfoo builds from source, but when building foo it doesn't see libfoo headers
[10:17] <popey> like the make install bit of libfoo wasn't done, or it needs an ldconfig or something?
[11:19] <qengho> popey: do you define the "after" clause on foo? Suppose you change to parts/foo/build, do you see references to stage/ libfoo stuff ?
[11:22] <popey> i did
[11:23] <popey> hm, no refrerence in the build dir,
[11:23] <popey> is there some way to say that foo needs to pull in libfoo?
[11:23] <popey> (i should probably say foo and libbar I guess) :)
[11:24] <popey> i see the build for the library in parts/libfoo/build
[11:26] <popey> ah, i guess my qmake plugin isn't doing the right things here, which I'm using for foo
[11:29] <qengho> popey: Yeah, you should be using the stagedir variables to constuct your -I cflags and -L ldflags and such.
[11:56] <popey> ahhh
[11:57] <popey> ta
[12:34] <dholbach> popey, I personally haven't, but I've seen the after keyword being used and played around with it a little bit
[12:34] <dholbach> good to see that you got it working
[12:38] <popey> heh, almost :)
[13:03] <jcastro> sergiusens: electron 1.0. Soon would be a great time to enable app developers to just ship those apps. :D
[13:13] <jdstrand> kgunn, kyrofa: responded in the bug
[13:15] <kgunn> ta
[13:56] <croepha> is there a lower level "debootstrap" like utility for creating a ubuntu snappy installation?
[14:09] <croepha> nvm, I think the ubuntu-device-flash will do what I want, sorry stupid question still learning basics about snappy
[14:23] <noizer> zyga: Hi any advice how i can snap my debootstrapped soft float system?
[14:27] <zyga> noizer: just copy it using the copy plugin
[14:27] <zyga> noizer: still sprinting
[14:28] <noizer> zyga sorry
[15:35] <kyrofa> didrocks, bug #1576411 was the one we were talking about
[15:52] <zyga> tyhicks: is it possible to constrain connect with apparmor/seccomp today?
[15:52] <zyga> tyhicks: I'm thinking of cups interface
[15:52] <zyga> tyhicks: is just having "network" enough to print?
[15:55] <tyhicks> zyga: /etc/apparmor.d/abstractions/cups-client
[15:56] <zyga> tyhicks: oooh, you just made my day easy
[15:56] <zyga> thank you!
[15:57] <tyhicks> :)
[16:00] <zyga> tyhicks: I think we should patch u-c-l to bind-mount /etc/alternatives
[16:00] <zyga> tyhicks: this will also address bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580018
[16:09] <sborovkov> Hi. Is there something wrong with the command I am using -  sudo /home/ubuntu/ubuntu-device-flash core 16 --channel edge --enable-ssh --developer-mode --gadget canonical-pi3 --kernel canonical-pi2-linux --os ubuntu-core -o snappy-2016-05-11-16-08-pi3.img -> expected a gadget snaps: snap not found
[16:10] <qengho> I get that^ too.
[16:10] <qengho> And the "sudo" worries me.  "-o", so why?
[16:11] <josepht> is there a cnonical-pi3 gadget?
[16:11] <josepht> *canonical-pi3
[16:12] <sborovkov> josepht: qengho: it's working with canonical-pi2 gadget. (exact same command, but gadget for pi2)
[16:12] <sborovkov> it is existing
[16:12] <sborovkov> https://uappexplorer.com/app/canonical-pi3.canonical
[16:12] <sborovkov> I am not sure where ubuntu-device-flash downloads it from though
[16:14] <tyhicks> zyga: I haven't looked at that bug until now but that seems like the most reasonable fix
[16:20] <Sweet5hark> apt.cache.FetchFailedException: W:The repository 'mirror://mirrors.ubuntu.com/mirrors.txt xenial Release' does not have a Release file., W:Data from such a repository can't be authenticated and is therefore potentially dangerous to use ...
[16:21] <Sweet5hark> ^^ seeing this with snapcraft on xenial -- any hints?
[16:21] <Sweet5hark> "sudo apt update" works fine?
[16:22] <seb128> Sweet5hark, that is apt.cache ... is snapcraft doing the caching or is that a local cacher from yours?
[16:22] <qengho> Sweet5hark: snapcraft is less forgiving than apt install is. Repos with "W"arnings cause errors.
[16:23] <Sweet5hark> seb128: thats the content of the exception that some snapcraft/python command wrapper throws ...
[16:24] <Sweet5hark> well, an "apt-cache search libreoffice" isnt unhappy either.
[16:25] <kyrofa> didrocks, https://github.com/kyrofa/qt-example-snaps
[16:25] <qengho> Sweet5hark: it's not smart. "apt" exited with nonzero, so you get that failure.
[16:27] <Sweet5hark> hmm, "sudo apt update; echo $?" gives a happy 0 ...
[16:27] <seb128> Sweet5hark, but with W:?
[16:28] <Sweet5hark> seb128: nope
[16:28] <seb128> k, dunno then
[16:28] <seb128> qengho, do you know where snapcraft is gettings its sources config from?
[16:29]  * Sweet5hark will hack snapcraft to echo what commands it run, I guess.
[16:29] <qengho> seb128: hardcoded internally. Constructed from variables.
[16:30] <qengho> /usr/lib/python3/dist-packages/snapcraft/internal/repo.py
[16:37] <kyrofa> seb128, qengho, only 1.x is hard-coded. 2.x uses the system sources by default
[16:38] <qengho> Oh, nice! Sorry.
[16:38] <Sweet5hark> No mirror file '/home/bjoern/checkouts/libreoffice-snap/parts/libreoffice-build/ubuntu/var/lib/apt/mirrors/mirrors.ubuntu.com_mirrors.txt'  <- iinteresting ..
[17:23] <jdstrand> tyhicks: hey, can you take a look at: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/comments/5
[17:24] <jdstrand> tyhicks: I've already added something to the policy updates IV card
[17:25] <jdstrand> tyhicks: and by 'take a look at', I mean, 'review the comment'
[17:25] <tyhicks> jdstrand: yes, I'll need a little bit
[17:25] <jdstrand> tyhicks: it isn't time-sensitive. I just want you to be aware
[17:25]  * tyhicks nods
[17:31] <seb128> jdstrand, tyhicks, @{HOME}/.config/ibus/bus/ is the snap home though?
[17:31] <seb128> not the system one
[17:31] <seb128> e.g it's not going to have the config needed
[17:41] <jdstrand> seb128: /home is not mounted over, so @{HOME}/.config/ibus/bus/ is there
[17:42] <jdstrand> seb128: note that $HOME is set to something like: /home/jamie/snap/hello-world/25
[17:43] <jdstrand> seb128: which is why you copied the stuff into ~/snap/...
[17:43] <jdstrand> but the apparmor policy actually currently allows /home/<user>/.config/ibus/bus/
[17:44] <jdstrand> so if you could find it, you could use it
[17:48] <seb128> k
[17:50] <zyga> jdstrand: do you think we should have stuff like REAL_HOME?
[17:53] <jdstrand> zyga: for sdoc, possibly to probably. for iot, I don't think so. it really depends on how much we want to expose. I mean, $REAL_HOME/.config/ibus/... means nothing on an iot system since there is no ibus daemon running. this is getting a bit into the area where I'm not super-comfortable with mixing policies of different target systems
[17:54] <jdstrand> ie, core vs sdoc vs future personal
[17:55] <jdstrand> I have concerns on the direction we're going that things are going to be quite muddled
[17:56] <jdstrand> I also realize that things are still in flux and we are figuring out, so that isn't a criticism. I just would like to see a clear path for handling the three target system types
[17:58] <zyga> jdstrand: about core vs iot: https://github.com/ubuntu-core/snappy/pull/1158 (already merged)
[18:06] <jdstrand> zyga: awesome! :) yes, that is certainly aprt of it
[18:06] <jdstrand> zyga: but I was getting more at target system security policy philosophy
[18:07] <jdstrand> ie on core/iot it makes a *ton* of sense to set HOME to ~/snap/...
[18:08] <jdstrand> but on Touch we did not do that because we wanted to reuse services like ibus, theme engines, etc and so we set HOME in the normal way with accesses to those directories, and app-specific directories in well-known XDG locations
[18:08] <jdstrand> so now with sdoc I'm not clear what we are doing. that will likely affect personal
[18:09] <jdstrand> I mean I know we are setting HOME to ~/snap/..., but that has implications like with what seb128 is facing
[18:09] <jdstrand> and traditional apps and service don't know know HOME vs REAL_HOME or whatever
[18:10] <jdstrand> so then we try to jump through hoops in the launcher to do bind mounts and things
[18:12] <jdstrand> Touch is cleaner in some ways in that the services, themes, ibus, etc all work cause there are no bind mounts and HOME is normal. but it has its own issues, like apps having to know they can write to ~/.config/snap.foo but not ~/.config/bar
[18:13] <jdstrand> on Touch, the toolkit handles that and apps must be designed for it, but sdoc is traditional apps, which are not
[18:14] <jdstrand> which circles back, HOME in ~/.snap/... helps the apps in some ways (they can write anywhere in $HOME/...) but then breaks them finding ibus files and the like
[18:14] <jdstrand> anyway, I'm just yammering here, but these are some of the things I've been thinking about
[18:14]  * jdstrand goes back to being productive
[18:35] <seb128> jdstrand, having a separate home mostly makes sense but maybe be could expose some selected dir in some way (bind mount, symlinks+apparmor access to the target,...)
[18:35] <seb128> but yeah, not going to be resolved today
[18:55] <zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snappy/pull/1160
[18:56] <popey> sergiusens: you planning on publishing the yaml for your telegram snap somewhere? I am sure a few of us can learn from it :)
[18:57] <zyga> elopio: ^^
[19:21] <elopio> popey, zyga: https://github.com/sergiusens/telegram-snap
[19:30] <popey> elopio: thanks
[20:55] <sergiusens> popey it is in my git hub account
[20:55] <sergiusens> Some things still don't work
[21:52] <nealmcb> I want to play with snaps, but haven't upgraded to xenial yet.  So I'm trying to run it via docker: (docker run -it ubuntu), where I apt update; apt install -y snapd    But then I get "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?sources=local"
[23:32] <popey> nealmcb: looks like your docker instance isn't a full install. maybe snap talks to snapd over dbus or something and the service isn't registered inside the docker container
[23:32] <popey> ... at a guess