14:59:55 #startmeeting FESCO (2020-01-13) 14:59:55 Meeting started Mon Jan 13 14:59:55 2020 UTC. 14:59:55 This meeting is logged and archived in a public location. 14:59:55 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:59:55 The meeting name has been set to 'fesco_(2020-01-13)' 14:59:57 #meetingname fesco 14:59:57 The meeting name has been set to 'fesco' 15:00:03 #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell 15:00:03 Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 15:00:07 #topic init process 15:00:12 .hello psabata 15:00:13 contyk: psabata 'Petr Šabata' 15:00:17 .hello2 15:00:18 bookwar: bookwar 'Aleksandra Fedorova' 15:00:20 .hello dcantrell 15:00:22 dcantrell: Sorry, but you don't exist 15:00:27 .hello dcantrel 15:00:28 dcantrell: dcantrel 'David Cantrell' 15:00:51 .hello2 15:00:52 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:01:10 I'm from mobile, so might not respond timely :) 15:01:24 morning 15:01:31 .hello2 15:01:32 bcotton: bcotton 'Ben Cotton' 15:01:42 .hello2 15:01:44 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:48 I'm here if needed for quorum, but I'm in a training class today. 15:01:50 so zbyszek says my agenda mail didn't make it 15:02:09 although I see it in my mail (probably because I sent it, not necessarily because I received it) 15:02:12 .hello2 15:02:15 decathorpe: decathorpe 'Fabio Valentini' 15:02:28 yeah I didn't get the agenda either 15:02:53 .hallo churchyard 15:02:56 .hello churchyard 15:02:57 mhroncok: churchyard 'Miro Hrončok' 15:03:00 I am here, but not for 100 % and will leave in cca 1 hour 15:03:14 WEll, that's kinda odd. 15:03:29 Anyway, there are three items on the agenda; two from last week and one new. 15:03:31 contyk: when did you send it? couple minutes ago, or on friday? 15:03:48 mhroncok: ~2 hours ago, I think. 15:04:01 I guess when you changed some tickets as announced? I wondered about it when I didn't get the agenda email :) 15:04:40 Yeah, I do that after I sent the email 15:04:44 Hmm 15:04:49 Well, let's begin... 15:05:16 #topic #2310 F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ 15:05:18 https://pagure.io/fesco/issue/2310 15:05:22 .fesco 2310 15:05:23 contyk: Issue #2310: F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ - fesco - Pagure.io - https://pagure.io/fesco/issue/2310 15:05:38 tstellar: Are you around? 15:05:41 contyk: yes 15:06:13 tstellar: is your motivation mostly to do the testing you are reporting back on devel ML? 15:08:01 mhroncok: For me yes, but I thin there are others intersted in having this change avaialble for general Fedora use. 15:08:57 So make take is that while this isn't perfect, it helps some poeple some of the time, and that is good enough for me. 15:09:51 gcc is not something that is used in early boot or anything, so using alternatives (which makes things potentially a bit more brittle), is OK. 15:10:30 I'm also fine with this, as noted in the ticket. 15:10:34 I'd like to require that our packaging guidelines disallow the use of /usr/bin/cc or /usr/bin/c++ in favor of the explicit compiler. 15:10:35 mhroncok: you said in ticket that " I think that all the benefits described in the proposal are achievable without alternatives." could you expand on that... 15:10:45 Otherwise, I'm basically +1 15:10:49 sgallagh: why? 15:10:52 nirik: sure 15:11:14 dcantrell: So that running `rpmbuild` on one of our SRPMs remains consistent and expected. 15:11:21 sgallagh: I don't think that is desirable. Most programs should be portable and should not care what compiler and in what version is used. 15:11:36 nirik: Setting up alternative buildroots for testing. - no need for alternatives, just redefine the macros or override the files 15:11:42 tstellar: what do you think the use case is for setting clang as cc system-wide? 15:11:43 zbyszek: But we (Fedora) *should* be opinionated. 15:11:54 sgallagh: that's reasonable, but I'd prefer to leave that decision up to the packager. in some packages, yes, you want that. in others, I really don't care what compiler is used 15:11:58 - Installing a gcc wrapper script to /usr/bin/cc to help migrate packages to new compiler flags or to capture statistics about compiler usage: you can just override the file 15:12:12 mhroncok: ok, fair enough 15:12:20 - Letting users experiment easily with alternate compilers. - users can experiment with gcc/clang via different means than /usr/bin/cc 15:12:24 dcantrell: I do care. Changing compilers on the system means changing the available security options too 15:12:38 - Easily switch between system gcc and a development version of gcc. - you would need to switch /usr/bin/gcc for that, nto cc 15:13:14 do note we also have: https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler 15:13:37 sgallagh: but security features can be validated after build anyway. 15:13:52 if the users want to change what cc is, they can create ~/.local/bin/cc 15:14:05 if the sysadmins want to copie with clang, they should do that explicitly 15:14:11 *compile 15:14:18 decathorpe: To make it easier to bulid arbitrary code bases using different compilers. 15:14:34 I see this as a fallback for build systems that just call the absolute paths 15:14:52 Or the easiest way to switch the compiler without fiddling with all kinds of env variables or PATH 15:15:07 I also don't have any issues with alternatives and don't see this as really breaking anyhing 15:15:11 So why not allow it? 15:15:19 it adds scriplets 15:15:22 that's my thinking on this 15:15:23 we want to get rid of them 15:15:29 so ... messing with fedora instead of "fixing" upstreams (for your definition of "mess" and "fix")? 15:16:30 gcc is very much a "leaf" package (i.e. not something that is installed in minimal systems), so the scriptlets there are not that painful. 15:16:34 I'm just trying to be practical here; sometimes you just get your hands on a large messy project that you need to build in some environment 15:17:09 You can go and "fix" it but it'd just be more convenient to override your workstation compiler 15:17:22 Because honstly, that's our major use case here, developer workstations 15:17:22 As I said, I'm fine with allowing this, I just don't want Fedora packagers allowed to rely on it. 15:17:48 sgallagh: ok, that's fair. then 'cc' and 'c++' are purely for users and not package maintainers 15:17:50 decathorpe: Yeah, I guess. The thing is that fixing upstream is not always practical for a user if for example you aren't familiar with a code base. 15:17:56 dcantrell: Exactly 15:18:17 decathorpe: Also, for packages that hard-code /usr/bin/gcc, the only way to really fix it is to hard-code /usr/bin/cc instead. 15:18:24 I am ok with adding to or beginning a list of executables that maintainers should not rely on for this purpose 15:19:17 I ma OK to change my vote for 0 if we ban the usage of cc in Fedora packages 15:19:35 mhroncok: that would mean you need to fix all buildsystems and such 15:19:37 I ma OK to chage my vote for +1 if we have a volunteer to find all sch cases and fix them :D 15:19:42 That's much more invasive change 15:19:46 mhroncok: I don't think that this is necessary. In a mock chroot, cc == gcc, period. 15:20:01 right, we already gained BuildRequires: gcc across the board 15:20:06 So even a hypothetical package which uses /bin/cc DTRT anyway. 15:20:27 mhroncok: cmake defaults to cc and c++. We would need to add CC=%{__cc} and CXX=%{__cxx} to __build_pre or something. 15:20:32 as long as they don't BR /usr/bin/cc 15:20:37 zbyszek: I just want `rpmbuild --rebuild` of a Fedora package to always DTRT too 15:21:07 But if you install local customizations, you can *always* make packages build differently. 15:21:15 following RFC terms, I would say maintainers SHOULD NOT rely on 'cc' and 'c++' but it's not explicitly forbidden. however, if that breaks their build, the fix would be in their package 15:21:25 Yeah, I disagree with sgallagh's last point 15:21:48 Dunno, I put a custom 'mv' in $PATH, that's on me, and there's no realistic way for .spec file authors to prevent that. 15:21:53 well, we already have the compiler rule, it would cover this no? 15:21:59 "rpmbuild --rebuild" is affected by many, many things; and I'd actually like it to use my selected compiler if I actually switched to the alternative version 15:22:10 One only gets a canonical build in the canonical environment... 15:22:23 * sgallagh shrugs 15:22:30 vote? 15:22:39 I'm comfortable with dcantrell's RFC phrasing. 15:22:46 I would expect a local mock rebuild of a Fedora SRPM to DTRT, not 'rpmbuild --rebuild' from my user account 15:23:06 dcantrell: +1 15:23:09 * nirik is a weak +1 I guess... 15:23:12 if this is only for "end users" and for packaging, cc==gcc, then I'll change my vote to 0, I guess ... 15:23:51 mhroncok: I'm good to vote 15:23:52 so are voting on the change proposal as is? 15:24:23 okay 15:24:38 so I'm +1, as stated in the ticket, just ftr 15:25:00 me too, +1 as in the ticket 15:25:08 +1 15:25:17 0 (assuming accidental clang builds are treated as bugz, which is the case with the current guidelines anyway) 15:25:28 +1 15:25:36 +1 15:25:38 +1 from me 15:26:01 decathorpe 0?, ignatenkobrain ? 15:26:15 -1, sorry 15:26:29 ack 15:27:09 #agreed F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ is approved (+6, 2, -1) 15:27:51 Let's see what really breaks :) 15:28:05 #topic #2309 F32 System-Wide Change: Enable fstrim.timer by default 15:28:07 https://pagure.io/fesco/issue/2309 15:28:10 .fesco 2309 15:28:11 contyk: Issue #2309: F32 System-Wide Change: Enable fstrim.timer by default - fesco - Pagure.io - https://pagure.io/fesco/issue/2309 15:28:29 * cmurf standing by to answer questions 15:28:50 Awesome. 15:29:21 So ignatenkobrain voted -1 in the ticket "based on the ML feedback" 15:29:21 * mhroncok still abstains 15:29:31 ok, some questions from me (typing) 15:29:57 contyk: I am -0 after reading discussion more 15:30:14 I've read through the ML and it's quite circular, but the concerns and questions I have are 1) why doesn't the kernel do this by default, 2) are there risks/concerns for data loss, 3) is there a performance impact for users? 15:30:25 * nirik is +1 15:30:55 (and based on what I've read, I do not feel this is an appropriate system-wide default and prefer that it be user opt-in on a per system basis. as of now I am -1, but convince me otherwise) 15:30:57 * zbyszek is +1 too 15:31:54 Re 3: the performance impact should be mostly positive, i.e. faster disk, except for a potential short delay at midnight or at machine boot. 15:33:05 1) I answered this twice in the mailing list discussion, I'm not sure what can be added to it. The file system folks have fairly consistently said this should be done on a timer approach, rather than with discard mount option. 15:33:06 Re 1: the kernel "doesn't know" if a specific SSD will be impacted badly (or well) by online trimming, so it leaves the decision to user space. And userspace in this case can easily do a periodic offline trim more easily than the kernel. 15:33:11 is there data to back up the performance claims or is mostly subjective? 15:33:16 The discard mount option is useful as an opt-in. 15:34:07 2) there are risks for data loss, those have either seen firmware fixes or have been blacklisted in the kernel 15:34:11 dcantrell: it varies by ssd and various other factors which we don't know. There's plenty of anecdata that it helps in specific cases. 15:35:09 3) performance depends on how the storage stack is created, it's case specific but overall it's mostly neutral, some positives. 15:36:40 ok, so the kernel doesn't know which keeps it out of the business of maintaining white and/or black lists. that's fine 15:36:55 there's a fair degree of positive in the cloud and server use case with thin provisioning, and sparse files 15:37:12 at some point I imagine that will be needed which means the risk for data loss is there. my concern is increasing the likelihood of data loss by enabling this by default for all users and whether or not that's worth it 15:37:31 does everyone here have fstrim enabled? 15:38:15 * nirik should enable it. I have just manually run it in the past. 15:38:19 the kernel does know, the blacklists are in libata - i'm not sure about NVMe drives, I haven't looked at that code 15:38:38 I have it either enabled or am running it manually. no data loss so far 15:38:39 * zbyszek the same as nirik. I have it on on some machines, but not consistently. 15:38:42 * contyk runs it manually once a month or so 15:39:25 I don't think FESCo can anticipate catastrophic edge case bugs of any sort - that could happen at anytime with anything. 15:39:33 very true 15:40:05 storage makes me scary. I'm remember many many many many years ago when early versions of reiserfs would trim the ends of files and the response was "ooops, just upgrade and reformat" 15:40:05 There is some magic incantation aspect to fstrim.timer but it is thus far the path of least resistence and risk, for the most gain. 15:40:13 Most people won't experience anything different. 15:40:48 it is a bit worrying to know that there is a blacklist and not a whitelist 15:40:55 there are both 15:41:00 I guess the concerns I have are not different than the typical risk concerns and no one has pointed out any negative impact. Only subjective improvement and positive impacts to cloud instances. 15:41:01 it depends on the firmware bug 15:41:04 I will change to a weak +1 15:42:30 ok, same here, +1 15:42:38 And as I'm looking at it, I don't see non-queued trim blacklist. I see a queued trim blacklist - i.e. the drive advertises support for queued trim, but somehow it's broken. 15:42:50 Cool. 15:42:52 So it's really a narrow condition. 15:42:57 sgallagh: Do you want to vote on this one? 15:43:23 And fstrim.timer doesn't depend on queued trim anyway, the expectation with a weekly trim is it's a one size fits all, queued or non-queued 15:43:37 0 15:44:19 #agreed F32 System-Wide Change: Enable fstrim.timer by default is approved (+6, 3, -0) 15:44:36 cmurf: Thank you. 15:44:46 cmurf: thank you 15:44:49 you are welcome, thanks everyone 15:45:06 #topic #2312 Python2 exception for mailman 15:45:12 https://pagure.io/fesco/issue/2312 15:45:16 .fesco 2312 15:45:17 contyk: Issue #2312: Python2 exception for mailman - fesco - Pagure.io - https://pagure.io/fesco/issue/2312 15:45:48 NotEnoughInformationException 15:45:59 * nirik isn't clear if we have buy in from all the maintainers. 15:46:11 -ENODATA ;) 15:46:15 yeah, I think the dependent package maintainers need to weigh in 15:46:26 I was pretty sure we were far down the path of putting python2 out to pasture 15:46:50 dcantrell: yes, here they have stopped me one day before retirement 15:46:59 hehe :) 15:47:25 proposal... 15:47:50 if they don't provide the requested data by the end of January, I retire the package. They can unretire it when ported 15:48:00 +1 15:48:05 sounds good to me. gives them another 2 weeks 15:48:12 (+1) 15:48:12 +1 15:48:14 +1 15:48:36 +1 15:49:06 where requested data is: time estimate and approval from all py2 dependencies maintainers and/or pghmcfc 15:49:38 +1 15:50:06 ignatenkobrain, sgallagh: ? 15:50:39 +1 15:52:08 #agreed Time estimate and approval from relevant parties should be provided by the end of the months or the package will be retired; can be unretired later when ported (+8, 0, -0) 15:52:26 Alright. 15:52:31 #topic Next week's chair 15:52:42 I can do it 15:52:47 I might miss next meeting, apologies. 15:52:54 mhroncok: Thanks. 15:52:56 and I can walk somebody new trough it as well 15:53:03 #action mhroncok will chair the next meeting. 15:53:08 #topic Open Floor 15:53:23 mhroncok: I'd like to understand the process so I can chair a meeting at some point 15:53:38 dcantrell: it's basically all on https://fedoraproject.org/wiki/FESCo_meeting_process 15:53:42 dcantrell: I will ping you on Friday 15:53:51 on the cc/c++ change, did we agree to add the SHOULD NOT language to the packaging guide? 15:54:01 contyk, mhroncok: thanks 15:54:02 nope 15:54:07 ok 15:54:47 Closing in a minute if there's nothing for the open floor. 15:54:53 I had no other question 15:55:15 Good! 15:55:41 +1 15:55:54 I need to find out why my mails don't make it to the list 15:56:04 Anyway... 15:56:07 #endmeeting