17:00:29 #startmeeting FESCO (2016-01-29) 17:00:29 Meeting started Fri Jan 29 17:00:29 2016 UTC. The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:29 The meeting name has been set to 'fesco_(2016-01-29)' 17:00:29 #meetingname fesco 17:00:29 The meeting name has been set to 'fesco' 17:00:29 #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh 17:00:29 #topic init process 17:00:29 Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh 17:00:39 .hello maxamillion 17:00:40 maxamillion: maxamillion 'Adam Miller' 17:00:45 .hello jsmith 17:00:45 I'm here but juggling several things at once 17:00:46 jsmith: jsmith 'Jared Smith' 17:00:50 .hello sgallagh 17:00:51 .hello pnemade 17:00:52 sgallagh: sgallagh 'Stephen Gallagher' 17:00:55 paragan: pnemade 'Parag Nemade' 17:00:59 hello 17:01:15 .hello kevin 17:01:16 nirik: kevin 'Kevin Fenzi' 17:02:30 hi 17:02:36 OK, we've got a quorum :-) 17:02:49 Let's dive in. 17:02:58 #topic Follow-ups 17:02:58 #topic #1532 F24 System Wide Change: NewRpmDBFormat 17:02:58 .fesco 1532 17:03:00 jsmith: #1532 (F24 System Wide Change: NewRpmDBFormat) – FESCo - https://fedorahosted.org/fesco/ticket/1532 17:03:26 We didn't get much followup on the mailing list, except for a short flurry today 17:03:40 I tried answering the questions in the f-d-l thread 17:03:42 maybe postpone voting till next week 17:03:50 is ffesti here? 17:03:56 oh heh 17:03:56 yup 17:03:59 jward-: Two lines up :-) 17:04:02 sorry, i missed your earlier comment 17:04:18 ffesti: is this change already in rawhide? 17:04:34 ffesti: I think there's still an outstanding question about your measurements done with SQLite -- was that with sqlite 2 or 3? 17:04:57 not, yet but I just build the libsolv changes needed locally 17:05:38 how difficult would it be to delay it by a week? 17:05:40 the thing is that the database scoping was done by Lubos Kardos so I cannot really comment on all of the details 17:05:52 also, if we delay it, don't we run the risk of missing the mass rebuild? 17:05:58 a change like this needs to land before that 17:06:05 ah right 17:06:06 yes, thats tuesday 17:06:11 jwb: Good catch.... hmmmmmnnn.... 17:06:16 so i believe it needs a decision today 17:06:23 why does it need to be in a mass rebuild? 17:07:48 It shouldn't need to be 17:08:13 the rpmdb format is supposed to be an internal thing of rpm 17:08:28 reliability of the database is still important 17:08:28 well, to shake out any issues, but yeah, it's not something that would change the packages themselves right? 17:08:29 unfortunately tha is not 100% true 17:09:27 there's really nothing better than a mass rebuild to shake issues out 17:09:33 ffesti: In my mind, given the information I have, this feels a bit rushed. Any info you can give us on how the tooling is coming along, etc.? 17:09:41 it's going to be creating rpmdbs for the buildroots for every package 17:10:11 mass rebuild is done in a non self-populating side tag, which doesn't cause buildroot creation 17:10:30 kalev: uh... what? 17:10:49 every package build needs buildroot no? 17:10:50 * handsome_pirate rolls in and waves 17:11:03 not sure what the exact koji terminology is, but it uses rawhide buildroot 17:11:15 oh. yes 17:11:18 right. 17:11:20 as long as the builders are not updated the buildroots will just use the old format 17:11:27 however, if this change lands in rawhide _before_ the mass rebuild, it will be used 17:11:28 builders are f23. 17:11:55 maybe i'm misremembering how mock works 17:12:16 when builders are installing packages in a build root, they use the host system's rpm, right? 17:12:24 which is F23 17:12:52 so even if it lands in rawhide it shouldn't get used for buildroot creation :) 17:13:10 for some reason i thought buildroot initialization was host initiated, but the subsequent build-dep installation was done with whatever was in the buildroot 17:13:12 yeah, I think the bootstrap of the chroot is going to be host's rpm, then from then on it's inside the chroot ... so it wouuld likely fall back to using the old format unless there's a conversion attempt 17:13:15 but i could be very wrong 17:13:22 jwb: +1 17:13:28 right, the f23 rpm/dnf will be used to make the chroot... 17:13:36 yes, even if we made the F24 rpm automatically convert the rpmdb to the new format it would still work 17:13:37 then the rawhide stuff in it will be used in building. 17:14:12 but, the rpmdb in the chroot will be the old format 17:14:38 the old format will still be supported 17:14:55 why choose a homebrew database format instead of using an established db? 17:14:55 everything else would really be suicidal 17:15:07 (Just as a time check... we're about 15 minutes into this topic) 17:15:20 lkardos looked at quite some implementations and there were issues with all of them 17:15:34 sqlite is extraordinarily widely used .. even my phone uses it 17:15:38 is the new format ready? I got the impression from the email thread that it's still in an exploratory phase ... which made me nervous 17:15:44 ffesti: Is any of that information public? 17:15:45 Such as? 17:15:47 ffesti: not that it is a huge influence, but are other RPM based distributions going to switch to the new db format? 17:15:47 also the new format resembles the libsolv format which we already use in the depsolver (dnf) extensivly 17:15:49 rwmjones: +1 17:15:51 maxamillion: Yes, hence my question about this being a bit rushed 17:15:56 jsmith: +1 17:16:31 What exactly is wrong with sqlite? 17:16:46 the format is fully implemented for quite a while 17:16:48 handsome_pirate: I'm not sure we need to get into that level of detail in this meeting... 17:16:58 we still fixed some issue end of last year 17:17:04 handsome_pirate: that's been discussed on the mailing list thread 17:17:09 to some extent anyways 17:17:14 ffesti: How much testing has it had? 17:17:17 one thing that took a while was getting support into libsolv 17:17:22 IMHO it would have been nice to go with a common format, but I don't think it's up to us to micromanage what rpm devel folks do. ;) 17:17:32 as it does read the rpmdb directly 17:17:36 nirik: +1= 17:17:38 nirik: +1 17:17:41 bleh, I can't type 17:17:58 maxamillion: +1=+1 is the answer :-p 17:18:07 jsmith: :) 17:18:30 jsmith, it so far has only be tested internally but I hope to get packages out for public testing next week 17:18:44 Any other questions? Do we think we're ready for a vote? Kick the can down the road another week? 17:19:50 seems not 17:19:57 * nirik is +1 for it 17:20:01 OK, let's vote. 17:20:19 * jsmith is -1, simply from the fact that it seems rushed 17:20:23 I haven't read up on all of the mailing list thread 17:20:29 jsmith: Please start with a Proposal: 17:20:36 but instead of +1 or -1, a mixed approach might be to ship F24 with the new database format support, but not do any conversions automatically and keep on writing to the old db by default 17:20:39 So it's very clear what a +1 or -1 means 17:20:40 so that interested people would test it if they want to try things out, but regular fedora installations would still keep on using the old format 17:20:50 0 17:21:01 kalev: No one but the RPM maintainers would know or care. 17:21:02 sgallagh: +1 17:21:04 kalev: I'm for this, not that I have a vote 17:21:09 Proposal #agreed to approve the NewRPMFormat change for F24 17:21:26 sgallagh: Some of us would try it out :) 17:21:44 +1 17:21:45 +1 17:21:52 kalev: I'm fine with that :-) 17:22:17 I'm reservedly +1, because pushing it out to F25 would mean that no mass-rebuild would occur and exercise it fully 17:22:33 I think test rpms should have been available so neither -1 not +1, 0 vote 17:22:53 +1 17:23:16 I know number80 is out (in Brussels at FOSDEM) 17:23:28 dgilmore? 17:23:32 dgilmore is also at FOSDEM 17:23:43 Gotcha... 17:23:54 kalev: I'm not sure I know where your vote is on this... 17:25:46 I think I'm +1, but that's with the reservation that I haven't read up on all of the mailing list discussion 17:26:06 OK, we're currently at +1=5 votes, +0=1 vote, -1=1 vote. 17:26:19 I think that means it passes.... 17:26:26 yes :) 17:26:29 #agreed to approve the NewRPMFormat change for F24 17:26:39 #topic #1518 Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled 17:26:39 .fesco 1518 17:26:43 jsmith: #1518 (Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled) – FESCo - https://fedorahosted.org/fesco/ticket/1518 17:26:48 jsmith: Please include the vote count in the #agreed next time 17:26:55 sgallagh: Oh, right... 17:27:02 * jsmith knew he's mess things up 17:27:09 sgallagh: Mind giving us an update? 17:28:53 * jsmith assumes we haven't seen any sort of response from the letter that sgallagh sent 17:28:54 I sent the email privately to some of the Mozilla folks 17:29:13 We got a simple response saying thank you for the detailed explanation and that they'd review it and reply soon. 17:29:27 Proposal: #agreed Wait another week for a reply 17:29:28 That was yesterday; I haven't gotten the full reply yet. 17:29:34 +1 17:29:42 wait for what? 17:29:58 i mean, in terms of the ticket, it's resolved 17:29:59 So yeah, let's take no action here until the conversation proceeds. 17:30:09 jwb: I'm not sure I follow what you mean 17:30:15 we said we'd discuss it with them, we are. we also said we aren't blocking firefox updates while we discuss 17:30:21 so... why is the ticket still open? 17:30:32 jwb: That's exactly what I'm proposing -- that we don't take any action -- but that we revisit next week if there's a reply 17:30:49 Let's just drop the meeting keyword and I'll re-add it if appropriate 17:31:02 Or close and reopen, I don't care which 17:31:09 WORKSFORME 17:31:15 Though the latter will probably annoy Kevin 17:31:53 Proposal 2: #agreed to drop the 'meeting' keyword from this ticket, revisit in the future as necessary 17:32:02 +1 to Proposal 2 17:32:04 Better? 17:32:04 * nirik shrugs. either is fine with me. 17:32:09 I don't think we need to vote on every small thing :) 17:32:12 just make it so 17:32:34 Any objection? 17:32:37 nope! 17:32:39 no 17:32:45 +1 to not voting on everything. Oh wait. 17:33:09 #agreed to drop the 'meeting' keyword from this ticket, revisit in the future as necessary 17:33:13 #agreed to drop the 'meeting' keyword from this ticket, revisit in the future as necessary 17:33:16 There we go... 17:33:27 #topic #1527 rabbitvcs package maintainer not responding 17:33:27 .fesco 1527 17:33:28 jsmith: #1527 (rabbitvcs package maintainer not responding) – FESCo - https://fedorahosted.org/fesco/ticket/1527 17:34:08 In this one, we were going to decide whether to orphan the packager's other packages, if I recall 17:34:23 not to orphan cicku's packages. 17:34:24 well, related maintainer... 17:34:44 they weren't maintainer of rabittvcs, just a comaintainer that didn't respond about it either. 17:35:06 Proposal: #agreed to not orphan cicku's packages 17:35:12 +1 17:35:14 +1 17:35:16 +1 17:35:16 +1 17:35:17 +1 17:35:36 +1 17:35:53 sure. We may have to someday... but I'm fine holding off for now. +1 17:36:00 I'm mildly surprised that we're even considering orphaning because someone on CC didn't reply 17:36:10 #agreed to not orphan cicku's packages (+1:7, 0:0, -1:0) 17:36:22 #topic #1535 quassel maintainer (tuxbrewr) not responding 17:36:23 .fesco 1535 17:36:23 right, what nirik said; we may have to orphan the packages one day, but not on this premise 17:36:24 jsmith: #1535 (quassel maintainer (tuxbrewr) not responding) – FESCo - https://fedorahosted.org/fesco/ticket/1535 17:37:19 so this one they were the maintainer... 17:37:26 should we orphan the rest of their packages? 17:37:27 Right... 17:37:30 quassel is taken care of 17:37:33 https://admin.fedoraproject.org/pkgdb/packager/tuxbrewr/ 17:37:46 lots of sugar packages 17:38:00 acpi and conman 17:38:03 Right... 17:38:13 if there are co-maintainers then no need to orphan now 17:38:22 as a side note, I find it hard to parse the list of package names when each and every one has rpms/ prepended 17:39:18 paragan: Incorrect 17:39:20 thats prep work for us shipping other things like docker containers. 17:39:25 kalev: that was a recent change for namespacing things to prepare for non-rpm build artifacts and deliverables (containers, etc) 17:39:29 that acpi package is useless afaik 17:39:32 We should still orphan and then one of the comaintainers should take over 17:39:38 sgallagh, I think others can take care 17:40:03 okay 17:40:11 Proposal: #agreed Orphan tuxbrewr's remaining packages 17:40:46 +1. (sadly. Hope he's ok and can come back someday) 17:40:51 +1 17:40:58 +1 17:40:59 +1 17:40:59 +1 17:41:16 Given the fact that he's listed as "inactive but still responsive" in the ticket, I'll go +0 17:41:39 jwb? 17:41:47 +1 i guess 17:42:06 huh 17:42:13 #agreed Orphan tuxbrewr's remaining packages (+1:6,0:1,-1:0) 17:42:13 we didn't even cc them on the ticket? 17:42:23 We didn't? 17:42:48 #undo 17:42:48 Removing item from minutes: AGREED by jsmith at 17:42:13 : Orphan tuxbrewr's remaining packages (+1:6,0:1,-1:0) 17:43:01 Anybody want to change their votes given that information? 17:43:03 that may have been my bad; I added this to last week's agenda and didn't CC them :( 17:43:09 Or revisit next week? 17:43:10 yeah, -1 17:43:14 (after adding him, of course) 17:43:18 revisit next week 17:43:21 maybe add to CC and revisit next week, yeah 17:43:23 I missed that too. 17:43:28 I concur 17:43:38 Proposal 2: #agreed revisit next week after adding tuxbrewr to the ticket 17:43:51 yeah, +1 lets wait a week. 17:43:52 +1 to Proposal2 17:43:54 +1 17:43:56 yup, +1 17:44:10 #agreed revisit next week after adding tuxbrewr to the ticket (+1:7,0:0,-1:0) 17:44:18 #topic New Business 17:44:18 #topic #1478 F24 Self Contained Changes 17:44:18 .fesco 1478 17:44:20 jsmith: #1478 (F24 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1478 17:44:26 #link https://fedoraproject.org/wiki/Changes/AtomicStorageClients 17:44:40 #link https://fedoraproject.org/wiki/Changes/Atomic_Developer_Mode 17:44:40 #link https://fedoraproject.org/wiki/Changes/Erlang_18 17:44:40 #link https://fedoraproject.org/wiki/Changes/ibus-fbterm_enhancement_for_ibus_1.5 17:44:40 #link https://fedoraproject.org/wiki/Changes/PingIpv6 17:44:42 #link https://fedoraproject.org/wiki/Changes/QGnomePlatform 17:44:42 #link https://fedoraproject.org/wiki/Changes/QtWebEngine 17:44:51 I'm +1 to all of them 17:45:07 +1 to all of them here as well 17:45:21 i had vague hesitations on the atomic developer mode one 17:45:28 but i can't remember what they were exactly 17:45:44 +1 to all of them 17:45:49 +1 to all 17:45:51 i think it was around how anyone can hit the down key and get root access on it 17:46:52 jwb: Is that to the installed system, or another test environment? 17:46:59 jwb: Didn't that require essentially physical access though? 17:48:29 sgallagh: so? kiosk systems by nature have physical access 17:48:42 turn it off, turn it on, hit down, rollback to somethign with a CVE in it 17:48:45 * jwb shrugs 17:48:50 Proposal: Approve all outstanding self-contained changes, except for Atomic_Developer_Mode. Revisit that one next week after discussion on the mailing list. 17:49:12 i mean, there's a reason the cloud people don't want to include a hardcoded root password in their images. i don't immediately see how this is better 17:49:34 but i'm not a security expert and i'm not willing to block it 17:49:44 jwb: No, that makes perfect sense... hence the reason I think it warrants more discussion. 17:49:56 jwb: I'm glad you brought that angle up 17:50:14 * kalev is clueless in the cloud area 17:50:55 I think I misunderstood that aspect of the atomic dev mode, I was under the impression that the dev mode would be part of a different ostree ref such that you're either running dev mode or you're not ... dev mode offering more a "open" system for tinkering 17:51:47 Given that none of us apparently know exactly how this works, I'm inclined to say agree that we should extend the on-list conversation here 17:52:23 For the record, I am +1 to my own proposal above... 17:52:28 sgallagh: +1 17:52:48 maxamillion: the change makes it read like there are two grub options. normal and developer mode 17:53:16 maxamillion: if you have to opt into a different ostree ref from a normal booted atomic image first... then fine 17:53:29 jwb: ahhh ok, I see what you mean 17:53:30 hrmmmm 17:55:14 Any other votes on the proposal? 17:56:06 I'm going to change mine, +1 to all but the Atomic dev mode and I'm +0 pending more investigation, I'd like to open a dialog with the dev about the security concerns 17:56:23 +1 to jsmith's last proposal to approve all but atomic dev mode this week 17:56:27 +! 17:56:30 er 17:56:31 +1 17:56:43 maxamillion: and i'd like that conversation to maybe be had with an actual security team member 17:56:47 oh, I missed that proposal 17:56:50 jwb: +1 17:56:50 maxamillion: because i am certainly not one 17:56:53 maxamillion: That's essentially the proposal I made 17:56:53 yes +1 to jsmith last proposal 17:56:54 jwb: me either 17:57:04 jsmith: yeah, sorry ... I totally missed that in the backlog 17:57:09 +1 to jsmith's proposal 17:58:06 sgallagh? nirik? 17:58:20 sure, +1 17:58:32 jsmith: I already +1ed that, didn't I? 17:58:50 sgallagh: Not that I saw... but I've messed up all kinds of things today :-p 17:59:20 #agreed Approve all outstanding self-contained changes, except for Atomic_Developer_Mode. Revisit that one next week after discussion on the mailing list. (+1:7,0:0,-1:0) 17:59:33 #topic #1539 Are 32-bit upgrades to Fedora 24 release blocking? Supported? 17:59:33 .fesco 1539 17:59:35 jsmith: #1539 (Are 32-bit upgrades to Fedora 24 release blocking? Supported?) – FESCo - https://fedorahosted.org/fesco/ticket/1539 18:00:14 proposal: defer to next meeting, pending more discussion in the ticket 18:00:22 jwb: +1 18:00:31 +1 jwb's proposal 18:00:42 sure, +1 18:00:46 I'd also like to have mattdm's agreement with whatever we're doing here 18:00:50 +1 to jwb 18:00:54 +1 18:01:25 #agreed defer to next meeting, pending more discussion (+1:6,0:0,-1:0) 18:01:36 #topic Next week's chair 18:01:40 Any volunteers? 18:01:46 are we going to have quorum next week? 18:01:49 * jflory7 knows this is off-topic right now, but would like to share something after all other discussion topics 18:01:59 jflory7: We'll have open floor next :-) 18:02:02 I can take it next week. 18:02:05 Great :) 18:02:06 sgallagh, myself, maxamillion are all going to be at devconf 18:02:11 I should be here... if there's enough others 18:02:15 jwb: Good question... 18:02:20 I should be here next week 18:02:28 * jsmith has no idea where he'll be next week 18:02:36 I will be available next week 18:02:59 I imagine dgilmore will be gone... not sure about number80 18:03:25 Proposal: #agreed Skip next week's meeting, but try to keep up on tickets instead 18:03:31 +1 18:03:42 sure, we can try 18:03:44 I will not actually be at DevConf 18:04:09 So I'll be around. I can run the meeting if we have quorum 18:04:39 sgallagh: sorry, my mistake 18:04:44 If we do not, I'll run it the following week 18:05:00 * nirik is happy too too, but fine with sgallagh taking it. 18:05:20 So should we shoot for a meeting next week, and if we don't get quorum, punt? 18:05:42 Proposal 2: #agreed try for quorum next week, othewise punt to Feb 12th 18:06:01 (with sgallagh as next week's chair) 18:06:15 or the next chair, whichever week it ends up being 18:06:15 We don't need to vote on this 18:06:30 yes no need to vote on this 18:06:31 #agreed sgallagh to chair the next meeting 18:06:41 #topic Open Floor 18:06:49 jflory7: Go ahead, please :-) 18:06:51 I have something after jflory7 18:07:04 nirik probably already knows what I'm about to say. ;) Anyways... 18:07:07 I know there was just recently a new FESCo elected, but many of you are either returning members, have served before, or have a good idea of what's going on in Fedora, so this should still apply. The CommOps team is helping sub-projects and groups put together a 2015 "Year in Review" post, which includes a few highlights from 2015 and a few goals for 2016. It would be fantastic to have a Year in Review from FESCo. 18:07:17 See the announcement here: https://communityblog.fedoraproject.org/share-your-year-in-review-with-fedora/ 18:07:27 See other examples of Year in Reviews here: https://communityblog.fedoraproject.org/tag/year-in-review-2015/ 18:07:28 eof 18:07:34 that's a neat idea 18:08:37 I'm obviously new to FESCo, but I think it's a good idea 18:09:36 Anybody want to volunteer to take point on writing something up? 18:09:47 These posts can be as simple or detailed as each group wishes. The set minimum is three highlights from 2015 and at least one goal from 2016. But more are definitely welcome. 18:10:16 /me hit his "wordy message from FESCo" quote for the first quarter already :) 18:10:22 s/quote/quota/ 18:10:31 There's also a template in that first article that makes the writing part easy, it's just coming up with the goals and highlights that should be the thinking part. :) 18:11:52 * nirik thinks it's a great idea, but doesn't have time to be point on it. 18:11:56 My goal is to do a better job of running the meeting next time :-) 18:12:29 jflory7: How about we take it under consideration, and hopefully someone will have time/inclination to tackle it. 18:13:17 jsmith: That sounds great to me. Any of you are welcome to ping me or #fedora-commops at any time when you're ready to write or have questions. :) 18:13:26 Sounds good :-) 18:13:29 We're hoping to finish this up by mid-February at the latest 18:13:42 OK, great. 18:13:55 I have to run now -- thanks FESCo! 18:13:59 sgallagh: You had something you wanted to bring up? 18:14:08 jflory7: Thanks for bringing it to our attention. 18:14:44 jsmith: Yes 18:14:53 Mostly just a follow-up on the GCC/mass-rebuild situation. 18:15:11 The GCC team is still "green" on the Feb 2 rebuild, but it's going to be a little bit tight. 18:15:12 sgallagh: Great! 18:15:26 did you figure out what's up with the glib versioning macros? 18:15:27 Due primarily to the excessively long armv7hl build times 18:15:43 kalev: Yes, it was a GCC6 change. It's being reverted while they figure it out 18:15:56 ahh, great work, thanks sgallagh 18:16:26 sgallagh++ 18:16:26 kalev: Karma for sgallagh changed to 5 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:16:29 Thanks :) 18:16:49 Anyway, this was our last meeting before the rebuild, so I figured I'd bring it up 18:17:07 Right now, we're still on target for the 2nd, though they might ask for a couple extra hours into that day. 18:17:13 who's going to run the actual rebuild? dgilmore? 18:17:20 kalev: yes 18:17:24 k 18:17:32 Since building GCC on armv7hl apparently takes north of 15 hours 18:17:40 oh my 18:17:41 FWIW I have been updating builders, they should all be up on the latest f23 stuff by mass rebuild time hopefully 18:17:51 nirik: Awesome :-) 18:18:11 maxamillion: Hopefully in the future we'll have some faster armv7hl builders too :-) 18:18:17 maxamillion: http://koji.fedoraproject.org/koji/buildinfo?buildID=714605 (see start time and estimated completion) 18:18:45 jsmith: does anyone make armv7hl hardware faster than the calxeda stuff? I thought all the new server grade arm was all aarch64 18:18:57 The est. completion was basically for x86_64... 18:19:09 maxamillion: I think the idea is to run 32-bit arm VMs on a 64-bit arm system :-) 18:19:12 sgallagh: goodness 18:19:16 jsmith: ah 18:19:24 Right, as jsmith says. 18:19:29 yes, that is the plan. 18:19:34 nirik was telling me earlier that they're going to start testing that soon 18:19:34 it's not yet in place, but soon. 18:19:50 Awesome 18:19:50 we have the hardware, just waiting on networking, then setup 18:21:16 That's it from me 18:21:16 Any other topics to bring up during the open floor? 18:21:27 * jsmith starts a countdown timer in his head... 18:22:08 #endmeeting