[01:50] <blackboxsw> hi folks, I've just started seeing failures based on the systemd triggered auto-update of installed snaps
[01:52] <blackboxsw>  cannot refresh snap-declaration for "<mysnap>": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/<myid>: dial tcp: lookup assertions.ubuntu.com on 127.0.1.1:53: server misbehaving
[01:52] <blackboxsw> have we changed something with the snap store recently that could cause some of the snap auto-refresh services to fall over?
[03:46] <mup> PR snapd#2166 opened: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2166>
[03:47] <mup> PR snapd#2163 closed: debian: update dependency of ubuntu-core-launcher to snap-confine <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2163>
[03:57] <dr1337> hey guys, anyone know where the snappy builder repos are being pulled from?
[03:57] <dr1337> like this one ? https://github.com/alexgg/ccimx6sbc-snappy
[04:08] <qengho> blackboxsw: No idea, without looking in source code.
[04:13] <blackboxsw> qengho, no worries, it seems intermittent
[04:13] <blackboxsw> I've seen many clients already update our snap via the auto-refresh mechanism.
[04:13] <blackboxsw> so I don't know if it was a temporary 404 of some content during a rollout
[04:24] <dr1337> Does anybody know what SNAP_CONTEXT environmental variable is for?
[04:46] <qengho> https://github.com/snapcore/snapd/search?utf8=%E2%9C%93&q=SNAP_CONTEXT
[05:15] <mup> PR snapd#2165 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2165>
[05:15] <mup> PR snapd#2166 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2166>
[05:23] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/172/files
[05:23] <mup> PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172>
[05:24] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/172/files
[05:24] <zyga> oh, sorry
[05:29] <jdstrand> zyga: heh, nice :)
[05:30] <jdstrand> I'm not going to review it right this second as I want to be more awake for the review, but added to my list
[05:35] <dr1337> qengho: thanks
[05:45] <mup> Bug #1621525 changed: classic environment variables for daemon snaps <Snappy:Fix Released> <https://launchpad.net/bugs/1621525>
[06:33] <ogra_> cjwatson, did some LP branch land last night or did the store change .... ?
[06:33] <ogra_> Launchpad uploaded this snap package to the store, but the store failed to
[06:33] <ogra_> scan it:
[06:33] <ogra_>   __all__: The upload does not appear to be a valid package.
[06:33] <ogra_> https://launchpad.net/~snappy-dev/+snap/core/+build/7240
[06:33] <ogra_> gotthat for all core and ubuntu-core builds tonight ...
[07:06] <cjwatson> ogra_: src/devportal/clickapp_forms.py:            msg = _("The upload does not appear to be a valid package.")
[07:06] <cjwatson> ogra_: so this is an SCA problem I'll bet
[07:09] <cjwatson> last SCA rollout was Friday though
[07:09] <cjwatson> and this succeeded yesterday
[07:10] <ogra_> cjwatson, yeah, weird ... i spoke to cprov when smoking about it
[07:11] <ogra_> he is taking a look now
[07:13] <cjwatson> ogra_: could yet be that we're sending the wrong data in the form, but the "__all__" smells of a bug on the SCA side to me
[07:14] <ogra_> yeah, smells like it mis-takes the architecture for the name or some such
[07:18] <cjwatson> ogra_: I don't think that's architecture, I think that's more like the __all__ special name in Python
[07:18] <cjwatson> given the double underscores
[07:18] <ogra_> hmm, yeah, or that :)
[07:19] <cjwatson> but there is no good reason for that to leak into error messages absent a bug :)
[07:24] <mup> PR snapd#2167 opened: Do not remove seed <Created by chipaca> <https://github.com/snapcore/snapd/pull/2167>
[07:41] <kyrofa> enoch85, you trying to reach me?
[08:01] <mup> PR snapd#2168 opened: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <https://github.com/snapcore/snapd/pull/2168>
[08:29] <zyga> jdstrand: hey, can you please ack and land https://github.com/snapcore/snap-confine/pull/172
[08:29] <mup> PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172>
[08:30] <zyga> Pharaoh_Atem: hey
[08:31] <zyga> Pharaoh_Atem: can you perhaps get into the xdistro room if you are not in a session now
[08:40] <dr1337> ogra_ is the system-a and system-b partition structure with writable still apply to the /snap partition structure?
[08:40] <dr1337> what about /var/snap ?
[08:47] <ogra_> dr1337, thats dead since 15.04
[08:47] <dr1337> :/
[08:48] <dr1337> ogra_ where's the new documentation?
[08:49] <mup> PR snapcraft#777 closed: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <Closed by teknoraver> <https://github.com/snapcore/snapcraft/pull/777>
[08:54] <cprov> ogra_: other LP built snaps are working fine, including store release. Come by, when you have time, so we can take a closer look on what's going on and how to improve the error message.
[09:04] <cjwatson> ogra_,cprov: c-r-t passes on that snap, at least; I wonder if the scan data is nonsense
[09:06] <cprov> cjwatson: what's the LP snap url ?
[09:07] <cjwatson> cprov: https://launchpad.net/~snappy-dev/+snap/core/+build/7241
[09:07] <cjwatson> cprov: well, ogra_ reported https://launchpad.net/~snappy-dev/+snap/core/+build/7240, but either way
[09:08] <cprov> cjwatson: yeah, same error
[09:09] <ogra_> yeah, i got a whole set of ten snaps that exposed it
[09:11] <cprov> cjwatson: the error is indeed coming from the store, src/devportal/clickapp_forms.py :-/
[09:11] <cjwatson> cprov: William pointed out that the __all__ bit probably means it's a django form-global error
[09:12] <cjwatson> was anything deployed yesterday?  CUD say?
[09:12] <cprov> cjwatson: which seems to be accurate.
[09:18] <Son_Goku> zyga: it begins... https://github.com/Conan-Kudo/snapcraft/commit/c960914b97440e2dca7a66c22c07438d809590fc
[09:24] <cjwatson> ogra_: the failure is because /var/lib/snapd/void changed from mode 0700 to mode 0000
[09:24] <cjwatson> ogra_: this appears to crash the review tools
[09:24] <ogra_> woah
[09:24] <ogra_> thats mvo'S fault then i guess. he changed something regarding the writable paths yesterday that could cause this
[09:26] <ogra_> hmm, he says it must be the review tools
[09:26] <cjwatson> the same version of the review tools seem to work for me
[09:26] <ogra_> with 0700 you mean ?
[09:26] <cjwatson> with 0000
[09:27] <ogra_> hmm, so why dont they work in the store then
[09:27] <cjwatson> but I don't know SCA well enough, maybe there's some confinement going on or something
[09:27] <ogra_> yeah, sounds like an environmental problem then
[09:27] <cjwatson> cprov: do you know if this error was directly from click-review, or if it was from the SCA task?
[09:29] <enoch85> kyrofa: I was, but I solved it with oparoz
[09:31] <qengho> Who approves new app names for Ubutu snap store? I thought it was automatic if not in a blacklist.
[09:32] <qengho> The FJKong tried to register something. It awaits some review or something.
[09:33] <ogra_> a  name that was already taken ?
[09:33] <ogra_> (usually it does not block)
[09:33] <qengho> I can not imagine it was taken.
[09:34] <ogra_> then it should just work i think ... (definitely did for me the last times i registered one, though admittedly that was a while ago)
[09:34] <qengho> Me too.
[09:34] <FJKong> ogra_: thanks I got the problem solved
[09:36] <FJKong> I got answer from cprov
[09:38] <qengho> Should all names be suffixed with a hyphen and a username? FJ wanted to register 'qrq'. There is no chance that there will be a conflict in names.
[09:39] <cprov> qengho: only in the case the requester is not the upstream or doesn't have a clear relation with it.
[09:39] <mup> PR snapd#2169 opened: interfaces/builtin: finish decl based checks <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2169>
[09:40] <FJKong> cprov: I think this package is no longer maintained any more by upstream
[09:40] <qengho> FJKong: I guess you need to become upstream!
[09:41] <FJKong> ye, glad to do that
[09:41] <qengho> Okay, not a snappy problem then.
[09:44] <cjwatson> ogra_: narrowed down.  can you please file a bug against software-center-agent for this?
[09:44] <cjwatson> ogra_: working on a fix
[09:44] <ogra_> doing ...
[09:48] <ogra_> cjwatson, bug 1634443 (feel free to adjust summary/description to be  more accurate)
[09:48] <mup> Bug #1634443: changing directories like /var/lib/snapd  to 0000 mode causes review-tools to misbehave <Software Center Agent:New> <https://launchpad.net/bugs/1634443>
[09:53] <kyrofa> enoch85, good deal
[09:53] <ogra_> lool, https://bugs.launchpad.net/bugs/1621380
[09:53] <mup> Bug #1621380: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):In Progress> <https://launchpad.net/bugs/1621380>
[10:23] <lool> ogra_: added to notes, thakns
[10:54] <bencc> do I need to install something to run snap packages on ubuntu 16.04 server?
[11:22] <Chipaca> bencc, "apt install snapd" should be enough
[11:26] <bencc> Chipaca: thanks
[11:26] <bencc> I'm considering packaging minio
[11:27] <bencc> https://github.com/minio/minio
[11:47] <Chipaca> bencc, nice!
[11:51] <mup> PR snapd#2170 opened: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2170>
[11:57] <mup> PR snapd#2164 closed: many: add supports for keeping and finding assertions with different format iterations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2164>
[12:23] <pstolowski> matiasb, ping
[12:24] <matiasb> pstolowski, o/
[12:24] <pstolowski> matiasb, hey, are you going to join store filtering session?
[12:25] <matiasb> pstolowski, I guess I can be there if it helps
[12:26] <pstolowski> matiasb, i think there is some confusion about what this session is about.. looks like client-side filtering and we may need to know what store is capable of et
[12:26] <pstolowski> etc
[12:26] <pstolowski> matiasb, it's in rembrandt
[12:26] <matiasb> pstolowski, ack
[12:26] <pstolowski> in 4 minutes
[12:44] <mup> PR snapd#2171 opened: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2171>
[12:49] <fgimenez> hey om26er, i'm in potter, well now i'm heading to the coffee machine :)
[12:49] <om26er> fgimenez: was just going to ask if you have the TTL cable, now borrowed HDMI from IS.
[13:00] <desrt> Chipaca: hihi
[13:00] <Chipaca> desrt, o/
[13:00] <desrt> Chipaca: got a chance to chat about XDG_RUNTIME_DIR inside of snaps?
[13:01] <desrt> am happy to meet in a hallway somewhere if you have some minutes
[13:01] <Chipaca> desrt, in half an hour?
[13:01] <desrt> sure
[13:01] <desrt> i'm in the desktop room if you want to come get me
[13:03] <om26er> fgimenez: Hey! if you have a wifi dongle, please bring that as well
[13:08] <fgimenez> om26er: ok, are you on the unity8 room?
[13:09] <om26er> yes
[13:09] <om26er> fgimenez: yes
[13:33] <mup> PR snapd#2156 closed: many: move from flags as ints to flags as structs-of-bools <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2156>
[13:36] <desrt> Chipaca: around?
[13:46] <mup> PR snapcraft#870 opened: sources: Add RPM source <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/870>
[14:06] <mup> PR snapd#2151 closed: asserts,interfaces/policy: allow OR-ing of subrule constraints in plug/slot rules <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2151>
[14:08] <Chipaca> desrt, was around for a bit, missed your message here when i was out
[14:09] <Chipaca> desrt, want to come by Potter?
[14:09] <desrt> sure
[14:15] <lazyPower> lool you're my new best friend :)  *much fanfare*
[14:16] <lool> lazyPower: Hmmm?
[14:16] <lazyPower> that mail to the snap list about the docker snap being available for testing
[14:17] <lool> :-)
[14:17] <lazyPower> lool - its suspiciously well timed as well - http://imgur.com/a/7nKwM
[14:18] <lool> wow!
[14:18] <lazyPower> armhf lab, 6 ssd backed rpi2/3's
[14:18] <lazyPower> its not as fast as a proper ssd, but at least the storage is reliable ;)
[14:18] <lool> lazyPower: BTW do you know you can network boot rpi3?
[14:18] <lazyPower> i do but its a one way change, adn i wasn't ready to commit
[14:19] <lool> yeah, same here  :-)
[14:19] <lazyPower> i have been following the discussion on those addon wifi cards
[14:19] <lazyPower> sounds interesting enough
[14:19] <lazyPower> when we can maas enlist these boards, i'll be in nirvana
[14:19] <lool> lazyPower: is there a maas driver for devices without bmc?
[14:20] <lazyPower> i dont think so, but i'm not positive. I'd have to poke the #maas group
[14:21] <lool> lazyPower: how do you intend to drive power from maas for the rpis?
[14:23] <lazyPower> lool - well, the idea is that any time the board boots, it should read and attempt a pxe boot. maas will not re-pxe boot a provisioned machine so it should hten default to booting off the curtained disk
[14:23] <lazyPower> so i could in theory build a usb power brick with some additional love from a pi that can change power states on the ports
[14:24] <lazyPower> but thats WIP that has yet to be done, and that would be my first hardware hack in a heck of a long time
[14:24] <lazyPower> but i'm game to spend some weekends cycling on it
[14:24] <niemeyer> rharper: ping
[14:24] <rharper> niemeyer: here
[14:24] <niemeyer> rharper: Heya
[14:24] <rharper> hey
[14:25] <niemeyer> rharper: Looking into that cloud-init detail from PR snapd#2160
[14:25] <mup> PR snapd#2160: image: tweak the cloud-init configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/2160>
[14:25] <mup> Bug #1620442 changed: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
[14:25] <lazyPower> lool - i was actually looking for a programmable usb hub/power-brick, and the only one i found was intended for telescope equipment, and its to the tune of 250 USD which is quite expensive for what its doing.
[14:25] <mup> PR snapd#2172 opened: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2172>
[14:25] <lazyPower> lool - so seems like we're also hitting an edge of a product market that doesn't exist yet
[14:25] <niemeyer> rharper: How does the logic take place when there is both a default cloud.cfg and something else on .d?
[14:26] <rharper> niemeyer: cloud-init does a dictionary based merging of all of the yaml cfg files present
[14:26] <rharper> so loading /etc/cloud/cloud.cfg and any *.cfg that's yaml in /etc/cloud/cloud.cfg.d
[14:27] <niemeyer> rharper: How do we take an option off if they're mergeD?
[14:28] <rharper> I believe setting the value to None, or empty should suffice
[14:33] <niemeyer> rharper: Ok, so in theory if we use the full cloud.conf, will it work the same way?
[14:33] <niemeyer> rharper: Well, in practice actually? :)
[14:34] <iliv_> is there a way to specify a target for make in the snapcraft.yaml file?
[14:35] <rharper> niemeyer: I can test that quickly by duplicating /etc/cloud/cloud.cfg and putting that in /etc/cloud/cloud.cfg.d/cloud.cfg
[14:35] <rharper> niemeyer: I expect it to work the same; yes
[14:35] <niemeyer> rharper: Thanks, it'd be nice to have some certainty about how this work as we'll be baking it into snapd proper.. if it's just a sum, then that's nicer indeed
[14:36] <lool> lazyPower: one of the old ones we used was http://www.digital-loggers.com/lpc.html
[14:36] <lool> lazyPower: but it's still fairly expensive and in my case the US power sockets are annoying
[14:37] <lazyPower> ah yeah i was hoping to avoid the AC power plug all together and get power-controlled USB ports instead
[14:37] <lazyPower> but this is a good lead, i should look into getting a managed power-switch
[14:38] <rharper> niemeyer: in general though, we'd like to avoid duplicating the default cloud.cfg in the gadget;
[14:38] <niemeyer> rharper: I'm still not entirely sure that's a good idea, but as long as the results of including a full cloud.cfg are the same, that should be okay
[14:40] <rharper> niemeyer: to be fair, the current cloud.conf file was never the full config; for example, it left off the 05_logging.cfg which is in /etc/cloud/cloud.cfg.d/ ... so current users of that miss configuring that and cloud-init.log remains empty
[14:41] <rharper> niemeyer: I'm interested in any scenario you think might not work ...  ;
[14:41] <lazyPower> lool but to be fair, i think i'll wait for that maas work first :) then i'll invest in a managed power switch
[14:41] <lazyPower> until then, the plugin will be "manual" - as in, i get off my bum and to plug/unplug the board.
[14:41] <lazyPower> s/to/go/
[14:42] <niemeyer> rharper: The problem is cloud.cfg changing behind the gadget's back, which is exactly the motivation for doing this
[14:42] <niemeyer> rharper: Somebody cooking an image for a particular environment will not expect these settings to magically change after an update
[14:42] <rharper> niemeyer: right, if the core snap (or cloud-init snap) updated;
[14:43] <niemeyer> rharper: Which it does all the time, right? :)
[14:43] <rharper> the cloud.cfg is pretty static actually
[14:43] <rharper> but the concern you raise is real
[14:43] <niemeyer> rharper: Right, but if the point is that it's okay because it doesn't change, then why are we doing this? :)
[14:44] <rharper> because almost zero folks copying in the correct cloud.cfg and it clobbered the default configureation
[14:44] <rharper> this meant that cloud-init ran but didn't do anything as the list of datasources and config modules to run was empty
[14:44] <niemeyer> rharper: Can you rephrase this?  I didn
[14:45] <niemeyer> 't get the real point behind the comment
[14:46] <rharper> sure:  previous behavior was:  gadget needs 'cloud.conf' or cloud-init is disabled;  if cloud.conf exists, copy cloud.conf to /etc/cloud/cloud.cfg;  the overlay of cloud.cfg requires extracting the default cloud.cfg and the contents of /etc/cloud/cloud.cfg.d/*.cfg to bundle the correct default configuration
[14:47] <rharper> ideally we'd not punish cloud-init users by requiring that assembly of configuration into a single file
[14:51] <niemeyer> rharper: In the previous phrasing you mentioned a bug (didn't do anything because ...).. what was the cause/consequence?
[14:54] <rharper> niemeyer: the bug was that the conf clobbers the default cloud-init config;
[14:56] <niemeyer> rharper: Okay.. I thought they were actually trying to clobber it
[14:57] <rharper> niemeyer: hrm; ok
[15:00] <rharper> niemeyer: I do think that puts almost too much burden on gadget creator to understand all of cloud-init's defaults (or at least to learn how to extract it all from cloud-init deb)
[15:01] <rharper> niemeyer: I agree that if a gadget wanted to disable the default config then overwriting the cloud.cfg in the core snap is the right way to do that;
[15:03] <rharper> niemeyer: I don't think folks would realize that they might also need the 05_logging.cfg and other defaults to get the same behavior one would get on a cloud-image
[15:05] <niemeyer> rharper: There's a grub.conf right next to it, and a gadget.yaml with a detailed specification of partitions..
[15:05] <niemeyer> rharper: I'm more concerned about behavior changing behind people's back than about them having to cargo cult a nice example
[15:07] <rharper> niemeyer: isn't that a general concern w.r.t conf files versus code in the core snap  ?
[15:09] <niemeyer> rharper: Hmm.. in which sense?
[15:11] <rharper> we could include a configuration file for  some other package in the core snap and an update could change behavior despite the config in the gadget
[15:24] <iliv_> is there a way to make snapcraft cd into a specific directory before calling the make plugin? in this case, a Makefile includes another Makefile and the path to the second file is relative.. so it never gets included as apparently snapcrafts cwd is not where the first Makefile resides.
[15:25]  * iliv_ wondering if ogra_ might be able to help. He usually does :P
[15:34] <nacc> iliv_: i believe you might need to write a custom plugin then (pretty easy to do)
[15:34] <nacc> iliv_: it can probably inherit almost everything from the make plugin, except for the actual building step which knows about the details of your setup
[15:39] <iliv_> hmm
[15:39] <iliv_> alright
[15:39] <iliv_> thanks nacc
[15:39] <iliv_> where do I find make plugin's source code btw?
[15:39] <nacc> iliv_: that's what i've done in the past, at least
[15:39] <nacc> iliv_: it should all be in github (snapcraft iirc)
[16:16] <zyga> jdstrand: hey
[16:16] <zyga> jdstrand: I got notified about this bug earlier https://bugs.launchpad.net/snap-confine/+bug/1620442
[16:16] <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
[16:17] <zyga> jdstrand: it looks easy technically but I wanted to ask you about your opinion first
[16:32] <mup> PR snapd#2171 closed: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2171>
[16:55] <mup> PR snapd#2173 opened: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <https://github.com/snapcore/snapd/pull/2173>
[17:03] <mup> PR snapd#2174 opened: store: send supported max-format when retrieving assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2174>
[17:19] <Chipaca> jdstrand, whereabouts are you?
[17:30] <mup> PR snapd#2132 closed: interfaces/builtin: enable out of process providers for locationd <Created by vosst> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2132>
[17:31] <Chipaca> jdstrand, dude we can tell you're not at the museum :-p
[17:38] <mup> PR snapd#2157 closed: boot,image,overlord,partition: read/write boot variables in single operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2157>
[18:03] <mup> PR snapd#2167 closed: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167>
[18:10] <mup> PR snapd#2174 closed: store: send supported max-format when retrieving assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2174>
[18:30] <mup> PR snapd#2160 closed: image: tweak the cloud-init configuration <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2160>
[18:31] <mup> PR snapd#2168 closed: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2168>
[18:32] <mup> PR snapd#2154 closed: cmd/snap: make snap run not talk to snapd for finding the revision <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2154>
[18:39] <mup> PR snapd#2170 closed: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2170>
[19:11] <jdstrand> Chipaca: yeah, not there
[19:12] <jdstrand> Chipaca: in my hotel room
[19:12] <Chipaca> jdstrand, we're in Potter, if you're feeling lonely
[19:12] <jdstrand> I'm feeling quite sleepy after last night tbh :)
[19:12] <Chipaca> jdstrand, but only if you have pants on
[19:13] <jdstrand> ya, you caught me there.  ;) I think I am going to call it a night in a few
[19:16] <jdstrand> zyga: I saw bug #1620442. on touch we set that to somewhere in /run and in snapd we currently allow: /{dev,run}/shm/snap.@{SNAP_NAME}.**
[19:16] <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
[19:17] <jdstrand> zyga: actually that rule is irrelevant
[19:19] <jdstrand> zyga: but I don't think the bind mount is particularly necessary, we could just add an apparmor rule for /run/user/*/snap.$SNAP/**, set XDG_RUNTIME_DIR to point to that and mkdir
[19:19] <jdstrand> zyga: can you think of why it should be a bind mount? I mean, it is already honoring the envvar
[19:19] <jdstrand> zyga: (and this is something ubuntu-app-launch on Touch would set)
[19:44] <mup> PR snapd#2143 closed: overlord: check that the first installed gadget matches the model assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2143>
[20:24] <mup> PR snapd#2172 closed: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2172>
[20:32] <mup> PR snapd#2175 opened: overlord: checks for kernel installation/refresh based on model assertion and previous kernel <Created by pedronis> <https://github.com/snapcore/snapd/pull/2175>
[20:36] <mup> PR snapd#2123 closed: daemon: ensure `snap create-user --known` errors on classic (unless --force-managed is added) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2123>
[20:43] <mup> PR snapd#2173 closed: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2173>
[20:44] <k_> Hi, is there a way to test snap on centos 7?
[20:52] <mup> PR snapd#2122 closed: snappy: disable auto-import of assertions on classic <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2122>
[21:07] <mup> PR snapd#2176 opened: store,daemon,overlord: download things to a partials dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/2176>
[21:19] <ypwong> slangasek, you may want to look at https://bugs.launchpad.net/ubuntu-image/+bug/1634557
[21:19] <mup> Bug #1634557: The writable partition is corrupted using the latest ubuntu-image(0.8 ) <Ubuntu Image:New> <https://launchpad.net/bugs/1634557>
[21:52] <mup> PR snapd#2177 opened: many: use the new systemd backend for configuring GPIOs <Created by zyga> <https://github.com/snapcore/snapd/pull/2177>
[21:53] <mup> PR snapd#2178 opened: snap: spool assertion candidates if snapd is not up yet <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2178>
[21:59] <slangasek> ypwong: hi - I had seen the bug and was going to raise this with barry today.  This is listed as a regression vs. 0.7?  where does this version of the package (0.8+17.04ubuntu1) come from?  that's not a version that's in the archive
[22:17] <mup> PR snapd#2179 opened: remove silly stuff <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2179>
[22:23] <slangasek> ypwong: ok, reproduced and it seems to not be a regression - we were just being spared this being an issue on the pi3 because of the firstboot autoresizing from the initramfs fixes it before we ever mount the rootfs
[22:47] <adam__> hello, I am looking at using ubuntu core snappy as the OS of choice for a raspberry pi solution to communicate with a webserver and some connected hardware via a serial port. I already have a node app that I want to repackage as a snap, but I am struggling to find the information that I need online: 1) Can I publish snaps privately, e.g. with proprietary closed source code and still make use of the auto-update functionality? 2) Can I 
[23:30] <rhollan> Is there a snappy package that has networking utils, specifically bridge-utils? I want to bridge two docker containers to the hosts interface and have them get internal IP addresses and gateways and dns servers therefrom
[23:31] <rhollan> I don't have any bridge utils on the host side in snappy
[23:32] <mup> PR snapd#2180 opened: overlord/snapstate: two bugs for one <Created by chipaca> <https://github.com/snapcore/snapd/pull/2180>
[23:33] <Chipaca> ^ fix for #1628914 :-D
[23:33] <mup> Bug #1628914: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:In Progress by chipaca> <https://launchpad.net/bugs/1628914>
[23:33]  * Chipaca ~> bed
[23:35] <mup> PR snapd#2179 closed: remove silly stuff <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2179>