[00:56] <mup> PR snapd#7504 opened: tests/cmd/debug_state: make the test output TZ independent <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7504>
[05:05] <mborzecki> morning
[05:05] <mvo> good morning mborzecki
[05:06] <mborzecki> mvo: hey
[05:08] <mborzecki> 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] <mvo> mborzecki: meh, that sounds like a zyga question
[05:14] <mup> PR snapd#7500 closed: api,timings: report duration via Doing column for ensure/startup <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7500>
[05:15] <mup> PR snapd#7501 closed: interfaces/kubernetes-support: allow use of /run/flannel <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7501>
[05:15] <mup> PR snapd#7502 closed: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7502>
[05:19] <mup> PR snapd#7505 opened: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7505>
[05:19] <mborzecki> mvo: zyga: this should fix the problem ^^
[06:41] <mup> PR snapd#7504 closed: tests/cmd/debug_state: make the test output TZ independent <Simple 😃> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7504>
[07:00] <pstolowski> morning
[07:02] <mborzecki> pstolowski: hey
[07:16] <mborzecki> duh gorename being silly and going through the whole of GOPATH
[07:26] <zyga> hey ho
[07:26] <zyga> sorry for starting late
[07:26] <zyga> I'm feeling so so still
[07:33] <mup> PR snapd#7506 opened: devicestate: add support for gadget->gadget remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7506>
[07:34] <mvo> pstolowski, zyga hey and good morning!
[07:34] <mvo> zyga: no worries, get well
[07:43] <pedronis> mvo: hi, I put some questions in 7506
[07:45] <pedronis> mvo: it would be good if either mborzecki or you did something about #7166
[07:45] <mup> PR #7166: client: add doTimeout to http.Client{Timeout} <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
[07:45] <mborzecki> pedronis: i keep working on that
[07:46] <mvo> thanks pedronis
[07:47] <mvo> pedronis: I can scope down 7506 to only allow track switching for now maybe?
[07:47] <mvo> pedronis: but I guess the question remains the same
[07:47] <mvo> pedronis: we need a check to ensure the volumes are compatible, right?
[07:47] <pedronis> yes
[07:48] <pedronis> anyway I doubt it's a small task, it sounds really more mborzecki material once he is done with other stuff
[07:48] <mvo> pedronis: yeah, that should be ok
[07:49] <pedronis> John will pick up #7377
[07:49] <mup> PR #7377: patch: add an overlord patch that normalizes channel in state <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7377>
[07:50] <mvo> pedronis: great!
[07:50] <pedronis> as I discussed with him yesterday
[07:51] <mup> PR snapd#7505 closed: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7505>
[07:54] <pedronis> 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] <mup> PR #7348: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
[07:55] <mvo> pedronis: fair enough, we can just close it if you feel it hurts more than it helps
[07:56] <pedronis> 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] <mvo> pedronis: ok
[07:59] <pedronis> mvo: #7434 is ready for review
[07:59] <mup> PR #7434: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
[08:03] <mvo> pedronis: thanks, looking
[08:05] <pstolowski> pedronis: hey, https://github.com/snapcore/snapd/pull/7468 is referencing itself in the comment (wrong PR #)
[08:05] <mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
[08:06] <pedronis> pstolowski: ah, anyway we probably want to wait for them to land one by one
[08:06] <pedronis> I haven't pushed the big one through all the way
[08:06] <pedronis> because too much rebase complexity all over
[08:07] <pstolowski> ack, yes i can imagine
[08:08] <pstolowski> pedronis: what would be the next to review after 7434?
[08:09] <pedronis> pstolowski: I think it's actually #7441
[08:09] <mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
[08:09] <pstolowski> 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] <pedronis> pstolowski: yes, I added some test lines
[08:10] <pedronis> where there was a ...
[08:10] <pstolowski> pedronis: ok. it's a bit confusing when something like this happens ;)
[08:11] <pedronis> I didn't know somebody was already reviewing it
[08:11] <pedronis> pstolowski: anyway I added exactly lines at the very end: https://github.com/snapcore/snapd/pull/7434/files#diff-81b90abba270c6b3849a0191b406c81bR719
[08:11] <mup> PR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
[08:11] <pedronis> there was a // check snap-revision  // ...  there
[08:12] <pstolowski> thanks
[08:13] <pstolowski> pedronis: btw all the //XXX: channel stuff is waiting for John's changes?
[08:14] <pedronis> pstolowski: no, I added to the description now, it is taken care in a follow up just about channel
[08:14] <pstolowski> ok
[08:14] <pedronis> though I expect later changes again because of some decisions about UC20 models
[08:14] <pedronis> pstolowski: it's done in #7467
[08:14] <mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[08:15] <pedronis> 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] <pedronis> but big things are taken are along the sequence
[08:16] <pedronis> 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] <pedronis> pstolowski: we do use just a for assertion here and there, is not the only place there
[08:19] <pedronis> I mean across the codebase
[08:19] <pstolowski> pedronis: ok, fair enough
[08:46] <mborzecki> pedronis:  pushed an update to #7166
[08:46] <mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
[08:47] <pedronis> mborzecki: thx, queued to look at
[08:47] <mborzecki> pedronis: great, thank you!
[09:26] <pedronis> mborzecki: are you going to work on the issue with invalid old gadgets that was discussed yesterday?
[09:26] <mborzecki> pedronis: yup, i'm working on it right now
[09:27] <pedronis> thx
[09:30] <pedronis> pstolowski: right now it seems you are commenting on some code that exists already like that in image.go
[09:30] <pedronis> not saying that it might not get more confusing now that is getting lifted
[09:31] <pedronis> and might need more comments
[09:31] <pedronis> but a bit of context maybe is useful
[09:32] <pedronis> pstolowski: I put a link to the original code in the response to one of your comments
[09:32] <pstolowski> pedronis: hmm, maybe... it's the inherent problem of stacked PRs :( (not your fault by any means)
[09:32] <pstolowski> easy to get lost
[09:33] <Chipaca> 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] <mup> PR #6958: Added api endpoint for downloading snaps <Created by glower> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6958>
[09:33] <Chipaca> pedronis: do you?
[09:34] <pedronis> Chipaca: we might want to send alternative auth bits or http proxy config at some point it
[09:34] <pedronis> it would get unwieldy as GET params
[09:35] <Chipaca> fair
[09:35] <Chipaca> mvo: ^^^
[09:37] <pedronis> 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] <mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
[09:41] <pedronis> pstolowski: btw fwiw I fixed the chaining ref in 7468, it's based on #7467
[09:41] <mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[09:41] <Chipaca> if y'all are hungering for something to review, #7320 is sitting there
[09:41] <mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
[09:47] <pedronis> Chipaca: I queued it, I skimmed it, it seems to need a couple of tweaks
[09:58] <zyga> mvo: I'll get some meds and work on triaging
[09:59] <zyga> mvo: I worked with roger in the morning, I have some updates on that, save them to the doc
[10:04] <pedronis> 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] <zyga> pedronis: we discovered that yesterday
[10:11] <pstolowski> 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] <mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
[10:17] <mvo> pedronis: just read backlog (meeting is over) - yes, thats serious and needs fixing :/
[10:30]  * pstolowski lunch and school run
[10:37] <mup> PR snapd#7507 opened: gadget: do not fail the update when old gadget snap is missing bare content <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7507>
[10:44] <zyga> mvo, pedronis: I updated the forum and created a detailed bug report
[10:59] <pedronis> zyga: I commented there, what's the right solution is not super clear to me
[10:59] <pedronis> we need to discuss further
[11:00] <zyga> 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] <cachio> mvo, hey
[11:32] <cachio> yesterday I was researching a bit an error on the rpi
[11:32] <cachio> for core 18 tests
[11:33] <cachio> I see that for arm devices the file /boot/grub/grubenv does not exist
[11:33] <cachio> and for amd64 and i386 it exists
[11:33] <cachio> do you know the reason?
[11:33] <ogra> arm doesnt use grub
[11:34] <ogra> instead you should have /boot/ubot
[11:34] <ogra> */boot/uboot
[11:34] <cachio> ogra, I have it
[11:34] <cachio> right
[11:34] <ogra> (and everything in snapd should take that into account=
[11:34] <ogra> )
[11:34] <cachio> so how should I get the env vars?
[11:35] <cachio> should we compile fw_printenv right?
[11:35] <ogra> 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] <cachio> ogra, ah, ok
[11:36] <ogra> 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] <ogra> we had some setup in core16
[11:37] <cachio> well in this case I'll have to skip this test for arm devices until we define an alternative path for it
[11:37] <cachio> thanks ogra
[11:37] <cachio> for the explanation
[11:37] <ogra> (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] <cachio> ogra, indeed
[11:43]  * Chipaca wanders off in search of sustenance
[11:44] <pedronis> cachio: mvo: sounds we might have to consider bringing it back, either in core or snapd
[11:44] <ogra> +1 !!
[11:45] <zyga> pedronis: snap debug boot-env {set,get,unset} ?
[11:45] <zyga> pedronis: so that snapd code for working with environment is exercised
[11:45] <mup> PR snapd#7508 opened: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7508>
[11:46] <pedronis> zyga: maybe
[11:46] <zyga> perhaps even as direct in snap thing
[11:46] <zyga> so that it can be used at all times
[11:46] <zyga> but not sure about that
[11:47] <pedronis> no, that seems strange
[11:47] <zyga> yeah, it's better to do it "for real" via snapd
[11:48] <ogra> 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] <zyga> yeah, I think that's key
[11:50] <pedronis> zyga: I missed what you meant
[11:50] <zyga> pedronis: that _a_ tool is available
[11:51] <pedronis> no, I though with direct, you meant snap boot-env, snap debug boot-env
[11:51] <pedronis> not about skipping snapd
[11:51] <zyga> ah, sorry, I meant snap <something not top level> boot-env
[11:51] <pedronis> either it's an area that will be in flux soon
[11:51] <pedronis> so a bit hard to start on this now
[11:51] <zyga> yeah
[11:59]  * zyga lunches
[12:10] <Chipaca> ogra: in https://forum.snapcraft.io/t/partition-layout-for-snappy/656/47
[12:10] <Chipaca> ogra: i know most of the words, but not in the order you're using them :-p
[12:10] <Chipaca> ogra: so, what would be a good title for the new topic that started tehre today?
[12:10] <Chipaca> ogra: so I can split it out as it doesn't seem to be related to the previous one
[12:15] <zyga> 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] <mup> Bug #1822337: Support for setting PIDFile for "forking" daemons <snapd:Triaged> <https://launchpad.net/bugs/1822337>
[12:15] <Chipaca> mmm, forks
[12:16] <Chipaca> zyga: I'd call that a papercut
[12:16] <Chipaca> zyga: is that what you're asking me?
[12:17] <zyga> if that's sensible in your eyes let's tag it and move on
[12:17] <Chipaca> zyga: yeap
[12:17] <Chipaca> 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] <zyga> Chipaca: at the 8th day of the week
[12:18] <Chipaca> zyga: and yes I pulled that number out of ... thin air
[12:18] <zyga> ;)
[12:18] <Chipaca> osvaldo
[12:20] <zyga> 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] <mup> Bug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1823768>
[12:20] <zyga> you're assigned to it as well
[12:20] <zyga> I've triaged it so I'll leave the rest to you, if you want to update the status please do so
[12:21] <Chipaca> zyga: that one has not been fixed afaik
[12:22] <pedronis> Chipaca: I might have fixed it in my remodel work
[12:22] <Chipaca> pedronis: was about to ask
[12:22] <pedronis> but we never reproduced it
[12:22] <Chipaca> pedronis: but even when it was reported it wasn't clear how to repro
[12:22] <Chipaca> yeah
[12:23] <pedronis> to be precise I found a place that was buggy in my remodel work and fixed it
[12:23] <pedronis> I don't know of any other place
[12:23] <pedronis> but might exist
[12:24] <pedronis> the place was in the alias handling code
[12:24] <pedronis> for an update
[12:27] <pedronis> mborzecki: #7166 is failing the static tests
[12:28] <mborzecki> duh
[12:28] <mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
[12:28] <mborzecki> let me see
[12:29] <zyga> kenvandine: is snap-store bug tracker on lauchpad?
[12:30] <zyga> kenvandine: can you please reassign this bug as appropriate https://bugs.launchpad.net/snapd/+bug/1824166
[12:30] <mborzecki> pedronis: interesting, looks like that naked return been there since 04.2018
[12:30] <mup> Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>
[12:32] <mup> PR snapd#7503 closed: tests: restart the journald service while preparing the test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7503>
[12:35] <zyga> hmmm, launchpad timeouts are somewhat common
[12:35] <mborzecki> 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] <ogra> Chipaca, hmmm which bits exactly do you want to split out ?
[12:36] <pedronis> mborzecki: what changed? anyway 5+ seems a bit too conservative but no strong opinion there
[12:37] <mborzecki> 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] <ogra> Chipaca, note that i only pointed to a howto from mvo to install to internal MMC ...
[12:37] <pedronis> mborzecki: let me look at that function and form an opinion :)
[12:38] <mborzecki> haha
[12:38] <mborzecki> 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] <zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1826064 is something you may be interested in as a hobby interest :)
[12:40] <mup> Bug #1826064: snap command outputs unicode in publisher name even when locale is ascii <cdo-qa> <foundations-engine> <snapd:Confirmed> <https://launchpad.net/bugs/1826064>
[12:40] <Chipaca> zyga: ikr
[12:41] <Chipaca> ogra: from shubham's question today down
[12:41] <ogra> 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] <ogra> so i dont think it is in the wrong place
[12:42] <pedronis> mborzecki: we could bump the default to -l 10 , 30 seems a bit much to me
[12:43] <Chipaca> ogra: ah, fair enough
[12:43] <pedronis> though
[12:44] <ogra> 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] <pedronis> mborzecki: a bit your call what you want to do there, either bump or fix
[12:44] <ogra> (in case your board has fastboot support in the ROM/first-stage-bootloader)
[12:45]  * ogra notes his typing sucks today :(
[12:45] <mborzecki> pedronis: already pushed a fix to use named arguments with return
[12:45] <zyga> 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] <pedronis> mborzecki: ok
[12:45] <mup> Bug #1826470: Can't launch brave from dock <snapd:Confirmed> <https://launchpad.net/bugs/1826470>
[12:46] <mborzecki> wow, our standup notes are *long* :P
[12:47] <pstolowski> mborzecki: we need a second document with only a highlights of the first one ;)
[12:48] <mborzecki> pstolowski: should employ some ML to distill the most important bits
[12:48] <cmatsuoka> I'm trying to keep it with a civilized level of detail
[12:48] <zyga> mborzecki: Machine Learning? :D
[12:48] <mborzecki> zyga: yup
[12:48] <zyga> I try to use a sub-points for details
[12:49] <zyga> and main points for highlights
[12:49] <zyga> this way you can just briefly read the report without needing to deduce what's detail and what's overview
[12:51] <cmatsuoka> after a few months we can feed it to a markov chain of sorts and have an entirely new set of activities
[12:52] <kenvandine> zyga: snap-store is strict, so not sure what I can do from within the confined snap to fix dns resolution
[12:52] <kenvandine> zyga: looks like something isn't properly exposed in the sandbox
[12:54] <zyga> kenvandine: perhaps the issue is fixed now
[12:54] <zyga> kenvandine: it was classic earlier if I recall correctly
[12:56] <kenvandine> It was briefly published to edge as classic
[12:56] <kenvandine> only for a couple days though, about 18 months ago
[12:57] <kenvandine> this bug report is only a few months old
[12:57] <kenvandine> i think the reporter is saying classic snaps work and strict snaps do not
[12:58] <kenvandine> vscode can access network, firefox can not
[12:58] <zyga> ah, perhaps I misread the bug
[12:58] <zyga> can you add this to the bug, I'll look at it on the next pass
[12:58] <kenvandine> that is in the bug :)
[12:59] <kenvandine> he explains that firefox can't access the network but vscode can.
[12:59] <kenvandine> and he explains that vscode is classic and hints that is why it works
[12:59] <kenvandine> i'll comment on the bug though
[12:59] <ijohnson> zyga: quit triaging bugs, it's my day today!
[12:59] <zyga> 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] <Chipaca> kenvandine: zyga: which bug is this?
[13:00]  * ijohnson accepts zyga's apology in exchange for more polish sweets at next sprint
[13:00] <zyga> ijohnson: I'll send you the menu ;)
[13:00] <Chipaca> kenvandine: zyga: please don't say kali
[13:00] <ijohnson> :-)
[13:00] <zyga> 2fa
[13:01] <kenvandine> Chipaca: bug 1824166
[13:01] <kenvandine> it's Deepin
[13:01] <mup> Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>
[13:02] <kenvandine> I moved it out of invalid until it gets looked at again
[13:02] <Chipaca> kenvandine: deepin has some kind of issue somewhere
[13:02] <Chipaca> kenvandine: snaps that need network, or x, don't work right
[13:03] <Chipaca> or maybe x is just kali?
[13:03] <Chipaca> kenvandine: https://forum.snapcraft.io/t/deepin-debian-9-snaps-have-no-internet-connection/11295/7?u=chipaca
[13:06] <Chipaca> ah, kali was the weird "homes are in /" thing
[13:06]  * Chipaca gets them confused
[13:08] <kenvandine> zyga: ok, the theory is confirmed by that forum post.
[13:26] <zyga> 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] <mup> Bug #1834688: connections stanza in gadget.yaml requires snap id <snapd:Confirmed> <https://launchpad.net/bugs/1834688>
[13:33] <cachio> mvo, I could reproduce the error running the interfaces-many-core-provided using a vm
[13:33] <cachio> here
[13:34] <cachio> I need to re run to start printing more information
[13:34] <cachio> debug information
[13:35] <cachio> what I saw is that the cpu went to 170% and then it didn't accepted any connection anymore
[13:35] <cachio> accept
[13:37] <mvo> cachio: cool, thank you!
[13:38]  * zyga breaks for coffee
[13:38] <zyga> mvo: snapd will have 0 new bugs today :)
[13:38] <zyga> mvo: the next pass will need to look at snappy
[13:38] <zyga> mvo: and finally at gardening all open bugs
[13:39] <mvo> zyga: \o/
[13:42] <zyga> not sure who's interested in seeding today but...
[13:42] <zyga> https://bugs.launchpad.net/snapd/+bug/1835795 is something that might impact design of the command that creates the seed structure
[13:42] <mup> Bug #1835795: seeding a snap with higher assumes than deb pkg of snapd on classic fails <snapd:Confirmed> <https://launchpad.net/bugs/1835795>
[13:42] <zyga> ping pedronis for architectural consideration, I think you can just read the 1st comment on the bug for a brief summary
[13:44] <zyga> 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] <pedronis> zyga: I fear it's medium
[13:44] <mup> Bug #1835805: strict snap run from classic snap can't write to filesystem <snapd:Triaged> <https://launchpad.net/bugs/1835805>
[13:44] <zyga> pedronis: please reassign the priority as you see fit
[13:45] <ijohnson> zyga: yay for triaging my bugs
[13:45] <zyga> ijohnson: thank you for filing nice bugs :)
[13:45] <ijohnson> 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] <pedronis> zyga: made a comment as well, I don't think it's a seeding time validation problem
[13:47] <zyga> 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] <pedronis> zyga: that's even a different problem
[13:47] <pedronis> we are talking assumes here
[13:47] <pedronis> we haven't really changed the seed format in a long while
[13:48] <zyga> that's true
[13:48] <zyga> that's a separate issue
[13:48] <pedronis> at some it becomes a "it hurts then don't do it" sort of situation
[13:48] <pedronis> assumes are bound to change quicker than sruing so I understand the concern
[13:49] <zyga> pedronis: indeed
[13:49] <pedronis> my point is mostly I don't think we need an unrealistically general solution
[13:49] <zyga> pedronis: I think as long as snapd can reexec it could be handled with proper logic in snapd itself
[13:49] <pedronis> still feels medium to me
[13:49] <zyga> sure, I think that as we do this more often (now) we will get a broader shared understanding of each priority
[13:50] <ijohnson> 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] <pedronis> ijohnson: you can do a bit reviewing, I'll try to get to some of your PRs today myself
[13:51] <ijohnson> ack, thanks!
[13:56] <mup> PR snapd#7509 opened: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
[14:13] <pstolowski> 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] <pstolowski> need to fall back to something else. not sure if it makes sense, may be confusing.
[14:22] <pedronis> pstolowski: it will be confusing
[14:23] <mup> PR snapd#7510 opened: daemon: make /v2/download take snapDownloadOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7510>
[14:24] <mup> PR snapd#7286 closed: tests: use images:ubuntu/ in lxd tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7286>
[14:24] <pstolowski> pedronis: so i think we need to stick to timestamps already available on Tasks. ReadyTime() ?
[14:25] <pedronis> pstolowski: no, we need to step back a bit and consider our options
[14:27] <mup> PR snapd#7447 closed: snapstate: do not allow removal of the snapd snap <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7447>
[14:27] <roadmr> but I want to use core without snapd 😤
[14:29] <Chipaca> roadmr: ?
[14:29] <roadmr> j/k Chipaca 😆
[14:29] <ijohnson> roadmr: there's an experimental option in edge that I think you can use now if you wanted to be serious
[14:30] <roadmr> ijohnson: not really, I mean, how would I even install stuff on a snapd-less core system...
[14:30] <ijohnson> you'd use the snapd snap and not the core snap!
[14:33] <mup> PR snapd#7506 closed: devicestate: add support for gadget->gadget remodel <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7506>
[14:34] <mup> PR snapd#7377 closed: patch: add an overlord patch that normalizes channel in state <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7377>
[14:34] <mup> PR snapd#7495 closed: [RFC] tests: add gh action for static checks <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7495>
[14:35] <diddledan> don't you need the snapd snap installed to be able to install the snapd snap?
[14:35] <diddledan> bootstrapping is hard
[14:36] <ijohnson> no first you install the "snap your fingers to turn the lights on" thing from night at the museum, then you snap your fingers and install the snapd snap
[14:36] <diddledan> doesn't snapping your fingers make 50% of all living things disappear?
[14:37]  * ijohnson stops snapping fingers
[14:37] <mup> PR snapcraft#2729 closed: snaps: if snap is installed, don't check is_valid() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2729>
[14:37] <pedronis> pstolowski: one option is to return the actual info about what waits for what and do a topological sort (in the client), generally in a lane tasks are sequential so ready time is probably as good as start time. so sortint (min(lanes), ready time) seems ok, except we need to think what to do about lane 0 tasks
[14:37] <pedronis> if we go that way
[14:54] <pedronis> pstolowski: I have a meeting now, do you want to have a chat in ~45 mins or tomorrow?
[14:55] <pstolowski> pedronis: later today works for me
[14:55] <pedronis> pstolowski: ok, I'll ping you
[14:55] <pstolowski> pedronis: thanks!
[14:56] <cachio> mvo, when it gets stuck I see this https://paste.ubuntu.com/p/CNb5P2Kf7K/
[15:02] <cachio> mvo, the problem seems to be with the focker-support interface
[15:02] <zyga> focker-support?
[15:02] <zyga> did we add a new interface? ;-)
[15:03] <diddledan> damn those fockers
[15:03] <zyga> cachio: can you look at journal  please? anything interesting there
[15:03] <cachio> zyga, no I can't
[15:03] <cachio> the machine is dead
[15:03] <cachio> I'll run again
[15:03] <cachio> and print the journal
[15:03] <zyga> diddledan: those fockers were meserszmits
[15:03] <zyga> cachio: interesting
[15:03] <zyga> cachio: is it responding to ping?
[15:03] <cachio> perhaps doing that I can get nicer information
[15:04] <zyga> cachio: ping is a good way to check if the kernel is up
[15:04] <zyga> cachio: but userspace is bonkers
[15:04] <zyga> cachio: please try that the next time if you can
[15:04] <zyga> cachio: keep pinging the machine
[15:04]  * diddledan spits some fire
[15:04] <cachio> zyga, sure
[15:04] <cachio> I'll make another round
[15:04] <zyga> cachio: once ping stops working it's a good indicator that the kernel went belly up
[15:05] <zyga> cachio: how do you reproduce this issue roughly?
[15:05] <diddledan> or you tripped over the cable
[15:05] <zyga> I don't want to jump into it
[15:05] <zyga> but I'm curious for tomorrow
[15:05] <zyga>    33 root      20   0       0      0      0 S  66.0  0.0   0:09.06 kswapd0
[15:05] <cachio> zyga, spread2 -repeat 10 -show-output external:ubuntu-core-16-64:tests/main/interfaces-many-core-provided
[15:05] <zyga> this feels like OMG MEMORY
[15:05] <zyga> KiB Swap:        0 total,        0 free,        0 used.    15462 avail Mem
[15:05] <zyga> and in fact, we have no swap
[15:05] <diddledan> who needs swap?!
[15:05] <cachio> with core 16 image from beta
[15:06] <zyga> cachio: can I ask you to run another command in a separate connection
[15:06] <cachio> zyga, yes
[15:06] <zyga> cachio: run slabtop
[15:06] <zyga> in case it is memory
[15:07] <cachio> zyga, sure
[15:07] <zyga> cachio: external, is the target a physical machine?
[15:07] <zyga> cachio: or kvm?
[15:07] <cachio> kvm
[15:08] <cachio> running in my laptop
[15:09] <zyga> cachio: perhaps log in as root
[15:09] <zyga> cachio: on the console
[15:09] <zyga> (if you have one)
[15:09] <cachio> yes
[15:09] <cachio> I do that
[15:09] <ogra> wiggle the cable !!
[15:12] <cachio> zyga, running
[15:12] <cachio> zyga, I am having lunch and then I'll show you the output
[15:12] <zyga> thanks
[15:12] <cachio> zyga, to you
[15:13] <zyga> I may be away but I'll happily look tomorrow
[15:13] <cachio> zyga, sure
[15:13] <cachio> I'll continue researching this one
[15:13] <cachio> zyga, thanks for the support
[15:13] <zyga> I'm very curious to see what this will uncover
[15:17] <pedronis> pstolowski: my meeting was quicker than usual, let me know when you can chat
[15:17]  * cachio lunch
[15:19] <zyga> mvo: hey, a quick question about https://bugs.launchpad.net/snapd/+bug/1840375 -- is it the case that we can now pass --extrausers to groupdel?
[15:19] <mup> Bug #1840375: groupdel doesn't support extrausers <verification-needed> <verification-needed-bionic> <verification-needed-disco> <verification-needed-xenial> <snapd:Triaged by mvo> <shadow (Ubuntu):Fix Released by mvo> <shadow (Ubuntu Xenial):Fix Committed> <shadow (Ubuntu Bionic):Fix Committed>
[15:19] <mup> <shadow (Ubuntu Disco):Fix Committed> <https://launchpad.net/bugs/1840375>
[15:19] <pstolowski> pedronis: ok, i'm ready
[15:20] <pedronis> pstolowski: going to the standup
[15:22] <ogra> zyga, looks like the SRU isnt finished
[15:23] <ogra> (so you could ... but only in "eoan core")
[15:26] <zyga> ah, I didn't notice the "green" is fix commited
[15:26] <zyga> oh well
[15:29] <mvo> zyga: yes, iirc I added this to groupdel, let me double check
[15:30] <mvo> zyga: https://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.5
[15:30] <zyga> mvo: so is the bug fix committed now?
[15:30] <zyga> mvo: actually, can you just update the bug as you see fit
[15:31] <mvo> zyga: its in -proposed
[15:31] <mvo> zyga: in a meeting
[15:31] <zyga> sure
[15:46] <mup> PR snapcraft#2730 opened: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>
[16:03]  * ijohnson takes a break
[16:05] <mup> Bug #1606539 changed: handle errors from `snap create-user` gracefully <snapd:Triaged> <https://launchpad.net/bugs/1606539>
[16:05] <mup> Bug #1609864 changed: Enable a command to be run on machine shutdown <cpc> <snapd:Triaged> <https://launchpad.net/bugs/1609864>
[16:05] <mup> Bug #1633141 changed: gadget.yaml should specify disk/volume image sizing behavior <snapd:Triaged by maciek-borzecki> <Ubuntu Image:New> <https://launchpad.net/bugs/1633141>
[16:05] <pedronis> mvo: I made a suggestion in #7348 , let me know what you think when you get to it
[16:05] <mup> PR #7348: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
[16:08] <mup> Bug #1620592 changed: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <snapd:Triaged> <https://launchpad.net/bugs/1620592>
[16:11] <mup> Bug #1621666 changed: It is possible to install the classic snap in a classic system <classic> <snapd:Confirmed> <https://launchpad.net/bugs/1621666>
[16:12] <Chipaca> who works on microk8s?
[16:12] <Chipaca> popey: do you know, offhand?
[16:13] <ogra> Chipaca, there is an upstream bug for the issue linked inside the topic
[16:13] <ogra> upstream sent him over to the forum
[16:13] <popey> https://github.com/ubuntu/microk8s/graphs/contributors
[16:13] <Chipaca> ah ok
[16:13] <Chipaca> popey, ogra, thanks
[16:13] <ogra> and there is no logical reason that this happens at all !!
[16:13] <popey> logic... lulz
[16:13] <ogra> neither is it reproducable
[16:14] <ogra> (i mean not reproducable for any of us but fully reproducable for that user)
[16:17] <mvo> pedronis: thank you, I check it out
[16:19]  * Chipaca puts on his running shoes
[16:25]  * zyga EODs
[16:26] <pedronis> Chipaca: I did a pass on #7320
[16:26] <mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
[16:26] <Chipaca> pedronis: thank you
[16:31] <ogra> oh, wow ... another missing symlink issue !
[16:33] <Chipaca> internet is needed to catch the etherbunny
[16:34] <Chipaca> I'm soft-EODing and going for a run
[16:34] <Chipaca> should be back in under an hour to poke at this a bit more
[16:35] <ogra> well, i bet the reinstall will just fix it
[16:35] <popey> of the snap or the whole machine?
[16:35] <popey> also "fix" :)
[16:35] <ogra> of snapd
[16:36] <popey> refreshing core or installing the snapd should trigger that?
[16:36] <ogra> well, he said core was pre-installed
[16:36] <popey> no, i mean, refreshing rather than uninstall/reinstall
[16:37] <ogra> my guess is something went wrong with initial seeding or so
[16:37] <ogra> ah
[16:37] <popey> plusible
[16:37] <popey> could we add some checks at startup, that if a snap is marked installed, it must have a current directory?
[16:37] <ogra> well, john already asked him to purge/reinstall ... i guess it is to late to check if refresh would have helped
[16:38] <Chipaca> yeah, seed.yaml busted is a safe bet
[16:38] <Chipaca> hopefully we can find the image and get it fixed
[16:38] <Chipaca> anyway! run run run run
[16:38]  * Chipaca disappears in a cloud of sweat
[16:39]  * ogra sprays some deodorant around
[16:56] <cachio> slabtop : https://paste.ubuntu.com/p/NTS4DCWKmG/
[16:56] <cachio> zyga,
[17:28] <mup> PR snapcraft#2730 closed: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>
[18:44] <mup> Issue classic-snap#33 opened: It is possible to install the classic snap in a classic system <Created by anonymouse64> <https://github.com/snapcore/classic-snap/issue/33>
[18:55] <mup> PR snapd#7511 opened: tests: when the backend is external skip the loop waiting for snap version <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7511>
[19:08] <cachio> zyga, I updated the standup doc with the details about the issue
[19:08] <cachio> zyga, the problem is related to memory
[19:08] <cachio> see you
[19:48] <mup> Bug #1626082 changed: Fedora 24 install fail with snapd 2.14 <snapd:Fix Released> <https://launchpad.net/bugs/1626082>
[19:48] <mup> Bug #1627860 changed: run fail at missing folder /lib/modules (eg. on a virtual host) <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1627860>
[19:51] <mup> Bug #1639798 changed: enable gpio interface for rpi2/3 (and other boards if suited) <gadget> <Snappy:Fix Released> <https://launchpad.net/bugs/1639798>
[19:51] <mup> Bug #1639952 changed: When running in unity8 desktop snap, snap application icons aren't found in app scope <personal> <Canonical System Image:Fix Committed by pat-mcgowan> <Snapcraft:Confirmed> <snapd:New> <ubuntu-app-launch (Ubuntu):Fix Released> <https://launchpad.net/bugs/1639952>
[19:57] <mup> Bug #1649399 changed: 'daemon: dbus' is incomplete <snap-docs> <snapd:New> <https://launchpad.net/bugs/1649399>
[19:57] <mup> Bug #1655834 changed: Support factory reset <snapd:In Progress> <https://launchpad.net/bugs/1655834>
[20:00] <mup> Bug #1630976 changed: Incomplete home directory mapping <snapd:Confirmed> <https://launchpad.net/bugs/1630976>
[20:04] <mup> Bug #1625817 changed: Document snap prepare-image options <snapd:Fix Released> <https://launchpad.net/bugs/1625817>
[20:10] <mup> Bug #1635101 changed: /snap/bin is not added to path for "sudo su" <snapd:Confirmed> <https://launchpad.net/bugs/1635101>
[20:16] <mup> Bug #1637934 changed: update install hook documentation <snapd:New> <https://launchpad.net/bugs/1637934>
[20:47] <mup> PR snapd#7512 opened: Misc updates for strict k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7512>
[20:49] <mup> PR snapd#7513 opened: interfaces/docker-support,kubernetes-support: misc updates for strict k8s - 2.42 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7513>
[20:59]  * cachio EOD
[21:11] <mup> PR snapcraft#2731 opened: meta: take no command-chain being prepended into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2731>
[21:20] <mup> PR snapcraft#2727 closed: storeapi: use the channels attribute in push <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>