[00:30] <elopio> cprov: sergiusens: hey, sorry, I couldn't access quassel for quite a while. Indeed, I had a typo on my exported var :/
[00:30] <elopio> sorry for the noise.
[00:39] <mup> PR snapd#2071 opened: interfaces,overlord/interfaces: switch to use declaration-based checking for auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/2071>
[01:26] <mup> PR snapd#2072 opened: cmd/snap: have 'snap autoimport' consider unmounted devices <Created by mwhudson> <https://github.com/snapcore/snapd/pull/2072>
[01:29] <mup> PR snapd#2068 closed: many: preparations for switching most of autoconnect to use the declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2068>
[01:50] <sergiusens> elopio cprov I am not oposed to a tools/staging_env.sh that one can source setting up the env and PS1 ;-)
[01:51] <cprov> sergiusens: that's a grand idea
[01:53] <sergiusens> cprov elopio I am on and off, but here's a bug just in case it falls off the radar LP: #1630083
[01:53] <mup> Bug #1630083: Provide sourceable script to work with the staging environment <Snapcraft:New> <https://launchpad.net/bugs/1630083>
[04:07] <mup> PR snapd#2073 opened: client, cmd/snap, daemon: add is-managed command <Created by mwhudson> <https://github.com/snapcore/snapd/pull/2073>
[06:25] <pitti> zyga: udev rules are all about events; so both a boot aand udevadm trigger will run every rule, so just attach it to teh "add" event of a device which provides the GPIO pins?
[06:26] <pitti> zyga: /sys/class/gpio/export, is that really a global thing? that doesn't sound like something you should change in udev rules then
[06:26] <pitti> or was that just simplifid/a template path?
[06:33] <mup> PR snapd#2074 opened: add /users endpoint and auto run `snap create-user --known` for unowned devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2074>
[06:37]  * kalikiana found bug 1576303 whilst trying to listen to Japanese music on the VLC snap
[06:37] <mup> Bug #1576303: Needs fontconfig integration <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576303>
[06:39] <dholbach> good morning
[06:53] <shuduo> morning
[06:57] <zyga> pitti: it wasn't simplified, that's the actual thing
[06:57] <shuduo> could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks
[06:57] <mup> Bug #1615124: apps should be able to run /usr/bin/shuf by default <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1615124>
[07:17] <mup> PR snapd#2073 closed: client, cmd/snap, daemon: add is-managed command <Created by mwhudson> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2073>
[07:23] <mup> Bug #1630145 opened: out of disk space needs better handling <Snappy:New> <https://launchpad.net/bugs/1630145>
[07:43] <mup> PR snapd#2075 opened: cmd/snap: add version command, same as --version <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2075>
[07:46] <mup> PR snapd#2026 closed: client, cmd: connect fixes <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2026>
[07:50] <morphis_> zyga: ping
[07:56] <ara> pitti, hello! would you approve snap-confine into xenial-proposed, please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snap-confine
[08:12] <zyga> morphis_: hey
[08:12] <morphis_> zyga: hey!
[08:12] <zyga> morphis_: sorry, I'm laggy, not slept much last night
[08:13] <morphis_> zyga: np :-)
[08:13] <morphis_> zyga: you already did the PR to fix the mount problem we have with the udisks2 snap?
[08:13] <morphis_> was looking for it but didn't found one?
[08:13] <morphis_> s/one/one?/
[08:13] <zyga> morphis_: no, though almost, I need to work on the all-snap side of the problem
[08:13] <morphis_> zyga: what is different there?
[08:14] <zyga> morphis_: the initial fs is /
[08:15] <zyga> morphis_: https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9
[08:15] <zyga> morphis_: I need to finish one more bit for snapd and then I'm back to confine, we're freezing this week
[08:15] <zyga> (well, today)
[08:15] <morphis_> zyga: actually this is required to be fixed before the freeze
[08:17] <zyga> morphis_: we can still change images after today so it will get fixed
[08:17] <zyga> morphis_: it will be in the released images
[08:17] <Skuggen> dpkg: error processing archive /var/cache/apt/archives/snapd_2.15.2ubuntu1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snap 2013-11-29-1ubuntu2
[08:17] <Skuggen> :)
[08:18] <morphis_> zyga: so by when? last week you said there will be a PR later that day
[08:18] <zyga> Skuggen: I think it is a known issue, I think it was fixed but perhaps that's not the case
[08:18] <zyga> morphis_: I spent literelly two weeks on this issue
[08:18] <zyga> morphis_: there's lots of hard edges there
[08:18] <Skuggen> zyga: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/1589037 just confirmed so far
[08:18] <mup> Bug #1589037: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.5 <amd64>
 <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <snap (Ubuntu):Invalid> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1589037>
[08:19] <morphis_> zyga: good, so do you need any further help? Lean suggested to ask Seth to help you with any further problems on the mount namespace
[08:19] <zyga> morphis_: I'd love some help on that if you want to, we know how it works now but the all-snap is significantly different that someone has to sit on it and push through the issues
[08:19] <zyga> morphis_: well, the mount namespace has been released, this is /media sharing
[08:20] <zyga> morphis_: it's not a problem of "how do we do it" anymore, that part is solved
[08:20] <zyga> morphis_: this is just some extra coding time that's required now
[08:20] <morphis_> zyga: so what the actual issues?
[08:21] <zyga> morphis_: take that branch and iterate on an all-snap system, it needs to be tweaked to use different rootfs_dir and the apparmor profile needs to be adjusted
[08:21] <zyga> morphis_: then if it doesn't crash the kernel and /proc/self/mountinfo looks sane then we're good
[08:22] <zyga> morphis_: apparmor profile needs to be cleaned up a little as it it now full of redundant rules
[08:22] <zyga> morphis_: it just need polish
[08:22] <morphis_> zyga: which branch?
[08:22] <zyga> morphis_: https://github.com/snapcore/snap-confine/commits/media-sharing
[08:22] <zyga> morphis_: I don't recommend anthing but a full blown VM
[08:23] <zyga> morphis_: one line wrong and you hose your box
[08:25] <zyga> morphis_: it would be amazing if we managed to run spread on master (not this branch) on an all-snap system
[08:25] <zyga> morphis_: in qemu or linode
[08:25] <zyga> morphis_: if you could get that, it would save me a lot of time
[08:25] <zyga> morphis_: I think qemu is easier and I would find it sufficient
[08:27] <morphis_> zyga: I must say I don't see where the actual rootfs change would come into this code change
[08:27] <zyga> morphis_: look at the new struct
[08:27] <zyga> it is called...
[08:28] <zyga> rootfs_dir :)
[08:28] <zyga> https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9#diff-0ec19215f6a6c97084d2e4eb5e0b54ccR546
[08:28] <morphis_> ah
[08:28] <morphis_> zyga: there seem to be a lot other TODO's
[08:29] <zyga> morphis_: specifically?
[08:29] <morphis_> I count atleast three from the commit message
[08:29] <zyga> morphis_: ah, some of those are stale
[08:29] <zyga> morphis_: if spread passes you're in good shape
[08:29] <zyga> morphis_: I think /etc needs love on actual sharing
[08:30] <zyga> morphis_: it works but I think it's setup wrong
[08:32] <morphis_> zyga: so what else do you have on your plate which prevents you from finishing this?
[08:32] <zyga> morphis_: just one branch on snapd, carry over from last night
[08:33] <zyga> https://github.com/snapcore/snapd/pull/2066 specifically
[08:33] <mup> PR snapd#2066: many: abbreviated forms of disconnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2066>
[08:36] <morphis_> zyga: which would mean you will get back to the snap-confine later today?
[08:37] <zyga> morphis_: yes, totally
[08:37] <zyga> morphis_: nothing else on my plate
[08:37] <morphis_> zyga: I don't really have much time to support here and it looks like you're the best to get this fixed quickly
[08:37] <morphis_> zyga: so how much more time you need to finish this?
[08:39] <zyga> morphis_: I think one more day, I bet the non-all snap version will be 100% done today, including nice aa profile, the all-snap is probably trivial but maybe there are dragons, I didn't try yet
[08:40] <morphis_> zyga: non-all snap is not really the problem, we need this for all-snap
[08:40] <morphis_> in the end we want both but all-snap should be IMHO the priority
[08:41] <zyga> morphis_: it needs to work in both cases but I think we're very very close
[08:42] <morphis_> yeah
[08:42] <zyga> morphis_: just figuring out the sequence of do's and don'ts was the hard part :)
[09:04] <Skuggen> How does snappy figure out dependencies for simple binary inclusions? run ldd?
[09:17] <mup> PR snapd#2076 opened: asserts: limit model to only lowercase until we can implement case insensitive/preserving headers <Created by pedronis> <https://github.com/snapcore/snapd/pull/2076>
[09:19] <mwhudson> Skuggen: yes, i think so
[09:49] <morphis_> sergiusens: ping
[10:05] <shuduo> could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks
[10:05] <mup> Bug #1615124: apps should be able to run /usr/bin/shuf by default <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1615124>
[10:08] <zyga> shuduo: hey
[10:09] <shuduo> zyga: hi
[10:09] <zyga> shuduo: please use the network-control interface
[10:09] <zyga> :-)
[10:10] <shuduo> zyga: yes, i added it but snappy-debug still report "Log: apparmor="ALLOWED" operation="create" profile="snap.connman.connman//null-/sbin/ifconfig" pid=7741 comm="ifconfig" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none"
[10:11] <shuduo> so i guess some lines needed in snapcraft.yaml too
[10:11] <zyga> hmmm
[10:11] <zyga> that may depend on what you use ifconfig for
[10:11] <zyga> can you pease file a bug on snappy (on launchpad) with more informatio
[10:11] <zyga> it is much better than figuring it out here, most of the team is busy working on the release
[10:11] <zyga> and some last few bits for it
[10:12] <shuduo> zyga: okay. understand. i will. do you know if any exist snap use ifconfig then i can refer to?
[10:12] <zyga> shuduo: I don't know, sorry
[10:13] <shuduo> zyga: no worry. thanks.
[10:19] <ogra_> ppisati, regarding the question in bug 1627643 i think you ned to ask mwhudson or pitti
[10:19] <mup> Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643>
[10:20] <ogra_> (not sure it is actually possible at all to run nplan on a xeianl classic install)
[10:20] <ogra_> *xenial
[10:24] <ppisati> ogra_: does it need yakkety?
[10:24] <pitti> ogra_: it  will be soon, see bug 1627641
[10:24] <mup> Bug #1627641: Backport netplan to xenial <verification-needed> <network-manager (Ubuntu):Fix Released> <nplan (Ubuntu):Fix Released> <systemd (Ubuntu):Fix Released> <network-manager (Ubuntu Xenial):Fix Committed by pitti> <nplan (Ubuntu Xenial):Fix Committed by pitti> <systemd (Ubuntu Xenial):In
[10:24] <mup> Progress by pitti> <https://launchpad.net/bugs/1627641>
[10:24] <ppisati> ogra_: i can build a yakkey img if needed
[10:25] <ogra_> ppisati, well, the userspace would be totally different and we dont have yakkety snappy
[10:25] <ogra_> (i mean snappy images ... classic + snap might work)
[10:27] <ppisati> ogra_: yeah, but you said 'not sure it is actually possible at all to run nplan on a xeianl classic install' so i thought you needed some yakkety bits
[10:27] <ogra_> ppisati, yes, netplan :)
[10:27] <ogra_> (and its dependencies)
[10:40] <ogra_> ppisati, i also have the impression it is somehow related to firstboot  i seem to not get the oops on second boot either here
[10:46] <sergiusens> morphis hello hello
[10:50] <ppisati> ogra_: but do you actually get an oops? because on first boot, my wifi doesn't get any ip and nothing is printed out
[10:50] <ppisati> ogra_: just a generic 'Fail to blabla' from nplan
[10:50] <ppisati> ogra_: and upon reboot, my wifi associated immediately
[10:50] <ogra_> ppisati, i only see the wifi interface very rarely (every 10th boot or so)
[10:50] <ppisati> but no oops at all
[10:50] <ogra_> most of the time there is the oops and the device isnt shown at all in console-conf
[10:51] <ppisati> so it's before the config phase the oops
[10:51] <ogra_> the prob iss that a reboto breaks the image completely
[10:51] <ogra_> *reboot
[10:52] <ogra_> (the snappy firstboot stuff only runs after console-conf completed ... and it breaks if it gets re-run on an already booted image)
[11:01] <ogra_> niemeyer, mvo, bug 1630145 made me think ... unrelated to diskspace, snapd should probably run with an oom_score_adj "- 500" value ... so it doesnt get killed early on OOM events
[11:01] <mup> Bug #1630145: out of disk space needs better handling <Snappy:New> <https://launchpad.net/bugs/1630145>
[11:15] <mup> PR snapd#2077 opened: overlord/devicestate,docs/hooks.md:  switch prepare-device/registration opts to use nesting, some hook docs  <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2077>
[11:20] <ogra_> mvo, niemeyer, i filed bug 1630208 for the above
[11:20] <mup> Bug #1630208: snapd should be excluded from OOM <Snappy:New> <https://launchpad.net/bugs/1630208>
[11:21] <zyga> oh interesting
[11:21] <mup> Bug #1630208 opened: snapd should be excluded from OOM <Snappy:New> <https://launchpad.net/bugs/1630208>
[12:00] <mup> PR snapd#2064 closed: interfaces/builtin: add autopilot-introspection <Blocked> <Created by heber013> <Closed by heber013> <https://github.com/snapcore/snapd/pull/2064>
[12:01] <didrocks> sergiusens: hey! small quetsion, I can't find the bug reference anymore, but I'm pretty sure there was one on organize: not supporting globbing (so that you can dump the copy plugin in favor of… dump!), do you think you have time working on tihs?
[12:01] <didrocks> this*
[12:02] <sergiusens> didrocks it is already released
[12:02] <didrocks> oh
[12:02] <didrocks> it's the version in -proposed?
[12:03] <didrocks> that's probably why I couldn't find it :)
[12:03] <didrocks> didn't check for closed ones
[12:04] <sergiusens> didrocks https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_pluginhandler.py#L676
[12:04] <sergiusens> didrocks should be in -updates since 3 or 4 weeks ago
[12:05] <didrocks> sergiusens: interesting, I was sure I tried a couple of weeks ago
[12:06] <didrocks> sergiusens: so "*" : "www/" should work from what I see in the test
[12:06] <sergiusens> didrocks yes
[12:06] <sergiusens> didrocks if not, we have  anew bug :-(
[12:07] <didrocks> sergiusens: oh, I did try ".": "www" as in the copy plugin
[12:07] <didrocks> probably
[12:07]  * didrocks gives it a try
[12:08] <sergiusens> oh, different semantics indeed
[12:08] <didrocks> I prefer *, makes more sense IMHO
[12:12] <didrocks> sergiusens: so, I'm getting: Trying to organize file '*' to 'www', but 'www' already exists
[12:13] <didrocks> something (I guess snapcraft) did create indeed a "www" file
[12:13] <didrocks> I want to put everyting in www
[12:13] <didrocks> maybe the syntax is rather: "*": "www/"
[12:16] <didrocks> sergiusens: that did it! Thanks a lot :)
[12:30] <sergiusens> didrocks \o/
[12:32] <jdstrand> shuduo: please file a bug at https://bugs.launchpad.net/snappy/+filebug with steps to reproduce. you should be using 'plugs: [network-control]' to use ifconfig, however, connman is doing something different with ifconfig that isn't included in the policy atm
[12:33] <abeato> jdstrand, hi, thanks for the thorough review. I have pushed changes to the PR, with a couple of questions too
[12:35] <jdstrand> ok
[12:35] <jdstrand> thanks :)
[12:35] <abeato> sergiusens, I was wondering about your opinion on using config flags to set file paths when compiling using autotools snapcraft plugin
[12:35] <shuduo> jdstrand: it's a customer's app intend to do what connman doing. i'm trying to get source code.
[12:35] <abeato> sergiusens, we are checking $SNAP in some programs to know if it is part of a snap or not
[12:36] <abeato> sergiusens, maybe using a standard configure flag would be better and make changes more palatable for merging in upstreams
[12:36] <jdstrand> shuduo: it's possible to debug via irc. do you have time now?
[12:38] <shuduo> jdstrand: i have time but don't have source code. is it possible? :)
[12:38] <sergiusens> abeato that's what we did for click; a nice configure flag we can standarize on would be great practice; all these configure flags are just convention after all
[12:39] <jdstrand> shuduo: yes, I'll give you rules to add and you tell me what you see in the logs
[12:39] <shuduo> jdstrand: good
[12:39] <abeato> sergiusens, promoting a couple of standard configure flags would certainly be great :)
[12:39] <jdstrand> shuduo: first off, does your app require devmode for other things or are you using devmode only for this one denial?
[12:40] <abeato> sergiusens, maybe paths to data, to daemon data, and to current snap
[12:41] <shuduo> jdstrand: i already use devmode in yaml and also installation.
[12:42] <jdstrand> shuduo: you misunderstand. must you use devmode? I'd prefer to use strict mode for policy debugging but if your app doesn't work at all in strict mode, then we can leave it
[12:42] <shuduo> jdstrand: okay. let me modify it.
[12:43] <shuduo> jdstrand: i thought if devmode works then i can try strict mode.
[12:45] <jdstrand> shuduo: you are doing the right thing. but for security policy development I prefer strict mode
[12:46] <shuduo> jdstrand: i changed it to strict and scanlog output is http://pastebin.ubuntu.com/23274922/.
[12:47] <jdstrand> shuduo: can you give the output of 'snap interfaces'?
[12:48] <shuduo> jdstrand: http://pastebin.ubuntu.com/23274935/
[12:48] <jdstrand> shuduo: please connect the interfaces with:
[12:49] <jdstrand> sudo snap connect connman:firewall-control ubuntu-core:firewall-control
[12:49] <jdstrand> sudo snap connect connman:network-control ubuntu-core:network-control
[12:49] <jdstrand> sudo snap connect connman:network-manager ubuntu-core:network-manager
[12:50] <jdstrand> (though I wonder about that last one-- is it supposed to talk to NetworkManager?
[12:50] <jdstrand> )
[12:53] <shuduo> jdstrand: now output is http://pastebin.ubuntu.com/23274944/
[12:54] <shuduo> seems no complain for ifconfig
[12:54] <jdstrand> shuduo: ok, so your snap has a little bit of work to do to make ListOfServers.txt relocatable, but we can hopefully work around that
[12:54] <jdstrand> shuduo: oh, would you have seen the ifconfig denial by this point?
[12:56] <shuduo> jdstrand: no ifconfig denial now.
[12:57] <jdstrand> shuduo: ok, so maybe you just needed to connect the interfaces. you need to do that in devmode too
[12:57] <shuduo> jdstrand: in ubuntu desktop, the app will create a file ListOfServvers.txt in working directory.
[12:57] <jdstrand> (in devmode if you don't connect, the accesses that are against policy are allowed, but logged. to make the logging go away, connect the interfaces)
[12:59] <jdstrand> shuduo: you should 'cd "$SNAP_DATA"' before starting-- or choose one of the other SNAP_* variables
[12:59] <jdstrand> shuduo: and by 'you', I mean your snap
[13:00] <shuduo> jdstrand: so i guess i need a wrapper to 'cd "$SNAP_DATA"', right?
[13:01] <jdstrand> shuduo: yes
[13:04] <shuduo> jdstrand: in strict mode, the app will exit with "Failed to open default display". In devmode, it exit with "XOpenIM() failed. Unable to find fonts. check your FontConfig configuration." i claimed unity7 in snapcraft.yaml. anything missed?
[13:04] <mup> PR snapd#2078 opened: daemon: fix login API to return local macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2078>
[13:06] <jdstrand> shuduo: we are getting out of my area of expertise (I work on security policy). I suspect you need to use the desktop/gtk3 part
[13:06] <jdstrand> shuduo: eg:
[13:06] <jdstrand> parts:
[13:06] <zyga> jdstrand: hey, how are you
[13:06] <jdstrand>   something:
[13:06] <jdstrand>   ...
[13:06] <jdstrand>   after: [desktop/gtk3]
[13:06] <jdstrand> meh
[13:06] <jdstrand> parts:
[13:06] <jdstrand>   something:
[13:06] <jdstrand>     ...
[13:07] <jdstrand>     after: [desktop/gtk3]
[13:07] <jdstrand> shuduo: something like that ^, but will need others in the channel to help if that doesn't work for you
[13:07] <jdstrand> zyga: hi! :)
[13:08] <shuduo> jdstrand: okay. thanks a lot!
[13:17] <mup> PR snapd#2079 opened: tests: use test snap from the store in the content interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2079>
[13:51] <mup> PR snapd#2080 opened: daemon: do not hardcode UID in userLookup <Created by mvo5> <https://github.com/snapcore/snapd/pull/2080>
[13:52] <lool> ogra_: would you by any chance now where the ubuntu-core snaps are built for stable and edge?
[13:55] <ogra_> lool, we only build edge and propagate it ATM ...
[13:55] <ogra_> lool, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core
[13:56] <ogra_> lool, plan is to have all PPA bits SRUed by GA and then build beta/candidate without the PPA ... but keep edge on PPA with daily builds
[13:56] <lool> ogra_: is there a cron scheduling this daily?
[13:56] <ogra_> lool, yep
[13:57] <lool> oh we even build it on s390x and ppc64el
[13:57] <ogra_> ogra@lillypilly:~$ crontab -l
[13:57] <ogra_> 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1
[13:57] <ogra_> 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1
[13:57] <ogra_> ogra@lillypilly:~$
[13:57] <lool> ogra_: ah I see we do the extra ppa thing in livecd-rootfs
[13:57] <lool> snappy-dev/image snappy-dev/edge
[13:57] <ogra_> right
[13:58] <ogra_> for beta/candidate we'll have a branch with this dropped
[13:59] <lool> and edge has daily github builds of master I guess
[13:59] <lool> https://launchpad.net/~snappy-dev/+archive/ubuntu/edge
[13:59] <lool> ouch loads of stuff in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
[13:59] <ogra_> lool, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
[13:59] <ogra_> thats the long term plan
[14:00] <ogra_> lool, well, you want https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
[14:01] <lool> ogra_: if I look at xenial, there are 3 uploads from you which are superseded that we might be able to drop
[14:01] <lool> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[14:01] <ogra_> lool, not yet ... they are in -propposed (LP UI lies)
[14:01] <ogra_> apart from snapcraft i think
[14:01] <ogra_> that can actually be dropped
[14:02] <ogra_> ah, no, not yet
[14:02] <ogra_> but yeah, i check it every day
[14:02] <lool> ogra_: ok, nice
[14:02] <ogra_> for initramfs-tools i'm waiting til cyphermox and lamont are done with theit ipv6 hackery before even attempting to land the fixtrc fix
[14:03] <ogra_> *their
[14:03] <ogra_> i dont want to cause mid-air clashes of uploads there
[14:03] <lool> I wonder if we should have snap-confine from edge too
[14:03] <lool> it's recent in the image PPA though
[14:03] <mvo> pitti: did you had a chance to check https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531 ? sorry for the nudge, its somewhat urgent for the team that works on that
[14:04] <ogra_> lool, perhaps
[14:04] <ogra_> lool, thats a zyga decision :)
[14:05] <ogra_> lool, oh, and on a sidenote we also have daily images built from the edge snap http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[14:05] <ogra_> s/snap/snaps/
[14:06] <lool> ah that's useful
[14:06] <lool> albeit I can just switch to edge ubuntu-core if I need that
[14:06] <ogra_> (these builds happen on my home desktop and get rsynced though ... waiting for infinity to get use dailies on cdimage)
[14:06] <ogra_> s/use/us/
[14:29] <mup> PR snapd#2080 closed: daemon: do not hardcode UID in userLookup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2080>
[14:31] <mup> PR snapd#2078 closed: daemon: fix login API to return local macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2078>
[14:32] <joc> pitti: hi, i would appreciate some feedback on this as soon as you can https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531
[14:35] <joc> zyga: did you get the extra info you requested on the udev rules?
[14:37] <mup> PR snapd#2077 closed: overlord/devicestate,docs/hooks.md: nest prepare-device configuration options <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2077>
[14:44] <elopio> ogra_: have you tried the new snapcraft in proposed?
[14:45] <ogra_> elopio, not yet, i'll pull it in for the next build before EODing
[14:45] <ogra_> thanks for the remonder (totally forgot about that)
[14:45] <ogra_> *reminder
[14:47] <mup> PR snapcraft#848 opened: `sign-build` to prompt users for key selection <Created by cprov> <https://github.com/snapcore/snapcraft/pull/848>
[15:02] <morphis_> kyrofa: ping
[15:06] <ogra_> elopio, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core is now building with the new snapcraft ... if s390x finishes without failure the fix is good to go
[15:07] <pitti> joc: replied
[15:11] <mup> PR snapd#2081 opened: snap: relax auto-import test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2081>
[15:15] <elopio> ogra_: thanks. Let us know when done to add the verification-done tag
[15:16] <mup> PR snapd#2082 opened: overlord,daemon,snap: support gadget config defaults <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2082>
[15:16] <ogra_> elopio, done :) https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5985
[15:16] <ogra_> (all arches ... so i dont think there are regressions either)
[15:26] <mup> Bug #1630281 opened: fltk-based app snap exit with "XOpenIM() failed" <Snappy:New> <https://launchpad.net/bugs/1630281>
[15:30] <kyrofa> morphis_, pong
[15:31] <morphis_> kyrofa: hey!
[15:31] <morphis_> kyrofa: I was trying the configuration hook today with one of my snaps but I somehow miss steps to see if it was actually run or if something has failed
[15:31] <morphis_> kyrofa: if a hook prints something to stdout where should this appear?
[15:33] <kyrofa> morphis_, I believe it gets swallowed unless the hook encounters an error. Try exiting non-zero
[15:33] <morphis_> tried that
[15:34] <morphis_> but snap set didn't return with an error
[15:34] <mup> PR snapd#2083 opened: cmd/snap: generate account-key revocation requests <Created by cjwatson> <https://github.com/snapcore/snapd/pull/2083>
[15:34] <morphis_> kyrofa: did a simple shell script meta/hooks/configuration, added #!/bin/sh exit 1 and made it executable
[15:34] <kyrofa> morphis_, sounds like it's not actually running. Is the hook executable?
[15:34] <morphis_> + snapcraft snap . and then tried a snap set test=1
[15:34] <kyrofa> Ah, it's meta/hooks/configure
[15:34] <morphis_> kyrofa: ah
[15:35] <morphis_> ah, used 'configure'
[15:35] <kyrofa> morphis_, some docs here: https://github.com/snapcore/snapd/blob/master/docs/hooks.md
[15:35] <morphis_> yeah saw those already
[15:36] <morphis_> kyrofa: all I get from snapd is:
[15:36] <morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: daemon.go:174: DEBUG: uid=0;@ PUT /v2/snaps/wifi-ap/conf 14.253704ms 202
[15:36] <morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: taskrunner.go:293: DEBUG: Running task 340 on Do: Run apply-config hook for wifi-ap
[15:36] <morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: daemon.go:174: DEBUG: uid=0;@ GET /v2/snaps 1.030001ms 200
[15:36] <morphis_> ah wait
[15:36] <kyrofa> morphis_, uh oh
[15:36] <kyrofa> morphis_, that looks old
[15:36] <kyrofa> The hook was renamed recently from apply-config
[15:37] <morphis_> 2.15.2ubuntu1
[15:37] <morphis_> hm, let me try recent edge then
[15:37] <zyga> lool: get most recent release (e.g. from ppa)
[15:37] <kyrofa> morphis_, yeah, might be a re-exec issue
[15:38] <zyga> joc: I crashed again (ENOSLEEP), looking at that now
[15:38] <zyga> joc: did you talk to pitti by any chance?
[15:38] <lool> zyga: I was asking why master is not CI-ed into the PPA like for snapd
[15:38] <lool> I dont actually need it
[15:38] <joc> zyga: not about that
[15:38] <lool> seemed like logic thing to have them both
[15:39] <zyga> lool: no reason really, it was not changing much earlier, I did a one-off upload but there's currently no setup that would put master into the PPA
[15:39] <lool> zyga: right, I was thinking we should copy the snapd one, but up to you
[15:39] <zyga> lool: there's some work towards that end, we want to run snapd tests with master version of snap-confine
[15:40] <zyga> lool: which versions are we talking about?
[15:40] <lool> zyga: versions?!
[15:40] <zyga> lool: sorry, perhaps my sleepiness is making me ask the wrong question, can we start over?
[15:40] <lool> zyga: right now ubuntu-core snap is built from "edge" and "image" PPAs and pushed to edge channel then promoted
[15:41] <lool> zyga: edge PPA has snapd from master; image PPA has snapd and snap-confine from releases; would you want to include snap-confine from master in edge PPA as well?
[15:42] <zyga> not at this time
[15:42] <lool> ok
[15:42] <zyga> lool: I'm very careful with releases (famous last words) and there's nothing significant there, the version 42.1 that is in the image PPA is the right one to use
[15:42] <zyga> lool: after I release .43 I will put it to the image PPA agai
[15:43] <jdstrand> zyga: .43 will have s/ubuntu-core/core/ support?
[15:43] <zyga> jdstrand: .42.1 does
[15:44] <zyga> it's released already (to yakkety though)
[15:44] <zyga> as it is more of a OMG images thing
[15:44] <jdstrand> zyga: sure, but I was more thinking about when that would be supported in xenial
[15:44] <mvo> jdstrand, ogra_: we will have a new "core" snap in parallel to ubuntu-core soon, could we make it so that the snapcraft LP builds and the reviewsers scripts consider them the same and not complain? that would be really nice
[15:44] <zyga> jdstrand: with .43 I think, in one or two days
[15:44] <jdstrand> mvo: that landed already
[15:44] <zyga> jdstrand: I'll try to release it before flying to seoul
[15:44] <mvo> jdstrand: woah - you rock!
[15:44] <jdstrand> mvo: well, the review tools bits
[15:45] <zyga> jdstrand: unless mvo says we need it now and then we'll upgrade the SRU to .42.1
[15:45] <zyga> jdstrand: ara is working on SRU validation
[15:45] <morphis_> kyrofa: ok, nevermind, go it working now
[15:45] <jdstrand> mvo: Chipaca had some uploads of 'core' last friday, so I fixed the tools and roadmr got them live this week
[15:45] <kyrofa> morphis_, excellent!
[15:45] <morphis_> kyrofa: also any ETA on getting hook support into snapcraft?
[15:46] <kyrofa> morphis_, I believe it's a sprint topic
[15:46] <jdstrand> zyga: ack. fyi, I'm just curious. I much prefer how snapd behaves with just 'core' and want to remove 'ubuntu-core'
[15:47] <zyga> jdstrand: hmmm
[15:47] <jdstrand> cause, with the snapd from the image ppa and both core and ubuntu-core installed, you get all the interfaces twice (one set for core:* the other for :*)
[15:47] <zyga> jdstrand: well, it's tagged and works OK, if ara verifies that one we can bump the SRU to .42.1
[15:47] <morphis_> kyrofa: so actually no snapcraft support real soon (1-2 weeks)?
[15:48] <jdstrand> zyga: to be clear, I'm not trying to create work. just curious
[15:48] <zyga> jdstrand: FYI, I'm off on thursday/friday (flying)
[15:48] <zyga> jdstrand: no worries :)
[15:48] <kyrofa> morphis_, that's my impression, yes. There's some disagreement about how it should be implemented
[15:48] <jdstrand> zyga: home?
[15:48] <zyga> jdstrand: roscon
[15:48] <jdstrand> ah
[15:48] <morphis_> kyrofa: I see
[15:49] <mup> PR snapd#2081 closed: snap: relax auto-import test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2081>
[15:49] <zyga> jdstrand: and I'll be off on the following week
[15:49] <zyga> jdstrand: I should send out an email perhaps ...
[15:50] <jdstrand> yeah, probably
[16:05] <ogra_> mvo, not sure we can do that, but i can set up a parallel build with different name
[16:06] <ogra_> mvo, you need to grant me access to it in the store though
[16:06] <mvo> ogra_: hats good enough
[16:06] <mvo> ogra_: sure, adding you
[16:06] <ogra_> cool
[16:06] <ogra_> i assume we can stop ubuntu-core eventually ?
[16:07] <ogra_> and just build core
[16:08] <ogra_> mvo, how will snapd handle the cross-grade for already installed ubuntu-core ? ubuntu-core is at revision 800+ ... wont that become a prob if core starts at 1 ?
[16:10] <mvo> ogra_: not at all right now
[16:10] <ogra_> ah, k
[16:10] <mvo> ogra_: we keep the two for a bit
[16:11] <ogra_> well, i understood your long-term plan was to simply switch people over
[16:11] <ogra_> i was just wondering how you handle the revision bits in such a case
[16:11] <mvo> ogra_: this is still the case but we have not figured the details out yet
[16:11] <ogra_> ah, k
[16:16] <mup> PR snapd#2070 closed: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2070>
[16:19] <zyga> jdstrand, ara, mvo: https://bugs.launchpad.net/snap-confine/+bug/1628612 updated with SRU meta-data
[16:19] <mup> Bug #1628612: prefer "core" rather than "ubuntu-core" if installed <Snappy Launcher:Fix Released by zyga> <https://launchpad.net/bugs/1628612>
[16:20] <jdstrand> mvo: hey, so I currently have both ubuntu-core and core installed. I have snapd and snap-confine from the image ppa. how can I remove ubuntu-core?
[16:22] <zyga> jdstrand: you don't have to, we're going to work on making that happen later
[16:22] <zyga> jdstrand: but with the current arrangement there's no rush
[16:22] <jdstrand> well, snap interfaces is annoying me
[16:23] <pmcgowan> for every new snap I install I get this when I run it execv failed: No such file or directory
[16:23] <pmcgowan> the snaps I installed a while back work fine
[16:23] <pmcgowan> sure would like to fix that
[16:25] <zyga> jdstrand: ah
[16:25] <zyga> jdstrand: oh, you are seeing double?
[16:25] <zyga> jdstrand: I didn't try that
[16:26] <zyga> I wonder what's the plan for that (when oyu have both, do we move the connections over?)
[16:30] <zyga> joc: can you please take https://github.com/snapcore/snapd/pull/2065 over
[16:30] <mup> PR snapd#2065: interfaces/builtin: use udev to export GPIOs to userspace <Reviewed> <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
[16:30] <zyga> joc: just change that to what you suggested and if it works get it merged
[16:30] <zyga> joc: I need to take a nap
[16:30] <zyga> I feel so tired today
[16:31] <zyga> joc: I'll try to stay away from my computer for some time, be back when I wake up
[16:31] <joc> zyga: ok, feel better
[16:31] <jdstrand> zyga: I am seeing double. I don't know what the plan for that is. I don't know how that affects connections
[16:32] <zyga> jdstrand: ask chipaca
[16:32] <zyga> jdstrand: he's been making that work for the past few days
[16:34] <jdstrand> I see
[16:36] <pmcgowan> jdstrand, zyga sorry to bother you but any idea why this happens http://pastebin.ubuntu.com/23275810/
[16:47] <mup> PR snapcraft#849 opened: Bugfixes for gated and validate commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/849>
[16:50] <jdstrand> pmcgowan: I don't see anything wrt security policy in there. can you paste the output of 'snap list ; snap interfaces'
[16:51] <jdstrand> pmcgowan: also, what version of snapd and snap-confine are you using?
[16:52] <pmcgowan> http://paste.ubuntu.com/23275869/
[16:53] <pmcgowan>  2.15.2ubuntu1 and 1.0.38-0ubuntu0.16.04.10
[16:54] <jdstrand> pmcgowan: your ubuntu-core is ancient
[16:54] <pmcgowan> oh?
[16:54] <jdstrand> I don't know why that is
[16:54] <jdstrand> try: sudo snap refresh ubuntu-core
[16:55] <jdstrand> pmcgowan: yeah, it should be revision 423
[16:56] <pmcgowan> jdstrand, do I need to periodically refresh it ?
[16:56] <pmcgowan> its updating now
[16:56] <jdstrand> you're not supposed to have to
[16:57] <jdstrand> pmcgowan: you said that new snaps are failing. I suggest removing those failing snaps and installing again
[16:58] <pmcgowan> lets see once its updated
[16:58]  * jdstrand nods
[16:58] <pmcgowan> I cant afford the bandwidth :)
[16:59] <pmcgowan> jdstrand, Connection to the daemon failed: Get http://127.0.0.1/enable: dial unix /var/snap/canonical-livepatch/6/livepatchd.sock: connect: no such file or directory
[17:00] <pmcgowan> other snaps are running now
[17:00] <jdstrand> pmcgowan: you uninstalled canonical-livepatch?
[17:00] <jdstrand> then reinstalled?
[17:00] <pmcgowan> not yet
[17:01] <jdstrand> you might be able to stop the service and restart it, but I'd prefer uninstall/reinstall
[17:01] <pmcgowan> jdstrand, working now, thanks
[17:01] <jdstrand> cool, np
[17:02] <pmcgowan> jdstrand, what about the snap not updating?
[17:02] <pmcgowan> anything to look for there
[17:02] <jdstrand> pmcgowan: I don't know-- that might be a question for mvo or another on the snappy team
[17:12] <pmcgowan> jdstrand, is it due to the switch from ubuntu-core to core? should I remove one and get the other?
[17:13] <ogra_> mvo, https://code.launchpad.net/~snappy-dev/+snap/core ... i'll set up daily cronned builds tomorrow morning
[17:13] <pmcgowan> ogra_, quassel-kalikiana in the stable channel :)
[17:13] <ogra_> pmcgowan, heh, right, he talked about it (wont make me change to quassel though :) )
[17:13] <ogra_> thanks !
[17:14] <ogra_> jdstrand, hmm, doesnt seem like the tooools changes for "core" are live yet ...
[17:15] <ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/9/
[17:20] <ogra_> WOAH !
[17:20] <mup> PR snapcraft#850 opened: catkin plugin: add `rosdistro` to help documentation <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/850>
[17:20] <ogra_> and it seems htis one fail blocka *all* subsequent uploads of that snap
[17:20] <jdstrand> oh I missed one. shoot
[17:20] <ogra_> *blocks
[17:20] <ogra_> thats new
[17:20] <ogra_> rev 10-13 all show "Revision waiting for review of a previous upload."
[17:21] <jdstrand> yeah
[17:21] <jdstrand> that's new
[17:21] <ogra_> given they are all for different arches thats rather bad
[17:22] <ogra_> it should take that into account somehow
[17:22] <ogra_> not just blindly block because a former revision failed
[17:25] <jdstrand> I don't know the implementation. the idea is to easy reviews. eg, say you upload a snap that uses a special interface. the tools flag for manual review. the reviewer says it is ok and that future uploads are allowed with this interface (ie, snap declaration is used). then approve and then all the other go through without being flagged cause they use that snap decl
[17:25] <jdstrand> ease*
[17:25] <ogra_> well, what if an upload for ppc64el fails for some esoteric reason ...
[17:25] <ogra_> that will block all amd64 uploads afterwards
[17:27] <jdstrand> that is an unusual case that I think would need more information to be smarter
[17:27] <jdstrand> note, I didn't implement this
[17:27] <jdstrand> but I agree with the concept
[17:27] <ogra_> thats totally not unsual ... regarding the design of store uploads
[17:28] <ogra_> if i build in LP for all arches s390x or ppc64el are usually the first to be done and the first to be uploaded
[17:28] <ogra_> if there is some ppc specific interface that i enable it will then block everything
[17:29] <ogra_> so i have to say i disagree with the concept :)
[17:31] <ogra_> thats like a lottery now ...
[17:32] <jdstrand> roadmr: sorry, I missed a check cor 'ubuntu-core' -> 'core'. can you pull r755?
[17:34] <ogra_> jdstrand, if your check was an arch specific oversight, dont forget s390x too ... (we dont have it yet for that snap since i need to apply for it at the LP team first)
[17:35] <jdstrand> ogra_: it was not
[17:35] <ogra_> ah, k
[17:35] <ogra_> (i thought, because the other arches seem to have gone through before)
[17:35] <jdstrand> though there is an arch check too
[17:35] <jdstrand> this is the ubuntu-core rename to core
[17:36] <ogra_> (and looking closer i see they havent at all :P ... all manually approved before)
[17:36] <jdstrand> but s390x might be an issue too
[17:36] <ogra_> well, it wasnt for ubuntu-core
[17:37] <jdstrand> ogra_: I just checkd: s390x is considered valid by the tools. no worries there
[17:37] <jdstrand> ogra_: ok, they are all approved. I see you are publishing them
[17:38] <ogra_> heh ... it is funny how the revision history disagrees about the uploader with the "submitted by" field above
[17:38] <ogra_> according to revision history it is the shared account ... according to "submitted by" it is me
[17:39] <jdstrand> ogra_: fyi, you seem to have missed this one https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/9/
[17:39] <ogra_> (and after all it is LP under the snappy-dev account ... it just happened to be me who set it up)
[17:39] <mup> PR snapd#2084 opened: snap/squashfs: add -all-root flag to mksquashfs <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2084>
[17:39] <ogra_> published rev9
[17:40] <ogra_> roadmr, let me know when jdstrand's change was merged, then i can enable cronned daily builds for that snap
[17:40] <ogra_> (still missing a few bits on my side anyway, so no hurry)
[17:40] <jdstrand> roadmr: again, I apologize. I did the hard change last week, but the easy one I missed :\
[17:41] <ogra_> (this above was just the first manuall test build)
[17:50] <mup> PR snapd#2084 closed: snap/squashfs: add -all-root flag to mksquashfs <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2084>
[17:55] <mup> PR snapd#2085 opened: many: check installation of slots and plugs against declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2085>
[18:07] <roadmr> jdstrand: no problem, I'll pull that now
[18:09] <mup> PR snapd#2086 opened: client, cmd: prompt for password when buying <Created by pete-woods> <Conflict> <https://github.com/snapcore/snapd/pull/2086>
[18:09] <ralsina> sergiusens, elopio: in a PR for snapcraft I am getting  "Coverage decreased (-0.006%)" which is funny, but also, we are checking coverage inside the tests, which makes no sense, right?
[18:11] <om26er> ogra_, curious, whats the difference with ubuntu-core and core snap ? new name ?
[18:11] <ogra_> om26er, yep
[18:12] <ogra_> eventually we'll drop ubuntu-core
[18:13] <om26er> ogra_, I assume its to make snap based systems to not be always tagged 'ubuntu' ?
[18:13] <ogra_> right ...
[18:13] <ogra_> the all-snap images will go on being called ubuntu-* ... but there is no need to call the core snap itsellf "ubuntu-"
[18:14] <ogra_> it is simply the core execution environment for snaps ...
[18:14] <om26er> understood, makes sense.
[18:46] <mup> PR snapd#2075 closed: cmd/snap: add version command, same as --version <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2075>
[18:47] <mup> PR snapcraft#850 closed: catkin plugin: add `rosdistro` to help documentation <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/850>
[19:08] <mup> PR snapcraft#851 opened: catkin plugin: nicely handle an invalid rosdistro <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/851>
[19:11] <mup> PR snapd#2076 closed: asserts: limit model to only lowercase until we can implement case insensitive/preserving headers <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2076>
[19:35] <jdstrand> roadmr: thanks
[19:36] <mup> PR snapd#2066 closed: many: abbreviated forms of disconnect <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2066>
[19:48] <mup> PR snapd#2074 closed: client,daemon,overlord,cmd: add /v2/users and create-user on auto-import <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2074>
[20:10] <mup> Bug #1629081 changed: "git clone" fails with "source-type: git" and "source-tag: x.y.z" in "snapcraft.yml" <snapcraft> <Snappy:Invalid> <https://launchpad.net/bugs/1629081>
[20:12] <mwhudson> good morning
[20:25] <mup> PR snapd#2087 opened: snap, daemon, store: fake the channel map in the REST API <Created by chipaca> <https://github.com/snapcore/snapd/pull/2087>
[20:34] <mup> PR snapd#2079 closed: tests: use test snap from the store in the content interface test <Critical> <Created by fgimenez> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2079>
[21:27] <mup> PR snapd#2088 opened: tests: fix snap-disconnect tests after core rename <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2088>
[21:46] <mup> PR snapd#2089 opened: store: do not set store auth for local users <Created by matiasb> <https://github.com/snapcore/snapd/pull/2089>
[21:52] <mup> PR snapd#2090 opened: wip: initial cleaning up of no arg AutoConnect related bits <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2090>
[22:25] <zyga> re
[22:34] <mup> PR snapd#2091 opened: interfaces: tweak wording and comment <Created by zyga> <https://github.com/snapcore/snapd/pull/2091>
[23:02] <mup> PR snapd#2088 closed: tests: fix snap-disconnect tests after core rename <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2088>