| mborzecki | morning | 06:58 |
|---|---|---|
| zyga | good morning | 07:02 |
| zyga | mvo: I've shut down half of the workers now | 07:02 |
| zyga | let me know if there is any disruption | 07:02 |
| mborzecki | zyga: hey | 07:06 |
| pstolowski | morning | 08:01 |
| mvo | hey pstolowski | 08:01 |
| mvo | zyga: thank you, excellent | 08:02 |
| mup | PR snapd#9724 closed: boot: observe successful command line update, provide a default <Run nested> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9724> | 08:05 |
| mup | PR snapd#9718 closed: secboot,devicestate: add scaffoling for "fde-reveal-key" support <Needs Samuele review> <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9718> | 08:10 |
| mborzecki | pstolowski: mvo; hey | 08:18 |
| mvo | mborzecki: good morning! | 08:29 |
| pedronis | #9730 needs 2nd reviews | 08:55 |
| mup | PR #9730: hookstate: refactor around EphemeralRunHook <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9730> | 08:55 |
| mborzecki | the apparmor support situation on opensuse leap is confusing, on the one hand we downgrade the policy template, on the other snap-confine is built without apparmor support, so why bother with any support at all? | 09:17 |
| mborzecki | and there's a special case for tw, where it's built with apparmor support and no policy downgrade | 09:18 |
| mborzecki | so on leap we generate some profiles, but never transition to them | 09:19 |
| mup | Bug #1906621 opened: System doesn't do FDE when installing with secure boot enabled <Snappy:New> <https://launchpad.net/bugs/1906621> | 09:27 |
| mup | Bug #1906621 changed: System doesn't do FDE when installing with secure boot enabled <Snappy:New> <https://launchpad.net/bugs/1906621> | 09:30 |
| mup | Bug #1906621 opened: System doesn't do FDE when installing with secure boot enabled <Snappy:New> <https://launchpad.net/bugs/1906621> | 09:36 |
| mup | Bug #1906621 changed: System doesn't do FDE when installing with secure boot enabled <Snappy:New> <https://launchpad.net/bugs/1906621> | 09:42 |
| jamesh | pedronis: bug filed here: https://bugs.launchpad.net/snapd/+bug/1906622 | 09:49 |
| mup | Bug #1906622: UC20 system fails to seed when model contains snaps requiring experimental.user-daemons or dbus-activation <snapd:New> <https://launchpad.net/bugs/1906622> | 09:49 |
| * mvo hugs mborzecki for reviewing 9695 | 09:50 | |
| mup | Bug #1906621 opened: System doesn't do FDE when installing with secure boot enabled <Snappy:New> <https://launchpad.net/bugs/1906621> | 09:51 |
| pedronis | jamesh: thx | 10:01 |
| pstolowski | pedronis: hey, does this structure look sensible? https://pastebin.ubuntu.com/p/tCSc7wznby/ | 10:44 |
| mup | PR snapd#9738 opened: secboot: use `fde-reveal-key` if available to unseal key <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9738> | 10:56 |
| pedronis | mborzecki: do you remember why we have EffectiveRole and EffectiveLabel, they don't to be used very consistently (especially for new UC20 stuff) ? | 10:58 |
| pedronis | *dont' seem | 10:58 |
| mborzecki | pedronis: iirc it was some backward compatibity hacks where things were left unspecified ing adget yaml | 11:00 |
| pedronis | mborzecki: it's a bit of a mess | 11:00 |
| pedronis | new code seems ignore them | 11:00 |
| pedronis | which seems not to provoke immediate problems, but long term is not a good state of things | 11:01 |
| mborzecki | pedronis: it should be used wherever we check Role, but i agree that it's not used and should be fixed | 11:02 |
| mborzecki | same holds for label | 11:02 |
| pedronis | or we should set things to the value | 11:02 |
| pedronis | having Label and EffectiveLabel is just asking to get it wrong | 11:02 |
| pedronis | or have only the accessor | 11:03 |
| pedronis | anyway bit of a tangle atm | 11:03 |
| * pstolowski going to the dentist | 11:03 | |
| mborzecki | though there will probably be some weird undocumented cases where it's supposed to be explicit | 11:03 |
| mborzecki | pedronis: i can put it my queue | 11:03 |
| pedronis | mborzecki: well, I'm looking into it right now because of the issue from yesterday | 11:03 |
| pedronis | mborzecki: I'll see how far I can get | 11:03 |
| mborzecki | pedronis: ok | 11:03 |
| pedronis | pstolowski: let's chat this afternoon, sorry, I was chasing something else | 11:06 |
| mup | PR snapd#9739 opened: interfaces/apparmor: fix generating of extended s-c AppArmor profiles with /usr/libexec <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9739> | 11:31 |
| mup | PR snapd#9740 opened: packaging/opensuse: enable AppArmor on Leap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9740> | 11:41 |
| zyga | mborzecki at the time this was a single decision | 11:51 |
| zyga | mborzecki we should probably just build s-c with apparmor now | 11:51 |
| mborzecki | zyga: yup, there's 9740 for that | 11:51 |
| pstolowski | re | 12:41 |
| mup | PR snapd#9409 closed: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9409> | 13:57 |
| * zyga looks at export manager now | 14:14 | |
| zyga | mborzecki https://github.com/snapcore/snapd/pull/9740#pullrequestreview-543996730 | 14:18 |
| mup | PR #9740: packaging/opensuse: enable AppArmor on Leap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9740> | 14:18 |
| om26er | My snap has a need to access `/usr/lib/libGLESv2.so.2` from the host, I have the opengl interface connected. However it seems that my snap's `/usr/lib` view is actually of the core20 snap and *not* the host's rootfs, which actually has the nvidia's libGL* libraries. | 14:19 |
| mborzecki | zyga: well, that requires a differnt fix then, because right now snapd acts silly when there's no s-c apparmor profile, and is completely oblivious to s-c not supporting aa at all | 14:21 |
| zyga | l | 14:21 |
| mborzecki | om26er: can you run the app with SNAP_CONFINE_DEBUG=1 SNAPD_DEBUG=1 and post the logs somewhere? btw. is it a tegra device? | 14:21 |
| zyga | om26er try /var/lib/snapd/lib/gl | 14:21 |
| zyga | tegra is not supported AFAIK | 14:22 |
| zyga | as in, no gl support for tegra | 14:22 |
| zyga | via snapd | 14:22 |
| om26er | mborzecki, yes its a Nvidia Jetson Xavier NX, running a yocto based image. | 14:22 |
| zyga | mborzecki why does snapd get confused when s-c has no apparmor enabled? | 14:23 |
| zyga | om26er no snapd support for nvidia on that platform | 14:23 |
| zyga | om26er if you want to know more I can explain but it's a long road to fix t hat | 14:23 |
| mborzecki | zyga: use has home on nfs: https://forum.snapcraft.io/t/snapd-doesnt-start-on-opensuse-leap-15-1/13710/10 and snapd tries to update s-c profile, which does not exist, so it just fails and exits | 14:23 |
| zyga | mborzecki that's different | 14:24 |
| zyga | we should have the profile | 14:24 |
| zyga | and not use it | 14:24 |
| om26er | zyga I was able to "fix" that by copying all the required libGL* files to `/var/lib/snapd/lib/gl`, maybe a patch to snapd would fix? | 14:24 |
| zyga | IMO that's safe | 14:24 |
| mborzecki | zyga: why have it when s-c has no aa? | 14:24 |
| om26er | that of course is a hack | 14:24 |
| zyga | om26er a dirty hack might work but that's not the right way | 14:24 |
| zyga | mborzecki for consistency and simplicity | 14:24 |
| zyga | mborzecki it's one to not use aa | 14:24 |
| zyga | mborzecki: it's something else to special case lots of places | 14:24 |
| zyga | om26er there are the following concerns: | 14:25 |
| zyga | om26er: hosts provides some files for "GL" support, those differ across hardware and across OSes for the same hardware | 14:25 |
| mborzecki | zyga: shipping apparmor profile without aa is a special case on its own | 14:25 |
| zyga | mborzecki I disagree, many packages ship unused profiles | 14:25 |
| zyga | and offer admins to enable them | 14:25 |
| zyga | I see it as lower cost than special fixes in code | 14:25 |
| zyga | om26er: apps need to load those libraries and find appropriate support files | 14:26 |
| zyga | om26er that's the general problem | 14:26 |
| zyga | now for nvidia specifically | 14:26 |
| zyga | we have two pieces of code, compile time choice, of how apparmor is "provided" | 14:26 |
| zyga | one is assuming everything is in a directory that can be bind mounted | 14:26 |
| zyga | the other assumes that the files are in /usr/lib or similar, and a symlink farm is constructed | 14:26 |
| zyga | those differ in sandbox description required to use them | 14:27 |
| zyga | before I left Canonical I wanted to build a different way that's no longer ugly | 14:27 |
| zyga | and also allow snaps to provide those libraries on some systems | 14:27 |
| zyga | either from snap to host or from snap to other snaps | 14:27 |
| zyga | but also allow the host to describe the files and allow classic host to provide the libraries to snaps | 14:28 |
| zyga | there's some work towards that | 14:28 |
| zyga | notably the export manager is nearly everything required to make that possible, there's still more work required after the manger is merged | 14:28 |
| zyga | but it gives you a way to tell that the host can just export the libraries and the snaps consume them | 14:28 |
| zyga | then snap-confine code can go away | 14:28 |
| zyga | and systems with other packaging, like debian even, can be made to work by adjusting packaging in the os (in debian) without patching snapd | 14:29 |
| zyga | the idea is that the export manager creates a tree of libraries | 14:29 |
| zyga | and the provided no longer matters | 14:29 |
| zyga | it could be provided from snaps later on | 14:29 |
| zyga | but can, most importantly, provided by the host in a way that is not hard-coded in snapd | 14:30 |
| zyga | om26er let me know if you are interested in pursuing that | 14:30 |
| om26er | In our case all the required libraries do live in /usr/lib, these are the one's that I had to copy https://gist.github.com/om26er/b4aaf190f5ce3629067bd18b5ff502f2 | 14:30 |
| zyga | om26er you probably want to build snap-confine with different config option then | 14:30 |
| zyga | it's an acceptable stop-gap even though the code was never tested on tegra | 14:30 |
| zyga | or !x86 "fork" of nvidia | 14:31 |
| zyga | some arm builds are more like x86 | 14:31 |
| zyga | tegra is not IIRC | 14:31 |
| om26er | zyga since I "build" the image, the do have the option to copy the required so files to a location from where snapd could read them. All in all we are looking for a solution that wouldn't break easily | 14:32 |
| zyga | well, as long as you upgrade everything in lockstep that's possble | 14:32 |
| zyga | I would still call it a hack though | 14:32 |
| om26er | So how would a change to snap-confine look like ? | 14:32 |
| zyga | om26er there's a binary choice of nvidia support mode | 14:32 |
| zyga | use the other one | 14:32 |
| zyga | it looks for libs in /usr/lib | 14:33 |
| zyga | the first one bind mounts the whole /usr/lib/nvidiasomething directory | 14:33 |
| zyga | how do you configure snap-confine today? | 14:33 |
| om26er | zyga nothing special, here is the build code that we stole from morphis's project https://github.com/crossbario/meta-snappy/blob/master/recipes-support/snapd/snapd_2.47.1.bb | 14:34 |
| zyga | hmm | 14:34 |
| zyga | I forgot which value is default | 14:34 |
| zyga | you're not explicitly using any | 14:34 |
| zyga | https://github.com/crossbario/meta-snappy/blob/master/recipes-support/snapd/snapd_2.47.1.bb#L68 you need more services | 14:35 |
| pstolowski | pedronis_: would you like to discuss validation set error i pasted earlier? | 14:39 |
| om26er | I think I should probably look at snapd' deb packaging ? | 14:39 |
| pstolowski | pedronis_: or shall I just push to the PR for re-review? | 14:39 |
| om26er | also apart from /usr/lib, the libglvnd vendor directory is also needs to be "read", namely `/etc/glvnd/egl_vendor.d` | 14:40 |
| === pedronis_ is now known as pedronis | ||
| pedronis | pstolowski: if you have time now, yes I would like to discuss a couple of things about it | 14:41 |
| om26er | and `/etc/egl/egl_external_platform.d/` | 14:41 |
| pedronis | pstolowski: they relate also to local vs store snaps | 14:41 |
| om26er | zyga re more services: Which one's do you have in mind ? | 14:42 |
| mborzecki | om26er: reminds me i have this outstanding pr to meta-snappy to review :/ | 14:43 |
| pstolowski | pedronis: ok, coming to standup HO | 14:43 |
| om26er | mborzecki I was planning to pursue that. Especially now that we have apparmor kernel patches for full confinement for multiple platforms. | 14:44 |
| om26er | qemu, linux-raspberrypi-5.4 and linux-tegra-4.9 | 14:45 |
| om26er | ^ of course, those patches are 99% Canonical's, we only fixed minor conflicts etc ;-) | 14:46 |
| mborzecki | om26er: let me take a look at that tomorrow morning and we can thing about taking that further | 14:46 |
| mup | PR snapd#9741 opened: boot: add sealKeyToModeenvUsingFdeSetupHook() <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9741> | 14:47 |
| om26er | sure, sounds good :+1: | 14:47 |
| mborzecki | zyga: kida meh https://paste.ubuntu.com/p/cnRQ7xMgpJ/ i would like to avoid having another configure switch | 14:48 |
| mborzecki | zyga: so in theory distro could decide to not ship the file at all, but then snapd behaves silly again if it finds sufficient kernel & userspace support | 14:49 |
| mborzecki | i think those 2 should be separate, if there's no aa profile for s-c snapd should not try to fix it even if aa is supported by userspace and the kernel | 14:50 |
| mborzecki | heh, type=AVC msg=audit(1607007092.399:196): apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-update-ns" pid=24802 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 14:53 |
| mborzecki | zyga: there's no x in s-c profile for s-u-n :/ so one canno really ship the profile for s-c without enabling other bits | 14:55 |
| * cachio lunch | 14:59 | |
| om26er | I wonder what would happen if I add /var/lib/snapd/hostfs/usr/lib/ to LD_LIBRARY_PATH ? The opengl interface already allow "read" access to quite a few so files there. | 15:00 |
| zyga | om26er tip, use SNAP_LIBRARY_PATH | 15:01 |
| ijohnson | pedronis: thinking about it, for that cloud-init thing, we probably want to _add_ that config key to existing zzzz_snapd.cfg's right? or do you think it's sufficient to just add it to new ones given that this new feature from multipass is the only entity that seems to require it enough to file a bug for us? | 15:02 |
| pedronis | ijohnson: let's start with a fix for new install and then see | 15:03 |
| ijohnson | ack | 15:03 |
| ijohnson | I think I should be able to also write a spread test for this case too given what they have in multipass is for a VM | 15:03 |
| om26er | zyga that kind of "worked". There are still a few so files that the opengl interface does not allow: | 15:13 |
| om26er | libnvdc.so libnvimp.so libnvos.so libnvrm.so libnvrm_gpu.so libnvrm_graphics.so | 15:13 |
| om26er | Would a PR for opengl interface be acceptable ? | 15:13 |
| zyga | om26er that's another aspect why this is hacky and annoying | 15:13 |
| zyga | om26er perhaps, I dont' see why not | 15:13 |
| zyga | it's just not scalable in general | 15:13 |
| om26er | Yeah, I understand it's not scalable, so would definitely love to have a real fix and even help where I can. Wouldn't be fun to have our UI break because Nvidia decided there is now a new .so file required as well | 15:16 |
| om26er | btw: That confined snap, would run on Weston's Kiosk Shell as full screen. (It kind of already works, with a few minor hacks) | 15:17 |
| ogra | erm ... nvidia libs are mapped to /var/lib/snapd/lib/gl usually (and fully accessible by the opengl interface this way) ... you dont need to access hostfs at all | 15:20 |
| zyga | mvo FYI: all workers are shut down,I'll kill the instancenow | 15:20 |
| zyga | ogra not exactly right | 15:20 |
| zyga | it depends | 15:20 |
| ogra | on what ? | 15:20 |
| zyga | on build config | 15:20 |
| zyga | there are two separate nvidia support versions | 15:21 |
| zyga | one does depend on hostfs | 15:21 |
| ogra | the desktop launchers definitely map these libdirs for you automatically | 15:21 |
| ogra | and that usually works very well for desktop and kiosk apps | 15:21 |
| zyga | no, that's not true either | 15:21 |
| zyga | I mean | 15:21 |
| zyga | snapd provides the libraries | 15:21 |
| zyga | helpers just use them | 15:21 |
| zyga | (explicitly) | 15:21 |
| ogra | right and i.e. the gnome extension auto-maps them into the library path | 15:21 |
| mvo | cachio: zyga shut down the other instances now | 15:22 |
| ogra | with its desktop-launch script | 15:22 |
| zyga | ogra that's correct | 15:22 |
| ogra | the only thing i found missing yet was VDPAU in some exotic setups | 15:22 |
| ogra | (interestingly intel ... not nvidia actually ... ) | 15:23 |
| cachio | mvo, nice, I'll start adding more in some minutes | 15:23 |
| zyga | hw support bits are a bit missing in snapd | 15:24 |
| zyga | I hope the export manager unlocks that | 15:24 |
| zyga | as custom hacks cannot scale | 15:24 |
| zyga | mborzecki interesting | 15:25 |
| zyga | yeah, sadly apparmor is used in two ways | 15:25 |
| zyga | implicitly | 15:25 |
| zyga | and explicitly | 15:25 |
| zyga | the explicit part we can control | 15:26 |
| zyga | the implicit one we cannot | 15:26 |
| zyga | but | 15:26 |
| zyga | can you compile snap-confine without apparmor support | 15:26 |
| zyga | so that when snap-update-ns runs, it is not confined either? | 15:26 |
| zyga | mborzecki looking at your diff | 15:27 |
| zyga | do not load profiles | 15:27 |
| zyga | if disabled, just keep them off | 15:27 |
| zyga | otherwise snap-confine _is_ confined anyway | 15:27 |
| zyga | and we don't want it to | 15:27 |
| zyga | out of our set, snap-confine is the only program that uses implicit path-based profile association | 15:27 |
| pedronis | mvo: ijohnson: mborzecki: proposed https://github.com/snapcore/snapd/pull/9742 | 15:28 |
| mup | PR #9742: gadget,o/devicestate: hybrid 18->20 ready volume setups should be valid <Created by pedronis> <https://github.com/snapcore/snapd/pull/9742> | 15:28 |
| ijohnson | pedronis: ack thanks I'll have a look today | 15:29 |
| pedronis | it's just the fix plus some gadget update tests | 15:29 |
| pedronis | to be clear | 15:29 |
| pedronis | but it's a baseline to then try to untangle things | 15:29 |
| mborzecki | zyga: apparmor.service will load the profile when restarted anyway | 15:32 |
| zyga | mmmm | 15:32 |
| zyga | indeedd | 15:32 |
| mup | PR snapd#9742 opened: gadget,o/devicestate: hybrid 18->20 ready volume setups should be valid <Created by pedronis> <https://github.com/snapcore/snapd/pull/9742> | 15:32 |
| mup | PR snapd#9743 opened: daemon: split unsupported buy implementation to its own api_*.go files <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9743> | 15:32 |
| zyga | hmm | 15:32 |
| pedronis | ijohnson: btw let me know if you have questions about my lk comments | 16:16 |
| ijohnson | pedronis: yes I was going through them, I will ask questions in a couple minutes | 16:16 |
| ijohnson | pedronis: instead of Go build tags what do you think of trying to type cast *os.PathError to Unwrap() and if it returns nil, then we do the compat thing, and if it does return non-nil just return it as-is ? | 16:18 |
| pedronis | ijohnson: that also works | 16:19 |
| ijohnson | essentially what Go source is doing here: https://golang.org/src/errors/wrap.go?s=372:400#L4 | 16:19 |
| ijohnson | ok, I think that is more managable | 16:19 |
| ijohnson | it just feels a bit heavy to have an entire set of multiple files per go versions that just have one method | 16:19 |
| pedronis | mvo: cachio: I'm seeing the cla check fail sometimes like this: https://github.com/snapcore/snapd/pull/9736/checks?check_run_id=1493790248 are we missing deps on some agents? | 16:20 |
| mup | PR #9736: o/devicestate: save model with serial in the device save db <Run nested> <Squash-merge> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9736> | 16:20 |
| cachio | pedronis, let me check | 16:20 |
| cachio | pedronis, this ran in canonistack | 16:21 |
| cachio | the old env | 16:21 |
| cachio | I'll monitor the other action jobs to see where it is happening | 16:22 |
| cachio | thanks for the ifno | 16:22 |
| pedronis | mvo: #9730 can be squash merged | 16:34 |
| mup | PR #9730: hookstate: refactor around EphemeralRunHook <Skip spread> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9730> | 16:34 |
| pedronis | #9705 needs 2nd reviews | 16:35 |
| mup | PR #9705: devicestate: add runFDESetupHook() helper <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9705> | 16:35 |
| pstolowski | pedronis: the error struct we discussed still needs to be slightly sophisticated, reason is that AFAIU a snap may be required by multiple validation sets (if they are not conflicting); so, something like map[string]map[string]bool is needed, or map[string][]string ? | 16:35 |
| pstolowski | (for each of: missing, required, wrongrevision) | 16:36 |
| pedronis | []string seems ok | 16:36 |
| pedronis | pstolowski: ^ | 16:40 |
| pstolowski | pedronis: yes, ok | 16:40 |
| ijohnson | pedronis: ok, so I think I have most of your comments handled, but you said something about "maybe we need two level of helpers", that bit is unclear to me, I eliminated backupEnvFile and removed the `if` from partLabelForRoleAndTime so it's now just partLabelForRole and the callers of that function do the appending of ".bin" themselves | 17:12 |
| pedronis | ijohnson: the two level helper is because of my wondering about envFileForPartName, it seems to be used for the actually boot partitions as well | 17:16 |
| pedronis | so the name is off | 17:16 |
| ijohnson | ah I see so that relates to your comment about using envFileForPartName being used in ExtractKernelAssets | 17:16 |
| pedronis | yes, but I had probably a different org in mind, you said you removed backupEnvFile which I didn't quite expect | 17:17 |
| pedronis | but that's ok | 17:17 |
| pedronis | so I don't know if we need two helper or not | 17:17 |
| pedronis | but that name is off | 17:17 |
| pedronis | given usage | 17:17 |
| ijohnson | pedronis: what about devFileForPartName ? | 17:17 |
| pedronis | ijohnson: that sounds ok in principle, I just wonder a bit how envFile looks like atm | 17:18 |
| ijohnson | https://www.irccloud.com/pastebin/bS2PX05E/ | 17:18 |
| cachio | mvo, today is comming 2.48.1 right? | 17:19 |
| ijohnson | envFileForPartName would become maybe devFileForPartName | 17:19 |
| ijohnson | pedronis: thoughts ? | 17:23 |
| mvo | cachio: yes, to beta in ~1h for snapd | 17:24 |
| mvo | cachio: I'm not sure we will do a core release but probably for symetry | 17:24 |
| mvo | cachio: but less urgent | 17:24 |
| cachio | mvo, nice | 17:24 |
| cachio | sure | 17:24 |
| * cachio afk 20mins | 17:26 | |
| pedronis | ijohnson: that looks ok, the bool doesn't read great though | 17:26 |
| ijohnson | yeah I have constants for that though | 17:26 |
| ijohnson | const ( | 17:26 |
| ijohnson | backupEnvFile = true | 17:26 |
| ijohnson | primaryEnvFile = false | 17:26 |
| ijohnson | ) | 17:26 |
| ijohnson | but agreed it's clunky | 17:26 |
| pedronis | devPathForPartName ? | 17:27 |
| pedronis | I think we might also want to acknowledge the reality that envFile is not always/primarely a file | 17:28 |
| pedronis | now that is not exposed anymore because we have Present | 17:28 |
| pedronis | might that should be called envBackstore() | 17:28 |
| pedronis | s/might/maybe/ | 17:30 |
| pedronis | ijohnson: ^ | 17:30 |
| ijohnson | mmm that sounds better | 17:30 |
| ijohnson | let me add that | 17:30 |
| mup | PR snapd#9744 opened: OpenGL interface: Support more Tegra libs <Created by om26er> <https://github.com/snapcore/snapd/pull/9744> | 17:43 |
| ijohnson | pedronis: oh wait actually I have more more question, you mentioned `validate()` in one of your last comments about checking if PrepareImageTime is true that Role is Sole or Recovery, but we don't have a validate() method? | 17:46 |
| ijohnson | did you mean to return an internal error from Present() | 17:46 |
| ijohnson | ? | 17:46 |
| om26er | fyi @zyga https://github.com/snapcore/snapd/pull/9744 | 17:48 |
| mup | PR #9744: OpenGL interface: Support more Tegra libs <Created by om26er> <https://github.com/snapcore/snapd/pull/9744> | 17:48 |
| zyga | looking | 17:49 |
| zyga | om26er replied | 17:49 |
| pedronis | ijohnson: we do on opts | 17:51 |
| ijohnson | oh right I see at that level | 17:51 |
| pedronis | I think it would be always correct, is just that only lk cares | 17:52 |
| pedronis | unless I'm confused | 17:52 |
| mup | PR snapd#9745 opened: [RFC] seed: enable uc20 devmode snaps in dangerous models <Bug> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9745> | 17:53 |
| zyga | om26er look again please :) | 17:57 |
| om26er | sure ;-) | 17:58 |
| mup | PR snapd#9746 opened: bootloader: add check for prepare-image time and more tests validating options <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9746> | 18:08 |
| ijohnson | cachio: CLA check failed again https://github.com/snapcore/snapd/pull/9695/checks?check_run_id=1494398856 | 18:10 |
| mup | PR #9695: bootloader/lk: add support for UC20 lk bootloader with V2 lkenv structs <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9695> | 18:10 |
| === ijohnson is now known as ijohnson|lunch | ||
| mup | PR snapd#9730 closed: hookstate: refactor around EphemeralRunHook <Skip spread> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9730> | 18:13 |
| pedronis | ijohnson|lunch: I'm seeing core20/degraded failing on one of my PRs but it passed before on it and nothing related to it changed, is it flaky? | 19:01 |
| cachio | ijohnson|lunch, updated all the canonistack and prodstack agents and installed the cla dependency | 19:32 |
| cachio | it is really weird it didn't fail before | 19:33 |
| === ijohnson|lunch is now known as ijohnson | ||
| ijohnson | pedronis: hmm I haven't seen it fail, I don't know that it is any more flaky than the nested tests are in general | 20:08 |
| ijohnson | if you have logs that would be good to look at | 20:08 |
| ijohnson | cachio: thanks, I'll let you know if I see it fail anywhere else again | 20:09 |
| cachio | ijohnson, nice ,thanks | 20:13 |
| mup | PR snapd#9747 opened: interfaces/builtin/log_observe.go: allow controlling apparmor audit levels <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9747> | 21:59 |
| pedronis | ijohnson: it failed here: https://github.com/snapcore/snapd/pull/9736/checks?check_run_id=1494221544 it's the saving serial one | 22:03 |
| mup | PR #9736: o/devicestate: save model with serial in the device save db <Run nested> <Squash-merge> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9736> | 22:03 |
| ijohnson | pedronis: thanks I'll have a look | 22:03 |
| pedronis | ijohnson: thx | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!