[00:56] PR snapd#7504 opened: tests/cmd/debug_state: make the test output TZ independent [05:05] morning [05:05] good morning mborzecki [05:06] mvo: hey [05:08] hmm google:ubuntu-18.04-64:tests/main/mount-ns:inherit failing, looks like the expected mountinfo content needs and update, but why doesn't it fail always [05:12] mborzecki: meh, that sounds like a zyga question [05:14] PR snapd#7500 closed: api,timings: report duration via Doing column for ensure/startup [05:15] PR snapd#7501 closed: interfaces/kubernetes-support: allow use of /run/flannel [05:15] PR snapd#7502 closed: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 [05:19] PR snapd#7505 opened: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD [05:19] mvo: zyga: this should fix the problem ^^ [06:41] PR snapd#7504 closed: tests/cmd/debug_state: make the test output TZ independent === pstolowski|afk is now known as pstolowski [07:00] morning [07:02] pstolowski: hey [07:16] duh gorename being silly and going through the whole of GOPATH [07:26] hey ho [07:26] sorry for starting late [07:26] I'm feeling so so still [07:33] PR snapd#7506 opened: devicestate: add support for gadget->gadget remodel [07:34] pstolowski, zyga hey and good morning! [07:34] zyga: no worries, get well [07:43] mvo: hi, I put some questions in 7506 === His_Dudeness__ is now known as huenzelgruenz [07:45] mvo: it would be good if either mborzecki or you did something about #7166 [07:45] PR #7166: client: add doTimeout to http.Client{Timeout} <⛔ Blocked> [07:45] pedronis: i keep working on that [07:46] thanks pedronis [07:47] pedronis: I can scope down 7506 to only allow track switching for now maybe? [07:47] pedronis: but I guess the question remains the same [07:47] pedronis: we need a check to ensure the volumes are compatible, right? [07:47] yes [07:48] anyway I doubt it's a small task, it sounds really more mborzecki material once he is done with other stuff [07:48] pedronis: yeah, that should be ok [07:49] John will pick up #7377 [07:49] PR #7377: patch: add an overlord patch that normalizes channel in state <⛔ Blocked> [07:50] pedronis: great! [07:50] as I discussed with him yesterday [07:51] PR snapd#7505 closed: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD [07:54] mvo: I need to think a bit more about #7348, I'm not happy with the regression in some cases, I'm not happy with the complexity of the clean solution either [07:54] PR #7348: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> [07:55] pedronis: fair enough, we can just close it if you feel it hurts more than it helps [07:56] mvo: no, maybe there is just cheap way out, but I really need to focus on some other things, we can try to rediscuss it in the next days [07:56] pedronis: ok [07:59] mvo: #7434 is ready for review [07:59] PR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code [08:03] pedronis: thanks, looking [08:05] pedronis: hey, https://github.com/snapcore/snapd/pull/7468 is referencing itself in the comment (wrong PR #) [08:05] PR #7468: seed/seedwriter: support local snaps [08:06] pstolowski: ah, anyway we probably want to wait for them to land one by one [08:06] I haven't pushed the big one through all the way [08:06] because too much rebase complexity all over [08:07] ack, yes i can imagine [08:08] pedronis: what would be the next to review after 7434? [08:09] pstolowski: I think it's actually #7441 [08:09] PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings [08:09] pedronis: btw did you force-pushed 7434 a moment ago? i was reviewing it and at some point github told me to refresh, but there was just 1 commit [08:10] pstolowski: yes, I added some test lines [08:10] where there was a ... [08:10] pedronis: ok. it's a bit confusing when something like this happens ;) [08:11] I didn't know somebody was already reviewing it [08:11] pstolowski: anyway I added exactly lines at the very end: https://github.com/snapcore/snapd/pull/7434/files#diff-81b90abba270c6b3849a0191b406c81bR719 [08:11] PR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code [08:11] there was a // check snap-revision // ... there [08:12] thanks [08:13] pedronis: btw all the //XXX: channel stuff is waiting for John's changes? [08:14] pstolowski: no, I added to the description now, it is taken care in a follow up just about channel [08:14] ok [08:14] though I expect later changes again because of some decisions about UC20 models [08:14] pstolowski: it's done in #7467 [08:14] PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps [08:15] pstolowski: related to the // ... I'm sure I forgot some small todos here and there, I'm trying to address them when I merge master into things when the prereq lands [08:15] but big things are taken are along the sequence [08:16] as I mentioned I do have code that makes image.go tests pass again, that's something I'm trying to finish today [08:19] pstolowski: we do use just a for assertion here and there, is not the only place there [08:19] I mean across the codebase [08:19] pedronis: ok, fair enough [08:46] pedronis: pushed an update to #7166 [08:46] PR #7166: client: add doTimeout to http.Client{Timeout} [08:47] mborzecki: thx, queued to look at [08:47] pedronis: great, thank you! [09:26] mborzecki: are you going to work on the issue with invalid old gadgets that was discussed yesterday? [09:26] pedronis: yup, i'm working on it right now [09:27] thx [09:30] pstolowski: right now it seems you are commenting on some code that exists already like that in image.go [09:30] not saying that it might not get more confusing now that is getting lifted [09:31] and might need more comments [09:31] but a bit of context maybe is useful [09:32] pstolowski: I put a link to the original code in the response to one of your comments [09:32] pedronis: hmm, maybe... it's the inherent problem of stacked PRs :( (not your fault by any means) [09:32] easy to get lost [09:33] pedronis: in #6958 we implemented download via snapd as a POST. I asked why it wasn't a GET, we discussed it in the standup, and apparently it needed to be POST … but we didn't write down why, and now I don't remember [09:33] PR #6958: Added api endpoint for downloading snaps [09:33] pedronis: do you? [09:34] Chipaca: we might want to send alternative auth bits or http proxy config at some point it [09:34] it would get unwieldy as GET params [09:35] fair [09:35] mvo: ^^^ [09:37] pstolowski: also maybe you are re-reviewing code? the only new code in that PR is https://github.com/snapcore/snapd/pull/7441/commits/ab5e4c151488cc399946a42ce413752c9a1651bd [09:37] PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings [09:41] pstolowski: btw fwiw I fixed the chaining ref in 7468, it's based on #7467 [09:41] PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps [09:41] if y'all are hungering for something to review, #7320 is sitting there [09:41] PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces [09:47] Chipaca: I queued it, I skimmed it, it seems to need a couple of tweaks [09:58] mvo: I'll get some meds and work on triaging [09:59] mvo: I worked with roger in the morning, I have some updates on that, save them to the doc [10:04] mvo: this is interesting: https://forum.snapcraft.io/t/first-boot-doesnt-recover-if-system-restarts-while-snapd-is-starting/13392 [10:04] * mvo is in a meeting right now [10:06] pedronis: we discovered that yesterday [10:11] Chipaca: my only reservation wrt #7320 is what i described in general comment, the fact that snap run will be affected. not sure if this is going to be an issue in practice [10:12] PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces [10:17] pedronis: just read backlog (meeting is over) - yes, thats serious and needs fixing :/ [10:30] * pstolowski lunch and school run [10:37] PR snapd#7507 opened: gadget: do not fail the update when old gadget snap is missing bare content [10:44] mvo, pedronis: I updated the forum and created a detailed bug report [10:59] zyga: I commented there, what's the right solution is not super clear to me [10:59] we need to discuss further [11:00] pedronis: sure, I only gave a suggestion how this might be addressed but I agree it's something to design more closely as this is a very critical element [11:32] mvo, hey [11:32] yesterday I was researching a bit an error on the rpi [11:32] for core 18 tests [11:33] I see that for arm devices the file /boot/grub/grubenv does not exist [11:33] and for amd64 and i386 it exists [11:33] do you know the reason? [11:33] arm doesnt use grub [11:34] instead you should have /boot/ubot [11:34] */boot/uboot [11:34] ogra, I have it [11:34] right [11:34] (and everything in snapd should take that into account= [11:34] ) [11:34] so how should I get the env vars? [11:35] should we compile fw_printenv right? [11:35] on core16 you had the fw_printenv tool pre-installed, but i think mvo decided to drop it in core18 so there is no way except from serial console directly in the bootloader shell [11:36] ogra, ah, ok [11:36] while you can indeed compile it, there is more to it, as you need a config file in /etc that points to the right addresses the uboot.env lives [11:36] we had some setup in core16 [11:37] well in this case I'll have to skip this test for arm devices until we define an alternative path for it [11:37] thanks ogra [11:37] for the explanation [11:37] (and it is massively annoying that fw_printenv/setenv are gone ... since customers need to hack bootloader configs directly in the uboot shell now .... quite a time waster to do all these reboots) [11:38] ogra, indeed [11:43] * Chipaca wanders off in search of sustenance [11:44] cachio: mvo: sounds we might have to consider bringing it back, either in core or snapd [11:44] +1 !! [11:45] pedronis: snap debug boot-env {set,get,unset} ? [11:45] pedronis: so that snapd code for working with environment is exercised [11:45] PR snapd#7508 opened: tests: skip the ubuntu-core-upgrade on arm devices on core18 [11:46] zyga: maybe [11:46] perhaps even as direct in snap thing [11:46] so that it can be used at all times [11:46] but not sure about that [11:47] no, that seems strange [11:47] yeah, it's better to do it "for real" via snapd [11:48] well, for development/porting it is super helpful to have some access from userspace ... wether thats via fw_* or via snap set/get surely doesnt matter ... but having *some* access again would be really helpful [11:48] yeah, I think that's key [11:50] zyga: I missed what you meant [11:50] pedronis: that _a_ tool is available [11:51] no, I though with direct, you meant snap boot-env, snap debug boot-env [11:51] not about skipping snapd [11:51] ah, sorry, I meant snap boot-env [11:51] either it's an area that will be in flux soon [11:51] so a bit hard to start on this now [11:51] yeah [11:59] * zyga lunches [12:10] ogra: in https://forum.snapcraft.io/t/partition-layout-for-snappy/656/47 [12:10] ogra: i know most of the words, but not in the order you're using them :-p [12:10] ogra: so, what would be a good title for the new topic that started tehre today? [12:10] ogra: so I can split it out as it doesn't seem to be related to the previous one === ricab is now known as ricab|lunch [12:15] Chipaca: consider looking at (wishlist to support another systemd service unit property useful for forking daemons) https://bugs.launchpad.net/snapd/+bug/1822337 [12:15] Bug #1822337: Support for setting PIDFile for "forking" daemons [12:15] mmm, forks [12:16] zyga: I'd call that a papercut [12:16] zyga: is that what you're asking me? [12:17] if that's sensible in your eyes let's tag it and move on [12:17] zyga: yeap [12:17] zyga: once we have ~5 papercuts we can start thinking of keeping it to that number (i.e. doing some of them ourselves in our copious free time) [12:18] Chipaca: at the 8th day of the week [12:18] zyga: and yes I pulled that number out of ... thin air [12:18] ;) [12:18] osvaldo [12:20] Chipaca: could I also ask you to look at https://bugs.launchpad.net/snapd/+bug/1823768 -- it was reported almost half a year ago and perhaps was fixed since [12:20] Bug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress [12:20] you're assigned to it as well [12:20] I've triaged it so I'll leave the rest to you, if you want to update the status please do so [12:21] zyga: that one has not been fixed afaik [12:22] Chipaca: I might have fixed it in my remodel work [12:22] pedronis: was about to ask [12:22] but we never reproduced it [12:22] pedronis: but even when it was reported it wasn't clear how to repro [12:22] yeah [12:23] to be precise I found a place that was buggy in my remodel work and fixed it [12:23] I don't know of any other place [12:23] but might exist [12:24] the place was in the alias handling code [12:24] for an update [12:27] mborzecki: #7166 is failing the static tests [12:28] duh [12:28] PR #7166: client: add doTimeout to http.Client{Timeout} [12:28] let me see [12:29] kenvandine: is snap-store bug tracker on lauchpad? [12:30] kenvandine: can you please reassign this bug as appropriate https://bugs.launchpad.net/snapd/+bug/1824166 [12:30] pedronis: interesting, looks like that naked return been there since 04.2018 [12:30] Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. [12:32] PR snapd#7503 closed: tests: restart the journald service while preparing the test [12:35] hmmm, launchpad timeouts are somewhat common [12:35] meh, the default config for nakedret used by golangci-lint is to complain if the func is above 30 lines of code, while vanilla nakedred does that for 5+ lines of code [12:36] Chipaca, hmmm which bits exactly do you want to split out ? [12:36] mborzecki: what changed? anyway 5+ seems a bit too conservative but no strong opinion there [12:37] pedronis: i've added some code to the function that nakedret flagged, and it's just above the default threshold of 5 lines when it start to complain [12:37] Chipaca, note that i only pointed to a howto from mvo to install to internal MMC ... [12:37] mborzecki: let me look at that function and form an opinion :) [12:38] haha [12:38] btw. forgot to mention that when we discussed the tooling we use, i'm using https://github.com/golangci/golangci-lint locally to check the code before pushing out [12:40] Chipaca: https://bugs.launchpad.net/snapd/+bug/1826064 is something you may be interested in as a hobby interest :) [12:40] Bug #1826064: snap command outputs unicode in publisher name even when locale is ascii

[12:40] zyga: ikr [12:41] ogra: from shubham's question today down [12:41] Chipaca, well, it is 50% about what i linked to (how to install to internal MMC) and 50% related to ondra's stuff regarding fastboot hackery [12:42] so i dont think it is in the wrong place [12:42] mborzecki: we could bump the default to -l 10 , 30 seems a bit much to me [12:43] ogra: ah, fair enough [12:43] though [12:44] Chipaca, i.e. you can use tw ways to get stuff to internal MMC ... one is to simply godd the image to the internal device from an SD booted system ... the orther is to jump through a million of hoops and make your image a multi-partition one tat fastboot accepts [12:44] mborzecki: a bit your call what you want to do there, either bump or fix [12:44] (in case your board has fastboot support in the ROM/first-stage-bootloader) [12:45] * ogra notes his typing sucks today :( [12:45] pedronis: already pushed a fix to use named arguments with return [12:45] popey: could I ask you to look at https://bugs.launchpad.net/snapd/+bug/1826470 -- it seems that brave works but only from the command line for some reason, perhaps it's a papercut in the desktop file [12:45] mborzecki: ok [12:45] Bug #1826470: Can't launch brave from dock [12:46] wow, our standup notes are *long* :P [12:47] mborzecki: we need a second document with only a highlights of the first one ;) [12:48] pstolowski: should employ some ML to distill the most important bits [12:48] I'm trying to keep it with a civilized level of detail [12:48] mborzecki: Machine Learning? :D [12:48] zyga: yup [12:48] I try to use a sub-points for details [12:49] and main points for highlights [12:49] this way you can just briefly read the report without needing to deduce what's detail and what's overview [12:51] after a few months we can feed it to a markov chain of sorts and have an entirely new set of activities [12:52] zyga: snap-store is strict, so not sure what I can do from within the confined snap to fix dns resolution [12:52] zyga: looks like something isn't properly exposed in the sandbox [12:54] kenvandine: perhaps the issue is fixed now [12:54] kenvandine: it was classic earlier if I recall correctly [12:56] It was briefly published to edge as classic [12:56] only for a couple days though, about 18 months ago [12:57] this bug report is only a few months old [12:57] i think the reporter is saying classic snaps work and strict snaps do not [12:58] vscode can access network, firefox can not [12:58] ah, perhaps I misread the bug [12:58] can you add this to the bug, I'll look at it on the next pass [12:58] that is in the bug :) [12:59] he explains that firefox can't access the network but vscode can. [12:59] and he explains that vscode is classic and hints that is why it works [12:59] i'll comment on the bug though [12:59] zyga: quit triaging bugs, it's my day today! [12:59] ijohnson: I know it's not my day, I kind of missed the schedule because I was partially off yesterday and didn't realize it's Wednesday [13:00] kenvandine: zyga: which bug is this? [13:00] * ijohnson accepts zyga's apology in exchange for more polish sweets at next sprint [13:00] ijohnson: I'll send you the menu ;) [13:00] kenvandine: zyga: please don't say kali [13:00] :-) [13:00] 2fa [13:01] Chipaca: bug 1824166 [13:01] it's Deepin [13:01] Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. [13:02] I moved it out of invalid until it gets looked at again [13:02] kenvandine: deepin has some kind of issue somewhere [13:02] kenvandine: snaps that need network, or x, don't work right [13:03] or maybe x is just kali? [13:03] kenvandine: https://forum.snapcraft.io/t/deepin-debian-9-snaps-have-no-internet-connection/11295/7?u=chipaca [13:06] ah, kali was the weird "homes are in /" thing [13:06] * Chipaca gets them confused [13:08] zyga: ok, the theory is confirmed by that forum post. [13:26] pedronis: can you please enqueue looking at this bug report, it has an observation that may be relevant for your core 20 model design work: https://bugs.launchpad.net/snapd/+bug/1834688 [13:26] Bug #1834688: connections stanza in gadget.yaml requires snap id [13:33] mvo, I could reproduce the error running the interfaces-many-core-provided using a vm [13:33] here [13:34] I need to re run to start printing more information [13:34] debug information [13:35] what I saw is that the cpu went to 170% and then it didn't accepted any connection anymore [13:35] accept [13:37] cachio: cool, thank you! [13:38] * zyga breaks for coffee [13:38] mvo: snapd will have 0 new bugs today :) [13:38] mvo: the next pass will need to look at snappy [13:38] mvo: and finally at gardening all open bugs [13:39] zyga: \o/ [13:42] not sure who's interested in seeding today but... [13:42] https://bugs.launchpad.net/snapd/+bug/1835795 is something that might impact design of the command that creates the seed structure [13:42] Bug #1835795: seeding a snap with higher assumes than deb pkg of snapd on classic fails [13:42] ping pedronis for architectural consideration, I think you can just read the 1st comment on the bug for a brief summary === ricab|lunch is now known as ricab [13:44] I think https://bugs.launchpad.net/snapd/+bug/1835805 is something jdstrand should add to his queue for some ideas on how we could design enough changes to unblock using classic snaps like compilers from other classic snaps, like developer IDEs [13:44] zyga: I fear it's medium [13:44] Bug #1835805: strict snap run from classic snap can't write to filesystem [13:44] pedronis: please reassign the priority as you see fit [13:45] zyga: yay for triaging my bugs [13:45] ijohnson: thank you for filing nice bugs :) [13:45] oh actually that most recent one about strict snap from classic snap is on the forum somewhere, let me update that one too [13:46] zyga: made a comment as well, I don't think it's a seeding time validation problem [13:47] pedronis: do you think and older snapd should be able to interpret a seed with assumes that it cannot itself satisfying by properly staging the re-execution step? [13:47] zyga: that's even a different problem [13:47] we are talking assumes here [13:47] we haven't really changed the seed format in a long while [13:48] that's true [13:48] that's a separate issue [13:48] at some it becomes a "it hurts then don't do it" sort of situation [13:48] assumes are bound to change quicker than sruing so I understand the concern [13:49] pedronis: indeed [13:49] my point is mostly I don't think we need an unrealistically general solution [13:49] pedronis: I think as long as snapd can reexec it could be handled with proper logic in snapd itself [13:49] still feels medium to me [13:49] sure, I think that as we do this more often (now) we will get a broader shared understanding of each priority [13:50] pedronis, mvo: I'm now blocked waiting on reviews for my snapstate PR's, should I work on reviews today or move on to fixing the socket/timer stuff we discussed in Paris? [13:51] ijohnson: you can do a bit reviewing, I'll try to get to some of your PRs today myself [13:51] ack, thanks! [13:56] PR snapd#7509 opened: gadget, snap/pack: perform extended validation of gadget metadata and contents [14:13] pedronis: re debug timings & start-time (what we discussed yesterday). it's slightly annoying: we have start times in timings for some tasks, but it's not guaranteed. some handlers may not implement timings, also sometimes timings are not stored (>5ms threshold). but we still report all tasks of the change (just doing/undoing time, with no nested timing details). so, we can use start-time if available, but otherwise [14:13]