/srv/irclogs.ubuntu.com/2020/04/23/#snappy.txt

=== urluck_ is now known as urluck
zygao/05:11
zygagood morning05:39
* zyga tracks a small anomaly05:39
zygain other news everything is hard05:40
mborzeckimorning05:44
zygahey05:44
zygasomehow 16.04 can do things 18.04 cannot05:45
zygaI think I just learned something new05:57
zygasession startup, you'd think stuff would wait06:00
zygamborzecki: how are you feeling today?06:04
mborzeckizyga: meh, tired, i should go for a bike ride or sth06:04
zygayeah06:06
zygaI feel the same06:06
zygabut also this damn allergy06:06
zygaI need to go to a pharmacy today06:06
zygaheh06:09
zygaI think I start to understand06:10
mupPR snapd#8546 closed: seccomp: add get_tls, io_pg* and *time64/*64 variants for existing syscalls <⚠ Critical> <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8546>06:16
zygaSo we will have another point release06:17
zygaok, breakfast and one more patch06:40
zygaand it is ready06:40
mupPR snapd#8496 closed: interfaces/apparmor: use differently templated policy for non-core bases <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8496>06:43
mborzeckimvo: hey, can you take a look at https://github.com/snapcore/snapd/pull/8543 ?07:02
mupPR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8543>07:02
mvomborzecki: sure07:02
pstolowskimorning07:02
mvopstolowski: good morning07:02
mvohappy release day07:02
pstolowskiha, likewise :)07:03
pedronismborzecki: mvo: hi, #8513 needs another review07:06
mupPR #8513: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8513>07:06
mborzeckipedronis: i'll take a look07:06
mborzeckilooks like uboot.env is still a mess07:07
pedronismborzecki: in which sense?07:07
mborzeckipedronis: looking at ijohnson's standup notes, he wrotne we cannot have /uboot.env (?)07:08
pedronismborzecki: yes, it's complicated, but we have a plan07:08
mvopedronis: yeah, saw your push there, thanks for this07:09
mborzeckipedronis: i see, /uboot/ubuntu/uboot.sel, should be rather simple, i can work on a pr07:11
pedronismborzecki: mvo: I think we should try to finish the tpm stuff07:11
mvo+107:11
mborzeckiok07:12
pedronismborzecki: I think Ian's might have work in progress on the uboot stuff07:12
pedronisnot sure07:12
pedronismborzecki: mvo: now secboot should have all the helpers we need07:12
pedronismborzecki: #8464 is still not working, right?07:13
mupPR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>07:13
mborzeckipedronis: yeah, i see some wip commits with /uboot/ubuntu in one of the new branches in ian's repo07:14
mupPR snapd#8543 closed: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>07:16
mborzeckiyay07:16
mborzeckibtw. have you guys noticed that there's like 2-3 emails when tests finish per pr now?07:17
pedronisyes, we something fails07:18
pedroniss/we/if/07:18
pedronismborzecki: actually, you didn't push master to #8464 again yet? it has conflicts atm btw07:19
mupPR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>07:19
mborzeckipedronis: heh, right, i merged and fixed conflicts yesterday but forgot to push07:19
mborzeckipedronis: anyways, ther's new conflicts to fix today07:19
pedronisthere might be more conflicts now07:20
pedronismvo: have you played with calling bootstrap.Run directly ? we need to decide what to do with #853107:30
mupPR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>07:30
mvopedronis: I did, I can create a proper pr, the most simple version that just moved bootstrap.run into overlord and leave strange imports is very small07:35
pedronismvo: we have the spread tests though07:36
mvopedronis: right, we could build the needed command for testing in the spread test07:36
pedronisyea, that sounds reasonable07:37
mvoI can poke at this now, I just did half a review of 8513 but this PR seems equally important07:37
pedronismvo: please finish 851307:38
pedronisit's kind of hard to progress on that side before it is in07:38
pedronisbecause of code placement questions07:38
mvopedronis: https://paste.ubuntu.com/p/yr8zqHPyqK/ is the absolute minimium without tests to call run directly07:40
mvopedronis: sure, will do the 8513 now07:40
pedronismvo: that looks reasonable, we'll need a way to mock it07:43
pedronisinstead of the command as we do now07:43
mvopedronis: yeah, that should be easy as it's pratcially the same as the commdnline07:43
mvopedronis: but yeah, will work on it right after 8513 - should I try to move the imports too ?07:43
pedronismvo: no, not right now, we have both boostrap and partition to deal with, and I'm not sure what to do exactly atm07:45
mvook07:46
zygais master green now (is it worth merging master to unstuck PRs)?07:49
pedroniszyga: i'ts better but still lots of weird failure, I just got failures on amazon linux, not sure about what08:01
mborzeckican we trim the standup doc? it's 148p long atm08:04
ijohnsonhey folks08:09
ijohnsonmborzecki: I see you found my wip branch for "text" ubootenv stuff, are you working on that now? I think it was mostly there except for tests and some changes to bootloader.Find sprinkled around08:11
mborzeckiijohnson: no, looking at some PRs atm08:12
ijohnsonmborzecki: ok I will finish that up now then08:12
mvoijohnson: good morning! isn't it like terrible early?08:16
ijohnsongood morning mvo08:17
ijohnsonit is fairly early yes, but I didn't finish everything yesterday so I wanted to wrap it up now08:17
ijohnsonit's a bit quieter in the house now :-)08:17
* mvo hugs ijohnson 08:18
mvoijohnson: woah!08:18
mvoijohnson: thanks so much!08:18
mborzeckipedronis: i suppose next step is adding MeasureSnapModelToTPM for run mode?08:20
mborzeckiand https://github.com/snapcore/snapd/pull/8531 ?08:20
mupPR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>08:20
pedronismborzecki: yes, but we need the lock keys one landed to have a place for the first thing08:22
pedronismborzecki: also we need to write model to modeenv still, right?08:22
mborzeckipedronis: this landed already08:22
mborzeckipedronis:  i mean model to modeenv08:22
pedronismborzecki: really ?08:23
pedronisI'm confused08:23
mborzeckipedronis: hm both #8542 #8543 landed08:24
mupPR #8542: boot: store model model and grade information in modeenv <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8542>08:24
mupPR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>08:24
mborzeckii think we should have everything we need now08:24
mborzeckizyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/8520/checks?check_run_id=611343459 wth happened there?08:38
mupPR snapd#8513 closed: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8513>08:38
mupPR #8520: data: fix shellcheck warnings in snapd.sh.in <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>08:38
zygasure, looking08:39
zygamborzecki: I think jamesh knows this issue08:39
zygamborzecki: the check is wrong, it assumes a specific history08:39
mborzeckiwhy isn't gh actions merging the branch to master or master to the branch?08:39
zygajamesh: ^ can you explain what's the problem with the CLA check08:39
zygathe action checks out the code as is08:41
zygathe cla check workflow is different as it gets more history IIRC08:41
jameshzyga, mborzecki: I think the problem is that the revision under test is a merge that allows fast forwards.  So the assumption that it has two parents is wrong08:41
zygamborzecki: we could code an action that merges first08:41
jameshin the fast forward case, we can't determine the base revision from the head revision08:42
mborzeckijamesh: i have this pr open: https://github.com/snapcore/snapd/pull/8455 maybe you know the proper way to pass the commit range from github context08:44
mupPR #8455: tests/lib/cla_check: expect explicit commit range <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>08:44
jameshmborzecki: I think we'd need an additional step to fetch the github.base_ref branch into the local repo08:45
zygamborzecki: did MATCH NOT get merged?08:49
mborzeckizyga: hm?08:49
zygajamesh: the checkout action has some options08:49
zygajamesh: perhaps we could use something it already offers08:49
zygamborzecki: the spread MATCH extension you proposed08:49
mborzeckiidk08:49
mborzeckizyga: i think someone else proposed that08:50
zygaah08:50
zygait's NOMATCH08:50
zygathanks !08:50
jameshmborzecki: I've added a comment to your PR with a possible solution08:55
mborzeckijamesh: thanks, let me check that08:57
mborzeckizyga: jamesh: btw the checkout action does something weird, in one PR it's doing: `/usr/bin/git checkout --progress --force refs/remotes/pull/8455/merge`, in one from a contributor it does `/usr/bin/git checkout --progress --force -B master refs/remotes/origin/master`09:00
mborzeckiin the first case it's using that magical ref that github has for 'merged' PR09:01
mborzeckino clue why it's not used in the 2nd case09:01
jameshmborzecki: check the source maybe?09:01
jameshmborzecki: looks like it treats "refs/heads/**" references different to "refs/pull/**" ones: https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L2909:04
mborzeckijamesh: heh, that's what, the magic happens here i'm doing https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L8-L5809:04
mborzeckiah, so we're reading the same code ;)09:04
mborzeckianyways, more important stuff to deal with atm :/09:07
mborzeckihttps://news.ycombinator.com/item?id=22953506 quite a bit of comments from people not so happy about snaps09:13
jameshJust tell them that snapd is written in Lisp.   Then they'll love it09:14
zygaand it's a lisp VM implementing haskel09:15
zygathen they will die with a smile on their faces09:15
jameshsnapd has all of the parentheses09:15
mborzeckiall you parens belong to us09:19
zygaon the upside, all my tests now pass on core and classic09:19
zygaand I found something I don't know the answer for yet09:19
zygajdstrand: app tracking works on 16.04, doesn't work on 18.04 (for the non-root user) - I presume it is the kernel version responsible09:19
zygajdstrand: and that 18.04 kernel has the extra hardening on cgroups that 16.04 lacks09:20
zygamborzecki: I replied to some comments there, it's not that negative actually09:22
zyga(and for context, it works on 16.04+ but in the desktop session)09:25
zygamy comment was not about the desktop session09:25
mupPR snapd#8547 opened: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>09:26
zygajamesh: FYI, core-* doesn't have dbus.socket for users09:34
zygajamesh: perhaps it should?09:34
zygait kind of cripples user sessions09:34
mvopedronis: 8547 is the minimal move we talked about for snap-bootstrap create-paritions, I look at the tests now09:35
mvo(spread tests)09:35
pedronismvo: thanks, afk for a bit, but I will look soon09:38
mupPR snapd#8548 opened: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>09:50
pedronismvo: thank you, did a pass on #8547, some small comments10:01
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>10:01
mupPR snapcraft#3083 opened: repo: revert logic to get deb_arch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>10:06
pedronismborzecki: thanks, some comments on #8548, a comment got messed up there10:07
mupPR #8548: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>10:07
zygamvo: can you merge 8515 please10:09
caribouHello everyone, I'm hitting a rather peculiar situation with snapd initialization on first boot from a Focal Ubuntu Cloud Image.10:13
caribouIf I copy files in /usr/local/bin in the QCOW2 prior to booting, everything works fine. If I untar the same files in the images, snapd is unable to complete its seeding10:13
zygacaribou: can you please share the state of the system when snapd tries to seed10:15
zygabut also this is not the best moment, everyone is swamped with work :/10:15
caribouzyga: very first boot off a slightly modified UCI10:15
jameshzyga: perhaps, but 16.04 classic also doesn't ship those units (it has the session bus managed by a user instance of Upstart)10:15
caribouzyga: I'm aware of that10:15
zygajamesh: indeed10:16
caribouso don't hesite to overlook the request for now10:16
jameshzyga: it would be pretty easy to add to core (install dbus-user-session), but it might not be worth it.10:16
zygajamesh: FYI, I pushed this test10:17
zygahttps://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R110:17
mupPR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>10:17
zygajamesh: this feature is really really really hairy10:17
zyga"what could go wrong" :|10:17
zygaI will run a smoke test to see what happens if it's on by default10:17
caribouzyga: don't bother with my request, I'm working on figuring out a workaround. I'll come back on calmer days :)10:18
zygaok10:18
zygacaribou: sorry and thank you for understanding10:19
jameshzyga: I doubt it would break anything: it would have zero effect on classic systems, and I doubt anyone starts systemd user sessions on Ubuntu Core 16 devices10:19
zygaI agree10:19
mborzeckiis vendor.json showing up as modified for you guys, despite calling govendor sync?10:20
mborzeckiit's like govendor does not know about git reset or sth10:20
zygamborzecki: nope?10:21
zygawhat does it show10:21
jameshzyga: looking at that spread test, is the plan to continue using adding processes to the freezer cgroup on v1 systems?10:22
zygayes because that is done for different reasons (mount raciness)10:22
zygathough we could probably invest in the new mount APIs at some point10:23
zygawhere we could drop that10:23
jameshzyga: so I guess the check would be to look for the substring "/snap." in the empty and name=systemd cgroups, or starting with "/snap."  in freezer cgroup?10:24
zygammm, sorry, got distracted10:25
zygacan you expand on this?10:25
jameshzyga: this is for a quick "is this process a snap?" check10:25
zygaahhh10:25
zygayes10:25
zygaI will send a small patch here to reverse the UUID and security tag bits10:25
zygaas jamie asked for that and I think -- at this point -- this branch can take anything10:26
jameshcould I skip the name=systemd group?10:26
jameshor would it be good to continue including that?10:26
zygaI would not skip it, you should look at freezer (on v1), at name=systemd or at v2 pure cgroup,10:26
zygaeither freezer or pure v2 will always be reliable10:27
jameshright.  That's why I was wondering if I could ignore name=systemd10:27
zygaah, I see10:28
zygaI guess... yeah10:28
zygabut I would check all three10:28
zygauntil phase out of v1 is more better understood10:28
zygain case there's a future window where freezer is gone10:28
zygabut we are still on v110:28
jameshfair enough.10:28
jameshincluding all three is not much of a problem10:29
mupPR snapd#8549 opened: tests: fix a typo in nested.sh helper <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8549>10:37
mupPR snapd#8515 closed: testutil: add NewDBusTestConn <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8515>10:38
zygata!10:38
ijohnsonpedronis: so I have the ubootenv + bootloader changes finished with tests (still need full system test on my pi which I will do in a moment), do you want me to split it up to propose just the "text" format support, then a followup using that format, or shall I just bundle them all together?10:41
zygabrb, neet to stretch back10:44
zygathe full run of refresh-app-awareness enabled by default is progressing and seems to be all good for now (fingers crossed)10:44
zygaI don't anticipate anything specific but I wanted to give it some broader check, even if it's disabled now10:45
pedronisijohnson: how big it the diff?10:46
ijohnson461 lines added, 334 removed10:47
ijohnsonpedronis: ^10:48
pedronisijohnson: seems fine as one PR, unless you think some bits are potential controversial10:49
pedronismborzecki: I have govendor messing with vendor.json too, I didn't dig though10:49
ijohnsonpedronis: mmm my ubootenv changes could be contraversial but hell let's give it a shot I'll open it all in 1 PR, give me a moment10:50
mborzeckipedronis: does git diff show that checksumSHA1 is changed in your system too?10:53
mborzecki(in vendor.json file)10:53
pedronismborzecki: yes10:53
pedronismborzecki: for secboot and x/sys/unix10:54
mborzeckipedronis: yup, same here10:54
mupPR snapd#8550 opened: ubootenv, uboot: support new uc20 style text bootenv <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8550>10:54
ijohnsonpedronis: opened at ^10:54
mborzeckimaybe they changed what goes into the checksum10:54
* ijohnson takes a break for a bit10:54
pedronismborzecki: what does govendor --version prints for you?10:54
mborzeckioh and https://github.com/kardianos/govendor is marked as archived10:54
mborzeckipedronis: 1.0.910:55
pedronissame10:55
pedronisyea, we should move to modules but need to consider when10:55
pedronisit terms of options and go we need to support10:55
pedronisijohnson: can you set milestone 2.45, that's the way we/I track beta (UC20+2.45)10:56
ijohnsonpedronis: sure10:56
pedronisijohnson: thx, its in my queue now, I'll look in a bit, kind of finishing lunch break10:57
pedronis*it's10:57
pedronismvo: good news #8547 passed on core 20 but lots of "random" red11:00
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>11:00
mvopedronis: good and bad11:00
mvopedronis: I will address your point in a wee bit, just pushed the test update11:01
mupPR snapd#8551 opened: snap-bootstrap: remove create-partitions and update tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8551>11:01
pedronismvo: actually is not random11:06
pedronismvo: we have the issues of build on any distro but ubuntu11:06
pedroniswe need the nosecboot tags11:06
pedronisused properly for this11:06
pedronismvo: snap-boostrap was built only on ubuntu, but of course snapd is built everywhere11:07
pedronismvo: do you need help with that?11:10
mvopedronis: uh, yes please11:12
mvopedronis: that will be a bit annyonig and I need to get lunch in a wee bit11:12
pedronismvo: I'll see what I can do there11:12
mborzeckihm maybe we shouldn't build s-b on non ubuntu at all and skip the tests that fail?11:13
mvopedronis: thank you!11:17
pedronismborzecki: we don't build s-b, on non-ubuntu, but mvo has moved a bunch of it inside snapd11:18
pedronisnow11:18
pedronisthat's the issue11:18
pedronisI'll work on it11:18
pedronismvo: not at simple as adding tags, there is something else going on with the build11:46
pedronisblargh, we rm  cmd/snap-bootstrap in some build11:47
mupPR snapd#8548 closed: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>11:48
mupPR snapcraft#3083 closed: repo: revert logic to get deb_arch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>11:57
pedronisijohnson: have you forgotten to add some files?  I see a openNativeFormat that is not defined12:13
pedronisijohnson: I also if possible would try to minize the diff12:14
pedronisof env.go, it's fairly unreadable atm12:14
pedronismvo: I pushed fixes for fedora etc, but debian is a bit messy and needs more work12:20
mvopedronis: ok, I have a look12:31
pedronismvo: I'm actually trying a fix, maybe it works12:31
jdstrandzyga: I tested it on 18.04 and saw that the scope was being created and pids added to it?!?12:32
zygajdstrand: hey!12:32
jdstrandzyga: note, my testing was done via terminal cli commands and not things launched from a desktop file, but that shouldn't matter12:32
zygajdstrand: I just pushed a little bit of an update that adds some more explanation12:32
jdstrandzyga: hey :)12:32
zygajdstrand: how do you like the -failure test?12:32
zygajdstrand: please check the new pair of XXX comments starting at https://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R18412:34
mupPR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>12:34
zygajdstrand: I will take the deb and play with it on VMs representing each desktop and server12:35
zygajdstrand: I also did an experiment to see what would happen to our test suite if this was enabled out of the box, the results were interesting, there were some failures but they are all legitimate change in behavior (we refuse to refresh or install snaps while there are apps running)12:35
jdstrandzyga: I've not looked at it yet. I've got several meetings this morning but will look at this today. I'll try to peek now real quick12:35
zygajdstrand: nothing failed in ways that would not be sensible IMO12:35
zygajdstrand: thank you!12:36
jdstrandzyga: that's cool :)12:36
zygajdstrand: just two theories, I'll explore this interactively now12:36
zygajdstrand: I _hope_ it will be green and I can merge it12:36
zygaI have some follow ups to do12:36
jdstrandzyga: ahhh! you weren't talking about new failures (phew), you were talking about explaining the existing failure12:37
zygayes!12:37
* jdstrand gives a sigh of relief12:37
jdstrandzyga: my whole body tensed up for a second ;)12:38
oSoMoNpedronis, can you hide/delete an offensive bug comment? https://bugs.launchpad.net/snapd/+bug/1776873/comments/3912:38
mupBug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>12:38
pedronisoSoMoN: not afaik,  mvo do you know ^12:39
jdstrandzyga: imho, you could land the PR with the cgroup-tracking-failure as a followup. based on what you said about wanting understand all of this before updating features.go for what is supported/not supported at this time, that could also be in the same followup. I'll leave that up to you12:40
jdstrandbut yes, I'll be looking at this today12:40
pedronismvo: seems I fixed debian too, the fix is ugly but is like the code already there12:41
mvooSoMoN: I'm afaraid not, I guess someone in #launchpad might be able to help12:41
mvopedronis: removing files?12:41
pedronisyes12:41
oSoMoNpedronis, mvo: I asked there first, and c_j_watson suggested that being the project bug supervisor, you have powers to do that yourself12:41
jdstrandzyga: Conversation: 201. Commits: 123. Files changed: 25. Impressive! (7825)12:41
mvopedronis: it's all because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95678312:41
mvooSoMoN: oh, let me try to figure out how then, I never used that feature12:42
oSoMoNmvo, pedronis is the project bug supervisor, so I guess only him can do that12:42
mvooSoMoN: aha, ok - I was wondering, I can't see the right button :)12:42
* zyga runs to check some family hurdle at home12:43
pedronismvo: https://paste.ubuntu.com/p/CPvpyJQnjV/ is the diff, good enough?12:43
mvopedronis: totally12:46
pedronisoSoMoN: I don't see any button either12:46
pedronisI'm maybe looking at the wrong place12:46
mvopedronis: push away12:46
oSoMoNcjwatson, can you advise how to hide a comment for a project bug supervisor? ^12:46
cjwatsonpedronis: There should be a green "Hide" button at the bottom right of the comment12:47
cjwatsonpedronis: Oh, but you need to look at https://bugs.launchpad.net/snapd/+bug/1776873, not on the /comments/39 page12:47
mupBug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>12:47
cjwatson(I'm suggesting that it be hide + explicit warning to user, btw)12:48
pedroniscjwatson: not seeing green buttons either place12:48
cjwatsonUgh12:49
cjwatsonWell, if I hide it could you warn them?12:49
cjwatsonSome kind of code of conduct warning12:49
cjwatsonI've hidden it now12:50
pedroniscjwatson: you mean in the bug comments, or over email? (sorry my brain is very partionated in its capabilities today)12:50
cjwatsonIn the bug comments12:51
pedronisok12:51
cjwatsonThat would be my suggestion anyway, since the bug comment will have been emailed to subscribers12:51
cjwatsonAnd it's good to be public about what the societal expectations are12:51
=== alan_g is now known as alan_g_
jdstrandmvo: thank you for merging the base policy PR :)12:53
jdstrandand thanks to all for the reviews :)12:53
mupPR snapd#8552 opened: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>12:54
jdstrandmvo: I don't know if you are doing another 2.44 point release (thought I saw that in reference to my syscalls PR), but if so, can you also cherry-pick https://github.com/snapcore/snapd/pull/8544 ?12:56
cmatsuokacachio: is the uc20 test working now?12:56
mupPR #8544: interfaces/firewall-control: allow -legacy and -nft for core20 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8544>12:56
mvojdstrand: we don't plan another 2.44 but happy to cherrypick just in case12:56
jdstrandmvo: ack, thanks again :)12:59
cachiocmatsuoka, I am running right now12:59
pedronismvo: I pushed btw13:00
pedronismborzecki: thanks, can you mark that PR UC20 and 2.4513:01
mborzeckiah forgot13:01
abeatosil2100, hey, I was wondering, do you have an example on how the --cloud-init option in u-i can be used? what would it be used for?13:06
mvopedronis: \o/13:06
oSoMoNcjwatson, pedronis: thanks for handling this13:09
* ijohnson pedronis: sorry I forgot to commit those files, added them to the PR now13:12
mupPR # opened: snapd#5822, snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143,13:19
mupsnapd#8247, snapd#8271, snapd#8301, snapd#8317, snapd#8334, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8414, snapd#8424, snapd#8436, snapd#8455, snapd#8464, snapd#8468, snapd#8475, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8528,13:19
mupsnapd#8531, snapd#8532, snapd#8533, snapd#8536, snapd#8537, snapd#8539, snapd#8541, snapd#8547, snapd#8549, snapd#8550, snapd#8551, snapd#855213:19
mupIssue # opened: core20#12, core20#32, core20#34, core20#4813:19
mupPR # opened: core20#11, core20#43, core20#45, core20#46, core20#4913:19
ograah, it isnt only me having issues with github today ...13:20
* ogra hugs mup 13:20
stgraberanyone has an idea of what's going on here? https://discuss.linuxcontainers.org/t/snap-lxd-snap-hooks-configure-snapctl-not-found/752513:26
* ogra shakes fist towards github and goes to take a break .... too many gateway timeouts :(13:30
ograstgraber, smells like a bug in the archlinux package or so ...13:33
mborzeckistgraber: replied in the snapcraft forum topic13:43
ograwho is doing the snap translations ? i noticed in focal i actually get german strings but they often look/feel like google translation ones13:59
ogras/snap/snapd/13:59
zygaogra: anyone can14:09
ograheh ... well i was wondring "who does" :)14:09
zygathere are no curated translations that we merge back to snapd14:09
zygaogra: my point is that nobody curates this14:09
ograright, so it isnt going through rosetta (launchpad) as all our other translations (which get peer reviews)14:10
ograi'm just noticing it shows ...14:10
zygaI think it does14:10
zygabut we never merge them to snapd, verify, alter or anything14:10
zygawe have 0% translations in tree14:11
zygabut actually14:11
zygayou gave me a crazy idea14:11
zygagettext that google-translates each string14:11
zygaMASHIN LERNIN ;)14:11
ograyeah, that will surely improve the quality !14:11
zygaand consistency ;)14:12
ograbut i think it should be a two step thing ... first translate to xhosa ... then to the target language ...14:12
ograthat definitely gets the funnier outcome14:12
pstolowskicachio: can you take a look at https://github.com/snapcore/snapd/pull/8549 ?14:15
cachiopstolowski, sure14:17
zyga##[warning]Failed to download action 'https://api.github.com/repos/actions/checkout/tarball/v2'. Error Response status code does not indicate success: 500 (Internal Server Error).14:19
zygamust be a good day to release14:19
ograyeah GH is stuttery today14:20
ograit is intermittent though ... so restarting the build/test/whatever eventually works14:20
ograi havent seen a 500 yet though ... only lots of 504's14:21
ogra(GW timeout)14:21
* zyga breaks for some time then14:28
zygajdstrand: I have a patch piled that reverses the UUID as you wanted14:28
zygajdstrand: but I will not send it to this branch, it's extra huge already14:28
zygajdstrand: I'll start piling fixes, tests and stuff into a new one14:28
mupPR # closed: core#38, core#107, core#108, core#110, core#11114:30
mupPR # opened: core#38, core#107, core#108, core#110, core#11114:31
pedronismvo: can you work more on #8547 or should cmatsuoka pick it up? either way maybe cmatsuoka can review it14:35
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>14:36
cachioxnox, I see these errors on uc20 https://paste.ubuntu.com/p/SKBqVNyyMN/14:37
cachioxnox, lines 693 and 134014:37
cachioxnox, it could be related to the removal of the snapd-shutdown helper14:37
cachioxnox, could you please take a quick look?14:38
jdstrandzyga: sounds great14:38
mvopedronis: I'm not working on it right now, I think you raised some points that still need adressing. I can probably work on those in a couple of minutes, just de-conflicting 854114:41
mvopedronis: either way is fine, I need to take a 15min break now though14:44
cmatsuokafyi I just built an image from that branch and partitions are created correctly14:45
xnoxcachio:  they are not errors14:45
xnoxcachio:  it's confirmation that finalrd is doing the shutdown correctly14:45
xnoxcachio:  and that the bad snapd shutdown hook is correctly disabled14:45
cmatsuokamvo: and ssh works14:46
cachioxnox, ok, thanks14:47
cachiocmatsuoka, I see this message in the log Please enter the recovery key for disk /dev/disk/by-label/ubuntu-data-enc: (press TAB for no echo)14:53
cmatsuokacachio: you shouldn't see that, let me try to reproduce here...14:54
pedroniscmatsuoka: great, please do a review of the PR itself14:55
ijohnsonpedronis: I added a response to your point on my ubootenv PR re Recovery in InstallBootConfig, it does mean something different but we don't currently have a real use case for that yet so I could just drop that tbh14:56
cmatsuokapedronis: already did a pass, it seems that there are many things to do to have it done properly but functionally it works, will add some notes there14:57
pedronisijohnson: the issue is that afaik we might still have to write a boot.sel or not14:58
pedroniswe don't know, depends what's inside that uboot.env14:58
ijohnsonpedronis: good point, I think that ideally we should still write a boot.sel in this case in addition to the uboot.env from the gadget we install14:58
pedronisijohnson: it might be easier if we don't have a use case to return an error for now, and do something when we have a use case14:59
cachiocmatsuoka, if you run spread -debug google-nested:ubuntu-20.04-64:tests/nested/core20/14:59
cachioyou will see that14:59
ijohnsonpedronis: sure that would be easiest14:59
cachioonce the test fails14:59
ijohnsonpedronis: also I forgot to write this in the PR I think, but we still have a need for the gadget.yaml in the 20 pi snap to install boot.sel onto ubuntu-boot, because otherwise bootloader.Find() in makeBootable20RunMode won't recognize any uboot bootloader on ubuntu-boot15:00
ijohnsonpedronis: I think that's fine, it's pretty similar to what we do for grub too, but it's a bit unexpected / weird given that snapd writes the file for ubuntu-seed, but the gadget has to create the file for ubuntu-boot15:00
ijohnsonpedronis: I wasn't sure how better to handle it though without adding methods to the bootloader interface somehow15:00
pedronisijohnson: yes, I think we are a bit carrying on with legacy logic15:00
ijohnsonyeah15:01
pedronisijohnson: in a sense we should pick a bootloader kind based on seed and apply it to boot15:01
ijohnsonmmm that's a good idea15:01
pedronisbut it might not be the right time to change15:01
pedronisI mean, for sure not in that PR15:01
ijohnsonagreed now is not the right time to do this change15:01
ijohnsonpedronis: do you think it's fine for beta to have the gadget snap install boot.sel onto ubuntu-boot ?15:02
pedronisijohnson: it's ok, but it sound weird at face value, but let's get everything else working first15:03
ijohnsonack15:03
cmatsuokacachio: running it15:08
cachiocmatsuoka, nice15:08
cachioI am having lunch now15:08
cmatsuokacachio: ok, I'll leave comments here if I find something15:08
pedronisijohnson: I understand the cleanliness of introducing nativeenv.go, but I think it would be maybe quicker to do just have env.go with the interface at the top and trying to keep as much of the rest as possible and textenv and do the splitting in a 2nd PR15:10
ijohnsonpedronis: you mean just puteverything in the same file?15:10
pedronisijohnson: no, have two files15:10
pedroniskeep most of env , and Env there15:10
pedronishave the new stuff in textenv.go15:11
ijohnsonah ok15:11
ijohnsonsure I can do that, give me a bit though trying to get this pi test running, needs a bit of hand holding15:11
pedronisijohnson: at the moment the diff of env.go is horrible, and nativenv.go is kind look I need to review code tha is actually old code15:11
ijohnsonI see15:11
pedronisijohnson: in general in this kind of situation is best to either do splitting before (if possible) and/or minimize the diff, and do renames or splits as a separate step15:12
* cachio lunch15:13
mvopedronis: when you have a moment, is https://github.com/snapcore/snapd/pull/8547#discussion_r413680649 what you have in mind?15:18
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>15:18
pedronismvo: I would say no15:20
mvopedronis: ok, it did not feel right so I wanted to ask, what am I missing ?15:20
mvo(and sorry to burden you with this :(15:20
pedronismvo: have you done more in that PR or just started there?15:20
mvopedronis: I updated the other bits, let me push15:21
mvopedronis: the other comments where clear, this one I had a bit of trouble15:21
pedronismvo: something like this https://paste.ubuntu.com/p/xyRmBhjwrX/  (the other change is optional)15:27
mvopedronis: aha, I see. feel free to commit, I have a meeting now, otherwise I will commit when the meeting is done15:30
pedronismvo: pushed15:33
mvopedronis: thanks!15:34
cmatsuokacachio: it failed here in a NOMATCH line in core20/basic/task.yaml (which should now be a not MATCH I believe) but otherwise it seemed to run ok. I'll break for lunch now and bbl15:39
cachiocmatsuoka, in that case it was fixed with a new pc-kernel or gadget15:41
cachiocmatsuoka, thanks15:41
pedroniscmatsuoka: so we should base #8531 on #8547 now, Options should contain directly a Model *asserts.Model ... the command can take a --model <model> and read it15:52
mupPR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>15:52
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>15:52
cmatsuokapedronis: ack, will do that after lunch15:53
pedroniscmatsuoka: thank you15:54
pedroniscmatsuoka: asserts.Decode can be used to make an assertion out of []byte, then you can check the Type() and then cast15:55
mupPR snapd#8541 closed: devicestate: add support for cloud.cfg.d config from the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8541>16:12
pedronisso #8464 failed on core 20 still16:16
mupPR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>16:16
pedroniswe are also having failures because of GH atm16:18
mupPR snapd#8553 opened: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/8553>16:22
mvozyga: did the bit-cacher got restarted? I guess there were some restarts since this was last installed :/16:23
mupPR snapd#8549 closed: tests: fix a typo in nested.sh helper <Simple 😃> <Skip spread> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8549>16:28
zygamvo: yes, I rebooted the system once since installation16:29
zygaWe maybe basic persistency?16:30
mvozyga: maybe, given that the cache fix is on the usptream radar, maybe it's not urgent16:30
* mvo gets dinner - please let me know if there is anything I should merge16:31
* mvo will read backlog16:31
ijohnsonpedronis: I did as requested in 8550 and disabled for now the traditional uboot.env that we don't have clear idea on yet, and I also move nativeenv.go back into env.go16:32
cmatsuokapedronis: thanks, will use that16:40
pedronisijohnson: did we lose import tests for native ? or am I confused by the diff?16:41
ijohnsonuhh I don't think so? I literally just moved all the stuff in nativeenv.go to the bottom of env.go16:42
ijohnsonlet me look again, but to confirm you are looking at the full diff in the github view?16:42
ijohnsonalso seems I forgot to update the prepare-image tests in image_test.go, I'm doing that now too16:42
pedronisijohnson: there was a thing called Import that seems to be gone16:48
pedronistbh it was not used16:48
ijohnsonpedronis: that function is now in textenv.go16:48
ijohnsonsorry maybe I should move that one back to env.go too16:48
pedronisI don't know16:48
ijohnsonthe tests are the only thing that used Import, and I refactored it slightly so that Import is now called ImportTextReader16:48
pedroniswas it a test helper?16:48
ijohnsonyes it's a test helper16:49
ijohnsonwell sorry let me clarify16:49
ijohnsonit was a pure test helper and had a separate implementation from everything else16:49
=== alan_g_ is now known as alan_g
ijohnsonI re-wrote it to share the actual implementation in parseData16:49
pedronisbut it was exported16:49
ijohnsonand now it is used by textEnv16:49
ijohnsonand it is exported in export_test.go now because it's not used directly anywhere other than the tests for ubootenv16:50
pedronisijohnson: as far as I can on master is not a test helper, it's an actual method of envs16:51
pedronisthat nothing uses16:52
ijohnsonyes16:52
ijohnsonthat's my point is that nothing actually used it outside of tests16:52
pedronisit's not used by tests16:52
ijohnsonI don't know why it was originally written as a method on env and not just a test helper16:52
pedronisit's tested by tests16:52
pedronison master16:52
pedronisto me that's two different things16:52
ijohnsonmmm I see your point16:53
ijohnsonI guess I didn't quite grok that, and since nothing actually uses it outside of tests I didn't think it necessary to keep the method around16:53
ijohnsondo you want me to resurrect it as a method in the Env interface?16:53
pedronisI would like to drop, but maybe somebody has a tool around using it16:54
ijohnsonI'd say let's drop and if someone has a dire need for it, it's easy enough to resurrect16:55
pedronisthat's fine, maybe mvo know more, apparently this all code lived somewehre else16:56
pedronisand was ported into snapd at some point16:56
ijohnsonright17:02
ijohnsonpedronis: ok sorry that took longer than expected to fix that image test, I was very confused about it, but all clear now17:12
ijohnsonjdstrand: any idea where to put this bug? I don't know where the ubuntu security tips this is referring to comes from tbh https://bugs.launchpad.net/snappy/+bug/187415617:16
mupBug #1874156: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1874156>17:17
cjwatsonhttps://docs.ubuntu.com/core/en/guides/intro/security17:18
cjwatson(I just web-searched for some of the quoted text)17:18
ijohnsonah thanks cjwatson17:19
cjwatsonThat links to https://bugs.launchpad.net/snappy/+bugs?field.tag=snap-docs for reporting bugs on the docs17:19
cjwatsonWhich is exactly where this bug is :)17:19
ijohnsonhaha so it seems I am exactly in the same place to fix this as the reporter17:19
ijohnsondegville: would you know where issues for https://docs.ubuntu.com/core/en/guides/intro/security should get forwarded to?17:20
ijohnsonI feel like this is now on github somewhere iirc17:20
degvilleijohnson: https://github.com/canonical-web-and-design/ubuntu-core-docs/issues17:22
ijohnsonthanks degville!17:22
ijohnsonmaybe we should also file an issue there for fixing the "report an issue on the docs" button too17:23
degvilleijohnson: good point.17:23
degvilleijohnson: It's me that will try and fix these things though, as they're the core docs I'm trying to update.17:23
jdstrandijohnson: I do and I know where and how to fix it. it is on my todo to fix. feel free to assign to me17:24
ijohnsondegville: right I realized that after looking at the url, I just have never seen the security tips page before so I didn't realize this is part of the core docs :-p17:24
ijohnsoncool, jdstrand I'll assign the LP bug to you17:24
jdstranddegville: I may ask for review/etc, but I'll take care of it. it should be coming from a forum doc that I wrote17:25
om26erWhat are the chances for a snap to be allowed auto-connect permissions for raw-usb interface. It is required by https://e.foundation/ project to flash Android devices and adb-support interface is not sufficient in that case17:26
degvillejdstrand: thank you, that would be a huge help!17:27
pedronisijohnson: if you could move back parseData and iterEnv around where they were original it would be best, you can move them in a follow up17:28
ijohnsonpedronis: ok, give me a minute I can do that right now17:28
pedronisijohnson: let's also drop Import as discussed17:29
ijohnsonpedronis: do you mean drop importTextReader ?17:30
pedronisyes17:30
ijohnsonok17:30
pedronisthe thing that is not quite what it was, and anyway the thing that was wasn't used17:31
pedronis(or so we hope)17:31
pedronisijohnson: and sorry, but my goal is to make reviewing the diff as much as a no-brainer as possible17:33
ijohnsonno problem I understand17:33
zygare17:36
ijohnsonpedronis: done (and I even ran the static-checks this time BEFORE I pushed, how good am I?)17:38
pedronis:)17:38
pedronisijohnson: thanks, looking in a sec17:41
pedronisijohnson: thanks, I'll do the proper review now, thanks for bearing with me about making the diff small and obvious17:45
ijohnsonno problem, I am about to break for lunch, so be back in a little bit17:45
mupPR snapcraft#3084 opened: repo: fix for multi-arch virtual-packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3084>18:01
* mvo heard his name and wonders if he can be helpful?18:08
mupPR snapd#8553 closed: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8553>18:11
mupPR snapcraft#3085 opened: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>18:16
pedronisijohnson: reviewed18:19
ijohnsoncool let me look18:20
mvocachio: I think I have an idea why sbuild fails, testing the fix now18:21
cachiomvo, great!!18:21
cachiothanks for digging18:22
cachiocmatsuoka, can't connect through ssh sometimes to the uc20 vm18:50
cachiocmatsuoka, you said you had a similar problem right?18:51
cmatsuokacachio: yes, but it doesn't seem to be deterministic18:51
cachiocmatsuoka, right18:51
cachiosame happening here18:51
cmatsuokacachio: I saw it happening a few days ago then this morning18:51
cachiosometimes work sometimes not18:51
cmatsuokacachio: did you report it to dimitri?18:52
cachiocmatsuoka, no18:53
mupPR snapd#8554 opened: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>18:55
cmatsuokacachio: ok, I pinged him18:55
mvocachio: the pr 8554 is the one that should fix the nightly sbuild19:00
mupPR #8554: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>19:00
cmatsuokacachio: I just tried to reproduce here but it's starting correctly, if it fails for you try to preserve a log19:00
mvohappy release day, lot's of 403 from the store it seems :/19:01
zygamvo: indeed19:02
zygamvo: I'm sure while we are stressed on release features the store team is scrambling to make it all work today :)19:03
mvozyga: yeah, it's not meant in a bad way, it just shows how popular ubuntu is19:07
zygahappy release day mvo :)19:08
zygaremember command-not-found?19:08
zygalong way eh?19:08
cmatsuokagood news everyone! it seems that #8547 + #8531 + #8552 is working end-to-end19:16
mupPR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>19:16
mupPR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>19:16
mupPR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>19:16
* cmatsuoka is really not used to things working that easily so he will test it again19:18
oSoMoNpedronis, another candidate for the "hide comment" feature: https://bugs.launchpad.net/snapd/+bug/1776873/comments/4319:23
mupBug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged by pedronis> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>19:23
mvozyga: totally remember it, I still maintain the thing that build the db :)19:24
pedroniscmatsuoka: sounds great news though :) , let me know when I should re-review 853119:25
pedronis8552 needs tweaks but is good to know things work together19:26
cmatsuokapedronis: will push soon, I'm just running a test commenting out the model measurement to make sure it's working :)19:26
mvopedronis: can I land 8547 to unblock people? just looking at the failures, looks like it's a bad case of "search" failing with 403, nothing real19:26
pedronismvo: I gave my +1 no? or you asking if you can override ?19:27
mvopedronis: yeah, if you are ok with landing it, I take that as a yes19:27
mvopedronis: I review the failures, so far all "failing search"19:27
pedronismvo: if you looked at the errors and seem unrelated, yes happy for it to land19:27
xnoxcachio:  cmatsuoka: please file bug reports on github.com/snapcore/core2019:29
mupPR snapd#8547 closed: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8547>19:31
cmatsuokapedronis: pushed to 8531, with master already merged in19:33
pedroniscmatsuoka: thanks, will look in a little bits19:34
cmatsuokapedronis: thanks19:35
cmatsuokacachio: could you file a bug for xnox? I'm not being able to reproduce the problem here19:38
* cmatsuoka will take a 30min break19:40
mupPR snapcraft#3085 closed: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>19:40
mvofwiw, I updated 855119:43
mvo(but not in the critical path)19:43
pedroniscmatsuoka: reviewed19:47
pedronismvo: yea, we should land 8531 before 855119:48
pedronismvo: if you are still around can you look also at 8531 ?19:48
pedronisah, actually you reviewed it already19:49
mvopedronis: yeah, your input on my points would be great19:53
mvopedronis: maybe I went over-the-top a bit19:53
mvo(if so, appologizes)19:53
pedronismvo: 8531 ?19:53
pedronisor somewhere else?19:53
mvopedronis: yes, the question about if we want cmd_create_partitions changes and if we do I think we want to add them to the spread tests, no?19:53
pedronismvo: we can pass a model in the spread test, it will mostly test that is accepted and nothing explodes19:55
pedronisbut the test doesn't really check the policy as such because there is no unsealing19:55
pedronismvo: the e-2-e uc20 tests with secboot, tpm will test this19:55
pedronisbut I don't think we have one yet19:56
mvook19:57
pedronismvo: sorry, that was vague19:57
pedronismvo: I think we want the spread test mostly because the coverage of bootstrap is very low atm19:57
pedronisand because it tests actual partition level stuff19:58
pedronisnot so much sealing details19:58
mvopedronis: ok, then we should probably update it, it's not updated to test the model yet19:58
pedronissnap model --assertion > model  and use that I suppose19:58
pedronisor whatever way works to get a model really19:59
mvook19:59
* mvo looks at this19:59
pedronismvo: ah, no, we need a model with a grade19:59
pedronismaybe19:59
pedronisshould work without but maybe saner with one that has grade19:59
* pedronis break20:00
cmatsuokapedronis, mvo: thanks for the review, I'll check/fix20:01
mvocmatsuoka: ok, let me quickly push my first tiny tweak20:01
cmatsuokamvo: sure20:02
mvocmatsuoka: I will leave the other bits to you then :) sorry for being pushy. once the spread bits are added I will updated 8551 but it's not in the critical path20:02
mvocmatsuoka: done, it's all yours again :)20:02
cmatsuokamvo: thanks!20:03
cmatsuokamvo: and thanks for 8551 too, it will make things much cleaner20:03
mvocmatsuoka: thank you20:04
mvocmatsuoka: actually, don't worry about the spread test in 8531, just fix the cosmetic bits from samuele, we can add the spread thing in 855120:12
* mvo takes a break now too20:12
mvocmatsuoka: unless you have it already or it's almost done or trivail etc :)20:12
pedronismvo: it's tests/nested/manual/uc20-create-partitions-encrypt20:13
cmatsuokamvo: I only have the cosmetic bits so I'll stop there20:13
pedroniscmatsuoka: also it's still marked draft20:14
pedronisyou should switch that20:14
cmatsuokapedronis: will unmark it, I forgot that, thanks20:14
pedronisnp20:14
mvopedronis: yeah, I will add the test as part of 8551 in my morning20:15
* mvo will stay around a bit to help landing 853120:15
ijohnsonpedronis: the ubootenv PR is ready again with your comments addressed, and I confirmed that it now works properly on the pi20:19
ijohnsonpedronis: I didn't go through the full battery of trying failing kernel snap upgrades etc. but I was able to upgrade the kernel perfectly fine20:20
ijohnsonpedronis: the one thing that I'm just now realizing however is that we need to truncate the boot.sel file when we write it since it could be smaller (and in practice it will end up being smaller after a successful upgrade), which it seems like is less than ideal for robustness against fs corruption20:21
cmatsuokamvo: pushed20:22
pedronisijohnson: yes, any suggestion?20:58
ijohnsonpedronis: well tbh I'm starting to think maybe we should just use the normal native uboot format instead of the text one precisely because it's fixed size :-/20:59
ijohnsonpedronis: the other thing we could do is pad the file with newlines or whitespace, as the parser currently ignores empty lines without any flags20:59
pedronisijohnson: is that true for uboot itself though?21:00
ijohnsonpedronis: mmm good point I could test it later tonight21:00
ijohnsonI need to step out shortly to go get groceries before the store closes21:01
pedronisijohnson: anyway,  can we specify a size for the native format? like 4096 instead of 128k , is the 128k only for the main uboot.env ?21:01
ijohnsonpedronis: yes 128k is only for the main uboot.env, this other one could be whatever size we want, as long as it's not _too_ big for some definition of too big21:02
ijohnsonbut I think the "too big" comment is like in megabytes21:02
mvo+121:02
pedronisijohnson: I suppose for this dave's script just need small tweaks ?21:02
ijohnsonpedronis: yes it would just be like 1-2 lines change to not drop the \0 anymore, otherwise the boot.scr looks exactly the same cause it's the same commands afaict21:03
pedronisijohnson: what are the -t on env import ?21:03
ijohnsonpedronis: I can't seem to find exactly what that flag does, waveform what does the `-t` flag do for `env import` ?21:07
ijohnsonoh he's not here21:07
pedronisit's quite late for him, I wonder if it means -t"ext"21:08
pedronisor something else21:08
ijohnsonpedronis: I was just talking to him in the other channel21:09
ijohnsonI don't think it's ext format because the fs isn't ext21:09
pedronisijohnson: no, I mean -t as contraction for -text21:10
ijohnsonah could be ys21:10
ijohnson*yes21:10
ijohnsonthis is all the usage command says: `env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import environment`21:10
* mvo really needs to leave, I will land 8531 in my morning21:10
pedronisijohnson: anyway it also means we don't need to support text format, which maybe is a plus21:12
pedronis(less code)21:12
pedronisbit of a roundabout adventure21:13
ijohnsonpedronis indeed it is a bit of a circular adventure21:14
ijohnsonIt would be a lot less code however that we need to merge now21:14
pedronisijohnson: yes, I said this: (less code)21:15
ijohnsonI really need to get to the store now but I will start early tomorrow again if you want to discuss options21:15
ijohnsonA bit sad we probably won't be able to land everything today and build tomorrow but oh well21:16
ijohnsonMaybe builds can happen over the weekend21:16
ijohnsonIf we land tomorrow that is21:16
ijohnsonI'll try to open a branch later tonight that does everything with native and maybe you and mvo can pick what to do tomorrow21:17
mupPR snapcraft#3084 closed: repo: fix for multi-arch virtual-packages <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3084>21:55
mupIssue core20#50 opened: Ssh server fails to start after core snap refresh <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/50>22:17

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