[05:26] morning [06:32] PR snapd#9292 opened: daemon: make checkAccess return a Response [06:45] mvo: hey [06:45] mvo: can you take a look at https://github.com/snapcore/snapd/pull/9265 ? i've stacked the boot chains on top of this one [06:45] PR #9265: many: move seal code from gadget/install to boot [06:46] mborzecki: ok [07:03] morning [07:05] good morning pstolowski [07:06] mborzecki: fwiw, I looking at the failure in the nested test in that pr right now [07:08] errand, need to take some paperwork to my accountant [07:11] any news on the searching 403 issues? [07:22] PR snapd#9291 closed: client: implement RebootToSystem [07:42] PR snapd#9293 opened: snap: auto-import will not try to auto-create users on managed devices [07:43] pstolowski: I had a green pr this morning, no 403 anymore [07:44] pstolowski: I did not see any notes or know why it works [07:44] mvo: hmm, ok, that's great (i think)( [07:52] mvo: hi, #9021 needs a master merge now? [07:52] PR #9021: snap: implement new `snap reboot` command [07:52] pedronis: yeah, let me do that [07:53] pedronis: updated, thank you [07:54] mvo: I'll try to get to it later today [07:54] thx [08:06] good morning [08:07] zyga-kaveri: good morning [08:07] yes, although it might rain later [08:07] how are things? [08:07] can I help with anything or can I code some more in the morning [08:07] PR snapd#9288 closed: tests: remove workaround for cups on ubuntu-20.10 [08:15] re [08:25] mvo: it seems 20.10 needs same nfs fix I made a while ago for debian-sid, i can prep a PR [08:28] PR snapd#9294 opened: o/snapstate: check available disk space in RemoveMany [08:29] pedronis: mvo: can we land #9265 maybe and tweak sid in a followup? [08:29] PR #9265: many: move seal code from gadget/install to boot [08:30] mborzecki: yes, just finished my review, will land now [08:31] pstolowski: please do [08:31] mvo: yep, running it now [08:31] pstolowski: \o/ [08:31] mvo: cool, thanks [08:31] pstolowski: the udp change? [08:31] mborzecki: maybe you can have a look at my comments in 9265 and tell me how wrong I am [08:32] mborzecki: especially the last one [08:32] mvo: one about tests/lib/uc20-create-partitions/main.go ? [08:33] mborzecki: it also makes me sad that our nested tetss are apparently broken. I want to debug this but it's really a bit annoying to debug them, I got kicked out twice from the vm already probably because of some set -x somewhere [08:33] PR snapd#9265 closed: many: move seal code from gadget/install to boot [08:33] mborzecki: yes, that one [08:48] PR snapd#9295 opened: tests: skip udp protocol in nfs-support test on ubuntu-20.10 <⚠ Critical> [08:53] PR snapd#9296 opened: packaging/debian-sid: tweak code preparing _build tree [09:10] ok, almost everything is tested now, just last stage of connecting the export manager now [09:20] mborzecki: if 9297 conflicts with your current work I can close it again, maybe a bad time for such a cleanup [09:21] mvo: i think it's ok, we can always merge it after mark boot successful lands [09:23] PR snapd#9297 opened: boot: add "rootdir" to baseBootenvSuite and use in tests [09:32] yay, the export manager is almost complete === seb128_ is now known as seb128 [09:51] mvo: I agree that the spread test in 9265 is doing a bit less, not sure how easy to do more it is though [09:52] pedronis: yeah, just an observation, not sure how much we can do about it [09:53] we can review that after boot is a bit less in flux I suppose [09:53] pedronis: +1 [09:53] mvo: maybe push a TODO there? [09:53] ijohnson: 9273 should be ready for your review, AFAICT mborzecki adressed all the points [09:54] pedronis: yeah, can do [09:55] mvo: this https://bugs.launchpad.net/snapd/+bug/1891644 isn't fixed right? [09:55] Bug #1891644: uc20 seeding fails with "service.console-conf.disable: true" [09:55] pstolowski: I have a pr that needs a second review [09:55] mvo: ah, ok, thanks [09:56] pstolowski: *nudge* 9272 *nudge* :) [09:56] mvo: looking [09:56] may need a spread re-run but I will see if I need to tweak/fix anything first [10:06] mvo: one question there [10:07] pstolowski: ta, in a meeting [10:07] pstolowski: but will see what I can do [10:13] pstolowski: replied [10:13] startup process is now fully unit tested [10:13] I'll start working on spread tests now [10:14] mvo: ty [10:32] pedronis: mvo: https://github.com/snapcore/snapd/pull/9298 [10:32] PR #9298: boot: represent boot chains, helpers for marshalling and equivalence checks [10:33] PR snapd#9298 opened: boot: represent boot chains, helpers for marshalling and equivalence checks [10:39] nice mborzecki ! [10:39] mborzecki: still in a meeting, will look once it's over [10:44] mborzecki: we need a sort on []bootChain [10:45] ah, right, will add that next [10:47] wrote some more tests and had to change a few functions dealing with removal of exported content [10:47] * zyga-kaveri takes a short break [10:55] mborzecki: left some initial comments [10:56] I made the ubuntu-20.10 test now a required test - it is working now [10:58] PR snapd#9280 closed: packaging/opensuse: fix for /usr/libexec on TW, do not hardcode AppArmor profile path [10:58] PR snapd#9295 closed: tests: skip udp protocol in nfs-support test on ubuntu-20.10 <⚠ Critical> [10:58] PR snapd#9296 closed: packaging/debian-sid: tweak code preparing _build tree [10:59] pedronis: thanks, i've converted it to draft for now [11:01] mborzecki: do we need 9298 for 9278 too? or can/should I review that one? [11:01] mvo: i think we do [11:03] mborzecki: ok, will ignore it for now [11:10] back [11:10] ok, on to fix remove [11:13] PR snapd#9272 closed: configcore: "service.console-conf.disable" is gadget defaults only [11:15] moving back home, back in a bit [11:44] mvo: some comments in #9021 [11:44] PR #9021: snap: implement new `snap reboot` command [11:54] re [12:03] PR snapcraft#3279 closed: Set VDPAU_DRIVER_PATH appropriately [12:08] I've glued all the tasks and trying to see how far we get in spread [12:22] I'll grab some coffee [12:23] need to write undo handlers as well [12:23] also need to examine overlord startup and seed process on core{16,18,20} [12:30] pstolowski: I looked at #9270 [12:30] PR #9270: [RFC] wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl [12:32] pedronis: ty. the tests are finally looking much better after fixes in master (and 403 no longer failing in search) [12:43] ok, time to add the painfully annoying task changes to tests [12:53] ok, on classic things look good [12:53] content exports are in place [12:53] current symlink is managed [12:53] looking at core now [12:54] PR snapd#9220 closed: o/snapstate: disk space check with single snap install [12:54] yay \o/ [13:16] mvo: SRU has regressed snapcraft: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#snapd but the errors don't make sense to me [13:17] zyga thanks! I bet there was no real regression, the last times I looked at this, the snapcraft tests were just very flaky [13:17] mvo, https://autopkgtest.ubuntu.com/packages/s/snapcraft/focal/amd64 doesn't seem flacky [13:18] there was no fail before 2.45 [13:18] but the tests don't output a lot, so hard to say what's the issue is... [13:30] seb128: in a meeting right now, will look after [13:37] seb128: fwiw - it seems like the test install snapcraft, then runs "+ grep snapcraft, version 3.* [13:37] + snapcraft version" which fails because snapcraft is now on version 4 [13:38] mvo, that looks like an explanation that makes more sense than the flakyness :-) [13:39] seb128: yeah, sorry [13:42] hmm, lost network [13:43] mvo: is it a regression? [13:44] zyga-kaveri: snapcraft version | grep "snapcraft, version 3.*" [13:44] ^⁻ this fails [13:44] zyga-kaveri: because snapcraft is now at v4 [13:44] lol [13:44] zyga-kaveri: so not our fault [13:44] :-P [13:44] PR snapd#9259 closed: client, api: handle insufficient space error [13:44] how did it pass snapcraft's own test suite? [13:45] zyga-kaveri: because previous snapcraft was v3 [13:45] zyga-kaveri: let me wip up a quick fix [13:45] I thought this was a test inside snapcraft itself [13:45] anyway, not important [13:47] zyga-kaveri: it is [13:47] oh? [13:47] zyga-kaveri: they are using deb2snap and the snap moved on [13:49] cjp256: do you mind if I upload https://paste.ubuntu.com/p/tMrn7VBBBX/ [13:49] ? [13:54] so!!! I just realized that when github doesn't let you reply to conversations on the main PR page (and it just shows you the "resolve" button), it is because you have existing "pending" comments on that PR, and to be able to reply to conversations, and if you delete or send those pending comments, then you can reply again [13:54] that's really weird behavior [13:54] but i can reproduce it now [14:00] cjp256: uploaded now after talking to sergio [14:01] mvo: ack [14:04] pedronis: was there other problems with my uc20 cloud-init pr other than the comments/tests mismatch ? [14:10] cachio: question to your nested PR [14:12] pstolowski, let me check if it works in uc20 [14:13] ijohnson: I need to look again, I didn't do quite a full review, when I wasn't sure if the code or me were confused [14:13] pedronis: ok, sorry about the confusion, I will push up a correction to those things now then unless you'd rather I wait til your review is done [14:14] ijohnson: no, I would prefer to review something consistent with the intentions, much easier on the brain [14:14] ok [14:15] ok back to unit tests for now [14:15] pstolowski, spread does "cut -f1 -d. /proc/uptime" [14:16] pstolowski, but if the id works it is much simpler [14:18] thanks for the idea [14:23] pedronis: ah will take a little bit more, we have wrong/confusing logged messages on uc20 here: [14:23] ``` [14:23] System initialized, cloud-init reported to be in disabled state, \n [14:23] ``` [14:24] bit confused how that happened but need to dig in a little bit more [14:25] ijohnson: sorry for pestering, did you had a chance to look at 9273 again? [14:25] ijohnson: it seems like mborzecki adressed the raised points and this just needs a re-review [14:25] seb128: fwiw, I pushed a SRU for the failing autopkgtest, if you feel like reviewing/approving the sru :) [14:25] mvo: sorry it's on my queue for today, do you need me to look right now right now or can it wait til the PM? [14:25] seb128: uploaded to focal-proposed [14:26] ijohnson: it can wait of course, just wanted to check if my msg made it :) [14:26] mvo, thanks, I'm not in the SRU team though so I can't do that... [14:26] seb128: oh, sorry then [14:26] mvo: ack sounds good [14:26] no worry! [14:29] cachio: fwtw snapd uses boot_id internally to track reboots [14:30] pstolowski, nice, I am running tests here to validate the change and I'll push it [14:30] cachio: but i don't know if this is the only thing [14:34] cmatsuoka: pedronis: i've updated #9298 (cc mvo) [14:34] PR #9298: boot: represent boot chains, helpers for marshalling and equivalence checks [14:34] PR snapcraft#3280 opened: Revert "lxd: update connectivity check url" [14:34] mborzecki: thank you! [14:34] mborzecki: ack, will check [14:54] gocheck does not respect test.failfast [15:00] mborzecki: cmatsuoka: commented there [15:01] pstolowski, fix pushed, thanks for the review [15:02] * cachio lunch [15:17] mborzecki: cmatsuoka: added one more comment [15:32] * cmatsuoka breaks for lunch [15:39] Hello There! [15:40] I'm having some trouble with snaps programs installation. [15:43] mborzecki: we probably need bootAssetsEqual ? [15:43] pedronis: got predictableBootAssetsEqual instead [15:44] yes [15:46] There is a Website that I can write multiple lines and past the URL here so I don't flood the channel. Anyone knows what site i'm talking about? [15:47] Jairo_Mx: pastebin.ubuntu.com ? [15:47] Jairo_Mx: you can also use the forum at forum.snapcraft.io [15:47] yep [15:48] zyga-kaveri, I've tried to find an answer at the forum, but I wasn't able to find it [15:50] you can post long stuff there as well [15:52] pedronis: #9237 is updated (finally) [15:52] PR #9237: devicestate: enable cloud-init on uc20 for grade signed and secured [15:53] https://pastebin.ubuntu.com/p/sq2S8VWG2z/ [15:54] Is there a good soul that is able to help me how to fix this? [15:55] Jairo_Mx: snapd requires systemd to operate [15:55] Jairo_Mx: I'm afraid that unless you can install systemd and reboot, nothing will help [15:56] how can I install systemd? [15:56] Jairo_Mx: what distro is this that you are using? [15:57] ijohnson: thx, I will look in a bit [15:57] Jairo_Mx: looks like you have debian 10, is that right? [15:57] thanks pedronis [15:57] Mx Linux Xfce [15:58] mx linux is built off of antix linux it seems, and antix linux is described thusly on the website (antixlinux.com): [15:58] > antiX is a fast, lightweight and easy to install systemd-free linux [15:58] Jairo_Mx: it seems the best way forward is to install debian with xfce instead [15:59] yeah what zyga-kaveri said [16:01] Ok, I'll reboot now. [16:04] pedronis: cmatsuoka: ok, updated the PR [16:04] got to run some errands now, i'll check back later [16:07] Jairo@jairo:~$ systemctl [16:07] System has not been booted with systemd as init system (PID 1). Can't operate. [16:07] I just reinstalled systemd again, rebooted and I still have the same issue [16:08] ijohnson: reviewed [16:08] ijohnson: have a consideration there [16:09] pedronis: do we care about custom vm images for i.e. multipass and `grade: secured` where the gadget in the image has NoCloud config ? [16:09] if not then I can do what you say and always set DisableNoCloud to true, but that would break the use case of setting up NoCloud in your gadget snap on `grade: secured` [16:09] ijohnson: but we said they don't need to run more than once, no? [16:10] ah yes good point [16:10] ok, then what you are saying is fine to do then [16:10] ijohnson: I mean, we are not disabling it fully, we are disabling after first boot, right? [16:10] yes that is accurate [16:11] yes, let's try to go that way and see if somebody protests [16:11] "DisableNoCloud" really means "disable after first boot if NoCloud, but restrict if not NoCloud" [16:11] yes [16:11] that was my understanding [16:11] perhaps DisableNoCloud is slightly misleading in that respect [16:11] well it's option to restrict [16:12] hmm right it is in CloudInitRestrictOptions [16:18] mborzecki: thx, are you about to EOD? [16:18] pedronis: yeah, about to leave do to groceries and stuff [16:18] mborzecki: ok, thx [16:19] mborzecki: cmatsuoka: I'll push some tweaks and TODOs there, the best is try to land it and then iterate [16:26] ok, again, all unit tests pass [16:26] I'll run spread and write an invariant checker that tools are valid [16:28] pedronis, cmatsuoka anything I can help with at this point? [16:28] #9221 is now ready for reviews [16:28] PR #9221: tests: disk space awareness spread test [16:29] mvo: #9298 needs reviews [16:29] PR #9298: boot: represent boot chains, helpers for marshalling and equivalence checks [16:30] pedronis: ta [16:30] pedronis: #9237 is ready again [16:30] PR #9237: devicestate: enable cloud-init on uc20 for grade signed and secured [16:31] mvo: if you really have nothing better to do (which I'm sure is false), you could review my uc20 cloud-init work with ^ [16:31] ijohnson: thanks, I see what I can do [16:31] * mvo needs to take a short break first [16:55] ijohnson: cmatsuoka: I pushed tweaks to #9298 (mostly about bootChain sorting plus some TODOs), it needs reviews [16:55] PR #9298: boot: represent boot chains, helpers for marshalling and equivalence checks [16:55] pedronis: ok, checking [16:56] ijohnson: I'll look at 9237 after dinner [17:04] thanks pedronis I will give 9298 a review after my lunch [17:28] ijohnson, hey [17:28] about this cloud init issue that you mentions [17:28] I see some connectoin errors in the nested [17:28] hi. beginner question. I installed ffmpeg via snap. When I try to create a file /tmp/out.mp4, ffmpeg does that and says it's done, but the file isn't there. when I try to run ffmpeg again, it sees the file. Where is it? Is snap making ffmpeg use a virtual filesystem? [17:28] ijohnson, is it related to that? [17:28] it is like it can't connect [17:38] answering myself: the package seems /tmp/snap.ffmpeg/tmp as the temp directory. Is there a way around this? [17:42] cachio: can you share logs ? [17:44] I've implemented undo logic for the new handlers [17:44] I need to write a few more tests now [17:44] but first a spread run and a longer break to check up with the family [17:44] o/ [17:45] ijohnson, https://github.com/snapcore/snapd/pull/9284/checks?check_run_id=1086629776#step:5:9111 [17:45] PR #9284: tests: some fixes and improvements for nested execution [17:48] cachio: that could be cloud-init, it's unclear unfortunately, but it's not an issue where it can't connect, the issue is it can't create the user [17:48] or rather that the user wasn't created somehow [17:48] ijohnson, yes [17:48] but it is not happening 100% of the times [17:49] some tests passed [17:49] some others dont [18:34] cmatsuoka: are you blocked? do you know what to do next? [18:35] pedronis: I'm currently creating bootChains [18:36] pedronis: some things are not fitting in a very smooth way there but I'm trying to work it out [18:37] cmatsuoka: should we chat quickly? [18:37] pedronis: SU room? [18:37] yes [18:37] one sec [19:09] * zyga-kaveri wonders if the two handlers are sufficient [19:09] some more changes to do [19:12] setting the current symlink should be in sync with link snap, it is now but the task structure feels somehow wrong [19:14] zyga-kaveri, hey, when you have time could you take a second look to #8986 please? [19:14] PR #8986: tests: new snaps-state command - part1 [19:15] cachio: tomorrow, ok? I want to EOD in the next few minutes [19:15] zyga-kaveri, sure, thanks [19:15] PR snapd#9299 opened: tests/core/uc20-recovery: fix check for at least 2 calls to mock-shutdown