[07:44] <zyga_> tyhicks: hey, so I had to revert the "capability sys_ptrace" removal
[07:44] <zyga> tyhicks: if you could have a look at the rationale I posted in     Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
[07:45] <zyga> 7373ee8938cebb82c88f5925d448b290d18a7122
[07:45] <zyga> tyhicks: it seems to fail if you're not root when starting snap-confine
[08:24] <cwayne> zyga: did a new snapd with that fix land in candidate?
[08:30] <zyga> tyhicks: https://github.com/snapcore/snapd/pull/2624/commits/7373ee8938cebb82c88f5925d448b290d18a7122
[08:30] <mup> PR snapd#2624: cmd/snap-confine: re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
[08:31] <zyga> tyhicks: we didn't release last night; we plan to relase early today
[08:31] <zyga> er
[08:31] <zyga> cwayne: ^
[08:33] <zyga> cwayne: candidate will be made after mvo investigates a packaging error we ran into
[08:35] <mvo> cwayne: what fix in particular?
[08:37] <cwayne> mvo: snap-confine bug about namespaces
[09:07] <mup> PR snapd#3033 closed: cmd/libsnap: make mountinfo structures public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3033>
[10:43] <mup> PR snapd#3031 closed: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3031>
[11:23] <mup> PR snapd#2990 closed: cmd: link libcap dynamically <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2990>
[11:42] <Son_Goku> zyga: I'd really like to have gnome-software have snappy support in Fedora for F26
[11:43] <Son_Goku> so we need to get snapd going into the archive, since someone rewrote the snappy plugin to require snapd-glib
[11:43] <Son_Goku> and snapd-glib won't install without snapd
[11:44] <zyga> Son_Goku: will you review a hand-made spec for the two deps?
[11:44] <Son_Goku> I can
[11:44] <Son_Goku> did you also file a bug about gofed's problems with gopkg.in?
[11:45] <zyga> no, I should really do that
[11:45] <zyga> may be easier than patching
[11:45] <Son_Goku> well... yes
[11:45] <zyga> actually
[11:45] <zyga> https://github.com/gofed/gofed/issues/75
[11:45] <zyga> it's there for two years
[11:45] <zyga> so...
[11:46] <Son_Goku> now bug them to say they broke things without it :)
[11:52] <zyga> Son_Goku: them == upstrem gofed?
[11:52] <Son_Goku> yes
[11:52] <Son_Goku> if it helps, you can file a bug in rhbz against gofed about it :)
[11:52] <Son_Goku> they might pay attention there
[11:55] <mup> Bug #1673435 opened: /lib/systemd/system-sleep/ is read-only <Snappy:New> <https://launchpad.net/bugs/1673435>
[11:56] <Son_Goku> zyga: http://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=gofed&version=25
[12:19] <mup> PR snapd#3039 opened: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
[13:06] <mup> PR snapd#3040 opened: cmd: enable large file support <Created by drizzt> <https://github.com/snapcore/snapd/pull/3040>
[14:11] <mup> Bug #1673465 opened: Cannot set a timezone on dragonboard core system <Snappy:New> <https://launchpad.net/bugs/1673465>
[14:23] <mup> Bug #1672472 changed: Date and time reports the wrong timezone <snapweb:Fix Released by justinmcp> <https://launchpad.net/bugs/1672472>
[14:26] <mup> Bug #1673465 changed: Cannot set a timezone on dragonboard core system <Snappy:New> <https://launchpad.net/bugs/1673465>
[14:28] <tyhicks> zyga: thanks for checking into that - I'm fine with leaving the rule in
[14:28] <mup> PR snapcraft#1196 opened: store: enable delta uploads by default when pushing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1196>
[14:30] <zyga> tyhicks: OK, thanks for confirming
[14:39] <cachio> tyhicks, any chance to see the dbus tests?
[14:40] <cachio> tyhicks, currently I have the spammer and the handler in the same snap, could it affect the resutls? should I split in different snpas?
[14:48] <Cynerva> How do I add auto aliases to a snap?
[14:48] <Cynerva> i.e. remove the need to `snap alias my-snap my-alias`
[14:49] <tyhicks> cachio: no, sorry but I'm still trying to climb out from under work that cropped up last week
[14:49] <Cynerva> I've seen references to this but I'm having trouble figuring out what enables that
[14:49] <tyhicks> cachio: I don't think it'll affect the performance since both ends will still be confined
[14:50] <cachio> tyhicks, yes
[14:51] <tyhicks> cachio: I think I mentioned it last week but when we originally benchmarked the dbus mediation performance, the typical case was a confined client and an unconfined service which resulted in a max of ~10% overhead when generating a lot of traffic
[14:51] <cachio> tyhicks, yes
[14:52] <mup> PR snapd#3041 opened: cmd/snap: handle missing snap-confine <Created by chipaca> <https://github.com/snapcore/snapd/pull/3041>
[14:53] <cachio> last execution I got 32% of overhead
[14:54] <cachio> but most of the them are around the 40%
[14:55] <cachio> tyhicks, the metrics are at the end of this graphic https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-zesty-dashboard
[14:55] <cachio> tyhicks, User: perf pass: ubuntuPERF
[14:57] <tyhicks> cachio: is it safe to publicize those credentials?
[14:58] <qengho> Hah.
[15:00] <tyhicks> cachio: I thought you reported a 15% overhead last week?
[15:00] <tyhicks> (with some blips up to around 40%)
[15:01] <cachio> tyhicks, no
[15:02] <cachio> tyhicks, all the overheads that I saw but client and service confined are more than 30%
[15:03] <cachio> tyhicks, in the graphics you can see the messages by second fof the execution in confinment and without confinment
[15:03] <cachio> those results are for zesty and the execution is in real hardware
[15:04] <cachio> tyhicks, the tests for those graphics are sending 20K messages with a paylod of 256 bytes
[15:04] <mup> PR snapd#3042 opened: cmd: discard the C implementation of snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3042>
[15:04] <tyhicks> cachio: you just publicized the credentials (this is a public channel)
[15:08] <cachio> tyhicks, firgit ut
[15:08] <cachio> fforgot it
[15:08] <cachio> tyhicks, but it is a read only user
[15:08] <cachio> and the dashboar is public
[15:10] <Rumple> Anyone have any idea how long 'manual review' takes when publishing to the snap store?
[15:10] <oky> Rumple: one hour
[15:11] <Rumple> oky: I have had a snap with 'Manual review pending' for over a week
[15:11] <cachio> tyhicks, I'll change the password just in case
[15:11] <oky> Rumple: ok, i'm sorry! i don't know - good idea to come here and get help
[15:12] <Rumple> oky: thanks for the guess at least
[15:14] <cachio_lunch> tyhicks, change done
[15:15] <cachio_lunch> tyhicks, ping me if could take a look to those results please
[15:16] <morphis> alecu: you talked with koza about your bluez problems on your pi3?
[15:18] <tyhicks> cachio_lunch: I've looked at the results but what I haven't yet had time for is to reproduce the results locally and begin poking at test and the dbus-daemon code
[15:24] <alecu> morphis: no... was expecting some pong here.
[15:24] <alecu> morphis: should I report a bug somewhere?
[15:24] <morphis> alecu: ok, koza ^^ alecu has problems getting the bluez snap to work on a pi3
[15:25] <morphis> alecu: let koza reply here first, then we can if we need a bug
[15:28] <koza> alecu, hey
[15:28] <alecu> hi koza!
[15:28] <koza> alecu, what is going on?
[15:29] <koza> alecy, just fyi we have sprint planning so I will be slow on re for a while but feel free to describe the problem
[15:29] <koza> alecu, ^^
[15:29] <alecu> koza: I'm using ubuntu core on a raspi3, and would like to use a bluetooth keyboard with it
[15:29] <trapchat> IS THIS THE NEW PPA?
[15:30] <alecu> koza: so, I've installed the bluez snap, and I'm trying to follow the steps here: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
[15:31] <alecu> koza: but, bluetoothctl never prints the line that would read something like: "[NEW] Controller 1C:C3:E4:79:43:4C localhost.localdomain [default]"
[15:32] <alecu> koza: so, I guess there must be a missing driver, or something like that?
[15:36] <koza> alecu, what if you type: power on just after the bluetoothctl is started
[15:36] <alecu> koza: I can't type a thing there :-/
[15:36] <alecu> koza: can't see anything I type
[15:36] <alecu> I'll give it a try anyway
[15:36] <koza> alecu, how come? how do you start bluetoothctl then?
[15:38] <alecu> koza: (sorry, on a meeting too)
[15:52] <cachio> tyhicks, ok
[15:58] <mup> PR snapd#2624 closed: cmd/snap-confine: re-associate with pid-1 mount namespace if required <Critical> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2624>
[16:08] <koza> alecu, I do not see bt controler on my pi either. I have all the time used a usb dongle plugged in to the pi. with that keyboards do work. i will try to figure out why the bt is not there
[16:10] <alecu> koza: ah, good to know
[16:11] <alecu> koza: perhaps it's a missing kernel compile option in the pi3. We should also ask ogra_
[16:24] <koza> ogra_, ^^^^
[16:50] <om26er> Hi! What could cause: - Fetch and check assertions for snap "core" (35) (internal error: circular assertions are not expected: account (canonical)) ?
[16:51] <om26er> Note: my snapd is pointing to staging.
[16:59] <pedronis> om26er: wrong snapd or wrong setup
[17:02] <didrocks> pedronis: hey, speaking of which, is there any way to tell snapd to forget about one snap assertion? (removing a snap doesn't remove the assertions)
[17:02] <pedronis> didrocks: no, they are facts, they don't become wrong (we might gc them at some point)
[17:02] <om26er> pedronis: I have snapd 2.22.5 with testkeys, while 2.22.6 is available. Could that be the reason or did I screw something in my build ?
[17:03] <didrocks> pedronis: yeah, I'm trying to illustrate the assertions in a tutorial, but if people already installed the snap in the store, I can't have them to then download the snap and try to install it without acking the assertion first
[17:04] <didrocks> pedronis: I would have thought that removing the snap would GC the corresponding assertions for that rev
[17:04] <pedronis> as I said we might to do at some point, but it would be an optimisation
[17:05] <didrocks> yeah, sounds unwanted to keep piling up cruft
[17:05] <pedronis> om26er: what does  snap known account-key authority-id=canonical reports,  mostly interested what is in name: of those keys
[17:06] <pedronis> didrocks: thank you
[17:06] <didrocks> pedronis: want a bug for this?
[17:06] <om26er> pedronis: returns nothing
[17:06] <pedronis> om26er: you sure, that's weird in different ways
[17:06] <pedronis> didrocks: if you want, unlikely to get high priority for a while
[17:07] <om26er> pedronis: yep.
[17:07] <didrocks> pedronis: yeah, still good to log it, will do, thanks!
[17:08] <pedronis> om26er: a couple come from inside snapd itself, that's why I'm perplexed
[17:08] <pedronis> om26er: "snap known account-key authority-id=canonical" is what I'm typing here
[17:08] <mup> PR snapd#3043 opened: interfaces: use spec in the dbus backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/3043>
[17:09] <om26er> pedronis: right, that's the command, I ran. OTH, here is mostly how I built snapd in my ppa: http://paste.ubuntu.com/24046002/
[17:11] <pedronis> om26er: not sure, I'm quite confused tbh
[17:11] <pedronis> there should be at least one key listed by that command
[17:11] <pedronis> even for a snap/snapd that have done nothing
[17:21] <mup> Bug #1673539 opened: snapd doesn't clean up imported (snap) assertions <Snappy:New> <https://launchpad.net/bugs/1673539>
[18:03] <mup> PR snapd#3041 closed: cmd/snap: handle missing snap-confine <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3041>
[19:06] <om26er> pedronis: figured that out, it was a mistake on my end, I had broken debian/rules file
[19:06] <pedronis> om26er: ah, ok
[19:07] <om26er> pedronis: I have another issue though.
[19:07] <om26er> pedronis: - Download snap "core" (35) from channel "stable" (read tcp 10.162.50.23:47680->69.88.149.140:443: read: connection reset by peer)
[19:07] <om26er> pedronis: this happens when I try to install a snap in my digitalocean droplet.
[19:07] <om26er> the issue does not happen on my local machine.
[19:07] <pedronis> seems some networking issue
[19:08] <om26er> pedronis: fwiw snap download works fine
[19:08] <pedronis> even stranger, but not sure what is happening
[19:08] <om26er> :/
[19:09] <pedronis> they use the same code more or less
[19:09] <om26er> actually snap download also has the same issue. (sometimes it works other don't)
[19:09] <om26er> atleast I am not alone, bug 1617765
[19:09] <mup> Bug #1617765: Connections reset when downloading snaps from CDN <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
[19:28] <mup> PR snapd#3044 opened: snapstate: more helpers to work with alias states (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3044>
[20:05] <datajerk> anybody else hear having problems with autoupdate (16.04) removing snapd?  happened to all of my cloud-based servers last night. thanks.
[20:06] <qengho> datajerk: Eh? What does your /var/log/apt/ log say?
[20:06] <datajerk> from my logs: Remove: snapd:amd64 (2.22.6)
[20:06] <datajerk> Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -q -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confold
[20:07] <qengho> datajerk: And "apt install snapd" didn't warn of conflict with something you have installed?
[20:08] <datajerk> nope, no conflict warning
[20:08] <qengho> Weeeeeird.
[20:09] <qengho> datajerk: Pastebin "apt policy snapd" ?
[20:11] <datajerk> http://pastebin.com/v1NGbfAh
[20:12] <qengho> datajerk: Paste the entire log stanza, too, from /var/log/apt/history.log ?
[20:14] <datajerk> http://termbin.com/fr3z
[20:18] <qengho> zyga: ^back 10 min.
[20:21] <zyga> gouchi: hmm?
[20:21] <zyga> not sure if related but snapd hit a bug in dpkg
[20:22] <zyga> dpkg was fixed and tomorrow we will issue an update that pre-depends on the updated dpkg
[20:22] <gouchi> zyga: ??
[20:22] <zyga> qengho: hmm
[20:22] <zyga> gouchi: sorry, I'm tired and misread notification
[20:22] <gouchi> zyga: np
[20:26] <zyga> datajerk: thank you, we are looking into this
[20:52] <datajerk> zyga qengho thanks
[21:31] <barry> does snap and/or snapcraft not support the snapcraft.yaml `environment` section in xenial and yakkety?
[22:35] <mup> PR snapcraft#1197 opened: tests: increase the timeout in the shared ros test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1197>