[06:38] <dholbach> good morning
[06:43] <ejat> hi, how can i upgrade
[06:43] <ejat> Name          Date       Version Developer
[06:43] <ejat> ubuntu-core   2015-08-28 1       ubuntu
[06:43] <ejat> to the latest?
[06:47] <ejat> ?
[06:50] <didrocks> ejat: hey, there is unfortunately no upgrade path between ubuntu core 15.04 and 16, you will need to reinstall
[06:51] <ejat> on thanks didrocks
[06:56] <ejat> https://developer.ubuntu.com/en/snappy/start/#snappy-azure <-- how to get the 16.xx to azure .. the same step ?
[07:01] <nhaines> ejat: you may need to wait until Ubuntu Core is released.
[07:04] <didrocks> yeah, it's only beta3 for now, we have images for amd64, x86 and pi2
[07:13] <Quacky2200> Hey, I normally package my application into a deb with the right binaries, as it's a node.js, how could I make sure it downloads a stable release from github and make sure to install the binaries, or should I use the nodejs plugin (it would install the necessary node dependencies right)?
[07:36] <Quacky2200> If I wanted a snap to pull from GitHub, does it always pull the latest source or the latest release source?
[07:42] <Son_Goku> zyga, how will this handle more than one different core snap being used on the same system?
[07:43] <Son_Goku> for example: ubuntu 14 core snap, ubuntu 16 core snap, fedora 24 core snap, centos 7 core snap, opensuse 42.1 core snap, mageia 6 core snap all being used by different snaps
[07:43] <zyga> Son_Goku: I don't know, let's make this a sprint topic
[07:43] <Son_Goku> the snap-confine code *look like* it only can handle one core snap
[07:43] <zyga> Son_Goku: yes, right now only one snap is supported
[07:44] <zyga> Son_Goku: technically snap-run should probably just tell it wich one to use
[07:44] <zyga> Son_Goku: but let's discuss the details at the sprint
[07:44] <Son_Goku> sure
[08:22] <ejat> ok noted nhaines n didrocks
[09:20] <popey> is there some way to recover from:-
[09:20] <popey> popey@localhost:~$ snap list
[09:20] <popey> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
[09:22] <zyga> popey: check why snapd stopped
[09:22] <OerHeks> popey, what is the status of snapd.refresh.service ?
[09:23] <OerHeks> systemctl status snapd.refresh.service >> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592503
[09:23] <mup> Bug #1592503: "snapd.refresh.service" fails to start on startup <amd64> <apport-bug> <xenial> <Ubuntu GNOME:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1592503>
[09:24] <popey> hm, will poke at it some more
[09:24] <popey> thanks
[09:46] <ogra_> popey, did your board switch channels again ?
[09:47] <ogra_> (the fw_setenv hack i gave you recently might not be persistent, it doesnt switch the channel, only forces the working ubuntu-core)
[10:16] <popey> ogra_: dunno, how can i tell?
[10:17] <ogra_> cat /proc/cmdline
[10:17] <ogra_> see which core is picked there
[10:17] <popey> 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=592 bcm2708_fb.fbheight=448 bcm2709.boardrev=0xa02082 bcm2709.serial=0xe377e4ab smsc95xx.macaddr=B8:27:EB:77:E4:AB bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=tty1,115200 elevator=deadline root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=ubuntu-core_424.snap snap_
[10:17] <ogra_> 424
[10:17] <ogra_> looks like it switched back to stable again
[10:17] <popey> :(
[10:18] <popey> is this install doomed?
[10:18] <popey> do i need to reflash to get to a known good state?
[10:18] <ogra_> dunno, you have to ask mvo if/how you can switch back to edge
[10:18] <popey> tempted to nuke from orbit
[10:18] <popey> as it seems badly broken
[10:18] <ogra_> you will need to reflash anyway at some point, there wont be a cross-grade option to go from ubuntu-core to core
[10:19] <popey> is core now in the unstable images?
[10:19] <ogra_> this bug is very serious though ... if you can, keep the SD
[10:19] <popey> so if i grab an image today I'll have the new shiny
[10:19] <popey> ok, happy to keep it to poke at it
[10:19] <ogra_> right, it is in the dailies (they ahve some issues though) and in the new beta
[10:20] <popey> if i go for beta3 (which I think I saw announced yesterday?) will I be on dailys?
[10:20] <ogra_> you will be a few days behind the daily
[10:21] <popey> but will it update to daily?
[10:21] <ogra_> oh, wait, i dont think we released the arm images yet
[10:21] <ogra_> no
[10:21] <ogra_> it will only update to the next beta set of snaps
[10:21] <ogra_> dailies are built with the edge channel, betas with the beta one
[10:22] <ogra_> (anfd thechnically the board should never ever switch channels on its own :P )
[10:23] <popey> heh
[10:32] <zyga> tyhicks: hey
[10:34] <zyga> tyhicks: I've addressed most of the things you pointed out, I'm just testing the far simplified apparmor profile
[10:34] <zyga> tyhicks: can you please have a look, I didn't squash or rebase anything
[11:32] <mup> PR snapd#2139 opened: cmd/snap: tweak unknown command error message <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2139>
[11:48] <mup> PR snapd#2140 opened: snap: validate and stringify plug/slot attributes early <Created by pedronis> <https://github.com/snapcore/snapd/pull/2140>
[12:02] <mup> PR snapcraft#866 opened: Bug/1619193 <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/866>
[13:19] <mup> PR snapd#2131 closed: tests add spread test for prepare-device customizing device init/registration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2131>
[13:48] <zyga> tyhicks: if you are around I could use a re-review of the media-sharing branch
[13:58] <popey> ogra_: think I should file a bug for my pi flipping channel?
[13:59] <ogra_> popey, i the the one you filed is sufficient
[14:00] <popey> ok
[14:07] <tyhicks> zyga: hey - I'll take a look
[14:07] <tyhicks> zyga: I need to take care of a couple other quick things first
[14:15] <Quacky2200> @thibautr_ @didrocks - I just got your email. I thought I might as well tell you I'm here in case you want to chat rather than email. I'm thinking of just trying to package my snaps similarly to debs with binaries rather than trying to build them separately.
[14:15] <nothal> Quacky2200: No such command!
[14:16] <Quacky2200> thibautr_    didrocks - I just got your email. I thought I might as well tell you I'm here in case you want to chat rather than email. I'm thinking of just trying to package my snaps similarly to debs with binaries rather than trying to build them separately.
[14:27] <didrocks> Quacky2200: oh, excellent! Do not hesitate to ask questions here if you have any :)
[14:27] <didrocks> (in some meetings right now)
[14:28] <tyhicks> zyga: looking now
[14:34] <apol> hi, I'm working on a snapd client. when I call the actions calls (i.e. POST /v2/snap/something) I get a 401 Unauthorized error message. Could anybody point out how should I acquire the privilege?
[14:34] <mup> PR snapd#2141 opened: overlord/devicestate: don't spam the debug log on classic <Created by chipaca> <https://github.com/snapcore/snapd/pull/2141>
[14:44] <Quacky2200> @apol is it your own API? You will probably need a token to use the api
[14:44] <nothal> Quacky2200: No such command!
[14:45] <apol> Quacky2200: is that a wild guess? it's not my own API, I'm writing a client that talks to the official snapd
[14:46] <Quacky2200> Well the 401 error means that the client is actually getting a connection and since a 401 means you're unauthorised, then it means you can't use it without authorisation. Typically API's use a token to authorise a user rather than credentials.
[14:48] <Quacky2200> apol: yes it's a guess...
[14:49] <apol> yes, I know what a 401 is and I've read the documentation
[14:49] <apol> I was hoping there would be someone here that knows how it actually works
[14:50] <Quacky2200> apol: Sorry I can't help more, however, did you use it on something that worked before?
[14:51] <apol> hm? snap cli client works as long as I use sudo, so I'm guessing we'd need to use policykit and an external process, but I'm not entirely sure
[14:53] <Quacky2200> Why would policykit send a 401 request, surely policykit would just block the request altogether?
[14:54] <apol> I'm not using policykit, I'm using the same socket as default
[14:54] <Quacky2200> Oh sorry, I apologise -_-
[15:04] <mup> Bug #1633111 opened: Missing API documentation for /v2/snaps/[name] POST <Snappy:New> <https://launchpad.net/bugs/1633111>
[15:05] <apol> Quacky2200: the answer was in the docs, FYI: Authentication over the unix socket is delegated to UNIX ACLs, and uses SO_PEERCRED to determine privilege levels. In essence this means that a user will be either authenticated or trusted, with the latter restricted to the superuser.
[15:06] <Quacky2200> apol: Ahh I'm glad you found the answer :)
[15:14] <mup> PR snapd#2141 closed: overlord/devicestate: don't spam the debug log on classic <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2141>
[15:17] <tyhicks> zyga: review done!
[15:37] <oparoz> Hello, 16.10 can't load any snaps, they segfault. Any issue logged yet for that?
[15:38] <didrocks> not that I know of, maybe open one with some coredumps info if you can?
[15:39] <oparoz> Thanks didrocks. It's just been reported by a user, so I'll see if he can do that
[15:46] <didrocks> great! thanks oparoz
[16:21] <mup> PR snapd#2142 opened: tests: skip auto-mount and auto-import tests on systems without trusted test keys <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2142>
[16:23] <mup> Bug #1633141 opened: gadget.yaml should specify disk/volume image sizing behavior <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1633141>
[16:31] <mup> PR snapd#2143 opened: overlord: check that the first installed gadget matches the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2143>
[16:53] <mup> PR snapd#2144 opened: overlord/snapstate: skip removing the snap on install if it's in the seed dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/2144>
[16:55] <Croepha> hi, is anyone familiar with an issue where running /snap/bin/ubuntu-image fails when calling snap prepare-image with a complaint about opening the model assertion with no such file or directory, but when I run snap prepare-image directly with the same arguments it works?
[17:05] <mup> PR snapcraft#867 opened: Handle 'broken' validations that don't match refresh-control <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/867>
[17:20] <mup> PR snapcraft#868 opened: Parametrize call args for pluginhandler <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/868>
[17:28] <mup> PR snapd#2144 closed: overlord/snapstate: skip removing the snap on install if it's in the seed dir <Created by chipaca> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2144>
[17:32] <mup> PR snapd#2142 closed: tests: skip auto-mount and auto-import tests on systems without trusted test keys <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2142>
[18:22] <zyga> tyhicks: thanks
[18:28] <zyga> tyhicks: let me know if the explanation I gave makes sense
[18:28] <tyhicks> zyga: it did, I'm happy with the PR :)
[18:52] <Croepha> so, if snaps run in a separate filesystem namespace, then accessing the cwd doesn't work reliably right? and is this a known issue? ie. accepted issue?
[18:53] <kyrofa> Croepha, indeed, the cwd might not be accessible from the snap
[18:55] <Croepha> kyrofa, gotcha ok thanks, that hung me up for a while couldn't figure out why the ubuntu image command couldn't find my files, newb mistake i guess
[18:58] <kyrofa> Croepha, I'm not familiar with ubuntu-image yet, but that's not part of the snap's documentation or anything?
[19:00] <Croepha> kyrofa: this is what I was following
[19:00] <Croepha> https://github.com/CanonicalLtd/snappy-docs/blob/master/core/images.md
[19:00] <Croepha> seems to be the most up to date
[19:03] <kyrofa> Croepha, and you installed it in devmode?
[19:04] <Croepha> yea
[19:04] <zyga> Croepha: if that happens we move to /var/lib/snapd/void
[19:05] <kyrofa> Croepha, you should probably log a bug against snappy-docs, then
[19:08] <Croepha> so. fyi, to fix, I just bind mounted stuff into my home directory
[19:08] <Croepha> and used that
[19:08] <Croepha> that seemed to work across snap commands
[19:16] <zyga> tyhicks: I just added one more patch
[19:16] <zyga> tyhicks: I need to review the code later for more cases of this
[19:17] <zyga> tyhicks: mount -o bind,r?{shared,private,slave} seems to really be different than two separate operations
[19:17] <zyga> tyhicks: I reviwed the .json files and saw that /etc/alternatives was "shared" (like /media) so I fixed that
[19:18] <zyga> tyhicks: I'll check the kernel sources and play with more examples when I'm properly awake, just FYI
[19:18] <tyhicks> zyga: ok, I'm off tomorrow so I won't be able to review
[19:18] <zyga> tyhicks: wanna see it now? :)
[19:18] <zyga> (it's short)
[19:19] <tyhicks> zyga: oh, I thought you had more changes to make
[19:19] <tyhicks> yeah, I'll look now
[19:19] <zyga> the .json files now look good (only one shared)
[19:19] <tyhicks> zyga: have you pushed yet?
[19:20] <zyga> https://github.com/snapcore/snap-confine/pull/168/commits/a6bedacfc6821c40ec39fa309ec2e5beee737614
[19:20] <mup> PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168>
[19:20] <zyga> just now
[19:21] <zyga> oh, I see a typo there (rslave vs slave)
[19:23] <zyga> pushed again
[19:24] <tyhicks> I left the same comment seconds before you pushed :)
[19:26] <zyga> Thanks, I'll do the rest tomorrow, I'll try to get back to sleep now
[19:27] <tyhicks> good night
[19:28] <wililupy> Trying to build an Ubuntu-Core image and I get the following error:
[19:28] <wililupy> cannot fetch and check prerequisites for the model assertion: account-key
[19:29] <wililupy> and a key I don't recognize. I'm using the doc in https://github.com/CanonicalLtd/snappy-docs/pull/13
[19:38] <wililupy> Ahh, figured it out.
[19:39] <wililupy> How do I delete a registered key in snapcraft?
[19:56] <niemeyer> jdstrand: Heya
[19:56] <niemeyer> tyhicks: Heya^2
[19:56] <jdstrand> niemeyer: hey
[19:56] <niemeyer> How're things going in snap-confine land?
[19:56] <tyhicks> hi!
[19:57] <tyhicks> niemeyer: good as far as I know :)
[19:57]  * jdstrand too
[19:59] <niemeyer> tyhicks, jdstrand: Anything pending in terms of reviews for media sharing, etc?
[20:00] <tyhicks> niemeyer: I've reviewed everything that zyga has pushed and it has my ack
[20:00] <tyhicks> niemeyer: he spotted something a little odd in the json files for the test and he's going to take a look at that tomorrow
[20:00] <tyhicks> niemeyer: but I think it is just about ready to be merged
[20:00] <niemeyer> \o/
[20:00] <niemeyer> tyhicks: Great to hear!
[20:01] <niemeyer> This one had me worried for a little while
[20:01] <tyhicks> niemeyer: it is great news but I have to say that zyga deserves the biggest pat on the back
[20:01] <tyhicks> yeah, that was some complex stuff
[20:01] <niemeyer> tyhicks: Yeah, he did a great job there
[20:02] <niemeyer> despite the bad timing
[20:02]  * tyhicks nods
[20:06] <jdstrand> yeah, that was pretty crazy
[20:07] <jdstrand> it happily fixed an issue in mountinfo along the way
[20:07] <zyga>  hmm?
[20:07] <zyga> which issue?
[20:07] <zyga> (yeah, I cannot get back to sleep again)
[20:07] <jdstrand> the docker workaround
[20:07] <zyga> damn week is so messed up ;)
[20:08] <zyga> ah
[20:08] <zyga> yes, I know what you are talking about now
[20:46] <qengho> :w
[20:46] <qengho> Gah.
[20:49] <kyrofa> qengho, that's a gnarly mustache
[20:51] <zyga> all I see is a duck face
[20:51] <zyga> kyrofa: how's your jetlag?
[20:59] <kyrofa> zyga, killer man. I got some weird stomach bug, too
[21:08] <zyga> kyrofa: for real? here you have to go to a market to buy those
[21:08] <kyrofa> zyga, hahaha
[21:08] <zyga> kyrofa: I'm sorry, hope you get better soon
[21:08] <kyrofa> zyga, thanks, yesterday was dreadful but I seem to be on the mend today
[21:10] <Quacky2200> I don't mind yet lag or being ill too much as to the continue of coughing to extremism, the repetitive dreams or vertigo
[21:10] <zyga> I did a loop on the bus here today, the outside of town is totally different, I'm going to see if I can get somewhere far tomorrow and snap some photos
[21:15] <kyrofa> zyga, yeah, try to get out in the country a bit! Go eat in a small town
[21:17] <zyga> kyrofa: I feel like I do every day
[21:18] <kyrofa> zyga, I felt like I barely saw the sky there :P
[21:18] <zyga> kyrofa: this place is different, it's the old part of the city, I live within the city walls :)
[21:18] <zyga> kyrofa: I wish I had two weeks here
[22:12] <blackboxsw> Question out of left field for folks. If I continue to release snaps the the stable channel, they are not automatically updated are they? From the docs it looks like the user would have to perform a snap refresh <mysnap>  http://snapcraft.io/docs/core/updates
[22:14] <qengho> blackboxsw: That's a great question. Users get updates automatically from whatever channel they got the package from last time.
[22:15] <qengho> blackboxsw: snapd has a scheduler. I don't know the delay, but on average, a could of hours after your upload.
[22:15] <qengho> blackboxsw: make sure it's marked "published" in the store.
[22:15] <blackboxsw> qengho, thanks so much for clarification
[22:16] <blackboxsw> qengho, were there other docs I should have looked at to glean that information? http://snapcraft.io/docs/core/update seems to mention the transactional refresh, but I didn't see mention of snapd here
[22:16] <qengho> blackboxsw: it feels a little weird to me that it's automatic, so I could be wrong in suggesting it's always like that.
[22:17] <blackboxsw> from http://snapcraft.io/docs/core/snapd I see "A store where developers can easily make their software directly available to users and from which devices can automatically pull updates on a daily basis."
[22:18] <qengho> blackboxsw: the code that implements that is so new that it could be the web site hasn't synch'ed up with reality.
[22:18] <blackboxsw> +1 qengho
[22:21] <qengho> blackboxsw: https://github.com/snapcore/snapd/blob/98c8e937625ce3134cf17025d8f0eb3e1016259a/docs/autoupdate.md
[22:23] <blackboxsw> excellent reference thanks qengho
[22:23] <qengho> blackboxsw: Welcome. Make something awesome!
[22:23] <blackboxsw> count on it ;)
[22:34] <wililupy> is the gadget snap for amd64 still called pc?
[22:41] <wililupy> Does anyone have an example assertion for building a vanilla ubuntu-core image? The one I used a month ago no longer works, and I am not trying to build on Pi, so the one in the documentation doesn't serve me too well.........
[22:42] <wililupy> I am using "gadget": "pc" and it is failing right after it says fetching pc