[01:46] <mwhudson> argh
[01:46] <mwhudson> the way LDFLAGS is set for classic snap builds is painful
[02:18] <mup> Bug #1662357 opened: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662357>
[02:53] <mup> PR snapcraft#1165 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1165>
[03:21] <mwhudson> waaait a minute
[03:21] <mwhudson> can i build classic snaps on launchpad for all architectures?
[03:22] <mwhudson> strongly getting the feeling that the interpreter is wrong for these builds
[07:07] <mup> PR snapd#2957 opened: snapstate: include change kind/summary in error report <Created by mvo5> <https://github.com/snapcore/snapd/pull/2957>
[08:29] <mup> PR snapd#2958 opened: snapstate: disable running the configure hook on classic for the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2958>
[08:36] <mup> Bug #1668891 opened: Can install non classic snap with --classic, but classic flag isn't set <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1668891>
[09:07] <mup> PR snapd#2959 opened: data: re-add snapd.refresh.{timer,service} with weekly schedule <Created by mvo5> <https://github.com/snapcore/snapd/pull/2959>
[09:21] <thresh> jdstrand, what exactly does that change mean, btw?  I'm too stupid to understand docs.
[09:26] <mup> PR snapd#2960 opened: release: add linuxmint 18 to the whitelisted distros <Created by mvo5> <https://github.com/snapcore/snapd/pull/2960>
[09:46] <mup> PR snapd#2961 opened: ifacestate: re-generate apparmor in InterfaceManager.initialize() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2961>
[10:21] <mup> PR snapd#2962 opened: tests: temporarly unbreak docker by manually connecting the interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/2962>
[10:30] <Son_Goku> gurgle
[10:39] <mup> PR snapd#2963 opened: interfaces: use MockInfo in tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/2963>
[10:40]  * ogra_ hands Son_Goku a snorkel
[10:40]  * Son_Goku takes it, then chokes on it
[10:41] <ogra_> should i have removed the cork at the end ?
[10:42] <paulliu> hi. I have a problem. I'm snapcrafting zenity. But zenity wants to load its ui file from /usr/share/zenity/zenity.ui
[10:43] <paulliu> I'd like to know if there's any tricks other than patching zenity?
[10:45] <Son_Goku> ogra_: probably :P
[10:46] <ogra_> :)
[11:08] <mup> PR snapd#2962 closed: tests: temporarly unbreak docker by manually connecting the interfaces <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2962>
[11:09] <mup> PR snapd#2957 closed: snapstate: include change kind/summary in error report <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2957>
[11:24] <Son_Goku> ogra_: I hate golang now
[11:24] <Son_Goku> a lot
[11:24] <Son_Goku> before, I just disliked it
[11:24] <Son_Goku> :/
[11:25] <mup> PR snapd#2964 opened: errtracker: forward port the 2.22.7 fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/2964>
[11:38] <mup> PR snapcraft#1166 opened: tests: Fix name registration window limit test to latest changes <Created by fgallina> <https://github.com/snapcore/snapcraft/pull/1166>
[11:56] <zioproto> coreycb, james I was able to compile the nova package versione 13.1.3 I pushed stable/mitaka and pristine-tar branches to https://code.launchpad.net/~zioproto/ubuntu/+source/nova/+git/nova    How does it work for the merge request on launchpad ? I have to do 1 MR for each branch ? I will be testing the new package on our staging cluster. I will do the merge request when I am sure it is okay.
[11:56] <zioproto> ops wrong channel :)
[11:57] <zioproto> sorry for the noise:)
[13:25] <ssweeny> jdstrand: awesome, thanks!
[13:38] <mup> PR snapd#2965 opened: snapstate: error in LinkSnap() if revision is unset <Created by mvo5> <https://github.com/snapcore/snapd/pull/2965>
[13:44] <enoch85_work> hey, anyone knows where kyrofa is?
[13:49] <jdstrand> thresh: the snap declaration issued by the store did not include an auto-connection constraint when it should have so that would make snapd auto-connect snaps that plugged yours
[14:06] <mup> PR snapd#2966 opened: daemon: DevModeDistro does not imply snapstate.Flags{DevMode:true} <Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/2966>
[14:23] <mup> Bug #1669000 opened: classic snap can't use confinement override <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1669000>
[14:46] <Tryum> ping didrocks (Thibault Jochem ^^)
[14:51] <mup> Bug #1669012 opened: Can't reinstall a snap already installed switching confinement mode <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1669012>
[14:51] <jdstrand> morphis_: hey, I was looking into mmcli not auto-connecting and it seems your yaml should be: http://paste.ubuntu.com/24090328/
[14:51] <morphis_> jdstrand: hey
[14:51] <morphis_> jdstrand: that syntax was working quite well so far, what is broken with this short form?
[14:52] <jdstrand> morphis_: I'm not sure if that is a bug in snapd or not. I know mmcli: null is supposed to work
[14:52] <morphis_> hm
[14:52] <morphis_> auto-connection AFAIK works
[14:53] <morphis_> or do you see this with a pretty recent snapd version?
[14:53] <jdstrand> morphis_: but this is supposed to be a dict. I'm looking at the docker snap declaration and the modem-manager snap declarations, and they are identical in how they allow auto-connect, but docker's works and modem-manager does not
[14:53] <jdstrand> morphis_: and this is the difference I see in their snap.yamls
[14:54] <jdstrand> $ snap --version
[14:54] <jdstrand> snap    2.22.7
[14:54] <morphis_> hm
[14:55] <morphis_> jdstrand:  let me try to reproduce this
[14:55] <jdstrand> morphis_: hmm. if I look at nm, it has the same style as mm, and it auto connects
[14:56] <morphis_> yeah, that is what makes me wonder and we have a CI test in place which verifies this doesn't break
[14:57] <jdstrand> morphis_: oh, weird
[14:57] <jdstrand> hmm, this is on classic
[14:58] <jdstrand> morphis_: let me reproduce on all snaps
[14:58] <jdstrand> I just noticed that :modem-manager and modem-manager:service were both in the list
[14:59] <morphis_> jdstrand: ah you do this on classic?
[14:59] <jdstrand> morphis_: I did. gimme a minute before spending time on it
[14:59] <morphis_> ok
[15:03] <jdstrand> morphis_: it is fine on all snaps
[15:03] <mup> PR snapd#2955 closed: cmd: fixes to run correctly on opensuse <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2955>
[15:04] <morphis_> jdstrand: ok
[15:04] <morphis_> reminds me we should put a CI job for testing classic in one day too
[15:04] <mup> PR snapd#2967 opened: tests: remove workaround for docker again, snap-declaration is fixed now <Created by mvo5> <https://github.com/snapcore/snapd/pull/2967>
[15:09] <jdstrand> morphis_: is ofono supposed to auto-connect to bluez?
[15:09] <jdstrand> there is no snap decl for that
[15:16] <didrocks> hey Tryum ;)
[15:17] <didrocks> Tryum: saw your email on the ML, let's see if that triggers ideas :)
[15:18] <jdstrand> morphis_: it seems clear there should be, so I granted it just now
[15:19] <morphis_> jdstrand: oh thanks, yeah it should
[15:24] <mup> PR snapd#2960 closed: release: add linuxmint 18 to the whitelisted distros <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2960>
[15:25] <mup> PR snapd#2964 closed: errtracker: forward port the 2.22.7 fixes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2964>
[15:39] <jdstrand> mvo: hey, I have 2 PRs that are 'Waiting for status to be reported' for travis-ci. They were submitted/updated yesterday. is there an issue with travis?
[15:39] <jdstrand> https://github.com/snapcore/snapd/pull/2948 and https://github.com/snapcore/snapd/pull/2956
[15:39] <mup> PR snapd#2948: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2948>
[15:39] <mup> PR snapd#2956: interfaces: allow 'getent' by default with some missing dbs to various interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2956>
[15:43] <mvo> jdstrand: yes, travis is in unhappy-land currently, I think related to the s3 outage the other day
[15:57] <jdstrand> mvo: ah, ok, thanks
[15:57] <mvo> jdstrand: also thanks for your feedback on the dynamic-detection of the apparmor features branch, happy to look at the directory instead of version_signature
[15:58] <mvo> jdstrand: lets talk tomorrow or friday, I need to get 2.23 out of the door today but I'm keen to fix snapd/snap-confine interaction soon :)
[15:58] <jdstrand> mvo: we might want to discuss with tyhicks and come up with a plan for making this easier/more robust
[15:58] <jdstrand> mvo: ah, ok, sure
[15:58] <mup> PR snapd#2965 closed: snapstate: error in LinkSnap() if revision is unset <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2965>
[15:59] <jdstrand> mvo: would you ind looking at 2948 and 2956 for 2.23 then?
[15:59] <jdstrand> mind*
[15:59] <mvo> jdstrand: yeah, I was  unaware of this problem until recently, we added some more distros for 2.23 (mint,zorin) so its not super urgent
[15:59] <mvo> jdstrand: sure, let me check
[16:00] <jdstrand> mvo: 2956 is super obvious. 2948 impacts morphis_' snaps, but he gave the +1
[16:00] <mvo> jdstrand: could you please merge master and push them? that hopefully wakes travis up again
[16:00] <jdstrand> sure
[16:02] <jdstrand> mvo: done for both. it looks like travis is 'in progress'
[16:03] <mvo> jdstrand: I keep an eye on it and restart if needed, thank you. reviewing now
[16:03] <jdstrand> mvo: thanks!
[16:14] <mup> PR snapd#2968 opened: overlord/snapstate: drop forced devmode <Created by chipaca> <https://github.com/snapcore/snapd/pull/2968>
[16:18] <pshod> set up a pi3 with core
[16:18] <pshod> from console asks for localhost login
[16:19] <pshod> ssh with sso username asks for password
[16:24] <pshod> help!!!
[16:25] <kyrofa> pshod, did it ever work?
[16:25] <kyrofa> pshod, or did you just finish the initial setup?
[16:26] <pshod> got till successfully registering my sso account
[16:28] <pshod> ssh ssousername@192.168.1.18
[16:28] <kyrofa> And your SSO account has SSH keys in it?
[16:28] <pshod> using this from the machine from which ssh keys are generated
[16:28] <pshod> yes
[16:28] <kyrofa> RSA ones (I seem to remember DSA not being supported)
[16:28] <pshod> should the pi3 be shown @ my sso accnt
[16:28] <pshod> ?
[16:28] <pshod> yes
[16:29] <pshod> twas a rsa key
[16:29] <kyrofa> pshod, run ssh with -vvv and pastebin the output (feel free to sanitize as necessary)
[16:29] <pshod> on every boot it goes to localhost login screen
[16:29] <pshod> okay.
[16:29] <pshod> wait.
[16:30] <kyrofa> pshod, that sounds like it may be an old image-- I think it should be listing available keys and its IP address
[16:30] <kyrofa> pshod, where did you get it?
[16:30] <pshod> from the ubuntu's site
[16:31] <kyrofa> davidcalle, how do I log a bug against https://developer.ubuntu.com/core/get-started/dragonboard-410c ?
[16:31] <kyrofa> pshod, can you please give me the link you used?
[16:31] <kyrofa> pshod, the link to the image could be out of date, I've discovered that before
[16:33] <davidcalle> kyrofa: https://github.com/ubuntudesign/developer.ubuntu.com/issues
[16:36] <davidcalle> pshod: I'm interested in where you got the image as well
[16:37] <pshod2> http://pastebin.com/rKHrQGPx
[16:37] <pshod2> pshod here
[16:37] <pshod2> frm inside vm
[16:37] <pshod2> david: ubuntu's website
[16:38] <pshod> https://github.com/ubuntudesign/developer.ubuntu.com/issues
[16:40] <pshod2> https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3
[16:40] <pshod2> tis is the link
[16:40] <pshod2> to the image
[16:41] <jdstrand> mvo: I think you may want to read and weigh in on https://github.com/snapcore/snapd/pull/2947#discussion_r103728147
[16:41] <mup> PR snapd#2947: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
[16:43] <kyrofa> davidcalle, interesting, that page is using releases, whereas the DB one uses cdimage
[16:43] <kyrofa> davidcalle, releases hasn't been updated since november
[16:44] <davidcalle> kyrofa: https://github.com/ubuntudesign/developer.ubuntu.com/pull/223
[16:44] <kyrofa> davidcalle, whereas cdimage was updated the end of January: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[16:44] <kyrofa> davidcalle, ah ha!
[16:45] <kyrofa> pshod2, try the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ instead
[16:45] <mvo> jdstrand: sure, looking
[16:46] <jdstrand> mvo: it's kind of a philosophical question that I think requires an architect/lead to consider
[16:46] <mvo> jdstrand: that sounds more like gustavo, but I will give my 0.02€ still
[16:46] <jdstrand> hehe
[16:55] <pshod2> anybody checked the pastebin?
[16:55] <pshod2> eating
[16:55] <pshod2> brb
[16:57] <kyrofa> pshod2, please try with a newer image. If it happens again we'll look at the pastebin
[17:01] <pshod2> how long till you are here
[17:02] <pshod2> i will download it and flash
[17:02] <pshod2> will take me some
[17:09] <kyrofa> pshod2, I'll be here for about 5 hours or so
[17:24] <pshod> md5?
[17:24] <pshod> should i cpy?
[17:24] <pshod> kyrofa
[17:25] <kyrofa> pshod, I don't understand what you're asking
[17:25] <pshod> while flashing the image onto the sd card
[17:25] <pshod> there is an option of copying md5 checksum file
[17:25] <pshod> should I use it?
[17:26] <kyrofa> You mean to verify the image you downloaded was good?
[17:26] <kyrofa> That's always a good idea
[17:27] <pshod> yes
[17:27] <pshod> okay
[17:29] <pshod> kyrofa: why is it that i need to use a sd card formatter off the net instead of the in built format option
[17:29] <kyrofa> pshod, which OS are you using?
[17:30] <pshod> windows
[17:30] <pshod> though have a vm running ubuntu 16
[17:31] <pshod> corportate workstation limits
[17:31] <pshod> shitty*
[17:32] <pshod> generated the ssh keys in vm
[17:33] <pshod> would ssh from there only
[17:34] <kyrofa> pshod, that's a question for davidcalle. I didn't know Windows had a built-in tool for flashing images
[17:35] <pshod> no
[17:35] <pshod> not a built in tool
[17:35] <pshod> Win 32 diskimager, redirected from the ubintu page
[17:36] <pshod> ubuntu
[17:36] <davidcalle> pshod: it's not a formatter it's a disk flasher, you can use https://etcher.io/ if you prefer
[17:37] <pshod> yes
[17:37] <pshod> used a diff app to format
[17:38] <pshod> now pi is booting
[17:46] <davidcalle> kyrofa: PR from earlier deployed thanks for pointing it out
[17:52] <pshod> kyrofa: thanks bro reflashing with new image worked.
[17:52] <kyrofa> pshod, good deal. Thanks for the update davidcalle!
[18:29] <mup> PR snapd#2827 closed: cmd: add helpers for mounting / unmounting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2827>
[18:34] <mup> PR snapd#2948 closed: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2948>
[18:34] <mup> PR snapd#2966 closed: daemon: DevModeDistro does not imply snapstate.Flags{DevMode:true} <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2966>
[18:35] <mup> PR snapd#2961 closed: ifacestate: re-generate apparmor in InterfaceManager.initialize() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2961>
[18:53] <mup> PR snapd#2958 closed: snapstate: disable running the configure hook on classic for the core snap <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2958>
[19:01] <mterry> Why might the version from "snap version" not match my installed deb version?  (I have xenial-updates version 2.22.3 installed, but snap version says 2.22.7)
[19:02] <jdstrand> mterry: because of snap reexec on classic
[19:02] <jdstrand> mterry: the core snap has a newer snapd than what is installed on the system
[19:03] <jdstrand> mterry: and there is magic to use it instead of what is shipped in the deb
[19:06] <mterry> jdstrand: interesting.  Is there a way I can turn that off so that I can test a manually rebuilt snapd deb?
[19:06] <jdstrand> mterry: I think SNAP_REEXEC=0
[19:08] <mterry> jdstrand: ah thx!
[19:16] <mterry> running snapd manually doesn't seem easy -- it seems to re-trigger its systemd job
[19:35] <mup> PR snapd#2934 closed: errtacker,overlord/snapstate: more info in errtracker reports <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2934>
[19:40] <lazyPower> hey stgraber - just wanted to follow up on http://pad.lv/1668659    Thanks for digging deep on this one. It sounds like the "sudo mount --make-rshared/" is a viable work around until the regression is patched? Is that a safe assumption to make?
[19:42] <stgraber> lazyPower: yeah
[20:20] <mwhudson> hey
[20:20] <mwhudson> what's the status on https://bugs.launchpad.net/snapcraft/+bug/1665165 ?
[20:20] <mup> Bug #1665165: classic snaps fail to build in launchpad in archs other than amd64 <classic> <launchpad-buildd:Invalid> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1665165>
[20:23] <mwhudson> because boy did i get confused about that yesterday
[20:31] <mup> PR snapd#2968 closed: overlord/snapstate: drop forced devmode <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2968>
[21:29] <mup> PR snapd#2956 closed: interfaces: allow 'getent' by default with some missing dbs to various interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2956>
[21:56] <bdmurray> is there something equivalent to cronjobs in snaps?
[21:59] <kyrofa> bdmurray, personally I just use sleep in a normal simple service
[21:59] <mup> Bug #1669151 opened: No way to discover one's own appID <Snappy:New> <https://launchpad.net/bugs/1669151>
[22:11] <bdmurray> kyrofa: sleep for 24 hours? if its a cron.daily job
[22:12] <kyrofa> bdmurray, yep: https://github.com/nextcloud/nextcloud-snap/blob/master/src/https/scripts/renew-certs#L29
[22:17] <kyrofa> bdmurray, not saying it's ideal by any means, but it's the only way I know to do it today
[22:18] <kyrofa> bdmurray, I expect at some point snapd will expose systemd's timers
[22:19] <bdmurray> kyrofa: thanks for the idea
[22:52] <mup> PR snapd#2949 closed:  cmd/libsnap: add sc_string_append_char_pair <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2949>