15:08:16 #startmeeting FESCO (2018-02-23) 15:08:17 #meetingname fesco 15:08:17 #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek 15:08:17 #topic init process 15:08:17 Meeting started Fri Feb 23 15:08:16 2018 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:08:17 The meeting name has been set to 'fesco_(2018-02-23)' 15:08:17 The meeting name has been set to 'fesco' 15:08:17 Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:08:21 who all is around? 15:08:26 .hello2 15:08:27 jsmith: jsmith 'Jared Smith' 15:08:27 hello (again) 15:08:43 .hello2 15:08:44 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:09:39 we need 1 more I guess for quorum... bowlofeggs ? 15:10:02 .hello2 15:10:02 bowlofeggs: bowlofeggs 'Randy Barlow' 15:10:15 cool. Lets go ahead and start then. 15:10:25 #topic #1714 Fedora 26 spins process was missed 15:10:26 .fesco 1714 15:10:26 https://pagure.io/fesco/issue/1714 15:10:28 nirik: Issue #1714: Fedora 26 spins process was missed - fesco - Pagure - https://pagure.io/fesco/issue/1714 15:10:53 maxamillion was going to make these pages... but seems not. 15:10:58 Isn't this just a question of manpower? I.e. everybody thinks this page should exist, but nobody is volunteering? 15:11:09 I can just do so... but that brings up the question if we want to change the process any 15:11:31 zbyszek: that and the "process" is pretty poorly documented/understood I think... 15:11:52 right now I guess fesco is supposed to make the page... but that doesn't give a clear action to one person who will do it. 15:12:31 we could do a divide and conquer, unless that would cause inconsistency 15:13:24 i'd do one 15:13:53 i'm not sure why FESCo took this on 15:14:09 because the spins sig is inactive/not existant. 15:14:34 which causes me to question how active the individual spins are 15:14:59 indeed. There are definitely some active ones... and some not 15:15:07 this is not rocket science. the people doing the work (spins owners) can easily go to the page to add their spin as it's created. if it doesn't exist, just create the page 15:15:33 What about we just create this page now, and ask people on fedora-devel to add their spins to it? 15:15:48 zbyszek: +1 15:15:49 For both 27 and 28, let's ignore 26. 15:15:55 well, what do you mean by 'as it's created' ? 15:16:06 nirik, the spin itlsef 15:16:09 or updated 15:16:10 whatever 15:16:22 well, most of them were added long ago... 15:16:42 the point is, i don't think FESCo should be on the hook for tracking down all the information needed for all the spins still active. the spin owners should update the page 15:16:44 we can ask people to add when they test at beta I guess 15:17:22 the last idea was that things must be tested at beta, if they aren't we drop them... but then we got lots of pushback that they didn't know about the testing... 15:17:28 we could put a "if you don't put your spin here by $date, it goes away 15:17:29 " 15:18:07 bowlofeggs: yeah, we tried that for... f25? f24? and several people came up near final and said they didn't know about having to test or it would be dropped. 15:18:38 anyhow, we could give it a go again and try and communicate it better 15:18:54 Yes. 15:19:34 anyhow I'm +1 for creating the pages and asking on devel and spins lists to populate it and require testing at beta to stay in. 15:20:12 we could go as far as contacting the spin maintainers directly instead of a mass post to devel 15:20:18 that way they can't say we didn't communicate it 15:20:28 if we knew who they were we could. ;) 15:20:34 we don't know who they are? 15:20:59 nope... I mean we could say "last person who touched it" 15:21:04 i continue to think spins is a scaling problem that we're solving incorrectly, but i have no major objection to the proposal 15:21:05 * nirik has to step away for a min. 15:21:13 jwb: Agreed :-) 15:21:15 https://fedoraproject.org/wiki/Astronomy_Spin has an owner section, do the others? 15:21:37 the proposal is fine with me, +1 15:21:48 though i think it would be good to additionally try to contact the spin "owners" 15:22:09 Yeah, if we can find them, put them in To: too, this can't hurt. 15:22:12 we could CC the owners who are listed at least, on the same e-mailt o devel 15:22:13 If not, too bad. 15:22:19 yeah 15:23:12 OK, it seems we are all in agreement. Can we vote on the proposal nirik put +1 on? 15:23:18 Count me as +1 to the proposal 15:23:25 +1 FTR 15:23:36 +1 15:23:43 +1 15:24:21 So that's +5. 15:25:22 cool. sorry about that. 15:25:58 #agreed FESco will create the pages and asking on devel and spins lists to populate it and require testing at beta to stay in. (+5,0,0) 15:26:09 #topic #1845 389-ds-base and freeipa on 32 bit arches 15:26:09 .fesco 1845 15:26:09 https://pagure.io/fesco/issue/1845 15:26:12 nirik: Issue #1845: 389-ds-base and freeipa on 32 bit arches - fesco - Pagure - https://pagure.io/fesco/issue/1845 15:26:32 This one makes me a little sad... 15:26:52 I personally prefer option 1, but realize that it's not ideal 15:26:55 yeah, but not sure what we can do 15:27:22 (if nothing else -- it gives time for the GCC and 389-ds-base team to work on a possible fix) 15:27:47 It also gives folks currently running on 32-bit ARM a bit more time to realize it's going away and find another solution 15:28:01 What do others think? 15:28:17 I agree with the sentiment, it's very late in the cycle to drop such significant packages. 15:28:33 yeah i think we should see about pursuing option 1 15:28:35 option 1 is basically a disaster waiting to happen 15:28:45 but then won't they hit corruption? 15:29:04 if there can be corruption due to unimplemented atomic types, then setting users up for that scenario seems irresponsible 15:29:11 They may, yes... but they've likely been running it that way for a while. 15:29:40 I guess I could go either way 15:29:41 jwb: if you read the bugzillas, it's not about unimplemented atomic types, but general memory corruption in the code. It just manifests on i686 more likely. 15:29:49 but now we know... so shouldn't we tell them? 15:29:58 zbyszek, either way, bad 15:30:26 what if we make them downgrade to versions that are known to work on 32 bit? 15:30:30 nirik: I ge the feeling that the problem exists on 64-bit as well, but doesn't manifest itself as easily, and this is just ignoring the real problem by making 32-bit go away 15:30:35 and do this for f29? 15:30:41 bowlofeggs: I'm not sure that there is such a version 15:30:47 ah 15:31:02 or if there is we aren't sure what it was 15:31:45 it sounds like investigation is ongoing... I wonder if we shouldn't try and wait a bit more and see if a solution or at least the scope of the problem is more clear 15:32:00 Proposal: Ask the GCC team to try to help find the source of the corruption. Post to the -devel list to let people know the situation. Revisit in two weeks. 15:32:16 jsmith: +1 15:32:40 +1 15:32:48 +1 (who will post and who will talk to gcc team) 15:33:23 +1 (even though I think waiting just makes option 1 more unlikely to happen) 15:34:24 I'm assuming jsmith is +1 for his own proposal? 15:34:39 Yes 15:34:43 #agreed Ask the GCC team to try to help find the source of the corruption. Post to the -devel list to let people know the situation. Revisit in two weeks. (+5,0,0) 15:34:55 so who is going to talk to gcc team? and who is going to post to devel? :) 15:35:26 oh i thought your parenthesis was you volunteering haha 15:35:41 sorry that should have had a ? at the end. ;) 15:36:03 who is "the gcc team"? the packagers? 15:38:11 not sure, but the glibc maintainer is definitely already digging in all those bugs. 15:38:39 i'd do it if i knew who we were talking about :) 15:38:51 i can e-mail the gcc packager group, if that's satisfactory 15:39:01 bowlofeggs: Sounds like a decent plan 15:39:02 fine with me... 15:39:05 cool 15:39:33 and i'll e-mail devel too 15:39:41 Thanks bowlofeggs 15:39:57 awesome 15:40:17 #action bowlofeggs to mail devel and gcc maintainers to make them aware of the converstation in bugs. 15:40:42 #topic #1846 F28 approved Changes not in MODIFIED status (considered as not testable) 15:40:42 .fesco 1846 15:40:42 https://pagure.io/fesco/issue/1846 15:40:44 nirik: Issue #1846: F28 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1846 15:41:10 The ones that are asking to defer to F29 should be a no-brainer, I think 15:41:22 The ones that need another week, I'm inclined to give them another week. 15:41:42 agreed 15:41:53 The ones that haven't responded, I'm tempted to push to F29 (but that's probably mean-spirited, and we should probably give them another week to respond) 15:42:17 A few are "cooking", should be ready in a week or two. 15:42:30 I know modularity is being worked on as far as composes... there's currently a pungi bug preventing rawhide composes with modular, but I think we have a f28 one now. 15:42:50 E.g. Strong crypto settings, Glibc collation 15:43:07 or perhaps its not on in f28 yet until we get it working in rawhide 15:43:21 i agree with jsmith 15:43:41 the strong crypto one definitely got a change done 15:44:00 because thunderbird stopped talking to an IMAP server i use this week (laptop is rawhide) 15:44:01 hahaha 15:44:49 so, proposal: changes wishing to defer to f29 can do so now, the rest we revisit next week for response or testable. 15:45:01 nirik: +1 15:45:47 +1 15:45:59 +1, somewhat begrudingly 15:46:43 jsmith: ? 15:46:50 +1 15:47:01 #agreed changes wishing to defer to f29 can do so now, the rest we revisit next week for response or testable. (+5,0,0) 15:47:21 #topic #1847 Request Permission to Retire w/o Responsive Maintainer 15:47:21 .fesco 1847 15:47:21 https://pagure.io/fesco/issue/1847 15:47:23 nirik: Issue #1847: Request Permission to Retire w/o Responsive Maintainer - fesco - Pagure - https://pagure.io/fesco/issue/1847 15:47:48 +1 to just retire it. it's been years. But should we also orphan other packages they maintain? 15:48:02 Like I wrote in the ticket, I propose to proceed immediately with xchat-ruby, and open the procedure on fedora-devel for nonresponisve maintainer. 15:48:25 isn't xchat removed anyway? 15:48:35 yeah t is 15:48:38 i agree with zbyszek 15:48:52 WORKSFORME 15:48:53 I can write the e-amil to fedora-devel and konradm. 15:48:57 yes, xchat is gone, this package is not installable. ;) 15:49:04 nirik: i think we should do the unresponsive maintainer for his other pacakges 15:49:13 ok, I'm fine with that... 15:49:21 jwb: ? 15:50:04 sorry, got pinged. let me scrollback 15:50:18 oh, +1 15:50:27 #agreed proceed immediately with retiring xchat-ruby, and open the procedure on fedora-devel for nonresponisve maintainer (+5,0,0) 15:50:39 zbyszek: can you retire xchat-ruby as well? 15:50:54 I'm not sure if I have privileges. 15:51:25 just 'fedpkg retire'.. if you are a pp it should work 15:51:48 OK, so then I can do it. 15:52:36 thanks 15:52:42 +1 15:52:47 (for the record) 15:52:58 #action zbyszek to retire xchat-ruby and start non responsive process for developer. 15:53:05 #topic #1848 Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository 15:53:05 .fesco 1848 15:53:05 https://pagure.io/fesco/issue/1848 15:53:07 nirik: Issue #1848: Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository - fesco - Pagure - https://pagure.io/fesco/issue/1848 15:53:24 * zbyszek wants to just nuke it 15:53:34 so, as I noted we refused this before several times... 15:53:40 this one i'd be concerned a bit if we didn't keep the old repo somewhere 15:54:04 I'd like dgilmore to weigh in... I suspect he feels strongly about it. :) 15:54:17 but yeah, keeping the old repo might be enough 15:54:59 It's not time-sensitive, so we can allow one more week for discussion in the ticket. 15:55:24 yes 15:55:36 sure. I think that would be nice.. 15:55:43 +1 15:56:30 jwb, jsmith? 15:56:56 jwb: "yes" means +1 I guess 15:56:59 +1 to waiting a week 15:57:03 +1 15:57:05 sorry 15:57:17 #agreed defer this another week for more discussion. (+5,0,0) 15:57:22 #topic next weeks chair 15:57:26 who wants it next week? 15:57:48 i will be on PTO. i can take the week after 15:58:10 I'll be at a Docs FAD 15:58:25 (but can take it, if nobody else volunteers) 15:58:40 i did it last week, but i could do it again unless zbyszek wants to do it :) 15:58:59 OK, I can volunteer. 15:59:23 cool Thanks zbyszek. There's a wiki page with all the steps. 15:59:30 #info zbyszek to chair next week 15:59:34 #topic Open Floor 15:59:38 I'll bug all of you if I can't figure it out ;) 15:59:39 anything for open floor? 15:59:43 do we want to talk abotu the meeting time some more? 15:59:49 Do we have a person for the first action? 16:00:02 I.e. the spins page mail and creation? 16:00:08 * nirik checks the when is good. 16:00:22 zbyszek: I can do it, unless someone else wants to... 16:01:06 Doesn't seem likely that anybody wants to 16:01:17 we only have 5 responses on the second whenisgood 16:01:27 the whenisgood responses are the same set of us that are here today 16:02:01 This is disappointing, but let's wait a week then. 16:02:25 yeah. I fear we are just going to keep the current time, but we will see. 16:03:17 ok, if nothing else will close out in a minute here. 16:04:47 ok, thanks for coming everyone! 16:04:50 #endmeeting