[01:59] <mup> PR snapd#3205 closed: tests: add openvswitch interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3205>
[05:56] <mup> PR snapcraft#1282 opened: parts: remove the deprecated snap keyword from the internal parts representation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1282>
[06:18] <mup> PR snapd#3138 closed: interfaces/mount: add Change.Perform <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3138>
[06:39] <pedronis> mvo_: morning, I need 2nd reviews of snapd#3192 and snapd#3239
[06:39] <mup> PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
[06:39] <mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[06:51] <mvo_> pedronis: thank, I have a look
[07:18] <pstolowski> morning
[07:30] <zyga> good morning
[07:30] <zyga> mvo_: sorry for being late, I will focus on code reviews the whole day
[07:31] <mvo_> zyga: hey, good morning. and no worries
[07:34] <zyga> mvo_: did you see this error? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170425_122307_f3ac6@/log.gz
[07:34] <zyga> + dpkg --purge --force-depends snapd
[07:35] <zyga> dpkg: error processing package snapd (--purge):
[07:37] <mvo_> zyga: I have not seen this error yet. pre-removal script returned 1 is really not helpful :(
[07:38] <zyga> mvo_: are those logged in any dpkg specific log file?
[07:39] <mvo_> zyga: unfortunately not, the best info we have is "Job for snapd.service canceled." right before that
[08:12] <mup> PR snapd#3197 closed: store: retry on connection reset too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3197>
[08:20] <mup> PR snapd#3192 closed: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3192>
[08:24] <pedronis> mvo_: static checks are failing on the refresh scheduling branch, and thanks for bearing with me about naming stuff
[08:25] <pedronis> mvo_: also thanks for the other review
[08:28] <mup> PR snapd#3240 opened: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
[08:28] <mvo_> pedronis: thank, looking
[08:29] <mvo_> thanks even
[08:37] <ogra_> zyga, do you have access to https://travis-ci.org/profile/snapcore  i would like to get the core-build branch turned on
[08:37] <ogra_> (or mvo_ ^^)
[08:37] <zyga> ogra_: looking
[08:38] <zyga> my github token is in poland so... fingers crossed
[08:38] <zyga> I have
[08:38] <zyga> ah, no
[08:38] <ogra_> whee
[08:38] <zyga> You require admin rights to enable these repositories
[08:38] <ogra_> :(
[08:38] <zyga> so that's gustavo or mvo perhaps
[08:38] <mvo_> ogra_: I can not
[08:38] <zyga> or JamieBennett
[08:38] <zyga> it's pretty terrible that we don't even know who controls this apart from gustavo
[08:39] <JamieBennett> zyga: I do not have admin rights there, I would defer to niemeyer
[08:39] <ogra_> yes, spoiled by LP team management :)
[08:39] <ogra_> ok, then i'll wait
[08:39] <zyga> thanks for checking JamieBennett
[08:40] <pedronis> Chipaca: hi, maybe you can give a 2nd review to snapd#3239 (it's smallish and has already a +1)
[08:40] <mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[08:41]  * zyga is sorry about the lack of reviews
[08:42] <zyga> I'll spend my whole day reading code, no writing today
[08:42] <Chipaca> pedronis— perhaps I could
[08:44] <ogra_> hey, seeing suddenly each and ever project switch to meson ... do we have support for that in snapcraft yet
[08:44] <ogra_> *every
[08:44] <ogra_> seems to be the next famous thing
[08:44] <Chipaca> http://mesonbuild.com/ ?
[08:44] <ogra_> yep
[08:45] <pedronis> Chipaca: thx
[08:48] <pedronis> mvo_: once #3239 lands I'm down to two PRs, one should be ok but needs  re-review/reviews, the other needs a little bit of further work
[08:55] <mvo_> pedronis: great, thank you
[08:56] <ogra_> sigh,. what changed in the store ... the core builds constantly fail uploading with a proxy error
[08:57] <mvo_> Chipaca: I like your suggestion about the --time help output. how about "Only show refresh time information" or "Only show refresh times information but not perform any refresh"?
[08:57] <ogra_> cjwatson, did anything change over night ? i did hit the retry button 3 times for 5 snaps already, all fail
[08:58] <ogra_> cjwatson, https://launchpad.net/~snappy-dev/+snap/core/+build/34833 or https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/34849
[08:59] <zyga> mvo_: maybe `snap refresh --query`
[08:59]  * zyga reads that branch now
[08:59] <Chipaca> mvo_— ( show refresh schedule information | list packages that would be refreshed ) but do not perform a refresh ?
[09:00] <Chipaca> zyga— --query is weird, as you might expect its output to be that of --list
[09:02] <zyga> Chipaca: hmm, I agree
[09:02] <zyga> Chipaca: but --time is also weird in this context
[09:02] <Chipaca> zyga— remove all flags, add a single --dwim
[09:02] <zyga> Chipaca: I don't like it when "command --option" does something that more feels like "command subcommand"
[09:02] <zyga> Chipaca: --dwim?
[09:02] <zyga> dowhatimean?
[09:02]  * Chipaca nods
[09:03] <zyga> no, wait, blue WHAAAM
[09:03] <mvo_> Chipaca: works for me, thanks for the suggestion!
[09:07] <Chipaca> mvo_— and i notice its prereq is gtg once green
[09:07] <mvo_> Chipaca: indeed :)
[09:16] <zyga> mvo_: added one question about 3240
[09:18] <pedronis> notice that we already have snap refresh ---list
[09:18] <pedronis> so that boat has sailed I think
[09:19] <zyga> yes, it is somewhat unavoidable, and I suspect nobody is really bothered by this (just software being software)
[09:22] <mvo_> zyga: uh, nice catch! thank yu
[09:23] <zyga> mvo_: ah, I wasn't sure if this is some deliberate design!
[09:23] <pstolowski> mvo_, added a test to #3235
[09:23] <zyga> mvo_: I'll read the rest (I oftne start from the bottom for no other reason than that it feels less daunting) :-)
[09:24] <cjwatson> ogra_: 502 means a problem within click-updown
[09:24] <cjwatson> ogra_: so if something changed it was on the store side, not LP
[09:24] <mvo_> pstolowski: \o/
[09:29] <cjwatson> ogra_: raised on the OLS channel since our failure rate has definitely got a lot worse in the last day or two
[09:30] <ogra_> cjwatson, yeah, it started around easter that i saw the first failures in a while, but it got massively worse during this week
[09:30] <morphis> zyga: did you rebase my branch?
[09:32] <morphis> zyga: the interesting thing is that I don't have tests/main/interfaces-openvswitch  in my tree
[09:32] <zyga> morphis: no, I commented on what is in the PR
[09:32] <zyga> morphis: I didn't even clone it locally
[09:32] <zyga> morphis: merge master, fix the test and push
[09:33] <zyga> morphis: maybe travis tests the merged branch as well as the branch itself
[09:35] <morphis> zyga: done
[09:35] <pedronis> "The job exceeded the maximum time limit for jobs, and has been terminated." is a bit frustrating :/
[09:35] <zyga> yes, indeed
[09:36] <zyga> especially since travis is there only to hand-hold spread and its army of VMs
[09:37] <cjwatson> ogra_: There was a previous incident that was due to a large volume of logs being shovelled around within prodstack and swamping internal bandwidth, but that was fixed
[09:38] <cjwatson> (we should possibly detect 502 and retry, but with the current failure rate I don't know that it'd make a whole lot of difference)
[09:46] <Trevinho> jdstrand: can you try use snapcraft-preload from this branch https://github.com/3v1n0/snapcraft-preload/tree/string-appends-fixes ?
[09:46] <Trevinho> it should fix the issues you were facing...
[09:54] <Trevinho> jdstrand: applying http://pastebin.ubuntu.com/24459277/ should be enough
[09:55] <jacekn> hello. How to "unpublish" snap from all channels?
[09:56] <zyga> jacekn: "snapcraft close" I think
[09:58] <jacekn> zyga: hmm ok, I may have to log in to do that (I was trying to avoid that)
[09:59] <zyga> jacekn: I suspect you can do that from the web UI too
[09:59] <zyga> jacekn: just not sure as I didn't try
[10:00] <jacekn> zyga: does not look like it, when I untick all channels web UI says "This field is required"
[10:02] <jacekn> zyga: ah alright so look like it's because the store must have something in edge and beta. I used snapcraft close and that just switched beta and edge to the same revision as candidate
[10:06] <pstolowski> Chipaca, added 1 comment to your tab-completion
[10:06] <Chipaca> woo
[10:07] <pstolowski> chances are it's nonsense ;)
[10:07] <Chipaca> oh the _other_ tab completion one
[10:07] <Chipaca> :-)
[10:07] <pstolowski> (my comment, not your PR)
[10:08] <Chipaca> good question about empty :. Let me check.
[10:09] <ogra_> cjwatson, well, the failure seems pretty reliable now ... in case anyone needs reproducers ... let me know ...
[10:10] <pedronis> pstolowski: made a small comment in one of your interface hooks PRs
[10:10] <zyga> mvo_: added one more comment to https://github.com/snapcore/snapd/pull/3240
[10:10] <mup> PR snapd#3240: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
[10:10] <Chipaca> pstolowski— basically parts[0] would be "", meaning we'll suggest any and all plugs :-(
[10:10] <pstolowski> pedronis, yes, just saw them thanks!
[10:10] <pstolowski> Chipaca, ha!
[10:11] <Chipaca> pstolowski— i'll confirm this empirically in a moment
[10:12] <pstolowski> Chipaca, should be easy to handle and make "" into "core" I guess, and let all the remaining logic do the job?
[10:12] <mvo_> zyga: aha, another nice catch, thank you again
[10:12]  * zyga is super slow with reviews, needs to switch into review mood
[10:16] <Chipaca> pstolowski— ah, we don't offer everything, we offer nothing instead
[10:16] <Chipaca> slightly better
[10:16] <Chipaca> still, I'll force it to 'core' if empty
[10:20] <pstolowski> Chipaca, :)
[10:22]  * zyga breaks for some lunch and coffee
[10:22] <zyga> brb
[10:23] <niemeyer> Mornings
[10:25] <mvo_> hey niemeyer, good morning!
[10:27] <pstolowski> hey niemeyer
[10:31] <mup> PR snapd#3241 opened: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
[10:32] <mup> PR snapd#2895 closed: client,cmd/snap: first pass at client messaging around modes <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2895>
[10:35] <jacekn> anybody knows what the problem could be? http://pastebin.ubuntu.com/24459530/ if I revert to tag v1.5.2 it builds fine so must be someting on prometheus side but still snapcraft should allow me to build it?
[10:36] <Chipaca> pstolowski— addressed
[10:37] <pstolowski> 👍👍
[10:37] <niemeyer> mvo_, pstolowski: Mornings!
[10:38] <niemeyer> mvo_: Seeing the recent change in snapd#2833, isn't there a test missing there?
[10:38] <mup> PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
[10:38] <Chipaca> jacekn— looks like a bug in prometheus indeed
[10:38] <Chipaca> jacekn— it's importing "context" from the wrong place
[10:38] <Chipaca> jacekn— that is an error from Go itself
[10:39] <Chipaca> jacekn— “package context: unrecognized import path "context" (import path does not begin with hostname)” i mean
[10:39] <Chipaca> it is a strange one though
[10:42] <mup> PR snapd#3239 closed: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[10:42] <jacekn> Chipaca: coudl the fact that snapcraft prepends improt-path with "./" ahve anythihng to do with it? 'go', 'get', '-t', '-d', './github.com/prometheus/prometheus/...']'
[10:43] <Chipaca> jacekn— it shouldn't, but it might
[10:43] <Chipaca> jacekn— give me a bit
[10:44] <morphis> niemeyer: anything left to get https://github.com/snapcore/spread-images/pull/1 merged?
[10:44] <mup> PR spread-images#1: Add debian-unstable-64 base image <Created by morphis> <https://github.com/snapcore/spread-images/pull/1>
[10:47] <Chipaca> jacekn— what happens if you run that by hand, adding a -v to it?
[10:49] <jacekn> Chipaca: it will fail I'm pretty sure because of missing GO env variables but I can try setting it up
[10:51] <pedronis> niemeyer: hi, snapd#3237 can be reviewed again
[10:51] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[10:52] <Chipaca> pstolowski— hm, re-reading your comment, is it only ever :<slot>, never :<plug>?
[10:56] <pstolowski> Chipaca, I think so yes, would need to check Resolve* methods again
[10:57] <Chipaca> then i've got this wrong. amending.
[10:58] <pstolowski> Chipaca, please double check in repo.go
[10:58] <niemeyer> morphis: It's in
[10:58] <morphis> niemeyer: thanks
[11:00] <niemeyer> morphis: np
[11:00] <niemeyer> pedronis: Looking
[11:00] <morphis> niemeyer: another one for fedora is coming soon
[11:01] <Chipaca> pstolowski— in connect, empty means core only for the slot; in disconnect, it's either
[11:02] <mup> PR snapcraft#1281 closed: core: switch to version git <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1281>
[11:09] <Chipaca> popey— about https://forum.snapcraft.io/t/broken-snap-breaking-snapd/401 zyga seemed to know what it was about (and there was a pr to address it)
[11:09] <Chipaca> popey— i'll give him a shout to have him comment in there when he's around
[11:10] <pstolowski> Chipaca, right
[11:11] <popey> Chipaca: thanks
[11:15] <niemeyer> pedronis: LGTM
[11:15] <pedronis> niemeyer: thx
[11:17] <ogra_> niemeyer, could you please enable travis for the core-build branch ?
[11:17] <niemeyer> ogra_: Done
[11:17] <ogra_> thanks :)
[11:18] <niemeyer> Any time
[11:18] <Chipaca> zyga— hey
[11:19] <Chipaca> zyga— we're seeing more and more panics in the wild with the nil map
[11:19] <Chipaca> zyga— what is the status of that fix?
[11:19] <zyga> Chipaca: let me see
[11:19] <Chipaca> zyga— and can you comment about it on https://forum.snapcraft.io/t/broken-snap-braking-snapd/401
[11:19] <zyga> Chipaca: yes
[11:20] <zyga> Chipaca: so the fix was merged by mvo long ago
[11:20] <zyga> Chipaca: we should also review and merge https://github.com/snapcore/snapd/pull/3208 to stay proactive for future issues
[11:20] <mup> PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
[11:21] <zyga> Chipaca: done
[11:22] <Chipaca> zyga— what is the snap doing wrong such that it breaks snapd?
[11:23] <zyga> Chipaca: just make a snap that has a "content" plug
[11:23] <zyga> Chipaca: without anything else
[11:24] <zyga> Chipaca: we go and sanitize that, notice the content type is empty so we go and say it is the same as the interface name
[11:24] <mup> PR snapd#3242 opened: tests: tweak time for econnreset test a bit more <Created by mvo5> <https://github.com/snapcore/snapd/pull/3242>
[11:24] <zyga> Chipaca: but then whaam, attr is a nil map
[11:24] <zyga> Chipaca: I fixed that quite some time ago
[11:24] <ahayzen> zyga, hey, you state to install the edge core snap to 'see the error go away', but i can't install the one from edge as the snapd service crashes as soon as it starts :-) is there anyway i can manually stop it trying to do the security profiles step ?
[11:25] <zyga> ahayzen: aha, when you already have that snap installed
[11:25] <zyga> ahayzen: I'm not sure actually
[11:25] <zyga> ahayzen: (eventually, like in two weeks) the change will garbage collect and won't run anymore
[11:25] <zyga> ahayzen: but I assume you meant for something better
[11:25] <ahayzen> like it failed to install and there is a pending task that never completes todo the security profiles (which then crashes each time the service starts)
[11:26] <ahayzen> zyga, right, yeah i was looking for a way to 'fix' my system :-) anyway i can force the garbage collect or something?
[11:26] <zyga> Chipaca, mvo_: ^ any ideas?
[11:26]  * zyga has none apart from moving the needle of time a little bit forward
[11:27] <ahayzen> :-)
[11:27] <zyga> mvo_: perhaps curious input to the repair assertion
[11:28] <niemeyer> morphis: Do you have the fixes for the PR we discussed lined up?
[11:28] <zyga> mvo_: I'd say that it would be good if we could send a repair assertion that repairs the state without sending 10MB binary
[11:28] <niemeyer> morphis: Want to include in the board
[11:28] <morphis> niemeyer: not yet
[11:29] <niemeyer> morphis: Okay, can you put that up in the pipeline so we don't risk releasing without the fixes?
[11:32] <pedronis> Chipaca: mvo_: snapd#3237 needs a 2nd review
[11:32] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[11:33] <mup> PR snapd#3208 closed: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3208>
[11:40] <sil2100> Hello! We seem to be haunted today by sha mismatches today when getting the pc-kernel snap from the store - almos all our autopkgtests for ubuntu-image failed with this error:
[11:40] <sil2100> error: sha3-384 mismatch for "pc-kernel": got 7873b5723739ece72e102f518ba4c3e4c8e656ea2f64f80759a4fcda0e0737ca1d13459ac97221a4a059fce357a2ca46 but expected 33d383ce8f59a0cc43905da29208d6152d8204dd7a90500d4dfd2f1586d440359796374f17778a88948561c002cc563a
[11:40] <sil2100> Does anyone know if there are any outages/issues that could cause this?
[11:40] <ogra_> sil2100, i wonder if thats related to the upload errors i see for the core snaps (proxy error)
[11:41] <niemeyer> sil2100: Can you please open a topic in the forum under the store category?
[11:42] <niemeyer> sil2100: Actually, I suspect we even already have a topic for that particular error
[12:00] <Chipaca> pstolowski— pushed a thing to handle : in connect better
[12:02] <Chipaca> sil2100— i'm willing to bet one of those hashes is the hash of '503 Service Unavailable'
[12:02] <Chipaca> sil2100— or sth like that
[12:03] <zyga> Chipaca: 504 Cure For Cancer Follows, but we only have the hash
[12:06]  * ogra_ wonders if he needs to swing another magic wand to make https://travis-ci.org/snapcore/core-build/builds/225967248 start 
[12:06] <ogra_> sits there since ages
[12:09] <ogra_> hah !
[12:10] <ogra_> complaining here helps it seems :)
[12:10] <Son_Goku> ogra_, hitting it with a hammer helps too :)
[12:10]  * Son_Goku hates Travis CI
[12:10] <ogra_> well, once it runs it is fine
[12:11] <mup> PR snapcraft#1283 opened: core: predetermine the magic path when a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
[12:14] <pstolowski> Chipaca, thanks
[12:15] <pedronis> ogra_: we were pinged here
[12:15] <ogra_> yeah
[12:15] <pedronis> but there's a forum topic
[12:16] <ogra_> yeah
[12:16] <pedronis> so any suggestion will go there
[12:46] <facubatista> question, does build.snapcraft.io build for several architectures?
[12:46] <ogra_> armhf and amd64 i think
[12:48] <facubatista> ogra_, thanks
[12:57] <Chipaca> jdstrand— thinking of changing the cat in complete.sh to \grep -v '[[:cntrl:];?*{}]'
[12:58] <ogra_> poor cat
[12:59] <zyga> Chipaca: does [[:cntrl:]] in any insane way depend on locale?
[12:59] <zyga> (just checking)
[12:59] <ogra_> nope
[13:00] <Chipaca> zyga— if it does, it's not insane :-)
[13:00]  * zyga reads the aliases branch
[13:00] <zyga> Chipaca: in nort korea space is a control character because they have little space
[13:00] <Chipaca> zyga— and way too much control
[13:06] <jdstrand> Chipaca: that seems like a reasonable start (I've not started looking at the branch yet today)
[13:06] <jdstrand> again yet...
[13:07] <Chipaca> jdstrand— I'm looking for something that's good enough to merge (so it can be in 2.25) even if we then make it better later
[13:07]  * jdstrand nods
[13:08] <jdstrand> I'll be getting back to this btw. just tending to review tools updates for the bad snap issue
[13:09] <Chipaca> np
[13:14] <niemeyer> morphis: not sure if you've seen that message: can you put that up in the pipeline so we don't risk releasing without the fixes?
[13:29] <mup> PR snapd#2833 closed: many: allow core refresh.schedule setting <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2833>
[13:32] <pedronis> mvo_: yay ^ !
[13:36] <fgimenez> mvo_: while working on an extension of the system-observe interface test i've found that any snap, even if they don't declare any plug, can read /proc/meminfo, this can't be intended, right?
[13:39] <mvo_> pedronis: \o/ indeed
[13:41] <mvo_> fgimenez: hm, that is curious
[13:41]  * mvo_ looks
[13:43] <Chipaca> zyga, jdstrand, why am i getting “hsearch_r failed” for things that used to work?
[13:44] <fgimenez> mvo_: thanks, a simple snap like this is enough to check http://paste.ubuntu.com/24460232/, with that installed "system-observe-consumer cat /proc/meminfo" shows the contents (the name of the snap can be misleading, no interface involved)
[13:44] <mvo_> fgimenez: I can confirm with hello-world.sh that I can read /proc/meminfo without special permissions. this is curious because "git grep meminfo" only shows an allow rule in the system-observer. maybe jdstrand knows more?
[13:48] <pedronis> zyga: sounds like out of sync snap-confine vs sepcomp bits in snapd
[13:48] <pedronis> sorry
[13:48] <pedronis> Chipaca: ^
[13:48] <pedronis> * in/from
[13:49] <pedronis> Chipaca: we should have ways to avoid that but if you running things manually I suppose it can happen
[13:54] <mup> PR snapd#3171 closed: snapstate: normalize gadget defaults <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3171>
[13:56] <mup> Bug #1619154 changed: Cannot adjust systemd service definition <Snapcraft:Opinion> <Snappy:Opinion> <https://launchpad.net/bugs/1619154>
[14:07] <Chipaca> a'ight
[14:07] <Chipaca> jdstrand— I added https://github.com/snapcore/snapd/pull/3150/commits/6dcbcded52192f57dedb980872e6ad22a84a93e8 and all tests passed just the same
[14:07] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[14:21] <mvo_> morphis: do you need a hand with the xauthority PRs comments from gustavo? we need those for 2.25 (or revert the PR) so I'm keen to get things addressed  asap
[14:24] <jdstrand> Chipaca: nice
[14:53] <morphis> mvo_: no, working on them now
[14:53] <morphis> mvo_: had to leave for a fire accident as I am a fire fighter; already started with them earlier today
[14:53] <morphis> mvo_: sorry for the delay
[14:54] <ogra_> another attempt of blowing up your city hall ?
[14:56] <morphis> ogra_: not really .. we already had a bigger ship on fire on tuesday really early in the morning ..
[14:56] <morphis> and today somebody decided to get light his shed :-)
[14:57] <ogra_> oh my
[14:57]  * niemeyer will feel safer with morphis around from now on
[14:58] <morphis> :-)
[14:58]  * ogra_ makes a note to not move to verden if not owning fireproof underwear
[14:58] <mup> PR snapd#3243 opened: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[14:58] <morphis> ogra_: hehe, however I guess the rate of fire accidents is quite similar anywhere else too :-)
[14:59] <ogra_> yeah
[14:59] <morphis> we have about 20-30 alarms per year were only ~5 are real fires
[14:59] <ogra_> the guy trying to blow up the city hall was unique though ... enough to make the news :)
[14:59] <zyga> jdstrand: I made a small branch to fix a bug that was uncovered by CE
[14:59] <zyga> jdstrand: added you as a reviewer
[15:01] <morphis> ogra_: yeah ..
[15:01] <ogra_> crazy germans ... :)
[15:01] <morphis> ogra_: http://www.nonstopnews.de/galerie/25062 is what we had yesterday
[15:02] <ogra_> oh man
[15:03] <niemeyer> Lunch!
[15:04] <pedronis> Chipaca: mvo_: I need a 2nd review of snapd#3237
[15:04] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[15:04] <Chipaca> on it
[15:04] <pedronis> Chipaca: it's a small one
[15:07] <mvo_> morphis: no worries, just wanted to make a friendly offer for help :)
[15:07] <morphis> mvo_: thanks!
[15:08] <mvo_> pedronis: I have a look as well
[15:09] <Chipaca> pedronis— what's the “! snap aliases | MATCH ... ” thing?
[15:10] <Chipaca> pedronis— more exactly, what's the start-command-with-bang thing
[15:10] <pedronis> Chipaca: it negates the whole pipeline, it succeed if the pipeline files
[15:10] <pedronis> s/files/fails/
[15:11] <Chipaca> TIL
[15:11] <pedronis> it's an obscure bit
[15:11] <pedronis> admittedly
[15:11] <pedronis> Chipaca: man bash and search pipelines,  there's option [!] bit in there
[15:12] <Chipaca> will do
[15:14] <pedronis> Chipaca: thx
[15:14] <mup> PR snapd#3237 closed: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[15:17] <mvo_> pedronis: 3220 has test failures that look unrelated (mirror on linode issues?). do you mind if I restart the test?
[15:18] <pedronis> mvo_: I'm about to push a merged anyway
[15:18] <mvo_> pedronis: even better
[15:20] <pedronis> not that it will make it smaller, it's big mostly because of tests
[15:22] <mvo_> pedronis: ok :)
[15:22] <pedronis> I mean it's main prereq was already merged
[15:25] <pedronis> mvo_: pushed now
[15:27] <zyga> mvo_: can you consider https://github.com/snapcore/snapd/pull/3243 for 2.25 as a fix for CE, assuming that jdstrand gives it a +1
[15:27] <mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[15:28] <mvo_> zyga: we need input from jamie here, but yeah, I think thats ok. this really feels like we need the "snapd controls how snpa-confine behaves" changes we talked about
[15:28] <zyga> mvo_: yes but this is just a bugfix, not related to any re-architecture
[15:29] <zyga> mvo_: it was supposed to work like that but this was missed
[15:29] <morphis> niemeyer, mvo_: https://github.com/snapcore/snapd/pull/3244
[15:29] <mup> PR snapd#3244: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
[15:29] <mup> PR snapd#3244 opened: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
[15:35] <mup> PR snapcraft#1283 closed: core: predetermine the magic path when a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
[16:05] <mup> PR snapd#3245 opened: many: aliases v2 cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/3245>
[16:08] <pedronis> mvo_: ^ this is the small cleanups branch I mentioned at the standup, anyway current blocker is reviews for snapd#3220
[16:08] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:18] <pedronis> mvo_: niemeyer: seems we are hitting archive or network fun in the tests now, I got:
[16:20] <pedronis> https://travis-ci.org/snapcore/snapd/builds/226053803
[16:22] <mvo_> pedronis: :(   Unable to connect to mirrors.linode.com:http:
[16:25] <mvo_> pedronis, niemeyer: it looks like we should open a support ticket on linode if their mirror times out?
[16:27] <niemeyer> pedronis: Where did you see that message?
[16:28] <niemeyer> mvo_: ^
[16:28] <niemeyer> Looking at the error there I couldn't find it
[16:28] <pedronis> niemeyer: last run for snapd#3220
[16:28] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:28] <pedronis> niemeyer: some project prepare have "unable to locate pkg foo" and some have a bunch of those mirror errors
[16:29] <niemeyer> pedronis: Yeah, sorry.. was looking at the Travis error and wondering about the message mvo_ pasted above
[16:29] <niemeyer> Aha
[16:30] <niemeyer> pedronis, mvo_: Mirror seems up now
[16:31] <pedronis> I went through the list of PRs, I think I commented on the ones I could, some have feedback that nees acting on, some I think need niemeyer input/opinion
[16:31] <pedronis> I mean the PRs in the sprint post
[16:32] <niemeyer> pedronis: Thanks!
[16:33] <pedronis> niemeyer: snapd#3220 should be ready for reviewes btw,  also I pushed the small cleanup PR I mentioned in the standup
[16:33] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:33] <niemeyer> pedronis: Thanks, will look into it next
[16:34] <Chipaca> jdstrand— how's it going?
[16:35]  * pedronis going afk for a while, will check on things later
[17:08] <morphis> Pharaoh_Atem: https://paste.ubuntu.com/24461436/ .. we're moving :-)
[17:10] <Pharaoh_Atem> :D
[17:15] <morphis> Pharaoh_Atem: still quite hacky but it works
[17:15] <Pharaoh_Atem> it's a start!
[17:18] <cjwatson> ogra_: LP->store uploads may be better now after IS stopped some swift migration jobs
[17:22] <ogra_>  heh, ok, i'll try a re-upload
[17:22] <ogra_> cjwatson, thanks!
[17:26] <pedronis> linode:ubuntu-14.04-64:tests/main/econnreset is really quite flaky
[17:40] <jdstrand> Chipaca: hey, going to get back to it just a sec
[17:48] <jdstrand> mvo_: fyi, I approved https://github.com/snapcore/snapd/pull/3243
[17:48] <mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[18:02] <mup> PR snapcraft#1284 opened: extra verbose tests  <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
[18:08] <mup> PR snapcraft#1284 closed: extra verbose tests  <Created by cprov> <Closed by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
[18:47] <pedronis> niemeyer: I tried to address or answer the comments to snapd#3220
[18:47] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[18:57] <niemeyer> pedronis: Cheers!
[19:15] <pedronis> niemeyer: was the review sprint forum post synced recently ? I see some branches that were merged not marked as such
[19:21] <mvo_> a second review for 3240 would be great
[19:35] <niemeyer> pedronis: No, need to update.. currently running an errand but will update shortly
[19:56] <niemeyer> pedronis: Updating, and also integrating a few of the new PRs that were pushed in the last two days
[20:08] <niemeyer> pedronis: Updated
[20:16] <niemeyer> pedronis: LGTM, thanks for the changes!
[20:16] <jdstrand> Chipaca: ok, it took a while to get all the way through it to my satisfaction, but I've left my review feedback
[20:17] <Chipaca> jdstrand— thank you!
[20:17] <Chipaca> niemeyer— do you know if mvo is cutting the release tonight?
[20:17] <jdstrand> Chipaca: it's going to look like a lot, but it is almost all requesting adding comments here and there. I tried to give comments you can copy/paste to help
[20:17] <niemeyer> Chipaca: I don't think so.. aliases are still not in
[20:17] <Odd_Bloke> I'm talking to someone who's trying to build images but they don't yet have an account ID because they haven't uploaded a snap; is there an easy way for them to generate one without messing around with actually building/registering a snap?
[20:17] <Chipaca> niemeyer— ah ok
[20:18] <Chipaca> then i'm going to not address the review and instead sleep :-)
[20:18] <niemeyer> Chipaca: Sounds like a good plan
[20:18] <Chipaca> jdstrand— appreciated. I'll get to them in my morn.
[20:18] <jdstrand> Chipaca: goodnight! I feel like I can talk fairly intelligently about this now. hopefully it won't atrophy by morning :)
[20:18] <Chipaca> jdstrand— will you want to once-over it once I do so, or are you ok with it landing?
[20:19] <jdstrand> Chipaca: I said 'request changes', so feel free to ping me when you do the changes and I'll go through it real quick
[20:19] <Chipaca> ah ok
[20:19] <niemeyer> Odd_Bloke: I suggest asking the question in the forum under the store category.. I know where we want to be, but I don't know what the status of account names is just now
[20:21] <Chipaca> jdstrand— and yes \foo in bash is a way to make sure you call the builtin (or external program) and not a function or alias
[20:21] <jdstrand> Chipaca: a comment stating that would be cool :)
[20:22] <jdstrand> Chipaca: do you sense a theme?
[20:22] <Chipaca> jdstrand— no
[20:22] <Chipaca> no theme sensing
[20:22] <jdstrand> hehe
[20:22]  * jdstrand is big on commenting
[20:22]  * Chipaca sucks at commenting almost as badly as he sucks at naming things
[20:22] <jdstrand> Chipaca: you've won some sort of best/worst of with etelpmoc.sh
[20:23] <Chipaca> \o/ <- winning!
[20:23] <jdstrand> I mean it is brilliantly terrible
[20:23] <jdstrand> it's perfect, yet horrible
[20:23] <jdstrand> please take that as a compliment :)
[20:28] <pedronis> niemeyer: thanks, should we rename refresh-aliases to refresh-auto-aliases?
[20:47] <niemeyer> pedronis: I think refresh-aliases is fine
[20:47] <niemeyer> pedronis: It may end up growing up some activity about manual aliases, even if it doesn't today
[20:50] <pedronis> ok
[21:35] <pedronis> ok, snapd#3220 needs a 2nd review and then we just have #3245 which after the former should be small and hopefully uncontroversial
[21:35] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[21:35]  * pedronis -> rest