16:00:16 #startmeeting FESCO (2017-04-21) 16:00:26 #meetingname fesco 16:00:36 #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann 16:00:45 #topic init process 16:00:47 .hello sgallagh 16:01:23 morning 16:04:01 hola 16:04:47 jwb jsmith? I know Rathann said he was out 16:05:00 sorry, here 16:05:39 Okay, that's quorum 16:05:54 #1653 Better communicating roles and responsibilities of FESCo 16:06:05 .fesco 1653 16:06:09 and luckily pagure is up. ;) 16:06:14 https://pagure.io/fesco/issue/1653 16:06:18 Indeed. 16:06:42 So this is the follow up with nirik's statement in there. We have had some feedback, but not much. Not sure if there is anything to do here, but it was still tagged meeting 16:06:43 I tossed up a draft a while back. 16:07:49 I think the draft is well written, though sgallagh's suggestion would be helpful 16:08:04 jforbes: +1 16:08:07 nirik: one query 16:08:10 nirik: Approval and coordination of "changes" for traditional Fedora releases. 16:08:17 why is traditional in there? 16:08:50 dunno... I guess they apply to any releases... unless we get to a point where say a modular release doesn't have any new changes in it. 16:08:59 happy to stike that word 16:09:15 at a literal sense I could say I want to go off and do something not close to traditional so I do not need to bother about working with FESCO 16:09:33 I would like traditional removed 16:09:43 sure 16:09:46 Seems reasonable to me 16:09:54 Seems a rather pedantic interpretation, but I could go with that 16:10:17 So do we want to do a quick edit in the ticket and vote on it? 16:10:26 jforbes: I may spend too much of my time having to be pedantic 16:10:31 sure 16:10:42 dgilmore: understandable. 16:11:05 want me to add a comment with the change? 16:11:05 i think we can likely just vote with the understanding that "traditional" will get axed 16:11:10 yeah. 16:11:19 I am good with that 16:11:25 +1 with dgilmore and sgallagh's changes 16:11:46 +1 with both changes 16:11:50 +1 with both 16:12:16 .hello maxamillion 16:12:18 sorry I'm later 16:12:21 late* 16:12:27 hi later ;) 16:12:33 :P 16:12:44 Okay, I have added a comment in the ticket to address both changes. 16:12:59 +1 16:13:10 I don't see a topic change ... which ticket? 16:13:14 maxamillion Markus_KMi_[m] mailga mark_otaris masta mattdm 16:13:21 https://pagure.io/fesco/issue/1653 16:13:33 maxamillion: zod bot is down 16:13:34 maxamillion: sorry, our bot is gone 16:13:36 maxamillion: zodbot is down due to the ongoing network issues 16:13:37 oh right 16:13:40 thanks 16:13:45 »» jforbes has changed the topic to: https://pagure.io/fesco/issue/1653 16:14:10 this wouldn't be a problem if I could be a decent adult and show up to things on time ;) 16:14:55 proposal: The updated statement in comments will be added to the FESCo wiki page 16:15:01 +1 16:15:02 +1 16:15:07 +1 16:15:22 +1 16:15:46 +1 16:17:02 5 is enough right? 16:17:06 #agreed The updated statement in comments will be added to the FESCo wiki page (+5,0,-0) 16:17:12 i voted +1 above 16:17:23 #undo 16:17:27 #agreed The updated statement in comments will be added to the FESCo wiki page (+6,0,-0) 16:17:46 #topic #1695 F27 System Wide Change: Switch libidn-using applications to IDNA2008 16:18:02 .fesco 1695 16:18:12 https://pagure.io/fesco/issue/1695 16:18:27 »» jforbes has changed the topic to: 1695 F27 System Wide Change: Switch libidn-using applications to IDNA2008 16:18:37 +1 from me. 16:18:49 +1 16:18:50 Might be a little rocky, but it necessary. +1 16:19:14 +1 here as well 16:19:32 +1 16:20:21 jwb? 16:20:32 »» jwb shrugs 16:20:35 +1 i guess 16:20:55 #agreed F27 System Wide Change: Switch libidn-using applications to IDNA2008 is approved (+6,0,-0) 16:21:12 #topic #1697 F27 System Wide Change: Switch libcurl back to OpenSSL 16:21:24 »» jforbes has changed the topic to: 1697 F27 System Wide Change: Switch libcurl back to OpenSSL 16:21:33 .fesco 1697 16:21:41 https://pagure.io/fesco/issue/1697 16:21:52 +1 16:22:15 +1 16:22:27 +1 16:22:55 +1 16:22:56 +1 16:23:26 +! 16:23:28 er, +1 16:23:41 #agreed F27 System Wide Change: Switch libcurl back to OpenSSL is approved (+6,0,-0) 16:23:59 #topic #1698 systemd preset decision: thermald.service 16:24:07 »» jforbes has changed the topic to: 1698 systemd preset decision: thermald.service 16:24:15 .fesco 1698 16:24:26 https://pagure.io/fesco/issue/1698 16:25:11 +1 to sgallagh's guideline addition. 16:25:21 i am going to defer to jforbes on this 16:25:37 I'm +1 to sgallagh's guideline addition as well 16:25:38 this seems like a bad thing to enable by default... 16:25:50 can we discuss the guideline part first? 16:25:52 Right, so there are 2 issues here. Let's vote on the guideline addition first. 16:26:00 as to the change in guidelines, it seems fine 16:26:09 Agreed. I am (obviously) +1 to the guideline change 16:26:13 as far as the thermald.service, I'd defer that to the recommendation of the kernel team (jforbes, labbott, et al) 16:26:30 guideline +1 16:27:22 so proposal from the ticket for prosperity: Append the Default Services criteria with "Installation of the package providing the unit auto-started by this preset may not change the behavior of any other service running on the system. Exceptions may be granted by FESCo on a case-by-case basis." 16:27:31 I am +1 there 16:28:09 »» nirik is still +1 16:28:11 +1 16:28:26 +1 16:28:35 jwb? 16:30:14 +1 16:30:25 #agreed Append the Default Services criteria with "Installation of the package providing the unit auto-started by this preset may not change the behavior of any other service running on the system. Exceptions may be granted by FESCo on a case-by-case basis." (+6,0,-0) 16:30:28 sorry, pulling double meeting duty :\ 16:30:34 #action sgallagh to draft the guideline change and add this to the Bugzilla template 16:30:47 So the next part is on the thermald service itself 16:31:22 Personally I think thermald is very good on most modern systems. Unfortunately the Fedora userbase is not made up entirely of modern systems. 16:31:29 As for the service, I'm generally opposed to enabling it by default, but if the kernel folks think it should be enabled, I can be swayed. 16:31:46 jforbes: isn't it just papering over bugs in the kernel that should be fixed there? 16:31:59 I am against enabling by default 16:32:04 jforbes: has anyone proposed adding it by default? 16:32:12 I mean it may be easier to tweak and help some people, but no telling if it breaks others... and then if it doesn't run... 16:32:18 nirik: potentially in some areas 16:32:19 dgilmore: yes 16:32:42 https://bugzilla.redhat.com/show_bug.cgi?id=1440479 requests it be added as default on in presets 16:32:54 nirik: thats not what I asked 16:33:04 then can you expand? 16:33:18 nirik: I mean adding to @core or some other comps group where the package would be installed by default 16:33:40 as opposed to a user having to do "yum install thermald" 16:33:48 No, that has not been requested as far as I know 16:34:11 not yet that I know of either. 16:34:16 but it easily could be 16:34:23 jforbes: what part of enabling by default are you against? 16:34:30 being installed on all systems? 16:34:39 or having it run by default when installed?> 16:35:21 I realise it would get tricky if we wanted to make sure it was disabled if in @core and all installs. 16:35:38 I am guessing the expectation from people installing it would be that it runs 16:35:41 well, if someone wanted to dnf install it, they would likely easily be able to enable it then... just like many other services 16:35:52 sure 16:35:59 dgilmore: That is a valid point. I suppose if a user specifically requests it, having it default on wouldn't be so bad. Though what happens when it gets brought into the default install for workstation or similar? 16:36:00 but that may be unexpected 16:36:26 jforbes: its a rock and a hard place 16:36:33 What also happens if some other package pulls it in? 16:37:05 dgilmore: I don't really think it is. There are plenty of services that people can install and then have to enable 16:37:19 jforbes: right 16:37:37 which in cases of having to configure is expected 16:38:21 in the end I am going to defer to what jforbes thinks is best, he is the expert. I just want to make sure we cover the bases in the discussion 16:39:23 I think in the case of someone having to manually install the package enabled by default is fine. but if everyone gets it by default and some % of cases it hurts things, we should disable by default 16:39:23 »» sgallagh nods 16:39:40 dgilmore: If we could ensure that the package would never end up as a part of a default package set, I would be fine with enabled by default. 16:39:58 jforbes: which we can not do 16:40:15 we would have to have something to trigger a big fat warning if it happened 16:40:57 so i think erring on the side of caution means we do not alllow the service to be enabled by default 16:41:56 The biggest problem is, while it works for a lot of users outside of the box, but for those it doesn't, it is going to be more subtle, and they may not notice, they may just notice a performance problem and assume Fedora sucks, or things might become more difficult to debug 16:42:31 I think the best course here is to be cautious. 16:42:58 »» nirik sees no reason to enable it by default. :) 16:43:04 proposal: thermald.service should not be enabled by default 16:43:09 +1 16:43:10 +1 16:43:24 +1 16:43:30 +1 16:44:23 also of note, my use of commas in stream of consciousness writing sucks... 16:44:30 jwb maxamillion ? 16:44:36 maxamillion: jwb: ^ 16:44:43 i defer to jforbes 16:44:53 so +1? 16:45:01 sorry guys, i'm really going to have to drop. too many meetings right now 16:45:11 i think i've logged my vote in most of the rest of the tickets 16:45:12 +1 16:45:13 sorry 16:45:22 I can't multi-task to save my life today :/ 16:45:23 jwb: cool, thanks 16:45:30 #agreed thermald.service should not be enabled by default (+6,0,-0) 16:45:46 thanks jwb 16:45:51 #topic #1699 meeting: xml-security-c new maintainer request 16:46:00 »» jforbes has changed the topic to: 1699 meeting: xml-security-c new maintainer request 16:46:06 .fesco 1699 16:46:14 https://pagure.io/fesco/issue/1699 16:46:55 I guess the request here is to grant the permission request in pkgdb? 16:47:14 some links in the issue wuld have been nice 16:47:28 Yeah, there is not a lot to go on here 16:47:34 well, and perhaps orphan the other packages from that maintainer 16:47:52 but yeah, the poor unresponsive maintainer process wasn't fully followed again. :( 16:47:56 I see the request on Feb 20 for volunteers 16:48:44 its kinda hard to see all with phx2 down 16:48:52 Yeah. 16:49:02 :/ 16:49:12 I'd probibly be ok with orphaning that maintainers packages, but not sure how many or if they were active in others. 16:49:36 maybe we sohould ask for more info on the request 16:49:55 I'm looking volunteers for maintaining xml-security-c package in Fedora. Current version is old in our repos and for example esteid (Estonian ID card) packages depend on newer xml-security-c (with openssl 1.1 support). I've already contacted anttix who is current package administrator to give committer rights to bruno and also contacted bruno to find out if he is still interested in maintaining it. Negative. And I'm also not too confident of mai 16:50:02 So I'm seeking towards devel list to find out, are there any volunteers with enough courage to update and maintain it. 16:50:05 thats the body of the request 16:50:15 They are POC on 4 packages, co-maintainer on about 6 more 16:50:55 seems like a poorly done non responsive maintainer request 16:50:55 Right, there is more to the thread. "Anttix, the initial maintainer of this package, has responded to my e-mail once. Have you contacted him directly?" which was unanswered 16:51:49 It was also pointed out in the thread that the non-responsive maintainer policy be initiated, with a link to the policy 16:52:06 That was Mar 30 16:52:27 so I guess we push back and ask policy to be followed? 16:52:48 well, the maintainer really may be unersponsive. 16:52:57 I would say so. Unfortunately I can't use pkgdb to actually see the current status 16:52:59 I can't tell if there's unanswered bugs for example. ;( 16:53:21 hard to do anything right now 16:53:26 should this be tabled until things are back online and we can gather all the info? 16:53:35 Okay, defer seems to make the most sense 16:53:40 yeah, defer is fine. 16:53:54 +1 16:54:04 +1 to defer 16:54:21 #agreed xml-security-c new maintainer request is deferred until things are online and we have more insight. 16:54:35 #topic #1700 Lulzbot 3d printer firmware 16:54:41 »» jforbes has changed the topic to: 1700 Lulzbot 3d printer firmware 16:54:49 .fesco 1700 16:54:57 https://pagure.io/fesco/issue/1700 16:55:22 I think I am okay with shipping the prebuilt firmware while the issues are debugged. 16:55:28 »» nirik is +1 but also curious as to what the cause is. ;) 16:55:37 but I wonder if we should set a timelimit 16:55:50 or allow it only in f25 and f26 16:56:02 and ban from rawhide so it has to be fixed before f27 16:56:25 that leaves rawhide users in a bit of a lerch. 16:56:33 »» spot would like to know what is broken, but arduino cross compiler is a deep dark hole 16:56:33 (not that there are likely too many affected) 16:57:03 I am curious as to the cause as well. I expect spot to chase it down. I am sure that he would get annoyed every time there is an update 16:57:24 Oh, hi spot! 16:57:57 jforbes: other half of the issue is that the upstream company is trying to hire someone to work on their firmware. :) 16:58:14 previous person left the company 16:58:16 spot: is it just us using a newer compiler? 16:58:22 dgilmore: possibly. 16:58:37 I don't think that leaving it out of rawhide is a good idea, though I don't see a problem with making our approval conditional on a release lifespan 16:58:40 upstream just points to the older debian compiler and says "we dont have any issues" 16:59:03 »» spot is fine with a temporary approval 17:00:08 So a temporary approval that would last through the F26 timeline, but require either local build or another request by F27 branch time? 17:00:29 as it is exceptional, limiting its life seems wise. we can always extend if need be. 17:00:39 jforbes: That sounds reasonable to me 17:00:50 jforbes: that seems reasonable 17:01:21 we can always extend if things have not been sorted but deny if its not been attempted 17:01:54 +1 for limited exception that can be extended if necessary 17:01:59 sure. +1 17:02:00 #proposal: packaging lulzbot prebuilt firmware along with source is acceptable though the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested 17:02:14 s/though/through/ 17:02:20 Otherwise, +1 17:02:29 #undo 17:02:34 #proposal: packaging lulzbot prebuilt firmware along with source is acceptable through the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested 17:02:39 +1 17:02:48 +1 17:03:14 #agreed packaging lulzbot prebuilt firmware along with source is acceptable through the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested (+5,0,-0) 17:03:26 #topic Next week's chair 17:03:35 »» jforbes has changed the topic to: Next week's chair 17:03:38 Any takers? 17:04:19 I can probably cover it next week. 17:04:46 I can take next week 17:04:55 if sgallagh isn't able or doesn't want it :) 17:05:03 you guys want to fight it out? :) 17:05:07 Be my guest. 17:05:23 yeah, I'll do it ... I haven't chair'd in a while, probably my turn 17:05:46 #action maxamillion to chair next weeks meeting 17:05:56 #topic Open Floor 17:06:02 »» jforbes has changed the topic to: Open Floor 17:06:25 nada aqui 17:06:46 If no one has anything, I will close out in 2 minutes 17:07:27 »» nirik has nothing 17:07:44 I'm done 17:08:10 Of note, meeting minutes will be late. I am going to wait for infra to feed this through the bot to get a proper summary. Laziness and all that 17:08:19 jforbes: +1 17:08:42 jforbes: cheers 17:08:49 #endmeeting 17:08:58 Thanks for coming 17:09:00 thanks jforbes 17:09:30 »» jforbes has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule 17:10:26 jforbes: thanks for hosting 17:11:23 Thanks jforbes