[05:20] morning [07:45] re [07:46] 30 min [07:46] till meds [07:47] thank you for moving the call [07:48] uh, lots of pain [08:14] 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] PR snapd#9042 opened: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) [08:22] mborzecki: yes, possibly, I'm still trying to land #9012 first [08:22] PR #9012: release/2.45: merge 2.45.2 release [08:40] PR snapd#9043 opened: daemon: decompose access check into smaller primitive access checkers [08:45] PR snapd#9044 opened: github: cherry-pick gh-action fixes (2.45) [08:45] pedronis: ^^ let's see how far that PR will run [09:16] okay, so this is much more lucid now [09:16] zyga-x240: https://github.com/snapcore/snapd/pull/9042 apparmor cherrypicks [09:16] PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) [09:16] zyga-x240: and https://github.com/snapcore/snapd/pull/9044 that's the gh actins caching tweaks [09:16] PR #9044: github: cherry-pick gh-action fixes (2.45) [09:16] and it's red (unsurprisingly?) [09:18] hmm, does command-chain only work for nondaemon apps ? [09:18] ogra_: it should not matter [09:18] (it does nto seem to get executed for me ) [09:18] *not [09:19] weird [09:19] looking at the failures [09:19] oh ! [09:20] seems snapcraft ignores changes in snap/local (where my script lives) 😛 [09:20] just preseed failures [09:20] * ogra_ manually cleans the part [09:20] well, in 19.10 - more failures elsewhere [09:21] shellcheck issues [09:45] pain slowly going away [09:59] 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] PR #9012: release/2.45: merge 2.45.2 release [10:00] looking [10:01] I've ran the unit tests test alone and it passed [10:01] so maybe random as well [10:01] ah drat, wrong branch [10:01] mborzecki: thx, other emergency maybe solved [10:01] we'll see [10:01] I agree we should merge [10:01] and iterate [10:01] I'look in a bit [10:07] zyga-x240: mborzecki: merged [10:07] mborzecki: it seems most thing you mentioned worth cherry picking are kind of small? [10:07] mborzecki: maybe worth doing one PRs with them, most of them? [10:07] to 2.45? [10:08] pedronis: yes, i'll do it [10:08] pedronis: thanks for merging the branch [10:10] PR snapd#9012 closed: release/2.45: merge 2.45.2 release [10:12] we have this 41d38c4b7f7554bdef88d567608241930a237cd9 [10:13] let me check if that is in the release branch [10:13] (nfs fix) [10:14] zyga-x240: ah, cool [10:15] one sec [10:15] PR snapd#9039 closed: cmd/snap-seccomp/syscalls: add faccessat2 (2.45) <⛔ Blocked> [10:16] https://github.com/snapcore/snapd/pull/9045 [10:16] PR #9045: Disable part of the nfs-support test that checks udp proto on debian-… [10:17] now about https://github.com/snapcore/snapd/pull/9044 [10:17] PR #9044: github: cherry-pick gh-action fixes (2.45) [10:17] * zyga-x240 looks at failures [10:17] zyga-x240: looked at failures already, i'll stat pushing cherry-picks there [10:17] zyga-x240: also, will pick 9045 [10:17] ok [10:20] PR snapd#9045 opened: Disable part of the nfs-support test that checks udp proto on debian-… [10:23] 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] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [10:28] mborzecki: shall I push there directly? [10:30] zyga-x240: hmm, yes, but maybe let's wait for spread jobs to run through [10:30] ok [10:33] 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] zyga-x240: hm fixes are trivial, so i'll just fix it rather than picking even more patches :/ [10:37] eh, silly shellcheck [10:37] ok [10:48] * zyga-x240 backported preseed fixes, testing now [10:52] * zyga-x240 looks at go [11:03] 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] PR #9046: tests: backport preseed test fixes to 2.45 [11:03] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [11:04] zyga-x240: thanks [11:05] wow, commits form april [11:05] from [11:05] we should release 2.46 [11:05] even if it's not in stable [11:05] just try to iterate [11:05] PR snapd#9046 opened: tests: backport preseed test fixes to 2.45 [11:06] zyga-x240: hm maybe i should just cherry-pick everything from 9046 to 9044 [11:06] yes [11:06] git merge it [11:06] mhm [11:06] I opened it separately to see how it behaves [11:06] will do [11:14] zyga-x240: one more cherry-pick i didn't notice before: https://github.com/snapcore/snapd/commit/6c09de0f3f [11:14] ah [11:15] put it directly into your fixes branch [11:23] yup [11:37] mborzecki: the plan is to land only 9044? [11:39] pedronis: yes, i plan to push necessary fixes to 9044, land it, and then rebase #9042 on top [11:39] PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) [11:40] pedronis: the good part is that most changes, if not all are in tests [11:41] mborzecki: sounds good [11:44] hmmm [11:44] is there anything in go that guarantees errno is set to zero before C calls? [11:44] because if not then user/ is buggy [11:55] ijohnson: around? [11:55] mborzecki: maybe cherry pick the travis test away as well :D [11:56] zyga-x240: go in general does it own syscall handling, it not following C conventions [11:57] zyga, not quite yet still having breakfast but I'll be into the office in 30 min or so [11:57] I suspect cgo does the right thing [11:57] but would need to dig [11:57] mmm [11:57] ijohnson: ok [11:57] talk to you later [11:58] * zyga-x240 reviewed https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453246893 [11:58] PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <⚠ Critical> [11:58] 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] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [11:58] brb [12:03] 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] paul424: is this fil expected to be modified by the end users? [12:06] heh, we have `var osutilFindGid = osutil.FindGid` in journal.go which does not appear to be used? [12:06] 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] 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] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [12:07] so... but I remember I somehow by-passed this and run succesfully OD .... problem is I don't remember how... [12:07] paul424: as those plugins something the user is expected to be able to add later? [12:08] s/as/are/ [12:08] mborzecki: the rendering plugins comes with Ogre3d engine hmm .... [12:09] PluginFolder=/usr/lib/OGRE [12:10] 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] the snap ogre lib is in : /snap/ogre/151/lib/ [12:13] Does snapper create a virtual executable envoierment or something ? [12:14] paul424: snaps are immutable filesysytems, they cannot be modified at all [12:14] great [12:14] paul424: snap author should arrage for files that need to be modified to live in other places [12:14] paul424: like $SNAP_DATA or $SNAP_USER_DATA [12:14] paul424: there are ways to make this work but it requires some cooperation with the snap author [12:14] 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] thanks for enlighting me :D [12:34] mborzecki: https://github.com/snapcore/snapd/pull/9044 looks optimistic [12:34] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [12:34] * ijohnson is back [12:34] zyga-x240: yup [12:34] * ijohnson or maybe here for first time today [12:34] ijohnson: +1 on the error checking for user lookup PR [12:34] thanks [12:34] I had a look through go and meh [12:35] ijohnson: o hi, fun stuff with user lookup :/ [12:35] too much inconsistency [12:35] yeah it's a bit disappointing, but then again the man page for getgrpnam_r does kinda say it's impossible anyways [12:35] mborzecki: oh? what more fun stuff ? [12:35] ijohnson: but I would expect _some_ level of consistency [12:35] between the various backends [12:35] but no, that's not the case [12:36] yeah [12:37] 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] pedronis: right, I was only curious because some calls do not reset errno [12:37] and I was wondering if cgo explicitly sets errno = 0 ahead of all calls [12:38] the real bug is in the higher layer in go [12:38] * zyga-x240 starts a test and takes that break === nottrobin_ is now known as nottrobin [12:40] zyga-x240: anyway cgo itself seems to emit "errno = 0" in some cases [12:42] zyga-x240: see cmd/cgo/out.go in go itself [12:43] * zyga-x240 looks [12:49] ijohnson: while you're around, can you take a look at https://github.com/snapcore/snapd/pull/9030 ? :) [12:49] PR #9030: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub [12:49] mborzecki: tests are failing on ... [12:49] 2020-07-22T12:22:24.0548501Z /tmp/sanity-squashfs-830795014: no space left on device [12:50] 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] pfffff [12:50] 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] another failed on EOF from reboot [12:50] 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] heh, gdoc does not like firefox [12:51] one failed on preparing due to purge [12:51] zyga-x240: lxd? [12:51] no, just prepare up front [12:51] mborzecki: submitted [12:51] one more is in progress [12:51] zyga-x240: 8883 is still waiting [12:52] ijohnson: thanks [12:52] I'd restart the three to see if they can land cleanly [12:52] but I'd be fine with override as well [12:52] mborzecki: but did you see my question in IRC earlier? was there something else to know about the user stuff ? [12:52] ijohnson: probably missed it, what was the question? [12:53] 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] mborzecki: 640GB should be enough for a google doc [12:54] ijohnson: ah, nah just the general state of things around that area [12:54] yeah rather sad [12:54] 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] zyga-x240: that failure in prepare is 8883 [13:01] ijohnson: standup? [13:01] yes [13:02] cachio: SU? [13:16] zyga-x240: restarted the spread job in https://github.com/snapcore/snapd/pull/9044 [13:16] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [13:16] ok [13:27] ahh [13:27] there's one thing I didn't do that jamie surely did [13:27] run this as user! [13:27] zyga-x240: the caching behavior in #9044 is such a nice improvement now that i restarted the ci job [13:27] PR #9044: many: cherry-picks for 2.45, gh-action, test fixes [13:27] :D [13:43] why do we even bother with hangouts on non-mobile devices, mobile experience is just so much better [13:44] zyga-x240: mborzecki: we can close 9045 and 9046 right? [13:44] checking [13:44] yes [13:44] they are now in the big PR [13:45] pedronis: ok, so looking again the ones that are blocking things are these PR's: 8890, 8612, 8854, 8652, and 8795 [13:45] pedronis: zyga-x240: closed them now [13:45] 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] pedronis: if you like I can prepare a backport PR with all of those after 9044 lands cleanly [13:46] PR snapd#9045 closed: Disable part of the nfs-support test that checks udp proto on debian-… [13:46] PR snapd#9046 closed: tests: backport preseed test fixes to 2.45 [13:47] 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] PR #9015: cmd/snap-preseed: handle relative chroot path [13:47] PR #9018: cmd/snap-preseed: check that target path exists and is a directory on --reset [13:48] mborzecki: yes to 8015, 9018 is nice to have but not necessary, it is just better error handling [13:48] ack [14:04] break [14:12] 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] mborzecki: looking [14:20] hmm [14:20] 2020-07-22T13:47:54.7315113Z Failed to connect to bus: Connection refused [14:20] yeah I think that's ok to merge [14:20] +1 and let's rebase the rest [14:20] yup, doing so now [14:20] ok [14:21] PR snapd#9044 closed: many: cherry-picks for 2.45, gh-action, test fixes [14:24] zyga-x240: rebased https://github.com/snapcore/snapd/pull/9042 please take a look [14:24] PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) [14:36] PR snapd#9047 opened: cmd/snap-preseed: backport fixes (2.45) [14:37] ijohnson: can you take a look ^^ ? [14:38] mborzecki: sure [14:38] ijohnson: thanks [14:38] 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] 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] PR #9027: tests: refresh/revert snapd in uc20 [14:51] 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] ijohnson, [15:01] ok [15:01] I'll try a new change with the gce platform to see if it improves [15:01] 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] thanks mborzecki ! === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [15:40] ijohnson: https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453438323 [15:40] PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <⚠ Critical> [15:40] thanks zyga-x240 [15:42] * cachio lunch [16:14] ijohnson: I need a break and then I'll try to go over that least of UC20 PRs [16:14] pedronis: k, sounds good [16:17] PR snapd#8980 closed: tests: backport preseed test fixes to 2.45 [16:21] mmh, I forgot about that one, that's bit the issue with long lived PRs [16:22] which one ? [16:22] the backport pawel did [16:22] already [16:23] 8980 [16:23] ah yes [16:24] 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] PR snapd#9048 opened: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too [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] PR snapd#8143 closed: github: add github workflow <⛔ Blocked> [16:56] ijohnson: that list of UC20-related PRs seems fine, the questions I suppose is whether they backport cleanly? [16:56] pedronis: not sure, but I can check [16:57] pedronis: if they backport cleanly shall I open a PR with them included ? [16:57] * ijohnson is about to break for lunch [16:57] ijohnson: yes, but needs to be on top of the two things we want to land [16:57] ijohnson: so maybe wait a bit? [16:57] pedronis: which ones, mborzecki already landed one of them I think [16:58] #9042 and #9047 ? [16:58] PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) [16:58] PR #9047: cmd/snap-preseed: backport fixes (2.45) [16:58] ah ok [16:58] unless I'm confused, which can be, I'm slightly exhausted atm [16:59] 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 === ijohnson is now known as ijohnson|lunch [17:02] re [17:02] back after painkillers [17:02] sorry the overlap hours are not great [17:06] ijohnson|lunch: https://github.com/snapcore/snapd/pull/9048#pullrequestreview-453515399 [17:06] PR #9048: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too [17:16] 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] build queue blocked again? [17:16] look at the time 16 minutes! [17:16] that's 16 less in each of the re-execing systems [17:17] cmatsuoka: let me check [17:18] not stuck - processing loads of jobs [17:18] ah ok, thanks [17:18] many are close to 40 minute CPU time [17:18] this is usually when they end [17:19] btw, if anyone has decent home network [17:19] and a spare laptop [17:19] I we can grow the pool [17:20] anyway [17:20] what kind of access is needed? I have a machine here but it's only accessible via ipv6 [17:21] only private IPv4 address [17:21] a machine behind lan is ok [17:21] it reaches out to github [17:22] I don't think ipv6 is supported in practice [17:23] 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] just send me the directions [17:23] sure [17:24] let me find the repo [17:27] hmmm, where is it? [17:29] actually [17:30] cmatsuoka: do you know things like ansible or other "magic" frameworks for deployment> [17:30] my instructions work but are really manual [17:30] zyga: I know that they exist, but never used them [17:31] manual is good, we learn a lot doing things by hand [17:31] as long as I don't have to do it multiple times [17:35] 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] cmatsuoka: I can recommend two things [17:35] cmatsuoka: I'll share the doc I wrote [17:35] and the scripts [17:36]