[00:40] <mup> PR snapd#9278 opened: boot: seal using boot chains from bootloader <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278>
[01:40] <mup> PR snapd#9253 closed: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>
[02:27] <mup> PR core20#85 opened: hooks: adapt to motd-news-config not being included in image any more <Created by jhenstridge> <https://github.com/snapcore/core20/pull/85>
[03:29] <mup> PR core18#168 opened: hooks: adapt to motd-news-config not being included in image any more <Created by jhenstridge> <https://github.com/snapcore/core18/pull/168>
[06:09] <mborzecki> morning
[06:17] <mup> PR core20#85 closed: hooks: adapt to motd-news-config not being included in image any more <Created by jhenstridge> <Merged by vorlonofportland> <https://github.com/snapcore/core20/pull/85>
[06:19] <mup> PR core18#168 closed: hooks: adapt to motd-news-config not being included in image any more <Created by jhenstridge> <Merged by vorlonofportland> <https://github.com/snapcore/core18/pull/168>
[06:59] <mborzecki> mvo: hey
[07:01] <pstolowski> morning
[07:08] <mborzecki> pstolowski: heya
[07:12] <mvo> good morning mborzecki and pstolowski !
[07:16] <mup> PR snapd#9274 closed: tests: simplify and fix tests for disk space checks on snap remove <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9274>
[07:20] <mborzecki> let's see if i've fixed tumbleweed builds
[07:21] <mborzecki> rpm macros are a bit pita
[07:21] <mup> PR snapd#9271 closed: boot: keep track of the original asset when observing updates  <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9271>
[07:22] <mborzecki> yay
[07:22]  * mvo hugs mborzecki 
[07:23] <mvo> pstolowski: 9245 needs a master merge now, yes? your test refactor got merged to tmaster
[07:25] <pstolowski> mvo: yes, thanks, will do
[07:26] <mvo> ta
[07:27] <pstolowski> 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] <pedronis> I suppose we could check what is set up in 20.04, and try to clone that config over in the test?
[07:31] <pstolowski> pedronis: yep, i'll try to figure that
[07:33] <mborzecki> duh, so %{_libexecdir} in opensuse 15.2 expands to /usr/lib, but in TW it's /usr/libexec
[07:36] <mborzecki> zyga-kaveri: around?
[07:39] <mborzecki> https://lists.opensuse.org/opensuse-factory/2019-10/msg00207.html
[07:47] <mup> PR snapd#8920 closed: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Squash-merge> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8920>
[07:52] <mup> PR snapd#9279 opened: github: run tests also on push to release branches <Created by mvo5> <https://github.com/snapcore/snapd/pull/9279>
[07:57] <mup> PR snapd#9280 opened: packaging/opensuse: do not hardcode AppArmor profile path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9280>
[08:31] <zyga> good morning
[08:34] <pstolowski> hey zyga !
[08:35] <zyga> last night was productive
[08:35] <zyga> morning was easy
[08:35] <zyga> let's make this day count
[08:38] <jamesh> So it looks like the UC20 seeding process doesn't like me having multiple base snaps in my image
[08:42] <zyga> jamesh I think someone asked about this
[08:42] <zyga> you can have any number of bases
[08:42] <zyga> but you must have one boot base
[08:42] <zyga> IIRC the yaml for 20 is different
[08:42] <zyga> although having never done this, I really don't know the details
[08:43] <jamesh> 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] <jamesh> i.e. there's two bases, a kernel, and a snapd, which doesn't equal len([base, kernel, snapd])
[08:45] <jamesh> zyga: this is my model definition: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model
[08:47] <zyga> hmm
[08:47] <zyga> indeed
[08:48] <zyga> mborzecki ^
[08:48] <zyga> is this expected?
[08:48] <jamesh> perhaps I could lie and pretend the second base is an app
[08:48] <jamesh> but that might cause a later failure
[08:48] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/9280 ?
[08:48] <mup> PR #9280: packaging/opensuse: do not hardcode AppArmor profile path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9280>
[08:49] <zyga> uhhhh
[08:49] <zyga> ffs
[08:49] <zyga> libexec
[08:49] <zyga> I hate that stuff
[08:49] <mborzecki> jamesh: got full log?
[08:50] <mborzecki> i'm guessing it's confused about two bases, and probbaly expects core20 base to be used
[08:51] <jamesh> mborzecki: I was booting this in a VM and it is on the VGA console rather than serial
[08:51] <mborzecki> jamesh: screenshot works too :P
[08:51] <mborzecki> hm maybe i can try and replicate it here
[08:52] <zyga> mborzecki thank you
[08:52] <zyga> mborzecki +1
[08:53] <jamesh> mborzecki: https://imgur.com/a/EK5lKD8
[08:53] <pstolowski> fix for cups test coming
[08:53] <jamesh> mborzecki: this is built from the following model: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model
[08:57] <mborzecki> jamesh: which base do you want to boot with? -gdm?
[08:57] <jamesh> mborzecki: core20-gdm (the one I list as the base at the top level)
[08:58] <mborzecki> can you drop the type: [base|app] for all other snaps?
[08:58] <jamesh> mborzecki: I had a booting image before I added core20 and network-manager
[08:59] <jamesh> mborzecki: i.e. this one worked: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/a08a02d949bd616558827b695ad18ec6bec09110/gdm-spike-model.model
[08:59] <mborzecki> 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] <jamesh> that was my guess too
[09:00] <jamesh> instead it should be checking whether there is at least one of each essential type
[09:00] <pstolowski> 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] <mup> PR #9281: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9281>
[09:01] <mborzecki> 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 <path> with ubuntu-image and we can fix the code if needed
[09:01] <zyga> pstolowski looking
[09:02] <jamesh> mborzecki: would anything be likely to break if I lied and pretended core20 was an app snap here?
[09:02] <mup> PR snapd#9281 opened: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9281>
[09:02] <jamesh> I suppose I can just give it a go
[09:03] <mborzecki> 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] <jamesh> 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] <seb128> pstolowski, hey, I don't know, best to check with tkamppeter on #ubuntu-desktop
[09:13] <pstolowski> seb128: sure, ok, thanks
[09:17] <pstolowski> mvo, pedronis: updated #9245
[09:17] <mup> PR #9245: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9245>
[09:18] <pedronis> jamesh: we fixed something related to that but it might not be in stable
[09:18] <pedronis> jamesh: https://bugs.launchpad.net/snapd/+bug/1883973
[09:18] <mup> Bug #1883973: cannot boot uc20 model with multiple base snaps <snapd:Fix Committed by pedronis> <https://launchpad.net/bugs/1883973>
[09:22] <mvo> 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] <jamesh> pedronis: that bug certainly sounds like the same issue, yeah.
[09:32] <pedronis> pstolowski: thanks for #9281,  commented there
[09:32] <mup> PR #9281: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9281>
[09:42]  * Eighth_Doctor waves
[09:42] <Eighth_Doctor> zyga: if it makes you feel any better, I'm eliminating a difference across distros :)
[09:43] <Eighth_Doctor> by virtue of patience and persistence :)
[09:44] <Eighth_Doctor> Debian 11 / Ubuntu 20.04, openSUSE Tumbleweed, and Fedora/RHEL now all permit the exact same paths for binaries of all kinds
[09:44] <Eighth_Doctor> that is, /usr/bin, /usr/sbin, and /usr/libexec
[09:45] <jamesh> The Debian aversion to libexec always seemed a weird hill to make a stand on
[09:45] <Eighth_Doctor> yeah
[09:46] <Eighth_Doctor> with the upgrade to FHS 3.0, they finally stopped doing that
[09:48] <jamesh> 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] <Eighth_Doctor> 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] <Eighth_Doctor> AT&T Unix lacked libexec, BSD added it because it was needed for some binaries
[09:50] <Eighth_Doctor> and at the time, Linux distributions were moving from BSD-style stuff to SysV-style stuff (except Slackware, which never changed)
[09:50] <jamesh> sure, but cluttering directories searched by the dynamic linker with non-libraries never seemed like a better choice
[09:50] <Eighth_Doctor> it wasn't, which is why Red Hat Linux never dropped it
[09:50] <Eighth_Doctor> SuSE Linux had it added and then removed in ~2000
[09:51] <Eighth_Doctor> Debian removed it in 2003
[09:51] <Eighth_Doctor> but distributions lacking the libexec path had to find other ways to handle this
[09:52] <Eighth_Doctor> and that was... incoherent and inconsistent
[09:53] <Eighth_Doctor> 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] <Eighth_Doctor> 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] <jamesh> I was mainly working upstream during that time frame, so just had to deal with distro bug reports with weird paths
[10:01] <Eighth_Doctor> well, at least now hopefully this is one less thing to deal with
[10:02] <Eighth_Doctor> the only difference left now is /usr/lib/<triplet> in Debian verses /usr/lib(32|64) everywhere else
[10:02] <mvo> 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] <mvo> zyga it's  google:ubuntu-16.04-64:tests/regression/lp-1813963
[10:02] <mvo> 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] <mvo> zyga I wonder if the logger change to look at /proc/cmdline causes this maybe?
[10:03] <mvo> zyga but then I wonder why it's starts happening now :(
[10:07] <mvo> zyga but it's also strange, our default profile has "@{PROC}/cmdline r"
[10:19] <pedronis> mvo: snap-update-ns gets its own profile though, not sure it contains the default
[10:20] <mborzecki> huh, why does govendor sync fail randomly on TW?
[10:24] <zyga> mvo hmmm
[10:24] <zyga> mvo looking now
[10:24] <zyga> mvo sorry, had to hand over lucy
[10:25] <zyga> I feel like Saturday is work catchup for me this week
[10:25] <zyga> mvo: uri expired
[10:25] <zyga> mvo is that master or a PR?
[10:25] <mvo> pedronis: indeed, it seems to be missing there
[10:25] <zyga> mvo: as samuele pointed out, snap-update-ns has a derived per-snap profile
[10:25] <zyga> it's in apparmor/templates
[10:25] <mvo> zyga: master and pr
[10:25] <zyga> UpdateNS*
[10:25] <zyga> shall I fix it?
[10:26] <mvo> zyga: I can fix it
[10:26] <zyga> ok
[10:26] <mvo> zyga: it's just adding /proc/cmdline, right?
[10:26] <zyga> yes
[10:26] <zyga> with @{PROC}
[10:26] <zyga> as to why it was missed
[10:26] <mvo> zyga what is puzzling is that it did not happen when the PR was merged
[10:26] <zyga> is it possible we hit rate limiting
[10:26] <mvo> zyga oh, ok
[10:26] <zyga> I know we disable it sometimes but perhaps that is buggy
[10:26] <zyga> which OS did it fail on?
[10:27] <mvo> zyga: 16.04
[10:27] <zyga> hmm
[10:28] <mvo> zyga and only with  google:ubuntu-16.04-64:tests/regression/lp-1813963  it seems
[10:28]  * zyga looks at that test
[10:29] <zyga>     # Nothing should have been denied yet.
[10:29] <zyga>     test "$(dmesg | grep -c DENIED)" -eq 0
[10:29] <zyga> I think none of or regular tests care about apparmor denials
[10:31] <mvo> zyga ok, I think I will add something then to spread too (something trivial)
[10:31] <mvo> zyga thanks for your help!
[10:31] <zyga> good luck
[10:34] <zyga> 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] <zyga> Eighth_Doctor wait, wat, debian is using libexec as well?
[10:36] <zyga> Eighth_Doctor: the debian multiarch triplet is superior to libXY things so I'd love to see that spread as well
[10:36] <zyga> anyway, back to coding
[10:37] <Eighth_Doctor> zyga: Debian is adopting it too
[10:37] <Eighth_Doctor> it even leaked into Ubuntu 20.04 ;)
[10:37] <Eighth_Doctor> look at the gnome-terminal package file list sometime ;)
[10:38] <Eighth_Doctor> zyga: some work in rpm is required first before I could consider the multiarch triplet thing
[10:38] <Eighth_Doctor> we're discussing improving the handling of autodeps to include more architecture info
[10:41] <zyga> that's really nice
[10:43] <Eighth_Doctor> 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] <mup> PR rpm-software-management/rpm#1038: elfdeps: Add full multiarch deps support <Created by Conan-Kudo> <https://github.com/rpm-software-management/rpm/pull/1038>
[10:50] <mvo> zyga it's up now
[10:51] <zyga-kaveri> mvo: where?
[10:51] <mvo> zyga-kaveri: pr 9282
[10:51] <mup> PR #9282: interfaces: allow snap-update-ns to read /proc/cmdline <Created by mvo5> <https://github.com/snapcore/snapd/pull/9282>
[10:51] <mvo> zyga-kaveri: pretty trivial
[10:52] <zyga-kaveri> ah, thank you
[10:52] <mup> PR snapd#9282 opened: interfaces: allow snap-update-ns to read /proc/cmdline <Created by mvo5> <https://github.com/snapcore/snapd/pull/9282>
[10:53] <zyga-kaveri> mvo: reviewed
[10:53] <mvo> zyga-kaveri: that was quick :)
[10:53] <mvo> zyga-kaveri: I will cherry pick to 2.46, yes
[10:56] <pstolowski> #9245 needs 2nd review
[10:56] <mup> PR #9245: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9245>
[10:57] <mvo> pstolowski: looking
[10:57] <mup> PR snapd#9281 closed: tests: workaround for cups issue on 20.10 where default printer is not configured <⚠ Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9281>
[10:58] <pstolowski> mvo: ta!
[10:59] <mvo> pstolowski: thank *you*
[11:01] <zyga-kaveri> pstolowski: https://github.com/snapcore/snapd/pull/9245#pullrequestreview-482557720
[11:01] <mup> PR #9245: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9245>
[11:01] <pstolowski> zyga-kaveri: thanks, will tweak it in one of the other PRs
[11:02] <zyga-kaveri> it's not a biggie :)
[11:02] <zyga-kaveri> thank you
[11:02] <mup> PR snapd#9245 closed: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9245>
[11:22] <pedronis> mborzecki: I reviewed #9273, some questions and remarks there, it doesn't look completely right atm
[11:22] <mup> PR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[11:22] <mborzecki> pedronis: thanks, let me see
[11:54]  * zyga-kaveri small break
[12:12] <mborzeck2> pfff no power
[12:38] <zyga-kaveri> mborzecki: fun
[12:39] <mborzecki> zyga-kaveri: hm?
[12:41] <mborzecki> hm opensuse TW should be good now
[12:41] <mborzecki> and spread is weird, a suite prepare fails and it tore down the setup of other suites too apparently
[12:42] <mborzecki> maybe there's something special about passing suites in the command line
[12:43] <mup> PR snapd#9283 opened: seed,c/snap-bootstrap: simplify snap-bootstrap seed reading with new seed.ReadSystemEssential <Created by pedronis> <https://github.com/snapcore/snapd/pull/9283>
[12:44] <pedronis> cmatsuoka: ^ that should hopefully help dealing with seeds in boot
[12:44] <cmatsuoka> pedronis: thanks, will check in a minute
[12:45] <pedronis> mborzecki: did my comments in 9273 make some sense?
[12:56] <pstolowski> zyga: i included the tweak you suggested in https://github.com/snapcore/snapd/pull/9220
[12:56] <mup> PR #9220: o/snapstate: disk space check with single snap install <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9220>
[12:58] <mborzecki> pedronis: yup, i'm updating the PR
[12:58] <zyga> pstolowski thanks
[12:59] <mborzecki> damn, and it's raining again
[12:59] <mborzecki> i don't see how the forecast of 25C tomorrow makes any sense
[13:27] <ogra_> 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] <ogra_> (i'd liek to get rid of the "initialize device" errors on custom images)
[13:29] <ogra_> *like
[13:35] <mborzecki> cachio: https://github.com/snapcore/snapd/pull/9280 <- opensuse tumbleweed fixes
[13:35] <mup> PR #9280: packaging/opensuse: fix for /usr/libexec on TW, do not hardcode AppArmor profile path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9280>
[13:42] <ijohnson> pedronis sorry give me a couple minutes need to take care of something
[13:42] <pedronis> ok
[13:45] <ijohnson> pedronis rejoining now
[13:54] <cachio> ijohnson, #9098 squash merged
[13:54] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[13:54] <ijohnson> \o/
[13:54] <ijohnson> very nice thanks cachio
[13:54] <cachio> ijohnson, now we can merge master
[13:54] <ijohnson> cachio: yes I will rebase my PR which I didn't open yesterday on these changes
[13:54] <ijohnson> thanks for all the work there
[13:55] <cachio> ijohnson, yaw
[13:55] <cachio> now I neeed to create a new one with small fixes
[13:58] <mup> PR snapd#9098 closed: tests: new organization for nested tests <Run nested> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[14: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:03] <mvo> jdstrand: nice, thank you!
[14:03] <jdstrand> mvo: I've talked to amurray and emitorino about this and they are aware
[14:04] <jdstrand> 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] <jdstrand> 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] <mborzecki> pedronis: i've updated #9273
[14:08] <mup> PR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[14:16] <jdstrand> 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] <pedronis> 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] <mup> PR #9237: devicestate: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
[14:23] <mvo> 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] <mvo> jdstrand: we will do 2.47 very soon as it contains all the uc20 bits
[14:25] <ijohnson> pedronis ah sorry missed that I will address it later sorry this morning is very busy for me
[14:26] <pedronis> it's ok
[14:26] <pedronis> just bit confused
[14:34] <jdstrand> mvo: wfm, thanks
[14:34] <mvo> ta
[15:03] <mup> PR snapd#9282 closed: interfaces: allow snap-update-ns to read /proc/cmdline <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9282>
[15:04] <ijohnson> 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] <pedronis> ijohnson: the check
[15:04] <ijohnson> i.e. do you want `func GadgetCloudConf(dir string) string` or did you want `func HasGadgetCloudConf(dir string) bool`
[15:04] <pedronis> just the join is a bit silly I suppose
[15:04] <ijohnson> ok, is `HasGadgetCloudConf` a reasonable name
[15:04] <ijohnson> ?
[15:04] <pedronis> yes
[15:05] <ijohnson> ack, thanks will push something up in a few minutes
[15:06] <cmatsuoka> 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] <pedronis> ah, I forgot about that
[15:07] <cmatsuoka> (I had placed it initially in install.go before I noticed that)
[15:07] <pedronis> cmatsuoka: I think maybe it fine where it is then but s/options.go/types.go/params.go/
[15:07] <cmatsuoka> pedronis: will rename to params, thanks
[15:14]  * zyga has working integration tests now :-)
[15:15] <zyga> now to add more tests using this pattern
[15:15] <zyga> but first tiny brek
[15:15] <zyga> *break
[15:15] <ijohnson> pedronis: ok now I addressed all your comments in 9237
[15:21] <pedronis> ijohnson: thx, I don't know if I get to look at it again today
[15:21] <mvo> 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] <ijohnson> 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] <cachio> ijohnson, I just pushed #9284 with some fixes for nested
[15:43] <mup> PR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[15:43] <mup> PR snapd#9284 opened: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[15:44] <cachio> ijohnson, if you could take a quick look should be nice
[15:44] <ijohnson> cachio: sure looking now
[15:44] <cachio> it is pretty simple
[15:45] <cachio> ijohnson, thanks
[15:56] <zyga-kaveri> hmm
[15:56] <zyga-kaveri> I think spread has a bug in reboot handling
[15:57] <zyga-kaveri> I have a qemu vm that reboots
[15:57] <zyga-kaveri> running it with gui shows me that the reboot completes and the machine is fully operational
[15:57] <zyga-kaveri> but spread sometimes just sits there waiting and waiting
[15:57] <zyga-kaveri> it's maybe one of 4-5 attempts
[15:57] <zyga-kaveri> on a relatively slow dual core system
[15:59] <cachio> zyga-kaveri, at some point I fixed that
[15:59] <cachio> there is a PR for that
[15:59] <cachio> nerver merged
[15:59] <zyga-kaveri> oh super
[15:59] <zyga-kaveri> oh
[15:59] <zyga-kaveri> which PR is that?
[16:00] <cachio> zyga-kaveri, https://github.com/snapcore/spread/pull/70
[16:00] <mup> PR spread#70: Close ssh connection when reboot is stuck <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
[16:00] <cachio> is it the same that you see?
[16:01] <zyga-kaveri> I didn't debug it yet, all I see is the rebooting message and nothing more
[16:01] <zyga-kaveri> can you close the ticker, we could get this reviewed and merged
[16:02] <cachio> zyga-kaveri, https://paste.ubuntu.com/p/kzJhnP7BHj/
[16:02] <cachio> this is the error in spread
[16:02] <cachio> zyga-kaveri, yes I can fix that
[16:02] <zyga-kaveri> locally I just see
[16:02] <zyga-kaveri> 2020-09-04 17:51:41 Rebooting on qemu:ubuntu-20.10-64 (qemu:ubuntu-20.10-64) as requested...
[16:03] <zyga-kaveri> 9 minutes
[16:03] <zyga-kaveri> this is not snapd so timeouts are different
[16:03] <cachio> zyga-kaveri, could you try to build spread and test this PR?
[16:03] <cachio> perhaps it is not enough for the problem you see and something else is needed
[16:03] <zyga-kaveri> cachio: yeah, I can try
[16:03] <cachio> zyga-kaveri, thanks
[16:04] <zyga-kaveri> mmm
[16:04] <zyga-kaveri> I'm hungry though, skipped PT, skipped lunch
[16:04] <zyga-kaveri> I'll take a break and test it afterwards
[16:05] <cachio> zyga-kaveri, nice, no hurry
[16:05] <cachio> it is friday :)
[16:06] <mvo> cachio: snapd 2.46.1 should be building now, snapd snap should be there in ~1h, core will take a bit longer
[16:06] <cachio> mvo, nice, thnanks
[16:08]  * mvo -> hockey
[16:09] <mup> PR snapd#9283 closed: seed,c/snap-bootstrap: simplify snap-bootstrap seed reading with new seed.ReadSystemEssential <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9283>
[16:14] <zyga-kaveri> hmm
[16:14] <zyga-kaveri> I ran my tests in GCE and my kernel replacement method does not work
[16:14] <zyga-kaveri> oh well
[16:14]  * zyga-kaveri needs to debug that
[16:16] <ijohnson> pedronis: I realize that mvo already merged 9283, but why do install/recover modes not measure the model anymore ?
[16:16] <pedronis> ijohnson: indeed, given you are off would be great if you could look at https://github.com/snapcore/snapd/pull/9273, https://github.com/snapcore/snapd/pull/9210
[16:16] <mup> PR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[16:16] <mup> PR #9210: daemon: add /v2/systems "reboot" action API <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9210>
[16:16] <pedronis> ijohnson: ?
[16:16] <pedronis> I didn't change that
[16:16] <ijohnson> pedronis: but the test change you did implies that it did ?
[16:16] <pedronis> ?
[16:17] <ijohnson> pedronis: see my comment on 9283
[16:17] <ijohnson> pedronis: i.e. you added expectedMeasureModelCalls and that is 0 for recover and install mode when before that was always 1
[16:17] <ijohnson> unless I'm misreading the test somehow
[16:17] <pedronis> ijohnson: those tests are error case
[16:18] <pedronis> we can't do get a model
[16:18] <pedronis> we can't measure it
[16:18] <pedronis> is just that we fail earlier
[16:18] <pedronis> those counts are more like we tried to measure a model
[16:18] <ijohnson> pedronis: ah I see now that we fail earlier
[16:19] <ijohnson> ok, nvm me then
[16:19] <ijohnson> pedronis: but also yes I will review those 2 pr's now then
[16:24] <pedronis> ijohnson: to be clear the reason I didn't check the error was not speed, the reason is more tha for the reader is confusing either way. But now that I think about it, snap-bootstrap was probably the only place where we opened and kept a seed and use it through more than one operation flow
[16:25] <pedronis> so in theory we could turn the only possible Model error into a panic
[16:26] <ijohnson> pedronis: that would be fine with me too
[16:27] <ijohnson> I didn't figure it was for speed, I figured it was more for simplicity of the code
[16:27] <ijohnson> mmm mvo already left
[16:28] <pedronis> ijohnson: he said he will be back later because 2.46.1
[16:28] <ijohnson> right, I will just msg him on mm about a thing he pinged me about before I started
[16:30] <pedronis> ijohnson: yea, we have alrady code like what I did in seed: 			// Model always succeed after LoadAssertions
[16:30] <pedronis> 			mod, _ := seed.Model()
[16:30] <ijohnson> mmm I guess it's fine, just feels a bit weird to ignore errors due to assumptions about implementations of seed
[16:33] <pedronis> as I said, I think at this point, we can turn them into panics
[16:33] <ijohnson> panic is fine with me
[16:34] <pedronis> all the code we have left does,  LoadAssertion, check error, immediately after Model
[16:36] <ijohnson> cachio: I reviewed 9284, please take a look at https://github.com/snapcore/snapd/pull/9284#discussion_r483733217
[16:36] <mup> PR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[17:08] <pedronis> ijohnson: https://github.com/snapcore/snapd/pull/9285 (but less urgent than anything else really)
[17:08] <mup> PR #9285: many: seed.Model panics now if called before LoadAssertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/9285>
[17:08] <ijohnson> pedronis: ok thanks
[17:09] <mup> PR snapd#9285 opened: many: seed.Model panics now if called before LoadAssertions <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9285>
[17:30] <cachio> ijohnson, ack, I was added for a specific situation but it is better to leave that I'll make that for all the nested suites, does it make sense to you?
[17:31] <ijohnson> cachio: imho I think it's best for the nested tests to install snapd from spread always
[17:32] <cachio> ijohnson, nice, in fact we needed that few times
[17:32] <cachio> I just removed because there was a TODO
[17:42] <cachio>  ijohnson fixed that
[17:42] <cachio> thanks for the review
[17:42] <ijohnson> yeah I think the more expected thing is to have snapd from spread on the host
[18:09]  * zyga-kaveri finished pushing patches and is tired
[18:09] <zyga-kaveri> I'll EOD
[18:09] <zyga-kaveri> more catch-up tomorrow
[18:09] <zyga-kaveri> enjoy your long weekend ijohnson and cachio
[18:09] <ijohnson> thanks zyga-kaveri see you on tuesday
[18:11] <cachio> zyga-kaveri, thanks but long weekend for me
[18:11] <cachio> it is for cmatsuoka
[18:11] <zyga-kaveri> ooh
[18:11] <cachio> zyga-kaveri, enjoy your weekend
[18:11] <zyga-kaveri> sorry I thought you have the same holidays
[18:11] <zyga-kaveri> or was it independence day
[18:12] <zyga-kaveri> and I misremembered?
[18:12] <cmatsuoka> zyga-kaveri: it's the brazilian independence day
[18:12] <zyga-kaveri> ahh
[18:12] <zyga-kaveri> well
[18:12] <zyga-kaveri> cmatsuoka: enjoy *your* long weekend then :)
[18:13] <cmatsuoka> zyga-kaveri: thanks! (but I'll probably work a bit on reseal)
[18:13] <zyga-kaveri> yeah I understand
[18:13]  * zyga-kaveri cannot wait for core22
[18:13] <cmatsuoka> haha
[18:23] <ijohnson> we will have all the things - 1 for core22, we can't have all the things for core22, then there would be no point in a core24
[18:24]  * ijohnson is actually now legitimately frightened about a core24
[18:24] <ijohnson> it just sounds eery
[18:24] <cmatsuoka> ijohnson: just imagine all the crazy features we can put there
[18:25] <ijohnson> i kno rite
[18:50] <ijohnson> cachio: can you also create the dir /tmp/work-dir/assets too in your PR 9284 ?
[18:50] <mup> PR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[18:50] <ijohnson> I see this failure:
[18:50] <ijohnson> https://pastebin.ubuntu.com/p/qJr9jFbBYD/
[18:52] <cachio> ijohnson, it is being done
[18:52] <cachio> I added the nested_prepare_env for all the nested suites in the prepare-each
[18:52] <ijohnson> cachio: also I see this after merging your PR: https://pastebin.ubuntu.com/p/zPvMB9MRtp/
[18:52] <ijohnson> cachio: ah ok great
[18:53] <cachio> ijohnson, this error was caused because of a last minute chagne in the 9098
[18:53] <ijohnson> ah ok
[18:56] <cachio> ijohnson, I was calling the function nested_prepare_env as last step of the nested_cleanup_env
[18:56] <cachio> to make sure the end was not destroyed
[18:56] <cachio> now it should work properly with the chagne introduced in 9284
[19:51]  * cachio afk
[20:14] <mup> PR snapd#9286 opened: Create ruby.yml <Created by yanz-androidify> <https://github.com/snapcore/snapd/pull/9286>
[20:29] <mup> PR snapcraft#3277 opened: pluginhandler: support using patchelf on strict snaps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3277>
[21:18] <pedronis> ijohnson: I tried to answer your question: https://github.com/snapcore/snapd/pull/9273/files#r483847492
[21:18] <mup> PR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[21:19] <pedronis> there's a bit of repetion in assets.go maybe at some point we can see if there are common helpers to extract
[21:26] <ijohnson> thanks
[21:55] <mup> PR snapd#9031 closed: interfaces/bluez: let slot access audio streams <Needs security review> <⛔ Blocked> <Created by alfonsosanchezbeato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9031>
[22:25] <mup> PR snapd#9287 opened: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>
[22:39] <mup> PR snapcraft#3268 closed: v2 plugins: add catkin plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3268>
[22:39] <mup> PR snapcraft#3278 opened: cli: client side check for setting default tracks <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3278>
[23:20] <mup> PR snapd#9286 closed: Create ruby.yml <⛔ Blocked> <Created by yanz-androidify> <Closed by pull[bot]> <https://github.com/snapcore/snapd/pull/9286>