[00:19] <liuxg> does anyone know how to select a different mirror server in ubuntu core using command. The reason for this is that some of the servers are far away from my region, and the build process is very long. thanks
[00:20] <liuxg> I am now using a ubuntu core device to build a snap.
[05:47] <mup> Bug #1648702 opened: We don't have a network interface that allows only local communication <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1648702>
[07:03] <mup> Bug #1648712 opened: Whole /etc content from host accessible to the snap <Snappy:New> <https://launchpad.net/bugs/1648712>
[07:49] <FJKong> liuxg: you can edit config file directly
[07:49] <liuxg> FJKong, but it is too much work. do you mean the sources.list file?
[07:50] <liuxg> FJKong, for some of the channels, there could be no correspondence.
[07:52] <FJKong> just %s/a/b/cgi with vim, you can skip some of it, this should be very fast
[07:54] <FJKong> backup before editing, by the way
[08:51] <mup> PR snapd#2442 opened: snap/snapenv: don't obscure HOME if snap uses classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2442>
[08:54] <mup> PR snapd#2443 opened: removing circular dependency between snapstate and hookstate <Created by cyberb> <https://github.com/snapcore/snapd/pull/2443>
[08:54] <mup> PR snapd#2444 opened: debian: depend on snap-confine at least 2.19 <Created by zyga> <https://github.com/snapcore/snapd/pull/2444>
[09:05] <mup> PR snapd#2445 opened: cmd/snap,tests: alias support in snap run <Created by pedronis> <https://github.com/snapcore/snapd/pull/2445>
[09:08] <mup> PR snapd#2446 opened: cmd/snap-confine: fix compilation on platforms with gcc < 4.9.0 <Created by zyga> <https://github.com/snapcore/snapd/pull/2446>
[09:12] <mup> PR snapd#2447 opened: many: fixes cherry-picked for the 2.19.1 release <Created by zyga> <https://github.com/snapcore/snapd/pull/2447>
[09:17] <mup> PR snapd#2428 closed: debian: add dependencies and build rules for snap-confine <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2428>
[10:26] <mup> PR snapd#2446 closed: cmd/snap-confine: fix compilation on platforms with gcc < 4.9.0 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2446>
[11:17] <palasso> Hello, I noticed from times to times spam gets through into the snapcraft mailing list. Shall spams be removed from the archive?
[11:18] <palasso> Some include links which I haven't clicked
[11:27] <mup> PR snapd#2435 closed: store: retry assertions <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2435>
[11:28] <mup> Bug #1648777 opened: writing a (3GB sized) x86 image to a 3GB SD card makes the filesystem resizing being skipped <Snappy:New> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1648777>
[11:29]  * ogra_ loves how filing a bug brings an IRC highlight as freebie every time :P
[11:32] <palasso> Those are some spams I found on the snapcraft mailing list (some of which include links to files) http://pastebin.com/eeXLTfT4
[11:43] <dslul> hello
[11:43] <dslul> has anyone managed to get this tutorial work https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ ?
[11:43] <dslul> in particular mir kiosk
[11:43] <dslul> on a virtual machine
[11:43] <dslul> it gives Mir fatal error: Failed to get frontbuffer
[11:44] <dslul> where can I file this bug?
[11:45] <didrocks> dslul: hey, I think kgunn will be interested in your feedback
[11:45] <didrocks> he should show up a little bit later on on this channel
[11:56] <blunden> is there a way to pass environment variables to snap packages? ie. I want to pass PORT and ROOT_URL to a rocket.chat server installed via snap
[11:57] <blunden> but they don't get picked up properly when exported
[11:58] <blunden> I also think the use of PORT is kind of stupid as there is bound to be another application reading that generic variable as well
[11:58] <didrocks> blunden: yeah, environment is stripped. You need to use configure hook for this
[11:58] <blunden> didrocks: is that documented somewhere?
[11:58] <blunden> I'm clearly missing the correct search term when googling :P
[11:59] <didrocks> blunden: well, TBH, the documentation isn't there yet
[11:59] <didrocks> but
[11:59] <didrocks> I have an example!
[11:59] <blunden> that works too :D
[11:59] <didrocks> https://github.com/ubuntu/snow-on-me-snap
[11:59] <didrocks> I've created a very generic configure hook: https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
[12:00] <didrocks> it enables to set and remove variables that are stored in a file
[12:00] <didrocks> that your app can pick up
[12:00] <didrocks> snap set <snap_name> key=value
[12:00] <didrocks> (/!\ you need to do it on ubuntu core, doesn't work well yet with snapd version on desktop)
[12:01] <didrocks> and a simple nodejs example on watching for a change and picking it up: https://github.com/ubuntu/snow-on-me-snap/blob/master/main.js#L71
[12:01] <blunden> this is on a normal ubuntu server 16.04.1 instance
[12:02] <blunden> so this is something that needs to get upstreamed to the rocket.chat project?
[12:02] <didrocks> yeah, I would suggest that
[12:02] <didrocks> supporting dynamic configuration and such
[12:03] <didrocks> (would be a nice contribution I think :))
[12:03] <blunden> I was hoping for something that I could do right now :)
[12:04] <blunden> I really don't want to bloat up this server with all the cruft their project depends on
[12:05] <didrocks> I don't think there is other way, you can modify their snap as well and build it yourself if you have the source
[12:05] <didrocks> then, a small wrapper watching for the config file
[12:06] <didrocks> once the config file is there, reading it and exporting PORT before exec their service
[12:07] <blunden> ideally they should just read the values from the config file instead of using a bunch of very generically named env variables in my opinion
[12:07] <blunden> thanks for the examples though :)
[12:08] <didrocks> yw! :)
[12:08] <blunden> didrocks: that "snap set" part where you set the port... is that using your hook too?
[12:10] <blunden> ah, it said so above :)
[12:14] <didrocks> blunden: yes :)
[12:14] <blunden> and by "you can only set on of those" you mean that they need to be set one at a time?
[12:15] <didrocks> blunden: no, just setting one from the supported keys in the configure hook
[12:15] <didrocks> so, in that case port and title
[12:15] <didrocks> you can either do:
[12:15] <didrocks> snap set <snap_name> port=4242 title="blablabla"
[12:15] <didrocks> or just
[12:15] <didrocks> snap set <snap_name> port=4242
[12:16] <didrocks> or even snap set <snap_name> port=""
[12:16] <didrocks> which will remove the key from the configuration
[12:16] <blunden> that's not how I read "Of course, you can set only one of those parameters."
[12:16] <blunden> ooh
[12:16] <blunden> nvm
[12:17] <blunden> I misread it
[12:17] <blunden> I basically read it as "Of course, it's only possible to set one of those parameters"
[12:18] <blunden> the sentence is ambiguous
[12:19] <blunden> now that I look at it more, your example looks very nice and generic
[12:20] <blunden> thanks again
[12:23] <didrocks> yw :)
[12:24] <didrocks> blunden: do not hesitate to rephase it (PR accepted), as not being a native speaker here… :)
[12:25] <blunden> ok
[12:26] <blunden> I'm home from work sick so I might just do that
[12:27] <didrocks> oh, hope you're feeling better soon!
[12:27] <didrocks> hoping*
[12:27] <blunden> thanks
[12:46] <blunden> pull request sent :)
[12:52] <didrocks> and merged, thanks!
[12:53] <blunden> np
[13:15] <morphis_> kyrofa: ping
[13:26] <dslul> kgunn, I had problems running mir kiosk, I wrote in private the details
[13:38] <didrocks> ogra_: oh, grub! that starts to all make sense then
[13:38] <ogra_> didrocks, yeah ... but we should still stay in sync with the content ... more worrying is that nobody noticed fuse support missing on all non x86 arches
[13:40] <didrocks> ogra_: well, nobody noticed the libpng which could be popular…
[13:40] <didrocks> ogra_: yeah, that was the point of the bug, to stay in sync :)
[13:41] <ogra_> didrocks, well, for libpng i'D expect most snaps to just ship it inside
[13:48] <didrocks> ogra_: what I did, until snapcraft strips it :p
[13:48] <ogra_> bah
[13:48] <ogra_> evil :)
[13:49] <ogra_> anyway, we got it now :)
[13:51] <kgunn> dslul: just not getting on for the morning, lemme catch up
[14:18] <renato__> popey, hey could you review this, please? https://code.launchpad.net/~renatofilho/ubuntu-docviewer-app/ubunut-app-platform/+merge/312913
[14:20] <jdstrand> ogra_: fyi, I don't know this, but suspect libfuse2 has something to do with lxd
[14:20] <jdstrand> perhaps historically. I don't know
[14:22] <ogra_> jdstrand, you mean thats the reason why grub-common depends on it ?
[14:23] <jdstrand> ogra_: oh, I idn't read your email that way. I didn't realize grub depended on it. ignore me then
[14:23] <ogra_> heh, i didnt either, i just found out before you pinged :)
[14:24] <ogra_> in any case we have core providing the fuse interface by default ... so not having the lib seeded will most likely cause issues on non x86
[14:33] <jdstrand> indeed
[14:34] <mup> PR snapd#2448 opened: Account for trusty-specifics in interfaces <Created by vosst> <https://github.com/snapcore/snapd/pull/2448>
[15:00] <didrocks> ogra_: while you are in those image rebuilding, will it be easy to have i2c enabled in rpi* images gadget snaps?
[15:12] <mup> Bug #1639981 opened: request canceled (Client.Timeout exceeded while awaiting headers) <Click Package Index:Confirmed> <Snappy:Confirmed> <https://launchpad.net/bugs/1639981>
[15:51] <ogra_> didrocks, i2c is enabled in the gadgets (in config.txt) ...
[15:51] <ogra_> does it not work ?
[15:54] <kyrofa> morphis_, good morning! What's up?
[15:56] <morphis_> ogra_: we need actual i2c slot definitions in the gadget snap.yaml
[15:56] <morphis_> kyrofa: morning!
[15:56] <morphis_> kyrofa: just wanted to find out what the outcome of the snapcraft/hooks meeting was :-)
[15:57] <kyrofa> morphis_, a redesign :P
[15:57] <kyrofa> morphis_, and it was placed behind another feature, which likely bumps it to the next cycle
[15:58] <didrocks> ogra_: snap interfaces didn't show up on my core
[15:58] <didrocks> ogra_: I didn't try since last week though
[15:58] <didrocks> is that recent?
[15:58] <didrocks> or should I reflash?
[16:01] <kyrofa> morphis_, now instead of specifying them in the YAML, you'll place them in the snap/hooks directory, and snapcraft will then generate the actual hooks via wrappers
[16:01] <morphis_> kyrofa: I see, so what would this mean in terms of actual dates
[16:01] <morphis_> next year I guess, right?
[16:02] <kyrofa> morphis_, yeah I'm afraid so
[16:02] <morphis_> hm
[16:21] <ogra_> diddledan, ah, well, it is enabled but there is no iterface, now i get it ... the gadgets didnt change in a while and will only for next stable release
[16:46]  * diddledan laughs maniacally about hijacking messages meant for didrocks
[17:34] <bregma> hey folks I', tryin to evaluate Ubuntu Core on a RasPi2... I can get it to boot but I never get the "Press enter to confiugure" prompt at the end of the boot sequence.  I'm using only the serial port on the Pi, is this supported or is a USB keyboard and HDMI monitor required for first boot?
[18:00] <kyrofa> bregma, probably a question for ogra_ if he's around
[18:03] <ogra_> bregma, serial should work, we enable both consoles by default
[18:03] <ogra_> (and both should show the press enter ... did you wait long enough ?
[18:03] <ogra_> )
[18:18] <mup> PR snapd#2425 closed: store: decode response.Body json inside retry loops <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2425>
[18:58] <mup> PR snapd#2449 opened: overlord/patch: patch to flag in the state required snaps from model <Created by pedronis> <https://github.com/snapcore/snapd/pull/2449>
[20:10] <kgunn> morphis: if you're still about...tried pa from the beta channel
[20:10] <kgunn> getting this
[20:10] <kgunn> http://pastebin.ubuntu.com/23604916/
[20:12] <bregma> ogra_, I've waited for 150 minutes now, still no prompt; I see the serial console enabled in the kernel command line and I see the boot messages, so I suspect the problem is whatever it that's does the first-time setup just can't cope
[20:13] <bregma> it's OK, other distros just let me get work done, so first impression of Ubuntu Core on the Pi2 is "doesn't work, don't bother" and I'll just move on
[20:15] <kyrofa> kgunn, pa doesn't like ACDC-- you didn't know that?
[20:16] <kyrofa> kgunn, do you see any denials from snappy-debug?
[20:16] <kgunn> lemme check
[20:18] <kgunn> kyrofa: ah...that's it...i shoulda checked...
[20:19] <kgunn> reinstalling with --demode
[20:21] <kgunn> well..it seems it's playing someplace but i don't hear it
[20:22] <kgunn> maybe a prob with my vm?
[20:23] <kyrofa> kgunn, still seeing something like this? http://pastebin.ubuntu.com/23604968/
[20:25] <kgunn> kyrofa: after devmode...now looks like this
[20:25] <kgunn> http://pastebin.ubuntu.com/23604974/
[20:25] <kyrofa> Huh, even in devmode?
[20:25] <kyrofa> Oh wait, allowed, nevermind
[20:30] <kyrofa> kgunn, I assume the previous denial was from the lack of a home interface?
[20:32] <kgunn> that's right, it could access it's home
[20:33] <kgunn> kyrofa: i'm wondering if it's the sound device selected by this vm
[20:33] <kyrofa> kgunn, yeah I wouldn't be surprised. Honestly I'm not sure I've ever tried playing audio in a VM before. KVM?
[20:59] <Guest78889> what basic thing am I missing. I have ubuntu core up and running on a pi3. How do I install nano or samba?
[21:00] <kyrofa> Guest78889, remember that ubuntu core uses snaps, not debs
[21:00] <kyrofa> Guest78889, `snap find nano` shows nano-editor as an option. Have you tried that?
[21:01] <kyrofa> (I have not)
[21:01] <Guest78889> yes I have
[21:01] <Guest78889> it doesn't find it
[21:02] <kyrofa> Guest78889, nano-editor.nano ?
[21:02] <kyrofa> Works for me
[21:02] <Guest78889> when I look at the web page version of the store I can find nano-editor but then download is only amd64
[21:02] <kyrofa> (just tried it)
[21:02] <kyrofa> Oh, I see
[21:03] <kyrofa> Perhaps rws only published an amd64 version, then
[21:03] <Guest78889> seems that way for everything I could think of searching for
[21:03] <Guest78889> so I thought I must be missing something
[21:03] <Guest78889> or is this all just that new
[21:07] <kyrofa> Guest78889, most snaps are provided by developers. Looks like rws build nano on their own amd64 machine instead of multiple architectures
[21:54] <mup> PR snapd#2391 closed: Discard mount namespace on a content i/f plug connect/disconnect <Created by albaguirre> <Closed by albaguirre> <https://github.com/snapcore/snapd/pull/2391>