[00:53] PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369 [05:11] morning [06:20] good morning [06:20] mborzecki: hey :) [06:20] zyga: hey hey [06:20] I walked my daughter to school today [06:20] it's so misty I was afraid of letting her go by herself [06:20] how are you doing? [06:20] and it's cold too [06:21] glad i swapped the tyres in the car on friday [06:22] yeah, scarfs, hand gloves and caps [06:25] * zyga reads some news about the election yesterday [06:25] then back to patches [06:28] zyga: heh, elections, the situation in lodz is 'stable' :) [06:37] mborzecki: so nothing changed? [06:38] zyga: yeah, exit polls suggest the same president as before with 70+% votes [06:40] I signed up to Apple Music yesterday as a trial to show my dad how it works [06:40] I'm in love :) it's fantastic [06:41] zyga: btw. https://status.github.com/messages [06:41] DRM free music, everything in iTunes seems to be available, 19zł a month [06:41] oh [06:41] github is down? I'm reading reviews now and it's ok so far [06:41] woah [06:41] data corruption [06:41] well [06:41] monday :) [06:42] zyga: appl music? basically like spotify? [06:42] no [06:43] it's like iTunes (you buy music, it's DRM free on your disk) [06:43] all you can eat [06:43] you can stream but you can also just download and keep offline forever [06:43] I usually spend 20-50 a month per music [06:43] so this is much cheaper [06:44] there's also a family plan but I didn't look at that yet, for up to six people [06:44] zyga: download as some format and keep forever elsewhere or are you forced to use the app? [06:44] it's just mp4 [06:44] normal format [06:44] one sec [06:56] zyga: heh, have you tried doing reviews today? [06:56] Good morning everyone [06:56] well, I'm trying now [06:56] hey dot-tobias :-) [06:56] mborzecki: what are you observing? [06:56] zyga: ui getting stuc waiting for response when adding comemnts [07:00] zyga: and got a unicorn erorr page :P [07:00] haha and the review was not sent [07:00] omg [07:02] so much for reviews [07:06] re [07:06] that's not encouraging :/ [07:08] quite possibly a dumb question, but … can I assume that the “last modified” date for edge images (http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/) can be completely ignored and the build is in fact “daily”? [07:08] hmmm, good question dot-tobias [07:08] it looks fishy to me [07:08] I think it's not the latest one [07:09] morning [07:10] pstolowski: hey [07:50] PR snapcraft#2378 opened: Release chagelog for 3.0 [07:51] mo'in [07:51] oi [07:52] mborzecki: https://pastebin.ubuntu.com/p/B6QY2h3gwB/ [07:52] Chipaca: nice [07:53] I wish we had a "can run things from such-n-such snap" interface [07:53] PR snapcraft#2378 closed: Release chagelog for 3.0 [07:53] then taht wouldn't need classic :-) [07:53] Chipaca: we could [07:53] we have the capability [07:53] mborzecki: if you want to push it feel free; otherwise i could [07:54] zyga: it's like a content interface but different [07:54] haha [07:54] yes [07:54] not content ;) [07:55] it'd be an interface where we'd have a set of snap commands that a given snap can run [07:55] enforced at snap-confine level, I suspect [07:55] mborzecki: otoh we could also package shellcheck into the snap ourselves [07:55] mborzecki: or offer spread-shellcheck upstream [07:55] mborzecki: the latter needs a bit of paperwork [07:56] Chipaca: shellcheck gets frequent updates, at least here on arch, it's probably upstream pushing new changes [07:58] on a completely unrelated subject: WTH https://i.imgur.com/YcjvITL.png [07:59] Chipaca: promoted! [07:59] WAT [07:59] exactly [07:59] somebody paid money to do that [07:59] * zyga puts on pants [07:59] must be important [08:01] zyga: maybe it's a US/UK thing [08:01] Chipaca: no pants? [08:01] mborzecki: https://en.wiktionary.org/wiki/pants [08:01] mborzecki: look at the pics [08:05] PR snapcraft#2378 opened: Release chagelog for 3.0 [08:06] hmmm [08:06] github is indeed wonky [08:06] oh, nice, github's databases are eventually inconsistent right now [08:06] chipaca's critical PR is marked as approved [08:06] but if you click on it, it is not, no comment history [08:07] https://mobile.twitter.com/TheRegister/status/1054267789232431104 [08:07] the pic is very representative of IS work [08:07] not [08:08] Chipaca: did you get my review of https://github.com/snapcore/snapd/pull/6026 ? when i go to the PR there's like 3 reviews pending (?) [08:08] well, it's the reg [08:08] PR #6026: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [08:08] mborzecki: i got yours [08:08] mborzecki: nobody else's yet [08:08] PR snapcraft#2378 closed: Release chagelog for 3.0 [08:08] Chipaca: well i got a unicorn in return :P [08:08] mborzecki: but as above, github's hard drive is full [08:09] unicorns [08:09] unicorns everywhere [08:10] zyga: https://www.youtube.com/watch?v=DX1iplQQJTo&feature=youtu.be&t=90 [08:11] https://imgflip.com/i/2knjpg [08:12] I guess the windows upgrade went well at GitHub today [08:24] GH reviews are still in read only mode [08:25] zyga: at least one got through :P [08:26] oh? I keep try to send a trivial comment to see what happens [08:33] haha got zyga's review email, but the reviews are not visible https://github.com/snapcore/snapd/pull/6026 [08:33] PR #6026: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [08:34] well I got mborzecki 's review twice [08:34] so there [08:34] hahah [08:34] zyga: and i just got a review from you as well [08:34] oh and in zyga's review the comment was doubled [08:34] yes [08:35] zyga: so, depends how you look at it :-) that was the thing that triggered the panic, so that's the immediate cause [08:35] zyga: but before that, cmdTry was different from other snap ops in that it didn't pass the error to errorToCmdMessage [08:35] https://blog.github.com/2018-10-21-october21-incident-report/ [08:35] zyga: so that's the deeper cause [08:36] zyga: because there _is_ an opts for this error, it's just not in main [08:36] zyga: which one of those causes is the crux, i guess it depends on how you look at it? [08:44] mmm, I see [08:45] I made exceptionally hot coffee [08:45] my hands are freezing here [08:49] * Chipaca hands zyga a "crux of the matter" trophy [08:49] (just got another few emails) [08:49] hahah [08:49] it's still being published? [08:50] I see them now [08:51] zyga: github liked you comment so much it keep on sending it ;) [08:51] haha [08:51] eventually it will stop ;-) [08:51] haha [09:22] is it just me or are none of the 2 reviews posted in https://github.com/snapcore/snapd/pull/6026 visible? [09:22] PR #6026: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [09:32] zyga: hey! Did you have a moment to check the dragonboard image? [09:32] yes! [09:32] let's do it :) [09:32] is the one from last week good? [09:32] or shall I pick lastest [09:33] http://cdimage.ubuntu.com/ubuntu-core/18/pending/ubuntu-core-18-arm64+snapdragon.img.xz <- latest is always the best ;) [09:33] Oh, no mvo today? [09:34] sil2100: no, sprinting [09:34] sil2100: flashing [09:34] zyga: do you maybe know when's the ETA for a stable-channel release of snapd? [09:34] no idea [09:34] maybe mid sprint? [09:35] but really no idea [09:36] sil2100: are you talking about 2.36? [09:37] Chipaca: I'm talking about the snapd snap [09:37] Chipaca: we don't have any version of it in stable from what I can see at least [09:37] ah [09:37] ok :-) [09:37] no idea [10:01] Chipaca: shall we try posting the reviews again? [10:02] mborzecki: zyga: please [10:02] * Chipaca afk for a bit [10:02] yep [10:02] bah [10:02] 10:47 British Summer TimeWe continue to monitor restores which are taking longer than anticipated. We estimate they will be caught up in an hour and a half. [10:02] so maybe let's check after lunch [10:02] zyga: mborzecki ^ [10:03] (that was 15 minutes ago) [10:03] too late, already clicked :P [10:03] aand unicorn! [10:09] unicorn days [10:10] I tried to fork a repo just now [10:10] 404 and errors [10:15] sil2100: it works [10:16] https://www.irccloud.com/pastebin/bPMblg1d/ [10:16] dragon board is operational :) [10:16] 11:47 CESTWe continue to monitor restores which are taking longer than anticipated. We estimate they will be caught up in an hour and a half. [10:16] from status.github.com [10:17] Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15 [10:17] PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30 [10:19] Let's SHIP IT [10:20] PR core-build#11 closed: remove cruft from the writable-paths [10:20] PR core-build#22 closed: unit testing for sync_dir() [10:20] PR core-build#26 closed: move most of the customization into the core snap build [10:20] Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15 [10:20] PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30 [10:21] PR core-build#11 opened: remove cruft from the writable-paths [10:21] PR core-build#22 opened: unit testing for sync_dir() [10:21] PR core-build#26 opened: move most of the customization into the core snap build [10:21] everything is broken :) [10:22] apparently ceph fails universally ;) [10:23] Chipaca finally figured Friday's issue greyback hit [10:23] PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369 [10:24] pstolowski: oh nice! [10:24] pstolowski: what was it? [10:25] mborzecki: a commit i introduced on sep 7, to conflict & retry on discard-snap. I missed the fact that discard-snap is created sometimes by install as well to remove inactive revision. so, auto-refresh conflicts with itself [10:26] mborzecki: in this case it tries to refresh lxd and also schedules removal of old inactive revision of lxd [10:26] pstolowski: nice [10:26] PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369 [10:27] pstolowski: sounds like a scenario we'd like to have a test for [10:27] mborzecki: yes, definately. i added a test for conflict, but no we have a case where we shouldn't conflict [10:27] *now we have [10:28] great [10:48] sil2100: there are some wifi errors on screen after a while [10:49] Oct 22 10:40:55 localhost kernel: wcn36xx: ERROR hal_remove_bsskey response failed err=6 [10:59] zyga: I think we need to poke the kernel team about those [11:00] where shall I report those? [11:06] any idea if it's possible to do spread -repeat= but directly in task.yaml? [11:10] heh after/before test is fiddly [11:18] mborzecki: no idea [11:18] count: 10? [11:21] zyga: doesn't appear to be anything like that [11:44] :/ [11:44] pstolowski: sounds like another critical 2.36 pr [11:44] how's our favourite unicorn factory? [11:44] Chipaca: sure, i'm in touch with mvo on that [11:44] and fix is in progress [11:45] pstolowski: 👍 [11:45] or maybe 🖒 [11:45] ¯\_(ツ)_/¯ [11:47] can i get 2nd reviews on https://github.com/snapcore/snapd/pull/6023 ? [11:47] PR #6023: overlord/snapstate, snap, wrappers: start services in the right order during install [11:50] off to pick up the kids [11:57] FYI, latest GitHub status [11:57] The majority of restore processes have completed. We anticipate all data stores will be fully consistent within the next hour. [11:57] I just pushed a patch without erorrs [12:01] I take that back [12:01] comments I added just disappeared [12:06] comment showed up and disappeared again [12:06] fun [12:11] zyga: were any of your reviews of 6026 a +1? [12:11] Chipaca: let me look [12:12] zyga: all I see are a bunch of "crux of the issue" comments :-) [12:12] was wondering if I should merge it [12:12] let me try to give it a +1 [12:12] my changes elsewhere on GH just go away after I reload [12:12] Hi, is there some interface that allows me to change the scaling_governor on the core? [12:13] sborovkov: let me look [12:13] Chipaca: green, merge it [12:13] zyga: ooh i see your +1 [12:13] sborovkov: no, I'm afraid not [12:13] would that be cpu_control, or do we need power_control? [12:14] zyga, is it something that's possible to add? basically we are running on rpis. we want to change the scaling governor to performance. Otherwise while it winds up video performance goes down [12:14] cpu-control sounds about right [12:14] and it goes down by a lot [12:14] yeah, I agree with ogra [12:14] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:14] feels like a reasonable tweak [12:14] sborovkov, thats weird, the ondemand governor sshould surely cope [12:15] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:15] ogra, it does work properly after some time. But when we have a fresh run - the times it takes us to render a frame goes upo from 32 to 64 ms for first 20 seconds and so [12:15] ogra: it takes about a second to ramp things up though, doesn't it? [12:15] (while we should add thiss to the interface, you should definitely not see much differenec in system behaviour when switching governors ... just that it doesnt clock down after it is done with processing) [12:15] that looks so bad on the customer screens [12:15] oh wow that's more than i'd expect [12:15] basically the timings were 2 times worse [12:16] once we enabled performance governor we never saw anything like that [12:16] sborovkov: can you add this to your snap [12:16] wow, is that with accelerated graphics or plain framebuffer? [12:16] and show me the --devmode denial [12:16] I can make a modification to the interface [12:16] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:16] i definitely dont see that with the kms driver [12:17] aaaaah now my pr is half-merged [12:17] non-kms indeed means you fully utilize the CPU and completely leave the GPU alone [12:17] Chipaca: what? [12:17] zyga, github fun today :) [12:17] wow, [12:17] yeah [12:17] I think today is not a good GH day [12:17] i actually learned their 404 pick is interactive ! [12:17] *pic [12:18] i never stayed long enough on it to even notice [12:18] but if you wiggle the mouse it makes nice layer shifting effects [12:18] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:18] alright I will need to build a devmode snap though or try it from some other one guys, I will write back when I do that. ogra what do you mean accelerated graphics or plain framebuffer? we do use h/w decoder. and yeah showing stuff with qt's qml, so it's using framebuffer [12:19] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:20] sborovkov, i mean the kms drm driver when you set "dtoverlay=vc4-kms-v3d" in config.txt (this turns on accelerated GLES ) [12:21] that's not enabled at the moment [12:21] it was breaking our qt app previously on the core [12:21] I should try to see if it works now actually [12:22] well, probably not without a compositor ... not sure [12:23] * ogra curses about this silly x11 restriction that forces you to add a .desktop file for a kiok app [12:23] *kiosk [12:23] re [12:23] * zyga turned on the heater [12:26] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:27] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:28] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:28] * Chipaca hugs mup [12:29] Pushing stuff to GH feels pointless now [12:29] the patches show up [12:29] the diff stays stale [12:29] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:29] zyga: let's move back to launchpad [12:29] mborzecki: anyway, I pushed trivial fixes to https://github.com/snapcore/snapd/pull/6010 [12:29] PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces [12:32] zyga: … or did you? [12:35] heh gh is the new single point of failure of modern software dev [12:36] pretty much that what we try to avoid when designing stuff ;) [12:37] mborzecki: wait until Microsoft moves GitHub to azure ;-) [12:38] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:38] 13h+ of outage [12:39] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:41] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:42] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:43] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:44] so does it make any sense to push stuff now or not? [12:47] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:49] mborzecki: probably not [12:49] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:49] ehh [12:49] damn [12:50] hmm 2018-10-22 14:50:23 Cannot allocate google:ubuntu-18.10-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-1810-cosmic-v20181002" on project "ubuntu-os-cloud-devel" [12:51] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:51] mborzecki: get master [12:51] mborzecki: that was fixed by the cachio late friday [12:51] ah ok [12:51] #6024 [12:51] PR #6024: tests: new cosmic image for spread tests on gce [12:52] you'd call that "saturday" [12:52] :-) [12:59] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [12:59] yeah, mup, thanks for reminding us [12:59] probably integration hooks firing as they restore the data [13:00] feels like starting an old card with water instead of gas [13:00] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:00] *cough* *cough* maybe this time it will wrok [13:00] lol [13:01] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:01] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:02] Chipaca: standup? [13:02] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:03] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:03] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:05] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:07] holly smokes GH, calm down [13:12] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:13] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:14] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:15] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:16] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:16] PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:17] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:18] https://media.ccc.de/v/ASG2018-173-libcapsule [13:18] I think mborzecki will find it interesting [13:18] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:19] zyga: thanks, will watch it [13:21] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:22] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:22] PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:23] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:24] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:26] looks like they are wiggling the cable at GH [13:27] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:29] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:30] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:31] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:31] PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:33] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:34] PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:41] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:42] mup really likes that PR [13:44] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:44] PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:46] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:47] Yeah, something is not quite right there [13:47] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:47] Hello all [13:47] hey [13:47] GH is broken for the last ~14 hours [13:48] Wow.. that's a long trail at status.github [13:48] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:48] trail of fire [13:49] * Chipaca pushes his luck [13:50] I get 404 on pull request pages now [13:50] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:50] I just created #6028 [13:50] at least you can play with your mouse with the 404 pic [13:50] … i'm feeling lucky [13:51] 404 [13:52] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:52] I've got an idea [13:53] * Chipaca considers taking the afternoon off [13:53] hah [13:53] I was thinking the same thing [13:53] I can go on a bike [13:53] it's bright still [13:53] and not like gh is now back and working [13:54] btw, all systems go has plenty of other interesting videos\ [13:54] I strongly recommend them [13:54] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:54] it's lovely out [13:55] I'll take the dog for a walk, then take the boys for a run, then go have tapas [13:55] enojy [13:55] I see *ZERO* problems with this plan [13:55] refresh [13:55] :-) [13:55] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [13:55] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:55] * Chipaca refreshes [13:55] self :) [13:55] zyga: still 404 [13:58] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [13:59] i think mup would appreciate if the snap command wouldnt panic on "snap try" ... [14:00] (just a guess though) [14:01] Chipaca, bug 1773174 ... did the fix got merged? there has been a recent comment which seems to suggest it's still an issue (but that has no details on version used, distro serie, etc) [14:01] Bug #1773174: Dutch lowercase translation warnings [14:01] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:02] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:03] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [14:03] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:04] seb128: the bug is in the translations in 18.10 [14:04] seb128: when the bug was reported we filed suggestions in the translations thing [14:05] ogra, it's not possible to set force_turbo to 1 right now on the rpi, right? [14:05] seb128: last time i checked, two had not been reviewed yet [14:05] i thought i'd answered that person though [14:05] * Chipaca writes it out again [14:06] Chipaca, so you rely on ubuntu langpacks or how does it work? [14:06] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:07] ogra: can you mute mup for a bit? [14:07] i keep on getting pinged :-) [14:07] i could ignore him [14:07] hm [14:07] seb128: translations in ubuntu come from langpacks yes [14:08] at least that's my understanding [14:08] but snapd is not Ubuntu specific [14:08] you can't rely on the Ubuntu langpacks to be providing your .mo [14:08] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:09] seb128: but the bug is about ubuntu [14:09] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:09] PR snapd#6028 opened: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly [14:09] ogra, would you accept PR that adds force_turbo to the list of rpi-config options. Looks like it's super critical for us to set it (most likely for others). Our rendering time when it's set goes from 32 to 16 ms per frame on the videos. [14:10] Chipaca, right, but I guess snapd source includes those translations, do you fix them directly there? [14:10] PR snapd#6028 closed: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly [14:10] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:11] seb128: we sync them from launchpad, and the last pull we noticed we weren't getting the fixes so we also fixed them there, yes [14:11] k, good, thx [14:13] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:14] seb128: a little bit more info and my thoughts on this just added to the bug [14:14] (i thought i'd done it over the weekend, but must've gotten side-tracked before hitting submit) [14:14] PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [14:14] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:15] * Chipaca adds mup to the ignore list [14:15] * Chipaca breathes in relief [14:16] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:17] Chipaca, thx [14:18] PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:20] PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [14:22] Chipaca, done (sorry, was in a call) ... a reminder later to unquieten it again would be nice (i might forget) [14:23] sborovkov, doesnt that void the warranty of the board ? (not sure, but i think i remember something like that) [14:23] nope [14:23] https://elinux.org/RPiconfig#force_turbo_mode [14:24] we can increase voltage and set this flag without voiding the warranty [14:26] sborovkov, well ... https://www.raspberrypi.org/forums/viewtopic.php?p=176865#p176865 [14:27] looks like manually setting the single values doent void it but using the force_turbo option doe [14:27] *doesnt/does [14:29] * cachio afk [14:29] I am confused about how you word it :) [14:29] https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md [14:29] this also states that setting only force_turbo is fine [14:29] and we don't really want to set anything else/overclock [14:30] force_turbo -> "Forces turbo mode frequencies even when the ARM cores are not busy. Enabling this may set the warranty bit if over_voltage_* is also set." [14:30] so you cant combine it with over_voltage_* stuff [14:30] right, but we are not going to do that [14:31] not sure if we offer any over_voltage settings in the core config ... if not, just adding force_turbo hould be fine [14:31] https://github.com/snapcore/core/blob/master/hooks/configure#L131 [14:31] no over voltage [14:31] well, its not a question about what you do but about us offering a setting where you can void the warranty without any warning :) [14:32] sure, but is not it the user responsibility https://github.com/snapcore/core/pull/98 [14:32] after all you could always add a hack that modifies the config.txt from the gadget ... since you own the gadget ... so we need to be sure what we offer for the general users is safe [14:33] ogra, no, core overwrites the config options [14:33] and can't users actually void warranty if they want :) it's their own device [14:33] sborovkov, i'd upvote the PR if GH weould not sshow me a 404 :) [14:34] they can ... but we dont really have a way to warn them if they just blindly call snap set [14:34] yeah I can't load it anymore [14:34] once GH is back to live i'll vote for it [14:34] hm, since this value is not in the list of supported options [14:34] if I set it in config.txt [14:34] core won't overwrite it, right? [14:34] yeah [14:35] it only touches stuff it knows [14:35] for everything else the gadget owner is the master [14:36] * zyga EODs and goes to take some time off from screens [14:37] ogra, the problem though is that if it's not in snapd we can't push out the change to the old users. even with gadget snap update [14:37] yep [14:37] i know :) ... so let get that change in [14:37] *letss [14:37] geez ! ... i hate my "S" key [14:38] (50% of the time it doesnt work, when it works it duplicates the char) [14:38] * Chipaca EODs as well [14:38] * Chipaca puts 20 "S" keys in the mail for ogra [14:38] haha [14:39] i really dont get how i manage to kill every keyboard within a year ... i had a model-M for 10 year that never had issues ... [14:39] *yearss [14:40] (GRRR) [14:40] ogra: remap the s to the z and viceversa [14:40] ogra: zuddenly you'll be zuper zmart [14:41] * Chipaca runs away [14:41] ogra, at least you have one keyboard. on my laptop I had US keyboard. When I went for the battety replacement (on warranty_ they replaced it with a Russian keyboard where enter key is completely diffrent. [14:43] i have like 20 keyboards ... each with a different broken key though :) [14:44] and they told me that it's my problem that I don't like it... Nevermind that they sold me laptop with the US layout. [14:44] i just need to combine them into a single one one day [14:44] luckily my laptop kbd still fully works [14:45] but i prefer a proper mechanical keyboard with clicky switches and all [14:55] zyga: 6017 needs you re-review [15:43] Ack [15:45] pstolowski: can you reply to https://github.com/snapcore/snapd/pull/6017/files#r226451342 [15:46] zyga: ah, thanks, got confused. applied. [15:47] pstolowski: approved now [15:51] thanks [15:55] cachio: ping [16:06] Hey there pstolowski, do you know if we have any docs about `assumes`? [16:06] kyrofa: no, degville may know? [16:06] kyrofa: and hi btw :) [16:08] kyrofa / pstolowski: I've not seen any, actually. [16:09] Alright, thanks guys-- I'll experiment! [16:13] kyrofa: please document your findings ;) [16:14] pstolowski, overlord/snapstate/check_snap.go [16:15] It seems one can rely on both snapd versions as well as specific features, but that set of features has long languished [16:15] yeah i remember hearing about that, never used it nor seen in action [16:16] There also at first glance seems to be no way to list the features supported by your version of snapd [16:16] kyrofa: might be a good forum topic [16:17] I've never used it/seen it used either, but we're about to start using command-chain in snapcraft so we've started thinking about adding an assumes to essentially every snap. I'm getting increasingly nervous using a feature that no one uses though :P [16:22] pstolowski, mvo is it too late to get a PR adding a feature to the featureset into 2.36? [16:22] kyrofa: he is at the sprint in us this week [16:22] Ah yes, because zyga can't I suppose [16:23] indeed [16:29] pstolowski, what do YOU think about that? Not sure what your release process is [16:31] kyrofa: depends on the complexity/risk i suppose, at this moment we're trying to land fixes for last-minute critical release blockers found in last couple of days [16:33] pstolowski, hey [16:33] Well, I'll propose it anyway, would be nice to get it into the actual release that contains the feature, but will still be useful if not [16:33] cachio: hey, sent you an email [16:35] pstolowski, ok, I'll play with the nested vm to see if I can make the serial usb adapter visible [16:36] pstolowski, I'll ping you once I have some news [16:36] cachio: ok, please reply to the email if you have something, i'm about eod [16:38] pstolowski, sure [16:39] kyrofa: sure, do that === pstolowski is now known as pstolowski|afk [16:40] If github will actually work... [16:44] pstolowski|afk, https://github.com/snapcore/snapd/pull/6029, easiest review of your life [16:46] kyrofa: ah, that looks simple and very safe indeed! [16:52] degville, by the way, how would you suggest handling documentation changes for an upcoming release? Wait until it's released and then update everything? [16:58] kyrofa: I'd right the documentation anyway, if feasible, with a caveat or 'engineering' blockquote as a caveat. [16:58] kyrofa: we could then remove the caveat on release, and add any new documentation to the outline (I wouldn't add them to the outline before features are available in stable). [16:59] s/right/write <- terrible! [16:59] degville, what if it was an update to existing docs? [16:59] (something already in the outline) [17:00] kyrofa: the current plan is to have both side-by-side, with a clear note saying "This is for version/upcoming version." [17:00] Alrighty, thanks! [17:01] kyrofa: np. but really, whatever's easier to work with. If you wanted to create a separate post, that would work too. I could then work it into the docs when it's ready to go. [17:31] 6022 needs a second review - should be trivial :) [17:31] and good morning [18:06] Nooo, webhooks are down again [18:56] sergiusens: Uh, so do we have to finish the launchpad-buildd rollout as an emergency? (bug 1791201) [19:02] cjwatson, I'm not sure what you've discussed in the past, but note that's only for bases [19:04] kyrofa: Doesn't the new version of snapcraft significantly change behaviour if SNAPCRAFT_BUILD_ENVIRONMENT=host isn't passed, then? [19:05] cjwatson, yes, but only if using bases [19:05] kyrofa: You're sure nobody's using base: 16? [19:05] sergiusens: Also, please don't mark launchpad-buildd bugs Fix Released. That fix isn't rolled out yet [19:08] (base: core16, I mean) [19:11] cjwatson, such snaps fail to build as far as I'm aware, and don't install either. There are some using core18, but if I remember correctly they aren't using LP to build. sergiusens will of course know more [19:12] Hey there. [19:12] Hey there Gargoyle, welcome [19:15] This is currently the file dialogue for atom (and slack, so probably all electron apps). Is this something in my snapd setup that needs fixing or do the individual snaps need updating? https://www.dropbox.com/s/pblpsnbyvuvez1z/atom.png?dl=0 ( snap versions = https://paste.ubuntu.com/p/JG6FkgDZCK/) [19:15] kyrofa: Yeah, I know core18 won't work yet. OK, maybe not an emergency then [19:21] Gargoyle, what does it look like normally? [19:21] Gargoyle, popey might be able to help here, he's much more familiar with those snaps [19:23] kyrofa: It's missing any kind of colour, padding or icons compared to say LibreOffice dialogue. [19:23] OK. Thanks. I'll wait and see if he chimes in. [19:24] Gargoyle, for what it's worth, the vscode dialog looks unremarkable to me: native. What OS are you on? [19:26] Ubuntu 18.10. [19:26] I'll throw a screen grab of LibreOffice for comparison. [19:27] https://www.dropbox.com/s/hacpaoxi58djukq/lo.png?dl=0 [19:30] Perhaps theming is having some issues on 18.10 [19:30] (I'm on 18.04) [19:33] Does anything theme wise in snapd rely on the system as it was when snapd or snaps were installed (I recently reverted back to ubuntu-session and removed gnome-session.) [19:55] Hi. I'm on trisquel linux 8 which is package compatible with ubuntu xenial 16.04 and would like to install snapd. Since there's no snapd in trisquel repo I needed a snapd package from a PPA and the only one I could find is ppa:snappy-dev/edge. I just wanted to know if there is a stable PPA ? Thanks. [20:21] cachio: hey, I saw you have a dedicated -nested-vm image for spread, is that something available in general for GCE or are you building this image yourself for this purpose? [20:37] cjwatson: sorry about that, was a glitch in my brain, I have the impression I quickly switched it back though, sorry if that was not the case [20:39] cjwatson: about `base: core16` or bases in general, I did have a conversation with wgrant here on how to move that forward, we need to iron it out a bit, but there is nothing to worry about today at all [20:39] Saviq, hey, I am building this vm [20:39] Saviq, kyrofa requested that for snapcraft [20:39] why? [20:41] Saviq, we're using it for build VM tests, using multipass. It's all mine though, you can't have it [20:41] cachio: we'd use it for multipass with spread for sure, but we've had someone try multipass on GCE and I was wondering if nested vm is even supported by default [20:41] cachio: what's special about it? [20:42] kyrofa: I'll remember that! ;P [20:42] Saviq, :P [20:42] You have to enable it, cachio worked his magic: https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances [20:42] Saviq, nested vms are supported but if you want to use kvm you need to build an image for taht [20:43] aha, interesting [20:43] Saviq, otherwise you are able to create a nested vm using qemu by default [20:43] cachio: qemu without kvm, that is? so not really virtualization :) [20:49] Saviq, yes, kind of virtualization [20:50] == emulation [20:50] cachio: if I wanted to run spread tasks on GCE do I need to get added to the project or something? [20:51] Saviq, you want to use those images to run the spread tasks? [20:53] cachio: yup [20:54] Saviq, so, you need just to use [20:54] image: ubuntu-1604-64-nested-vm [20:54] image: ubuntu-1804-64-nested-vm [20:54] for xenial and bionic [20:55] I'll create tasks to keep them updated next week [20:55] then you can use them normally [20:57] Saviq, for reference: https://github.com/snapcore/snapcraft/blob/master/spread.yaml#L37 [20:59] cachio: yeah, but to run that from my laptop? [20:59] like I go to https://console.cloud.google.com/compute and I have no projects there, should I? [21:01] Saviq, you should have computeengine [21:02] Saviq, this is ou rproject [21:02] ah maybe I should switch to the right account... [21:03] to the canonical one :) [21:04] still, I can only create a new project, can't see any existing one [21:04] Saviq, did you see computeengine before? [21:04] no [21:04] or it is the first time you try that [21:05] Saviq, in that case you need gustavo [21:05] ack [21:05] tx [21:05] Saviq, he manages the permissions, roles, etc [21:06] * cachio afk [21:08] Saviq: You were already in the account [21:08] Saviq: You should be able to login and use our project [21:16] niemeyer: not sure what I'm doing wrong, then, I can only create a new project :/ [21:17] Saviq: Well, you can do lots of things I'm sure :) [21:17] Saviq: The question would be why the one thing you can do, which is logging in with your Canonical credentials so you get proper spread access, not working? [21:17] Saviq: I'm out of context, though.. [21:18] Saviq: What's failing? Which error are you getting? [21:18] niemeyer: I go to https://console.cloud.google.com/projectselector/compute/ and I can't see any projects [21:18] (and if I create a project it wants my credit card :P) [21:20] Saviq: Yep, sounds expected [21:20] oh ok I thought I should be able to see it there [21:21] Saviq: No, the role provides only enough permissions for Spread to work [21:21] ack, trying that then [21:31] hi, is there a way to inject ssh config/keys into the vm used by snapcraft when building? [21:33] ackk: I don't know about the actual build VM work going into snapcraft 3.0, but I don't think there's a supported way for the lxd container that `snapcraft cleanbuild` creates, however if this is a git project you could store the credentials in a file that is ignored by git and have a part in the snapcraft.yaml that reads that file and uses it [21:33] ackk: there may be a way to configure the default lxd profile to contain what you need, I'm not sure though [21:34] ijohnson, but lxd is not the official way to build with 3.0 right? [21:34] yeah with 3.0 I think currently only multipass is supported, but I'm not familiar with how 3.0 works with the VM yet so I can't speak to that [21:35] ok, thanks [21:36] kyrofa may know [21:42] ackk, ijohnson indeed, I believe that's a problem today. I'm not sure what the ideal solution would be. sergiusens, any thoughts there? [21:43] It's not a problem we ever solved for cleanbuild, either [21:44] kyrofa: is there any obvious way that someone could accidentally leak credentials by storing such files in the source tree and using it in a part in snapcraft.yaml? I don't think that the sentry error reports include file contents, but I'm not sure [21:44] I don't think the manifest.yaml file would leak anything if they turned that on [21:46] ijohnson, in my case it's not credentials, I need to checkout a private branch using ssh keys [21:46] so the config is actually in .ssh/config [21:46] ijohnson, yeah I'm not sure what you mean, I'm just thinking of SSH keys as well [21:46] kyrofa, precisely [21:46] A short-term solution might be snapcraft bind-mounting that into place in the VM [21:47] But I figure there's a good reason we didn't do that for cleanbuild [21:47] Just not sure what it is :) [21:47] kyrofa, sigh. and cleanbuild is the only way to properly build a core18 snap right? [21:48] Build VMs, but yeah same concept [21:48] I guess I was just referring generally to the files like private ssh keys, etc. You could always have a part that copies the private key from your snapcraft tree into the containers ~/.ssh/ [21:49] Yeah that might work around it for now. Would make me pretty nervous, make sure you filter it out [21:50] right my concern was rather that even if you filter it out and be careful that snapcraft doesn't automatically include the file contents in an oops report or something, subverting all your efforts to keep it safe [21:50] also not very generic, not everyone has the config and keys in the same place [21:50] Nah, those reports are pretty spartan, and aren't automatic unless you make it so [21:51] ackk, you can also use --destructive-mode which will run on the host like it does without bases, but then you exit supported territory [21:51] kyrofa: ack, good to know [21:51] ackk, I'm assuming you're using edge? [21:54] kyrofa, well I was trying edge yes. I'm currently using stable for builds [21:56] ackk, alright, yeah, on edge you can run `snapcraft --destructive-mode` and it won't spin up a VM, it'll run the build on the host. So you take responsibility for ensuring you're on the right host for the base, and make sure your environment isn't dirty, etc. [21:57] But then you have access to things on the host, like SSH keys [21:57] kyrofa, so that's the equivalent of the old plain "snapcraft" ? [21:57] Yeah, like running `snapcraft` without bases [21:57] I see [21:58] kyrofa, is there an ETA on when snapcraft 3.0 will be published to stable? [21:58] If you think you hit a bug in destructive mode, though, reproduce it in a build VM before reporting [21:59] ackk, not of which I'm aware beyond "soon", but it should be in candidate any time [21:59] kyrofa, cool, thanks [22:02] cachio: any pointers on how to set up auth for spread on google? when I run spread it bails out pointing at https://developers.google.com/accounts/docs/application-default-credentials - that then redirects to https://cloud.google.com/docs/authentication/production... all of that seem to require me to be able to see the project, and being able to create a service account on it... [22:02] ... but $ gcloud projects list [22:02] Listed 0 items. [23:19] sergiusens: panic over then, thanks :-) I will try to get that deployed this week though