[01:10] <mup> PR snapcraft#764 opened: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <https://github.com/snapcore/snapcraft/pull/764>
[01:55] <mup> PR snapcraft#767 opened: Make a copy of the snapcraft files common list before using it <Created by elopio> <https://github.com/snapcore/snapcraft/pull/767>
[02:22] <mup> PR snapcraft#741 closed: Make it easy to setup a pre-commit hook <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/741>
[02:58] <mup> PR snapcraft#767 closed: Make a copy of the snapcraft files common list before using it <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/767>
[06:14] <dholbach> hey hey
[06:43] <tvoss> o/
[07:09] <mup> PR snapd#1780 opened: Mention Launchpad bugs list in README <Created by nottrobin> <https://github.com/snapcore/snapd/pull/1780>
[07:10] <nottrobin> We got an issue with Snapd filed to the snapcraft.io site. I realise your github README doesn't mention where to file bugs. I've created a PR to fix that. ^
[07:20] <zyga> good morning
[07:20] <zyga> mwhudson: hey
[07:20] <zyga> mwhudson: would you mind adding me as a co-maintainer to snap-confine and snapd?
[07:22] <mup> PR snapd#1781 opened: README: cover the new /run/snapd-snap.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/1781>
[07:24] <mup> PR snapd#1781 closed: README: cover the new /run/snapd-snap.socket <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1781>
[07:44] <mup> PR snapd#1780 closed: Mention Launchpad bugs list in README <Created by nottrobin> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1780>
[07:46] <mup> PR snapd#1782 opened: docs/interfaces: Add empty line after lxd-support title <Created by caldav> <https://github.com/snapcore/snapd/pull/1782>
[07:47] <mup> PR snapd#1782 closed: docs/interfaces: Add empty line after lxd-support title <Created by caldav> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1782>
[07:56] <mup> Bug #1600713 changed: snapd.boot-ok.service always failed after booting <Snappy:Invalid> <https://launchpad.net/bugs/1600713>
[08:30] <mup> PR snapd#1783 opened: snap-exec: add support for commands with internal args in snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/1783>
[08:33] <mvo> pitti: re bug #1618207 - whats the best bet to figure out if the system is on a high-quality link? talking to NM?
[08:33] <mup> Bug #1618207: snapd.refresh.service runs when being offline or on expensive/slow internet <amd64> <apport-bug> <yakkety> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1618207>
[08:34] <pitti> mvo: NM might not be installed (but if it isn't, then I think we can assume to not have 3G or other "expensive" links)
[08:35] <pitti> mvo: not sure what touch does for updates, maybe that does something clever
[08:36] <mvo> pitti: iirc its using the download-manager which tries to be very smart
[08:36] <mvo> pitti: I wish nm-online had an option --is-expensive
[08:36] <ogra_> hmm
[08:36] <mvo> pitti: then it would be super simple
[08:37] <ogra_> my dragonboard and rpi3 installs used to greet me every day with a refreshed core snap for the past two weeks ... seems that has stopped very recently
[08:37] <ogra_> i need to run snap refresh now to actually get the update
[08:38] <ogra_> snapd.refresh.timer says "loaded active waiting" ...
[08:38] <pitti> mvo: "ip route show to 0/0" shows the device of the default route, and nmcli d show $(device) the device type; but that's non-trivial indeed
[08:39] <pitti> mvo: not the most important thing in the world too, but I noticed the failed service so I thought I'd at least record a bug
[08:39] <mvo> pitti: yeah, it makes sense
[08:39] <mvo> ogra_: uh, strange
[08:39] <mvo> ogra_: no reason why its waiting?
[08:40] <ogra_> how do i find out ?
[08:40] <pitti> well, why would a timer not be waiting?
[08:40] <pitti> (that's the normal state)
[08:41] <pitti> ogra_: maybe snapd.refresh.service failed for you? check systemctl status?
[08:41] <ogra_> http://paste.ubuntu.com/23110890/
[08:41] <pitti> it does fail for me on my normal laptop
[08:41] <pitti> Aug 30 06:24:30 donald snap[1084]: error: cannot refresh []: Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
[08:41] <pitti> which is different than the two bugs I filed
[08:42] <ogra_> Aug 30 08:36:55 dragonboard /usr/lib/snapd/snapd[2597]: snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
[08:42] <ogra_> Aug 30 08:36:55 dragonboard snapd[2597]: 2016/08/30 08:36:55.414746 snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
[08:42] <ogra_> aha
[08:43] <ogra_> ah, wait, thats my manual run
[08:43] <pitti> FWIW, if I open https://search.apps.ubuntu.com/api/v1/snaps/metadata in a browser I get a 403
[08:44] <ogra_> i dont see any changes in progress
[08:44] <ogra_> thats weird
[08:46] <ogra_> seems when i manually refresh it tries to spawn the timer refresh too at the same time
[08:47] <ogra_> ubuntu@pi3:~$  grep refresh /var/log/syslog
[08:47] <ogra_> Aug 30 08:37:40 pi3 systemd[1]: Starting Automatically refresh installed snaps...
[08:47] <ogra_> Aug 30 08:37:40 pi3 /usr/lib/snapd/snapd[2663]: snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
[08:47] <ogra_> Aug 30 08:37:40 pi3 snapd[2663]: 2016/08/30 08:37:40.631024 snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
[08:47] <ogra_> Aug 30 08:37:48 pi3 systemd[1]: Started Automatically refresh installed snaps.
[08:47] <ogra_> Aug 30 08:37:48 pi3 systemd[1]: snapd.refresh.timer: Adding 1h 15min 34.967902s random time.
[08:47] <ogra_> Aug 30 08:37:48 pi3 systemd[1]: snapd.refresh.timer: Adding 4h 22min 20.282576s random time.
[08:47] <ogra_> this was definitely triggered by a manual "snap refresh"
[08:48] <ogra_> i guess the timer and the manual refresh somehow wrangle over it
[08:48] <mvo> pitti: I got a timeout as well in one of my tests currently
[08:49]  * ogra_ got a properly updated ubuntu-core ... no timeouts here 
[08:49] <ogra_> do you have the VPN active ?
[08:50] <ogra_> i noticed that sometimes after DSL reconnect i get DNS issues with it ... reconnecting the VPN then helps
[08:50] <ogra_> (DNS issues with all canonical machines)
[09:01] <mup> PR snapd#1770 closed: overlord/assertstate,asserts/snapasserts: give snap assertions helpers a package, introduce ReconstructSideInfo <Critical> <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1770>
[09:02] <ahoneybun> dholbach: I'm looking for a project in snappy-playpen that uses those white_check_marks and red_circles for examples
[09:03] <dholbach> ahoneybun, just take a look at the top-level README.md
[09:03] <dholbach> (the file itself)
[09:04] <ahoneybun> none of the projects use that
[09:04] <ahoneybun> the check mark things
[09:08] <ahoneybun> mm :Cannot find definition for part 'desktop-qt5
[09:09] <ahoneybun> oh got it
[09:15] <mup> PR snapd#1784 opened: Add an interface to access the usb drives <Created by axelebas> <https://github.com/snapcore/snapd/pull/1784>
[09:19] <ahoneybun> that's a real useful line right there: http://start.ubuntu.com/connectivity-check.html
[09:22] <ahoneybun> yea this thing called lxd is kinda useless with the errors
[09:24] <mwhudson> zyga: sure, you@ubuntu.com?
[09:24] <mwhudson> i'm not even sure i'm a maintainer for snapd yet
[09:27] <Son_Goku> I can't believe I'm saying this, but morning all
[09:27]  * Son_Goku doesn't understand how he's awake this early in the morning...
[09:27] <ahoneybun> same
[09:27] <ahoneybun> it's 5:30am here
[09:27] <Son_Goku> yep
[09:27] <Son_Goku> same here
[09:27] <ahoneybun> niice
[09:28] <Son_Goku> I'm going to be in for a world of hurt today, since I have meetings ALL afternoon
[09:28] <Son_Goku> this is going to suck hard
[09:31] <mwhudson> zyga: eh given that https://qa.debian.org/developer.php?login=zygmunt.krynicki@canonical.com has things and ubuntu.com does not...
[09:45] <Son_Goku> what port does snapd use to talk to the Canonical store?
[09:47] <zyga> Son_Goku: part?
[09:47] <Son_Goku> what TCP port?
[09:47] <zyga> mwhudson: me@zygoon.pl
[09:47] <Son_Goku> I'm attempting to write a simple SELinux policy for snapd
[09:48] <zyga> mwhudson: I'll transition my packages over there
[09:48] <zyga> Son_Goku: woot! thank you!
[09:48] <mwhudson> zyga: done
[09:48] <Son_Goku> zyga, making no promises here, as I have almost no idea what I'm doing :P
[09:48] <zyga> Son_Goku: I cracked the snap-confine feature I was trying to implement; I will try to land it and release 1.0.41 today/tomorrow
[09:48] <Son_Goku> awesome
[09:49]  * zyga hugs Son_Goku 
[09:49] <zyga> Son_Goku: mount namespaces are *complex* and underdocumented
[09:49] <Son_Goku> ugh
[09:49] <zyga> I'd like to fix the namespace(7) man page, it's just lacking essential facts
[09:49] <Son_Goku> I feel like stabbing someone after hearing that
[09:49] <zyga> mwhudson: thank you :-)
[09:49] <ogra_> Son_Goku, isnt "i dont know what i'm doing" a prerequisite for using selinux ?
[09:49] <Son_Goku> no
[09:49] <ogra_> :)
[09:49] <zyga> mwhudson: I'll try to prepare 1.0.41 in alioth and ask you for review (not today, no worries :)
[09:50] <Son_Goku> I do actually know what I'm doing with SELinux
[09:50] <mwhudson> zyga: did you get your DM?
[09:50] <zyga> mwhudson: given our timezone coverage it should be good to work on the overalap for a few moments
[09:50] <Son_Goku> I have no idea what the totality of snapd's scope is
[09:50] <zyga> mwhudson: yes
[09:50] <mwhudson> zyga: congrats!
[09:50] <mwhudson> zyga: and collab-maint?
[09:51] <ogra_> Son_Goku, totality of snapd scope -> make the world a better place... and free beer for zyga ...
[09:51] <zyga> mwhudson: not sure, I think that is separate, no?
[09:51] <ogra_> (what else :) )
[09:52] <mwhudson> zyga: yeah it is
[09:53] <mwhudson> zyga: https://lists.debian.org/debian-devel-announce/2012/01/msg00006.html i think
[09:54] <zyga> aleba: o/
[09:54] <mwhudson> zyga: took a couple of days for me, but might have been over a weekend or something, don't remember
[09:54] <Son_Goku> more procedure?
[09:55] <zyga> mwhudson: ah, I see
[09:55] <zyga> mwhudson: just signed email
[09:55] <Son_Goku> ogra_ , I don't know what TCP/UDP ports snapd uses to talk to the store API
[09:55] <zyga> Son_Goku: yeah, I would really like to see more of fedora's web tools in debian
[09:55] <zyga> Son_Goku: ahhh, just http/https I bet
[09:55] <ogra_> Son_Goku, 80/443 i think
[09:55] <ogra_> err
[09:55] <zyga> Son_Goku: there's no UDP involved
[09:56] <zyga> Son_Goku: everything is http-based
[09:56] <ogra_> yeah,
[09:58] <zyga> Son_Goku: there's the trivial store implementation somewhere AFAIR
[09:58] <Son_Goku> zyga, insofar as seeing more of fedora's awesome tools in debian, they gotta at least implement fedmsg fully
[09:58] <Son_Goku> https://wiki.debian.org/FedMsg
[09:58] <zyga> Son_Goku: and badges!!!
[09:59] <zyga> Son_Goku: but badges should be cross-distro
[09:59] <Son_Goku> the badges are powered by fedmsg :)
[09:59] <zyga> Son_Goku: one person, all the badges from all the distros toether
[09:59] <zyga> Son_Goku: I know, I looked at it
[09:59] <zyga> Son_Goku: badges are awesome :)
[09:59] <Son_Goku> the fedora people would definitely be interested in spreading the software everywhere :)
[09:59] <Son_Goku> there's even people interested in making Koji build proper debian packages, too :P
[10:00] <Son_Goku> the fedora infrastructure is awesome
[10:00] <Son_Goku> the upcoming fedora hubs will be even more amazing
[10:00] <zyga> hubs?
[10:01] <Son_Goku> https://fedoraproject.org/wiki/Fedora_Hubs
[10:02] <zyga> Fedorabook ;)
[10:02] <Son_Goku> yep
[10:02] <zyga> interesting, I'm going to look at how that evolves
[10:02] <Son_Goku> it's supposed to be deployed shortly after the third generation Fedora Account System goes live
[10:02] <Son_Goku> we're on FAS2 now
[10:02] <Son_Goku> which I think we've been using for about six years
[10:03] <zyga> Son_Goku: heads up, snappy now uses two sockets, the new one is /run/snapd-snap.socket
[10:03] <zyga> Son_Goku: 2.14 in COPR has an updated patch to cover this
[10:04] <zyga> Son_Goku: the 2nd socket is designed to allow all the snaps to talk to snapd about their stuff
[10:04] <zyga> Son_Goku: (it is not a priviledged socket)
[10:04] <Son_Goku> ugh
[10:04] <zyga> Son_Goku: I guess I have to update the request for the socket presets
[10:04] <Son_Goku> it's a systemd socket?
[10:05] <zyga> yes
[10:05] <Son_Goku> err systemd unit
[10:05] <zyga> Son_Goku: actually
[10:05] <zyga> Son_Goku: it's one .socket
[10:05] <zyga> Son_Goku: the same one we had
[10:05] <Son_Goku> so you're fine
[10:05] <zyga> Son_Goku: it just has two listen streams
[10:05] <zyga> Son_Goku: ahhh right :-)
[10:05] <zyga> that's a relief :)
[10:06] <zyga> Son_Goku: I'll finish my coffee and .41 patch and do a quick test to see how snapd works without top-level /snap
[10:06] <Son_Goku> does snapd have any log files?
[10:06] <zyga> Son_Goku: no
[10:06] <zyga> Son_Goku: just systemd stuff
[10:06] <ogra_> it logs to syslog
[10:06] <Son_Goku> okay
[10:06] <ogra_> (or journald )
[10:06] <zyga> Son_Goku: I was wondering how to transition people on COPR
[10:07] <zyga> Son_Goku: plan a) do nothing, advertize this and let people transition manually
[10:07] <zyga> Son_Goku: plan b) do the transition in COPR before the package lands
[10:07] <zyga> Son_Goku: and keep the transition logic copr-only
[10:07] <Son_Goku> transition what?
[10:07] <zyga> Son_Goku: transition away from /snap
[10:07] <Son_Goku> plan B
[10:08] <Son_Goku> the transition logic shouldn't exist in the official fedora packaging
[10:08] <Son_Goku> but being the good person you are, you'll handle the transition properly in copr
[10:08] <zyga> Son_Goku: yeah, I agree
[10:08] <Son_Goku> you'd probably use one of the transaction scriptlets to do this
[10:09] <zyga> Son_Goku: I was thinking that the package could stop all the mount units, this should stop all the services, do the transition in the mount files, and re-start the mount units
[10:09] <Son_Goku> right
[10:09] <zyga> Son_Goku: but I don't know, I'd like to try it out in a controlled env before I push any updates
[10:09] <Son_Goku> sure
[10:09] <zyga> Son_Goku: (and move the stuff around a little on the FS while this happens)
[10:09] <Son_Goku> zyga: https://fedoraproject.org/wiki/Packaging:Scriptlets
[10:21] <mup> PR snapd#1745 closed: overlord/snapstate: respect SnapMountDir in tests <Reviewed> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1745>
[10:21] <Son_Goku> zyga, are there any config files that snapd needs rw access?
[10:27] <jamespage> SamYaple, I appear to be following you around snap bits and pieces related to openstack - I have some prelimary snaps for keystone and nova - https://github.com/search?q=user%3Ajavacruft+snap
[10:28] <jamespage> might be good to hook up and collab and ensure we're not re-doing each others work to much :-)
[10:31] <zyga> Son_Goku: /var/lib/snapd/*
[10:31] <zyga> Son_Goku: nothing in /etc AFAIK
[10:32] <Son_Goku> okay
[10:33] <ogra_> oh
[10:34] <zyga> ogra_: ?
[10:34] <ogra_> nothing, i just checked the ubuntu-core dl stats :)
[10:35] <zyga> ogra_: aand? :)
[10:36] <ogra_> +50% since i last checked (about two weeks ago or so)
[10:37] <zyga> ogra_: woot :-)
[10:45] <ogra_> mvo, we will need to talk about GL libs in the kernel and how to handle them ...
[10:45] <Son_Goku> zyga: https://gitlab.com/Conan_Kudo/snapcore-selinux
[10:45] <ogra_> (afaik there is nothing today that bind mounts them into the right place etc )
[10:45] <ogra_> (or that even recognizes them in the kernel snap)
[10:46] <zyga> Son_Goku: checking
[10:47] <zyga> Son_Goku: https://gitlab.com/Conan_Kudo/snapcore-selinux/blob/master/snappy.fc#L6
[10:47] <zyga> Son_Goku: will that catch both snapd.socket and snapd-snap.socket?
[10:47] <Son_Goku> I think so
[10:47] <zyga> Son_Goku: what does ? do in that context?
[10:47] <zyga> Son_Goku: it looks like you wanted *
[10:48] <zyga> Son_Goku: or better yet, just spell out both sockets
[10:49] <zyga> Son_Goku: quick question, would you mind moving this to github? we could move it to snapcore/snapcore-selinux
[10:49] <Son_Goku> create the project and I'll push it there
[10:49] <zyga> Son_Goku: thanks, I don't mind gitlab but that's just one-more-account for me
[10:49] <Son_Goku> I personally dislike GitHub a lot
[10:50] <Son_Goku> but I can't avoid it
[10:50] <Son_Goku> more and more projects are moving there all the time :(
[10:52] <mup> PR snapd#1776 closed: image: snap assertions into image <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1776>
[11:31] <ogra_> cjwatson, did yu see my ping about Bug #1608432 yesterday ?
[11:31] <mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <launchpad-buildd:New> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
[11:31] <cjwatson> no
[11:31] <ogra_> i have the manifext in place now ...
[11:32] <ogra_> *manifest
[11:33] <cjwatson> right, that path is fine
[11:33] <ogra_> cjwatson, and another question i asked yesterday, is there any way for me to get the store revision number for a snap from the LP api (i have a script that screen-scrapes the url from the UI currently, but thats indeed no long term solution)
[11:34] <cjwatson> ogra_: not at present, will probably need thought, file  abug
[11:34] <ogra_> will do
[11:55] <Son_Goku> zyga, so I have a super basic SELinux policy module for snapd
[11:55] <Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux
[11:55] <Son_Goku> it has a Makefile and install instructions
[11:56] <zyga> Son_Goku: checking
[12:59] <mup> PR snapd#1785 opened: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
[12:59] <zyga> tyhicks: hey, I've implemented the mount namespace sharing
[13:00] <zyga> tyhicks: I'll write a few spread tests for it and I'll ask you for review
[13:00] <zyga> tyhicks: there's one thing that I didn't anticipate but it's not a major thing
[13:00] <zyga> tyhicks: (systemd changing a default)
[13:05] <mup> PR snapd#1786 opened: debian: readd ubuntu-core-snapd-units as a transitional package <Created by mvo5> <https://github.com/snapcore/snapd/pull/1786>
[13:11] <mvo> tvoss: I pushed a vendoring branch fwiw
[13:16] <mup> PR snapcraft#768 opened: Update kernel meta to the latest spec <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/768>
[13:21] <tyhicks> zyga: nice!
[13:27] <sergiusens> good morning!
[13:27] <zyga> tyhicks: the only wart that kept me from getting this to work is that the preserving bind mount needs to be targetted to a private tree
[13:27] <zyga> tyhicks: and systemd makes / shared by default
[13:40] <mup> PR snapcraft#769 opened: Minor fixes for typos in --help <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/769>
[13:43] <zyga> tyhicks, jdstrand: can you join a hangout please
[13:43] <zyga> https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1
[13:43] <zyga> about the ns sharing thing
[13:43] <tyhicks> zyga: not quite yet - having another conversation
[13:44] <zyga> tyhicks: when could you be free?
[13:45] <zyga> jdstrand: how about you?
[13:46] <jdstrand> I'm in said conversation
[13:46] <mup> PR snapcraft#770 opened: HACKING.md: list dependencies to install with pip <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/770>
[13:46] <zyga> ok, let me find a spot for the four of us then
[13:48] <zyga> I sent you an invite, please tell me if you are free at this time or if you have other commitments
[13:50] <mup> PR snapd#1786 closed: debian: re-add ubuntu-core-snapd-units as a transitional package <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1786>
[13:56] <zyga> jdstrand, tyhicks, niemeyer: I moved the call a few hours into the future, I hope that we can all meet then
[13:57] <tyhicks> zyga: I can't do the new time
[13:57] <tyhicks> zyga: I'm off this afternoon
[13:57] <zyga> can you do it now?
[13:59] <tyhicks> zyga: in a few more minutes
[13:59] <zyga> jdstrand, niemeyer: ^^ let's use that time if you are available
[13:59] <zyga> as the rest of the day looks packed
[13:59] <zyga> and we are running out of time
[14:01] <jdstrand> I have a meeting in 1 hour and in 2 hours
[14:01] <jdstrand> zyga: I think tyhicks and I are almost done. do we need a full our?
[14:01] <jdstrand> hour?
[14:01] <zyga> let's hope not :)
[14:02] <zyga> let's do it now
[14:02] <zyga> joining the hangout
[14:03] <zyga> tyhicks, jdstrand, niemeyer: https://hangouts.google.com/hangouts/_/canonical.com/mount-namespace?authuser=1
[14:04] <mup> PR snapcraft#765 closed: Use a recursive iglob for filesets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
[14:17] <mup> PR snapd#1771 closed: store: refresh expired device sessions <Critical> <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1771>
[14:39] <SamYaple> jamespage: sounds good. I have nova and glance put together mostly. lets catch up on what to do next
[14:39] <jamespage> SamYaple, api services appear to be relatively simple (just network and network-bind required)(
[14:40] <jamespage> SamYaple, the big tickets on my list atm are openvswitch, libvirt and all of the network management and virt management stuff that happens
[14:40] <mup> PR snapd#1783 closed: snap-exec: add support for commands with internal args in snap-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1783>
[14:40] <jamespage> SamYaple, have you any thoughts on snap naming?  as this is greenfield, having something that easily identifies the snap as openstack related feels goof to me
[14:40] <jamespage> so I was going for something like
[14:40] <jamespage> openstack-identity
[14:41] <jamespage> openstack-image
[14:41] <jamespage> openstack-block-storage
[14:41] <jamespage> so project names, rather than codenames?
[14:43] <SamYaple> jamespage: well the project names are keystone, glance, cinder
[14:43] <SamYaple> not naming them that seems like a bad choice
[14:44] <jamespage> SamYaple, purpose vs name I guess
[14:44] <SamYaple> but i do have the snap names for the openstack projects registered
[14:44] <SamYaple> well this affects the binaries too, keep that in mind
[14:44] <jamespage> SamYaple, I'm easy either way tbh - for our charms we use the keystone, cinder, glance names..
[14:44] <tvoss> mvo, thx, got link?
[14:44] <jamespage> SamYaple, so you're thinking simply keystone/glance
[14:44] <jamespage> no openstack prefix?
[14:45] <SamYaple> if there is an openstack prefix then we end up with openstack-keystone.manage, and openstack-nova.manage
[14:45] <SamYaple> its not the end of the world, but im not sure its ideal
[14:46] <jamespage> SamYaple, I saw the bug related to additional binary naming - agree if feels awkward and would mean lots of *NOTES* in official docs...
[14:46] <jamespage> I'd rather not write a whole new install guide for this stuff :-)
[14:46] <mvo> tvoss:  https://github.com/snapcore/snapd/pull/1785
[14:46] <jamespage> SamYaple, I was pondering a plugin extending py2 or py3 (or either) to wrap the OpenStack snap related bits in
[14:46] <mup> PR snapd#1785: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
[14:46] <SamYaple> i know what you mean. thats what i was trying to get out of that bug report. however a simple alias would align all the packages
[14:47] <SamYaple> jamespage: what do you mean?
[14:47] <SamYaple> jamespage: ive extended the py2 plugin to do mostly everything thats needed. now im refactoring the py2 and py3 plugins to be one plugin
[14:47] <jamespage> SamYaple, I was thinking about some non py related stuff
[14:47] <jamespage> SamYaple, having these - https://github.com/javacruft/snap-openstack-compute-controller/blob/master/bin/run.sh
[14:48] <jamespage> in every snap feel ugly - it should be generated as part of the creation of the snap IMHO
[14:48] <jamespage> so the yaml would allow a snap author to configure bits of that
[14:48] <SamYaple> im not sure any script inside the snap is needed
[14:48] <jamespage> SamYaple, what's been your approach to configuration files then?
[14:49] <jamespage> that's pretty much all that does - so for example for keystone it sets various state paths to SNAP_COMMON/xxxx
[14:49] <SamYaple> there is some changes being implemented that would allow /etc/nova from the host to bind into the container. that is my ideal
[14:49] <SamYaple> i want a replacement to system packages as much as possible
[14:50] <SamYaple> operators manage it the same way they would a baremetal deploy
[14:50] <SamYaple> certainly things we can talk about though
[14:50] <jamespage> I can see how that helps with config files; but for local state, I think that want to be in SNAP_COMMON
[14:51] <jamespage> that said, I don't think we should consider ourselves bound to /etc/XXXX
[14:51] <mup> PR snapd#1787 opened: overlord/snapstate, daemon, cmd/snap: more explicit revision support <Created by chipaca> <https://github.com/snapcore/snapd/pull/1787>
[14:51] <jamespage> keystone and nova control plane service where quite happy to run in a non root location, with config files pulled in from SNAP_COMMON and the snap itself
[14:51] <SamYaple> well the /etc bind part is done at run time right? so thats a variable location
[14:52] <SamYaple> but i woud like the ability to set the configs _to_ that location. i dont think this restricts either one of us in what were saying though
[14:53] <SamYaple> jamespage: you arent the first to express intrest about this. i just threw up a channel at ##openstack-snappy, perhaps we can discuss the openstack bits there rather than clog up this channel with non-snappy things
[14:54] <jamespage> coreycb, ddellav: ^^ you might wanna join that as well
[14:59] <coreycb> jamespage, joined
[15:02] <morphis__> ogra_: I saw that cloud-init isn't generating files in /etc/network/interfaces.d anymore, is that due to the netplan landing?
[15:02] <ogra_> morphis__, yeah, we're waiting for the final bits in subiquity
[15:03] <morphis__> ogra_: but any edge channel should have these already?
[15:03] <ogra_> no
[15:03] <ogra_> you need to manually create the /e/n/i files atm
[15:04] <morphis__> but networkd takes over on my current pi3 image
[15:04] <mup> PR snapcraft#770 closed: HACKING.md: list dependencies to install with pip <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/770>
[15:04] <ogra_> not here
[15:04] <morphis__> ogra_: there is a /etc/netplan/00-initial-config.yaml  which enables dhcp for all ethernet devices
[15:05] <morphis__> and networkctl marks my en* devices as configured
[15:05] <ogra_> well, i dont have issues on my devices ...
[15:05] <morphis__> ogra_: I don't have issues too
[15:05] <ogra_> they both have a wlan0 config though
[15:06] <morphis__> just trying to understand what the current state is
[15:06] <jamespage> coreycb, did you?
[15:06] <ogra_> the current state is that we wait for subiquity
[15:06] <morphis__> ogra_: and what exactly are you waiting for?
[15:06] <ogra_> that will then forcefully re-config
[15:06] <ogra_> missing UI bits fior fixed bugs
[15:06] <coreycb> jamespage, a double #
[15:07] <jamespage> coreycb, yah
[15:07] <jamespage> lolo
[15:07] <jamespage> cargonza, ditto you ##openstack-snappy
[15:11] <morphis__> ogra_: what will it re-config? network configuration via netplan?
[15:11] <ogra_> everything
[15:11] <morphis__> or via /etc/network/interfaces.d?
[15:11] <ogra_> default user ... network etc
[15:11] <ogra_> subiquity will forecefully do a basic config
[15:12] <ogra_> since that kills your system if it doesnt succeed it has been ripped out til all UI bits for all config pieces are there
[15:12] <morphis__> ogra_: so who is currently putting /etc/netplan/00-initial-config.yaml in?
[15:12] <ogra_> i guess netplan
[15:13] <morphis__> ok, where are the netplan packages we currently pull in?
[15:13] <ogra_> in the PPA
[15:13] <mup> PR snapd#1788 opened: snapstate: use umount --lazy when removing the mount units <Created by mvo5> <https://github.com/snapcore/snapd/pull/1788>
[15:16] <morphis__> ogra_: which ppa?
[15:17] <ogra_> the ubuntu-core build PPA ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[15:22] <morphis__> ogra_: thanks
[15:32] <mup> PR snapd#1789 opened: many: when installing snap file derive metadata from assertions unless --force-dangerous <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1789>
[15:35] <nessita> elopio, hi! who is in charge of snapcraft/snappy docs? I'm following http://snapcraft.io/create/ and it mentions snapcraft 2.11 while in xenial we already have 2.15.1
[15:37] <mup> PR snapcraft#769 closed: Minor fixes for typos in --help <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/769>
[15:39] <mup> PR snapd#1790 opened: store: set initial device session <Blocked> <Created by matiasb> <https://github.com/snapcore/snapd/pull/1790>
[15:48] <davidcalle> nessita: "you'll need to have Snapcraft 2.11 or later installed"
[15:49] <mup> PR snapcraft#764 closed: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/764>
[15:49] <nessita> davidcalle, users don't read text, we just look at the pretty pictures or bash-clis :-P (thanks)
[15:50] <ysionneau> hmmm
[15:50] <ysionneau> "the requried kernel commandline snap_core is not set" after upgrading os.snap
[15:50] <ysionneau> what is supposed to be in snap_core ?
[15:50] <sergiusens> davidcalle oh, btw
[15:51] <sergiusens> davidcalle https://bugs.launchpad.net/snapcraft/+bug/1618126
[15:51] <mup> Bug #1618126: tour: snapcraft upload does not return a url <Snapcraft:New> <https://launchpad.net/bugs/1618126>
[15:52] <davidcalle> nessita: the point is valid though, the plan was to update it when we have breaking changes or new major versions.
[15:52] <morphis__> ogra_: also is that known that with a image generated for the pi3 from edge neither gadget or kernel snaps are listed?
[15:53] <ogra_> morphis__, nope
[15:54] <morphis__> it also redownloads the core snap
[15:54] <ogra_> mvo, ^^^
[15:54] <sergiusens> davidcalle which makes me want to delete https://github.com/snapcore/snapcraft/blob/master/docs/upload-your-snap.md
[15:54] <sergiusens> davidcalle and https://github.com/snapcore/snapcraft/blob/master/docs/your-first-snap.md
[15:56] <davidcalle> sergiusens: oh thanks, when I saw the title, I thought it was an issue on your side. The store API is not returning it at all?
[15:58] <sergiusens> davidcalle we changed the whole workflow
[15:59] <ysionneau> any idea what snap_core is supposed to be in the cmdline ?
[16:02] <davidcalle> sergiusens: I'm about to EOD, can you take some time tomorrow to walk me through the new workflow? I may have some assumptions about it that could use an update.
[16:05] <ysionneau> hm it seems I reached the end of what I could squeeze out of U-D-F to generate working images
[16:05] <ysionneau> with new os.snap it does not work anymore
[16:05] <ysionneau> what's the working replacement for U-D-F then?
[16:10] <ogra_> ysionneau, u-d-f
[16:10] <ogra_> from the u-d-f snap package
[16:11] <ysionneau> ah right a new u-d-f
[16:12] <ysionneau> snap find udf ?
[16:14]  * ysionneau does not find udf package
[16:14] <ogra_> snap install ubuntu-device-flash --edge --devmode
[16:15] <mup> PR snapd#1791 opened: Support checking account-key-request assertions <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1791>
[16:21] <ysionneau> yann@imperium:~/dev/snappy_paros/tools/snappy/paros_image$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 -o paros.img --channel edge  --gadget ../../../paros_2.0_all.snap --kernel ../../../paros_kernel/paros-kernel_3.10.97_armhf.snap --os ubuntu-core --developer-mode --enable-ssh
[16:21] <ysionneau> cannot use "../../../paros_2.0_all.snap", must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"]
[16:21] <ysionneau> I cannot supply my gadget file?
[16:26] <ogra_> ysionneau, i think there was an option ot override that check ...
[16:26] <ogra_> damn .. but i forgot what it was, mvo should be able to help
[16:27] <ysionneau> I wasn't using extra option before but if there is one I'm interested :)
[16:27] <ogra_> i think it was an env var ... morphis__ do you remember ?
[16:36] <ysionneau> please pm it to me if you find something, I've got to do
[16:36] <ysionneau> to go*
[16:36] <ysionneau> thanks for the help!
[16:43] <morphis__> ogra_: I've just changed the kernal snap, for the gadget I can't say :-)
[16:43] <ogra_> hmm
[17:03] <mup> PR snapd#1718 closed: daemon,overlord: add subcommand handling to snapctl <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1718>
[17:35] <ogra_> hrm
[17:36] <ogra_> ubuntu@pi3:~$ sudo reboot
[17:36] <ogra_> Failed to start reboot.target: Connection timed out
[17:36] <ogra_> ...
[17:36]  * qengho hugs systemd.
[17:37] <ogra_> well, seems kill doesnt work ...
[17:38] <ogra_> i cant kill -9 any processes
[17:38] <ogra_> pitti, ^^^ i have a suspicion that systemd on arm has some issues
[17:39]  * ogra_ had the kill -9 issue before and thought it was only subiquity ... but seemingly it is deeper in the system since subiquity was unseeded
[17:44] <mup> PR snapd#1792 opened: asserts: introduce device-session-request <Created by pedronis> <https://github.com/snapcore/snapd/pull/1792>
[17:44] <pitti> ogra_: do you have a full journal from that system? signal handling is unrelated to pid 1, that sounds kernel-ish
[17:45] <ogra_> well, i rebooted ...
[17:46] <mup> PR snapd#1793 opened: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <https://github.com/snapcore/snapd/pull/1793>
[17:47] <ogra_> hmm... and there is no logging in journalctl between this morning reboot and the reboot i did just now
[17:47] <ogra_> well, actually it didnt log anything since the 26th
[17:47] <ogra_> thats weird
[17:48] <ogra_> uh
[17:48] <ogra_> no, actually i see the clock switch backwards during boot in the log
[17:49] <ogra_> pitti, http://paste.ubuntu.com/23112815/
[17:49] <ogra_> this is a werid log
[17:49] <ogra_> (syslog though)
[17:50] <ogra_> it seems to jump to aug. 26th during boot
[17:54] <pitti> ogra_: systemctl --failed ?
[17:58] <ogra_> ubuntu@pi3:~$ sudo systemctl --failed
[17:58] <ogra_> 0 loaded units listed. Pass --all to see loaded but inactive units, too.
[17:58] <ogra_> To show all installed unit files use 'systemctl list-unit-files'.
[17:58] <ogra_> nothing... but as i said, i rebooted by now
[18:04] <pbek> hello all, since today when I upload my qownnotes snap to the store I get an error message: Launchpad uploaded this snap package to the store, but the store failed to
[18:04] <pbek> scan it:
[18:04] <pbek>  'Exec=usr/bin/QOwnNotes' does not use: qownnotes
[18:04] <pbek> (the same snapcraft.yml worked yesterday)
[18:04] <pbek> that's the yml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
[18:04] <pbek> Does anyone have an idea?
[18:34] <slangasek> mwhudson, cyphermox: sounds like we should get nplan 0.11 or later into the ppas soonish?
[18:40] <cyphermox> yes
[18:40] <cyphermox> is it somewhere right now?
[18:51] <sergiusens> ogra_ mind adding a manual test case here https://github.com/snapcore/snapcraft/blob/master/manual-tests.md for kernel building?
[18:52] <kyrofa> pbek, your .desktop file is off
[18:52] <kyrofa> pbek, try changing the Exec to `Exec=qownnotes`
[18:52] <kyrofa> pbek, so you use the command you exported
[18:53] <kyrofa> pbek, the desktop file is not run from within $SNAP-- it's run from outside the snap altogether
[18:53] <kyrofa> pbek, so usr/bin/QOwnNotes does not exist. You need to run the app like a user would, using the qownnotes in the PATH
[18:54] <pbek> kyrofa: thanks a lot for mentioning, I will try that!
[18:54] <kyrofa> pbek, sure thing!
[19:16] <sergiusens> jdstrand hey there, is this correct? /dev/shm/snap/my-snap/my-mem (my-snap is my snap)
[19:18] <jdstrand> sergiusens: no. use /dev/shm/snap.my-snap.<anything else including '/'>
[19:18] <sergiusens> ah, thanks
[19:32] <nessita> anyone with experience using debian packages as dependency for a snap part? I'm listing a few debian deps as "stage-packages" for a part and getting "Error downloading stage packages for part 'magicicada-client': no such package 'gir1.2-notify'"
[19:33] <nessita> from the docs " This method can reuse any of the 48000 .deb packages that traditional Ubuntu provides" I understand I can list as many debian package names as needed
[19:36] <seb128> nessita, there is no such deb in ubuntu, you forgot a -0.7?
[19:37] <seb128> nessita, https://launchpad.net/ubuntu/+source/libnotify
[19:37] <seb128> nessita, see the debs names listed
[19:37] <nessita> seb128, ah, I guess I was confused because sudo apt-cache policy gir1.2-notify returns a result, and apt-get install also works :-)
[19:37] <nessita> seb128, thank you!
[19:38] <seb128> nessita, it does?
[19:38] <nessita> seb128, yeah
[19:38] <seb128> weird
[19:38] <nessita> nessita@miro:~/projects/magicicada-client/current$ sudo apt-cache policy gir1.2-notify
[19:38] <nessita> gir1.2-notify-0.7:
[19:38] <nessita>   Installed: 0.7.6-2svn1
[19:38] <nessita>   Candidate: 0.7.6-2svn1
[19:38] <seb128> ah
[19:38] <nessita> but as you say the package name is gir1.2-notify-0.7
[19:38] <seb128> right, it's named -0.7
[19:38] <ogra_> sergiusens, a manual test case for building a kernel ? what do you want to verify with that ?
[19:38] <nessita> seb128, yeah, just noticed, thank you!
[19:38] <seb128> apt seems to do something weird
[19:38] <seb128> yw!
[19:41] <sergiusens> ogra_ ask elopio
[19:41] <sergiusens> ogra_ just to see thst nothing breaks in every release
[19:43] <mup> PR snapcraft#766 closed: Better file conflict message <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/766>
[19:46] <mup> PR snapcraft#768 closed: Update kernel meta to the latest spec <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/768>
[19:48] <mup> PR snapd#1794 opened: devicestate: some cleanups and solving a couple todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/1794>
[19:52] <kyrofa> jdstrand, can I ask you to take a look at #1586465 for the reviewer tools when you're able?
[19:52] <mup> Bug #1586465: Add support for hooks <Canonical Click Reviewers tools:New> <Snapcraft:New> <snapd (Ubuntu):Fix Committed by kyrofa> <https://launchpad.net/bugs/1586465>
[19:55] <ogra_> sergiusens, elopio, i doubt it makes any sense to build a kernel  without a full image test ... (you need to check bootability etc)
[19:56] <ogra_> and the store already does a lint check when uploading the auto-built snap so issues will be catched there
[19:58] <ogra_> sergiusens, elijah all we could perhaps test is to roll an empty kernel snap and check in the snap.yaml that the values didnt return ... but given the whole code was ripped out thats very unlikely anyway ;)
[19:58] <ogra_> err
[19:58] <ogra_> s/elijah/elopio/ ... sorry
[20:00] <elopio> ogra_: I would like to have documented and execute for every release a test of building the kernel and booting it.
[20:01] <elopio> I know we are not there yet.
[20:01] <elopio> If you think we are safe making releases with that test, that's ok for me. We can wait until ubuntu-image is ready.
[20:01] <ogra_> hmm, thats now pretty deeply integrated with LP and nearly fully automated ... you can indeed do it locally but that wont tell you much
[20:01] <ogra_> i'll think about it
[20:03] <elopio> ogra_: thanks.
[20:03] <elopio> s/with that test/without that test. :)
[20:06] <mup> PR snapd#1795 opened: camera interface improvements <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1795>
[20:28] <nessita> sergiusens, hi! what's the proper path for getting assistance for a snapcraft error? https://pastebin.canonical.com/164307/
[20:28] <nessita> trying to follow the same procedures as end users :-)
[20:33] <josepht> nessita: either ask here, the snappy-playpen channel on gitter, or the mailing list.
[20:34] <mup> PR snapd#1794 closed: devicestate: some cleanups and solving a couple todos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1794>
[20:36] <nessita> josepht, thanks.
[20:36] <nessita> Help! snapcraft is failing when trying to build a part and the error is unclear on how to get it fixed https://pastebin.canonical.com/164307/
[20:36] <nessita> hum, I should use a public paste :-/
[20:42] <sergiusens> nessita we don't have a real solution for that yet, except for telling people about http://stackoverflow.com/questions/14296531/what-does-error-option-single-version-externally-managed-not-recognized-ind
[20:44] <nessita> sergiusens, perhaps snapcraft can fetch latest setuptools instead of using the system's?
[20:45] <sergiusens> nessita the setuptools in xenial are fine with this, what needs updating is setup.py
[20:46] <nessita> sergiusens, is "my" setup.py you mean?
[20:46] <sergiusens> nessita yes yours... or wait for us to fix
[20:49] <nessita> sergiusens, is there any doc I can read about what I need to change in my setup.py? or what command I can run to make this error appears and fix it
[20:55] <mup> PR snapcraft#762 closed: node plugin: run build in pull phase to download dependencies <Created by smoser> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/762>
[20:56] <smoser> \o/
[20:58] <mup> PR snapd#1796 opened: interfaces: add screen-inhibit-control interface (LP: #1604880) <Created by jdstrand> <Conflict> <https://github.com/snapcore/snapd/pull/1796>
[20:58] <sergiusens> nessita not that I know of; I still get confused with setuptools distutils eggs and what not to have it handy
[20:59] <sergiusens> nessita is your snapcraft.yaml anywhere?
[20:59] <nessita> sergiusens, let me push it
[20:59] <sergiusens> smoser thanks for the PR
[21:04] <nessita> sergiusens, https://code.launchpad.net/~nataliabidart/magicicada-client/snapping/+merge/304417
[21:04] <nessita> sergiusens, be aware I'm not sure what I'm doing, yet :)
[21:05] <nessita> sergiusens, I'm following http://snapcraft.io/create/ and making free interpretation of things
[21:11] <sergiusens> ev do you have something I can test this with? https://github.com/snapcore/snapcraft/pull/752/files
[21:11] <mup> PR snapcraft#752: Ant properties, build target, and destination directory options <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/752>
[21:11] <sergiusens> nessita that's fine
[21:12]  * sergiusens install bzr
[21:14] <ev> sergiusens: cooking something up
[21:15] <sergiusens> ev if you have something simple, please add to integration_tests :-)
[21:15] <ev> sergiusens: confused; I did add an integration_test
[21:17] <sergiusens> ev err ignore me :-)
[21:18] <ev> ooh, slight bug: properties and targets in the docstring should be ant-properties and ant-targets
[21:18] <ev> fixing
[21:19] <sergiusens> ok, this just means I need to look at this closer
[21:19] <ev> damn, and I was so close ;)
[21:32] <mwhudson> slangasek, cyphermox: yes
[21:32] <mwhudson> slangasek, cyphermox: it's just dch -Dxenial "build for xenial" && dput ...
[21:32] <sergiusens> nessita it might take me a bit on my 6Mbps
[21:33] <slangasek> mwhudson: can you do this, for whichever version you would like me to also copy to the snappy-dev ppa? :)
[21:34] <kyrofa> sergiusens, lucky, you have 6?
[21:34] <mwhudson> slangasek: sure
[21:34] <mwhudson> slangasek: aren't we supposed to be talking now? :)
[21:34] <slangasek> mwhudson: we clearly are talking!
[21:35] <sergiusens> kyrofa I was told I was going to be upgraded from 3 to 6 but it still feels like 3 according to speedtest
[21:35] <sergiusens> and over the air ;-)
[21:35] <mwhudson> slangasek: multi format communication!
[21:35] <kyrofa> Yeah that's what mine is right now too. It's terrible!
[21:40] <nessita> sergiusens, thanks!
[21:43] <mup> PR snapd#1797 opened: interfaces: add upower-observe interface (LP: #1595813) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1797>
[21:51] <ev> sergiusens: https://gist.github.com/evandandrea/b1ed4ffa0395f994ec31a6a6101d0cb4
[21:51] <ev> produces the same snap as https://github.com/evandandrea/cassandra-snap/blob/master/parts/plugins/x-cassandra.py did
[22:30] <mup> PR snapd#1765 closed: many: move network initialization to a separate service <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/1765>
[22:33] <lool> would someone know where the code corresponding to the ubuntu-device-flash snap is stored? I can't find the same error strings in lp:goget-ubuntu-touch
[22:33] <mup> PR snapd#1798 opened: firstboot: change location of netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1798>
[22:34] <lool> doesn't seem to be under https://launchpad.net/~snappy-dev/+snaps either
[22:47] <slangasek> lool: if you find it, please let me know; that would help for ubuntu-image porting work as well...
[22:48] <lool> slangasek: lp:goget-ubuntu-touch does not seem extremely far off, and there were mentions of a derived branch in recent conversations lp:~mvo/goget-ubuntu-touch/minimal-first-boot
[22:48] <lool> but I can't confirm it's the same code
[23:14] <sarnold> does this look familiar? Download snap "ubuntu-core" (352) from channel "stable" (read tcp 192.168.122.102:58452->64.94.115.12:443: read: connection reset by peer)
[23:23] <sarnold> apt-get purge snapd && apt-get install snapd fixed that.
[23:26] <lool> jdstrand: thanks for taking the time to do another pass on the docker snap; see card/pull request for what I know about the breakage of this snap
[23:26] <lool> jdstrand: in fact fwding you the email
[23:31] <sergiusens> jdstrand hi there, has cprov briefed you on `grade`?
[23:35] <cprov> sergiusens: I didn't. Any side effect on CRT ?
[23:35] <sergiusens> cprov it might block uploads :-)
[23:35] <sergiusens> in any case I affected click-reviewers-tools to the bug
[23:36] <cprov> If absent it defaults to stable, exactly as confinement
[23:37] <cprov> And Snacraft init starts with develop
[23:38] <sergiusens> ev nice! I do have two observations; glue seems temporary which is good; [build-]environment is coming for parts and apps but in your custom plugin you could of done it by overriding the `env` method.
[23:38] <sergiusens> cprov yes, that is all good :-) Problem is, we might get rejected as the key might be unknown to c-r-t
[23:38] <sergiusens> unless that works already
[23:39] <cprov> Yes, should have checked that, sorry
[23:40] <mup> PR snapd#1799 opened: asserts,cmd/snap: add "name" header to account-key(-request) <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1799>
[23:59] <sergiusens> cprov no need to be sorry ;-)