17:58:53 <paddatrapper> #startmeeting 17:58:53 <MeetBot> Meeting started Thu Jul 2 17:58:53 2020 UTC. The chair is paddatrapper. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:53 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:00 <paddatrapper> #topic roll call 17:59:04 <paddatrapper> Agenda: http://deb.li/oNCD 17:59:13 <pollo> 0/ 17:59:14 <paddatrapper> Please say hi if you're here for the meeting 17:59:19 <tumbleweed> o/ 17:59:21 <olasd> hi if you're here for the meeting 17:59:23 <wouter> I forgot again 17:59:24 <mujeebcpy[m]> hi 17:59:35 <wouter> (actually not, but hey) 17:59:42 <ivodd> hi 18:00:26 <paddatrapper> #topic Action items from last meeting 18:00:43 <paddatrapper> tumbleweed: have you had a chance to create the 4 issues on salsa? 18:00:48 <pollo> heh 18:00:55 <tumbleweed> no! I just thought about that yesterday :P 18:01:07 <paddatrapper> heh no worries 18:01:14 <phls> hi 18:01:16 <wouter> yeah, the issue page is still empty 18:01:20 <paddatrapper> #action tumbleweed to create issues for the 4 pending action items 18:01:54 <paddatrapper> #topic Video Stack 18:02:05 <paddatrapper> pollo: you've been playing around with Vocto? 18:02:10 <olasd> (no progress on my side at all) 18:02:31 <pollo> yes! 18:02:36 <highvoltage> o/ 18:02:55 <pollo> so I did sucessfully run the FOSDEM voctoweb frontend 18:03:12 <paddatrapper> #info pollo successfully ran the FOSDEM voctoweb frontend 18:03:15 <pollo> I think it works well enough and can be easily customized to for our needs 18:03:29 <paddatrapper> awesome 18:03:31 <pollo> my next step would be to re-work their ansible role 18:03:38 <wouter> yeah, it's a bit ugly 18:03:45 <wouter> I looked at doing that a while ago, but meh 18:03:46 <tumbleweed> I spun up a voctocore to play with 18:03:56 <tumbleweed> so, we should stick a voctoweb to it 18:04:01 <pollo> I also managed to playback videos to voctomix from the CLI 18:04:04 <pollo> using "$ voctomix-ingest --video-source file --video-attribs "location=foobar.mkv"'" 18:04:17 <pollo> worked well, but I didn't check audio 18:04:23 <pollo> tumbleweed: yes, that's my next step 18:04:32 <wouter> maybe we should make it possible to control that from the web frontend, too? 18:04:32 <ivodd> the main issue with audio is that it needs to change with the source 18:04:34 <pollo> having that will let me check for audio synx 18:04:37 <ivodd> which is different from our normal setup 18:04:50 <paddatrapper> #info we can play video files using voctomix-ingest, but not tested audio yet 18:04:52 <wouter> ivodd: ah yes, good point 18:05:03 <pollo> ivodd: that can be a command passed to vocto 18:05:06 <paddatrapper> #action pollo to test audio sync 18:05:17 <pollo> it's not very hard to do, we'll need to make presets anyway 18:05:30 <paddatrapper> #action pollo to add voctoweb frontend to video team's voctocore VM 18:05:34 <wouter> pollo: if the pre-recorded talks are available, maybe we could have a link in the voctoweb thing to say "start playing the video now"? 18:05:41 <pollo> wouter: yes, that's the idea 18:05:45 <wouter> i.e., have a list of videos etc 18:05:46 <wouter> right 18:05:57 <wouter> and then that link can try to ensure that audio works, too 18:05:59 <pollo> olasd volunteered to add a list of available recordings to voctoweb 18:06:08 <wouter> cool, so that's great then 18:06:15 <paddatrapper> #action olasd to add a list of available recordings to voctoweb 18:06:16 <olasd> yeah, I'll look at that during sprint (I took friday off of work) 18:06:25 <pollo> that's it for me 18:06:31 <ivodd> paddatrapper: #info we got VMs from infomaniak to host our infra 18:06:41 <paddatrapper> #info we got VMs from infomaniak to host our infra 18:07:09 <olasd> (and Monday 13/Tuesday 14th are vacation days too, which I may use for sprint overflow tasks :P) 18:07:19 <paddatrapper> are there any points in that that need mentioning? 18:07:21 <paddatrapper> tumbleweed: ? 18:07:45 <tumbleweed> busy fighting with the nvidia card in the one VM with a GPU 18:07:51 <tumbleweed> haven't got it to work yet 18:08:02 <paddatrapper> though if we have working Vocto do we need GPUs? 18:08:02 <wouter> tumbleweed: do we need that if we're going to use vocto? 18:08:05 <paddatrapper> heh 18:08:06 <tumbleweed> But, on the flip side, OBS seems to work on llvmpipe, if you throw enough CPU at it 18:08:07 <wouter> I thought it was only necessary for OBS 18:08:18 <tumbleweed> wouter: Still keeping options open there 18:08:24 <wouter> fair enough 18:08:24 <pollo> I think tumbleweed's tests with OBS are worth it 18:08:42 <wouter> though I understand it needs a lot more CPU than vocto does? 18:08:43 <ivodd> OBS needs/wants GPU, vocto doesn't 18:08:49 <paddatrapper> #info GPU instances with nvidia cards don't work as expected at the moment 18:08:52 <pollo> at least for now. I'd still prefer it if we can use vocto, but options are a good thing to have 18:08:53 <wouter> if so, I'd be reluctant to use it if we can avoid it 18:08:57 <tumbleweed> wouter: OBS composites with GL, as I understand it 18:08:59 <wouter> true 18:09:17 <wouter> don't get me wrong, I agree that it's good to test 18:09:27 <wouter> but if we don't resolve the nvidia issues, I'd rather go with vocto than with OBS 18:09:28 <paddatrapper> #action tumbleweed to investigate OBS on the GPU instance, to keep options open 18:09:31 <tumbleweed> so, on the infomaniak VMs 18:09:43 <wouter> even if we can get stuff to work, I would rather have something that doesn't nearly max out our VMs 18:09:53 <tumbleweed> aside from the GPU one, they seem to be on a private v4 network, with NATed public IPs 18:09:58 <tumbleweed> and public IPv6 18:10:10 <tumbleweed> connectivity between them seems reasonable 18:10:22 <tumbleweed> no reason to think we can't use them for all of our infra, at this point 18:10:23 <wouter> didn't zigo say it was 10Gbit? 18:10:33 <tumbleweed> yeah. Although that 10gbit will be shared by other users 18:10:38 <wouter> sure, but still 18:10:50 <tumbleweed> are you saying that's good, or bad? 18:10:51 <paddatrapper> #info infomaniak VMs are on a private v4 network, with NATed public IPs and public IPv6. Good conectivity between them 18:10:58 <wouter> I'm saying it's definitely not bad 18:11:00 <olasd> as long as we don't let wouter use all these 10gpbs for sreview ;p 18:11:05 <wouter> olasd: heh :) 18:11:14 <pollo> tumbleweed: but we'll keep using the DO droptlets for the streaming frontends right? 18:11:16 <wouter> olasd: well, I was thinking here, you know... 18:11:21 <tumbleweed> pollo: may as well 18:11:24 <paddatrapper> I certainly think we should default to infomaniak where possible 18:11:33 <paddatrapper> streaming frontends would not work there for example 18:11:53 <tumbleweed> would we want to spin up a debconf-specific jitsi, there? 18:11:56 <wouter> it's certainly also a good idea to spread streaming frontends across the globe 18:12:06 <paddatrapper> #agreed use infomaniak VMs for video team infrastructure where possible 18:12:23 <paddatrapper> tumbleweed: it would prevent having to mess with the streaming script, so maybe 18:12:27 <highvoltage> it would probably be nice to have jitsi close to voctomix if the machine can handle it 18:12:28 <paddatrapper> the NAT may be an issue though 18:12:39 <tumbleweed> the NAT doesn't seem to have been an issue, yet 18:12:40 <highvoltage> (jitsi and jibri, that is) 18:12:44 <tumbleweed> I was getting several gbps through it 18:12:57 <paddatrapper> tumbleweed: speed isn't the issue, webRTC and Jitsi are 18:13:02 <tumbleweed> I'd guess with some /etc/hosts munging, we can make that all behave 18:13:15 <paddatrapper> maybe, gave up on it last time 18:13:28 <tumbleweed> OK, so that's probably a next action here 18:13:32 <olasd> I'm sure people have managed to run jitsi on public clouds with nated public IPs before 18:13:34 <highvoltage> ah yes at AIMS we set up that one jitsi instance on a machine that also has a private IP but a public IP entirely natted to it and jitsi just couldn't do webrtc at all 18:13:36 <paddatrapper> may just need a proper TURN server 18:13:50 <tumbleweed> want to action me to setup a jitsi? 18:13:57 <paddatrapper> I'm happy to 18:14:03 <paddatrapper> set up enough of them at this point 18:14:14 <pollo> tumbleweed: if you do have time for that, please have a look and Ansible Galaxy and check if we can reuse a role there 18:14:21 <pollo> no point in writing tons of generic code 18:14:25 <paddatrapper> #action paddatrapper to setup a Jitsi VM and add to ansible 18:14:31 <wouter> yeah, I was about to say, might be a good idea to have an ansible something 18:14:37 <tumbleweed> they provide a debian package 18:14:42 <wouter> even so 18:14:45 <tumbleweed> so any existing ansible role may not have much value on top of that 18:14:46 <wouter> you still need configuration 18:14:50 <pollo> it's more complicated then apt install :s 18:14:53 <wouter> oh, that part :) 18:14:54 <wouter> right 18:15:19 <wouter> tumbleweed: do they provide a repository, or just a package? 18:15:24 <paddatrapper> wouter: repo 18:15:33 <pollo> you need to manage TLS certs, prosody, multiple services, etc. 18:15:36 * wouter makes a note to add it to extrepo, then :) 18:15:41 <tumbleweed> but yes, we should look at the ansible stuff 18:15:41 <pollo> and the debian packages are kinda crap 18:15:51 <pollo> they break often 18:16:48 <paddatrapper> Anything else on the video stack, or shall we move on to streaming setup? 18:16:49 <pollo> anyway, I've been burnt by Jitsi in the past and I'm happy others are in charge of it :p 18:17:01 <wouter> pollo: :D 18:17:14 <wouter> paddatrapper: I think we should move on? 18:17:15 <tumbleweed> it's good to get more people familiar with jitsi 18:17:23 <tumbleweed> I certainly learned a bit, adding the voip stuff 18:17:30 <paddatrapper> #topic Streaming Setup 18:17:47 <paddatrapper> #agreed streaming frontends still on digitalOcean 18:18:00 <paddatrapper> #action olasd to try minimize stream delay 18:18:21 <paddatrapper> don't think there is anything else? 18:18:25 <olasd> we've started butting heads on limitations of the nginx geoip module during MDCO so we need to figure a better solution for that 18:18:29 <wouter> don't think so either 18:18:33 <olasd> I think tumbleweed wrote $something 18:18:41 <wouter> olasd: can you expand on that? what's the issue? 18:18:53 <tumbleweed> I did 18:18:55 <tumbleweed> I need to finish it 18:19:08 <tumbleweed> stilll stuck on the maxmind license 18:19:16 <olasd> wouter: the geoip module shipped with nginx only supports the old database format, which maxmind has stopped providing free of charge 18:19:25 <wouter> oh, okay 18:19:28 <tumbleweed> and the new one has non-distributable terms 18:19:33 <tumbleweed> so we can't trivially ansible distributing it 18:19:39 <paddatrapper> #info the geoip module shipped with nginx only supports the old database format, which maxmind has stopped providing free of charge 18:19:44 <tumbleweed> (see the debian-legal thread) 18:19:47 <wouter> so, essentially, we should move to something not geoip I guess? 18:20:02 <olasd> tumbleweed: well it's not that different from the blackmagic situation 18:20:06 <tumbleweed> yeah 18:20:09 <wouter> (would be cool if we could have a database that knows about routing distances rather than country...) 18:20:31 <ivodd> well, we don't need to go over all the details in this meeting 18:20:43 <paddatrapper> tumbleweed: do you want an #action for this? 18:20:45 <wouter> well, that's called "anyrouting", I guess, but that would get us too far 18:20:47 <wouter> er 18:20:50 <wouter> anycast, I mean 18:21:00 <tumbleweed> paddatrapper: sure, give me an action to finish this 18:21:11 <olasd> I can also stare at it during sprint 18:21:14 <tumbleweed> I'll distribute the geoip db from people.debian.org, like olasd, probably :P 18:21:22 <paddatrapper> #action tumbleweed to find a solution to the geoip issue 18:21:33 <olasd> tumbleweed: or from the streaming backend 18:21:40 <olasd> (just wget it once) 18:21:44 <tumbleweed> yeah 18:21:46 <paddatrapper> #action Advice/training for directors (/talkmeisters) 18:21:58 <olasd> who's advice/training? :P 18:21:59 <wouter> paddatrapper: didn't you mean to topic that? 18:22:15 <paddatrapper> wouter: yes, that is the next point on the agenda 18:22:16 <wouter> (maybe undo this one first...) 18:22:26 <paddatrapper> #undo 18:22:26 <MeetBot> Removing item from minutes: <MeetBot.items.Action object at 0x157f850> 18:22:29 <paddatrapper> urg 18:22:34 <paddatrapper> #topic Advice/training for directors (/talkmeisters) 18:22:38 <wouter> :) 18:22:39 * paddatrapper needs coffee 18:22:39 <nattie> hello! 18:22:56 * pollo frowns at the idea at this hour 18:22:58 <pollo> :P 18:23:06 <paddatrapper> or sleep :P 18:23:18 <paddatrapper> at this point either would work 18:23:20 <wouter> didn't we say we wanted to decide on which recording stack we're going to have first, before thinking about training? 18:23:29 <pollo> we did do some work on this after the last meeting 18:23:40 <wouter> and since we're not quite decided yet... 18:23:44 <wouter> oh, okay 18:23:52 <paddatrapper> #link https://storm.debian.net/shared/iVvMB3RMXFtTen_jbtZ_FIh0-Ob54DaYvXvxaZx7_Ls 18:24:18 <paddatrapper> pollo: what still needs doing on it? 18:24:27 <paddatrapper> I assume technology specific stuff 18:24:41 <paddatrapper> #undo 18:24:41 <MeetBot> Removing item from minutes: <MeetBot.items.Link object at 0x1365210> 18:24:46 <paddatrapper> that link is for presenters 18:24:58 <paddatrapper> tumbleweed: do you have the directors, etc training link? 18:25:34 <pollo> ah, I confused the two then, I don't think we did work on that one yet for the reasons wouter mentionned 18:25:40 <paddatrapper> ok cool 18:25:54 <tumbleweed> I don't think we had a pad for training yet 18:26:09 <paddatrapper> #agreed will only start working on training for directors once video stack is finalized 18:26:11 <tumbleweed> offtopic, but: Issues created: https://salsa.debian.org/debconf-team/public/data/dc20-online/-/issues 18:26:17 <wouter> \o/ 18:26:22 <paddatrapper> #topic Advice/training for presenters 18:26:27 <wouter> (and not offtopic) 18:26:33 <paddatrapper> #link https://storm.debian.net/shared/iVvMB3RMXFtTen_jbtZ_FIh0-Ob54DaYvXvxaZx7_Ls 18:27:13 <paddatrapper> does anything still need to be added there? 18:27:16 <wouter> I think that looks like a good idea 18:27:22 <pollo> we should start putting this in LaTeX and push it somewhere on salsa 18:27:30 <wouter> maybe limit to just one codec though 18:27:37 <wouter> ideally the codec we'll be using for live streaming 18:27:42 <paddatrapper> nattie: I seem to recall you and I offering to edit and compile that? 18:27:49 <tumbleweed> wouter: don't think the codec really matters 18:27:49 <pollo> or pandoc +md -> LaTeX 18:27:56 <nattie> paddatrapper: yeah, i think so 18:27:56 <tumbleweed> sphinx, like our other docs 18:28:04 <tumbleweed> wouter: it'll be going through voctomix 18:28:04 <paddatrapper> +1 for sphinx 18:28:07 <wouter> expecting vocto to transcode VP9 -> mp4 at live speeds might be expecting too much? 18:28:08 <pollo> ah, that's not a bad idead :0 18:28:24 <tumbleweed> wouter: that's not how vocto works 18:28:27 <wouter> or am I just being a pessimist here? 18:28:33 <tumbleweed> the ingest will decode to raw video, and give that to vocto 18:28:40 <wouter> oh, okay 18:28:42 <tumbleweed> the recording will encode to something 18:28:45 <tumbleweed> the stream will encode to something 18:28:48 <paddatrapper> #action paddatrapper to edit and compile presenter advice to video-team docs 18:28:56 <paddatrapper> #action nattie to edit and compile presenter advice to video-team docs 18:28:58 <wouter> so we run the ingest on a different VM from the voctocore one then? 18:29:13 <tumbleweed> maybe? maybe note 18:29:22 <tumbleweed> the ingest is almost free, it's just decoding video 18:29:41 <tumbleweed> and bandwdith into vocto 18:29:45 <paddatrapper> we should probably test and see 18:29:45 <wouter> yeah, okay, I just thought vocto would be transcoding, but if that's not the case, no worries then 18:29:47 <tumbleweed> probably makes sense to do it on the core VM for that reason 18:29:50 <wouter> and we have 10Gbit there, so yeah 18:30:19 <paddatrapper> #topic Any other business 18:30:32 <wouter> so, yeah 18:30:44 <wouter> zigo said that there is the possibility for block storage 18:30:47 <wouter> do we want to use that? 18:30:49 <pollo> it'll certainly be easier to have voctoweb run ingest shell commands if it's on the same host as the voctocore 18:31:02 <olasd> going back on the video stack topic: we need to make sure the core vms can be allocated enough disk space for 1/ having the pre-recorded videos stored; 2/ doing the voctocore recordings 18:31:06 <wouter> I can make SReview use block storage semi-directly, which could speed things up slightly 18:31:12 <CarlFK> wouter: vocto (like what is in the voc repo/package" is like an audio mixer - it has electroncic and a UI, but no mics or speaker hardware. all that needs to be plugged in 18:31:29 <paddatrapper> #info there is the possiblity for block storage for the infomaniak VMs 18:31:31 <wouter> CarlFK: right 18:31:58 <wouter> essentially, I'm querying whether we want to run SReview on vittoria or at infomaniak 18:32:05 <wouter> and if the latter, whether we use block storage or NFS 18:32:20 <paddatrapper> #agreed we need to make sure the core vms can be allocated enough disk space for 1/ having the pre-recorded videos stored; 2/ doing the voctocore recordings 18:32:21 <wouter> I should note that I haven't used the block in anger yet, so 18:32:35 <wouter> block storage* 18:32:42 <wouter> what do people think? 18:32:56 * tumbleweed sees what storage options infomaniak has 18:33:04 <olasd> I don't know how to record to "block storage", whatever that is 18:33:12 <paddatrapper> can anything else use block storage directly? (aside from sreview) 18:33:13 <olasd> so we'll have to do a file transfer either way 18:33:27 <wouter> olasd: block storage is essentially Amazon S3 and lookalikes 18:33:29 <tumbleweed> they'll go up to 2TB 18:33:42 <ivodd> wouter: that sounds overly complex for little gain 18:33:49 <olasd> wouter: yeah, I don't know how to record to that; I don't think ffmpeg has a s3 output, nor gstreamer? 18:34:09 <ivodd> if we can get vms with enough disk space, that should be easier 18:34:17 <ivodd> and 2TB should be enough 18:34:19 <DLange> you can mount that as a filesystem (s3fs) 18:34:22 <wouter> ivodd: I don't think it is complex, but meh 18:34:23 <DLange> just sayin 18:34:39 <tumbleweed> DLange: sreview is quite I/O heavy 18:34:41 <ivodd> wouter: you wanted an opinion from someone else... 18:34:51 <wouter> also, modern SReview has sreview-copy which transparently copies into S3 if wanted 18:34:55 <olasd> DLange: I wouldn't want to chance live recordings on a fuse backend 18:34:59 <wouter> ivodd: sure 18:35:03 <CarlFK> pollo: can you point me to a wiki where I can make notes about playing videos? (I hope I didn't miss this last week) 18:35:18 <DLange> I can just tell you it works better than NFS 18:35:24 <tumbleweed> CarlFK: https://salsa.debian.org/debconf-team/public/data/dc20-online/-/issues/3 18:35:27 <DLange> so if only these two are your choices... 18:35:32 <olasd> DLange: that's a low bar to pass 18:35:38 <DLange> olasd: full ack 18:35:38 <CarlFK> tumbleweed: thanks 18:36:03 <phls> will content team ask presenters if they want make live streaming or send recorded talk? 18:36:20 <tumbleweed> phls: I think they'll strongly encourage them to record 18:36:34 <wouter> okay, was just idly wondering, but I guess if it makes the streaming side of things more complex, it's probably not worth it 18:37:00 <tumbleweed> wouter: hrm, how does it relate to streaming? 18:37:13 <wouter> tumbleweed: er, I meant the recording side of things 18:37:15 <olasd> tumbleweed: s/streaming/recording/ 18:37:17 <olasd> right 18:37:25 <paddatrapper> #agreed we won't use block storage for recording, as it makes things more complex 18:37:26 <CarlFK> he wants to plug the tape recorder into the line out of a powered speaker :D 18:37:45 <wouter> CarlFK: well, it is how FOSDEM does things 18:37:51 <wouter> (the live stream is recorded) 18:37:58 <CarlFK> see! 18:37:59 <wouter> and yes, that's crazy and has shitty downsides 18:38:09 <paddatrapper> Any other business? 18:38:24 <wouter> still want to know whether to run sreview on vittoria or at infomaniak 18:38:47 <wouter> even if we don't do the block storage, it might still be a good idea (or not) to run SReview at infomaniak at one of the VMs there 18:38:53 <paddatrapper> probably infomaniak would be good? 18:39:00 <tumbleweed> wouter: when do you want to start setting up sreview? 18:39:03 <paddatrapper> makes file transfer easy 18:39:14 <tumbleweed> paddatrapper: hrm? 18:39:14 <olasd> we'll want to archive the recordings on vittoria, the infomaniak offer is time-limited 18:39:17 <wouter> tumbleweed: eh, haven't thought of that yet :) 18:39:26 <paddatrapper> tumbleweed: s/easy/fast 18:39:37 <wouter> olasd: yeah, sure, but I'm mostly concerned about massive file transfers during the conference 18:40:07 <wouter> tumbleweed: I could probably start off slowly if the VMs at infomaniak are going to stick around until debconf 18:40:24 <tumbleweed> zigo didn't want us to consume vast VMs for months 18:40:30 <wouter> (on a side note, I could also fix the bugs in ansible around SReview that I have been sitting on since dc19...) 18:40:43 <tumbleweed> so it'd probably make sense to delay creating the big 2TB VM for a while (unless he's OK with that) 18:41:04 <wouter> I'd think we'd want that one to be an NFS server and nothing else? 18:41:10 <tumbleweed> I guess all the sreview stuff is ansibled enough that we don't need to be worrying abuot this right now 18:41:21 <wouter> you'd guess slightly wrongly ;) 18:41:27 <tumbleweed> heh 18:41:28 <olasd> 2TB is also probably more than we need; are we splicing the original recordings or are we recording our playback? 18:41:31 <wouter> most of it is ansibled fine, but some of it is slightly buggy 18:42:01 <wouter> it would be cool if I could work on this a bit more while I have VMs that are going to stay around for more than a debconf 18:42:01 <tumbleweed> olasd: presumably we're recording our playback, for our sanity? 18:42:20 <olasd> tumbleweed: I don't know, which is why I'm asking ;) 18:42:20 <paddatrapper> Also splicing isn't well supported 18:42:56 <olasd> anyway, nothing further that *needs* discussing now from me 18:43:03 <wouter> because usually I go "don't have the time to fix this now, I'll do it manually", and then things like https://salsa.debian.org/debconf-video-team/ansible/-/issues/40 happen... 18:43:26 <wouter> I think we should be recording our playback 18:43:41 <paddatrapper> #agreed we will record our own playback 18:43:43 <ivodd> it would be nice if you could use the source instead 18:43:46 <wouter> mostly because SReview assumes an uninterrupted timeline 18:43:52 <tumbleweed> wouter: they go up to 32 core. would you just want a single VM for sreview then? 18:43:54 <ivodd> that way, the video could be released immediately when the talk ends 18:44:05 <tumbleweed> ivodd: then you lose Q&A 18:44:08 <ivodd> but that's "nice to have", not a requirement 18:44:11 <wouter> tumbleweed: wow, yeah, that's more than enough 18:44:17 <ivodd> tumbleweed: I'm talking for talks where there is no live q&a 18:44:31 <wouter> ivodd: mmm, good point 18:44:32 <tumbleweed> ivodd: sure, we could publish those directly 18:44:42 <tumbleweed> probably bypassing sreview entirely 18:44:49 <ivodd> maybe sreview can do it 18:44:58 <ivodd> (if I can find the energy to look at it again) 18:45:01 <wouter> it shouldn't be too hard to make it bypass the review cycle 18:45:24 <pollo> wouter: zigo did ask us to try to use as few resources as possible though, as a 32 cores VM means racking a server for them or something 18:45:51 <wouter> pollo: I'm not going to actually use the cores, but I don't think he's going to kill me if I end up running ansible on it a few times? 18:45:57 <wouter> I'll double-check with him to be sure 18:46:03 <wouter> zigo: ^^ ;-) 18:46:06 <wouter> (there, done ;-P) 18:46:07 <tumbleweed> yeah, let's have that discussion with him outside this meeting 18:46:24 <paddatrapper> #action wouter to talk to zigo about VM resource use 18:46:34 <paddatrapper> #topic Upcoming meetings 18:46:44 <wouter> can you also #action me about bypassing the review for prerecorded talks? 18:46:50 <paddatrapper> #undo 18:46:50 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x140ca10> 18:46:53 <ivodd> wouter: we don't want to bypass the review 18:47:00 <ivodd> we want it to be (slightly) different 18:47:05 <wouter> well, that 18:47:10 <tumbleweed> bypass recording, essentially 18:47:11 <paddatrapper> #action wouter to work on review for prerecorded talks 18:47:17 <wouter> thx 18:47:20 <paddatrapper> #topic Upcoming meetings 18:47:23 <paddatrapper> Next week Thursday @ 18:00 UTC? 18:47:28 <nattie> sure 18:47:42 <tumbleweed> yeah 18:47:45 <paddatrapper> #agreed Next IRC meeting - Thursday 9 July @ 18:00 UTC 18:47:54 <wouter> wfm, mostly 18:48:08 <paddatrapper> #info Online sprint is 10-12 July 18:48:24 <tumbleweed> it's a long weekend here, this weekend ('murica day, basically) 18:48:25 <ivodd> according to olasd, also 13/14 ;) 18:48:29 <tumbleweed> so I'll be hacking 18:48:38 <olasd> ivodd: t-t-t 18:48:44 <wouter> not sure yet whether I'll have a lot of time, but I can see 18:48:49 <olasd> I said /overflow/ 18:49:08 <paddatrapper> #info can tentatively aim for some video test runs on the weekend of 17-19 July 18:49:25 <paddatrapper> #endmeeting