[05:20] <mborzecki> morning
[07:45] <zyga> re
[07:46] <zyga> 30 min
[07:46] <zyga> till meds
[07:47] <zyga> thank you for moving the call
[07:48] <zyga> uh, lots of pain
[08:14] <mborzecki> pedronis: hi, wondering maybe we should try to cherry-pick to 2.45 the commits that tweak spread.yaml so that we get the caching behavior from master
[08:19] <mup> PR snapd#9042 opened: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
[08:22] <pedronis> mborzecki: yes, possibly, I'm still trying to land #9012 first
[08:22] <mup> PR #9012: release/2.45: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
[08:40] <mup> PR snapd#9043 opened: daemon: decompose access check into smaller primitive access checkers <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
[08:45] <mup> PR snapd#9044 opened: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[08:45] <mborzecki> pedronis: ^^ let's see how far that PR will run
[09:16] <zyga-x240> okay, so this is much more lucid now
[09:16] <mborzecki> zyga-x240: https://github.com/snapcore/snapd/pull/9042 apparmor cherrypicks
[09:16] <mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
[09:16] <mborzecki> zyga-x240: and https://github.com/snapcore/snapd/pull/9044 that's the gh actins caching tweaks
[09:16] <mup> PR #9044: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[09:16] <mborzecki> and it's red (unsurprisingly?)
[09:18] <ogra_> hmm, does command-chain only work for nondaemon apps ?
[09:18] <zyga-x240> ogra_: it should not matter
[09:18] <ogra_> (it does nto seem to get executed for me )
[09:18] <ogra_> *not
[09:19] <ogra_> weird
[09:19] <zyga-x240> looking at the failures
[09:19] <ogra_> oh !
[09:20] <ogra_> seems snapcraft ignores changes in snap/local (where my script lives) 😛
[09:20] <zyga-x240> just preseed failures
[09:20]  * ogra_ manually cleans the part 
[09:20] <zyga-x240> well, in 19.10 - more failures elsewhere
[09:21] <zyga-x240> shellcheck issues
[09:45] <zyga-x240> pain slowly going away
[09:59] <mborzecki> pedronis: i've left a note about failures in https://github.com/snapcore/snapd/pull/9012 i think we should just force merge and i'll start cherry-picking the obvious things (cc zyga-x240)
[09:59] <mup> PR #9012: release/2.45: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
[10:00] <zyga-x240> looking
[10:01] <zyga-x240> I've ran the unit tests test alone and it passed
[10:01] <zyga-x240> so maybe random as well
[10:01] <zyga-x240> ah drat, wrong branch
[10:01] <pedronis> mborzecki: thx, other emergency maybe solved
[10:01] <pedronis> we'll see
[10:01] <zyga-x240> I agree we should merge
[10:01] <zyga-x240> and iterate
[10:01] <pedronis> I'look in a bit
[10:07] <pedronis> zyga-x240: mborzecki: merged
[10:07] <pedronis> mborzecki: it seems most thing you mentioned worth cherry picking are kind of small?
[10:07] <pedronis> mborzecki: maybe worth doing one PRs with them, most of them?
[10:07] <pedronis> to 2.45?
[10:08] <mborzecki> pedronis: yes, i'll do it
[10:08] <mborzecki> pedronis: thanks for merging the branch
[10:10] <mup> PR snapd#9012 closed: release/2.45: merge 2.45.2 release <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9012>
[10:12] <zyga-x240> we have this 41d38c4b7f7554bdef88d567608241930a237cd9
[10:13] <zyga-x240> let me check if that is in the release branch
[10:13] <zyga-x240> (nfs fix)
[10:14] <mborzecki> zyga-x240: ah, cool
[10:15] <zyga-x240> one sec
[10:15] <mup> PR snapd#9039 closed: cmd/snap-seccomp/syscalls: add faccessat2 (2.45) <Simple 😃> <⛔ Blocked> <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/9039>
[10:16] <zyga-x240> https://github.com/snapcore/snapd/pull/9045
[10:16] <mup> PR #9045: Disable part of the nfs-support test that checks udp proto on debian-… <Created by zyga> <https://github.com/snapcore/snapd/pull/9045>
[10:17] <zyga-x240> now about https://github.com/snapcore/snapd/pull/9044
[10:17] <mup> PR #9044: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[10:17]  * zyga-x240 looks at failures
[10:17] <mborzecki> zyga-x240: looked at failures already, i'll stat pushing cherry-picks there
[10:17] <mborzecki> zyga-x240: also, will pick 9045
[10:17] <zyga-x240> ok
[10:20] <mup> PR snapd#9045 opened: Disable part of the nfs-support test that checks udp proto on debian-… <Created by zyga> <https://github.com/snapcore/snapd/pull/9045>
[10:23] <mborzecki> zyga-x240: pushed most to #9044, i need to look at the PR with preseed tests, either pick everything from it or just https://github.com/snapcore/snapd/commit/0a9a25f1b4c3a711a96874a1d14933d01a97e0e8
[10:23] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[10:28] <zyga-x240> mborzecki: shall I push there directly?
[10:30] <mborzecki> zyga-x240: hmm, yes, but maybe let's wait for spread jobs to run through
[10:30] <zyga-x240> ok
[10:33] <mborzecki> zyga-x240: btw. tests/main/lxd has changed quite a bit, one from 2.45 branch is failing spread-shellcheck locally here: https://paste.ubuntu.com/p/W9htPXc3bx/
[10:35] <mborzecki> zyga-x240: hm fixes are trivial, so i'll just fix it rather than picking even more patches :/
[10:37] <zyga-x240> eh, silly shellcheck
[10:37] <zyga-x240> ok
[10:48]  * zyga-x240 backported preseed fixes, testing now
[10:52]  * zyga-x240 looks at go
[11:03] <zyga-x240> https://github.com/snapcore/snapd/pull/9046 has the preseed changes, it should be merged into https://github.com/snapcore/snapd/pull/9044 when another round of tests passes
[11:03] <mup> PR #9046: tests: backport preseed test fixes to 2.45 <Created by zyga> <https://github.com/snapcore/snapd/pull/9046>
[11:03] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[11:04] <mborzecki> zyga-x240: thanks
[11:05] <mborzecki> wow, commits form april
[11:05] <mborzecki> from
[11:05] <zyga-x240> we should release 2.46
[11:05] <zyga-x240> even if it's not in stable
[11:05] <zyga-x240> just try to iterate
[11:05] <mup> PR snapd#9046 opened: tests: backport preseed test fixes to 2.45 <Created by zyga> <https://github.com/snapcore/snapd/pull/9046>
[11:06] <mborzecki> zyga-x240: hm maybe i should just cherry-pick everything from 9046 to 9044
[11:06] <zyga-x240> yes
[11:06] <zyga-x240> git merge it
[11:06] <mborzecki> mhm
[11:06] <zyga-x240> I opened it separately to see how it behaves
[11:06] <mborzecki> will do
[11:14] <mborzecki> zyga-x240: one more cherry-pick i didn't notice before: https://github.com/snapcore/snapd/commit/6c09de0f3f
[11:14] <zyga-x240> ah
[11:15] <zyga-x240> put it directly into your fixes branch
[11:23] <mborzecki> yup
[11:37] <pedronis> mborzecki: the plan is to land only 9044?
[11:39] <mborzecki> pedronis: yes, i plan to push necessary fixes to 9044, land it, and then rebase #9042 on top
[11:39] <mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
[11:40] <mborzecki> pedronis: the good part is that most changes, if not all are in tests
[11:41] <pedronis> mborzecki: sounds good
[11:44] <zyga-x240> hmmm
[11:44] <zyga-x240> is there anything in go that guarantees errno is set to zero before C calls?
[11:44] <zyga-x240> because if not then user/ is buggy
[11:55] <zyga-x240> ijohnson: around?
[11:55] <zyga-x240> mborzecki: maybe cherry pick the travis test away as well :D
[11:56] <pedronis> zyga-x240: go in general does it own syscall handling, it not following C conventions
[11:57] <ijohnson> zyga, not quite yet still having breakfast but I'll be into the office in 30 min or so
[11:57] <pedronis> I suspect cgo does the right thing
[11:57] <pedronis> but would need to dig
[11:57] <zyga-x240> mmm
[11:57] <zyga-x240> ijohnson: ok
[11:57] <zyga-x240> talk to you later
[11:58]  * zyga-x240 reviewed https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453246893
[11:58] <mup> PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Preseeding 🍞> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
[11:58] <mborzecki> zyga-x240: all of it now https://github.com/snapcore/snapd/pull/9044 hopefully we can land it once the spread jobs finish
[11:58] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[11:58] <zyga-x240>  brb
[12:03] <paul424> I try to modfiy the file : /snap/opendungeons/27/etc/opendungeons/plugins.cfg  ; I get non-writable file system. What should I do to modfiy the aforementioned file ? :)
[12:05] <mborzecki> paul424: is this fil expected to be modified by the end users?
[12:06] <mborzecki> heh, we have `var osutilFindGid = osutil.FindGid` in journal.go which does not appear to be used?
[12:06] <paul424> well yes and no, the friend of mine created ad hoc solution of packaging the OD into snap; usually the user is expected to modfiy the file plugins.cfg in Ogre3d game engine for example : to set the proper path of the rendering plugins
[12:07] <mborzecki> pedronis: all patches (sans apparmor backports) are now in https://github.com/snapcore/snapd/pull/9044 if you want to take a look
[12:07] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[12:07] <paul424> so... but I remember I somehow by-passed this and run succesfully OD .... problem is I don't remember how...
[12:07] <mborzecki> paul424: as those plugins something the user is expected to be able to add later?
[12:08] <mborzecki> s/as/are/
[12:08] <paul424> mborzecki: the rendering plugins comes with Ogre3d engine hmm ....
[12:09] <paul424> PluginFolder=/usr/lib/OGRE
[12:10] <paul424> cause troubles, also shoudn't that be reassigned to diffrent path if it is running under snap ? That is to the path of Snap's Ogre library ?
[12:13] <paul424> the snap ogre lib is in :  /snap/ogre/151/lib/
[12:13] <paul424> Does snapper create a virtual executable envoierment or something ?
[12:14] <zyga-x240> paul424: snaps are immutable filesysytems, they cannot be modified at all
[12:14] <paul424> great
[12:14] <zyga-x240> paul424: snap author should arrage for files that need to be modified to live in other places
[12:14] <zyga-x240> paul424: like $SNAP_DATA or $SNAP_USER_DATA
[12:14] <zyga-x240> paul424: there are ways to make this work but it requires some cooperation with the snap author
[12:14] <mborzecki> zyga-x240: in this case it sounds like ogre (the engine) is expected to be a content snap?
[12:15]  * zyga-x240 doesn't want to jump into details 
[12:16] <paul424> thanks for enlighting me :D
[12:34] <zyga-x240> mborzecki: https://github.com/snapcore/snapd/pull/9044 looks optimistic
[12:34] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[12:34]  * ijohnson is back
[12:34] <mborzecki> zyga-x240: yup
[12:34]  * ijohnson or maybe here for first time today
[12:34] <zyga-x240> ijohnson: +1 on the error checking for user lookup PR
[12:34] <ijohnson> thanks
[12:34] <zyga-x240> I had a look through go and meh
[12:35] <mborzecki> ijohnson: o hi, fun stuff with user lookup :/
[12:35] <zyga-x240> too much inconsistency
[12:35] <ijohnson> yeah it's a bit disappointing, but then again the man page for getgrpnam_r does kinda say it's impossible anyways
[12:35] <ijohnson> mborzecki: oh? what more fun stuff ?
[12:35] <zyga-x240> ijohnson: but I would expect _some_ level of consistency
[12:35] <zyga-x240> between the various backends
[12:35] <zyga-x240> but no, that's not the case
[12:36] <ijohnson> yeah
[12:37] <pedronis> zyga-x240: regarding your errno question, go in general seems to do it's own syscall handling, about cgo afaict it works as expected because th c code gets its own tls stuff, but this is as usual slightly hard to follow in the go code
[12:37] <zyga-x240> pedronis: right, I was only curious because some calls do not reset errno
[12:37] <zyga-x240> and I was wondering if cgo explicitly sets errno = 0 ahead of all calls
[12:38] <zyga-x240> the real bug is in the higher layer in go
[12:38]  * zyga-x240 starts a test and takes that break 
[12:40] <pedronis> zyga-x240: anyway cgo itself seems to emit "errno = 0" in some cases
[12:42] <pedronis> zyga-x240: see cmd/cgo/out.go in go itself
[12:43]  * zyga-x240 looks
[12:49] <mborzecki> ijohnson: while you're around, can you take a look at https://github.com/snapcore/snapd/pull/9030 ? :)
[12:49] <mup> PR #9030: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
[12:49] <zyga-x240> mborzecki: tests are failing on ...
[12:49] <zyga-x240>  2020-07-22T12:22:24.0548501Z        /tmp/sanity-squashfs-830795014: no space left on device
[12:50] <zyga-x240> 2020-07-22T12:22:24.0542897Z ##[error]2020-07-22 12:22:24 Error executing google:ubuntu-19.10-64:tests/main/install-store-laaaarge (jul221201-927192) :
[12:50] <mborzecki> pfffff
[12:50] <ijohnson> mborzecki: ah so sorry yes I will submit it now, I wrote all the comments and it seems I forgot to submit it :-)
[12:50] <zyga-x240> another failed on EOF from reboot
[12:50] <zyga-x240> 2020-07-22T12:42:59.1435778Z ##[error]2020-07-22 12:42:59 Error executing google:ubuntu-core-16-64:tests/core/reboot (jul221201-861200) : kill-timeout reached after jul221201-861200 (google:ubuntu-core-16-64:tests/core/reboot) reboot request
[12:51] <mborzecki> heh, gdoc does not like firefox
[12:51] <zyga-x240> one failed on preparing due to purge
[12:51] <mborzecki> zyga-x240: lxd?
[12:51] <zyga-x240> no, just prepare up front
[12:51] <ijohnson> mborzecki: submitted
[12:51] <zyga-x240> one more is in progress
[12:51] <mborzecki> zyga-x240: 8883 is still waiting
[12:52] <mborzecki> ijohnson: thanks
[12:52] <zyga-x240> I'd restart the three to see if they can land cleanly
[12:52] <zyga-x240> but I'd be fine with override as well
[12:52] <ijohnson> mborzecki: but did you see my question in IRC earlier? was there something else to know about the user stuff ?
[12:52] <mborzecki> ijohnson: probably missed it, what was the question?
[12:53] <ijohnson> mborzecki: oh you just said there was more fun, and I wasn't sure if you were just referring to the situation in general or something else that you found after looking at the PR
[12:53] <zyga-x240> mborzecki: 640GB should be enough for a google doc
[12:54] <mborzecki> ijohnson: ah, nah just the general state of things around that area
[12:54] <ijohnson> yeah rather sad
[12:54] <ijohnson> but good that we debugged it in MM some more and it sounds like CPC has a way forward in the meantime while waiting for the fix
[13:01] <mborzecki> zyga-x240: that failure in prepare is 8883
[13:01] <pedronis> ijohnson: standup?
[13:01] <ijohnson> yes
[13:02] <ijohnson> cachio: SU?
[13:16] <mborzecki> zyga-x240: restarted the spread job in https://github.com/snapcore/snapd/pull/9044
[13:16] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[13:16] <zyga-x240> ok
[13:27] <zyga-x240> ahh
[13:27] <zyga-x240> there's one thing I didn't do that jamie surely did
[13:27] <zyga-x240> run this as user!
[13:27] <mborzecki> zyga-x240: the caching behavior in #9044 is such a nice improvement now that i restarted the ci job
[13:27] <mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[13:27] <zyga-x240> :D
[13:43] <zyga-x240> why do we even bother with hangouts on non-mobile devices, mobile experience is just so much better
[13:44] <pedronis> zyga-x240: mborzecki: we can close 9045 and 9046 right?
[13:44] <zyga-x240> checking
[13:44] <zyga-x240> yes
[13:44] <zyga-x240> they are now in the big PR
[13:45] <ijohnson> pedronis: ok, so looking again the ones that are blocking things are these PR's: 8890, 8612, 8854, 8652, and 8795
[13:45] <mborzecki> pedronis: zyga-x240: closed them now
[13:45] <ijohnson> pedronis: the only ones that are not strictly snap-bootstrap related are the _writable-defaults thing, and a cloud-init related thing that needs to land with the _writable_defaults, otherwise the _writable-defaults PR as-is will undo the cloud-init fix
[13:46] <ijohnson> pedronis: if you like I can prepare a backport PR with all of those after 9044 lands cleanly
[13:46] <mup> PR snapd#9045 closed: Disable part of the nfs-support test that checks udp proto on debian-… <Created by zyga> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9045>
[13:46] <mup> PR snapd#9046 closed: tests: backport preseed test fixes to 2.45 <Created by zyga> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9046>
[13:47] <mborzecki> pedronis: ijohnson: for preseeding we may want https://github.com/snapcore/snapd/pull/9015 and https://github.com/snapcore/snapd/pull/9018 in .45 right?
[13:47] <mup> PR #9015: cmd/snap-preseed: handle relative chroot path <Bug> <Preseeding 🍞> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9015>
[13:47] <mup> PR #9018: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding 🍞> <Simple 😃> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9018>
[13:48] <ijohnson> mborzecki: yes to 8015, 9018 is nice to have but not necessary, it is just better error handling
[13:48] <mborzecki> ack
[14:04] <zyga-x240> break
[14:12] <mborzecki> pedronis: zyga-x240: so 9044 is looking good, the failure on 19.10 is probably related to user session fixes in tests that are done in master, but were not cherry-picked
[14:16]  * pedronis in meeting
[14:19] <zyga-x240> mborzecki: looking
[14:20] <zyga-x240> hmm
[14:20] <zyga-x240> 2020-07-22T13:47:54.7315113Z Failed to connect to bus: Connection refused
[14:20] <zyga-x240> yeah I think that's ok to merge
[14:20] <zyga-x240> +1 and let's rebase the rest
[14:20] <mborzecki> yup, doing so now
[14:20] <zyga-x240> ok
[14:21] <mup> PR snapd#9044 closed: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
[14:24] <mborzecki> zyga-x240: rebased https://github.com/snapcore/snapd/pull/9042 please take a look
[14:24] <mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
[14:36] <mup> PR snapd#9047 opened: cmd/snap-preseed: backport fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9047>
[14:37] <mborzecki> ijohnson: can you take a look ^^ ?
[14:38] <ijohnson> mborzecki: sure
[14:38] <mborzecki> ijohnson: thanks
[14:38] <ijohnson> I updated the getgrnam_r PR, but some of the code I changed has to do with sudo, so I would like some extra eyes on it
[14:51] <ijohnson> cachio: so regarding #9027, I think it is actually pretty unfortunate but I don't think we have another option right now, because there doesn't seem to be a way for us to identify the case where we have a real bug in snapd vs this bug in qemu where the system gets rebooted randomly in the middle of the test
[14:51] <mup> PR #9027: tests: refresh/revert snapd in uc20 <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
[14:51] <ijohnson> cachio: I think we need to just merge it with the changes you have and expect that the test is very flaky / fail often due to this qemu bug
[15:01] <cachio> ijohnson,
[15:01] <cachio> ok
[15:01] <cachio> I'll try a new change with the gce platform to see if it improves
[15:01] <mborzecki> ok, the ci jobs are running, seems like the most problematic bits of 2.45.3 are done, need to run some errands now, but i'll check in on the PRs later
[15:02] <ijohnson> thanks mborzecki !
[15:40] <zyga-x240> ijohnson: https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453438323
[15:40] <mup> PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Needs security review> <Preseeding 🍞> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
[15:40] <ijohnson> thanks zyga-x240
[15:42]  * cachio lunch
[16:14] <pedronis> ijohnson: I need a break and then I'll try to go over that least of UC20 PRs
[16:14] <ijohnson> pedronis: k, sounds good
[16:17] <mup> PR snapd#8980 closed: tests: backport preseed test fixes to 2.45 <Test Robustness> <Created by stolowski> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8980>
[16:21] <pedronis> mmh, I forgot about that one, that's bit the issue with long lived PRs
[16:22] <ijohnson> which one ?
[16:22] <pedronis> the backport pawel did
[16:22] <pedronis> already
[16:23] <pedronis> 8980
[16:23] <ijohnson> ah yes
[16:24] <ijohnson> well for that one I think pawel made changes there that weren't on master so it would have been a bit tricky to merge the release branch back to master when time came to actually finalize the release
[16:37] <mup> PR snapd#9048 opened: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
[16:38]  * ijohnson may have opened a new PR, but also closed an old one, so net PR count change is 0
[16:39]  * ijohnson goes back to actual productive things
[16:42] <mup> PR snapd#8143 closed: github: add github workflow <⛔ Blocked> <Created by sd-hd> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8143>
[16:56] <pedronis> ijohnson: that list of UC20-related PRs seems fine, the questions I suppose is whether they backport cleanly?
[16:56] <ijohnson> pedronis: not sure, but I can check
[16:57] <ijohnson> pedronis: if they backport cleanly shall I open a PR with them included ?
[16:57]  * ijohnson is about to break for lunch
[16:57] <pedronis> ijohnson: yes, but needs to be on top of the two things we want to land
[16:57] <pedronis> ijohnson: so maybe wait a bit?
[16:57] <ijohnson> pedronis: which ones, mborzecki already landed one of them I think
[16:58] <pedronis> #9042 and #9047 ?
[16:58] <mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
[16:58] <mup> PR #9047: cmd/snap-preseed: backport fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9047>
[16:58] <ijohnson> ah ok
[16:58] <pedronis> unless I'm confused, which can be, I'm slightly exhausted atm
[16:59] <ijohnson> pedronis: it's okay I know what to do, I can land these PR's in my PM if they are green, I will do a double-check on 9042, but the other one is aleady approved
[17:02] <zyga> re
[17:02] <zyga> back after painkillers
[17:02] <zyga> sorry the overlap hours are not great
[17:06] <zyga> ijohnson|lunch: https://github.com/snapcore/snapd/pull/9048#pullrequestreview-453515399
[17:06] <mup> PR #9048: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
[17:16] <ijohnson|lunch> zyga, we may be able to leverage that in the builds themselves, I haven't looked into it too much I really just copied what joedborg did for the microk8s snap GitHub actions :-P
[17:16] <cmatsuoka> build queue blocked again?
[17:16] <zyga> look at the time 16 minutes!
[17:16] <zyga> that's 16 less in each of the re-execing systems
[17:17] <zyga> cmatsuoka: let me check
[17:18] <zyga> not stuck - processing loads of jobs
[17:18] <cmatsuoka> ah ok, thanks
[17:18] <zyga> many are close to 40 minute CPU time
[17:18] <zyga> this is usually when they end
[17:19] <zyga> btw, if anyone has decent home network
[17:19] <zyga> and a spare laptop
[17:19] <zyga> I we can grow the pool
[17:20] <zyga> anyway
[17:20] <cmatsuoka> what kind of access is needed? I have a machine here but it's only accessible via ipv6
[17:21] <zyga> only private IPv4 address
[17:21] <zyga> a machine behind lan is ok
[17:21] <zyga> it reaches out to github
[17:22] <zyga> I don't think ipv6 is supported in practice
[17:23] <cmatsuoka> I have ipv4 but it's behind a nat, if that's ok I can set up a couple of nodes here to see what happens
[17:23] <cmatsuoka> just send me the directions
[17:23] <zyga> sure
[17:24] <zyga> let me find the repo
[17:27] <zyga> hmmm, where is it?
[17:29] <zyga> actually
[17:30] <zyga> cmatsuoka: do you know things like ansible or other "magic" frameworks for deployment>
[17:30] <zyga> my instructions work but are really manual
[17:30] <cmatsuoka> zyga: I know that they exist, but never used them
[17:31] <cmatsuoka> manual is good, we learn a lot doing things by hand
[17:31] <cmatsuoka> as long as I don't have to do it multiple times
[17:35] <zyga> cmatsuoka: let's do this some other time - the real version that would allow snapd to benefit requires admin access to the repo
[17:35] <zyga> cmatsuoka: I can recommend two things
[17:35] <zyga> cmatsuoka: I'll share the doc I wrote
[17:35] <zyga> and the scripts
[17:36] <zyga> and I'd recommend deploying that for a personal repo
[17:36] <cmatsuoka> ok
[17:36] <zyga> you will learn the process
[17:36] <zyga> and improve it as well
[17:36] <cmatsuoka> sounds good
[17:40] <zyga> cmatsuoka: my recommendation is to do this on a focal system with focal containers
[17:40] <zyga> drat, I'm terrible at google docs
[17:40] <zyga> I know for a fact there's a gdoc
[17:40] <zyga> let me try on my phone
[17:41] <zyga> google is the worst UX company on this planet
[17:41] <zyga> borland docs would be better
[17:41] <cmatsuoka> finding stuff in gdocs is hard, these guys should learn something about searching
[17:41] <cmatsuoka> oh wait
[17:41] <zyga> haha
[17:41] <zyga> right?
[17:44] <zyga> installing the app
[17:50]  * zyga searches gmail
[17:51] <zyga> I'm lost
[17:51] <zyga> sorry, I wonder where that is
[17:52] <cmatsuoka> someday you'll find it, and then you tell me
[18:14]  * pedronis admits to have made a gdoc with links to other gdocs
[18:37] <mup> PR snapd#9024 closed: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9024>
[18:46]  * cachio kinesiologist
[18:52] <ijohnson> zyga: https://github.com/snapcore/snapd/pull/9048#issuecomment-662625884
[18:52] <mup> PR #9048: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
[19:14] <zyga> jdstrand: I found one more bug in my implementation of the reproducer of the bug you found
[19:14] <zyga> jdstrand: testing it now, fingers crossed that it finally shows something
[19:34] <zyga> testing that now
[19:41] <ijohnson> uggh why do we have to have infinite amounts of conflicts in cmd_initramfs_mounts.go
[19:42]  * ijohnson cries a little a lot on the inside
[19:43]  * zyga hugs ijohnson virtually
[19:43] <ijohnson> haha
[19:43] <zyga> I had to deconflict some of those snapstate.go things
[19:44] <zyga> I learned how to tell my editor "yeah, you can use this much memory"
[19:44] <ijohnson> haha so true
[19:44] <ijohnson> before pstolowski split up that snapstate_test.go file, a conflict there was sure to crash my editor
[20:04] <zyga> jdstrand: no luck, I wrote a much more elaborate test that really mimics what you experienced except there's no failure yet :|
[20:04] <jdstrand> weird. I took my system out of it and did it in a vm in the bug...
[20:05] <zyga> I will try with your snap verbatim
[20:05] <zyga> I must have missed something
[20:06] <zyga> I pushed the updated (non failing) test to fix/lp-1888305
[20:07] <zyga> https://github.com/zyga/snapd/commit/db5c7c98b666ad3022d67a771706d11291f24da8
[20:07] <zyga> if you could eyeball that and spot any obviously wrong things I'd love to know
[20:08] <zyga> otherwise I will run with your snap in a VM tomorrow
[20:13] <mup> PR snapd#9049 opened: release/2.45: backport of uc20 PR's <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9049>
[20:13] <jdstrand> zyga: I think those experimental feature can be removed. I didn't carry those into the vm
[20:13] <zyga> OK
[20:13] <zyga> I will do one more round with a long running process
[20:15] <jdstrand> zyga: something that I don't see in this (maybe I missed it?) is that I have a long running process
[20:15] <zyga> right
[20:15] <zyga> I didn't do that because it should not be a factor
[20:15] <jdstrand> zyga: specifically, I have an app indicator that is long running
[20:16] <jdstrand> hmm
[20:16] <zyga> I though that it is caused by skew in snapd tools as snapd revisions change
[20:16] <jdstrand> zyga: are you sure? if there is a process running, isn't there different behavior for mount namespace updates?
[20:16] <zyga> no because snapd does not trigger mount namespace updates in our model
[20:17] <jdstrand> zyga: note that I could always resolve the issue by stopping and starting the indicator
[20:17] <zyga> that made me add the "observe" mode
[20:17] <zyga> as I realized that may matter
[20:18] <zyga> started one more round with the process running
[20:18] <zyga> that is interesting bit of information as well actually
[20:18] <zyga> it suggests that indeed the namespace "turns stale" somehow
[20:19] <zyga> and that starting a process is enough to fix it
[20:19] <zyga> but that's unusual as we must have done something to choose to update the namespace
[20:19] <zyga> and snapd, again, is not a factor
[20:19] <zyga> unless mount profiles changed somehow?
[20:40] <zyga> jdstrand: no change with running process
[20:43] <pedronis> ijohnson: I landed 9025, I suppose #9026 need a master merged now
[20:43] <mup> PR #9026: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
[20:43] <mup> PR snapd#9025 closed: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9025>
[20:45] <ijohnson> pedronis thanks yes I think so
[20:52]  * zyga EODs
[20:52] <zyga> o/
[23:14] <mup> PR snapd#9040 closed: spread: add opensuse 15.2 and tumbleweed for qemu <Simple 😃> <Created by jdstrand> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9040>