[04:13] o/ [04:13] * zyga travels today [04:15] PR snapd#7212 opened: tests: respect SPREAD_DEBUG_EACH on the main suite [04:15] PR snapd#7213 opened: cmd/snap-confine: implement snap-device-helper internally [05:19] PR snapd#7214 opened: interfaces/network-setup-control: allow dbus netplan apply messages [05:32] morning [05:35] Hey [05:36] mborzecki: wish me luck :-) trying to use pkp today [05:37] Bought ticket online, barely. I cannot understand why that system is so poor [05:37] Now noticed that “mandatory replacement bus service” is to be used [05:38] hahaha [05:39] zyga: *) walking short distances included [05:39] Foreigners beware :-) [05:39] I sent a pair of PRs [05:39] Stuff from yesterday [05:40] Once I am on board I will ping you [05:40] “Opóźnienie może ulec zmianie” 😂 [05:45] I “like” how they repeat the same announcement about each train like 10 times [05:45] Definitely not confusing because there is something being said all the time [05:50] mborzecki: ok, settled in [05:51] fantastic service, 2 minutes late on arrival, 15 minutes wifi included [05:51] eh, everything is red again [05:55] zyga: why red? the sbuild task? [05:55] yeah [05:55] just merged your fix [05:55] zyga: cool, thx [05:55] PR snapd#7210 closed: packaging/debian-sid: set GOCACHE to a known writable location [05:58] zyga: the year of linux desktop, apparently when logging into gnome on wayland, there's likely some race in gsd where it fails to set up your keyboart shortcuts :/ you have to log out and log in once more [05:58] mborzecki: brilliant [05:58] why am i even surprised :) [05:58] mborzecki: just buy a mac already [05:58] mborzecki: maybe in 10 years [05:58] mborzecki: maybe it will work ;-) [05:58] mborzecki: having said that, try WSL2 [05:59] zyga: woudl need to have windows for that [05:59] I think this is a transformative, game-changing development [05:59] mborzecki: get a free eval version for 90 days [05:59] it's well worth playing with [06:00] zyga: i'm using eval for games, though can't quite recall when was the last time i booted it [06:01] mborzecki: switched over to my ubuntu phone for network [06:01] mborzecki: I wonder how much of the journey will have cellular coverage [06:01] mborzecki: I recall it's ~ 30% [06:05] mborzecki: btw, once again I'm reaffirmed that 13" is the perfect travel laptop [06:05] mborzecki: my 15" is at home, it's a good secondary desktop but it's not fit for travel [06:06] it would not fit on the intercity folding table, it would not fit on the economy airline folding tray, etc [06:13] brb, new kernel [06:24] so, running 5.2.6 now [06:24] neat [06:24] I'm on 5.2.0 still [06:29] zyga: still on tw? [06:29] mborzecki: tw? [06:29] tumblweed [06:29] mborzecki: ah, no, this is eoan [06:30] mborzecki: I'm using in on the huawei [06:30] mborzecki: I kind of miss TW but it is just for 4 days :) === pstolowski|afk is now known as pstolowski [07:07] morning [07:10] pstolowski: hey [07:16] 123 testing [07:52] I'm arriving in 20 minutes, I will be online in around an hour again [07:59] brb, quick errand, back in 30 [08:46] I’ve arrived but will be AFK for a few more moments [08:50] re [09:20] zyga: somewhat closed to reproducing context canceled in unit tests, `while true; do : | taskset -c 0,1 ./snap.test -test.count=1 || break; done` seems to work [09:28] zyga: somehow can't reproduce it when i replace s.tomb.Context(nil) with context.TODO() [09:32] re [09:33] what is taskset -c 0,1? [09:33] cpu affinity? [09:33] mborzecki: I'm not an expert on context, perhaps Context.TODO does nothing at all but Context from tomb is a real deal that need some code? [09:45] mborzecki: ok, unless anything else interrupts I'll work on the bugfix [09:47] How do I install local package with snap? [09:47] Perkol: can you elaborate? [09:48] zyga: are you able to help with https://github.com/snapcore/snapd/pull/7129 ? [09:48] PR #7129: userd: allow setting default-url-scheme-handler [09:58] related to that, is it possible to detect the snapd version at runtime from an app? [09:59] once that is merged, we'd only want to prompt to handle url schemes for a supporting version of snapd [09:59] popey_: looking [10:05] jwheare: you can use "assumes" for that [10:05] jwheare: no, but you can use "assumes: 2.40" (for example) [10:05] jwheare: though that is a static annotation on a snap, not a dynamic check [10:05] https://snapcraft.io/docs/snapcraft-yaml-reference [10:05] zyga: ok, i think i know what's going on, (goroutine 1) the agent calls Shutdown(ctx) with child context obtained from tomb, (goroutine 2) http.Serve() in tomb's func exits and returns nil, in t.kill() the child context get cancelled, and sets the reason to nil, rescheduled back to (1) child context is canceled, calls t.Kill(err), which sets the tomb's err context.Canceled (since it was nil as http.Serve() exited and didn't set one) [10:05] jwheare: you can use snapctl to query for the version [10:06] mborzecki: so, a race, and perhaps a bug in use of tombs as well [10:06] at least I think you can, I'd have to check the API [10:07] I need to prioritize tasks [10:07] sorry, settling ing [10:07] settling in [10:10] yeah i wouldn't want to block installation of the app entirely based on that missing feature [10:10] just need to determine whether to show the prompt on first launch [10:13] jwheare: unfortunately snapctl has missing features as compared to snap [10:13] jwheare: technically there is the /v2 API endpoint that has this information [10:13] it's just not exposed with snapctl [10:14] could just do a version check though [10:14] jwheare: that's the thing, you cannot [10:14] nothing will tell you which version of snapd is there [10:14] zyga: can you use curl from inside a snap to the snapd api? [10:15] popey_: based on a quick look, no [10:15] popey_: there are two sockets, if you recall [10:15] popey_: one is for full snapd api [10:15] popey_: and you cannot use it without snapd-control [10:15] popey_: the other one is for snapctl [10:15] popey_: but this one doesn't expose this [10:16] ondra: hey, thanks for yesterday's explanation of the failing first boot scenario; easily reproduced with broken gadget snap, also spotted the code responsible for this in snapd (i also looked at initrd script as well) [10:19] pstolowski: cool, :) [10:20] i'm just wondering how to test potential snapd fix without waiting for a new core image in edge [10:21] pstolowski: can you walk me through it? [10:21] pstolowski: maybe that will help [10:21] zyga: quick HO? [10:22] pstolowski: perhaps just chat, sorry, there's some distraction around here and my network is so-so [10:22] zyga: sure [10:23] pstolowski: let's try an audio-only one? [10:23] pstolowski: facetime audio? [10:23] zyga: ok [10:24] calling now [10:26] huh ok [10:28] is there any info on release cadence and adoption rates for new versions of snapd? [10:29] Most people get their snapd version from an automatic update of the core snap (or core18), via re-exec... [10:30] zyga: https://github.com/snapcore/snapd/pull/7215 [10:30] pstolowski: ^^ [10:30] PR #7215: usersession/agent: use background context when stopping the agent [10:30] PR snapd#7215 opened: usersession/agent: use background context when stopping the agent [10:31] jwheare: roughly 99.97 of snap users are on the latest 2.39 [10:33] * diddledan wants 2.41 already :-p [10:33] looking [10:33] hopefully .41 will include my optical-drive/scsi-generic patch that might enable makemkv [10:34] Nice! [10:34] mborzecki: s/a the/.../ [10:34] (that 99.97 should be a percentage, of course) :D [10:34] I think it was merged too late for inclusion in .40 [10:35] I choose to ignore that you think it's a percentage, and ask whose lost .03 of a person? :-p [10:35] Danny DeVito doesn't like automatic updates. [10:35] who's? which whose/who's should that be? [10:35] mborzecki: I'm honestly quite lost by the context stuff, I need to read more upon it [10:35] whom [10:36] https://twitter.com/natfriedman/status/1158557170423611393 [10:36] mborzecki: I mean, the pathc looks good [10:36] *patch [10:36] I just feel unqualified to say so [10:36] haha :) [10:37] mborzecki: https://github.com/snapcore/snapd/pull/7215#pullrequestreview-271258784 [10:37] PR #7215: usersession/agent: use background context when stopping the agent [10:38] we have 81 PRs [10:38] can we look at merging some [10:38] when mvo sees 101 PRs he will smite anyone opening a new one ;) [10:39] for instance: https://github.com/snapcore/snapd/pull/7212 [10:39] PR #7212: tests: respect SPREAD_DEBUG_EACH on the main suite [10:39] (shamelessly my own) [10:39] can we +1 that? [10:44] hola cachio :) [11:03] I’m going for a walk [11:18] zyga, hey [11:18] zyga, buenos dias [11:25] re [11:35] I tweaked the test, it should now pass everywhere [11:35] hey cachio [11:35] pstolowski, hey [11:49] PR snapd#7212 closed: tests: respect SPREAD_DEBUG_EACH on the main suite [11:51] PR snapd#7187 closed: data/selinux: allow snap-confine to read entries on nsfs [11:51] pstolowski: can you take a look? https://github.com/snapcore/snapd/pull/7137 [11:51] PR #7137: gadget: support for writing symlinks [12:01] hmm, I somehow made a racy service ... [12:02] * zyga thinks === ricab is now known as ricab|lunch [12:08] don't make me run. the leg movement makes my belly turn into a pendulum and I fall over [12:09] plus: seriously unfit! [12:09] * diddledan eyes zyga's race.. [12:10] have i already complained that tests/main/sbuild occasionally hits spread job timeout? [12:11] mborzecki: do we know where it spends most of the time? [12:11] interesting. python3's venv module in disco (core18) is not relocatable - it tries to, and fails to, read files in /usr/share/python-wheels [12:11] cachio: restarted https://github.com/snapcore/snapd/pull/7211 bc it didn't fail with PROTOCOL error, maybe we'll get lucky in the next run [12:12] PR #7211: tests: add more debug information to see the root cause of the protocol error <⛔ Blocked> [12:12] mborzecki, thanks [12:12] zyga: idk, tbh, when debugging that task manually on gcp i managed to get 3 incomplete runs before the node was killed [12:14] * zyga has issues with systemctl restart [12:14] cachio: wondering, if you have the log from when the problem happens, perhaps you could try to run the request with curl --http2 [12:14] is that different from stop + start? [12:16] the problem happens basically when we need to download a snap from fastly and it is not in the endpoint, so it goes to get it from a central repository [12:16] mborzecki, [12:16] mborzecki, it happens really sporadically [12:17] I'm trying with stop + start [12:17] mborzecki, yesterday verterok requested information I think [12:17] I don't know if there is more info about this protocol issue [12:17] cachio: mhm [12:18] cachio: Hi, yesterday I filed a support ticket to fastly, got a reply: they can't reproduce [12:20] cachio: if there is a way to reproduce, that would be helpful, otherwise I think the http2debug logs might shed some light [12:21] mborzecki, I added the GODEBUG=http2client=1 to te test env but logs are the same [12:21] after the protocol error [12:21] do you know if it is ok or I should change something? [12:22] perhaps display a different log on debug? [12:23] cachio: do you have the log that contains the error? [12:26] mborzecki, you restarted the failed log :) [12:26] mborzecki, last exec failed with protocol error [12:26] cachio: in 7211? that one failed because of sbuild [12:27] mborzecki, or perhaps someone else restarted that before? [12:27] yesterday I saw that [12:27] no worry in that case [12:27] lets see if fails now [12:31] restarting services is tricky [12:31] snap "run" chain takes long enough that raciness is easy [12:32] I wonder if we could turn all daemon simple into daemon notify internally [12:32] where we only poke systemd at around snap-exec [12:45] pfff 2019-08-06 11:48:32 Error executing google:ubuntu-19.04-64:tests/main/login : read tcp 10.20.0.181:57254->34.74.6.202:22: use of closed network connection [12:46] mborzecki: mmmmm [12:47] our shutdown code does not seem very reliable? [12:51] *yes* [12:51] finally it passed [12:52] now it will not fail, but I feel we have a problem [12:52] * zyga tries on 14.04 [12:56] mborzecki, you are right about the #7211, I saw the protocol error in another one [12:56] PR #7211: tests: add more debug information to see the root cause of the protocol error <⛔ Blocked> [12:58] mborzecki, this happens when I have like 15 logs open heheheh [13:23] hey folks, can I get another review on https://github.com/snapcore/snapd/pull/7189 ? :-) [13:23] PR #7189: HACKING.md: update spread section, other updates === Eleventh_Doctor is now known as Pharaoh_Atem === ricab|lunch is now known as ricab [13:37] * zyga is on the roof [13:38] obviously storm is coming now [13:39] zyga: don't stay with antenna in your hand [13:43] get an umbrella so you dont get wet ... [13:51] -80dBm signal [13:51] hmmm, a bit crappy [13:52] I need a longer pole [13:53] anyway [13:53] that's that for now [13:58] PR snapd#7189 closed: HACKING.md: update spread section, other updates [14:00] pstolowski cool [14:00] pstolowski I can point you easily to initrd code if you want [14:00] ondra: i found it [14:00] pstolowski cool [14:01] pstolowski what do you think is best way, assume seed as primary location instead of looking in vat/lib/snapd/snaps? [14:02] thanks for the merge zyga [14:07] ondra: good question, i'm not sure we need to change initrd, making snapd more robust should fix it. but if we change initrd, we would make seed a fallback, not primary, no? [14:09] pstolowski I'd prefer to make initrd also more forgiving [14:10] pstolowski if we check snaps and seed/snaps for kernel and core snap, there should be no danger and it will make boot more reliable [14:11] now we are creating symbolic link only to make initrd happy [14:12] pstolowski if we use seed for first boot, it will be more aligned with all other snaps, now we are treating core and kernel snaps at first boot as special snow flakes :) [14:14] would you do the seeding from initrd then ? [14:14] (and gpg verification etc etc) [14:14] that will likely grow the initrd a lot [14:15] (which in turn would make the boot slower on low-end HW) [14:18] ogra: no, it's just about looking for kernel in seed/ even if there is no symlink [14:22] ondra: https://bugs.launchpad.net/snapd/+bug/1838937 it is public now [14:22] Bug #1838937: device cgroup enforcement is partially ineffective for snap services [14:30] ondra: where is the repository for initrd code? [14:33] Hey guys, I'm currently looking into Ubuntu Core and I'm confused about the update process, because I see that apps are updated using snap, but how is the system image/kernel updated? Also via snap? [14:37] pstolowski, https://github.com/snapcore/core-build ? [14:38] Sheogorath[m]: yes the kernel and rootfs is also updated via gadget and kernel snaps [14:39] ijohnson: Do you happen to know how unsuccessful upgrades are handled? (i.e. New kernel installed, device no longer boots) [14:40] updates are transactional, so if the device fails to boot, it will automatically rollback to the previous kernel [14:42] :+1: Thanks, that's what I wanted to know. Any pointer for docs on that? [14:42] ogra: thanks [14:43] Sheogorath[m]: see https://assets.ubuntu.com/v1/66fcd858-ubuntu-core-security-whitepaper.pdf [14:50] Awesome thanks! [14:55] * cachio lunch [15:47] pstolowski reference is here https://github.com/snapcore/core-build/tree/master/initramfs [15:47] pstolowski but I think there is also ppa [15:47] ondra: yep, thanks, got it from ogra [15:47] pstolowski OK :) [15:49] ondra: btw, does any change there land automatically in core from edge? how can i test it before it lands? [15:49] pstolowski what would be question to ogra [15:49] pstolowski I do usually build own kernel snap to test [15:50] pstolowski you can append initrd overlay to existing initrd blob and it will overide file in question [15:56] ondra: can you elaborate or give a pointer to doc? sorry, i'm new to this.. [15:56] pstolowski no worries [16:00] pstolowski see https://git.launchpad.net/~ondrak/ondras-snaps/+git/linux-kernel/tree/snapcraft.yaml?h=snapdragon-fit-dmcrypt#n142 [16:00] pstolowski line 142 builds overlay initrd, in your case this would be likely just one file in there [16:01] pstolowski line 143 will then put two together [16:02] pstolowski actually check line 145 [16:04] pstolowski something like this https://paste.ubuntu.com/p/2MsV3hwtyc/ [16:07] ondra: got it, thanks. so looks like to test it with qemu & amd64 core image i need to rebuild amd64 kernel snap, that means assertions etc [16:08] pstolowski no need for new assertion [16:08] pstolowski you can sideload kernel snap [16:08] pstolowski unpack stock kernel snap, append to existing initrd.img, snap pack, and build image with --snap [16:10] ondra: ah, allright.. will try that out, thanks! === pstolowski is now known as pstolowski|afk [17:16] PR snapd#7216 opened: interfaces/misc: updates for k8s 1.15 (and greengrass test) [17:47] PR snapd#7217 opened: interfaces/bluetooth-control: add udev rules for BT_chrdev devices [18:08] * zyga fell asleep [18:09] sorry folks, I'm just exhausted by lack of sleep [18:14] zyga: 💤 timezone shifting is tough. Take it easy :) [18:15] roadmr: sprinting is tough even without the timezone shifting :) [18:15] as I've just now learned [18:15] roadmr: yeah, I'm just tired [18:15] cwayne: it is, yes [18:16] roadmr: especially when the last lightning talk breaks your stuff 😂 [18:16] cwayne: I attended the snapcraft summit earlier this year - it was local (so just swapped WFH for a 25-minute commute downtown) - I was still exhausted by the end of the week [18:16] roadmr: oh i believe it [18:16] it's called sprinting for a reason! [18:16] cwayne: haha :) popey will be happy to know we have a fix for the null snap, should be in prod in the next couple of days [18:18] roadmr: hurrah! [18:19] roadmr: what was the issue? [18:19] roadmr: None [18:19] ;D [18:19] (it's a joke) [18:19] zyga: exactly :) [18:19] we were happily assuming that if a key was present in a dict, the value would be non-none :D [18:20] How wrong you were! [18:20] (interestingly I never intended it to fail the store, it worked in my earlier test because I did it slightly differently) [18:20] popey_: remember what they say about assuming [18:20] https://www.explainxkcd.com/wiki/index.php/1339:_When_You_Assume [18:20] roadmr: mypy got a new feature lately [18:20] roadmr: typed dicts [18:20] roadmr: it's super useful [18:21] Made for a nice end to the talk though, thanks for speaking up :D [18:21] \o/ [18:21] popey_: you've raised the bar, now Chipaca's challenge is to also crash the store on-stage [18:22] (he's crashed it plenty, just behind the scenes mostly) [18:24] DEAL! [18:27] given the null snap is a noop effectively, it's fun to run it with --trace-exec :D [18:28] snap-confine will always be ~0.029s or so, even on an empty snap [18:28] I've sent a patch for improving that [18:28] though a good chunk is constant cost of go [18:28] Good. 0.029s is outrageous! :D [18:28] it really is [18:30] huh. today I learned you can "snap info path/" [18:30] I just did "snap info null" and wondered why I didn't get info about channels. It was seeing the null/ folder in my home that I used to make the snap [18:30] that's confused me for a few moments! [18:38] PR snapd#7215 closed: usersession/agent: use background context when stopping the agent [19:03] PR snapcraft#2655 opened: Gnome extension [19:55] PR core-build#50 opened: initramfs: run recover mode if trigger is detected [20:25] roadmr, noise][, trying to upload a banner for my snap. Restrictions state "Min resolution: 720 x 240 pixels" and "Max resolution: 4320 x 1440 pixels". But when uploading a 4320x1440px image, I get an error: "Legacy banner (banner.png) image must be 1218x240 pixels in size" [20:27] roadmr, noise][: the stated restrictions also include "Aspect ratio: 3:1", which 1218x240 is not [20:27] What should we be using, here? [20:28] kyrofa: either don't name it banner.png, or comply with the 1218x240 requirement [20:28] ... seriously? It cares about the name I chose on a file upload? [20:29] I'm doing this through the web ui [20:29] ............. yes [20:29] Hahaha [20:29] kyrofa: there's some special handling for those "legacy" banners [20:29] That is very confusing [20:29] But you're right, renaming it works [20:30] kyrofa: yep - that'll go away in the future and there will be a specific "banner" media type - the issue right now is that the old way of handling it relied on a specially-named screenshot named banner.png [20:31] (well, I say "old" but as you can see, this is still in place - we're working on it :) [20:35] to be phased out legacy banner method [20:35] and yeah, kinda unfortunate, but here we are