04:11 <isd> Reminder: office hours tomorrow

13:31 <abliss> i managed to get Matrix up and running last night, with autologin using sandstorm credentials, and multiple users chatting with each other inside the grain. No federation or outreaching plugins yet.

13:31 <abliss> but i think it's just about up to parity with SandChat (except for a long grain startup time) now

13:32 <JacobWeisz[m]> Nice

16:55 <abliss> maybe we can chat on tonight's call about public apis for grains.

16:56 <abliss> and/or device drivers for outgoing non-httpGet network calls (e.g. irc)

18:35 <isd> Awesome!

18:49 <isd> abliss : add it to the agenda

19:18 <JacobWeisz[m]> Ian, how hard is disabling TLS 1.0/1.1 support?

19:24 <isd> Looking at it now. I think it's a one-liner

19:24 <isd> Though maybe we should push this into libkj's rather than doing it in sandstorm.

19:24 <kentonv> JacobWeisz[m], add `options.minVersion = kj::max(kj::TlsVersion::TLS_1_2, options.minVersion);` around here https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/gateway.c++#L943

19:24 <isd> ^ kentonv?

19:25 <kentonv> yeah I was about to say that... probably KJ should be updated

19:25 <kentonv> to change the default

19:25 <kentonv> since KJ claims to automatically choose a non-broken version

19:26 <kentonv> we should review the default cipherList too

19:26 <kentonv> see if the recommendations have changed

19:26 <JacobWeisz[m]> I'd like to close a really old issue about the built in server getting an A or A+ rating, but allowing the old versions caps it at B.

19:27 <kentonv> yeah I saw

19:27 <kentonv> https://github.com/capnproto/capnproto/blob/master/c++/src/kj/compat/tls.c++#L506

19:29 <kentonv> here I'll update it

19:41 <kentonv> https://github.com/capnproto/capnproto/pull/992

19:53 <isd> kentonv: thoughts on un-bundling clang? I think most people's system compilers should be able to handle the C++ we'ere using these days.

20:26 <abliss> ok, so i've gotten myself a bit tangled up by switching too often between vagrant-spk and spk. assuming i have all my stuff in .sandstorm/, how does a regular 'spk dev' know to mount the `..` directory as `/opt/app/`? is that defined somewhere? doesn't seem to be in my source map.

20:27 <abliss> ok nevermind i got it, my sourceMap was messed up

20:48 <abliss> now having troubles with python venv that show up on a real spk pack, but not in spk dev. Stuff about PYTHONHOME and locale encoding. sound familiar to anyone?

20:49 <abliss> `Could not find platform independent libraries <prefix>`

20:49 <abliss> `# Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]`

20:55 <abliss> so, wait, `vagrant-spk dev` expects to be run from the parent dir of `.sandstorm`, but it expects `.sandstorm/sandstorm-pkgdef.capnp` to have a `.` in the source map (referring to the parent dir)? whereas `spk dev` expects to be run in the same dir where `sandstorm-pkgdef.capnp` lives, and `.` refers to that same dir?

20:58 <abliss> ... so if you want to mix and match, you have to always pass `spk dev -p.sandstorm/sandstorm-pkgdef.capnp`, is that it?

20:58 <JacobWeisz[m]> I think so? The whole .sandstorm directory thing is a vagrant-spk specific convenience.

20:59 <JacobWeisz[m]> I didn't think spk even insisted on /opt/app either.

21:00 <JacobWeisz[m]> I thought it used wherever you put it in the original file system.

21:01 <abliss> i think it just uses /

21:01 <JacobWeisz[m]> It might, I think I saw that when entering grains

21:02 <abliss> where does vagrant-spk store the /opt/app info?

21:03 <JacobWeisz[m]> I am not sure. I found it difficult/frustrating to use spk with an app built for vagrant-spk.

21:04 <isd> I believe /opt/app is an artifact of the Vagrantfile. IIRC it's set up as a shared folder, so /opt/app in the VM maps to your working directory on the host.

21:04 <isd> It would be nice to bring those more in-line with one another.

21:04 <JacobWeisz[m]> That sounds right

21:06 <JacobWeisz[m]> The one I find silliest is the different keyring locations.

21:07 <isd> Yeah. Maybe we could find a way to migrate vagrant-spk from what it does now to using the same location as raw spk

21:09 <isd> Ah, there's comments in the source about the why

21:11 <isd> Maybe we should just move spk over using the location used by vagrant-spk, or have it search both locations.

21:11 <isd> ..and prefer the one that works with vagrant-spk

21:11 <JacobWeisz[m]> vagrant-spk's choices are better, IMHO

21:12 <abliss> my vagrant doesn't seem to be port-forwarding into the vm. the vm is running, and sandstorm is listening on 6080 inside, but nothing's listening from the outside (i changed config.vm.network to use host=6090 so as not to conflict with the host). any debugging ideas?

21:14 <JacobWeisz[m]> Current vagrant-spk uses 6090 inside, you know.

21:14 <isd> Hm, are you running vagrant-spk master?

21:15 <abliss> oh yeah, i think i started this one before updating

21:15 <abliss> oh wait, i just restarted vagrant and apparently it's using 60808

21:15 <abliss> seems to be ignoring my Vagrantfile

21:16 <abliss> oops,, no, i was looking at the wrong Vagrantfile buffer! ignore me, sorry

21:21 <abliss> so even if you use `spk-dev -p`, you still seem to have the question of what to put as your start command. for spk-dev it should be e.g. `.sandstorm/launcher.sh` but apparently for vagrant-spk it shoudl be `./launcher.sh` ?

21:40 <isd> Looks like vagrant-spk runs spk from within the .sandstorm directory

22:03 <abliss> (omg, debian stretch still has python 3.5??)

22:03 <kentonv> stretch is like 3 years old isn't it?

22:04 <JacobWeisz[m]> vagrant-spk should work fine with a newer image. Some stacks might not setup correctly though.

22:05 <abliss> https://wiki.debian.org/LTS has stretch as the newest LTS (2020-2022)

22:05 <kentonv> Buster is the latest (released... last year)

22:06 <kentonv> dunno why it isn't listed there

22:07 <JacobWeisz[m]> And I intend to switch vagrant-spk to buster this year. Haven't done the work yet though.

22:21 <abliss> hm, ubuntu 20.04 LTS apparently comes with py3.8

23:05 <mokomull> kentonv: because buster's still in the normal support cycle, responsibility for it hasn't been passed onto the LTS team yet

23:06 <kentonv> yeah that's what I figured... it _will_ be LTS eventually but it's not yet because it's currently current.

23:07 <kentonv> (many other projects label a version as "LTS" immediately upon release)

23:13 <mokomull> yeah I have to reverse-engineer the Debian project structure every time I have to do any real sysadmin work on my boxes :P

23:16 <simpson> Yep. Can't wait to switch over my last Debian machine.