14:59:55 <contyk> #startmeeting FESCO (2020-01-13)
14:59:55 <zodbot> Meeting started Mon Jan 13 14:59:55 2020 UTC.
14:59:55 <zodbot> This meeting is logged and archived in a public location.
14:59:55 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:55 <zodbot> The meeting name has been set to 'fesco_(2020-01-13)'
14:59:57 <contyk> #meetingname fesco
14:59:57 <zodbot> The meeting name has been set to 'fesco'
15:00:03 <contyk> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell
15:00:03 <zodbot> Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:07 <contyk> #topic init process
15:00:12 <contyk> .hello psabata
15:00:13 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:17 <bookwar> .hello2
15:00:18 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:00:20 <dcantrell> .hello dcantrell
15:00:22 <zodbot> dcantrell: Sorry, but you don't exist
15:00:27 <dcantrell> .hello dcantrel
15:00:28 <zodbot> dcantrell: dcantrel 'David Cantrell' <dcantrell@redhat.com>
15:00:51 <ignatenkobrain> .hello2
15:00:52 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:01:10 <ignatenkobrain> I'm from mobile, so might not respond timely :)
15:01:24 <nirik> morning
15:01:31 <bcotton> .hello2
15:01:32 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:42 <zbyszek> .hello2
15:01:44 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:48 <sgallagh> I'm here if needed for quorum, but I'm in a training class today.
15:01:50 <contyk> so zbyszek says my agenda mail didn't make it
15:02:09 <contyk> although I see it in my mail (probably because I sent it, not necessarily because I received it)
15:02:12 <decathorpe> .hello2
15:02:15 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:02:28 <decathorpe> yeah I didn't get the agenda either
15:02:53 <mhroncok> .hallo churchyard
15:02:56 <mhroncok> .hello churchyard
15:02:57 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:03:00 <mhroncok> I am here, but not for 100 % and will leave in cca 1 hour
15:03:14 <contyk> WEll, that's kinda odd.
15:03:29 <contyk> Anyway, there are three items on the agenda; two from last week and one new.
15:03:31 <mhroncok> contyk: when did you send it? couple minutes ago, or on friday?
15:03:48 <contyk> mhroncok: ~2 hours ago, I think.
15:04:01 <decathorpe> I guess when you changed some tickets as announced? I wondered about it when I didn't get the agenda email :)
15:04:40 <contyk> Yeah, I do that after I sent the email
15:04:44 <contyk> Hmm
15:04:49 <contyk> Well, let's begin...
15:05:16 <contyk> #topic #2310 F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
15:05:18 <contyk> https://pagure.io/fesco/issue/2310
15:05:22 <contyk> .fesco 2310
15:05:23 <zodbot> 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 <contyk> tstellar: Are you around?
15:05:41 <tstellar> contyk: yes
15:06:13 <mhroncok> tstellar: is your motivation mostly to do the testing you are reporting back on devel ML?
15:08:01 <tstellar> mhroncok: For me yes, but I thin there are others intersted in having this change avaialble for general Fedora use.
15:08:57 <zbyszek> 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 <zbyszek> 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 <contyk> I'm also fine with this, as noted in the ticket.
15:10:34 <sgallagh> 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 <nirik> 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 <sgallagh> Otherwise, I'm basically +1
15:10:49 <dcantrell> sgallagh: why?
15:10:52 <mhroncok> nirik: sure
15:11:14 <sgallagh> dcantrell: So that running `rpmbuild` on one of our SRPMs remains consistent and expected.
15:11:21 <zbyszek> 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 <mhroncok> nirik: Setting up alternative buildroots for testing. - no need for alternatives, just redefine the macros or override the files
15:11:42 <decathorpe> tstellar: what do you think the use case is for setting clang as cc system-wide?
15:11:43 <sgallagh> zbyszek: But we (Fedora) *should* be opinionated.
15:11:54 <dcantrell> 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 <mhroncok> - 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 <nirik> mhroncok: ok, fair enough
15:12:20 <mhroncok> - Letting users experiment easily with alternate compilers. - users can experiment with gcc/clang via different means than /usr/bin/cc
15:12:24 <sgallagh> dcantrell: I do care. Changing compilers on the system means changing the available security options too
15:12:38 <mhroncok> - 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 <nirik> do note we also have: https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler
15:13:37 <dcantrell> sgallagh: but security features can be validated after build anyway.
15:13:52 <mhroncok> if the users want to change what cc is, they can create ~/.local/bin/cc
15:14:05 <mhroncok> if the sysadmins want to copie with clang, they should do that explicitly
15:14:11 <mhroncok> *compile
15:14:18 <tstellar> decathorpe: To make it easier to bulid arbitrary code bases using different compilers.
15:14:34 <contyk> I see this as a fallback for build systems that just call the absolute paths
15:14:52 <contyk> Or the easiest way to switch the compiler without fiddling with all kinds of env variables or PATH
15:15:07 <contyk> I also don't have any issues with alternatives and don't see this as really breaking anyhing
15:15:11 <contyk> So why not allow it?
15:15:19 <mhroncok> it adds scriplets
15:15:22 <dcantrell> that's my thinking on this
15:15:23 <mhroncok> we want to get rid of them
15:15:29 <decathorpe> so ... messing with fedora instead of "fixing" upstreams (for your definition of "mess" and "fix")?
15:16:30 <zbyszek> 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 <contyk> 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 <contyk> You can go and "fix" it but it'd just be more convenient to override your workstation compiler
15:17:22 <contyk> Because honstly, that's our major use case here, developer workstations
15:17:22 <sgallagh> As I said, I'm fine with allowing this, I just don't want Fedora packagers allowed to rely on it.
15:17:48 <dcantrell> sgallagh: ok, that's fair.  then 'cc' and 'c++' are purely for users and not package maintainers
15:17:50 <tstellar> 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 <sgallagh> dcantrell: Exactly
15:18:17 <tstellar> 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 <dcantrell> I am ok with adding to or beginning a list of executables that maintainers should not rely on for this purpose
15:19:17 <mhroncok> I ma OK to change my vote for 0 if we ban the usage of cc in Fedora packages
15:19:35 <ignatenkobrain> mhroncok: that would mean you need to fix all buildsystems and such
15:19:37 <mhroncok> 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 <ignatenkobrain> That's much more invasive change
15:19:46 <zbyszek> mhroncok: I don't think that this is necessary. In a mock chroot, cc == gcc, period.
15:20:01 <dcantrell> right, we already gained BuildRequires: gcc across the board
15:20:06 <zbyszek> So even a hypothetical package which uses /bin/cc DTRT anyway.
15:20:27 <tstellar> 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 <mhroncok> as long as they don't BR /usr/bin/cc
15:20:37 <sgallagh> zbyszek: I just want `rpmbuild --rebuild` of a Fedora package to always DTRT too
15:21:07 <zbyszek> But if you install local customizations, you can *always* make packages build differently.
15:21:15 <dcantrell> 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 <contyk> Yeah, I disagree with sgallagh's last point
15:21:48 <zbyszek> 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 <nirik> well, we already have the compiler rule, it would cover this no?
15:21:59 <contyk> "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 <zbyszek> One only gets a canonical build in the canonical environment...
15:22:23 * sgallagh shrugs
15:22:30 <mhroncok> vote?
15:22:39 <sgallagh> I'm comfortable with dcantrell's RFC phrasing.
15:22:46 <dcantrell> I would expect a local mock rebuild of a Fedora SRPM to DTRT, not 'rpmbuild --rebuild' from my user account
15:23:06 <contyk> dcantrell: +1
15:23:09 * nirik is a weak +1 I guess...
15:23:12 <decathorpe> 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 <dcantrell> mhroncok: I'm good to vote
15:23:52 <contyk> so are voting on the change proposal as is?
15:24:23 <contyk> okay
15:24:38 <contyk> so I'm +1, as stated in the ticket, just ftr
15:25:00 <zbyszek> me too, +1 as in the ticket
15:25:08 <sgallagh> +1
15:25:17 <mhroncok> 0 (assuming accidental clang builds are treated as bugz, which is the case with the current guidelines anyway)
15:25:28 <dcantrell> +1
15:25:36 <nirik> +1
15:25:38 <bookwar> +1 from me
15:26:01 <contyk> decathorpe 0?, ignatenkobrain ?
15:26:15 <ignatenkobrain> -1, sorry
15:26:29 <contyk> ack
15:27:09 <contyk> #agreed F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ is approved (+6, 2, -1)
15:27:51 <contyk> Let's see what really breaks :)
15:28:05 <contyk> #topic #2309 F32 System-Wide Change: Enable fstrim.timer by default
15:28:07 <contyk> https://pagure.io/fesco/issue/2309
15:28:10 <contyk> .fesco 2309
15:28:11 <zodbot> 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 <contyk> Awesome.
15:29:21 <contyk> So ignatenkobrain voted -1 in the ticket "based on the ML feedback"
15:29:21 * mhroncok still abstains
15:29:31 <dcantrell> ok, some questions from me (typing)
15:29:57 <ignatenkobrain> contyk: I am -0 after reading discussion more
15:30:14 <dcantrell> 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 <dcantrell> (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 <zbyszek> 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 <cmurf> 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 <zbyszek> 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 <dcantrell> is there data to back up the performance claims or is mostly subjective?
15:33:16 <cmurf> The discard mount option is useful as an opt-in.
15:34:07 <cmurf> 2) there are risks for data loss, those have either seen firmware fixes or have been blacklisted in the kernel
15:34:11 <zbyszek> 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 <cmurf> 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 <dcantrell> 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 <cmurf> there's a fair degree of positive in the cloud and server use case with thin provisioning, and sparse files
15:37:12 <dcantrell> 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 <dcantrell> 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 <cmurf> 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 <decathorpe> 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 <cmurf> I don't think FESCo can anticipate catastrophic edge case bugs of any sort - that could happen at anytime with anything.
15:39:33 <dcantrell> very true
15:40:05 <dcantrell> 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 <cmurf> 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 <cmurf> Most people won't experience anything different.
15:40:48 <bookwar> it is a bit worrying to know that there is a blacklist and not a whitelist
15:40:55 <cmurf> there are both
15:41:00 <dcantrell> 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 <cmurf> it depends on the firmware bug
15:41:04 <dcantrell> I will change to a weak +1
15:42:30 <bookwar> ok, same here, +1
15:42:38 <cmurf> 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 <contyk> Cool.
15:42:52 <cmurf> So it's really a narrow condition.
15:42:57 <contyk> sgallagh: Do you want to vote on this one?
15:43:23 <cmurf> 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 <sgallagh> 0
15:44:19 <contyk> #agreed F32 System-Wide Change: Enable fstrim.timer by default is approved (+6, 3, -0)
15:44:36 <contyk> cmurf: Thank you.
15:44:46 <dcantrell> cmurf: thank you
15:44:49 <cmurf> you are welcome, thanks everyone
15:45:06 <contyk> #topic #2312 Python2 exception for mailman
15:45:12 <contyk> https://pagure.io/fesco/issue/2312
15:45:16 <contyk> .fesco 2312
15:45:17 <zodbot> contyk: Issue #2312: Python2 exception for mailman - fesco - Pagure.io - https://pagure.io/fesco/issue/2312
15:45:48 <mhroncok> NotEnoughInformationException
15:45:59 * nirik isn't clear if we have buy in from all the maintainers.
15:46:11 <zbyszek> -ENODATA ;)
15:46:15 <dcantrell> yeah, I think the dependent package maintainers need to weigh in
15:46:26 <dcantrell> I was pretty sure we were far down the path of putting python2 out to pasture
15:46:50 <mhroncok> dcantrell: yes, here they have stopped me one day before retirement
15:46:59 <dcantrell> hehe  :)
15:47:25 <mhroncok> proposal...
15:47:50 <mhroncok> 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 <nirik> +1
15:48:05 <decathorpe> sounds good to me. gives them another 2 weeks
15:48:12 <decathorpe> (+1)
15:48:12 <bookwar> +1
15:48:14 <dcantrell> +1
15:48:36 <contyk> +1
15:49:06 <mhroncok> where requested data is: time estimate and approval from all py2 dependencies maintainers and/or pghmcfc
15:49:38 <zbyszek> +1
15:50:06 <contyk> ignatenkobrain, sgallagh: ?
15:50:39 <sgallagh> +1
15:52:08 <contyk> #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 <contyk> Alright.
15:52:31 <contyk> #topic Next week's chair
15:52:42 <mhroncok> I can do it
15:52:47 <zbyszek> I might miss next meeting, apologies.
15:52:54 <contyk> mhroncok: Thanks.
15:52:56 <mhroncok> and I can walk somebody new trough it as well
15:53:03 <contyk> #action mhroncok will chair the next meeting.
15:53:08 <contyk> #topic Open Floor
15:53:23 <dcantrell> mhroncok: I'd like to understand the process so I can chair a meeting at some point
15:53:38 <contyk> dcantrell: it's basically all on https://fedoraproject.org/wiki/FESCo_meeting_process
15:53:42 <mhroncok> dcantrell: I will ping you on Friday
15:53:51 <dcantrell> on the cc/c++ change, did we agree to add the SHOULD NOT language to the packaging guide?
15:54:01 <dcantrell> contyk, mhroncok: thanks
15:54:02 <mhroncok> nope
15:54:07 <dcantrell> ok
15:54:47 <contyk> Closing in a minute if there's nothing for the open floor.
15:54:53 <dcantrell> I had no other question
15:55:15 <contyk> Good!
15:55:41 <ignatenkobrain> +1
15:55:54 <contyk> I need to find out why my mails don't make it to the list
15:56:04 <contyk> Anyway...
15:56:07 <contyk> #endmeeting