[05:19] <zyga> Good morning
[05:25] <mborzecki> morning
[05:37] <zyga> Hey :-)
[06:05] <zyga> Coffee
[06:14] <mborzecki> zyga: hey
[06:19] <zyga> Hello mvo
[06:19] <zyga> I’ll start around 9
[06:19] <zyga> Need to take a walk and get kids up
[06:21] <mvo> hey zyga
[06:21] <mvo> zyga: sure thing
[06:34] <mborzecki> mvo: hey
[06:34] <mvo> hey mborzecki
[06:34] <mborzecki> added a topic about the tool for building images: https://forum.snapcraft.io/t/snapd-tool-for-building-ubuntu-core-images/12118/1
[06:34] <mvo> mborzecki: nice
[06:36] <mvo> mborzecki: looks interessting, we will need to adjust it a bit and then it seems like we can use it for core20 in the recovery to do the initial disk setup
[06:38] <mborzecki> mvo: sure, it'd be intersting to see it used :)
[07:11] <pstolowski> morning
[07:11] <mvo> hey pstolowski ! good morning
[07:11] <zyga> and I'm working now
[07:12] <zyga> proper hellos :)
[07:16] <mborzecki> pstolowski: hey
[07:24] <zyga> mborzecki: question, do you think jamie's comments on https://github.com/snapcore/snapd/pull/7026 warrant removal of the wrappers?
[07:25] <zyga> mvo: ^ perhaps you can decide
[07:27]  * mvo is looking
[07:28] <mvo> zyga: what wrappers exactly? sc_error_simple?
[07:28] <zyga> yep
[07:29] <zyga> mainly for https://github.com/snapcore/snapd/pull/7026/commits/b72ff86fb6712f1dc7bb6dca5152120f8f2ed03b
[07:29] <zyga> but also because the case of error without a code is common
[07:29] <zyga> and given that jamie was positive on the error handling I want to keep using this pattern for new code
[07:30] <zyga> so I though to make it shorter
[07:30] <zyga> 2nd one is https://github.com/snapcore/snapd/pull/7026/commits/aad7810aff69dc5427825dc8cb59fc103ff725c4
[07:30] <mvo> zyga: I have not looked at what jamie said, I can do that a bit later. but from what I read so far it seems he simply wants to have the new error handling in a subsequent pr and not distract this "main" pr with it which seems sensible, no?
[07:32] <mvo> zyga: eh, sorry, I did look at what jamie said but I have not looked into the broader context or the things disucssed earlier, thats what I mean, I have limited context so take it with a grain of salt
[07:32] <zyga> mvo: it seems sensible but it is also wasteful since I added it in the same batch along with new error check for newlines
[07:34] <zyga> mvo: shall I remove it and re-propose it?
[07:35] <mvo> zyga: I can look at the bigger picture in a few minutes (need to finish my current task) and we can have a HO if you want. with my limited understand so far my suggestion would be to simply create a new branch with the new error wrappers and change this one to use the current code which is hopefully not too much work
[07:35] <zyga> mvo: I don't want HO, just a path forward
[07:36] <zyga> ok
[07:48] <pedronis> Chipaca: jamesh forced pushed to 7036 and now I am unclear what you actually reviewd
[07:50] <jamesh> pedronis: It was a simple rebase to see if it fixed the CI failure.  I don't think the failure has anything to do with the changes in the branch
[07:50] <pedronis> jamesh: that's not the problem, we do not force push to reviewed PRs
[07:51] <pedronis> it's entirely a process issue
[07:52] <pedronis> degville: hi, have you have some time, could you give a look at all the help text in https://github.com/snapcore/snapd/pull/6848 , it needs another pass from me too
[07:53] <pedronis> s/have you have/when you have/
[07:55] <degville> pedronis: hallo! Yes, of course. I'd been waiting for the pushes to settle down.
[07:55] <pedronis> thx
[08:02] <mborzecki> jq is so nice, too bad when one tries anything other than simple value printing it gets super weird super fast :/
[08:06] <zyga> re
[08:06] <zyga> sorry, big interrupt
[08:15] <zyga> mvo: done now
[08:15] <zyga> mvo: sorry, had some funny situation over here that required a bit of my attention
[08:18] <zyga> a car broke down, the driver was polish but didn't speak english, there's a local guy that speaks english and tries to help him with a car mechanic, but they have no common language to use, so I translated from catalan to english to polish along with the help of the guy who knew catalan and english
[08:18] <zyga> we live opposite to a car shop
[08:19] <zyga> there must be a movie plot with similar situation somewhere but it just happened for real :)
[08:36] <mborzecki> https://github.com/snapcore/snapd/pull/7041 is quite simple, bulk of the diff is tests
[08:37] <zyga> looking
[08:37] <mvo> zyga: ack, in a meeting right now
[08:38] <zyga> mvo: no worries, all good
[08:49] <mborzecki> got to run an errand, back in 1.5h or so
[08:50] <mborzecki> btw. https://github.com/snapcore/snapd/pull/7044 is a very simple review, pstolowski maybe you could take a look?
[08:50] <pstolowski> mborzecki: sure
[08:50] <mborzecki> pstolowski: thanks!
[08:51] <pedronis> mborzecki: I did a first pass over 6890, I honestly struggled a bit to follow what goes on
[08:51] <mborzecki> pedronis: maybe we could do a HO once i get back?
[08:52] <pedronis> mborzecki: not immediately, you should probably read the comment and see if you can make the code clearer
[08:52] <pedronis> without hand holding the reader
[08:52] <mborzecki> pedronis: ok, will do
[08:53] <mborzecki> got to go
[08:55] <zyga> hmm
[08:55] <zyga> some odd thing on travis
[08:55] <zyga> I get tests that time out after .... 6 mintes
[08:55] <zyga> not run into the log length limit
[08:55] <zyga> just time out
[08:58] <zyga> now the logs are 404
[08:58] <zyga> hmmm
[09:11] <Chipaca> zyga: 6 minutesish might be the timeout for no output
[09:12] <zyga> Chipaca: it was some kind of travis fluke, I force-pushed and we can see what happens now
[09:16] <Chipaca> mborzecki: jq does seem write-only for anything more complicated than a query
[09:16] <zyga> Chipaca: I agree
[09:17] <zyga> it's haskell-level interesting -- as in "what does this syntax do?"
[09:54] <pedronis> Chipaca: +1ed 6848 with some final small comments,  as I said degville should go over the help texts
[09:55] <degville> pedronis: Chipaca: just looking through it now.. I won't be long :)
[10:12] <pedronis> pstolowski: hi, there's a typo blocking spread tests in #6977
[10:13] <mvo> pstolowski: quick question - do we have a forum topic about base: none that I can link to in from the 2.40 release notes?
[10:15] <pstolowski> pedronis: ah, thanks, fixed
[10:16] <pedronis> mvo: we still have a couple of things marked for 2.40 ?
[10:16] <pedronis> 7016 would have also been a candidate for 2.40
[10:16] <pstolowski> mvo: none that i know of
[10:18] <mvo> pedronis: yes, some we can cherry pick, let me mark those
[10:18] <mvo> pedronis: 7016 is marked so that should be fine
[10:18] <mvo> pstolowski: ta
[10:39] <zyga> oooh
[10:39] <zyga> github has a new feature
[10:40] <zyga> allows reviewers to mark files as viewed so future look at a PR is shorter!
[10:46] <pstolowski> very nice!
[10:46] <Chipaca> woo, i now have an actual debian system for poking at
[10:46] <zyga> Chipaca: debian 9?
[10:47] <Chipaca> yes
[10:47] <Chipaca> 386
[10:47] <Chipaca> an old inspiron 8600
[10:47]  * pstolowski lunch
[10:53] <Chipaca> degville: out of curiosity what's the typo in the quotes around 'check-health'?
[10:54] <degville> Chipaca: different quote marks, unless my sight is getting even worse (which could be the case).
[10:54] <Chipaca> degville: ah, we've ben using single quote marks for commands and filenames, and double quote marks for … concepts? quotes? other namey things
[10:55] <Chipaca> e.g. «see 'snap help login'»
[10:55] <degville> Chipaca: ah, ok. thanks - that makes complete sense.
[10:56] <Chipaca> thus «"unhealthy"» vs «'check-health'»
[11:01] <zyga> mvo: you requested  that https://github.com/snapcore/snapd/pull/7026 to be squash merged
[11:01] <zyga> mvo: I would rather preserve the history there, would that be a problem
[11:02] <zyga> mvo: note that you can "cherry-pick" this into the release branch as well, using slightly different git command
[11:02] <zyga> (not patch by patch)
[11:03] <zyga> alternatively I can propose a 2.40 backport if that helps
[11:03] <zyga> mvo: would that be okay?
[11:03] <mvo> zyga: yeah, sure, the issue is only that historically the cherry pick of large amount of patches was cumbersome
[11:04] <mvo> zyga: please share the git magic
[11:04] <zyga> I just google for that and end up at...https://stackoverflow.com/questions/34133628/cherry-pick-a-pull-request-into-a-branch
[11:04] <zyga> I can  open a  cherry-picked PR for 2.40
[11:04]  * zyga does that
[11:04] <jamesh> zyga: from your review comments on https://github.com/snapcore/snapd/pull/6954, I think the only think remaining were your comments about the response.go file.  It is mostly a trimmed copy of daemon's Response type, and I'm not sure how much will be needed by whatever APIs we add.
[11:05] <zyga> jamesh: thank you, I will  look at that shortly
[11:05] <mborzecki> re
[11:07] <jamesh> zyga: on another subject, I was working on a new snapd interface that introduces new mount entries, and initially got failures because I forgot to add equivalent  AddUpdateNS rules on the AppArmor side.  As I was adding this, it got me thinking that we could probably generate those rules if presented with a MountEntry struct
[11:08] <jamesh> it'd reduce the boilerplate, and make sure things like the rules needed for writable mimics were in place
[11:08] <zyga> jamesh: interesting, that would be doable for sure
[11:09] <zyga> jamesh: only question if this is any hard with regards to imports and cycles or what not
[11:09] <jamesh> zyga: I'm not necessarily suggesting that it be done automatically
[11:09] <Chipaca> pedronis: are there any good & pithy examples of what 'blocked' would be used for?
[11:09] <zyga> jamesh: I'll try to review your  branches tomorrow  morning my time
[11:09] <Chipaca> pedronis: I've got «e.g. a service needs to be configured»
[11:09] <zyga> jamesh: or  today  evening perhaps
[11:10] <jamesh> zyga: even with an "AddUpdateNSFromMountEntry" function, I could split out the code that generates the osutil.MountEntry structs into a helper shared by the AppArmor and Mount methods
[11:11] <zyga> jamesh: yeah, that sounds good to me, thank you!
[11:14] <pedronis> Chipaca: that's a typical example, yes
[11:19] <zyga> mvo: https://github.com/snapcore/snapd/pull/7056
[11:22] <zyga> mvo: with this, can I keep the merge commit on the original?
[11:24] <zyga> mvo: could you do a 2nd look on  https://github.com/snapcore/snapd/pull/7053
[11:34] <mvo> zyga: will check after lunch
[11:39] <zyga> thank you
[12:21] <mborzecki> pstolowski: pushed a little tweak to https://github.com/snapcore/snapd/pull/7044 should be much cleaner now
[12:21] <mborzecki> on to the filesystem updater
[12:21] <Chipaca> oh my
[12:22] <Chipaca> somebody is asking me for help to make « curl some-url | bash » work better when the script uses snap
[12:22] <Chipaca> I need to find words with other than four letters to respond
[12:27] <zyga> Chipaca: WAT\0
[12:32] <mborzecki> zyga: looking at the kernel for some hints which namespace modprobe gets executed in
[12:33] <Chipaca> zyga: https://forum.snapcraft.io/t/how-to-run-a-snap-install-verbose-in-terminal/12100/3?u=chipaca
[12:34] <cmatsuoka> route restablished in my backup link \o/
[12:40] <zyga> mborzecki: thanks,  I'm looking at something else, task switched  away from that for a sec
[12:46] <mvo> cmatsuoka: welcome back
[12:49] <cmatsuoka> main link still hitting route dead ends
[12:52] <pstolowski> mhmmmm undoConnect only restores conns and doesn't update repo
[12:53] <mvo> zyga: 7053 needs either squashed or a PR for 2.40 then, whatever you prefer
[13:01] <zyga> mvo: thanks, I made a 2.40 PR  now
[13:01] <zyga> oh
[13:01] <zyga> standup!
[13:01] <zyga> 2fa
[13:07] <mborzecki> zyga: hm https://paste.ubuntu.com/p/qRFHzvkqG8/ looks like it's calling mopdprobe from root ns (?)
[13:16] <zyga> mborzecki: looking
[13:17] <ogra> Chipaca, you should convince jdstrand to have the security team implement a check in bash if stdin comes from curl and just have it refuse to exec ;)
[13:17] <zyga> mborzecki: modprobe, yeah
[13:17] <zyga> I'm not sure how some of the automatic module loading logic works though
[13:17] <zyga> e.g. when you create a socket
[13:17] <zyga> is that systemd doing it
[13:17] <zyga> or kernel doing it
[13:17] <zyga> or what?
[13:18] <Chipaca> ogra: these idiots^Wpeople^Windividuals will find a way to circunvent it
[13:18] <ogra> yeah, sadly
[13:19] <Chipaca> circumvent*
[13:19] <Chipaca> silly Spanish spelling rules overrides
[13:25] <Chipaca> can I change snap so that if it's being run in a pipe from curl, it installs slackware and reboots?
[13:26] <ogra> have it make a screenshot, mirrror that upside down and force-overlay the screen with it
[13:26] <zyga> mborzecki: based on what you linked and what I looked starting from that  it does look  like  it is using the mount namsepace of the current process
[13:26] <ogra> thats immediately visible ... slackware will only kick in on next reboot when the user already forgot he had run that script
[13:26] <zyga> I will run a test to confirm
[13:26] <zyga> but first
[13:26] <zyga> FOOD
[13:26] <zyga> I'm starving
[13:27] <Chipaca> ogra: I could install that http proxy that inverted all images
[13:27] <mborzecki> zyga: i started with the assumption, but the experiment did not behave that way :/
[13:27] <ogra> +1 !!!
[13:27] <mborzecki> zyga: probably some magic inside the vfs handlers
[13:27] <zyga> mborzecki: what did you do in the experiment?
[13:28] <mborzecki> zyga: mounted a shell script over /sbin/modprobe (which is hardcoded path in the kernel), triggered PF_CAN socket
[13:28] <mborzecki> zyga: check the pastebin i linked
[13:29] <zyga> mmm, I see e
[13:29] <zyga> I'll double check
[13:29] <zyga> feels like something that's worth knowing :)
[13:29] <mborzecki> zyga: yeah, i'd like to poinpoint the exact place where we know which ns is that
[13:31] <zyga> yeah
[13:32] <zyga> there's some work queue
[13:32] <zyga> anyway, I'll check after lunch :)
[13:39] <mborzecki> zyga: this is where it ends up: https://elixir.bootlin.com/linux/latest/source/kernel/umh.c#L67
[13:43] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7041 ? the actual code is quite short, the diff is inflated by tests
[13:45] <pstolowski> ok
[13:51] <mborzecki> pstolowski: thanks!
[13:53] <zyga> mborzecki: looking
[13:54] <zyga> following the rabbit  hole
[13:55] <mvo> mborzecki: could you please remind me where the gadget.yaml spec is recorded?
[13:55] <mborzecki> mvo: recorded as in documented?
[13:55] <mvo> mborzecki: yes
[13:56] <zyga> mborzecki: still falling
[13:56] <mvo> mborzecki: the authoritative place what the valid fields are etc
[13:56] <mborzecki> mvo: https://docs.snapcraft.io/gadget-snap that's the only place i know of
[13:56] <mvo> mborzecki: thank you
[13:56] <zyga> mborzecki: maybe this is the key? https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L2183
[13:57] <mborzecki> zyga: try going through the whole path from do_execve, nameidata should be initialized at some point there
[14:02] <Chipaca> pedronis: meeting?
[14:02] <mborzecki> zyga: https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L513 set_nameidata() is called in do_filp_open(), along the path from do_execve()
[14:03] <mborzecki> zyga: maybe we could trace that :)
[14:21] <ackk> jdstrand, hi, is there a snapd release already which contains fixes for #1831473 and #1831457 ?
[14:34] <ackk> mvo, hi is the fix for https://bugs.launchpad.net/snapd/+bug/1819318 in snapd itself or core18? I have snapd 2.39.2+18.04 here but still see the issue
[14:36] <mvo> ackk: if you have an updated deb this should work, if you could provide a quick reproducer I will look into it
[14:36] <mvo> ackk: (reproducer in the sense, what snap did you install on a fresh 18.04 system with updated snapd deb?)
[14:37] <ijohnson> hey zyga I have a wording suggestion on https://github.com/snapcore/snapd/pull/7053 I want to suggest, how do you do a "github suggestion" where you can commit the change directly?
[14:37] <ackk> mvo, ah, I haven't updated the deb, saw that mileston was 2.39 and thought that 2.39.2 would have it
[14:37] <ackk> mvo, I have 2.39.2+18.04 deb
[14:38] <ackk> (from bionic)
[14:38] <mvo> ackk: that sounds right - what snap do you install?
[14:38] <ackk> mvo, just core18
[14:38] <ackk> mvo, but I also tried htop, as per the bug
[14:38] <mvo> ackk: let me look
[14:38] <mvo> ackk: thanks for the report!
[14:38] <ackk> I'll try adding -proposed
[14:39] <ackk> mvo, ty for looking into it
[14:40] <ackk> mhm, no snapd update in proposed
[14:41] <ackk> mvo, fwiw I tried core18 --edge too
[14:44] <mvo> ackk: hm, so here is what I did: booted a fresh ubuntu 18.04 vm, apt install snapd which installed 2.39.2. sudo snap install htop. this installed htop,core18,snapd snaps. snap interfaces then shows me the system interfaces. what am I missing (if anything)?
[14:44] <ackk> I don't have the snapd snap
[14:44] <mvo> cmatsuoka: just FYI, I'm working on making the spike use the core20/edge snap, some issues with that though
[14:44] <ackk> did you install it explicitly?
[14:45] <ogra> note that i did my initial test on a UC18 system ... if you use a VM anyway thats probably easier and faster
[14:45] <mvo> ackk: it got pulled in automatically (this is the fix in 2.39). if this did not work for you, could you please pastebin "snap list" and "snap changes" for me?
[14:45] <mvo> ackk: oh, are you on a UC18 system?
[14:46] <ackk> mvo, no, it's a bionic lxc container
[14:46] <ackk> mvo, lemme start fresh
[14:46] <ogra> (but later others reported the same issue for classic systems with only core18 installed)
[14:46] <mvo> ackk: please pastebin the bits
[14:46] <mvo> ackk: maybe there are some clues there
[14:46] <ackk> mvo, https://paste.ubuntu.com/p/Vshs7827wh/
[14:46] <mvo> ackk: maybe our starting points where different and the fix is incomplete in some way
[14:47] <ackk> mvo, ah so I think I installed core18 *before* upgrading to the fixed version of snapd
[14:48] <mvo> ackk: cool, let me try this
[14:48] <ackk> mvo, mhm, same
[14:49] <mvo> ackk: please pastebin also "snap interfaces" just so that I can get the full picture
[14:49] <ackk> mvo, it's empty
[14:49] <ackk> mvo, so this: is with a brand new container, after running apt update && apt install snapd: https://paste.ubuntu.com/p/WKYJkkcxym/
[14:50] <mvo> ackk: thanks!
[14:50] <ackk> mvo, ty
[14:51] <ackk> mvo, (from an ubuntu-daily:u lxc image)
[14:51] <mvo> ackk: I can reproduce that with core18 no snapd snap gets pulled in so "snap interfaces" is empty. however "snap install htop" pulls in snapd and after that snap interfaces looks sane
[14:51] <ackk> err ubuntu-daily:b
[14:51] <mvo> ackk: I need to look why core18 alone does not pull in snapd
[14:52] <ackk> mvo, confirmed, installing htop pulls in snapd for me as well. in the first run I had htop installed before upgrading snapd
[14:53] <mvo> ackk: aha, yes - I think that makes sense, it will not work this way around
[14:53] <ackk> mvo, would it install it on a refresh?
[14:53] <mvo> ackk: yes
[14:53] <ackk> cool
[14:53] <mvo> ackk: let me double check but pretty sure it will
[14:56] <mvo> cmatsuoka: iirc you had a missing bind mount in build-image.sh during the sprint, how did you fix that? I think I have the same right now :/
[14:57] <ackk> mvo, thanks for looking into it
[14:57] <mvo> ackk: will take some second, needs to find a buggy snapd first
[14:58] <ackk> np
[15:01] <mvo> ackk: just double checked, a refresh of htop pulls in snapd as expected
[15:02] <mvo> (one the snapd deb is updated of course)
[15:02] <ackk> mvo, awesome, so "2.39.2+18.04" is the version  with the fix. right?
[15:02] <mvo> ackk: correct
[15:02] <ackk> mvo thanks!
[15:32] <mvo> pedronis: any suggestions for a common branch name for the spike/uc20 in the various git repos we have? I was thinking simply "20" or do you think it should be spike20 or something more like this?
[15:35] <pedronis> mvo: the problem with 20 is that we might need those for the real code at some point, no?
[15:35] <zyga> ijohnson: hey
[15:36] <zyga> ijohnson: either is fine, suggestions are  usually easier while you review
[15:36] <zyga> ijohnson: if  you want to push directly, by all means do
[15:36] <ijohnson> hey, yeah I tried to figure out how to use suggestions on your PR but couldn't find it in the github ui :-/
[15:36] <mvo> pedronis: yes, that may be a problem, so spike20? I guess we can discuss in the call tomorrow
[15:37] <mvo> cmatsuoka: I have some PRs for you :) this switches our spike to the "real" core20 snap
[15:37] <ijohnson> zyga: also I've been reading through all the mount setup that happens with strict confinement for snap-confine, and some of the comments are out-dated or confusing so I will file a PR to fix some of those comments as best I can
[15:38] <zyga> excellent
[15:38] <ijohnson> zyga: I've also been collecting notes on the mount setup so we at the least you and others can correct my misunderstandings, and possibly also make an updated documentation post on the mount setup for snaps
[15:39] <ijohnson> err that was poorly worded
 zyga: I've also been collecting notes on the mount setup so at the least you and others can correct my misunderstandings, and possibly also make an updated documentation post on the mount setup for snaps
[15:41] <cmatsuoka> mvo: ack, let's do it!
[15:42] <mvo> cmatsuoka: please double check but for me this change was sufficient
[15:42]  * cachio afk
[15:42] <mvo> cmatsuoka: silly question - do we still need initramfs/scripts/local-premount/install now that we have the recovery.go and the ability to do this from the writable ramdisk?
[15:47] <zyga> ijohnson: when do  you think we should document stuff
[15:47] <zyga> ijohnson: perhaps on the forum?
[15:47] <zyga> ijohnson: perhaps in the code (I mean, in addition to current micro comments)
[15:48] <mvo> cmatsuoka: nevermind, I'm silly and reading it wrong
[15:48] <ijohnson> zyga: yeah that's what I was going to do is post on the forum a cleaned up version of my notes, then after review of that either clean up the same post or make a more concise version on the forum to serve as a wiki
[15:48] <ijohnson> zyga: but note my PR with comment cleanup will be separate from that
[15:49] <ijohnson> so hopefully the code comments will continue to be all up to date, and then we will have another place (forum) with updated info
[15:49] <cmatsuoka> mvo: ah I was re-reading the scripts here to see if we were able to create the writable tmpfs from somewhere else
[15:49] <cmatsuoka> mvo: I'll test the whole thing with core20 now
[15:50] <zyga> ijohnson: ok
[15:50] <zyga> ijohnson: you can perhaps look at the 2.26 walkthrough and fix that
[15:50] <zyga> ijohnson: I can make it  a wiki
[15:51] <ijohnson> did you mean 2.36 here? https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843
[15:51] <zyga> yes
[15:51] <ijohnson> I would be fine just updated that as well instead
[15:51] <mvo> cmatsuoka: I'm just silly, I pushed a tiny pr to help silly people like me
[15:52] <ijohnson> zyga: I've been trying to just focus on the code to understand it myself first in case things have changed or are slightly inaccurate, etc.
[15:52] <zyga> ijohnson: though I don't mind a new thread if that helps you organize it
[15:52] <mvo> cmatsuoka: thanks! I think with that in place we can now attack the items in the trello board for uc20
[15:52] <zyga> ijohnson: I'm happy that you do, +1
[15:53] <ijohnson> cool, I'm hoping to have that by my EOD, so probably your morning tomorrow it will be ready
[15:53] <mvo> cmatsuoka: I have dinner now, keep me updated please what you are up to :)
[15:53] <cmatsuoka> mvo: ah haha, the names are really confusing
[15:53] <cmatsuoka> mvo: ok!
[15:53] <mvo> ijohnson: thanks for jumping into this :)
[15:53] <ijohnson> :)
[15:53] <zyga> ijohnson: I started 2nd batch of work now, I'll be around for some time stll
[15:53] <mvo> cmatsuoka: I think it just shows I need more tea but well :)
[15:54] <ijohnson> zyga: ack, I'll ping you here if I have any questions
[15:56] <zyga> ijohnson: my pleasure, happy to have you on board  :)
[16:26] <cmatsuoka> mvo: a fresh install using core20 is working well
[17:02]  * zyga  walk
[17:56] <mvo> cmatsuoka: nice, thank you!
[17:57] <cmatsuoka> mvo: now testing luks device creation
[18:05] <zyga> ijohnson: hey, almost over (my walk)
[18:06] <zyga> Do you have something I can look at
[18:06] <zyga> Or shall we try after eod
[18:06] <ijohnson> zyga: hey sorry I'm at lunch, might be a while before I'm back
[18:08] <ijohnson> zyga: how much longer will you be around?
[18:22] <mvo> cmatsuoka: cool
[18:38] <zyga> ijohnson: probably an hour
[18:38] <ijohnson> k I'll ping you if you're around if not you can take a look when you get time tomorrow
[18:39] <zyga> sure!