15:00:32 #startmeeting FESCO (2018-03-09) 15:00:32 Meeting started Fri Mar 9 15:00:32 2018 UTC. The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:32 The meeting name has been set to 'fesco_(2018-03-09)' 15:00:32 #meetingname fesco 15:00:32 The meeting name has been set to 'fesco' 15:00:38 .hello2 15:00:39 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:46 #topic Roll Call 15:00:54 Oh, I'm not chaired. 15:01:00 morning 15:01:02 #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek 15:01:02 Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:01:06 #topic Roll Call 15:01:11 .hello2 15:01:12 sgallagh: sgallagh 'Stephen Gallagher' 15:01:14 .hello2 15:01:15 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:02:13 .hello2 15:02:14 maxamillion: maxamillion 'Adam Miller' 15:02:24 dgilmore jsmith bowlofeggs tyll jwb: fesco meeting in -2 15:02:36 apologies for my absence the last few meetings, I have a newborn and things are a bit crazy at my house right now 15:02:38 hi 15:02:53 i'm double booked, but i should be able to pay attention 15:02:54 .hello2 15:02:55 jsmith: jsmith 'Jared Smith' 15:03:34 Hi 15:03:46 Hello everyone, we have quorum 15:03:57 I'll wait a minute more, and start 15:04:19 Quorums are good :-) 15:04:35 spelling is a bitch though ;) 15:04:57 words are hard 15:05:13 OK, let's go. 15:05:16 = Followups = 15:05:16 #topic #1853 F29 System Wide Change: Enable dbus-broker 15:05:17 .fesco 1853 15:05:17 https://pagure.io/fesco/issue/1853 15:05:18 zbyszek: Issue #1853: F29 System Wide Change: Enable dbus-broker - fesco - Pagure - https://pagure.io/fesco/issue/1853 15:05:39 I think we need to postpone this again. There has been no reply from Change Owners. 15:05:59 One is on PTO... 15:06:32 +1 to defer another week 15:06:33 is there anything by way of the schedule that would make it problematic to postpone again? 15:06:34 * nirik is fine with more (any?) discussion on it. 15:06:38 There's plenty of time to decide on it before F29 15:06:47 Yeah, no hurry whatsoever. 15:06:52 .hello2 15:06:54 (sorry for my tardiness - lost track of time) 15:06:55 bowlofeggs: bowlofeggs 'Randy Barlow' 15:07:08 Hi! 15:07:13 #topic #1845 389-ds-base and freeipa on 32 bit arches 15:07:13 .fesco 1845 15:07:13 https://pagure.io/fesco/issue/1845 15:07:14 zbyszek: Issue #1845: 389-ds-base and freeipa on 32 bit arches - fesco - Pagure - https://pagure.io/fesco/issue/1845 15:07:31 Do we have any news here? 15:07:39 i don't think so 15:07:45 zbyszek: i tried to follow up on this one but i don't feel like i have the info 15:07:47 I haven't heard anything :-( 15:07:50 * nirik checks bugs 15:07:50 they also still did not file a change 15:07:54 i asked them to 15:07:55 :/ 15:08:04 note that there's a bug linked from the bug 15:08:19 bugs on bugs on bugs 15:08:26 https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c9 has more info 15:09:12 At least they think it's just i686 that is affected, and not 32-bit ARM 15:09:14 So it sounds like A) only i686 and B) only in newly-written code since F27 15:09:26 So there's no way to know yet if it has real-world impact 15:09:37 But their tests leave them without a warm fuzzy feeling 15:09:37 we have the i686 sig 15:09:43 can we ask them to care about this and move on? 15:09:50 or was that just about the kernel? 15:10:14 That's a good idea. If i686-sig does not care, then maybe the issue is overblown (or i686-sig does not exist ;)) 15:10:28 either way a change should be filed 15:11:18 proposal: kick the issue to i686 sig, and simultaneously get an f28 change filed. the change can be withdrawn if i686 sig can fix this in time 15:11:26 hm 15:11:37 bowlofeggs: +1 15:11:46 bowlofeggs: +1 to your proposal, but what if they don't file a change? 15:11:47 bowlofeggs: +1 15:11:47 well, it's still murky to me where the issue is... 15:11:47 if it's just i686, why did they disable arm? 15:11:52 or did they not do that 15:11:59 jwb: Exactly what I was trying to get to the root of... 15:12:25 If they have to write up a change page, it'll have to include those things. 15:12:35 jsmith: can we just decree that the packager has to file the change? 15:12:55 i don't want to kick an issue to the i686 sig if it isn't truly i686-only. that would be mean, for a sig that is rather understaffed/ethereal 15:12:55 also note that they blocked the x86 arch blocker bug...which if there is a i686 sig, they should be watching. ;) 15:12:59 basically say they either have to file the change or bring 686 back? 15:13:08 jwb: My gut feeling was that they thought it was a problem with 32-bit atomics and just disabled all 32-bit arches 15:13:11 jwb: they are saying it is 686 only 15:13:17 bowlofeggs: Sounds fair :-) 15:13:25 jwb: https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c9 15:13:32 "apparently" 15:13:39 i guess that's not the strongest statement 15:14:15 this is all "we have a problem. we don't really care about the problem where it surfaces, let's punt on it entirely" 15:14:16 they only excluded i686 from the rawhide package 15:14:18 jwb: i think we can kick it to i686 with no penalty if they don't fix it 15:14:33 basically alert them of the problem - if they want to let it get dropped, fine 15:14:45 bowlofeggs, yes, but they don't actually understand the issue, do they? they're just dropping 32-bit 15:14:47 but still give them an opportunity to get involved and keep it working 15:14:50 let it be their choice 15:15:08 jwb: it does sound like the issue isn't fully understood to me 15:16:14 jwb, nirik, vote on bowlofeggs proposal? 15:16:22 bowlofeggs, right. and since it isn't understood and they've punted and they also included ARM, i don't think we can say "it's the i686 SIGs" problem 15:16:28 -1 15:16:57 proposal: FESCo leaves this to the maintainers of the packages and architectures to sort out. 15:16:58 I'm not all that in favor... I think we should have the tools folks press them for the real issue so it gets fixed... but we can't really force that 15:18:07 jwb: so ARM is included? i thought they were saying it was only i686 15:18:21 oh but i guess arm is why dgilmore filed in the first place? 15:19:12 https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec: 15:19:18 # Exclude 32 bit arches 15:19:18 ExcludeArch: %{ix86} 15:19:33 So the comment does not match the line below, but it's just i686 right now 15:19:39 haha 15:19:55 I think it did also filter out armv7 before 15:19:59 i think they did include arm, then when people complained they dropped it. again, because they don't have root cause 15:19:59 But they might've re-added that later 15:20:10 i would be more worried if all 32-bit were excluded. not to sound mean to 386, but if it's just 386 that does seem less bad to me 15:20:36 which is why i said just leave it to the maintainers. FESCo has nothing they can do here 15:20:39 OK, since they only seem to be excluding i686, I'm all for letting them fiture it out. 15:20:59 yeah, I'm with bowlofeggs in that I thought it to be i686 only but it's possible I'm lacking context 15:20:59 zbyszek: huh, 389-ds-base has i686... 15:21:12 nirik: lol? 15:21:28 yeah i can be ok with that - and i think it could be good ot specifically alert the 686 sig just for their info (i.e., not requiring anything of them, just a friendly highlight of the issue) 15:21:46 they do need a change i think 15:21:48 389-ds has no ExcludeArch in F28 15:22:43 But 389-ds-base has ExcludeArch: i686 15:22:51 (as nirik said) 15:23:02 my worry about this entire thing is that there is a subtle toolchain bug, which ideally would be found and fixed, but it seems this is hard to isolate. 15:23:11 yeah it does look like the exclude is only on rawhide 15:23:22 https://src.fedoraproject.org/rpms/389-ds/blob/f28/f/389-ds.spec 15:23:28 no exclude there 15:23:35 but it is here: https://src.fedoraproject.org/rpms/389-ds/blob/f28/f/389-ds.spec 15:24:06 bowlofeggs: those are the same links, no? 15:24:12 * jsmith just got confused 15:24:14 whoops 15:24:15 haha 15:24:20 https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec 15:24:21 sorry 15:24:25 bowlofeggs: it's excluded in f28 for 389-ds-base 15:24:30 https://src.fedoraproject.org/rpms/389-ds-base/blob/f28/f/389-ds-base.spec#_5 15:24:30 that was a middle click vs. ctrl-v error 15:24:41 But 389-ds Requires 389-ds-base so that cannot work 15:24:53 oh different package 15:24:53 right 15:25:17 I guess 389-ds is not important at all, it's a noarch package. 15:25:44 389-ds-base is what counts, and that has ExcludeArch in F28 and rawhide 15:26:00 we've spent almost 20 minutes on this. we have nothing we can actually do about it. why are we still discussing here? 15:26:47 proposal: FESCo requires a change for f28, the packagers are otherwise free to sort it out 15:27:42 +1 15:27:52 zbyszek: +1 15:28:20 sure, +1. 15:29:00 note that there might be also releng changes here at some point... since the i386 server images will stop composing. They aren't blocking, but if they don't work we should remove them/stop trying to make them at some point. 15:29:09 +1 15:29:10 +1 15:29:30 nirik: Good point, but I don't know what else we can do 15:29:31 nirik: oh true. that should be noted in the change, which should be system-wide 15:30:03 well, we can remove them after beta, just means some work 15:30:18 #agree FESCo requires that a Change be filed for F28, and involved are otherwise free to sort out the issue (+6, 0, -0) 15:30:21 #info If the change is accepted, releng changes will be required 15:30:47 Another "nice" topic: 15:30:52 #topic #1820 Adjust/Drop/Document batched updates policy 15:30:52 .fesco 1820 15:30:52 https://pagure.io/fesco/issue/1820 15:30:56 zbyszek: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820 15:30:59 fun! 15:31:08 Yay 15:31:10 note that there were comments this morning just right before the meeting. 15:31:21 I made a proposal in the ticket. 15:31:21 nirik: can you summarize the results of the experiment over the last week? 15:31:38 and in fact some just now _during_ the meeting 15:31:41 zbyszek: I can tell you that I've only seen stable be pushed out on Monday if I recall correctly 15:31:58 (not counting Tuesday, and the Monday one I did because of the dhcp one) 15:32:30 zbyszek: as puiterwijk said (he was on push duty)... 15:33:10 yeah we can def make the changes requested by sgallagh pretty easily 15:33:19 I think we might step back a second and look at our goals here. My understanding is there were 2: 1) less "flood" of updates for users, 2) less metadata changes for users. 15:33:33 i also found a few deficiencies around severity in bodhi this week which i've been working on 15:33:49 like the CLI not supporting them at all (PR filed for that yesterday) 15:33:58 nirik: Also "less frequent syncs to mirrors" 15:34:11 nirik: and also 3) a way for QA to test the batch 15:34:19 sgallagh: sure, I guess that falls under 2 somewhat... 15:34:22 QA doesn't do that yet, but it would be possible now 15:34:56 i don't know if QA wants to do that 15:35:00 haha 15:35:08 yeah, that perhaps should be something we find out. ;) 15:35:29 I know the OSCI people really want that to happen and are working towards it 15:35:49 towards testing batches? 15:35:57 I believe so, yes 15:36:01 Going back to nirik's goal #1 and goal #2, I think sgallagh's proposal moves us towards those two goals 15:36:05 sgallagh: news to me 15:36:27 well, the delta repodata would help 2 a fair bit (but that is only in development) 15:36:31 hmm, I thought I remembered dperpeet and rsibley mentioning it. But it's been a while. 15:36:41 Dunno, I have to agree with kkofler that batched is not really working right now. 15:36:53 zbyszek: I agree it's not working in its current incarnation 15:37:06 I postulated that the reason for that is because it's implementation didn't take best advantage 15:37:12 If the delta repodata solves #2, then #1 is not enough of motivation, because it is better done on the client side. 15:37:13 I think a user end batching might make more sense for users, barring us testing them... which I think couldbe very valuable 15:37:29 But we would be able to test them the same way 15:37:45 do note that all/most workstation users don't see the 'flood of updates' already, since it's batched on client end. 15:38:01 one nice thing i've noticed this week is that i get more drpms 15:38:11 +1 15:38:11 that's another subtle benefit of batching 15:38:13 I mean we could install a default dnf-install-batched.timer that fires on (say) Tuesday, and QA would test that batch. 15:38:16 I do like drpms 15:38:18 bowlofeggs: +1 15:38:18 (i don't update every day) 15:38:26 (so i used to not get very many drpms) 15:38:33 bowlofeggs: I did notice more drpms too 15:38:36 (same, I update weekly) 15:38:42 That's an advantage we haven't made clear. 15:38:54 yeah it dind't occur to me until just yesterday 15:38:55 It's a significant decrease in download usage 15:39:05 I used to update every day (and still do on my rawhide laptop), but I don't on my other machines anymore... I just update once a week or so. 15:39:07 Useful for those on metered or slow connections, certainly 15:40:02 i like the idea of a fasttrack repo, i just don't know if we can do it infra wise 15:40:04 like, resource wise 15:40:12 or if the mirrors would bear it storage wise 15:40:16 zbyszek: the timer gets into 'do we auto apply updates' also? 15:40:29 sgallagh: yeah, on that note apparently metered connections are making a comeback ... I've noticed it in the small print of a lot of recent local offers, so that might become a rising concern for users 15:40:47 which honestly surprised me 15:40:57 I think the fasttrack thing adds a lot of complexity and resources for... probibly not too many people. 15:41:19 nirik: yeah that's a good counter point 15:41:23 it's hard to say for sure of course 15:41:56 ultimately on the note of things, I think "bugfixes batch" and "security updates go out immediately" is a good stance, regardless of security severity 15:42:13 i actually think most security updates aren't important 15:42:17 some security fixes are very minor. 15:42:18 The hardest part of a decision like this is that we will *never* hear from the people it benefits. 15:42:18 maxamillion: I am not really sure I'd agree with that general a statement on security bugs.. 15:42:21 most updates aren't important 15:42:32 But we will never *stop* hearing from the people who disagree. 15:42:36 sgallagh: yep 15:42:46 most of them are very difficult to exploit and also give very little benefit when they are exploited 15:42:56 they might not be, but who's going to "grade" them and make that decision for all packages across the distro at all times? 15:42:57 maxamillion: I definitely disagree with that statement on security bugs. 15:43:06 also, it's not just secuirty that can be worthy of skipping to stable - think of a real bad data eating bug 15:43:08 maxamillion: RH prodsec does so... 15:43:14 That's the data I've been using last week 15:43:18 so a bugfix would also warrant going out right away if it's real bad 15:43:19 can you use the gnome-software batching without installing a pile of gui? 15:43:20 If only because we have those at least every 2-3 days. It would render batching basically meaningless. 15:43:27 puiterwijk: RH prodsec does that for all of Fedora? 15:43:32 Look in RHBZ's for ecurity bugs, and tehre's a whiteboard with severity=(low|moderate|important|critical) 15:43:43 maxamillion: No, only those things RH also ships. 15:43:52 then I think it's a moot point 15:43:54 But honestly, that's 99% of the stuff that *really* matters. 15:43:58 sgallagh: not per se. I've seen enough prodsec bugs for things that aren't in products 15:44:06 interesting 15:44:10 They follow external things like oss-security and NVD 15:44:18 Let's settle for "only guaranteed for" 15:44:23 True on that 15:44:50 the CVE itself usually has a score too 15:45:04 But there's also other sources, like the CVE database and NVD, which have the CVSS score... 15:45:10 so as another datapoint: 15:45:31 So tehre's a lot of people checking the importance of security issues and publishing them in useful databases 15:45:34 fedora infra has all fedora installs we do setup with dnf autoupdate for security stuff. 15:45:49 But looking at the list from this week, I think that clamav is something that should not be batched, and php def too 15:46:24 to pick a random machine, it's applied them 13 times so far this year. 15:46:36 nirik: that is interesting 15:46:49 * misc also have autoupdate on most servers 15:46:51 That averages to one a week 15:47:02 sgallagh: a possible amendment to your proposal from the ticket: we could also require a justification from packagers when they pick "urgent" on the severity 15:47:04 err, a bit more than that, sorry 15:47:11 I guess my main point is that these entities that may or may not "score" things to give us a metric by which we can mark a security update as "important" or "not important" (or some variant of those) are not Fedora contributors, which means that the responsibility will eventually fall on us or others in the community and I don't think anyone just has a pile of spare cycles sitting around 15:47:12 but that was bodhi-backend01, machines with more packages will have more 15:47:14 zbyszek: note that for the clamav one, there was a few hours between batched and stable, so I didn't even get the time to look at that 15:47:15 bowlofeggs: I could be fine with that. 15:47:17 sgallagh: like a text box where they type why it's important, and releng can read it 15:47:24 zbyszek: same for the PHP one... 15:48:33 proposal: implement the severity stuff proposed in bodhi, ask QA about batch testing plans, go back to normal pushes, revisit next week and keep discussing plans ? 15:48:36 bowlofeggs: who's going to audit the justifications? who has authority to say "yes, that's a valid justification" or "no, that's not" 15:48:58 or perhaps if we don't know what we want to do in bodhi yet, drop that 15:49:02 maxamillion: perhaps the push duty person? 15:49:04 nirik: I think that's reasonable. Consider me +1 15:49:29 bowlofeggs: I think that's infeasible in the long term, just too much work 15:49:40 maxamillion: I'd say we trust the packagers but if the updates they submit consistently get marked as Urgent, maybe someone can take a look and if in doubt, submit to fesco? 15:49:43 nirik: i can +1 with the exception that i can't do that myself in the next week (too much modularity and container and other things on my plate) 15:49:52 alright 15:49:57 (and the data on "who marks things as urgent a lot" is easy to gather) 15:50:03 bowlofeggs: fair, we can drop the bodhi part until we decide more anyhow 15:50:08 I think the whole thing is silly, but consensus says otherwise so I'm going to back away from this item 15:50:42 the bodhi changes aren't too hard, though they technically are backward incompatible so would require an x release bump, unless we carry a fedora-specific patch 15:50:53 puiterwijk: I think that's a fair middle-ground. 15:50:58 or maybe i could make it a setting which severity levels are allowed... 15:51:13 maxamillion: the whole thing being batched updates? or requiring some kind of justification for every update? 15:51:17 bowlofeggs: Let's leave the justifications out for now until and unless it becomes obvious they're needed 15:51:22 sure 15:51:36 Or, in other words, "assume positive intent" :-) 15:51:45 yes 15:51:47 yeah that's good 15:52:04 I also think that reducing the number of choices to "batched" and "urgent" makes it more clear to our users what the fields mean 15:52:30 we should probably just tie urgency to whatever the urgency of the bug is 15:52:30 true 15:52:35 I think that, given the choice, the vast majority of our packagers will do the right thing 15:52:37 and not let it be selectable in bodhi 15:52:46 one thing to keep in mind is that yum and dnf also consume this urgency field 15:52:48 jwb: Not every update has BZs 15:52:53 sgallagh, then it isn't urgent 15:52:57 nirik: requiring justification and the idea that some security updates should be batched instead of sent out as soon as they hit stable 15:53:01 so i actually can't use "standard" i don't think 15:53:04 jwb: Fair point 15:53:10 but i could probably do medium and urgent or something 15:53:21 i assume that yum/dnf expect certain specific strings there 15:53:24 (not sure) 15:53:37 bowlofeggs: Well, at the UI layer you could translate those 15:53:39 maxamillion: I'm with you on the first part... but having seen some of the things that get CVE's... some security updates are super duper stupid. :) 15:53:40 nirik: I agree that some security updates don't need everyone to drop everything they're doing and get them tested and pushed out immediately, but it seems silly to me to let them sit and wait for a batch push 15:53:41 And just store them differently 15:53:48 sgallagh: true 15:54:42 proposal: ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week 15:54:50 nirik: that's fine, but I don't think we realistically have the people to really monitor and/or police that on a daily basis across all updates so it just makes more sense to me to not follow the Red Hat Errata model 15:54:54 nirik: +1 15:55:01 maxamillion: some security updates can't be exploited unless other security measures are also broken. in some cases they just can't be exploited at all, but should still be fixed. i think those are obvious to wait 15:55:05 maxamillion: I've handled plenty of CVEs that boiled down to "first have sudo access on the console"... 15:55:08 maxamillion: ime, most CVEs are in that category 15:55:21 bowlofeggs: I disagree, I say push them out ... what harm does it do? 15:55:28 i read oss-security and so many CVEs really are like that 15:55:39 maxamillion: well it triggers everyone to download 40 MB 15:55:40 maxamillion: Unnecessary churn on the mirrors/metadata 15:55:51 and more flood of useless updates. ;) 15:55:52 nirik: +1 15:55:54 sgallagh: how many people copy and paste "sudo curl foo.com | bash" ? 15:56:30 like I said, I'm stepping away from this item 15:56:46 maxamillion: My point was that the actual exploit often requires enough access that the exploit itself is meaningless 15:57:05 sgallagh: but I think that's really up to maintainer to decide 15:57:12 Sure, I agree 15:57:23 But it's why I think "security != urgent" in all cases 15:57:23 We should trust maintainers to do their job, no need to secondguees. 15:57:27 zbyszek: agreed. Which is why I think that not all security marked bugs should be treated equal 15:57:32 zbyszek: We're in violent agreement :) 15:57:36 Yes! 15:57:41 Yeah. That 15:57:54 sgallagh: I agree that not all security updates are urgent, I attempted to clarify that 15:57:57 and urgent != security too (bad bugs) 15:57:59 nevermind, stepping away from this one 15:58:02 OK, so we have +3 to nirik, anyone else? 15:58:07 OK, I think we're all agreed there 15:58:09 +1 to nirik 15:58:10 urgent just means... urgent :) 15:58:25 i do think newpackage and enhancement updates should not be urgent 15:58:28 nirik: +1 15:58:35 +1 to nirik's proposal, in case my vote wasn't clear 15:59:14 +1 i suppose 15:59:41 #agree Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+6, 0, -0) 15:59:44 Oh, can I get one clarification, seeing that I'm still on push duty? 15:59:51 once f28 calms down i can get bodhi to be more in line with these ideas 15:59:59 #undo 16:00:00 Removing item from minutes: AGREED by zbyszek at 15:59:41 : Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+6, 0, -0) 16:00:02 Do people want me to push out everything today, or is the urgent-only push I did an hour ago good enough? 16:00:19 puiterwijk: whats done is fine. 16:00:20 zbyszek: sorry. Wasn't meant to revert the vote. Just clarification on when "back to normal pushes" starts 16:00:26 puiterwijk: i think today's push was fine - i think we just go back to normal tomororw 16:00:28 nirik: okay. Just wanted to make sure 16:00:32 Yeah, but I thihk I miscounted 16:00:39 I just wanted to go back to normal so we don't have to explain what to do to every other releng person on push duty... 16:01:00 nirik: well, we have a simple operation to do it now, so that's simple :) 16:01:00 #agree Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+7, 0, -0) 16:01:02 yeah if we want that behavior it'd be better if bodhi did it 16:01:16 puiterwijk: oh yeah, truuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuue. 16:01:18 bowlofeggs: funny enough, it kinda does. I didn't want to do it manually. 16:01:21 argh. 16:01:27 nirik: wayland? 16:01:32 puiterwijk: yeah that --urgentonly patch :) 16:01:34 bodhi-push --urgent-only :) 16:01:47 OK, let's move on. 16:01:49 #topic #1745 F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL 16:01:50 .fesco 1745 16:01:50 https://pagure.io/fesco/issue/1745 16:01:50 my sound card power saving likes to cause a nice delay when it loads in to beep on a highlight. 16:01:52 zbyszek: Issue #1745: F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL - fesco - Pagure - https://pagure.io/fesco/issue/1745 16:02:18 uh... F27? 16:02:19 F27 still? I think that title might need updating 16:02:32 it's 28 now. 16:02:37 it got deferred 16:02:39 Yeah. The title needs updating 16:03:02 It's ON_QA. I'm not sure if there's anything to discuss here. 16:03:23 oh, and it was orig a f26 one that got delayed to f27. ;) 16:03:26 Well, I think the technicality is that we may not have approved it for F28 16:03:28 but yeah, ack +1, move on 16:03:30 But I'm +1 16:03:44 (fyi my f27-20180302 updated isos now show 115M of updates) 16:04:12 +1 16:04:18 +1 from me 16:04:28 +1 16:04:31 +1 16:05:21 #agree F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL is reapproved (+6, 0, 0) 16:05:31 #topic FESCo meeting time 16:05:48 http://whenisgood.net/fesco2018roundtwo/results/ss5khfp 16:06:21 We only have 8 answers, but there's isn't much more choice. 16:06:32 proposal: keep current time, stop discussing 16:06:43 +1 16:06:44 i was +1 to the OpenLDAP change 16:06:54 i'm also +1 to keeping the current time 16:06:56 note: Daylight stealing time starts in the US this weekend. 16:07:03 +1 - that works for me, my availability is pretty open 16:07:12 so, do we keep to the same UTC time? or ? 16:07:17 * jsmith is fine with the current time, but would prefer Monday or Tuesday 16:07:20 nirik: oof that'll be real early for you, but not relative to the sun :) 16:07:31 it'll be 9 AM for me (it's 10 now) 16:08:06 i do think it's better for meetings to not change with DST 16:08:21 because DST is not observed in all places and in the places it is observed, it changes on different dates 16:08:25