[00:21] <mwhudson> slangasek: do you have any idea what is going on here? https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot/+build/9495
[00:22] <slangasek> mwhudson: not offhand.  Is the livecd-rootfs package in our ppa up-to-date?
[00:22] <slangasek> (along with other packages there, generally)
[00:22] <mwhudson> slangasek: i just deleted all the packages in our ppa :)
[00:22] <mwhudson> well xenial ones anyway
[00:23] <slangasek> so the only other 'manifest' ref I see in the log is: + cp assets/dpkg.list /build/snappy-first-boot/parts/livebuild/build/livecd.ubuntu-core.device.manifest
[00:23] <mwhudson> ah i think it's getting livecd-rootfs from the primary archive now
[00:23] <mwhudson> i guess i need to copy it over from ppa:snappy-dev/image
[00:50] <mwhudson> slangasek: oh wait
[00:50] <mwhudson> slangasek: so it's hard coding the snap name in lp in there?
[00:51] <slangasek> is it?  I don't know
[00:53] <mwhudson> yeah i think so
[00:53] <mwhudson> look at the line before the failing line
[00:53] <mwhudson> moving something to /build/snappy-first-boot/...
[00:55] <overflyer> hello all
[00:56] <overflyer> my raspi2 dont boot with ubuntu-core-16-pi2.img
[00:56] <overflyer> only red led is on
[00:56] <overflyer> any idea?
[00:58] <overflyer> cmdline.txt:
[00:58] <overflyer> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
[01:00] <overflyer> i think cmdline is wrong. can anyone help?
[01:10] <overflyer> hello all my raspi2 dont boot with ubuntu-core-16-pi2.img  only red led is on  any idea? cmdline.txt:
[01:10] <overflyer> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline i think cmdline is wrong. can anyone help?
[01:11] <mwhudson> yeah, that was it
[01:11] <mwhudson> overflyer: sorry, don't know, you could try emailing the devices list
[01:58] <mup> PR snapcraft#893 opened: Add a script to retry autopktests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/893>
[02:30] <mwhudson> slangasek: is http://people.canonical.com/~vorlon/official-models/ still the best place to get model assertions from?
[02:39] <Ric> Possibly dumb question but is there a way put the core and a few snaps into an image that is easy to install on embedded devices.
[02:50] <boadie> Is there a way put the core and a few snaps into an image that is easy to install on many embedded devices?
[03:02] <mwhudson> hm my dragonboard image doesn't boot :(
[03:21] <liuxg> has anyone successfully followed the blog at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html to build the snapd? I succeeded it once. now, I am having this error "can't load package: package snap.amd64: cannot find package "snap.amd64" in any of". the detailed info is at http://paste.ubuntu.com/23449276/
[03:23] <liuxg> I removed "snap.amd64" in my "devtools" dir, and I cannot get it back any more. I thought it was a compiled file from building the snapd.
[03:40] <elfgoh> ogra_: just to be sure, this what you meant by flashing? https://youtu.be/LDN7QQ1-2c0?t=1m22s
[03:42] <elfgoh> Didnt seem to work for me. I am using Beaglebone black industrial Rev C
[05:58] <mup> Bug #1640386 opened: $SNAP_DATA and $HOME are not the same <Snappy:New> <https://launchpad.net/bugs/1640386>
[06:25] <Mirv> nessita: three weeks ago I heard it's something that is being fixed in store (or store checker tools, not sure) trunk, but not yet deployed. and later I got that you are a good one to ask about store topics.
[06:56] <zyga> o/
[07:05] <mup> Bug #1619258 changed: netplan should allow NICs to be disconnected and not stall the boot <Snappy:Invalid> <nplan (Ubuntu):Invalid> <https://launchpad.net/bugs/1619258>
[07:08] <foxmask> bonjello
[08:09] <dholbach> hey hey
[08:23] <didrocks> hey dholbach!
[08:27] <dholbach> salut didrocks
[10:41] <liuxg> zyga, ping
[10:45] <liuxg> zyga, I followed your instructions at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html to build the snapd at https://github.com/zyga/snapd/tree/hello-iface. The very first time, the build was succeessful. However, i did not see the "reboot" interface. Then I removed the "snap.amd64" file in the "devtools" directory. After that, I get the error like http://paste.ubuntu.com/23450405/. How can I get the "snap.amd64" file back? thanks
[10:51] <Mirv> nessita: the problem we have with that is anyway that ubuntu-app-platform (now in store) needs manual review for each upload, because of the warning about the "content:" field in the content interface definition, which is however required for the snap to function
[12:14] <renato__> Mirv,hey just tested the new package with unity8. Not running yet. Probably we need to export some env variables
[12:15] <renato__> Mirv, probably we need didrocks help
[12:21] <didrocks1> renato__: try tweaking the launcher and export MIR_CLIENT_PLATFORM_PATH=$SNAP/ubuntu-app-platform/usr/lib/$ARCH/mir/client-platform (if this is shipped by the new content snap)
[12:21] <didrocks1> this was the only thing to add Mir support
[12:21] <renato__> let me try
[12:51] <renato__> didrocks1, Mirv, http://paste.ubuntu.com/23450827/, do you know where I can find Mir logs?
[12:53] <didrocks1> I would say you don't access to the socket
[12:53] <didrocks1> but kgunn would be the one to ping about it
[13:05] <BjornT> hi. i'm getting (quite frequently) intermittent errors downloading the ubuntu-core snap while installing a local snap: http://pastebin.ubuntu.com/23450862/
[13:05] <BjornT> any ideas on what's wrong here? sometimes it does work, but mostly it doesn't
[13:09] <BjornT> actually, it seems like the CDN is broken. i'm trying in canonistack, and that host name maps to these ips: http://pastebin.ubuntu.com/23450880/
[13:10] <BjornT> if i add an entry in /etc/hosts to map the host name to 95.172.71.38 it works
[13:12] <BjornT> ev_: ^^^^
[13:25] <Mirv> renato__: right, ok so the QPA is now there at least
[13:26] <Mirv> the new snap is not yet in the store because each upload needs manual review at the moment, but it seems you got it from LP, which is good
[13:26] <renato__> Mirv, yes. I am trying to understand what is causing the app to fail to launch on unity8. Are you test app working?
[13:59] <ev_> BjornT: thank you, I’ve passed that on
[13:59] <ev_> and pointed them here
[14:27] <Mirv> renato__: I think we need to check with the U8 team indeed what are the expectations
[14:28] <Mirv> renato__: are you testing Unity8 on zesty or xenial overlay?
[14:28] <Mirv> I've that separate zesty machine I could try too
[14:28] <renato__> Mirv, xenial
[14:29] <renato__> Mirv, it was working with the old qt5/gtk-launcher. I am trying to find what is missing
[14:30] <sergiusens> BjornT ev we are seeing this in our testing too fwiw, thanks for looking into it
[14:32] <qengho> Do configure hooks need anything from snapcraft other than copying the hook/configure file and the optional YAML to expand the security permissions?
[14:37] <Mirv> renato__: ah, ok, then it must be something relatively small (I hope)
[14:37] <qengho> I have a configure hook I expect to run on "snap set". It doesn't.  """- Run configure hook for snapname (cannot snap-exec: cannot find hook "configure" in "snapname")"""
[14:40] <qengho> I peeked with strace. snapd lstat()s the configure hook file (ret 0), but then exits (val 1).
[14:41] <qengho> FWIW, is executable. 0755
[14:42] <renato__> Mirv, yes, probably is one missing env var :D
[15:03] <renato__> guys how I can solve this:
[15:03] <renato__> - Download snap "ubuntu-core" (423) from channel "stable" (received an unexpected http response code (500) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_423.snap?t=2016-11-10T14:59:42Z&h=f609260aa36b4327500712f9dfdeb8a059cb9b35)
[15:03] <renato__> I removed my snapd and re-installed it, and now I can not install any app
[15:09] <renato__> ok snap login did the trick
[15:13] <didrocks> qengho: quite puzzled, it does work for me (on an ubuntu core machine)
[15:13] <didrocks> qengho: did you try it there? it seems desktop ubuntu-core snapd doesn't have the same version, that could impact
[15:13] <mup> PR snapcraft#894 opened: store: send snapcraft version in a header <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/894>
[15:16] <qengho> didrocks: I have only tried on snapd-on-classic Z.
[15:16] <didrocks> qengho: try in a vm, do you mind keeping me posted?
[15:17] <didrocks> I definitively got the configure hook working here yesterday on it
[15:18] <faenil> guys, it seems /snap/bin is not in $PATH (environment: Zesty) even though there's a script that does that in profile.d, it seems like it's not used
[15:18] <faenil> known issue? or should I report a bug?
[15:18] <qengho> didrocks: grep "hook" /snap/${snapname}/meta/snap.yaml ?
[15:18] <qengho> faenil: what shell?
[15:19] <faenil> both unity7 and unity8
[15:19] <qengho> Maybe, echo $SHELL ?
[15:19] <faenil> then snap run <app> works in unity7, but not in unity (returns QXcbConnection error, it's not using Mir)
[15:19] <faenil> qengho: maybe?
[15:19] <faenil> not in unity8*
[15:20] <didrocks> qengho: wdym? no, there is nothing to refer in snap.yaml
[15:20] <qengho> didrocks: Thanks.
[15:20] <didrocks> qengho:  dropping the file as meta/hooks/configure is enough
[15:20] <qengho> didrocks: I was wondering if your yaml had something else. Thanks.
[15:20] <didrocks> no, just meta/hooks/configure, shebang (bash script), executable
[15:21] <faenil> qengho: that was a statement, not a question :D both under u7 and u8 PATH does not contain /snap/bin
[15:21] <sergiusens> didrocks if you need specific interfaces for your hook you need to define them in meta
[15:21] <faenil> (some bad english there, sorry)
[15:21] <didrocks> sergiusens: right, but here, I guess qengho just want first to have his configure script running :)
[15:21] <didrocks> like basic 1o1
[15:21] <sergiusens> ah, well I might take on this tomorrow or this evening as kyle is out this week
[15:22] <didrocks> let's see first if qengho reproduces his issue on ubuntu core
[15:22] <qengho> faenil: That profile.d part is the perview of ksh or bash or zsh or csh or tcsh or ipython ... I'm asking which shell you use.
[15:22] <didrocks> let me try my snap on desktop 16.04 at the same time
[15:23] <faenil> qengho: ah you mean terminal shell..zsh on unity7, vty on u8
[15:23] <didrocks> sergiusens: qengho: doesn't work with snapd on 16.04 FYI (didn't try the version in -proposed yet)
[15:23] <didrocks> unsure if the issue you have in Zesty is similar
[15:23] <didrocks> as it's a newer snapd
[15:24] <faenil> qengho: vty, still zsh it is
[15:25] <qengho> faenil: Will you please check if zsh reads from /etc/profile under your circumstances?
[15:25] <faenil> qengho: I will have a look. it's not my laptop and I don't use zsh myself, but let's see
[15:25] <faenil> (it's the team laptop)
[15:26] <faenil> although http://askubuntu.com/a/476435 suggests /etc/profile won't work with zsh
[15:28] <faenil> also https://bugzilla.redhat.com/show_bug.cgi?id=88457
[15:29] <qengho> faenil: that seems like a real bug. Pleasae advise in a bug report where snapd should also put its PATH alterationsfor ZSH users.
[15:29] <faenil> qengho: I have no idea, I'm not a zsh user :D someone in the team is, I'll ask around
[15:29] <faenil> .zshrc is a good bet, surely
[15:29] <qengho> faenil: you are until you run "chsh"? :D
[15:30] <faenil> zsh is not running on my laptop :D this is a shared laptop
[15:30] <faenil> but sure, I'll report a bug ;)
[15:30] <qengho> faenil: thank you.
[15:30] <faenil> qengho: should it be filed against snapd?
[15:34] <renato__> kgunn, hey, I am having problems to launch a snappy app on unity8:http://paste.ubuntu.com/23450827/, could you help me with that?
[15:38] <faenil> qengho: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1640514
[15:38] <mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <snapd (Ubuntu):New> <https://launchpad.net/bugs/1640514>
[15:41] <didrocks> faenil: you should add the upstream "snappy" project for upstream to consider it
[15:41] <faenil> didrocks: done
[15:43] <didrocks> thx!
[15:44] <mup> Bug #1640514 opened: /snap/bin is not added to the PATH when using zsh <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1640514>
[15:50] <roadmr> jdstrand: are you around?
[15:53] <jdstrand> roadmr: hi! I am
[15:53] <mup> Bug #1640386 changed: $SNAP_DATA and $HOME are not the same <Snappy:Fix Released> <https://launchpad.net/bugs/1640386>
[15:54] <roadmr> jdstrand: I'm testing r796 on staging, for the --plugs/--slots thing. I wanted your help figuring out an error...
[15:54] <jdstrand> roadmr: ok
[15:55] <roadmr> jdstrand: but I figured it out myself :) looks like our click-review invocation fumbles the order of parameters: https://pastebin.canonical.com/170282/
[15:55] <roadmr> jdstrand: still I'd appreciate sanity-check on my theory
[15:59] <jdstrand> roadmr: yes. overrides must be last after the snap with how argparse is configured
[15:59] <roadmr> jdstrand: ok, no problem, we can easily accommodate that in our code. Thanks :D
[15:59] <jdstrand> cool, np
[16:01] <noise][> renato__: and anyone else that had a problem with ubuntu-core snap (r423 from stable for amd64), the problem is resolved and downloads should be working again. Sorry for the inconvenience.
[16:12] <faenil> ogra_: have you read the bug report I linked?
[16:12] <faenil> (the one on redhat portaL)
[16:12] <faenil> bbl
[16:25] <mup> PR snapcraft#888 closed: Always respect go-buildtags <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/888>
[16:35] <faenil> ogra_: the zsh bug about "zsh does not source /etc/profile" was marked NOTABUG
[16:35] <faenil> so I don't think that's going to happen ;)
[16:36] <faenil> the feature was there, and was removed on purpose
[16:36] <faenil> so if you want to support running snaps from zsh, it seems changing zsh behaviour is not an option :/
[16:41] <ogra_> faenil, well, it points to other bugs that were closed with pointing to adding that change in ~/.zshrc
[16:41] <faenil> yes
[16:41] <ogra_> (or rather to /etc/skel/.zshrc )
[16:42] <ogra_> did you check if our package ships that file and if it has these changes ?
[16:42] <ogra_> if so, it is actually a matter of the user to update his config in the homedir accordingly
[16:43] <ogra_> there is no way that is a snappy bug ... snappy uses the agreed shell standard of using /etc/profile.d ...
[16:43] <faenil> ogra_: sure, I agree with you
[16:46] <niemeyer> ogra_, faenil: We can easily patch the stock zsh profile in Ubuntu to make sure the proper path is included, I'd guess?
[16:46] <ogra_> that was what i thought ...
[16:46] <ogra_> but it would mean an ubuntu specific delta
[16:47] <ogra_> (though perhaps we could get it into debian ... not sure if they'd accept that)
[16:48] <faenil> niemeyer: that would be ubuntu specif though :/
[16:48] <faenil> specific*
[16:49] <niemeyer> faenil: Indeed, but it's not uncommon for tooling to have distribution-specific path handling
[16:49] <niemeyer> faenil: The alternative would be to upstream into the zsh source code itself
[16:50] <faenil> ogra_: we do not seem to ship .zshrc
[16:50] <niemeyer> faenil: Might be worth attempting to push this upstream
[16:50] <faenil> niemeyer: +1
[16:51] <niemeyer> faenil: +1 as well.. who's going to work on that? :)
[16:52] <faenil> not sure, someone whose job task include working on snapd? :) or someone who has enough spare time to add that on top
[16:55] <niemeyer> faenil: We need help with that sort of thing, as we can't keep our eyes on every single software that might interact with snaps
[16:56] <niemeyer> The right file to tweak is /etc/zsh/zshenv
[16:56] <faenil> niemeyer: I know, I know..we're in the same company :P each busy on his own bits :D
[16:57] <ogra_> sswell, whichever team maintains zsh should do it ...
[16:57] <ogra_> :)
[16:58]  * ogra_ glances in foundations direction ...
[16:58] <faenil> haha :)
[17:15] <SuperJonotron> how can you access the  user invoking a snappy binary, normal methods such as $SUDO_USER and whoami don't seem to work
[17:21] <qengho> SuperJonotron: You can't. And you can't do anything with it anyway. Don't "sudo".
[18:39] <n0c_> how do I use docker with snap?
[18:39] <n0c_> I did `snap install docker`
[18:39] <n0c_> but, how do I start the daemon?
[18:40] <lazyPower> sudo service snap.docker.dockerd start
[18:40] <lazyPower> n0c_ ^
[18:41] <n0c_> thanks! where would I have learned about that?
[18:41] <lazyPower> the confined docker snap is still pretty new. lool - any hints for n0c_ on where they can follow along at home?
[18:42] <lool> n0c_m lazyPower: https://lists.ubuntu.com/archives/snapcraft/2016-October/001382.html is the best compilation, the gdoc might not be fully up-to-date but I could fix any issues there
[18:43] <lool> n0c_: this should soon work out of the box, but a bug prevents it right now
[18:43] <lazyPower> lool - does uapp explorer not have support for listing things like README's? I would think having a canonicalized wiki style place for this information would be better than a gdoc.
[18:43] <lazyPower> just my 2 cents though
[18:43] <lool> lazyPower: yeah good point, link frmo description would be good
[18:43] <lazyPower> in terms of discoerability, a google doc is the equivalent of not having any information out there, as they dont get indexed by google.
[18:44] <jdstrand> tyhicks: I decided to take a look at bug #1592022 and think I found the solution. Can you review my comments in trello for sanity? (you should have an email now)
[18:44] <lazyPower> we ran into this ourselves when we were doing all of our annotation in gdocs, so we just moved to GH + MD and called it a day
[18:44] <mup> Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592022>
[18:44] <lool> Sure, the point is I can update it to keep it up-to-date, it's not meant to be permanent, eventually it will go away
[18:44] <jdstrand> tyhicks: it seems completely trivial to fix
[18:44]  * lool => dinner &
[18:44] <lazyPower> thanks lool, :)  <3
[18:49] <mup> PR snapcraft#876 closed: repo: allow for architecture-specific stage-packages <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/876>
[18:50] <jdstrand> oh interesting-- that ^ snapcraft PR would've helped in my seccomp investigation
[18:52] <jdstrand> popey: do you still have the wine snap around?
[18:53] <sergiusens> jdstrand there for next time I guess ;-)
[18:53] <jdstrand> :)
[18:53]  * jdstrand -> lunch
[18:53] <noise][> FYI, we are still troubleshooting an issue with downloads of ubuntu-core r423 (stable, amd64)
[19:00] <popey> jdstrand: I have _a_ wine snap, yes.
[19:00] <popey> jdstrand: the one I currently have is built with --enable-win64.
[19:08] <popey> jdstrand: http://people.canonical.com/~alan/wine_1.6-git_amd64.snap  snapcraft.yaml -> http://paste.ubuntu.com/23452189/  'wine' launcher -> http://paste.ubuntu.com/23452191/
[19:46] <mup> PR snapcraft#894 closed: store: send snapcraft version in a header <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/894>
[19:55] <mup> PR snapcraft#895 opened: Release changelog for 2.22 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/895>
[20:13] <jdstrand> popey: I don't know what --enable-win64 does. does that mean you can't run win32 on amd64 or does that enable 64bit in addition to 32bit?
[20:13] <jdstrand> I guess I can just build from the yaml
[20:14] <jdstrand> ah "The problem is that by itself, that build will only run applications compiled for 64-bit Windows"
[20:30] <popey> jdstrand: yeah
[20:51] <noise][> Update: issue with downloads of ubuntu-core r423 (stable, amd64) has been resolved
[21:31] <mup> Bug #1595813 changed: implement upower interface <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1595813>
[22:06] <mwhudson> hey
[22:06] <mwhudson> snap create-user leaves a \r at the end of authorized_keys :)
[22:54] <skillman> could anyone help me with first time setup for ubuntu core?
[23:19] <jdstrand> sergiusens: hey, are there limitations to stage-packages? if I stage 'wine1.6' then it barfs. I have to edit _get() from repo.py to:
[23:19] <jdstrand> except SystemError:
[23:19] <jdstrand>     logger.debug("ERROR: could not mark '%s' to install")
[23:19] <jdstrand> sergiusens: but it actually continues and marks it ok
[23:29] <jdstrand> sergiusens: actually, it didn't seem to mark it ok. I staged wine1.6, wine1.6-amd64 and wine1.6-i386:i386 and it didn't pull wine1.6 (it did pull the other two
[23:57] <jdstrand> popey: hey, can you build without --enable-win64? I can't get it to build here and can't get snapcraft to stage-packages what is in the archive so I'm stuck