=== chihchun_afk is now known as chihchun [07:44] tyhicks: hey, so I had to revert the "capability sys_ptrace" removal === zyga_ is now known as zyga [07:44] tyhicks: if you could have a look at the rationale I posted in Signed-off-by: Zygmunt Krynicki [07:45] 7373ee8938cebb82c88f5925d448b290d18a7122 [07:45] tyhicks: it seems to fail if you're not root when starting snap-confine [08:24] zyga: did a new snapd with that fix land in candidate? [08:30] tyhicks: https://github.com/snapcore/snapd/pull/2624/commits/7373ee8938cebb82c88f5925d448b290d18a7122 [08:30] PR snapd#2624: cmd/snap-confine: re-associate with pid-1 mount namespace if required [08:31] tyhicks: we didn't release last night; we plan to relase early today [08:31] er [08:31] cwayne: ^ [08:33] cwayne: candidate will be made after mvo investigates a packaging error we ran into [08:35] cwayne: what fix in particular? [08:37] mvo: snap-confine bug about namespaces [09:07] PR snapd#3033 closed: cmd/libsnap: make mountinfo structures public === gavinlin is now known as Guest72522 === pachulo_ is now known as pachulo === JanC is now known as Guest95676 === JanC_ is now known as JanC === Sir_Gallantmon is now known as Son_Goku [10:43] PR snapd#3031 closed: cmd/snap-confine-suid-trampoline: add new helper [11:23] PR snapd#2990 closed: cmd: link libcap dynamically === chihchun is now known as chihchun_afk [11:42] zyga: I'd really like to have gnome-software have snappy support in Fedora for F26 [11:43] so we need to get snapd going into the archive, since someone rewrote the snappy plugin to require snapd-glib [11:43] and snapd-glib won't install without snapd [11:44] Son_Goku: will you review a hand-made spec for the two deps? [11:44] I can [11:44] did you also file a bug about gofed's problems with gopkg.in? [11:45] no, I should really do that [11:45] may be easier than patching [11:45] well... yes [11:45] actually [11:45] https://github.com/gofed/gofed/issues/75 [11:45] it's there for two years [11:45] so... [11:46] now bug them to say they broke things without it :) [11:52] Son_Goku: them == upstrem gofed? [11:52] yes [11:52] if it helps, you can file a bug in rhbz against gofed about it :) [11:52] they might pay attention there [11:55] Bug #1673435 opened: /lib/systemd/system-sleep/ is read-only [11:56] zyga: http://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=gofed&version=25 [12:19] PR snapd#3039 opened: many: add support for partially static builds === souther_ is now known as souther [13:06] PR snapd#3040 opened: cmd: enable large file support === ysionnea1 is now known as ysionneau === petevg_afk is now known as petevg [14:11] Bug #1673465 opened: Cannot set a timezone on dragonboard core system [14:23] Bug #1672472 changed: Date and time reports the wrong timezone [14:26] Bug #1673465 changed: Cannot set a timezone on dragonboard core system [14:28] zyga: thanks for checking into that - I'm fine with leaving the rule in [14:28] PR snapcraft#1196 opened: store: enable delta uploads by default when pushing [14:30] tyhicks: OK, thanks for confirming [14:39] tyhicks, any chance to see the dbus tests? [14:40] 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] How do I add auto aliases to a snap? [14:48] i.e. remove the need to `snap alias my-snap my-alias` [14:49] cachio: no, sorry but I'm still trying to climb out from under work that cropped up last week [14:49] I've seen references to this but I'm having trouble figuring out what enables that [14:49] cachio: I don't think it'll affect the performance since both ends will still be confined [14:50] tyhicks, yes [14:51] 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] tyhicks, yes [14:52] PR snapd#3041 opened: cmd/snap: handle missing snap-confine [14:53] last execution I got 32% of overhead [14:54] but most of the them are around the 40% [14:55] tyhicks, the metrics are at the end of this graphic https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-zesty-dashboard [14:55] tyhicks, User: perf pass: ubuntuPERF [14:57] cachio: is it safe to publicize those credentials? [14:58] Hah. [15:00] cachio: I thought you reported a 15% overhead last week? [15:00] (with some blips up to around 40%) [15:01] tyhicks, no [15:02] tyhicks, all the overheads that I saw but client and service confined are more than 30% [15:03] tyhicks, in the graphics you can see the messages by second fof the execution in confinment and without confinment [15:03] those results are for zesty and the execution is in real hardware [15:04] tyhicks, the tests for those graphics are sending 20K messages with a paylod of 256 bytes [15:04] PR snapd#3042 opened: cmd: discard the C implementation of snap-update-ns [15:04] cachio: you just publicized the credentials (this is a public channel) [15:08] tyhicks, firgit ut [15:08] fforgot it [15:08] tyhicks, but it is a read only user [15:08] and the dashboar is public [15:10] Anyone have any idea how long 'manual review' takes when publishing to the snap store? [15:10] Rumple: one hour [15:11] oky: I have had a snap with 'Manual review pending' for over a week [15:11] tyhicks, I'll change the password just in case [15:11] Rumple: ok, i'm sorry! i don't know - good idea to come here and get help [15:12] oky: thanks for the guess at least === cachio is now known as cachio_lunch [15:14] tyhicks, change done [15:15] tyhicks, ping me if could take a look to those results please [15:16] alecu: you talked with koza about your bluez problems on your pi3? [15:18] 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] morphis: no... was expecting some pong here. [15:24] morphis: should I report a bug somewhere? [15:24] alecu: ok, koza ^^ alecu has problems getting the bluez snap to work on a pi3 [15:25] alecu: let koza reply here first, then we can if we need a bug [15:28] alecu, hey [15:28] hi koza! [15:28] alecu, what is going on? [15:29] 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] alecu, ^^ [15:29] koza: I'm using ubuntu core on a raspi3, and would like to use a bluetooth keyboard with it [15:29] IS THIS THE NEW PPA? [15:30] 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] 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] koza: so, I guess there must be a missing driver, or something like that? [15:36] alecu, what if you type: power on just after the bluetoothctl is started [15:36] koza: I can't type a thing there :-/ [15:36] koza: can't see anything I type [15:36] I'll give it a try anyway [15:36] alecu, how come? how do you start bluetoothctl then? [15:38] koza: (sorry, on a meeting too) === cachio_lunch is now known as cachio [15:52] tyhicks, ok [15:58] PR snapd#2624 closed: cmd/snap-confine: re-associate with pid-1 mount namespace if required [16:08] 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] koza: ah, good to know [16:11] koza: perhaps it's a missing kernel compile option in the pi3. We should also ask ogra_ [16:24] ogra_, ^^^^ [16:50] Hi! What could cause: - Fetch and check assertions for snap "core" (35) (internal error: circular assertions are not expected: account (canonical)) ? [16:51] Note: my snapd is pointing to staging. [16:59] om26er: wrong snapd or wrong setup [17:02] 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] didrocks: no, they are facts, they don't become wrong (we might gc them at some point) [17:02] 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] 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] pedronis: I would have thought that removing the snap would GC the corresponding assertions for that rev [17:04] as I said we might to do at some point, but it would be an optimisation [17:05] yeah, sounds unwanted to keep piling up cruft [17:05] om26er: what does snap known account-key authority-id=canonical reports, mostly interested what is in name: of those keys [17:06] didrocks: thank you [17:06] pedronis: want a bug for this? [17:06] pedronis: returns nothing [17:06] om26er: you sure, that's weird in different ways [17:06] didrocks: if you want, unlikely to get high priority for a while [17:07] pedronis: yep. [17:07] pedronis: yeah, still good to log it, will do, thanks! [17:08] om26er: a couple come from inside snapd itself, that's why I'm perplexed [17:08] om26er: "snap known account-key authority-id=canonical" is what I'm typing here [17:08] PR snapd#3043 opened: interfaces: use spec in the dbus backend [17:09] 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] om26er: not sure, I'm quite confused tbh [17:11] there should be at least one key listed by that command [17:11] even for a snap/snapd that have done nothing [17:21] Bug #1673539 opened: snapd doesn't clean up imported (snap) assertions [18:03] PR snapd#3041 closed: cmd/snap: handle missing snap-confine [19:06] pedronis: figured that out, it was a mistake on my end, I had broken debian/rules file [19:06] om26er: ah, ok [19:07] pedronis: I have another issue though. [19:07] 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] pedronis: this happens when I try to install a snap in my digitalocean droplet. [19:07] the issue does not happen on my local machine. [19:07] seems some networking issue [19:08] pedronis: fwiw snap download works fine [19:08] even stranger, but not sure what is happening [19:08] :/ [19:09] they use the same code more or less [19:09] actually snap download also has the same issue. (sometimes it works other don't) [19:09] atleast I am not alone, bug 1617765 [19:09] Bug #1617765: Connections reset when downloading snaps from CDN [19:28] PR snapd#3044 opened: snapstate: more helpers to work with alias states (aliases v2) [20:05] anybody else hear having problems with autoupdate (16.04) removing snapd? happened to all of my cloud-based servers last night. thanks. [20:06] datajerk: Eh? What does your /var/log/apt/ log say? [20:06] from my logs: Remove: snapd:amd64 (2.22.6) [20:06] 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] datajerk: And "apt install snapd" didn't warn of conflict with something you have installed? [20:08] nope, no conflict warning [20:08] Weeeeeird. [20:09] datajerk: Pastebin "apt policy snapd" ? [20:11] http://pastebin.com/v1NGbfAh [20:12] datajerk: Paste the entire log stanza, too, from /var/log/apt/history.log ? [20:14] http://termbin.com/fr3z [20:18] zyga: ^back 10 min. [20:21] gouchi: hmm? [20:21] not sure if related but snapd hit a bug in dpkg [20:22] dpkg was fixed and tomorrow we will issue an update that pre-depends on the updated dpkg [20:22] zyga: ?? [20:22] qengho: hmm [20:22] gouchi: sorry, I'm tired and misread notification [20:22] zyga: np [20:26] datajerk: thank you, we are looking into this [20:52] zyga qengho thanks [21:31] does snap and/or snapcraft not support the snapcraft.yaml `environment` section in xenial and yakkety? [22:35] PR snapcraft#1197 opened: tests: increase the timeout in the shared ros test