/srv/irclogs.ubuntu.com/2020/10/28/#snappy.txt

mupPR snapd#9558 opened: cmd/snap, snapmgr, tests: cleanups after #9418 <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9558>01:29
mupPR snapcraft#3342 opened: unit tests: mock os.environ.copy() for deb tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3342>02:17
mupPR snapd#9489 closed: daemon,client: write and read a maintenance.json file for when snapd is shut down <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9489>02:35
mupPR snapd#9542 closed: interfaces: deny connected x11 plugs access to ICE <Bug> <Needs security review> <⚠ Critical> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9542>02:40
mupPR snapd#9559 opened: client, daemon, cmd/snap: cleanups from #9489 + more unit tests <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9559>02:40
mupPR snapd#9560 opened: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9560>03:50
zygagood morning06:40
zygahey mvo06:59
mvohey zyga07:00
zygahey mbeierl07:00
zygamborzecki,07:00
mborzeckimorning07:00
mborzeckizyga: heya07:00
mvohey mborzecki07:03
zygamborzecki, last nigth I was cursing at selinux07:03
zygamborzecki, I totally failed to fix that denial, after hours of wasted effort trying things07:04
mborzeckizyga: heh, i'm pretty sure you're not the only one unhappy with selinux :P07:07
zygaI felt so lost because the denial and the rules are so far away from each other07:08
zygaI give up on that,07:08
zygaI want to actually spend my days on productive progress07:08
zygamaybe you could look when you have a moment07:08
mborzeckihmm not good `13 files changed, 891 insertions(+), 86 deletions(-)`07:47
mborzeckineed to chop it up into more reviewable bits07:54
zygahey pawel08:06
pstolowskiheya08:06
mupPR snapd#9561 opened: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>08:06
mvogood morning pstolowski08:06
mborzeckimvo: can you take a look at #9561?08:07
mupPR #9561: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>08:07
mborzeckipstolowski: hey08:07
mborzeckizyga: btw. yday i ran a loop with this test https://github.com/bboozzoo/spread-mini/blob/master/mini/vendor-sync/task.yaml on tumbleweed, 27 iterations, all good08:08
mborzeckiwonder whteher we're doing something wrong there08:09
mvomborzecki: sure08:09
zygamborzecki, that's great08:14
zygamborzecki, so is that using our images?08:15
mborzeckizyga: yes08:15
zygathat is even more surprising08:15
* zyga grabbed small breakfast08:17
mupPR snapd#9562 opened: tests: improve uc20-create-partitions-reinstall test <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9562>08:21
mborzeckimvo: thanks ;) now i need to get +1 from pedronis and a green merge button08:22
zygapedronis, o/08:32
zygagood morning08:32
zygaI've replied to some questions and sent a few small patches in response to others08:32
zygalet's discuss the rest at 1008:32
zygaI will try to make all the changes as fast as possible08:32
mborzeckipedronis: hi, can you take a look at #9561?08:43
mupPR #9561: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>08:43
pedronisyes, in a bit08:43
mborzeckipedronis: thanks08:48
pedronismborzecki: can you look at https://github.com/snapcore/snapd/pull/9560 it seems to simple to me08:55
mupPR #9560: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions <Run nested> <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9560>08:55
mborzeckipedronis: yeah, just left a comment there08:55
mborzeckiheh, ok see you left one too08:56
* zyga grabs laptop08:57
pedronismborzecki: I think we use the offset indirectly because we run ensureLayoutCompatibility first08:57
pedronisbut is still all a bit fragile08:57
mborzeckipedronis: hm it should probably identify the role of the partition based on gadget info from laid out volume and then double check it's the same partition (i.e. look at offset, though a bit of belt & suspenders maybe?)08:59
mborzeckiloos like ensure layout compatibility runs later09:02
mbeierlzyga, hello!09:05
dot-tobiashi all09:05
mupPR snapd#9558 closed: cmd/snap, snapmgr, tests: cleanups after #9418 <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9558>09:27
pedroniszyga: pasted https://github.com/snapcore/snapd/pull/9546#issuecomment-71781382509:38
mupPR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>09:38
zygapedronis, thank you!09:38
zygapedronis, one more thing that I just thought of is gadget/kernel copy-exporting assets\09:45
zygapedronis, like device tree files or kernel images copied to FAT09:45
zygapedronis, but I think this is all in sync with this approach09:45
zygapedronis, changes look good, I think this will be over quickly :-)10:01
* zyga coffee or tea, depending on what's made upstairs, brb10:09
zygare10:25
mborzeckipedronis: i have the code that passes luks2 format options, but i wonder whether we should just pick something in the snapd/secboot package rather than expose it all the way to gadget/install, the patch here: https://github.com/snapcore/snapd/commit/603fee44875e73a9c129e06574bf41bcad0eeadd10:25
mupPR snapd#9557 closed: tests/snap-advise-command: re-enable test <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9557>10:47
pedronismborzecki: I moved something in the TODO list10:50
pedronismborzecki: should we quickly sync about your question and other bits?10:50
mborzeckipedronis: sure, let me jump into standup HO10:51
zygapedronis, I ran into one bump, Manifest stores SnapName and ExportedVersion but we mangle core_revision or revision as both "snapd". When you look at ExportedFile.SourcePath you cannot use /snap/$snapName/$revision directly, instead we must unpack that special case there11:16
zygaI was wondering if this would warrant a distinction between (true) SnapName, SnapRevision and ExportedSnapName and ExportedVersion11:17
zygaif we were to store SnapName: "core", SnapRevision: "1234", ExportedSnapName: "snapd", ExportedVersion: "core_1234" then we would not have to parse anything11:18
zygawe might even make ExportedSnapName and ExportedVersion omitempty, and fall back to SnapName/SnapVersion11:18
mvomborzecki, pedronis 9561 is green, ok if I merge?11:19
zygaI think this is better than trying to bake the logic there11:19
zygafor clarity, I am trying to write a pair of functions ExportedFilePathName and ExportedFileSourceName11:19
zygathat both take the following arguments: manifest *Manifest, set *ExportSet, exported *ExportedFile11:19
zygapedronis, I made those modifications, I will post this soon11:31
zygait's much more natural now11:31
pedronissorry, I was syncing with Maciej about something else11:32
mupPR snapd#9561 closed: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>11:32
zygafor reference https://paste.ubuntu.com/p/vt7Xg4frcH/11:33
pedronismmh, I'll need to look, I worry a bit if it's confusing or not confusing11:34
pedronisI need to go have lunch11:35
pedroniszyga: it's probably fine but we need to be careful how we name things and where we put the fields12:09
pstolowskimvo: updated #955312:10
mupPR #9553: tests: add spread test for refreshing from an old snapd and core18 <Run nested> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9553>12:10
mvopstolowski: thank you! and sorry that I did not think about this earlier12:12
pstolowskinp!12:12
cachiozyga, hey12:14
cachiozyga, I left a comment https://github.com/snapcore/snapd/pull/9556#issuecomment-71789045912:14
mupPR #9556: tests: testing new fedora 33 image <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>12:14
cachiodo you know how to fix that?12:14
zygapedronis, ack12:24
zygacachio, looking12:24
zygaoh that's serious12:25
zygabut again related to how we test things IMO12:25
zygamborzecki, ^ fedora bumped libc?12:25
zyganew libc baked into snap-exec12:25
zygaI thougth we made it static12:25
zygabut perhaps not really?12:25
mborzeckihm maybe?, it should be static, there's a check in snapd.spec for it12:25
zyga: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/lib/snapd/snap-exec)12:26
* mvo hugs mborzecki for 952812:32
pedroniszyga: I didn't notice this yesterday, bit confused:  https://github.com/snapcore/snapd/pull/9546/files#r51340543112:34
mupPR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>12:34
zygammmm, replied12:36
zygado you want to re-think?12:36
zygashould I pause the changes?12:36
zygaI think, as a first instinct, that this _is_ fine12:37
zygaespecially with what we said about a higher level mapper for things like aliases/man pages12:37
mborzeckizyga: i can take a look a bit later12:37
zygamborzecki, thank you!12:37
zygapedronis, as one more data point, this is exactly why you designed core_$rev as the exported name before12:38
dot-tobiasHow do I completely reset a part in snapcraft that pulls in stage-packages? I'm testing which packages are required for a cmake-based build; is snapcraft clean my-part && apt autoremove enough?12:43
* zyga doesn't know, sorry12:44
* ogra just uese a fresh lxd container for such cases12:45
ogra*uses12:45
dot-tobiasogra: That would be my go-to approach if it would't need ~ 10min for each run to get to the part I'm working on 🙈12:46
pstolowskizyga: do you have some time for #9535?12:51
mupPR #9535: o/snapstate: generate snapd snap wrappers again after restart on refresh <Bug> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9535>12:51
zygayes, I remember that12:51
zygapstolowski, why is the new logic only applied to core?12:55
pstolowskizyga: only on core we generate wrappers. this check is repeated anyway in AddSnapdServices in wrappers12:55
zygaah, I see12:55
pedroniszyga: two things come to mind, in general what is in .../export/* is really the input for another round of indirection in most cases, this is a bit hidden right now because we have only use case. because of that though there is really no good reason to do the dance we are doing conflating snapd/core and host for anything but snapd12:59
pedronis*only 1 use case12:59
mborzeckizyga: heh, so snap-exec is not statis, wtf is our check doing even12:59
zygamborzecki, ;D12:59
zygamborzecki, it's on strike today12:59
mborzeckihaha, i think i know13:00
zygapedronis, if we ever want to remove that special case we could create one more layer which updates snapd-tools -> core/tools or host/tools or otherwise, so I think we are safe here13:01
zygamborzecki, ldd is naive13:01
zygamborzecki, readelf FTW13:01
mborzeckizyga: ldd is good enough, just that it prints to stderr now apparently13:01
pedroniszyga: yes, we could do that. but my point here is more that we need to make clear that the strange bits are really only for this special case13:01
mborzeckizyga: and the check is ldd .. | grep withouth 2>&113:02
mborzeckiwithout13:02
zygamborzecki, readelf has issues with some things in my experience but I'm happy the issue is easier this time :)13:02
pedroniszyga: there's no reason to abuse them later for something else, it's probably a bad idea even13:02
zygapedronis, ack13:02
zygapstolowski, approved13:03
pstolowskizyga: thank!13:04
pstolowski*thanks13:04
mupPR snapd#9535 closed: o/snapstate: generate snapd snap wrappers again after restart on refresh <Bug> <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9535>13:08
mupPR snapd#9563 opened: secboot: set metadata and keyslots sizes when formatting LUKS2 volumes <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9563>13:08
mborzeckizyga: fun fact, i had a fix for f33, but not proposed yet, it's a sync between fedora packaging and our snapd.spec in tree13:12
zygamborzecki, related https://forum.snapcraft.io/t/apps-wont-run-and-crash-on-gnome-wayland/20322?13:14
zygamborzecki, or is that for the x11 socket?13:14
zygaah sorry13:14
zygaignore em13:14
zyga*me13:14
mupPR snapd#9564 opened: secboot: fix doc comment on helper for unlocking volume with key <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9564>13:23
pstolowskipedronis: NewRequestWithContext is available from go 1.13 :( they actually show version numbers, see https://golang.org/pkg/net/http/#NewRequestWithContext (it's on right-hand side)13:23
pedronissad :(13:24
pstolowskipedronis: is upgrade out of question13:25
pstolowski?13:25
pedroniswe need to talk with mvo13:25
pedronisI think there's a older way to do what we want13:26
pedronisis just messier13:26
pedronisI didn't notice the versions on the right, I suppose is recent-ish change13:27
pedronispstolowski: btw I think we do set some other timeouts via httputil/transport.go13:30
pedronispstolowski: the old way is to use cli.Transport.CancelRequest13:31
ijohnsonpedronis: mborzecki: perhaps we can chat sometime this morning re gpt attrs ?13:33
ijohnsonI guess I'm a bit confused how to implement it using offsets given that we essentially already do that exact check in verifyLayoutCompatibility13:33
mborzeckiijohnson: i'm ok with after/before standup13:33
pedronisijohnson: I don't think the issue is strictly the offsetts, you reasoning is not wrong, the issue is more about what is the marker/what we correlate with, the fs label might not be set13:35
pstolowskipedronis: hmm, i missed that, got confused by &ClientOptions{} and Timeout: opts.Timeout in NewHTTPClient13:35
ijohnsonpedronis: ok, yeah I suppose it makes sense to not use the fs label in that case and more rely on the partition label, but again we won't have the partition label on mbr13:36
ijohnsonlet me have a look at the code again then perhaps we can chat after the SU13:36
pedronisijohnson: we could use offset everywhere then?13:36
pedronisanyway my other issue with the PR as is, is that the flag seems more and more of a danger13:36
mborzeckiijohnson: offet will work for gpt and mbr13:36
ijohnsonpedronis: I think as you said we need to just get rid of that CreatedDuringInstall flag entirely and then just compare the offsets after we have both the ondisk and the laidout from the gadget13:37
ijohnsonmborzecki: right13:37
mborzeckiijohnson: you'll probably need to thing about fitting that with the rest of the code, iirc ensureLayoutsCompatible runs later and looks at IsCreatedDuringInstall flag13:38
pedronisdoes it?13:38
pedronisit says it does13:38
pedronisbut I missed where13:38
ijohnsonmborzecki: I think we should just drop that IsCreatedDuringInstall flag because yes ensureLayoutsCompatible runs after we build up the on disk layout (obviously)13:38
ijohnsonI think I know what to do now13:39
ijohnsonI just need to see if I know _how_ to do it :-)13:39
pedronismmh, it does13:39
pedronisso I'm confused indeed13:39
zygahip hip hippo!13:40
ograshave it !13:42
pstolowskipedronis: CancelRequest is marked deprecated in current go docs, not a huge problem but means we may need to redo this in the future13:43
pedronisyea, I know13:44
* ijohnson is slightly sad my suggestion to use hyrax was not taken13:46
zygahyrax?13:46
* zyga googles 13:46
ijohnsonit's like a little african prairie dog13:46
zygaoh wow13:46
zygaall the new words :)13:46
ijohnsonI guess my comparison requires you know what a prairie dog looks like :-)13:46
* ogra would have voted for homunculus13:46
zygahasty hummus13:46
ogra(given it is the first one after an LTS that seemed to fit)13:47
* ijohnson plans to try again in 13 years13:47
ijohnsonhaha13:47
pedronismborzecki: you bumped secboot to current tip in your PRs?13:50
mborzeckipedronis: yes13:50
mborzeckipedronis: hmmm13:51
mborzeckipedronis: not quite the tip apparently, it's a this commit https://github.com/snapcore/secboot/commit/7c5ed6888746f5a798e475c02d23c08678a5ede813:53
pedronisah, so will need another bump13:53
mborzeckiyup, the activation with multiple keys isn't there13:53
zygacannot join14:00
zygaone sec14:00
ograzyga, LOL ... did you see the journal at LP#1898869 ?14:09
zygain a call14:09
ograits an atom laptop 4GB that runs boinc !14:09
ogra+with 4GB14:10
zygaogra, I'm running focal on a core2 duo with 3GB ram and it runs, pretty great actually14:17
ograzyga, yeah, but you didnt install BOINC ... and a ton of broken "screen share" gnome-shell extensions14:18
ograand your focal surely also doesnt have ifupdown installed (which seems to confise NM)14:19
ograi'm refreeing to https://bugs.launchpad.net/bugs/189886914:19
mupBug #1898869: System slow on booting <amd64> <apport-bug> <focal> <ubuntu> <snapd (Ubuntu):New> <systemd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1898869>14:19
ograin the light of what he installed it is actually booting pretty fast14:20
zygaogra, wait, what is boinc?14:24
zygaI thought you said "bionic"14:24
ograthe successor of "seti at home"14:24
ograhttps://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing14:25
zygaLOL14:26
ograso someone installs all possible 3rd party SW that puts high load on the machine on boot ... uses the lowest end CPU, 4GB RAM and a rotary disk and complains about 1.5min boot time 🙂14:27
ograi'd say that system actually flies given what it has installed 🙂14:27
* pstolowski lunch14:32
mupPR snapd#9553 closed: tests: add spread test for refreshing from an old snapd and core18 <Run nested> <Test Robustness> <Created by stolowski> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9553>14:48
mupIssue core20#93 opened: forward port things to 22 branch <Created by xnox> <https://github.com/snapcore/core20/issues/93>14:49
mupPR core20#91 closed: hooks: add /var/lib/snapd/save <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/91>14:49
* cachio lunch14:59
mborzeckixnox: thanks!15:04
zygapedronis, I've pushed the big change, I'll look at the SetStatus part now but it seems to be somewhat problematic15:14
zygathe task has now DoneStatus even though it is undone15:15
zygaon disk behavior is correct15:15
zygabut I wanted to ask if that is expected15:15
zygapedronis, a few misc comments remain but I think the bulk of it is good now15:20
zygaI'll break for an hour and rebase the rest on top to ensure that it still works end-to-end15:21
mupPR snapd#9564 closed: secboot: fix doc comment on helper for unlocking volume with key <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9564>15:48
zygarebased, running export smoke test now15:49
pedroniszyga: there' something off about instances (because of how we do current), there's is probably a bit more to simplify15:54
zygammm15:56
zygafound a trivial one liner bug, will add some tests and push again15:58
zygaI will look at instances after that15:59
zygapedronis, if we do .../export/instance_key/revsion directly we can indeed simplify16:00
zygapedronis, neither bases nor snapd allow instances so that's compatible with the goal16:00
zygapedronis, we could also eventually allow that, for whatever reason, by having the mapping layer we discussed16:00
zygaso I think that yes, we can further simplify this16:00
pedroniszyga: when we discussed this I didn't consider that most other cases will need another indirection anyway16:02
zygayeah, this turns the export manager mostly into a "mechanical" layer16:02
zygawhich is good16:02
zygaI wonder if we should do the snapd special case differently, perhaps by using a different symlink which picks current tool provider, pointing at snapd/current/tools, core/current/tools or host/current/tools16:04
zygathen the whole special case would go away and only one, distinct symlink would be custom16:04
pedroniszyga: that would need more design16:06
zygapedronis, I've rebased the other branch, tests are passing,16:09
zygapedronis, this change was entirely self-contained, good :)16:09
ijohnsonugh gadget tests are very difficult to write - they require doing arithmetic!16:15
zygaijohnson, easy as pi16:16
ijohnsonit's as easy as finding a rational representation of pi16:16
zygayou are being irrational!16:17
* zyga shoots upstairs to check up on kids16:17
zygamore export manager push tomorrow16:17
mborzeckimvo: still around? can you merge #9528 ? the failure on 18.04 is mount-ns:inherit16:59
mupPR #9528: cmd/snap-bootstrap: mount ubuntu-save during boot if present <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9528>16:59
ijohnsonthat test has been failing more consistently recently16:59
ijohnsonfor whatever reason the cgroup mountsh ave different options16:59
mborzeckiheh17:01
mvomborzecki: sure, let me do this17:07
mvomborzecki: done, I guess that means that 9563 is now also unblocked?17:08
mupPR snapd#9528 closed: cmd/snap-bootstrap: mount ubuntu-save during boot if present <Run nested> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9528>17:09
mborzeckimvo: thanks, yes, i'll merge and push17:09
mvomborzecki: \o/17:10
mupPR snapd#9565 opened: [RFC] overlord/devicestate: bind mount ubuntu-save under /var/lib/snapd/save on startup <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9565>17:14
mborzeckimvo: pedronis: ^^17:14
mborzeckiand #9563 has been updated too17:15
mupPR #9563: secboot: set metadata and keyslots sizes when formatting LUKS2 volumes <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9563>17:15
pedronismborzecki: thanks17:16
mborzeckipedronis: it does a mount via systemd-mount, felt it may be a bit cleaner and easier to test than fiddling with syscall.Mount again17:17
mborzeckianyways, need to wrap it up and help kids with the homework17:17
pedronissounds good17:17
mvopedronis: I'm working on the new location for lockout/policy-auth. should the recovery key also change location (I guess not but wanted to double check)17:22
pedronismvo: they are in /var/lib/snapd/device/fde right now ?17:28
mvopedronis: correct17:29
pedronisso they would got to .../save/device/fde17:29
mvopedronis: ok17:29
pedronisabout the recovery keys I don't have strong opinions atm17:29
cmatsuokapedronis: I'm a bit confused with the save partition key, will it exist in both sealed and unsealed forms?17:38
mupPR snapd#9559 closed: client, daemon, cmd/snap: cleanups from #9489 + more unit tests <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9559>17:39
pedroniscmatsuoka: yes17:42
pedroniscmatsuoka: there will be an unsealed copy inside encrypted ubuntu-data17:42
pedronisand sealed copy inside a fallback sealed object17:42
cmatsuokabut not with the normal data sealed key, is that correct?17:43
pedroniscmatsuoka: the ubuntu-data key exists only sealed (once in the run object, once in a fallback object for recover paths only)17:44
pedroniscmatsuoka: we discussed this design with Chris, the reason to do this way is that the normal run path needs to unseal only one object17:45
pedronisand unsealing is a bit expensive, so we avoid the run boot slow down17:45
cmatsuokaok, that makes sense now, thanks17:45
cmatsuokapedronis: is it more expensive or otherwise worse if I seal the ubuntu-data key as the only key using the SealMultiple call?17:46
pedroniscmatsuoka: not really, actually secboot internally does that, the single object calls use the multi object ones17:47
pedronisnow17:47
cmatsuokaok, great17:47
cmatsuokathanks17:47
pedronisSealKeyToTPM does SealKeyToTPMMultiple(tpm, []*SealKeyRequest{{Key: key, Path: keyPath}}, params)17:48
mupPR snapd#9566 opened: boot: store the TPM{PolicyAuthKey,LockoutAuth}File in ubuntu-save <Run nested> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9566>18:09
mupPR snapd#9567 opened: tests: using the nested-state tool in nested tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9567>18:29
* cachio afk18:29
zyga-mbpogra: that's one badass gramma, running postfix18:45
ograhaha, yeah ... that laptop is a mess18:45
ogra"lowlatency makes granny faster" 🙂18:46
ogra(or not)18:46
zyga-mbplowlatency 4GB folding at home arch linux19:09
pmarthi. i need to access user mounts from snap. i connected removable-media interface but /media is still missing from snap root directory19:46
pmartis this the correct interface?19:46
ijohnsonpmart: what directory are you trying to access ?19:48
pmart /media/user/stuff19:48
pmartit's present in chromium snap e.g. but chromium has additionaly system-files connection19:52
pmartwait it works, kinda20:10
pmartit's just missing from "ls /" output20:11
mupPR snapd#9562 closed: tests: improve uc20-create-partitions-reinstall test <Simple 😃> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9562>20:15

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