=== elfgoh_ is now known as elfgoh [01:59] PR snapd#3205 closed: tests: add openvswitch interface spread test === chihchun_afk is now known as chihchun === cpaelzer_ is now known as cpaelzer [05:56] PR snapcraft#1282 opened: parts: remove the deprecated snap keyword from the internal parts representation [06:18] PR snapd#3138 closed: interfaces/mount: add Change.Perform [06:39] mvo_: morning, I need 2nd reviews of snapd#3192 and snapd#3239 [06:39] PR snapd#3192: many: implement snap unalias (aliases v2) [06:39] PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) [06:51] pedronis: thank, I have a look === JanC is now known as Guest5365 === JanC_ is now known as JanC [07:18] morning [07:30] good morning [07:30] mvo_: sorry for being late, I will focus on code reviews the whole day [07:31] zyga: hey, good morning. and no worries [07:34] 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] + dpkg --purge --force-depends snapd [07:35] dpkg: error processing package snapd (--purge): [07:37] zyga: I have not seen this error yet. pre-removal script returned 1 is really not helpful :( [07:38] mvo_: are those logged in any dpkg specific log file? [07:39] zyga: unfortunately not, the best info we have is "Job for snapd.service canceled." right before that [08:12] PR snapd#3197 closed: store: retry on connection reset too [08:20] PR snapd#3192 closed: many: implement snap unalias (aliases v2) [08:24] mvo_: static checks are failing on the refresh scheduling branch, and thanks for bearing with me about naming stuff [08:25] mvo_: also thanks for the other review [08:28] PR snapd#3240 opened: snap: add `snap refresh --time` option [08:28] pedronis: thank, looking [08:29] thanks even [08:37] 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] (or mvo_ ^^) [08:37] ogra_: looking [08:38] my github token is in poland so... fingers crossed [08:38] I have [08:38] ah, no [08:38] whee [08:38] You require admin rights to enable these repositories [08:38] :( [08:38] so that's gustavo or mvo perhaps [08:38] ogra_: I can not [08:38] or JamieBennett [08:38] it's pretty terrible that we don't even know who controls this apart from gustavo [08:39] zyga: I do not have admin rights there, I would defer to niemeyer [08:39] yes, spoiled by LP team management :) [08:39] ok, then i'll wait [08:39] thanks for checking JamieBennett [08:40] Chipaca: hi, maybe you can give a 2nd review to snapd#3239 (it's smallish and has already a +1) [08:40] PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) [08:41] * zyga is sorry about the lack of reviews [08:42] I'll spend my whole day reading code, no writing today [08:42] pedronis— perhaps I could [08:44] hey, seeing suddenly each and ever project switch to meson ... do we have support for that in snapcraft yet [08:44] *every [08:44] seems to be the next famous thing [08:44] http://mesonbuild.com/ ? [08:44] yep [08:45] Chipaca: thx [08:48] 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] pedronis: great, thank you [08:56] sigh,. what changed in the store ... the core builds constantly fail uploading with a proxy error [08:57] 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] cjwatson, did anything change over night ? i did hit the retry button 3 times for 5 snaps already, all fail [08:58] cjwatson, https://launchpad.net/~snappy-dev/+snap/core/+build/34833 or https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/34849 [08:59] mvo_: maybe `snap refresh --query` [08:59] * zyga reads that branch now [08:59] mvo_— ( show refresh schedule information | list packages that would be refreshed ) but do not perform a refresh ? [09:00] zyga— --query is weird, as you might expect its output to be that of --list [09:02] Chipaca: hmm, I agree [09:02] Chipaca: but --time is also weird in this context [09:02] zyga— remove all flags, add a single --dwim [09:02] Chipaca: I don't like it when "command --option" does something that more feels like "command subcommand" [09:02] Chipaca: --dwim? [09:02] dowhatimean? [09:02] * Chipaca nods [09:03] no, wait, blue WHAAAM [09:03] Chipaca: works for me, thanks for the suggestion! [09:07] mvo_— and i notice its prereq is gtg once green [09:07] Chipaca: indeed :) === chihchun is now known as chihchun_afk [09:16] mvo_: added one question about 3240 === chihchun_afk is now known as chihchun [09:18] notice that we already have snap refresh ---list [09:18] so that boat has sailed I think [09:19] yes, it is somewhat unavoidable, and I suspect nobody is really bothered by this (just software being software) [09:22] zyga: uh, nice catch! thank yu [09:23] mvo_: ah, I wasn't sure if this is some deliberate design! [09:23] mvo_, added a test to #3235 [09:23] mvo_: I'll read the rest (I oftne start from the bottom for no other reason than that it feels less daunting) :-) [09:24] ogra_: 502 means a problem within click-updown [09:24] ogra_: so if something changed it was on the store side, not LP [09:24] pstolowski: \o/ [09:29] ogra_: raised on the OLS channel since our failure rate has definitely got a lot worse in the last day or two [09:30] 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] zyga: did you rebase my branch? [09:32] zyga: the interesting thing is that I don't have tests/main/interfaces-openvswitch in my tree [09:32] morphis: no, I commented on what is in the PR [09:32] morphis: I didn't even clone it locally [09:32] morphis: merge master, fix the test and push [09:33] morphis: maybe travis tests the merged branch as well as the branch itself [09:35] zyga: done [09:35] "The job exceeded the maximum time limit for jobs, and has been terminated." is a bit frustrating :/ [09:35] yes, indeed [09:36] especially since travis is there only to hand-hold spread and its army of VMs [09:37] 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] (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] jdstrand: can you try use snapcraft-preload from this branch https://github.com/3v1n0/snapcraft-preload/tree/string-appends-fixes ? [09:46] it should fix the issues you were facing... [09:54] jdstrand: applying http://pastebin.ubuntu.com/24459277/ should be enough [09:55] hello. How to "unpublish" snap from all channels? [09:56] jacekn: "snapcraft close" I think [09:58] zyga: hmm ok, I may have to log in to do that (I was trying to avoid that) [09:59] jacekn: I suspect you can do that from the web UI too [09:59] jacekn: just not sure as I didn't try [10:00] zyga: does not look like it, when I untick all channels web UI says "This field is required" [10:02] 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] Chipaca, added 1 comment to your tab-completion [10:06] woo [10:07] chances are it's nonsense ;) [10:07] oh the _other_ tab completion one [10:07] :-) [10:07] (my comment, not your PR) [10:08] good question about empty :. Let me check. [10:09] cjwatson, well, the failure seems pretty reliable now ... in case anyone needs reproducers ... let me know ... [10:10] pstolowski: made a small comment in one of your interface hooks PRs [10:10] mvo_: added one more comment to https://github.com/snapcore/snapd/pull/3240 [10:10] PR snapd#3240: snap: add `snap refresh --time` option [10:10] pstolowski— basically parts[0] would be "", meaning we'll suggest any and all plugs :-( [10:10] pedronis, yes, just saw them thanks! [10:10] Chipaca, ha! [10:11] pstolowski— i'll confirm this empirically in a moment [10:12] Chipaca, should be easy to handle and make "" into "core" I guess, and let all the remaining logic do the job? [10:12] zyga: aha, another nice catch, thank you again [10:12] * zyga is super slow with reviews, needs to switch into review mood [10:16] pstolowski— ah, we don't offer everything, we offer nothing instead [10:16] slightly better [10:16] still, I'll force it to 'core' if empty [10:20] Chipaca, :) [10:22] * zyga breaks for some lunch and coffee [10:22] brb [10:23] Mornings [10:25] hey niemeyer, good morning! [10:27] hey niemeyer [10:31] PR snapd#3241 opened: snap: make `snap prepare-image` read .assert files for local snaps [10:32] PR snapd#2895 closed: client,cmd/snap: first pass at client messaging around modes [10:35] 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] pstolowski— addressed [10:37] 👍👍 [10:37] mvo_, pstolowski: Mornings! [10:38] mvo_: Seeing the recent change in snapd#2833, isn't there a test missing there? [10:38] PR snapd#2833: many: allow core refresh.schedule setting [10:38] jacekn— looks like a bug in prometheus indeed [10:38] jacekn— it's importing "context" from the wrong place [10:38] jacekn— that is an error from Go itself [10:39] jacekn— “package context: unrecognized import path "context" (import path does not begin with hostname)” i mean [10:39] it is a strange one though [10:42] PR snapd#3239 closed: many: show alias changes on snap alias/unalias (aliases v2) [10:42] 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] jacekn— it shouldn't, but it might [10:43] jacekn— give me a bit [10:44] niemeyer: anything left to get https://github.com/snapcore/spread-images/pull/1 merged? [10:44] PR spread-images#1: Add debian-unstable-64 base image [10:47] jacekn— what happens if you run that by hand, adding a -v to it? [10:49] Chipaca: it will fail I'm pretty sure because of missing GO env variables but I can try setting it up [10:51] niemeyer: hi, snapd#3237 can be reviewed again [10:51] PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup [10:52] pstolowski— hm, re-reading your comment, is it only ever :, never :? [10:56] Chipaca, I think so yes, would need to check Resolve* methods again [10:57] then i've got this wrong. amending. [10:58] Chipaca, please double check in repo.go [10:58] morphis: It's in [10:58] niemeyer: thanks [11:00] morphis: np [11:00] pedronis: Looking [11:00] niemeyer: another one for fedora is coming soon [11:01] pstolowski— in connect, empty means core only for the slot; in disconnect, it's either [11:02] PR snapcraft#1281 closed: core: switch to version git [11:09] 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] popey— i'll give him a shout to have him comment in there when he's around [11:10] Chipaca, right [11:11] Chipaca: thanks [11:15] pedronis: LGTM [11:15] niemeyer: thx === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:17] niemeyer, could you please enable travis for the core-build branch ? [11:17] ogra_: Done [11:17] thanks :) [11:18] Any time [11:18] zyga— hey [11:19] zyga— we're seeing more and more panics in the wild with the nil map [11:19] zyga— what is the status of that fix? [11:19] Chipaca: let me see [11:19] zyga— and can you comment about it on https://forum.snapcraft.io/t/broken-snap-braking-snapd/401 [11:19] Chipaca: yes [11:20] Chipaca: so the fix was merged by mvo long ago [11:20] Chipaca: we should also review and merge https://github.com/snapcore/snapd/pull/3208 to stay proactive for future issues [11:20] PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots [11:21] Chipaca: done [11:22] zyga— what is the snap doing wrong such that it breaks snapd? [11:23] Chipaca: just make a snap that has a "content" plug [11:23] Chipaca: without anything else [11:24] 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] PR snapd#3242 opened: tests: tweak time for econnreset test a bit more [11:24] Chipaca: but then whaam, attr is a nil map [11:24] Chipaca: I fixed that quite some time ago [11:24] 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] ahayzen: aha, when you already have that snap installed [11:25] ahayzen: I'm not sure actually [11:25] ahayzen: (eventually, like in two weeks) the change will garbage collect and won't run anymore [11:25] ahayzen: but I assume you meant for something better [11:25] 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] zyga, right, yeah i was looking for a way to 'fix' my system :-) anyway i can force the garbage collect or something? [11:26] Chipaca, mvo_: ^ any ideas? [11:26] * zyga has none apart from moving the needle of time a little bit forward [11:27] :-) [11:27] mvo_: perhaps curious input to the repair assertion [11:28] morphis: Do you have the fixes for the PR we discussed lined up? [11:28] 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] morphis: Want to include in the board [11:28] niemeyer: not yet [11:29] morphis: Okay, can you put that up in the pipeline so we don't risk releasing without the fixes? [11:32] Chipaca: mvo_: snapd#3237 needs a 2nd review [11:32] PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup [11:33] PR snapd#3208 closed: interfaces: recover panics when sanitizing plugs and slots [11:40] 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] error: sha3-384 mismatch for "pc-kernel": got 7873b5723739ece72e102f518ba4c3e4c8e656ea2f64f80759a4fcda0e0737ca1d13459ac97221a4a059fce357a2ca46 but expected 33d383ce8f59a0cc43905da29208d6152d8204dd7a90500d4dfd2f1586d440359796374f17778a88948561c002cc563a [11:40] Does anyone know if there are any outages/issues that could cause this? [11:40] sil2100, i wonder if thats related to the upload errors i see for the core snaps (proxy error) [11:41] sil2100: Can you please open a topic in the forum under the store category? [11:42] sil2100: Actually, I suspect we even already have a topic for that particular error [12:00] pstolowski— pushed a thing to handle : in connect better [12:02] sil2100— i'm willing to bet one of those hashes is the hash of '503 Service Unavailable' [12:02] sil2100— or sth like that [12:03] 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] sits there since ages [12:09] hah ! [12:10] complaining here helps it seems :) [12:10] ogra_, hitting it with a hammer helps too :) [12:10] * Son_Goku hates Travis CI [12:10] well, once it runs it is fine [12:11] PR snapcraft#1283 opened: core: predetermine the magic path when a snap [12:14] Chipaca, thanks [12:15] ogra_: we were pinged here [12:15] yeah [12:15] but there's a forum topic [12:16] yeah [12:16] so any suggestion will go there [12:46] question, does build.snapcraft.io build for several architectures? [12:46] armhf and amd64 i think [12:48] ogra_, thanks [12:57] jdstrand— thinking of changing the cat in complete.sh to \grep -v '[[:cntrl:];?*{}]' [12:58] poor cat [12:59] Chipaca: does [[:cntrl:]] in any insane way depend on locale? [12:59] (just checking) [12:59] nope [13:00] zyga— if it does, it's not insane :-) [13:00] * zyga reads the aliases branch [13:00] Chipaca: in nort korea space is a control character because they have little space [13:00] zyga— and way too much control [13:06] Chipaca: that seems like a reasonable start (I've not started looking at the branch yet today) [13:06] again yet... [13:07] 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] I'll be getting back to this btw. just tending to review tools updates for the bad snap issue [13:09] np [13:14] 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] PR snapd#2833 closed: many: allow core refresh.schedule setting [13:32] mvo_: yay ^ ! [13:36] 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? === chihchun is now known as chihchun_afk [13:39] pedronis: \o/ indeed [13:41] fgimenez: hm, that is curious [13:41] * mvo_ looks [13:43] zyga, jdstrand, why am i getting “hsearch_r failed” for things that used to work? [13:44] 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] 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] zyga: sounds like out of sync snap-confine vs sepcomp bits in snapd [13:48] sorry [13:48] Chipaca: ^ [13:48] * in/from [13:49] Chipaca: we should have ways to avoid that but if you running things manually I suppose it can happen [13:54] PR snapd#3171 closed: snapstate: normalize gadget defaults [13:56] Bug #1619154 changed: Cannot adjust systemd service definition [14:07] a'ight [14:07] jdstrand— I added https://github.com/snapcore/snapd/pull/3150/commits/6dcbcded52192f57dedb980872e6ad22a84a93e8 and all tests passed just the same [14:07] PR snapd#3150: In-snap bash tab completion [14:21] 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] Chipaca: nice [14:53] mvo_: no, working on them now [14:53] mvo_: had to leave for a fire accident as I am a fire fighter; already started with them earlier today [14:53] mvo_: sorry for the delay [14:54] another attempt of blowing up your city hall ? [14:56] ogra_: not really .. we already had a bigger ship on fire on tuesday really early in the morning .. [14:56] and today somebody decided to get light his shed :-) [14:57] oh my [14:57] * niemeyer will feel safer with morphis around from now on [14:58] :-) [14:58] * ogra_ makes a note to not move to verden if not owning fireproof underwear [14:58] PR snapd#3243 opened: cmd/snap-confine: don't use apparmor if it is disabled on boot [14:58] ogra_: hehe, however I guess the rate of fire accidents is quite similar anywhere else too :-) [14:59] yeah [14:59] we have about 20-30 alarms per year were only ~5 are real fires [14:59] the guy trying to blow up the city hall was unique though ... enough to make the news :) [14:59] jdstrand: I made a small branch to fix a bug that was uncovered by CE [14:59] jdstrand: added you as a reviewer [15:01] ogra_: yeah .. [15:01] crazy germans ... :) [15:01] ogra_: http://www.nonstopnews.de/galerie/25062 is what we had yesterday [15:02] oh man [15:03] Lunch! [15:04] Chipaca: mvo_: I need a 2nd review of snapd#3237 [15:04] PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup [15:04] on it [15:04] Chipaca: it's a small one [15:07] morphis: no worries, just wanted to make a friendly offer for help :) [15:07] mvo_: thanks! [15:08] pedronis: I have a look as well [15:09] pedronis— what's the “! snap aliases | MATCH ... ” thing? [15:10] pedronis— more exactly, what's the start-command-with-bang thing [15:10] Chipaca: it negates the whole pipeline, it succeed if the pipeline files [15:10] s/files/fails/ [15:11] TIL [15:11] it's an obscure bit [15:11] admittedly [15:11] Chipaca: man bash and search pipelines, there's option [!] bit in there [15:12] will do [15:14] Chipaca: thx [15:14] PR snapd#3237 closed: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup [15:17] pedronis: 3220 has test failures that look unrelated (mirror on linode issues?). do you mind if I restart the test? [15:18] mvo_: I'm about to push a merged anyway [15:18] pedronis: even better [15:20] not that it will make it smaller, it's big mostly because of tests [15:22] pedronis: ok :) [15:22] I mean it's main prereq was already merged [15:25] mvo_: pushed now [15:27] 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] PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot [15:28] 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] mvo_: yes but this is just a bugfix, not related to any re-architecture [15:29] mvo_: it was supposed to work like that but this was missed [15:29] niemeyer, mvo_: https://github.com/snapcore/snapd/pull/3244 [15:29] PR snapd#3244: many: fix review comments from PR #3177 [15:29]