[00:24] <mwhudson> maybe the Status update for version mails from the store should mention architecture?
[05:00] <morphis_> robert_ancell_: ping
[05:00] <robert_ancell_> morphis_, hi
[05:00] <morphis_> robert_ancell_: we're currently porting snapd-glib to Fedora and enabling support for it in gnome-software there too
[05:01] <robert_ancell_> morphis_, awesome, thanks!
[05:01] <morphis_> robert_ancell_: however we saw something very interesting: http://imgur.com/a/CowmR
[05:02] <morphis_> the default locale of the user is en_GB but he gets turkish messages; I figured out later yesterday that this is because policykit in Fedora doesn't have gettext support
[05:02] <robert_ancell_> oh
[05:02] <morphis_> robert_ancell_: and found an old upstream bug you filed years ago https://bugs.freedesktop.org/show_bug.cgi?id=29639
[05:02] <morphis_> so policykit always falls back to the last <message ..> entry in the .plolicy file
[05:03] <robert_ancell_> morphis_, ah, I probably forgot about that and should generate the PolicyKit file with the translations as per the spec
[05:03] <robert_ancell_> morphis_, I can fix that up tomorrow and make a 1.10 release
[05:03] <morphis_> robert_ancell_: awesome!
[05:03] <robert_ancell_> morphis_, thanks for finding the problem!
[05:04] <morphis_> robert_ancell_: so upstream polkit has gettext support but in a different way?
[05:04] <robert_ancell_> morphis_, I think it never got accepted upstream and I didn't notice because I'm testing on Ubuntu
[05:04] <morphis_> robert_ancell_: np, Son_Goku and a gnome-software developer found it :-)
[05:04] <morphis_> robert_ancell_: yeah.. :-)
[05:05] <morphis_> robert_ancell_: as I am mainly focussing on cross-distro these days I am seeing  a lot of these things
[05:09] <morphis_> robert_ancell_: btw. would it make sense to move snapd-glib over to github.com/snapcore?
[05:09] <robert_ancell_> morphis_, possibly. I ended up putting on LP just to get going quickly.
[05:10] <robert_ancell_> morphis_, do you know who I'd have to ask to migrate there?
[05:10] <morphis_> robert_ancell_: I think zyga or niemeyer can do that
[05:11] <morphis_> robert_ancell_: if you don't overlap with them today I can talk with them or maybe better you create a forum topic on forum.snapcraft.io
[05:11] <robert_ancell_> morphis_, I'm past EOD, so I have to head off now. If you could raise it with them today that would be helpful.
[05:12] <robert_ancell_> bye
[05:57] <zyga> good morning
[05:58] <zyga> mvo: hey, could you please review https://github.com/snapcore/snapd/pull/3131
[05:58] <mup> PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscall… <Created by zyga> <https://github.com/snapcore/snapd/pull/3131>
[05:58] <zyga> mvo: and perhaps https://github.com/snapcore/snapd/pull/3129 (just a struct)
[05:58] <mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
[05:58] <mvo> zyga: sure
[05:59] <mup> PR snapd#3039 closed: many: add support for partially static builds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3039>
[05:59] <zyga> thanks :)
[05:59] <zyga> mvo: ^^ I just landed partially static builds, let me know if something starts to misbehave
[06:00] <mvo> ok
[06:01] <mup> PR snapd#3125 closed: tests: download and install additional dependencies when using prepackaged snapd <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3125>
[06:06] <zyga> oho, a bug in regression test
[06:06] <zyga> /bin/bash: line 56: [: missing `]'
[06:08] <mup> PR snapd#3134 opened: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
[06:08] <zyga> mvo: https://github.com/snapcore/snapd/pull/3134 this will fix some autopkgtest failures
[06:08] <mup> PR snapd#3134: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
[06:09] <mup> PR snapd#3106 closed: tests: enable docker test for more ubuntu-core systems <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3106>
[06:14] <zyga> morphis_: hey, I wanted to get this on your radar https://bugzilla.novell.com/show_bug.cgi?id=1028568
[06:14] <zyga> morphis_: I'll open a forum topic to discuss this
[06:15] <mvo> zyga: thanks, I'm going over all the one ones now
[06:17] <mvo> zyga: keen to see the tests, autopkgtest should be fixed
[06:17] <zyga> mvo: I'll merge master into https://github.com/snapcore/snapd/pull/3085 once the fix above lands and everything (maybe) goes green
[06:17] <mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
[06:21] <mup> PR snapd#3112 closed: interfaces: add a joystick interface <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3112>
[06:21] <mvo> ha! #3115 has all tests green again, so nice to see that autopkgtest is now fixed again
[06:22] <morphis_> zyga: hey! yeah I saw already that lxd is broken both on Fedora and openSUSE, but good that we have a dedicated bug for that
[06:32] <zyga> morphis_: I did a quick branch to fix that but we need coordination from ogra and the core snap
[06:32] <morphis_> mvo: if you have a min, another review on https://github.com/snapcore/snapd/pull/3096 and a merge later today would be great!
[06:32] <mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
[06:32] <zyga> morphis_: my plan was to essentially stop sharing /etc
[06:33] <morphis_> zyga: is that easily possible?
[06:33] <zyga> except for hostname and resolv.conf
[06:33] <zyga> morphis_: yes
[06:33] <zyga> aww, brb
[06:33] <morphis_> we may have a few more dependencies on it don't we?
[06:33] <morphis_> like /etc/netplan
[06:34] <morphis_> zyga: and grep'ing through interfaces/builtin shows a lot more
[06:34] <morphis_> at least 12 which have rw permissions
[06:34] <morphis_> zyga: https://paste.ubuntu.com/24311669/
[06:36] <mvo> morphis_: sure, happy to
[06:37] <morphis_> mvo: thanks
[06:37] <mvo> morphis_: looks great! thanks for your patience
[06:37] <morphis_> mvo: np
[06:38] <zyga> morphis_: re :)
[06:38] <zyga> morphis_: so that will all work, but we need to tweak one symlink
[06:38] <morphis_> zyga: you saw the list I've pasted above?
[06:38] <zyga> morphis_: as if we stop sharing all of /etc one of the writable things has to be adjusted
[06:39] <zyga> morphis_: no
[06:39] <morphis_> https://paste.ubuntu.com/24311669/
[06:39] <zyga> morphis_: sorry, I had to do IRL stuff
[06:39] <morphis_> IRL?
[06:39] <zyga> morphis_: in-real-life
[06:40] <morphis_> ah :-)
[06:40] <zyga> morphis_: not sure what I'm looking at
[06:40] <morphis_> zyga: that is a grep through interfaces/builtin for things which refer to /etc
[06:40] <morphis_> there are quite a few writable things in /etc
[06:40] <morphis_> if we stop sharing those with the host things will break
[06:40] <zyga> morphis_: and they work with /writable and symlinks and such AFAIR
[06:40] <morphis_> zyga: what is with classic?
[06:41] <zyga> morphis_: the whole point is that it already works in core/all-snap
[06:41] <morphis_> zyga: ok, then I may don't get yet what you're planing to do
[06:43] <morphis_> we have symlinks in /etc in the core snap, I get that, but wont those break too if we have the same core snap on multiple distributions as they would point to /writable which doesn't exist there
[06:44] <morphis_> so if we stop sharing /etc with the host it looks to my like we have to repeat all the writable-paths handling the initramfs on Ubuntu Core currently does for classic
[06:44] <mvo> morphis_: 3084 has some more suggestions, but I must say I think its looking super nice, the extra bit in there will just make it even more nice :) great work there!
[06:44]  * mvo hugs zyga for the review too
[06:46] <morphis_> mvo, zyga: will change that in a bit
[06:46] <mvo> zyga: 3096 needs a second review, if you have a moment, should be trivial then it can land
[06:46]  * zyga will review/read stuff in a sec
[06:46] <zyga> just sending kids to school
[06:52] <mvo> zyga: thank, no real rush
[06:54] <zyga> ok :)
[06:54] <zyga> all gone now
[06:54] <zyga> morphis_: of coruse writable would exist
[06:54] <zyga> morphis_: it is in the core snap after all
[06:54] <zyga> morphis_: and we look at the world _after_ the pivot_root is done
[06:55] <zyga> morphis_: so it is just a matter of putting the right host data files to /writable
[06:55] <zyga> morphis_: and setting everything up so that after pivot_root it's all resolving correctly
[06:55] <zyga> morphis_: writable would have to be a tmpfs
[06:55] <zyga> morphis_: and would need to be managed by either snapd or by snap-confine
[06:56] <zyga> mvo: I was already looking at 3096 :-)
[06:57] <mup> PR snapd#3122 closed: packaging: do not compile spread for autopkgtests <Created by fgimenez> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3122>
[07:00] <morphis_> zyga: right, and we need to bind mount things there from the real /etc
[07:00] <morphis_> otherwise snaps wont be able to change timezone/locale/...
[07:03] <mup> PR snapd#3131 closed: interfaces/mount: add OptsToFlags for converting arguments to syscall… <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3131>
[07:05] <zyga> morphis_: interesting
[07:05] <zyga> morphis_: yes, perhaps
[07:06] <zyga> mvo: looks like adt will be green now :) https://github.com/snapcore/snapd/pull/3134
[07:06] <mup> PR snapd#3134: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
[07:07] <mvo> zyga: yeah, I like the level of greeness
[07:08] <zyga> once this passes I'll merge it and start merging it into pending brnaches
[07:08] <zyga> mvo: I'll start with those for 2.24
[07:08] <zyga> oh, no more 2.24 :)
[07:17] <zyga> just one test yellow :)
[07:17] <morphis_> zyga: but lets explore this a bit more, worth a forum topic :-)
[07:20] <zyga> morphis_: what?
[07:20] <zyga> all green, merging!
[07:21] <morphis_> zyga: the unshared /etc on classic
[07:21] <zyga> morphis_: aha, yes, definitely
[07:21] <mup> PR snapd#3134 closed: tests: fix incorrect shell expression <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3134>
[07:21] <zyga> eveyone, let's not land failing tests now
[07:21] <zyga> everything should be green
[07:23] <mup> PR snapd#3132 closed: overlord/state: make sure that setting to nil a state key is equivalent to deleting it <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3132>
[07:33] <zyga> pstolowski: hey
[07:33] <pstolowski> zyga, o/
[07:34] <zyga> pstolowski: I just resolved conflicts on https://github.com/snapcore/snapd/pull/3119 and I worry that it is too easy to add a wrong version of AddConnected{Plug,Slot}
[07:34] <mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
[07:34] <zyga> pstolowski: I'd like to do a sanity test that looks at each interface and makes sure it doesn't implement the old APIs
[07:34] <zyga> pstolowski: no snippets, no attr-less connected plugs or slots
[07:35] <zyga> pstolowski: with the definer hack we essentially turned to duck typing on a security component
[07:35] <zyga> pstolowski: and this is a bit risky :/
[07:37] <pstolowski> zyga, thanks for resolving conflicts in that branch;
[07:38] <zyga> fgimenez: conflicts on https://github.com/snapcore/snapd/pull/3105
[07:38] <mup> PR snapd#3105: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105>
[07:39] <fgimenez> zyga: thanks on it
[07:40] <pstolowski> zyga, as for duck typing yes, I realized these risks too. I think from now only every interface needs to have full tests
[07:40] <pstolowski> zyga, good idea about sanity test, a simple shell script will do
[07:41] <zyga> pstolowski: I was thinking about a go based test actually, let me try something
[07:41] <zyga> everyone: I'm going through PRs and merging master into them, this should fix adt failurs
[07:41] <zyga> *failures
[07:42] <zyga> please don't merge things if they are not green anymore
[07:45] <zyga> hmm
[07:45] <zyga> FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune
[07:45] <zyga> this failed on my laptop just now
[07:45] <zyga> was that known racy?
[07:56] <zyga> pstolowski: we need to plan a 2nd pass through all PRs to adjust them to the new interface APIs
[07:56] <zyga> pstolowski: but I'd like to see this new test merged first
[07:56] <zyga> pstolowski: I'll take a break, prepare for some meetings today and then start working on it
[07:57] <zyga> pstolowski: if you could do a trivial review on a struct: https://github.com/snapcore/snapd/pull/3129
[07:57] <mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
[07:57] <zyga> pstolowski: that would help me move update-ns effort forward :)
[08:01] <mup> PR snapd#3135 opened: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135>
[08:04] <mup> PR snapd#3108 closed: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108>
[08:12] <zyga> mvo: I'm done, nearly everyting is either yellow now or has been commented upon to have the author do something
[08:12] <zyga> mvo: probably we'll run out of machines but spread can be restarted
[08:12] <zyga> mvo: and adt will nicely queue
[08:15]  * zyga afk
[08:24] <mup> PR snapd#2971 closed: data: ship "snap.mount" service that ensures /snap is MS_SHARED <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2971>
[08:28] <morphis_> zyga: can you have another look on https://github.com/snapcore/snapd/pull/3084 ?
[08:28] <mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
[08:28] <zyga> morphis_: yes, after my calls
[08:28] <morphis_> thanks!
[08:51] <zyga> fgimenez:     - autopkgtest:ubuntu-16.04-ppc64el:tests/main/classic-custom-device-reg failed on https://github.com/snapcore/snapd/pull/3129
[08:51] <mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
[08:52] <zyga> fgimenez: died on kill timeout there
[08:52] <zyga> mvo: it would be awesome if we had a way to re-try adt tests
[08:53] <zyga> we're starting to see green tests :)
[08:53] <zyga> not all but at least some
[08:53] <zyga> random failures on adt are annoying as they are harder to re-try
[08:54] <mvo> zyga: yeah, I have no idea how to retrigger those, we need help from the adt people on that. but its worth investigating the failures I think
[08:54] <zyga> mvo: if it is just slower infrastructure we should tweak knobs to kill them later
[08:54] <zyga> mvo: if it is real failure we want to investigate
[08:54] <zyga> mvo: so yeah, agreed!
[08:57] <zyga> aha, that looks like a real bug
[08:57] <zyga> [ 1602.570508] audit: type=1400 audit(1491294017.372:1090): apparmor="DENIED" operation="create" profile="snap.classic-gadget.hook.prepare-device" pid=27121 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[08:57] <zyga> snapctl + ipv6
[08:58] <zyga> mvo: did your branch with config that was addressing that landed?
[08:58] <zyga> s/landed/land/
[09:02] <zyga> I added https://github.com/snapcore/snapd/pull/3129/commits/f82c78c07facd73f5ad1a31f26b0b337dc6ce4ce to try to figure out what is failing on ppc64
[09:02] <mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
[09:05] <ogra> zyga, i dont see a PR for the lxd bit
[09:17] <fgimenez> hi mvo: i'm looking into the expect errors on ubuntu-core http://paste.ubuntu.com/24305344/ and, trying manually tests/main/create-key on amd64 with edge core, it gets stuck after the "Confirm password" prompt http://paste.ubuntu.com/24312255/ if you could take a look when you have a moment that would be great
[09:18] <morphis_> zyga: so for gnome-software we have a hardcoded /snap/bin in snapd-glib we need to workaround
[09:18] <morphis_> err, a hardcoded /snap/bin in gnome-software
[09:37] <zyga> morphis_: aha
[09:37] <zyga> morphis_: we can do a small patch or we could maybe have it ask snapd
[09:37] <zyga> morphis_: but I think we can do it easily with a small patch
[09:38] <zyga> ogra: hmm
[09:38] <morphis_> zyga: yeah that is the plan
[09:39] <morphis_> zyga: talked with Robert this morning and he wants to do a minor release of snapd-glib tomorrow anyway so I am asking him now if he can add a small API function returning the snap mount dir
[09:39] <morphis_> we can than set it statically via a configure switch and later ask snapd
[09:43] <niemeyer> Good mornings
[09:45] <mvo> hey niemeyer! good morning
[09:47] <morphis_> niemeyer: morning!
[09:47] <niemeyer> o/
[09:47] <zyga> morphis_: sounds good!
[09:47] <zyga> niemeyer: good morning :)
[09:48] <morphis_> zyga: you already had time to give snapd on Fedora a try or is that something for later this week?
[09:48] <zyga> pstolowski: error: cannot refresh "test-snapd-delta-refresh": cannot get refresh information for snap "test-snapd-delta-refresh": Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: EOF
[09:49] <zyga> morphis_: I'll try that today, I have my 2nd machine standing by
[09:49] <zyga> pstolowski: this failed here: https://github.com/snapcore/snapd/pull/3111
[09:49] <mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
[09:49] <zyga> pstolowski: will that be fixed with https://github.com/snapcore/snapd/pull/3126 ?
[09:49] <mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
[09:50] <morphis_> zyga: sounds great! we need 6 points to get the update done, so need to collect people :-)
[09:52] <zyga> morphis_: I'll boot F25 first
[09:52] <morphis_> ok
[09:53] <zyga> fgimenez: tests/main/interfaces-network-observe failed on timeout (seems like test was stuck)
[09:53] <zyga><EMAIL_ADDRESS>[09:53] <fgimenez> zyga: thanks looking..
[09:55] <zyga> fgimenez: your new dbus interface spread test seems to be geuinely failing https://github.com/snapcore/snapd/pull/3014
[09:55] <mup> PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
[09:57] <Chipaca> had to reboot because my tests leaked out and borked the environ, and spread realised and restarted qemu without me having to meddle
[09:57]  * Chipaca hugs niemeyer
[09:57] <ogra> koza, next customer ... Bug #1679432 ...
[09:57] <mup> Bug #1679432: Bluetooth SCO connections don't work on Dragonboard 410c <Snappy:New> <https://launchpad.net/bugs/1679432>
[09:57] <zyga> Chipaca: good morning :)
[09:57] <zyga> hmm, I really wish we could retry adt tests
[09:58] <zyga> error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.
[09:58]  * niemeyer feels the love and hugs Chipaca back
[09:58] <zyga> random error on git clone
[09:58] <Chipaca> zyga, niemeyer :-)
[09:58] <pstolowski> zyga, yes, i hope so..
[10:00] <fgimenez> zyga: indeed, the test snaps weren't being built for ppc64el, doing that now
[10:01] <fgimenez> zyga: and thanks! :)
[10:01] <zyga> pstolowski: let's merge it then!
[10:02] <zyga> fgimenez: thank you!
[10:02] <zyga> fgimenez: I think we have a chance at all-green tests today
[10:02] <zyga> fgimenez: I'll do my best to help
[10:02] <pstolowski> zyga, i've just pushed the little fix for unneeded var error;
[10:04] <fgimenez> zyga: \o/ thanks a lot, spring is definitely coming to our poor test results :)
[10:06]  * zyga reviews 3126
[10:07] <mup> PR snapcraft#1230 opened: Refactor Cleanbuilder into Containerbuild and add Project <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1230>
[10:11] <Chipaca> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/comments/10 is exciting
[10:11] <mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819>
[10:11] <Chipaca> which reminds me
[10:12] <Chipaca> zyga— do you have a fedora system/vm up?
[10:15] <brunch875> Guys I noticed that telegram puts downloads in /snap/.../Downloads/ instead of ~/Downloads. I know it's for the sake of confinement, but wouldn't it be a better idea to also mount this folder into ~/Downloads?
[10:16] <brunch875> that way, the snap doesn't see other snaps downloads but I can go to ~/Downloads to get my stuff
[10:16] <brunch875>  /snap/Downloads is a long path
[10:18] <zyga> Chipaca: yes
[10:18] <Chipaca> zyga— can you check whether that bug happens in fedora also? (it should, but maybe they patch their kernel for this already)
[10:18] <Chipaca> brunch875— it's tricky
[10:19] <Chipaca> brunch875— ~/Downloads isn't guaranteed; in fact, it's localised
[10:19] <zyga> Chipaca: sure
[10:19] <Chipaca> brunch875— if you're in spanish I think it's ~/Descargas
[10:19] <zyga> Chipaca: we have $XDG_CONFIG_DIR/user-dirs.dirs
[10:19] <brunch875> damn translations... how does firefox deal with this?
[10:20] <Chipaca> zyga— exactly, but people editing that is rarer than people speaking something different
[10:20] <Chipaca> not saying it's impossible; it's tricky
[10:20] <zyga> Chipaca: yeah
[10:20] <zyga> Chipaca: just sligthly trickier than fixed path
[10:20] <zyga> Chipaca: it's tricky if it changes underneath
[10:20] <ogra> Chipaca, i think we stopped localizing it ... your original install must be old
[10:20] <Chipaca> it's three indirections to get the thing
[10:20] <zyga> but that is rare I hope
[10:20] <zyga> yep
[10:21] <Chipaca> is it bad that i made tests pass by removing the failing ones :-D
[10:21] <zyga> Chipaca: I bet there's a bible rerefence that fits this but I don't think we want that ;)
[10:22] <Chipaca> zyga— “And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days.” (here "beast" could be "snapd")
[10:24] <koza> ogra, haha thanks, reading now
[10:24] <zyga> Chipaca: the church of snapd
[10:24] <zyga> Chipaca: apply for tax deductions
[10:25] <Chipaca> in civilization i always name my religion "worms"
[10:25] <Chipaca> because i spread worms to other civilization and that makes me chuckle
[10:25] <Chipaca> but "the church of snapd" could work also
[10:27] <mvo> reviews for https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.24 would be great - so that we can get 2.24 ready
[10:28] <zyga> Chipaca: thu shal not have other packages before me ;-)
[10:28] <zyga> thu shall refresh on weekends ;)
[10:28]  * zyga gets back to being useful
[10:30] <mup> PR snapd#3136 opened: snap-confine: add code o ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136>
[10:32] <niemeyer> mvo: I'm about to jump into it shortly.. just want to get a discourse snap with SSO support building meanwhile
[10:33] <niemeyer> Chipaca: So it was indeed a bug in the kernel..
[10:35] <mvo> niemeyer: thank you!
[10:37] <zyga> Chipaca: fedora booting, sorry, vmware decided it's time for upgrade
[10:39] <zyga> fgimenez: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
[10:40] <zyga> fgimenez: this seems to clober and affect tests on https://github.com/snapcore/snapd/pull/3010
[10:40] <mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
[10:40] <zyga> fgimenez: I wonder why it only happens here. it looks like either we reexec where we previously did not
[10:40] <zyga> fgimenez: or we log where we previously did not
[10:40] <zyga> fgimenez: I have no other ideas
[10:41] <zyga> oddly
[10:41] <zyga> fgimenez: same spread run has this message:
[10:41] <zyga> 2017/04/04 09:49:49.300407 cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.23.6 2.23.6]): older than "/usr/bin/snap" (13<IP_ADDRESS>)
[10:41] <zyga> so it restarted once
[10:41] <zyga> but not another time
[10:41] <zyga> during one run
[10:41] <zyga> mvo: does this make any sense to you?
[10:42] <zyga> it seems that all the failures there are caused by the extra DEBUG message
[10:45] <zyga> mvo: aha, so that branch sets  +    SNAPD_DEBUG: 1
[10:45] <zyga> mvo: I think we need something more flexible
[10:45] <mvo> zyga: indeed - maybe going back to snappy_testing?
[10:46] <zyga> mvo: I commented on the PR
[10:46] <zyga> mvo: snappy_testing? what is that
[10:47] <mvo> zyga: its a flag we set when spread runs, it tells that the system is being tested
[10:47] <mvo> zyga: let me try that
[10:47]  * mvo really lunch now
[11:05] <zyga> Chipaca: ok, updated my f25 to latest kernel and trying the suid bug now
[11:06] <zyga> fgimenez: I have a question about https://github.com/snapcore/snapd/pull/3085/files
[11:06] <mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
[11:07] <zyga> fgimenez: what happened to the prepare_all_snap vs prepare_classic code?
[11:07] <zyga> aha I see you excluded core
[11:08] <zyga> fgimenez: so do we run any tests on core with that PR now?
[11:10] <fgimenez> zyga: of course, the core system filtering is a refactor only for the unit suite, previously the tasks in that suite were excluding the core systems, with this PR the exclusion is done at the suite level
[11:11] <zyga> aha, makes sense
[11:11] <zyga> thanks!
[11:11] <zyga> let's merge it when it goes green
[11:12] <fgimenez> zyga: np thank you
[11:15] <zyga> Chipaca: yep, it also affects fedora
[11:15] <zyga> Chipaca: but curiously the go version is ok
[11:15] <zyga> Chipaca: but the c+pthread version is not
[11:16] <zyga> Chipaca: maybe fedora has different golang build defaults?
[11:36] <mvo> zyga: https://github.com/snapcore/snapd/pull/3096 has some strange commits, did you maybe push the wrong branc there?
[11:36] <mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
[11:39] <Chipaca> zyga— the go version might be ok if you have only one (real) cpu on your vm
[11:40] <zyga> mvo: checking
[11:41] <zyga> oh, I must have
[11:41] <zyga> sorry,
[11:41] <zyga> shall I push --force to remove them?
[11:41] <zyga> ah
[11:41] <zyga> no sorr
[11:41] <mvo> zyga: sounds reasonable
[11:41] <zyga> I did this on purpose!
[11:41] <mvo> zyga: you did?
[11:41] <zyga> earlier run failed on EOF bug
[11:41] <zyga> so I merged the EOF fix branch
[11:42] <mvo> zyga: the eof stuff is random
[11:42] <zyga> as that is coming to land soon in another PR
[11:42] <zyga> mvo: yes but I wanted to give it a try to see if it fails on EOF
[11:42] <mvo> zyga: honestly I think that is not a good idea, its mixing two branch changes and makes the review harder
[11:43] <zyga> mvo: we can back those out or wait for https://github.com/snapcore/snapd/pull/3126 and merge master again
[11:43] <mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
[11:44] <mvo> zyga: yeah, we can deal with this easily, I think we should avoid this in the future, i.e. 3126 was almost in master so a little wait and its all easier to review/land
[11:45] <zyga> mvo: noted, I'll refrain from doing this
[11:45] <mvo> ta
[11:54] <niemeyer> zyga: #3039 again went in with unanswered comments
[11:56] <niemeyer> zyga: Starting to get worried about the fact we're getting used to overrunning comments
[11:57] <zyga> niemeyer: aha? checking,
[11:59] <zyga> niemeyer: are you referring to https://github.com/snapcore/snapd/pull/3039#discussion_r109441348 ?
[11:59] <mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3039>
[11:59] <zyga> niemeyer: I didn't see it, it's another case where github had stale UI :/
[11:59] <niemeyer> zyga: I'm referring to my comment there made before the merge and unanswered
[11:59] <zyga> niemeyer: it seems to refresh sometimes but not always
[12:00] <zyga> niemeyer: right, I'm tring to clarify which comment that was
[12:00] <zyga> niemeyer: I checked for past comments to make sure it was all addressed
[12:01] <niemeyer> zyga: I had one comment with Request Changes.. the Approve came together with the comment
[12:01] <zyga> niemeyer: I think the lesson is to reload a tab before merging
[12:01] <niemeyer> So either you didn't see the approve, in which case Request Changes was still in place, or you saw the Approve
[12:01] <niemeyer> and the comment
[12:01] <zyga> niemeyer: I really didn't see the comment
[12:02] <zyga> niemeyer: I don't know why exactly or how github works there
[12:02] <niemeyer> zyga: In either case, let's please be more careful.. we had two such cases in the last couple of days
[12:02] <niemeyer> zyga: Those were pretty minor, but my concern is obviously that we overrun critical things and nobody notices
[12:18] <Chipaca> ogra— the 1m you're calling copying also involves sha3'ing the files, which omnoms a cpu for about a minute also
[12:18] <ogra> ah
[12:18] <Chipaca> at least afaik :-)
[12:18] <ogra> yeah, i thought it is related to that step at least
[12:18]  * Chipaca nods
[12:18] <ogra> probably not much we can do apart from adding a progress bar :P
[12:19] <ogra> the key gen change is super impressive though ... it takes almost no time
[12:19] <mvo> Chipaca: hey, I was wondering if you had a chance to look at the channel2.0 stuff, looks like channels_map_list is now available from the store and I was wondering if I can start doing some of the groudnwork or if you are already on it
[12:19] <Chipaca> ogra— zyga promised us some assembler work to make it faster :-D
[12:19] <Chipaca> mvo— i am not on it
[12:19] <ogra> heh, good luck with that ...
[12:19] <Chipaca> mvo— i don't want to delay completion further
[12:19]  * ogra waits for the s390x assembler to land
[12:20] <Chipaca> ogra— in any case that'd buy us a ~15% perf bump, not more
[12:20] <mvo> Chipaca: no problem, just wanted to double check to avoid duplicating work
[12:20] <Chipaca> mvo— it should be really straightforward to do though
[12:20] <Chipaca> mvo— good luck :-D
[12:20] <Chipaca> (famous last words)
[12:20] <ogra> Chthats at least 9secs from a 1min run !
[12:21] <ogra> damn, auto-completion fail
[12:21] <niemeyer> pstolowski: #3126 reviewed
[12:22] <ogra> well, in any case we should get  https://github.com/snapcore/snapd/pull/3130 landed asap IMHO
[12:22] <mup> PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
[12:22] <ogra> the difference is massive
[12:24] <pstolowski> niemeyer, ty
[12:29] <mup> PR snapd#3137 opened: overlord: switch to aliases v2 tasks for install/refresh etc ops plus transition <Created by pedronis> <https://github.com/snapcore/snapd/pull/3137>
[12:36] <morphis> Son_Goku: we're moving torwards a working gnome-software, just if you didn't follow the conversation in #g-s
[12:41]  * zyga lunch
[12:44] <mup> PR snapd#3138 opened: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
[12:47] <zyga> niemeyer: some more progress for your attention https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23/13
[12:48] <zyga> niemeyer: I suspect you will be busy with 2.24 tasks today but if you can revise feedback on the oldest PR of that set I could progress significantly
[12:49] <Chipaca> I love how the whole edifice of tab completion falls down if you have something with a newline in it
[12:49] <Chipaca> I'm using edifice here in the same sense you'd use it to describe an 8m column of toothpicks stood on end
[12:50] <zyga> Chipaca: try adding tab completion for a file with a newline in it :)
[12:50] <Chipaca> zyga— this is what i meant
[12:51] <Chipaca> just a space is enough to trip up some of it
[12:51] <Chipaca> a newline just causes giggling
[12:58] <niemeyer> pstolowski: Why the else if on 3126?
[12:59] <niemeyer> zyga: Thanks, I'll check it out soon
[12:59] <niemeyer> zyga: I started yesterday, actually, but this one needs a fresher mind
[12:59] <zyga> niemeyer: understandably so, thank you
[12:59] <pstolowski> niemeyer, because it turns out that after unwrapping the error becomes a net error, so it falls into the check. and goes into return netErr.Timeout() check, which is not what we want
[13:00] <niemeyer> pstolowski: Seems fishy.. let's discuss in the call
[13:09] <niemeyer> tvoss: Heya
[13:09] <tvoss> niemeyer: o/
[13:10] <niemeyer> tvoss: Can you open a thread in the forum with details of the issue about the ssh-keygen vs. internal generation issue?
[13:10] <niemeyer> tvoss: Curious about your findings so far about where the problem lies
[13:10] <tvoss> niemeyer: sure, good part of the findings is on the PR, too
[13:11] <tvoss> niemeyer: https://github.com/snapcore/snapd/pull/3130
[13:11] <mup> PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
[13:12] <niemeyer> tvoss: Thanks
[13:14] <pstolowski> niemeyer, ok, tweaked retry error check as just discussed
[13:14] <tvoss> niemeyer: in summary, the current theory is that check for primality in the key generation is killing performance. Mostly due to the BigInt implementation in Go not being as optimized as the ssh one.
[13:15] <niemeyer> tvoss: Ack, will have a look at the PR
[13:36] <zyga> mvo: reviewed the snap-confine change, have a look
[13:40] <zyga> niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/3085/files -- if it lands we will have more travis slots for testing and we will have faster iteration overall
[13:40] <mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
[13:44] <mvo> zyga: yeah, thank you
[13:44] <niemeyer> zyga: Looking
[13:49] <mup> PR snapd#3085 closed: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3085>
[13:57] <sborovkov> Hello, Is there some builtin executable to test snapd's REST API?
[13:57] <sborovkov> on core.
[13:58] <ogra> sborovkov, snap install http ...
[13:58] <ogra> then you can talk to it using the http tool
[13:59] <sborovkov> Meh. I can't install it easily. I need another image then. because my image uses branded store. oh well.
[14:00] <ogra> sborovkov, well, perhaps Chipaca has a local version of that snap you could install
[14:00] <Chipaca> sborovkov— why can't you install it easily?
[14:00] <pedronis> sborovkov: so it's a branded store not setup to inherit the main one?
[14:01] <sborovkov> pedronis: yes, It only has 2 snaps
[14:02] <sborovkov> Chipaca: store I am using is not inheriting anything from the main one.
[14:03] <Chipaca> nice
[14:03] <Chipaca> sborovkov— if you have a snapd running against the regular store somewhere, you can 'snap download http' and then copy the two resulting files over
[14:04] <sborovkov> Right, I should have classic image lying somewhere around. It's easier to change what store it's using on the fly.
[14:04] <Chipaca> :-)
[14:05] <ogra> yeah ... that silly IoT stuff ... way to secure nowadays
[14:05] <ogra> :)
[14:05] <Chipaca> sborovkov— you also should have a way of copying snaps into your store
[14:05] <Chipaca> i don't know how that side of things work though
[14:06] <sborovkov> Documentation on REST API says that - "The API documents three levels of access: open, authenticated and root" and " The root user also gains authenticated access without having to send authorization." - Does that apply to snaps that run under root?
[14:06] <Chipaca> sborovkov— if you do 'snap download', make sure to copy the .assert as well as the .snap
[14:06] <sborovkov> Chipaca: understood.
[14:07] <Chipaca> sborovkov— no, snaps need the snapd-control to talk to snapd even as root
[14:07] <Chipaca> otherwise they can't even open the socket
[14:08] <sborovkov> ah, alright. So if I connect to that interface I won't need to send authentication header? I want to make requests to core/conf to modify config.txt on RPI
[14:26] <zyga> re
[14:27] <zyga> yay, thank you for merging that niemeyer :-)
[14:27] <niemeyer> zyga: No problem, thanks for bringing it up
[14:27] <niemeyer> fgimenez: Btw, I think we could run the gccgo test on amd64 only
[14:28] <niemeyer> ubuntu-16.04-64 to be precise
[14:29] <zyga> I'm seeing hook error reporting failure in spread
[14:29] <zyga> Apr 04 13:31:57 autopkgtest /usr/lib/snapd/snapd[13737]: hookmgr.go:380: DEBUG: Cannot report hook failure: cannot upload error report, return code: 500
[14:29] <niemeyer> zyga: Btw, I've created custom badges for distinguished community groups, per Ryan's request
[14:29] <zyga> I thouht we didn't send those from tests
[14:29] <zyga> niemeyer: yeah, I saw those
[14:29] <fgimenez> niemeyer: ok, i'll propose a branch for that
[14:29] <zyga> niemeyer: when I had a look at badges I saw some UI in account preferences
[14:29] <niemeyer> zyga: Got morphis and songoku on Fedora.. Ryan on system76.. any other suggestions?
[14:30] <zyga> niemeyer: specifically https://forum.snapcraft.io/users/zyga/preferences/badge_title
[14:30] <zyga> niemeyer: but that's not the same, is it?
[14:30] <morphis> niemeyer: nice one!
[14:30] <zyga> niemeyer: we may want to tag Canonical CE as such
[14:30] <niemeyer> zyga: It's related.. specific badges allow using them as titles
[14:30] <niemeyer> zyga: See how Neil shows up now, for example
[14:30] <zyga> niemeyer: looking
[14:30] <niemeyer> or Ryan
[14:30] <zyga> nice
[14:31] <zyga> I wish we had icons too
[14:31] <zyga> (such a forum thing but I like it :)
[14:31] <niemeyer> Yeah, those badges may have icons associated too
[14:31] <niemeyer> But, one step at a time :)
[14:31] <niemeyer> zyga: Who's responsible for the Debian packaging those days?
[14:32] <niemeyer> and arch, opensuse, etc
[14:32] <zyga> niemeyer: I think that's mwhudson
[14:32] <zyga> niemeyer: opensuse that's me and morphis
[14:32] <zyga> niemeyer: arch that's timothy (not sure if he participates in the forum)
[14:32] <zyga> niemeyer: (we cannot upload to the arch packge ourselves)
[14:32] <niemeyer> zyga: Do you plan to remain directly involved in those efforts?
[14:32] <zyga> niemeyer: yes, I want to say involved, maybe 10%/20%, depending on need
[14:33] <morphis> niemeyer: worth adding Yocto too
[14:33] <niemeyer> zyga: Okay, I'll keep morphis as the main point of contact for now then
[14:33] <zyga> niemeyer: I can help with reviews, some release testing and being a backup so that there are several people involved and aware of what's going on
[14:33] <zyga> niemeyer: sounds good
[14:33] <zyga> niemeyer: yocto yes, morphis updated snapd in yocto AFAIR
[14:34] <morphis> zyga: I maintain it :-)
[14:34] <niemeyer> morphis: Who's handling Yocto, only you for now?
[14:34] <zyga> niemeyer: do you think we should have "snapd developer" badge?
[14:34] <morphis> niemeyer: yes
[14:34] <zyga> niemeyer: can we do many badgets for one person?
[14:34] <niemeyer> zyga: Well, looks at your own badges :)
[14:35] <niemeyer> s/looks/look
[14:35]  * zyga looks
[14:36] <zyga> oh
[14:36] <niemeyer> zyga: Not sure, let's think about that one (developer)
[14:36] <zyga> forum does feel like a massive upgrade over mailing lists
[14:36] <zyga> brick by brick it builds a community
[14:37] <niemeyer> zyga: Feels a bit too generic to be useful.. everyone should feel like they are developers.. PRs for all
[14:37] <zyga> indeed
[14:37] <zyga> we can revisit that once the forum has 100s of users
[14:37] <niemeyer> Yeah
[14:41] <zyga> pedronis: can we merge master into https://github.com/snapcore/snapd/pull/3087
[14:41] <mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
[14:41] <pedronis> zyga: I did
[14:42] <zyga> pedronis: thanks!
[14:42] <pedronis> zyga: did something else got merge to master recently that fixes something?
[14:43] <niemeyer> https://usercontent.irccloud-cdn.com/file/OldF6S1B/
[14:43] <zyga> pedronis: one thing that was breaking many adt runs and one simplification from federico that will make test runs faster
[14:43] <niemeyer> Did I miss anything?
[14:43] <zyga> niemeyer: gentoo, but we don't actively maintain it really
[14:43] <zyga> niemeyer: I would also consider centos
[14:43] <niemeyer> Okay.. let's create it on demand then
[14:43] <zyga> niemeyer: as many people love it
[14:44] <zyga> niemeyer: and it feels distinct from fedora
[14:44] <niemeyer> Hmm.. what's the packaging story there?
[14:44] <zyga> niemeyer: once the fedora package is out we will request a package for centos
[14:44] <zyga> niemeyer: I was wondering if we want to have 'Ubuntu & Derivatives' instead of Ubuntu
[14:44] <niemeyer> zyga: What does that mean?
[14:45] <zyga> niemeyer: (elementary, mint and multitude of [KLX...]buntu)
[14:45] <niemeyer> zyga: I mean, requesting a package for CentOS.. what does that mean in practice?
[14:45] <zyga> niemeyer: it means that you get a permission to target your package to "enterprise" distros
[14:45] <zyga> niemeyer: it's distinct from fedora
[14:45] <zyga> niemeyer: you go through the review process again
[14:45] <zyga> niemeyer: different people decide, etc
[14:45] <niemeyer> Is it the same package, though?
[14:45] <zyga> niemeyer: then you get a branch that you can use for that distribution
[14:46] <zyga> niemeyer: not quite, it's the same package _name_ but it can be different _packaging_
[14:46] <zyga> niemeyer: it typically is somewhat different in the end
[14:46] <zyga> niemeyer: for snapd we will reuse the same package but build it with different switches
[14:46] <zyga> niemeyer: as centos doens't have golang much so what happens is you built it with fedora deps that are bundled / linked statically
[14:46] <zyga> niemeyer: that's what I understand from the process
[14:46] <morphis> niemeyer: it can be the same .spec file but build with different parameters
[14:47] <zyga> niemeyer: yes
[14:47] <zyga> niemeyer: it's actually automatic as our package has those switches onw
[14:47] <zyga> now*
[14:47] <morphis> niemeyer: King_InuYasha build the .spec file in a way that it can work on RedHat, CentOS and Fedora
[14:47] <zyga> niemeyer: we mainly need to apply for the permission and come up with a working srpm for review
[14:47] <niemeyer> Okay, sounds good.. badge created
[14:47] <niemeyer> We're only handing it off when it lands though!  :P
[14:47] <zyga> niemeyer: exactly, this is why the spec files for golang are so convoluted
[14:47] <zyga> niemeyer: sounds good :)
[14:48] <zyga> niemeyer: question: what do you use for those tiny screenshots?
[14:48] <niemeyer> zyga: Which tiny screenshots?
[14:49] <zyga> niemeyer: like the one you linked to above
[14:49] <niemeyer> zyga: Ah, you mean the screen cropped ones?
[14:49] <zyga> yes
[14:49] <niemeyer> zyga: Stock gnome-screenshot with proper keyboard shortcuts
[14:51] <mup> PR snapd#3139 opened: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3139>
[14:53] <zyga> Chipaca: does this test failure ring a bell to you? https://github.com/snapcore/snapd/pull/2982#issuecomment-291524618
[14:53] <mup> PR snapd#2982: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
[14:53] <zyga> Chipaca: it's odd that it failed on some places and passed in others
[14:54] <Chipaca> gocheck's output for diffing maps sucks :-(
[14:54] <Chipaca> but no
[14:54] <zyga> yep
[14:55] <zyga> Chipaca: thanks!
[14:55]  * zyga looks at TestEnsureLoopPrune
[14:55] <mup> PR snapd#2982 closed: daemon: add desktop file location for app to the API <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2982>
[14:59] <mup> PR snapd#3140 opened: overlord: increase prune test wait by x10 <Created by zyga> <https://github.com/snapcore/snapd/pull/3140>
[15:00] <Chipaca> zyga— so, apps is different
[15:00] <Chipaca> zyga— missing desktopfile stuff
[15:01] <Chipaca> ?
[15:01] <Chipaca> ah!
[15:01] <Chipaca> no
[15:01] <Chipaca> zyga— something is wrong in that test or something
[15:01] <Chipaca> there is no order to apps and the test is checking an ordered struct
[15:01] <zyga> Chipaca: aah
[15:02] <zyga> Chipaca: thanks, I'll look at fixing that
[15:02] <zyga> fgimenez: commented on https://github.com/snapcore/snapd/pull/3139#pullrequestreview-30806386
[15:02] <mup> PR snapd#3139: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3139>
[15:03] <Chipaca> zyga— it should probably be a map[string]daemon.appJSON instead of a []daemon.appJSON
[15:07]  * ogra laughs about the forum
[15:08] <mup> PR snapcraft#1211 closed: sources: add git source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1211>
[15:08] <ogra> "You earned an Ubuntu"
[15:08] <mup> PR snapcraft#1213 closed: sources: add bazaar source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1213>
[15:08] <ogra> yay
[15:09] <zyga> ogra: it's yours to keep :)
[15:09]  * ogra hugs his Ubuntu
[15:09] <ogra> my precious!
[15:10] <daker> lol
[15:11] <daker> zyga: can we have other providers for the login ? i don't want to create another account for it
[15:12] <zyga> daker: https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75
[15:13] <daker> zyga: thanks
[15:19] <mup> PR snapd#2982 opened: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
[15:21] <zyga> Chipaca: about map[string]daemon.appJSON, should the key be just the app name?
[15:22] <Chipaca> zyga— yah
[15:22] <zyga> Chipaca: the problem is that this is client-visible protocol, right?
[15:22] <zyga> Chipaca: alternatively I can sort by that
[15:22] <zyga> Chipaca: so that it shows up in good order
[15:23] <Chipaca> yeah
[15:23] <zyga> Chipaca: but I also recall the need to have a "launch" button that may imply order cannot be alphabetic
[15:23] <Chipaca> sorting works
[15:23] <zyga> Chipaca: and needs to be something special :/
[15:23] <Chipaca> the launch is per desktop
[15:23] <Chipaca> ¯\_(ツ)_/¯
[15:23] <zyga> Chipaca: yes but in gnome software you have one buttn
[15:23] <zyga> button
[15:23] <Chipaca> zyga— imagine :shrug:, but where each stroke is a ¯\_(ツ)_/¯
[15:24] <Chipaca> heh
[15:24] <Chipaca> hexchat fail
[15:28] <zyga> Chipaca: something like this http://paste.ubuntu.com/24313896/
[15:28] <zyga> Chipaca: if you +1 I will push that into mvo's PR
[15:29] <sborovkov> Hello again. Am I doing something wrong here? Trying to get conf details for core snap. r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/core/conf') - this returns me 404. I was doing it according to this https://github.com/snapcore/snapd/wiki/REST-API#get-v2snapsnameconf
[15:31] <ogra> sborovkov, if there are no config options set (the default) you probably wont get any back
[15:32] <Chipaca> sborovkov— is your url correct? e.g. does /v2/system-info work?
[15:34] <ogra> sborovkov, try something like: "snap set core system.powerkey-action=poweroff" (thats a harmless one) and see if you then get something else than 404
[15:35] <zyga> Chipaca: pushed, please comment on the PR
[15:38] <Chipaca> zyga— sorry got delayed
[15:38] <Chipaca> zyga— recommend leave the code as it was, and then use sort.Slice directly
[15:39] <mup> Bug #1679739 opened: System-User Assertions and the system time <Snappy:New> <https://launchpad.net/bugs/1679739>
[15:39] <Chipaca> zyga— saying as much on the pr
[15:39] <Chipaca> there
[15:40] <zyga> Chipaca: aha, looking
[15:40] <mbruzek> Setup snap "core" (1441) security profiles (cannot setup apparmor for snap "core": cannot load apparmor profile "snap.core.hook.configure": cannot load apparmor profile: exit status 243
[15:41] <mbruzek> apparmor_parser: Unable to replace "snap.core.hook.configure".  Permission denied; attempted to load a profile while confined?
[15:41] <zyga> Chipaca: odd, I don't have sort.Slice
[15:41] <zyga> Chipaca: is that a 1.7 thing?
[15:41] <Chipaca> ah
[15:41] <Chipaca> if it is, then ignore me
[15:41] <Chipaca> zyga— quite possibly
[15:41] <pedronis> living in the future (well past) ?
[15:41] <zyga> Chipaca: I wish go docs had a @since thing
[15:41] <Chipaca> yeah
[15:41] <zyga> :/
[15:41] <Chipaca> me too
[15:42] <zyga> ok
[15:43] <sborovkov> Chipaca: /v2/system-info works '{"type":"sync","status-code":200,"status":"OK","result":{"kernel-version":"4.4.0-1048-raspi2","managed":true,"on-classic":false,"os-release":{"id":"ubuntu-core","version-id":"16"},"series":"16","version":"2.23.6+201704032253.git.e2ab58d~ubuntu16.04.1"}}'
[15:44] <sborovkov> ogra: command you have me works as well.
[15:44] <fgimenez> zyga: the test snaps are already in place since this morning for the dbus interface branch, could you please retrigger the tests? (i don't have the right permissions sorry)
[15:44] <mbruzek> Has anyone had problems with apparmor profiles while running snaps in lxd?
[15:44] <ogra> sborovkov, well, does it stop returning 404 after you used that  ?
[15:44] <tyhicks> mbruzek: what ubuntu release for the host and container?
[15:44] <Chipaca> sborovkov— and /v2/snaps/core/conf ?
[15:44] <mbruzek> xenial and xenial
[15:44] <Chipaca> sborovkov— you might be missing the /snaps/ in there
[15:45] <mbruzek> tyhicks: snap version 2.22.6
[15:46] <sborovkov> Chipaca: oh you are right, my bad :-( How did I not notice that. So it's not gonna return the full list of settings anyway? Because with corrected url I get '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"invalid option name: \\"\\""}}'
[15:46] <mbruzek> tyhicks: actually the host is yakkety
[15:46] <zyga> fgimenez: I don't have permissions for adt, I can merge master and push though
[15:47] <fgimenez> zyga: np, i'll do it
[15:47] <Chipaca> sborovkov— I don't know enough about config to answer that
[15:47] <tyhicks> mbruzek: and the container OS?
[15:47] <mbruzek> Ubuntu
[15:47] <tyhicks> oh
[15:47] <tyhicks> you didn't higlight me in you orig answer
[15:48] <tyhicks> mbruzek: is the container unprivileged?
[15:48] <mbruzek> tyhicks: so xenial, and yakkety
[15:48] <mbruzek> tyhicks: it is a privileged container
[15:49] <tyhicks> mbruzek: that's a problem - that means that /sys/kernel/security/apparmor doesn't exist inside your container, does it?
[15:50] <tyhicks> mbruzek: well, you'll probably see "permission denied" even as root when trying to look at that directory
[15:51] <mbruzek> when I sudo su - I can see the profiles file.
[15:51] <ogra> sborovkov, try querying for "system" after you set the powerkey-action key it should contain something ... what you are running is teh equivalent of: snap get core " " ... that returns the "invalid-option" while: "snap get core system" will return the json for the system category
[15:51] <tyhicks> mbruzek: your inside the container?
[15:51] <mbruzek> tyhicks: oh that was on host
[15:52] <tyhicks> mbruzek: right - the problem is that you don't have access to apparmorfs inside of the privileged container so snapd can't load profiles
[15:52] <mbruzek> tyhicks: Nope I can see in that folder and the files in it when inside the container
[15:52] <sborovkov> ogra: Trying.  r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', data={'keys': 'system'}) -> '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"invalid option name: \\"\\""}}'
[15:52] <sborovkov> snap get core system does return proper values though
[15:52] <zyga> fgimenez: thank you!
[15:53] <zyga> tyhicks: hello :)
[15:53] <ogra> ogra@localhost:~$ snap get core system
[15:53] <ogra> {
[15:53] <ogra> 	"powerkey-action": "poweroff"
[15:53] <ogra> }
[15:53] <tyhicks> mbruzek: inside the container, run `"echo profile ctest {}" | sudo apparmor_parser -qr`
[15:53] <ogra> sborovkov, it does for me
[15:53] <tyhicks> hey zyga!
[15:53] <ogra> sborovkov, oops, sorry, i read "doesn't"
[15:53] <zyga> morphis: I'll EOD and focus on giving F25 workstation and server a quick test
[15:53] <sborovkov> ogra: Yup that works. But not when I am doing request myself. Not sure what's the difference. I see that I am supposed to pass keys to it which I do
[15:54] <ogra> perhaps try the full key name ... "system.powerkey-action"
[15:54] <mbruzek> tyhicks: # `"echo profile ctest {}" | sudo apparmor_parser -qr`
[15:54] <mbruzek> echo profile ctest {}: command not found
[15:55] <sborovkov> ogra: Same error :-( It does not like "keys" it seems.
[15:55] <mbruzek> tyhicks: same error if I run as "ubuntu" inside the contaienr
[15:55] <ogra> hmm
[15:56]  * zyga waves o/
[15:56] <tyhicks> mbruzek: I goofed up the quotes
[15:56] <sborovkov> ogra: Ok I figured it out, mistake in my code
[15:56] <ogra> ah, cool
[15:56] <tyhicks> mbruzek: `echo "profile ctest {}" | sudo apparmor_parser -qr`
[15:56] <Chipaca> sborovkov— does 'data' work with a dictionary like that?
[15:57]  * ogra never used the REST api for config ... always only snap set/get
[15:57] <Chipaca> sborovkov— what's the request you're doing, once you're past your library?
[15:57] <mbruzek> tyhicks: apparmor_parser: Unable to replace "ctest".  Permission denied; attempted to load a profile while confined?
[15:57] <mup> Bug #1679747 opened: Cannot send bluetooth SCO packets with Raspberry Pi 3 internal bluetooth module. <Snappy:New> <https://launchpad.net/bugs/1679747>
[15:58] <sborovkov> Chipaca: Yeah, I replaced data with params and it works. I rarely use REST API so hence that mistake.
[15:58] <Chipaca> sborovkov— out of curiosity, why are you using the api directly?
[15:59] <tyhicks> mbruzek: in the host, look in /var/log/syslog for any lines containing apparmor="DENIED" and /sys/kernel/security/apparmor/.replace
[15:59] <morphis> zyga: nice!
[16:00] <morphis> zyga: don't forget to comment in bodhi!
[16:01] <sborovkov> Chipaca: well we distribute our software with users not having access to the system. So for some cases (for some TVs) they might need to change config.txt values from webinterface to get it to work. So I need an ability to modify it programmatically from our snap
[16:01] <mbruzek> tyhicks: Yep I see it
[16:01] <mbruzek> tyhicks: Apr  4 08:48:58 pandora kernel: [ 1782.858544] audit: type=1400 audit(1491313738.389:146): apparmor="DENIED" operation="file_mmap" namespace="root//lxd-juju-70fced-0_<var-lib-lxd>" profile="/usr/lib/lxd/lxd
[16:01] <mbruzek> -bridge-proxy" name="/usr/lib/lxd/lxd-bridge-proxy" pid=17468 comm="lxd-bridge-prox" requested_mask="m" denied_mask="m" fsuid=165536 ouid=165536
[16:02] <Chipaca> sborovkov— and your snap is python already so you prefer to talk to the rest api directly?
[16:03] <tyhicks> mbruzek: that's not the one I'm looking for since it doesn't mention the ".replace" file
[16:04] <sborovkov> Chipaca: yes
[16:04] <Chipaca> fair
[16:05] <zyga> morphis: will do :)
[16:06] <morphis> zyga: we need to talk in the next days a bit more about your research in the past about the policy for golang packages in openSUSE
[16:07] <zyga> morphis: sounds good
[16:07] <mbruzek> tyhicks: The DENIED ones do not contain replace, the STATUS ones do. http://pastebin.ubuntu.com/24314095/
[16:08] <tyhicks> mbruzek: ok, I'll need a little bit to look through lxd's code and/or poke at this myself
[16:09] <mbruzek> would you like me to create a bug?
[16:11] <tyhicks> mbruzek: this is an intentional decision by lxd to not allow apparmor profile loads inside of privileged containers: https://github.com/lxc/lxd/blob/master/lxd/apparmor.go#L321
[16:13] <tyhicks> mbruzek: we're not seeing a denial message in the syslog because the rule on line 326 denies without auditing those filesystem accesses
[16:13] <tyhicks> mbruzek: you should use an unpriv container if you need to run snaps inside the container today
[16:14] <mbruzek> tyhicks: I thought priviledge containers should be able to do everything? why can they not load apparmor profiles?
[16:15] <tyhicks> mbruzek: no, they cannot do everything
[16:15] <mbruzek> OK
[16:15] <tyhicks> mbruzek: they're still confined and there attempts made at trying to keep them from affecting the system
[16:15] <tyhicks> s/there attempts/there are attempts/
[16:18] <tyhicks> mbruzek: you could file a bug against lxd and subscribe the security team so that we can discuss if it is safe to enable profile loads inside of a privileged container using apparmor namespaces
[16:18] <tyhicks> mbruzek: I don't know the answer to that off the top of my head and we'd need broader discussion
[16:18] <mbruzek> will do after my meeting.
[16:18] <tyhicks> ok
[17:00] <mup> PR snapd#3141 opened: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141>
[17:56] <pedronis> mvo: this test seems to fail often, at least under autopkgtest: autopkgtest:ubuntu-16.10-amd64:tests/main/refresh-core-with-hanging-configure-hook
[19:10] <mdye> I have snapd 2.23.6 and a snap installed in devmode and tracking from the beta channel. "snap info" shows a new version (2.0.1 vs. my current 2.0.0) in that channel, but "snap refresh" doesn't update my running instance. Is that intended or a bug?
[19:14] <ogra> you need to pass --devmode to the refresh command too if you installed with --devmode
[19:14] <ogra> (security feature)
[19:20] <mdye> ogra: thx; automatic updates and rollbacks are handled by snapd as of something like 2.22 instead of the systemd timer, right? is there a way today to enable automatic updates and rollbacks of snaps installed with devmode?
[19:24] <pmcgowan> mdye, not currently, there is an open bug on it
[19:25] <mdye> thx. do you have a URL to the bug? I'd like to track it
[19:25] <pmcgowan> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102
[19:25] <mup> Bug #1665102: Snap refresh not working as expected on devmode snaps <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1665102>
[19:25] <mdye> thx :)
[19:25] <pmcgowan> yep
[19:25] <mup> Bug #1676928 opened: snap shell can't reach $SNAP_USER_DATA: Permission denied <cdo-qa> <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1676928>
[19:45] <Chipaca> why, oh *why*, does setting IFS to \n make compgen not print newlines?
[19:48] <jrwren> in bash, IFS is internal field separator. its not awk where it is input field separator with corresponding output field separator
[19:50] <mup> PR snapcraft#1214 closed: sources: add subversion source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1214>
[19:55] <Chipaca> jrwren— so why does setting it to \n make the output of compgen not include it?
[19:55] <Chipaca> I'd be unsurprised if compgen used ${IFS[0]} to separate its output
[19:55] <Chipaca> but ... this is the opposite
[19:57] <jrwren> Chipaca: sorry, not sure, just trying to help with pointers, hopefully not bad pointers.
[19:57] <Chipaca> :-D
[20:02] <mup> PR snapcraft#1215 closed: sources: add mercurial source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1215>
[20:11] <chani_> hi guys i got a doubt
[20:12] <Chipaca> chani_— shoot
[20:12] <chani_> i am trying to include a debian package in my snap using stage-packages
[20:13] <chani_> and when i try to run that package from a coustom script via deamon
[20:14] <chani_> its not working as the deb executable script has hard links to other files like /usr/bin/...
[20:15] <chani_> which it can't find as they are included in /snap/my-snap/usr/bin....
[20:15] <chani_> so what can i do here
[20:18] <chani_> should i use docker instead as where i have a complete virtualization
[20:18] <chani_> or is there some way i can use virtualization in my snaps
[20:23] <niemeyer> Okay, I'm going to take a break now..
[20:23] <niemeyer> Sorry, didn't manage to get to 2.24 yet.. will try to do some work there today still
[20:25] <niemeyer> chani_: Can you please ask a question under the snapcraft category in the forum, if that's not asking too much?  I'll back back later and  would like to hear/collaborate on the conversation
[20:26] <niemeyer> chani_: There are a few tricks you can use to make that work, and I have some ideas to improve on that exact area
[20:26]  * niemeyer back later
[20:26] <chani_> can you give me the link as to where to post the question
[20:27] <chani_> and also if there is any document reference for the tricks you mentioned
[20:45] <pedronis> chani_: https://forum.snapcraft.io/
[20:47] <chani_> got it i am posting it right there now
[20:53] <mup> PR snapcraft#1224 closed: tests: update name registration window limit test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1224>
[20:59] <mdye> is there a way to prevent snapd from doing updates ? (to lock a version indefinitely or delay updates for a time?)
[21:18] <chani_> niemeyer: hai i had posted my question in the form here is the link https://forum.snapcraft.io/t/how-to-ship-deb-packages-along-with-snaps/149
[21:20] <mup> PR snapcraft#1231 opened: pluginhandler: exclude `/snap/` from libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1231>
[21:29] <mup> PR snapcraft#1228 closed: nodejs plugin: switch to the newer LTS <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1228>


[09:18] <cjwatson> Kuraokami: Weekly
[09:20] <cjwatson> Kuraokami: The restore job currently starts at 03:30 UTC every Saturday, and typically takes until around 13:00 UTC on Sunday to complete
[09:20] <cjwatson> (or maybe a bit more)
[09:21] <cjwatson> Kuraokami: That's a full dump/restore from production, so everything changed only on staging vanishes at that point
[10:46] <mitya57> Hi! These builds are marked as failed, but according to the log they succeeded:
[10:46] <mitya57> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4885/+build/24245671
[10:46] <mitya57> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4885/+build/24245673
[11:00] <cjwatson> mitya57: Known networking issue with bos02, being investigated.  I've retried those jobs in the meantime, which is the only remedy right now
[11:03] <mitya57> Thank you!
[13:18] <athos> I got the same issue with some php builds a few hours ago. Is there a bug open for that network issue?
[13:23] <cjwatson> athos: There's an internal ticket
[13:23] <cjwatson> Not much point in an external bug as well because it's not a defect in Launchpad itself, but rather in infrastructure
[13:25] <athos> ack; thanks, cjwatson :)