=== Eickmeyer is now known as Eickmeyer__ === Eickmeyer__ is now known as Eickmeyer_E [05:10] morninb [05:10] morning [06:29] mvo: good morning [06:30] mborzecki: good morning [06:32] mvo: do we need https://github.com/CanonicalLtd/subiquity/pull/770 and https://github.com/snapcore/snapd/pull/8661 for beta? [06:32] PR CanonicalLtd/subiquity#770: console-conf: always run when triggered for the chooser [06:32] PR #8661: configcore: add "service.console-conf.disable" config option <⛔ Blocked> [06:32] mborzecki: it's not beta critical [06:32] mborzecki: I will not even backport it :) [06:33] mvo: ah ok [06:45] Good morning [06:47] zyga: hey [06:50] hey zyga [06:59] morning [07:01] good morning, I'm seeing a weird behavior with a core20-based snap. If I call the snapraft-runner script in a configure hook, it segfaults [07:01] it worked fine with core18 [07:09] pstolowski: hey [07:11] oh, actually I might know what's the issue [07:16] have snap hook always been duplicated in snap/hooks and meta/hooks ? [07:20] hmm google:ubuntu-18.04-64:tests/main/mount-ns:reboot failing? [07:21] mborzecki: how? [07:22] zyga: https://paste.ubuntu.com/p/NSHS5rHk34/ [07:22] look slike / is moutned with different options and efivars is present [07:22] Are you up to date in relation to master? [07:23] This changed yesterday to match the new image [07:23] ah ok, i need to update tht branch then [07:24] ackk: hooks must be in meta/hooks [07:24] Perhaps snapcraft is copying them? [07:25] zyga, yeah I mean you put them in snap/hooks for snpcraft to find them right? [07:25] I don’t really know, 90% of my snaps are hand made [07:26] heh [07:28] ah yeah, it seems they've always been in both places. [07:29] maybe snapcraft could not populate snap/hooks? [07:29] That does seem weird [07:38] PR snapd#8667 opened: interfaces/fwupd: allow bind mount to /boot related on core [07:43] zyga, IIUC snapcraft copies snap/ as-is, with the exception of snap/local [07:57] PR snapd#8663 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials [08:05] PR snapd#8664 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 [08:05] PR snapd#8665 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 [09:04] xnox: hey [09:09] mvo, hi, to confirm, there's currently no way via sudo/su to drop from root the snap_daemon user, right? [09:11] ackk: hey, not sure I understand the question, can you please give me a little bit more context? what do you want to archive exactly. you are root and drop to the snap daemon-user inside the snap? [09:13] mvo, yes, I want to run a process as daemon user, ideally from a bash script. afaict sudo/su don't work in the snap [09:15] mvo, I thought we did that in maas, but actually we have a python script that does that [09:15] ackk: I'm out of my depth here unfortunately, I think we need jdstrand to help if you can use su/sudo inside a snap to drop from root to the snap-daemon user [09:15] mvo, ok, np, thanks [09:43] zyga: what was the PR you wanted reviewed to unblock you (mentioned yesterday in the standup)? [09:43] pstolowski: let me find it [09:43] https://github.com/snapcore/snapd/pull/8566 [09:43] PR #8566: c/snaplock/runinhibit: add run inhibition operations [09:44] k [09:47] wow, https://github.com/snapcore/snapd/pull/8650 is green [09:47] PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run [09:51] ackk: if you want to drop privs to snap_daemon from a shell script you need to use one of the tricks mentioned in "Usage considerations" on https://snapcraft.io/docs/system-usernames [09:53] ijohnson, ah, thanks [09:53] re [09:53] sorry, helped wife with lucy for a moment [09:54] mborzecki: makes all the test fixing worth it :) [10:00] pstolowski: I removed the hacks around /home/ubuntu from https://github.com/snapcore/snapd/pull/8633 it now simply ignores it [10:00] PR #8633: tests: detect and report root-owned files in /home [10:00] pstolowski: also extended tests to show this [10:00] thanks [10:00] pstolowski: and extended help to show the invariants [10:00] pstolowski: I think it's good now [10:00] and rebased on master to get all the fixes [10:01] I didn't do the extra test suite as that's somewhat more work [10:12] zyga: naive question to the lock PR [10:12] looking [10:13] pstolowski: as in when the lock file exists but is empty? [10:13] pstolowski: if you look at unlock() that's exactly an unlocked lock :) [10:13] pstolowski: we truncate to unlock [10:13] zyga: exists & not-empty [10:13] if it exists and is non-empty then it is locked [10:14] zyga: yes and if reboot happens it remains non-empty, is it going to ihibit snap run? [10:14] perhaps the confusing aspect is that there are two locks in one: the contents of the file and the flock protecting reading/writing the contents [10:14] yes [10:14] pstolowski: that's the fature [10:14] *feature [10:14] it can very much happen that you reboot to uninhibit [10:14] zyga: is there a guarantee it gets released? [10:14] (i'm missing bigger picute) [10:14] *picture [10:14] pstolowski: it's not a part of this branch [10:15] pstolowski: it's the same question as link/unlink snap [10:15] pstolowski: those are just the primitives [10:15] pstolowski: and the primitives do allow having a lock for indefinite amount of time [10:15] ok. my only concern is that this interrupts a snapd op in flight and we leave snap run unusable for given snap [10:15] but yes, i can see it belongs elsewhere to handle this [10:15] pstolowski: if you look at the usage of this in another PR [10:15] I currently inihibit before unlinking [10:16] and uninhibit after linking [10:16] though my preference is to expand that period so we inhibit when we decide to refresh [10:16] and uninhibit when refresh is either done or aborted [10:20] mborzecki: have you seen https://bugs.launchpad.net/snapd/+bug/1878505 ? [10:20] Bug #1878505: recovery chooser doesn't trigger on rpi with core20 [10:21] ijohnson: hm not surprised really, it's probably a usb keyboard, so it may come up whenever during the boot [10:22] mborzecki: yes he mentioned it was a usb keyboard, in fact he has multiple attached [10:22] ijohnson: probably after loadign the modules, and udev has to settle and create input devices by the time the trigger detection runs [10:22] mborzecki: so perhaps the chooser should gain a systemd depends on systemd-modules-load and systemd-udev-settle (or whatever it's called) ? [10:23] ijohnson: the post-pivot one runs after snapd seeding is done iirc [10:23] ah I see [10:23] ijohnson: what i would expect to work pretty well is using gpio-keys in dtb, setting up one gpio to emit KEY_1 [10:25] quick errand, bbiab [10:26] PR snapd#8650 closed: daemon, tests: indicate system mode, test switching to recovery and back to run [10:33] ijohnson: added a note, not sure udev settle would fix that reliably tho [10:33] it's a usb stack after all :/ [10:38] brb [10:44] mborzecki: ack thanks for looking at it [10:45] PR snapd#8668 opened: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts [10:45] pedronis: mvo: I opened https://github.com/snapcore/snapd/pull/8668 which is the first step to cross-check, complete with some tests, not sure if y'all will want more tests or not, it's already at ~1k lines [10:45] PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts [10:46] ijohnson: thanks I will look, we would also like to move partition somewhere else before 1.0, so need also to think whether this bits belong here or not [10:47] ok [10:47] *these bits [10:50] ijohnson: thanks [10:51] re [10:52] TIL, well, not T but recently, gparted cannot resize FAT16 [10:52] those small boot partitions, you need some hand holding and remaking from scratch to grow them [10:52] mvo: also could you do a sudo git merge on https://github.com/snapcore/snapd/pull/8659 ? [10:52] the test failures are unrelated [10:52] PR #8659: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available [10:59] o/ is it possible to do 'snap run --gdb' on UC? It complains about gdb command not found [10:59] abeato: IIRC not at present [11:00] abeato: we discussed some work required for that but it's not scheduled [11:00] ok, thanks [11:03] an errand, back in 2-3h [11:03] PR snapd#8659 closed: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available === Eighth_Doctor is now known as Conan_Kudo === Conan_Kudo is now known as Eighth_Doctor [11:26] re [11:33] pstolowski: thanks your view in 8531! great comments [11:33] hmm [11:33] that binfmt misc change is annoying [11:33] let me take it out of the equation [11:37] mvo: yw, glad you found it useful [11:43] pedronis: fwiw, I updated the vitality score pr, need to address the comemnts from pawel still though, feel free to have a look still [11:47] PR snapd#8669 opened: tests/mount-ns: stop binfmt_misc mount unit [11:47] https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test [11:47] PR #8669: tests/mount-ns: stop binfmt_misc mount unit [11:55] mvo: ^ [12:04] cachio: hi, i commented on your nested.sh PR [12:04] pstolowski, thanks [12:13] pstolowski: hi [12:14] xnox: hey! i've sent you an email [12:17] mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/ [12:17] PR #8656: snap-mgmt: perform cleanup of user services [12:17] I think it's okay now [12:17] mvo: I have one tiny fix for you https://github.com/snapcore/snapd/pull/8670 -- debian packaging [12:17] PR #8670: packaging: update sid packaging to match 16.04+ [12:18] ijohnson: do you want to review https://github.com/snapcore/snapd/pull/8566 -- it has +2 and I'd like to merge it to make progress [12:18] PR #8566: c/snaplock/runinhibit: add run inhibition operations [12:18] you marked yourself as a reviewer [12:18] PR snapd#8670 opened: packaging: update sid packaging to match 16.04+ [12:18] but that was two weeks ago [12:19] zyga: go ahead without me, I started a review but didn't finish [12:19] ok [12:19] thanks :) [12:24] ijohnson: I reviewed #8668, it probably could help if it go split at least in two, I comment as much. I need to go take of an errand, but happy to chat about it later if you have questions. I also think it should live under osutil/disks or something like that. [12:24] PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts [12:24] *take care of an errand [12:26] mvo: notice that I commented on one of pstolowski considerations and your answer [12:26] * pedronis errands [12:29] * zyga found a curious failure in session agent test, looking [12:29] a daily reminder that spread -seed is your friend [12:56] zyga: thank you [13:49] * zyga breaks for a moment, for the next meeting [13:51] zyga, please tell be what you mentioned about the spread user [13:51] pedronis: yes let me finish going through your comments, splitting out is probably a good idea and fine to do, I had forgotten I still had the exported mocking methods in the file, those are used in a followup [13:51] zyga, couldn't hear [14:03] re [14:04] cachio: in a moment, in another call [14:07] pedronis: what was the second comment you had about 8351? I will work on the seeding spread test now but forgot what comment 2 was [14:07] mvo: we should block people from putting snapd itself in the list [14:08] because we are not going to support making it less important than other things [14:09] pedronis: nice, will do [14:17] ijohnson: I asked a question, and answered/made a suggestion to something else in that PR [14:40] pstolowski: mvo's PR has landed (and maybe we got new enough kernels), #8533 needs master merge [14:40] PR #8533: image, tests: core18 early config [14:40] pedronis: ok, thanks [14:40] 20 minutes until next call [14:40] mvo: I feel your pain :D [14:43] jdstrand: before the next call, do you have time to look at https://github.com/snapcore/snapd/pull/8578 [14:43] PR #8578: interfaces: add system-packages-doc interface [14:43] jdstrand: it's doing the same thing, just some naming changes [14:43] thanks pedronis sounds good [14:52] ijohnson: made a suggestion based on your answer [14:53] pedronis: do you have a minute to talk abou the tweaks to keeping track of the current system? i implemented the changes we discussed and have some concerns that we may be overcomplicating it [14:53] thanks yes a Dev() method is fine too [14:53] also a quick review on https://github.com/snapcore/snapd/pull/8652 by anybody would be great :-) [14:53] PR #8652: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover [14:54] mvo: should I come to the next meeting? mborzecki wants to chat about something with me [14:54] zyga: before the next call? no. as mentioned yesterday when talking about the coordination email I sent, I will be getting to PR reviews today/tomorrow. I have a bunch of meetings so likely tomorrow [14:56] jdstrand: sure, no worries [14:57] ackk, mvo: you may not use sudo/su in a snap to drop to the snap_daemon user. those go through the pam stack. I outlined in https://forum.snapcraft.io/t/system-usernames/13386 with a link to code on how to do it. I believe there is something in the snapcraft realm that (cc cjp256) to make it even easier [14:58] one of the reasons why is that sudo and su use the pam stack. but you don't need pam for this [14:58] PR snapd#8669 closed: tests/mount-ns: stop binfmt_misc mount unit [14:59] thanks zyga for the review! [14:59] :) [14:59] I need to look at the snap routine portal info test [14:59] but [14:59] more meetings [14:59] PR snapd#8652 closed: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover [15:04] pedronis: no worries, we can talk after your meeting [15:04] pstolowski, hey [15:05] nested is working again [15:05] cmatsuoka, told me the problem === erich is now known as E_Eickmeyer [15:05] cachio: yay, that's great [15:05] pstolowski, I'll push in a bit [15:07] thx [15:11] woot [15:12] mborzecki: I'm available now, standup? [15:12] pedronis: ok [15:12] zyga: yes, I looked at your PR, we indeed should talk, also because if I understand that's not the final place you want to put those in, right? [15:12] I mean the inhibit locks [15:13] pedronis: that's right, I'd like to grab the lock earlier, when we do the soft check and it succeeds [15:13] pedronis: I will look at it in detail tomorrow [15:13] my main question was where should this live [15:13] as there will be more code for a non-demo version (undo, all exit paths covered, tests) [15:15] pstolowski, I pushed the change [15:16] I already tested that [15:16] cachio: my question was about the external user [15:16] cachio: what's the reason for using a non-root user to log into the test device in spread, when using the ad-hoc backend [15:16] cachio: and a follow-up, if we could use regular root instead [15:17] zyga, I suppose that in core device we need a user [15:17] different than root [15:17] cachio: do you know why? [15:17] cachio: could you push this fix as a separate PR? i think this could land quickly if independent of your nested lib PR [15:18] I mean, if you can setup the password for root you can use root [15:18] zyga, but you need to specify the passwotd in the spread.yaml [15:18] cachio: and how is that different from the external user? we specify a password for it [15:19] cachio: I want to avoid the difference between ad-hoc and all the other backends [15:19] zyga, I mean, it is the same [15:19] cachio: because we get more and more session level things [15:19] and now we will get a new session that only occurs in a rarely-exercised test interaction [15:19] zyga, we could use root [15:19] zyga, I dindt' [15:20] didn't try with root in a core device but I dont see any restriction [15:20] zyga, let me make a try [15:20] cachio: cool, if we can do it that is preferable [15:20] cachio: if we cannot do it I will try to accommodate the external user instead [15:20] pstolowski, yes I can, but I'll need a bitr of time because there are few other thinks needed as well [15:21] zyga, ok [15:21] cachio: ah, if it is more than this 2 line change to apply it on master than maybe it's not worth it [15:22] pstolowski, I'll make a try after lunch [15:22] I need to review what is needed [15:23] ijohnson: hey, if you have a moment, I'd love to get a 2nd review for https://github.com/snapcore/snapd/pull/8633 -- I have some extra checks piled after that, which might help with flaky tests [15:23] PR #8633: tests: detect and report root-owned files in /home [15:24] I merged master to get some more fixes but it should otherwise pass (unless network issues show up) [15:26] mvo: I guess I could look at proposing prompting in to master [15:26] mvo: it needs considerable setup so it would be a distinct suite / backend perhaps [15:27] mvo, is it possible to add a password to root in ubuntu core? [15:27] zyga, ~ [15:27] home :) [15:30] zyga: sure I will take a look at it [15:32] ahhh [15:33] I just understood why we still see some failures [15:33] the failover fixes [15:33] they don't reload root's session systemd --user [15:33] I'll send a follow up shortly [15:33] the things we learn :) [15:34] zyga: btw not urgent, but I also spent some time thinking about how to name the *-tool things. we should think a good time to talk about that [15:34] pedronis: I'm off tomorrow but we can try early next week [15:34] ok [15:34] pedronis: or by email if it's low bandwidth [15:35] pedronis: I see the problem but I also love the -tool suffix is recognizable as our internal thing and it's short [15:36] yes, I agree, we need recognizable or at last standing out names [15:36] but the problem with -tool is that is not easy to know what to actually expect from them [15:37] zyga: anyway this is a bit an area were it's easy to bikeshed, I might have to simply make a call about where to got at some point [15:38] pedronis: SURE [15:38] sure [15:38] :) [15:38] sorry, tabbed out of vm with the wrong key [15:39] also we have snap-tool that being consistent should be called snapd-tool-tool [15:39] :) [15:40] anyway [15:41] pedronis: snapd-metatool [15:42] https://github.com/snapcore/snapd/pull/8671 should fix the cases that fail with errors like [15:42] PR #8671: tests: reload root's systemd --user after snapd tests [15:42] - Make snap "test-snapd-user-service-sockets" (unset) available to the system (Post http://0/v1/service-control: read unix @->/run/user/0/snapd-session-agent.socket: read: connection reset by peer) [15:42] PR snapd#8671 opened: tests: reload root's systemd --user after snapd tests [15:42] and with that I'd like to do some paperwork and EOD [15:42] cachio: ^ [15:44] ijohnson: I should probably move the defer.sh + tac trick into a helper [15:44] ijohnson: cleanup-tool (accepting any rename after we agree on new names) [15:45] PR snapd#8654 closed: tests: test registration with serial-authority: [generic] [15:46] this is so nice [15:46] I wanted to do my own model a few times [15:46] and now with the generic authority I can just really do that [15:46] and not feel like it's half baked [15:48] * cachio lunch [15:50] * zyga EOWs [15:50] see you on Monday everyone [16:03] pstolowski: there seem to be some selinux failures showing up in #8533 [16:03] PR #8533: image, tests: core18 early config [16:03] looking [16:09] PR snapd#8672 opened: o/devicestate: change how current system is reported for different modes [16:09] hmm that's weird, seems unrelated [16:10] cachio: adding a password to the root user is pretty hard, it's /etc/passwd,shadow are readonly so we would need to play bind-mount tricks [16:20] is it possible to share unix sockets via a content interface between snaps? [16:23] ackk: yes [16:23] ackk: it's also tested [16:23] ackk: and really works :) [16:26] zyga, lol. yeah I think I have misconfiguration on my side [16:27] thanks [16:27] :) [16:27] I'm EOD but can respond to questions with small alg [16:27] *lag [16:27] pedronis: ok, it's not obvious with selinux and the test alone against master didn't fail, i'll investigate tomorrow [16:28] pstolowski: looking [16:29]