mupPR snapd#9278 opened: boot: seal using boot chains from bootloader <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278>00:40
mupPR 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>01:40
mupPR 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>02:27
mupPR 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>03:29
mupPR 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:17
mupPR 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:19
mborzeckimvo: hey06:59
mborzeckipstolowski: heya07:08
mvogood morning mborzecki and pstolowski !07:12
mupPR 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:16
mborzeckilet's see if i've fixed tumbleweed builds07:20
mborzeckirpm macros are a bit pita07:21
mupPR 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:21
* mvo hugs mborzecki 07:22
mvopstolowski: 9245 needs a master merge now, yes? your test refactor got merged to tmaster07:23
pstolowskimvo: yes, thanks, will do07:25
pstolowskire cups issue on 20.10, there are no destinations/printers defined, confirmed with lpstat and lpoptions, seems something changed in 20.10,07:27
pedronisI suppose we could check what is set up in 20.04, and try to clone that config over in the test?07:30
pstolowskipedronis: yep, i'll try to figure that07:31
mborzeckiduh, so %{_libexecdir} in opensuse 15.2 expands to /usr/lib, but in TW it's /usr/libexec07:33
mborzeckizyga-kaveri: around?07:36
mupPR 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:47
mupPR snapd#9279 opened: github: run tests also on push to release branches <Created by mvo5> <https://github.com/snapcore/snapd/pull/9279>07:52
mupPR snapd#9280 opened: packaging/opensuse: do not hardcode AppArmor profile path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9280>07:57
zygagood morning08:31
pstolowskihey zyga !08:34
zygalast night was productive08:35
zygamorning was easy08:35
zygalet's make this day count08:35
jameshSo it looks like the UC20 seeding process doesn't like me having multiple base snaps in my image08:38
zygajamesh I think someone asked about this08:42
zygayou can have any number of bases08:42
zygabut you must have one boot base08:42
zygaIIRC the yaml for 20 is different08:42
zygaalthough having never done this, I really don't know the details08:42
jameshzyga: 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 out08:43
jameshi.e. there's two bases, a kernel, and a snapd, which doesn't equal len([base, kernel, snapd])08:44
jameshzyga: this is my model definition: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model08:45
zygamborzecki ^08:48
zygais this expected?08:48
jameshperhaps I could lie and pretend the second base is an app08:48
jameshbut that might cause a later failure08:48
mborzeckizyga: can you take a look at https://github.com/snapcore/snapd/pull/9280 ?08:48
mupPR #9280: packaging/opensuse: do not hardcode AppArmor profile path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9280>08:48
zygaI hate that stuff08:49
mborzeckijamesh: got full log?08:49
mborzeckii'm guessing it's confused about two bases, and probbaly expects core20 base to be used08:50
jameshmborzecki: I was booting this in a VM and it is on the VGA console rather than serial08:51
mborzeckijamesh: screenshot works too :P08:51
mborzeckihm maybe i can try and replicate it here08:51
zygamborzecki thank you08:52
zygamborzecki +108:52
jameshmborzecki: https://imgur.com/a/EK5lKD808:53
pstolowskifix for cups test coming08:53
jameshmborzecki: this is built from the following model: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/main/gdm-spike-model.model08:53
mborzeckijamesh: which base do you want to boot with? -gdm?08:57
jameshmborzecki: core20-gdm (the one I list as the base at the top level)08:57
mborzeckican you drop the type: [base|app] for all other snaps?08:58
jameshmborzecki: I had a booting image before I added core20 and network-manager08:58
jameshmborzecki: i.e. this one worked: https://github.com/jhenstridge/ubuntu-core-gdm-spike/blob/a08a02d949bd616558827b695ad18ec6bec09110/gdm-spike-model.model08:59
mborzeckijamesh: 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 confused08:59
jameshthat was my guess too08:59
jameshinstead it should be checking whether there is at least one of each essential type09:00
pstolowskiseb128: 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
mupPR #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:00
mborzeckijamesh: 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 needed09:01
zygapstolowski looking09:01
jameshmborzecki: would anything be likely to break if I lied and pretended core20 was an app snap here?09:02
mupPR 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
jameshI suppose I can just give it a go09:02
mborzeckijamesh: 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 wrong09:03
jameshmborzecki: 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 image09:05
seb128pstolowski, hey, I don't know, best to check with tkamppeter on #ubuntu-desktop09:13
pstolowskiseb128: sure, ok, thanks09:13
pstolowskimvo, pedronis: updated #924509:17
mupPR #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:17
pedronisjamesh: we fixed something related to that but it might not be in stable09:18
pedronisjamesh: https://bugs.launchpad.net/snapd/+bug/188397309:18
mupBug #1883973: cannot boot uc20 model with multiple base snaps <snapd:Fix Committed by pedronis> <https://launchpad.net/bugs/1883973>09:18
mvoijohnson: 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 this09:22
jameshpedronis: that bug certainly sounds like the same issue, yeah.09:25
pedronispstolowski: thanks for #9281,  commented there09:32
mupPR #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:32
* Eighth_Doctor waves09:42
Eighth_Doctorzyga: if it makes you feel any better, I'm eliminating a difference across distros :)09:42
Eighth_Doctorby virtue of patience and persistence :)09:43
Eighth_DoctorDebian 11 / Ubuntu 20.04, openSUSE Tumbleweed, and Fedora/RHEL now all permit the exact same paths for binaries of all kinds09:44
Eighth_Doctorthat is, /usr/bin, /usr/sbin, and /usr/libexec09:44
jameshThe Debian aversion to libexec always seemed a weird hill to make a stand on09:45
Eighth_Doctorwith the upgrade to FHS 3.0, they finally stopped doing that09:46
jameshThe 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 there09:48
Eighth_Doctormy 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_DoctorAT&T Unix lacked libexec, BSD added it because it was needed for some binaries09:49
Eighth_Doctorand at the time, Linux distributions were moving from BSD-style stuff to SysV-style stuff (except Slackware, which never changed)09:50
jameshsure, but cluttering directories searched by the dynamic linker with non-libraries never seemed like a better choice09:50
Eighth_Doctorit wasn't, which is why Red Hat Linux never dropped it09:50
Eighth_DoctorSuSE Linux had it added and then removed in ~200009:50
Eighth_DoctorDebian removed it in 200309:51
Eighth_Doctorbut distributions lacking the libexec path had to find other ways to handle this09:51
Eighth_Doctorand that was... incoherent and inconsistent09:52
Eighth_Doctorjamesh: 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_DoctorFHS 3.0 was the point where they decided that all the current practices that weren't going to go away were finally documented09:53
jameshI was mainly working upstream during that time frame, so just had to deal with distro bug reports with weird paths09:58
Eighth_Doctorwell, at least now hopefully this is one less thing to deal with10:01
Eighth_Doctorthe only difference left now is /usr/lib/<triplet> in Debian verses /usr/lib(32|64) everywhere else10:02
mvozyga 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%3D10:02
mvozyga it's  google:ubuntu-16.04-64:tests/regression/lp-181396310:02
mvozyga 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=010:02
mvozyga I wonder if the logger change to look at /proc/cmdline causes this maybe?10:03
mvozyga but then I wonder why it's starts happening now :(10:03
mvozyga but it's also strange, our default profile has "@{PROC}/cmdline r"10:07
pedronismvo: snap-update-ns gets its own profile though, not sure it contains the default10:19
mborzeckihuh, why does govendor sync fail randomly on TW?10:20
zygamvo hmmm10:24
zygamvo looking now10:24
zygamvo sorry, had to hand over lucy10:24
zygaI feel like Saturday is work catchup for me this week10:25
zygamvo: uri expired10:25
zygamvo is that master or a PR?10:25
mvopedronis: indeed, it seems to be missing there10:25
zygamvo: as samuele pointed out, snap-update-ns has a derived per-snap profile10:25
zygait's in apparmor/templates10:25
mvozyga: master and pr10:25
zygashall I fix it?10:25
mvozyga: I can fix it10:26
mvozyga: it's just adding /proc/cmdline, right?10:26
zygawith @{PROC}10:26
zygaas to why it was missed10:26
mvozyga what is puzzling is that it did not happen when the PR was merged10:26
zygais it possible we hit rate limiting10:26
mvozyga oh, ok10:26
zygaI know we disable it sometimes but perhaps that is buggy10:26
zygawhich OS did it fail on?10:26
mvozyga: 16.0410:27
mvozyga and only with  google:ubuntu-16.04-64:tests/regression/lp-1813963  it seems10:28
* zyga looks at that test10:28
zyga    # Nothing should have been denied yet.10:29
zyga    test "$(dmesg | grep -c DENIED)" -eq 010:29
zygaI think none of or regular tests care about apparmor denials10:29
mvozyga ok, I think I will add something then to spread too (something trivial)10:31
mvozyga thanks for your help!10:31
zygagood luck10:31
zygaEighth_Doctor: unless you take that all the way to Debian it's just a transition that changes little in the grand scheme of things10:34
zygaEighth_Doctor wait, wat, debian is using libexec as well?10:35
zygaEighth_Doctor: the debian multiarch triplet is superior to libXY things so I'd love to see that spread as well10:36
zygaanyway, back to coding10:36
Eighth_Doctorzyga: Debian is adopting it too10:37
Eighth_Doctorit even leaked into Ubuntu 20.04 ;)10:37
Eighth_Doctorlook at the gnome-terminal package file list sometime ;)10:37
Eighth_Doctorzyga: some work in rpm is required first before I could consider the multiarch triplet thing10:38
Eighth_Doctorwe're discussing improving the handling of autodeps to include more architecture info10:38
zygathat's really nice10:41
Eighth_Doctorzyga: 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/103810:43
mupPR 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:43
mvozyga it's up now10:50
zyga-kaverimvo: where?10:51
mvozyga-kaveri: pr 928210:51
mupPR #9282: interfaces: allow snap-update-ns to read /proc/cmdline <Created by mvo5> <https://github.com/snapcore/snapd/pull/9282>10:51
mvozyga-kaveri: pretty trivial10:51
zyga-kaveriah, thank you10:52
mupPR snapd#9282 opened: interfaces: allow snap-update-ns to read /proc/cmdline <Created by mvo5> <https://github.com/snapcore/snapd/pull/9282>10:52
zyga-kaverimvo: reviewed10:53
mvozyga-kaveri: that was quick :)10:53
mvozyga-kaveri: I will cherry pick to 2.46, yes10:53
pstolowski#9245 needs 2nd review10:56
mupPR #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:56
mvopstolowski: looking10:57
mupPR 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:57
pstolowskimvo: ta!10:58
mvopstolowski: thank *you*10:59
zyga-kaveripstolowski: https://github.com/snapcore/snapd/pull/9245#pullrequestreview-48255772011:01
mupPR #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
pstolowskizyga-kaveri: thanks, will tweak it in one of the other PRs11:01
zyga-kaveriit's not a biggie :)11:02
zyga-kaverithank you11:02
mupPR 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:02
pedronismborzecki: I reviewed #9273, some questions and remarks there, it doesn't look completely right atm11:22
mupPR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>11:22
mborzeckipedronis: thanks, let me see11:22
* zyga-kaveri small break11:54
mborzeck2pfff no power12:12
=== mborzeck2 is now known as mborzcki
zyga-kaverimborzecki: fun12:38
mborzeckizyga-kaveri: hm?12:39
mborzeckihm opensuse TW should be good now12:41
mborzeckiand spread is weird, a suite prepare fails and it tore down the setup of other suites too apparently12:41
mborzeckimaybe there's something special about passing suites in the command line12:42
mupPR 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:43
pedroniscmatsuoka: ^ that should hopefully help dealing with seeds in boot12:44
cmatsuokapedronis: thanks, will check in a minute12:44
pedronismborzecki: did my comments in 9273 make some sense?12:45
pstolowskizyga: i included the tweak you suggested in https://github.com/snapcore/snapd/pull/922012:56
mupPR #9220: o/snapstate: disk space check with single snap install <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9220>12:56
mborzeckipedronis: yup, i'm updating the PR12:58
zygapstolowski thanks12:58
mborzeckidamn, and it's raining again12:59
mborzeckii don't see how the forecast of 25C tomorrow makes any sense12:59
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:27
ogra_(i'd liek to get rid of the "initialize device" errors on custom images)13:29
mborzeckicachio: https://github.com/snapcore/snapd/pull/9280 <- opensuse tumbleweed fixes13:35
mupPR #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:35
ijohnsonpedronis sorry give me a couple minutes need to take care of something13:42
ijohnsonpedronis rejoining now13:45
cachioijohnson, #9098 squash merged13:54
mupPR #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
ijohnsonvery nice thanks cachio13:54
cachioijohnson, now we can merge master13:54
ijohnsoncachio: yes I will rebase my PR which I didn't open yesterday on these changes13:54
ijohnsonthanks for all the work there13:54
cachioijohnson, yaw13:55
cachionow I neeed to create a new one with small fixes13:55
mupPR 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>13:58
jdstrandmvo: 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 assessment14:02
mvojdstrand: nice, thank you!14:03
jdstrandmvo: I've talked to amurray and emitorino about this and they are aware14:03
jdstrandemitorino: 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 assessment14:04
jdstrandmvo: for more involved PRs, we'll have to have a conversation, but do feel like you can reach out to have the conversation :)14:04
mborzeckipedronis: i've updated #927314:08
mupPR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>14:08
jdstrandmvo: 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:16
pedronisijohnson: 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
mupPR #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
mvojdstrand: I asked in the desktop team channel if they need it urgently. it seems they are fine with it being in 2.4714:23
mvojdstrand: we will do 2.47 very soon as it contains all the uc20 bits14:24
ijohnsonpedronis ah sorry missed that I will address it later sorry this morning is very busy for me14:25
pedronisit's ok14:26
pedronisjust bit confused14:26
jdstrandmvo: wfm, thanks14:34
=== pedronis_ is now known as pedronis
mupPR 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:03
ijohnsonpedronis: 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
pedronisijohnson: the check15:04
ijohnsoni.e. do you want `func GadgetCloudConf(dir string) string` or did you want `func HasGadgetCloudConf(dir string) bool`15:04
pedronisjust the join is a bit silly I suppose15:04
ijohnsonok, is `HasGadgetCloudConf` a reasonable name15:04
ijohnsonack, thanks will push something up in a few minutes15:05
cmatsuokapedronis: re SystemInstallObserver in install.go, install.go is !nosecboot, is it ok for you to define it also in install_dummy.go?15:06
pedronisah, I forgot about that15:06
cmatsuoka(I had placed it initially in install.go before I noticed that)15:07
pedroniscmatsuoka: I think maybe it fine where it is then but s/options.go/types.go/params.go/15:07
cmatsuokapedronis: will rename to params, thanks15:07
* zyga has working integration tests now :-)15:14
zyganow to add more tests using this pattern15:15
zygabut first tiny brek15:15
ijohnsonpedronis: ok now I addressed all your comments in 923715:15
pedronisijohnson: thx, I don't know if I get to look at it again today15:21
mvopedronis: fun, I just looked at 20.10 failure logs and it's not longer degraded, the failure I see there is slightly different15:21
ijohnsonno problem, I'm off on Monday anyways so not a big deal15:21
* cmatsuoka needs to get groceries and have lunch, bbl15:27
cachioijohnson, I just pushed #9284 with some fixes for nested15:43
mupPR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>15:43
mupPR snapd#9284 opened: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>15:43
cachioijohnson, if you could take a quick look should be nice15:44
ijohnsoncachio: sure looking now15:44
cachioit is pretty simple15:44
cachioijohnson, thanks15:45
zyga-kaveriI think spread has a bug in reboot handling15:56
zyga-kaveriI have a qemu vm that reboots15:57
zyga-kaverirunning it with gui shows me that the reboot completes and the machine is fully operational15:57
zyga-kaveribut spread sometimes just sits there waiting and waiting15:57
zyga-kaveriit's maybe one of 4-5 attempts15:57
zyga-kaverion a relatively slow dual core system15:57
cachiozyga-kaveri, at some point I fixed that15:59
cachiothere is a PR for that15:59
cachionerver merged15:59
zyga-kaverioh super15:59
zyga-kaveriwhich PR is that?15:59
cachiozyga-kaveri, https://github.com/snapcore/spread/pull/7016:00
mupPR spread#70: Close ssh connection when reboot is stuck <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>16:00
cachiois it the same that you see?16:00
zyga-kaveriI didn't debug it yet, all I see is the rebooting message and nothing more16:01
zyga-kaverican you close the ticker, we could get this reviewed and merged16:01
cachiozyga-kaveri, https://paste.ubuntu.com/p/kzJhnP7BHj/16:02
cachiothis is the error in spread16:02
cachiozyga-kaveri, yes I can fix that16:02
zyga-kaverilocally I just see16:02
zyga-kaveri2020-09-04 17:51:41 Rebooting on qemu:ubuntu-20.10-64 (qemu:ubuntu-20.10-64) as requested...16:02
zyga-kaveri9 minutes16:03
zyga-kaverithis is not snapd so timeouts are different16:03
cachiozyga-kaveri, could you try to build spread and test this PR?16:03
cachioperhaps it is not enough for the problem you see and something else is needed16:03
zyga-kavericachio: yeah, I can try16:03
cachiozyga-kaveri, thanks16:03
zyga-kaveriI'm hungry though, skipped PT, skipped lunch16:04
zyga-kaveriI'll take a break and test it afterwards16:04
cachiozyga-kaveri, nice, no hurry16:05
cachioit is friday :)16:05
mvocachio: snapd 2.46.1 should be building now, snapd snap should be there in ~1h, core will take a bit longer16:06
cachiomvo, nice, thnanks16:06
* mvo -> hockey16:08
mupPR 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:09
zyga-kaveriI ran my tests in GCE and my kernel replacement method does not work16:14
zyga-kaverioh well16:14
* zyga-kaveri needs to debug that16:14
ijohnsonpedronis: I realize that mvo already merged 9283, but why do install/recover modes not measure the model anymore ?16:16
pedronisijohnson: 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/921016:16
mupPR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>16:16
mupPR #9210: daemon: add /v2/systems "reboot" action API <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9210>16:16
pedronisijohnson: ?16:16
pedronisI didn't change that16:16
ijohnsonpedronis: but the test change you did implies that it did ?16:16
ijohnsonpedronis: see my comment on 928316:17
ijohnsonpedronis: i.e. you added expectedMeasureModelCalls and that is 0 for recover and install mode when before that was always 116:17
ijohnsonunless I'm misreading the test somehow16:17
pedronisijohnson: those tests are error case16:17
pedroniswe can't do get a model16:18
pedroniswe can't measure it16:18
pedronisis just that we fail earlier16:18
pedronisthose counts are more like we tried to measure a model16:18
ijohnsonpedronis: ah I see now that we fail earlier16:18
ijohnsonok, nvm me then16:19
ijohnsonpedronis: but also yes I will review those 2 pr's now then16:19
pedronisijohnson: 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 flow16:24
pedronisso in theory we could turn the only possible Model error into a panic16:25
ijohnsonpedronis: that would be fine with me too16:26
ijohnsonI didn't figure it was for speed, I figured it was more for simplicity of the code16:27
ijohnsonmmm mvo already left16:27
pedronisijohnson: he said he will be back later because 2.46.116:28
ijohnsonright, I will just msg him on mm about a thing he pinged me about before I started16:28
pedronisijohnson: yea, we have alrady code like what I did in seed: // Model always succeed after LoadAssertions16:30
pedronismod, _ := seed.Model()16:30
ijohnsonmmm I guess it's fine, just feels a bit weird to ignore errors due to assumptions about implementations of seed16:30
pedronisas I said, I think at this point, we can turn them into panics16:33
ijohnsonpanic is fine with me16:33
pedronisall the code we have left does,  LoadAssertion, check error, immediately after Model16:34
ijohnsoncachio: I reviewed 9284, please take a look at https://github.com/snapcore/snapd/pull/9284#discussion_r48373321716:36
mupPR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>16:36
pedronisijohnson: https://github.com/snapcore/snapd/pull/9285 (but less urgent than anything else really)17:08
mupPR #9285: many: seed.Model panics now if called before LoadAssertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/9285>17:08
ijohnsonpedronis: ok thanks17:08
mupPR snapd#9285 opened: many: seed.Model panics now if called before LoadAssertions <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9285>17:09
cachioijohnson, 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:30
ijohnsoncachio: imho I think it's best for the nested tests to install snapd from spread always17:31
cachioijohnson, nice, in fact we needed that few times17:32
cachioI just removed because there was a TODO17:32
cachio ijohnson fixed that17:42
cachiothanks for the review17:42
ijohnsonyeah I think the more expected thing is to have snapd from spread on the host17:42
* zyga-kaveri finished pushing patches and is tired18:09
zyga-kaveriI'll EOD18:09
zyga-kaverimore catch-up tomorrow18:09
zyga-kaverienjoy your long weekend ijohnson and cachio18:09
ijohnsonthanks zyga-kaveri see you on tuesday18:09
cachiozyga-kaveri, thanks but long weekend for me18:11
cachioit is for cmatsuoka18:11
cachiozyga-kaveri, enjoy your weekend18:11
zyga-kaverisorry I thought you have the same holidays18:11
zyga-kaverior was it independence day18:11
zyga-kaveriand I misremembered?18:12
cmatsuokazyga-kaveri: it's the brazilian independence day18:12
zyga-kavericmatsuoka: enjoy *your* long weekend then :)18:12
cmatsuokazyga-kaveri: thanks! (but I'll probably work a bit on reseal)18:13
zyga-kaveriyeah I understand18:13
* zyga-kaveri cannot wait for core2218:13
ijohnsonwe 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 core2418:23
* ijohnson is actually now legitimately frightened about a core2418:24
ijohnsonit just sounds eery18:24
cmatsuokaijohnson: just imagine all the crazy features we can put there18:24
ijohnsoni kno rite18:25
ijohnsoncachio: can you also create the dir /tmp/work-dir/assets too in your PR 9284 ?18:50
mupPR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>18:50
ijohnsonI see this failure:18:50
cachioijohnson, it is being done18:52
cachioI added the nested_prepare_env for all the nested suites in the prepare-each18:52
ijohnsoncachio: also I see this after merging your PR: https://pastebin.ubuntu.com/p/zPvMB9MRtp/18:52
ijohnsoncachio: ah ok great18:52
cachioijohnson, this error was caused because of a last minute chagne in the 909818:53
ijohnsonah ok18:53
cachioijohnson, I was calling the function nested_prepare_env as last step of the nested_cleanup_env18:56
cachioto make sure the end was not destroyed18:56
cachionow it should work properly with the chagne introduced in 928418:56
* cachio afk19:51
mupPR snapd#9286 opened: Create ruby.yml <Created by yanz-androidify> <https://github.com/snapcore/snapd/pull/9286>20:14
mupPR snapcraft#3277 opened: pluginhandler: support using patchelf on strict snaps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3277>20:29
pedronisijohnson: I tried to answer your question: https://github.com/snapcore/snapd/pull/9273/files#r48384749221:18
mupPR #9273: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>21:18
pedronisthere's a bit of repetion in assets.go maybe at some point we can see if there are common helpers to extract21:19
mupPR 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>21:55
mupPR snapd#9287 opened: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>22:25
mupPR snapcraft#3268 closed: v2 plugins: add catkin plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3268>22:39
mupPR snapcraft#3278 opened: cli: client side check for setting default tracks <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3278>22:39
mupPR snapd#9286 closed: Create ruby.yml <⛔ Blocked> <Created by yanz-androidify> <Closed by pull[bot]> <https://github.com/snapcore/snapd/pull/9286>23:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!