[00:40] PR snapd#9278 opened: boot: seal using boot chains from bootloader [01:40] PR snapd#9253 closed: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf [02:27] PR core20#85 opened: hooks: adapt to motd-news-config not being included in image any more [03:29] PR core18#168 opened: hooks: adapt to motd-news-config not being included in image any more [06:09] morning [06:17] PR core20#85 closed: hooks: adapt to motd-news-config not being included in image any more [06:19] PR core18#168 closed: hooks: adapt to motd-news-config not being included in image any more [06:59] mvo: hey [07:01] morning [07:08] pstolowski: heya [07:12] good morning mborzecki and pstolowski ! [07:16] PR snapd#9274 closed: tests: simplify and fix tests for disk space checks on snap remove [07:20] let's see if i've fixed tumbleweed builds [07:21] rpm macros are a bit pita [07:21] PR snapd#9271 closed: boot: keep track of the original asset when observing updates [07:22] yay [07:22] * mvo hugs mborzecki [07:23] pstolowski: 9245 needs a master merge now, yes? your test refactor got merged to tmaster [07:25] mvo: yes, thanks, will do [07:26] ta [07:27] re cups issue on 20.10, there are no destinations/printers defined, confirmed with lpstat and lpoptions, seems something changed in 20.10, [07:30] I suppose we could check what is set up in 20.04, and try to clone that config over in the test? [07:31] pedronis: yep, i'll try to figure that [07:33] duh, so %{_libexecdir} in opensuse 15.2 expands to /usr/lib, but in TW it's /usr/libexec [07:36] zyga-kaveri: around? [07:39] https://lists.opensuse.org/opensuse-factory/2019-10/msg00207.html [07:47] PR snapd#8920 closed: interfaces: update cups-control and add cups for providing snaps

[07:52] PR snapd#9279 opened: github: run tests also on push to release branches [07:57] PR snapd#9280 opened: packaging/opensuse: do not hardcode AppArmor profile path [08:31] good morning [08:34] hey zyga ! [08:35] last night was productive [08:35] morning was easy [08:35] let's make this day count [08:38] So it looks like the UC20 seeding process doesn't like me having multiple base snaps in my image [08:42] jamesh I think someone asked about this [08:42] you can have any number of bases [08:42] but you must have one boot base [08:42] IIRC the yaml for 20 is different [08:42] although having never done this, I really don't know the details [08:43] zyga: sure. I'm tripping the error in LoadEssentialMeta() from seed/seed20.go: I think it is finding more essential snaps than it expects so erroring out [08:44] i.e. there's two bases, a kernel, and a snapd, which doesn't equal len([base, kernel, snapd]) [08:45] zyga: this is my model definition: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model [08:47] hmm [08:47] indeed [08:48] mborzecki ^ [08:48] is this expected? [08:48] perhaps I could lie and pretend the second base is an app [08:48] but that might cause a later failure [08:48] zyga: can you take a look at https://github.com/snapcore/snapd/pull/9280 ? [08:48] PR #9280: packaging/opensuse: do not hardcode AppArmor profile path [08:49] uhhhh [08:49] ffs [08:49] libexec [08:49] I hate that stuff [08:49] jamesh: got full log? [08:50] i'm guessing it's confused about two bases, and probbaly expects core20 base to be used [08:51] mborzecki: I was booting this in a VM and it is on the VGA console rather than serial [08:51] jamesh: screenshot works too :P [08:51] hm maybe i can try and replicate it here [08:52] mborzecki thank you [08:52] mborzecki +1 [08:53] mborzecki: https://imgur.com/a/EK5lKD8 [08:53] fix for cups test coming [08:53] mborzecki: this is built from the following model: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model [08:57] jamesh: which base do you want to boot with? -gdm? [08:57] mborzecki: core20-gdm (the one I list as the base at the top level) [08:58] can you drop the type: [base|app] for all other snaps? [08:58] mborzecki: I had a booting image before I added core20 and network-manager [08:59] mborzecki: i.e. this one worked: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/a08a02d949bd616558827b695ad18ec6bec09110/gdm-spike-model.model [08:59] jamesh: right, afaiu the code picks snaps of a given type from the model, the initramfs helper expects base, kernel and snapd, but gets 2 bases, kernel and snapd and thus gets confused [08:59] that was my guess too [09:00] instead it should be checking whether there is at least one of each essential type [09:00] seb128: hi, do you know if there is a deliberate change in cups on 20.10 that would explain the need for something like https://github.com/snapcore/snapd/pull/9281 ? [09:00] PR #9281: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> [09:01] jamesh: maybe if you drop the type: from from the extra snaps it will work, or skip those snaps altogether for now and use --snap with ubuntu-image and we can fix the code if needed [09:01] pstolowski looking [09:02] mborzecki: would anything be likely to break if I lied and pretended core20 was an app snap here? [09:02] PR snapd#9281 opened: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> [09:02] I suppose I can just give it a go [09:03] jamesh: iirc type: is not mandatory there, if it's missing the snap becomes required, while if you specify type: base it means it's a base you boot (at least that's my undetanding) pedronis please correct me if i'm wrong [09:05] mborzecki: looking at the code that reads the model, missing is treated as "type: app". I'll give it a go and see if I have a booting image [09:13] pstolowski, hey, I don't know, best to check with tkamppeter on #ubuntu-desktop [09:13] seb128: sure, ok, thanks [09:17] mvo, pedronis: updated #9245 [09:17] PR #9245: o/snapstate, features: add feature flags for disk space awareness [09:18] jamesh: we fixed something related to that but it might not be in stable [09:18] jamesh: https://bugs.launchpad.net/snapd/+bug/1883973 [09:18] Bug #1883973: cannot boot uc20 model with multiple base snaps [09:22] ijohnson: do I remember correctly that you had an example snap that allows loading extra certs via custom configure hooks? I thought that was docker but I looked at the code and can't see it there. or am I misremembering? the maas team is curious about this [09:25] pedronis: that bug certainly sounds like the same issue, yeah. [09:32] pstolowski: thanks for #9281, commented there [09:32] PR #9281: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> [09:42] * Eighth_Doctor waves [09:42] zyga: if it makes you feel any better, I'm eliminating a difference across distros :) [09:43] by virtue of patience and persistence :) [09:44] Debian 11 / Ubuntu 20.04, openSUSE Tumbleweed, and Fedora/RHEL now all permit the exact same paths for binaries of all kinds [09:44] that is, /usr/bin, /usr/sbin, and /usr/libexec [09:45] The Debian aversion to libexec always seemed a weird hill to make a stand on [09:45] yeah [09:46] with the upgrade to FHS 3.0, they finally stopped doing that [09:48] The omission from FHS also seemed weird, when it was mostly a standard describing existing best practice, but decided to forbid this one with a justification that didn't seem to understand what people would put there [09:49] my understanding was that they didn't like that Linux systems inherited the practice from BSD (which is where most of the Unixisms in Linux come from) [09:49] AT&T Unix lacked libexec, BSD added it because it was needed for some binaries [09:50] and at the time, Linux distributions were moving from BSD-style stuff to SysV-style stuff (except Slackware, which never changed) [09:50] sure, but cluttering directories searched by the dynamic linker with non-libraries never seemed like a better choice [09:50] it wasn't, which is why Red Hat Linux never dropped it [09:50] SuSE Linux had it added and then removed in ~2000 [09:51] Debian removed it in 2003 [09:51] but distributions lacking the libexec path had to find other ways to handle this [09:52] and that was... incoherent and inconsistent [09:53] jamesh: funnily enough, I need to update Fedora docs to move our references to FHS 2.3 with exceptions to 3.0 with no exceptions ;) [09:53] FHS 3.0 was the point where they decided that all the current practices that weren't going to go away were finally documented [09:58] I was mainly working upstream during that time frame, so just had to deal with distro bug reports with weird paths [10:01] well, at least now hopefully this is one less thing to deal with [10:02] the only difference left now is /usr/lib/ in Debian verses /usr/lib(32|64) everywhere else [10:02] zyga looks like we have unhappy tests in 16.04 currently https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/12517/signedlogcontent/78?urlExpires=2020-09-04T10%3A02%3A37.1597745Z&urlSigningMethod=HMACV1&urlSignature=NcrO%2BGTSFMEl0h0dVzsxox54uC0Va1fhKQq6cZVIpvQ%3D [10:02] zyga it's google:ubuntu-16.04-64:tests/regression/lp-1813963 [10:02] zyga more specifically [ 1922.415859] audit: type=1400 audit(1599171492.141:1234): apparmor="DENIED" operation="open" profile="snap-update-ns.test-snapd-simple-service" name="/proc/cmdline" pid=31417 comm="5" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [10:03] zyga I wonder if the logger change to look at /proc/cmdline causes this maybe? [10:03] zyga but then I wonder why it's starts happening now :( [10:07] zyga but it's also strange, our default profile has "@{PROC}/cmdline r" [10:19] mvo: snap-update-ns gets its own profile though, not sure it contains the default [10:20] huh, why does govendor sync fail randomly on TW? [10:24] mvo hmmm [10:24] mvo looking now [10:24] mvo sorry, had to hand over lucy [10:25] I feel like Saturday is work catchup for me this week [10:25] mvo: uri expired [10:25] mvo is that master or a PR? [10:25] pedronis: indeed, it seems to be missing there [10:25] mvo: as samuele pointed out, snap-update-ns has a derived per-snap profile [10:25] it's in apparmor/templates [10:25] zyga: master and pr [10:25] UpdateNS* [10:25] shall I fix it? [10:26] zyga: I can fix it [10:26] ok [10:26] zyga: it's just adding /proc/cmdline, right? [10:26] yes [10:26] with @{PROC} [10:26] as to why it was missed [10:26] zyga what is puzzling is that it did not happen when the PR was merged [10:26] is it possible we hit rate limiting [10:26] zyga oh, ok [10:26] I know we disable it sometimes but perhaps that is buggy [10:26] which OS did it fail on? [10:27] zyga: 16.04 [10:27] hmm [10:28] zyga and only with google:ubuntu-16.04-64:tests/regression/lp-1813963 it seems [10:28] * zyga looks at that test [10:29] # Nothing should have been denied yet. [10:29] test "$(dmesg | grep -c DENIED)" -eq 0 [10:29] I think none of or regular tests care about apparmor denials [10:31] zyga ok, I think I will add something then to spread too (something trivial) [10:31] zyga thanks for your help! [10:31] good luck [10:34] Eighth_Doctor: unless you take that all the way to Debian it's just a transition that changes little in the grand scheme of things [10:35] Eighth_Doctor wait, wat, debian is using libexec as well? [10:36] Eighth_Doctor: the debian multiarch triplet is superior to libXY things so I'd love to see that spread as well [10:36] anyway, back to coding [10:37] zyga: Debian is adopting it too [10:37] it even leaked into Ubuntu 20.04 ;) [10:37] look at the gnome-terminal package file list sometime ;) [10:38] zyga: some work in rpm is required first before I could consider the multiarch triplet thing [10:38] we're discussing improving the handling of autodeps to include more architecture info [10:41] that's really nice [10:43] zyga: I did have an initial go at it, which wound up prompting a bigger discussion about improving arch handling in general: https://github.com/rpm-software-management/rpm/pull/1038 [10:43] PR rpm-software-management/rpm#1038: elfdeps: Add full multiarch deps support [10:50] zyga it's up now [10:51] mvo: where? [10:51] zyga-kaveri: pr 9282 [10:51] PR #9282: interfaces: allow snap-update-ns to read /proc/cmdline [10:51] zyga-kaveri: pretty trivial [10:52] ah, thank you [10:52] PR snapd#9282 opened: interfaces: allow snap-update-ns to read /proc/cmdline [10:53] mvo: reviewed [10:53] zyga-kaveri: that was quick :) [10:53] zyga-kaveri: I will cherry pick to 2.46, yes [10:56] #9245 needs 2nd review [10:56] PR #9245: o/snapstate, features: add feature flags for disk space awareness [10:57] pstolowski: looking [10:57] PR snapd#9281 closed: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> [10:58] mvo: ta! [10:59] pstolowski: thank *you* [11:01] pstolowski: https://github.com/snapcore/snapd/pull/9245#pullrequestreview-482557720 [11:01] PR #9245: o/snapstate, features: add feature flags for disk space awareness [11:01] zyga-kaveri: thanks, will tweak it in one of the other PRs [11:02] it's not a biggie :) [11:02] thank you [11:02] PR snapd#9245 closed: o/snapstate, features: add feature flags for disk space awareness [11:22] mborzecki: I reviewed #9273, some questions and remarks there, it doesn't look completely right atm [11:22] PR #9273: boot: mark successful with boot assets [11:22] pedronis: thanks, let me see [11:54] * zyga-kaveri small break [12:12] pfff no power === mborzeck2 is now known as mborzcki [12:38] mborzecki: fun [12:39] zyga-kaveri: hm? [12:41] hm opensuse TW should be good now [12:41] and spread is weird, a suite prepare fails and it tore down the setup of other suites too apparently [12:42] maybe there's something special about passing suites in the command line [12:43] PR snapd#9283 opened: seed,c/snap-bootstrap: simplify snap-bootstrap seed reading with new seed.ReadSystemEssential [12:44] cmatsuoka: ^ that should hopefully help dealing with seeds in boot [12:44] pedronis: thanks, will check in a minute [12:45] mborzecki: did my comments in 9273 make some sense? [12:56] zyga: i included the tweak you suggested in https://github.com/snapcore/snapd/pull/9220 [12:56] PR #9220: o/snapstate: disk space check with single snap install [12:58] pedronis: yup, i'm updating the PR [12:58] pstolowski thanks [12:59] damn, and it's raining again [12:59] i don't see how the forecast of 25C tomorrow makes any sense [13:27] that new "generic" brand-id feature for model assertions, do we have any example assertion anywhere using it (or just a doc describing it) ? [13:29] (i'd liek to get rid of the "initialize device" errors on custom images) [13:29] *like [13:35] cachio: https://github.com/snapcore/snapd/pull/9280 <- opensuse tumbleweed fixes [13:35] PR #9280: packaging/opensuse: fix for /usr/libexec on TW, do not hardcode AppArmor profile path [13:42] pedronis sorry give me a couple minutes need to take care of something [13:42] ok [13:45] pedronis rejoining now [13:54] ijohnson, #9098 squash merged [13:54] PR #9098: tests: new organization for nested tests

[13:54] \o/ [13:54] very nice thanks cachio [13:54] ijohnson, now we can merge master [13:54] cachio: yes I will rebase my PR which I didn't open yesterday on these changes [13:54] thanks for all the work there [13:55] ijohnson, yaw [13:55] now I neeed to create a new one with small fixes [13:58] PR snapd#9098 closed: tests: new organization for nested tests

[14:02] mvo: hey, I know that the /proc/cmdline isn't a big deal, but it reminded my that while I may not be focusing on engineering atm, I'd like you to still come to us for policy changes. do 'needs security review' or whatever. you'll probably need to ping me. I can then assign someone, then review their assessment [14:03] jdstrand: nice, thank you! [14:03] mvo: I've talked to amurray and emitorino about this and they are aware [14:04] emitorino: 09:02 < jdstrand> mvo: hey, I know that the /proc/cmdline isn't a big deal, but it reminded my that while I may not be focusing on engineering atm, I'd like you to still come to us for policy changes. do 'needs security review' or whatever. you'll probably need to ping me. I can then assign someone, then review their assessment [14:04] mvo: for more involved PRs, we'll have to have a conversation, but do feel like you can reach out to have the conversation :) [14:08] pedronis: i've updated #9273 [14:08] PR #9273: boot: mark successful with boot assets [14:16] mvo: thank you so much for merging the cups PR. I defer to you on 2.46 at this point. if you want it in 2.46, do you want me to do a PR? [14:23] ijohnson: am I confused? there's a couple of points in my first review of #9237 that weren't touched, should I re-review it anyway? [14:23] PR #9237: devicestate: enable cloud-init on uc20 for grade signed and secured [14:23] jdstrand: I asked in the desktop team channel if they need it urgently. it seems they are fine with it being in 2.47 [14:24] jdstrand: we will do 2.47 very soon as it contains all the uc20 bits [14:25] pedronis ah sorry missed that I will address it later sorry this morning is very busy for me [14:26] it's ok [14:26] just bit confused [14:34] mvo: wfm, thanks [14:34] ta === pedronis_ is now known as pedronis [15:03] PR snapd#9282 closed: interfaces: allow snap-update-ns to read /proc/cmdline [15:04] pedronis: when you say a helper in sysconfig, do you mean just the filepath.Join or do you mean the check for the cloud.conf existing there? [15:04] ijohnson: the check [15:04] i.e. do you want `func GadgetCloudConf(dir string) string` or did you want `func HasGadgetCloudConf(dir string) bool` [15:04] just the join is a bit silly I suppose [15:04] ok, is `HasGadgetCloudConf` a reasonable name [15:04] ? [15:04] yes [15:05] ack, thanks will push something up in a few minutes [15:06] pedronis: re SystemInstallObserver in install.go, install.go is !nosecboot, is it ok for you to define it also in install_dummy.go? [15:06] ah, I forgot about that [15:07] (I had placed it initially in install.go before I noticed that) [15:07] cmatsuoka: I think maybe it fine where it is then but s/options.go/types.go/params.go/ [15:07] pedronis: will rename to params, thanks [15:14] * zyga has working integration tests now :-) [15:15] now to add more tests using this pattern [15:15] but first tiny brek [15:15] *break [15:15] pedronis: ok now I addressed all your comments in 9237 [15:21] ijohnson: thx, I don't know if I get to look at it again today [15:21] pedronis: fun, I just looked at 20.10 failure logs and it's not longer degraded, the failure I see there is slightly different [15:21] no problem, I'm off on Monday anyways so not a big deal [15:27] * cmatsuoka needs to get groceries and have lunch, bbl [15:43] ijohnson, I just pushed #9284 with some fixes for nested [15:43] PR #9284: tests: some fixes and improvements for nested execution [15:43] PR snapd#9284 opened: tests: some fixes and improvements for nested execution [15:44] ijohnson, if you could take a quick look should be nice [15:44] cachio: sure looking now [15:44] it is pretty simple [15:45] ijohnson, thanks [15:56] hmm [15:56] I think spread has a bug in reboot handling [15:57] I have a qemu vm that reboots [15:57] running it with gui shows me that the reboot completes and the machine is fully operational [15:57] but spread sometimes just sits there waiting and waiting [15:57] it's maybe one of 4-5 attempts [15:57] on a relatively slow dual core system [15:59] zyga-kaveri, at some point I fixed that [15:59] there is a PR for that [15:59] nerver merged [15:59] oh super [15:59] oh [15:59] which PR is that? [16:00] zyga-kaveri, https://github.com/snapcore/spread/pull/70 [16:00] PR spread#70: Close ssh connection when reboot is stuck [16:00] is it the same that you see? [16:01] I didn't debug it yet, all I see is the rebooting message and nothing more [16:01] can you close the ticker, we could get this reviewed and merged [16:02] zyga-kaveri, https://paste.ubuntu.com/p/kzJhnP7BHj/ [16:02] this is the error in spread [16:02] zyga-kaveri, yes I can fix that [16:02] locally I just see [16:02] 2020-09-04 17:51:41 Rebooting on qemu:ubuntu-20.10-64 (qemu:ubuntu-20.10-64) as requested... [16:03]