18:06:04 <dgilmore> #startmeeting FESCO (2015-01-21) 18:06:04 <zodbot> Meeting started Wed Jan 21 18:06:04 2015 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:06:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:06:04 <dgilmore> #meetingname fesco 18:06:04 <zodbot> The meeting name has been set to 'fesco' 18:06:04 <dgilmore> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:06:04 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:06:07 <dgilmore> #topic init process 18:06:12 * mattdm is here 18:06:15 <sgallagh> .hello sgallagh 18:06:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 18:06:29 <sgallagh> I'm here but distracted 18:06:41 <kalev_> hello! 18:06:43 <nirik> .hello kevin 18:06:44 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com> 18:06:52 <dgilmore> we have a shortish agenda today 18:06:54 <jwb> hi 18:07:54 <dgilmore> we have 5 lets go 18:08:15 <mitr> Hello 18:08:21 <dgilmore> #topic #1349 Fedora 22 scheduling strategy (and beyond) 18:08:21 <dgilmore> .fesco 1349 18:08:22 <dgilmore> https://fedorahosted.org/fesco/ticket/1349 18:08:22 <zodbot> dgilmore: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349 18:08:44 <mattdm> some of these are "mattdm neglected to close ticket after last meeting" 18:09:07 <mattdm> because we had a resolution here and I just didn't put it in 18:09:17 <nirik> yeah, this one we dealt with last week. ;) 18:09:25 <dgilmore> mattdm: :) okay. moving on then 18:09:41 <dgilmore> #topic #1326 change to fesco replacement process? 18:09:41 <dgilmore> .fesco 1326 18:09:42 <dgilmore> https://fedorahosted.org/fesco/ticket/1326 18:09:43 * mattdm closes ticket 18:09:44 <zodbot> dgilmore: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326 18:10:21 <mattdm> that one we didn't get to :) 18:11:05 <dgilmore> so 18:11:35 <dgilmore> i have to agree with sgallagh that leaving a seat vacant long term is not good 18:12:00 * jreznik is around, if you will need me, ping me - our team meeting is going on too 18:12:35 <nirik> I'm finding it hard to see concrete proposals in all the discussion... or I guess we don't have one? 18:12:49 <jwb> we dont' have one 18:13:02 <mattdm> Yeah we're kind of working our way towards one. 18:13:05 <dgilmore> we seem to have vague ideas and nothing concrete 18:13:09 <mattdm> slowly :) 18:13:39 <mattdm> So, do we want to a) hash it out now, b) keep slowly moving forward in the ticket, or c) decide that we're not likely to come up with a good proposal and just move on :) 18:13:50 <dgilmore> I think b 18:13:55 <sgallagh> I thought mine was fairly concrete, minus the one question about filling the seat 18:14:16 <jwb> which is probably the part that needs to be the most concrete :) 18:14:17 <mattdm> sure complete minus the hard part :) 18:14:36 <dgilmore> Iḿ with mattdm 18:14:43 <jwb> you built a driveway with quicksand in the middle sgallagh ;) 18:14:51 <jwb> yeah, i vote continue in ticket 18:14:54 <sgallagh> jwb: So ride a bike :) 18:14:59 <sgallagh> But yes, let's continue in the ticket 18:15:00 <nirik> yeah, I guess b... 18:15:09 <mattdm> punt! 18:15:09 <jwb> sgallagh, but i have no shed! nor do i know what color it should be! 18:15:25 <sgallagh> jwb: Obviously red, like the herring contained within 18:15:49 <dgilmore> proposal #agreed continue discussion in the ticket to resolve the hard bit 18:16:16 <mitr> +1 18:16:22 <nirik> +1 18:16:34 <sgallagh> +1 18:16:42 <mattdm> +1 18:16:45 <kalev_> +1 18:16:50 <dgilmore> +1 18:17:13 <dgilmore> #agreed continue discussion in the ticket to resolve the hard bit (6+, 0-) 18:17:20 <jwb> +1 18:17:26 <dgilmore> #undo 18:17:26 <zodbot> Removing item from minutes: AGREED by dgilmore at 18:17:13 : continue discussion in the ticket to resolve the hard bit (6+, 0-) 18:17:31 <dgilmore> #agreed continue discussion in the ticket to resolve the hard bit (7+, 0-) 18:17:42 <dgilmore> #topic #1381 Nonresponsive maintainer: odysseus 18:17:49 <dgilmore> .fesco 1381 18:17:50 <dgilmore> https://fedorahosted.org/fesco/ticket/1381 18:17:50 <zodbot> dgilmore: #1381 (Nonresponsive maintainer: odysseus) – FESCo - https://fedorahosted.org/fesco/ticket/1381 18:18:04 <nirik> this got handled I guess... but shouldn't we orphan his other packages as well? 18:18:06 <nirik> he has 4 18:18:15 <mattdm> well, clearly, he has a long voyage home and is beset by many perils along the way 18:18:16 <nirik> s/he/they/ 18:18:30 <jwb> mattdm, you have been waiting far too long to make that joke 18:18:47 <nirik> https://admin.fedoraproject.org/pkgdb/packager/odysseus/ 18:18:54 <mattdm> jwb yeah, so? :) 18:19:05 <sgallagh> Yes, by the process I think we have to orphan his remaining packages 18:19:18 <jwb> yes 18:19:26 <dgilmore> we should orphan his packages 18:20:02 <mattdm> right as per the process I think we don't even need to talk about it here 18:20:02 <dgilmore> proposal #agreed he is awol and his packages should be orphaned per the process 18:20:02 <nirik> sgallagh: the process only talks about the one package 18:20:16 <sgallagh> nirik: OK, then the process is wrong :) 18:20:21 <mattdm> sgallagh: +1 18:20:41 <mattdm> proposal: amend process to cover all packages owned by same unresponsive maintainer 18:20:43 <nirik> sgallagh: yes, it needs rewriting badly. I keep hoping to do so someday. 18:20:44 <sgallagh> (I'm pretty sure we've done it that way in the past too) 18:20:49 <mitr> nirik, mattdm: See the “Notes for Mass Orphaning” section 18:21:12 <mitr> It does need rewriting/cleanup to make this more obvious (as well as the short-circuit clause in Coverage section) 18:21:16 <nirik> mitr: sure, but the ticket only talks about the one package 18:21:17 <mattdm> mitr: ah yep. 18:21:33 <nirik> the entire thing needs work...but it's what we have now. ;) 18:21:43 <nirik> anyhow, +1 for orphaning all their packages. 18:21:55 <sgallagh> Ditto: +1 to orphan the other packages 18:21:57 <mattdm> it does seem good to generally have that information, because maybe a maintainer is actually really responsive in one package but not respoinding to others 18:22:02 <mattdm> and yeah, +1 for this case. 18:22:18 <kalev_> +1 from me as well 18:22:18 <mitr> +1 18:22:19 <sgallagh> mattdm: That's not non-responsive, exactly 18:22:29 <jwb> it's kind of worse 18:22:30 <sgallagh> If that's the case, they should be voluntarily orphaning that one package 18:22:42 <dgilmore> +1 18:22:46 <dgilmore> sgallagh: indeed 18:22:59 <dgilmore> jwb: any vote? 18:23:01 <nirik> there's multiple cases here. ;) 18:23:15 <jwb> +1 18:23:43 <dgilmore> #agreed he is awol and his packages should be orphaned per the process (7+, 0-) 18:24:00 <nirik> ok, I can do that orphaning 18:24:01 <dgilmore> #topic #1392 Review scope of "Python 3 as default" Change for F22 18:24:08 <dgilmore> .fesco 1392 18:24:09 <dgilmore> https://fedorahosted.org/fesco/ticket/1392 18:24:33 <sgallagh> proposal: We don't need to revisit this right now, since there's a contingency plan in place. Let it work itself out. 18:25:11 <zodbot> dgilmore: #1392 (Review scope of "Python 3 as default" Change for F22) – FESCo - https://fedorahosted.org/fesco/ticket/1392 18:25:18 <mitr> That contingency plan is fine, yes. 18:25:19 <dgilmore> I think at this point the chances of anaconda being ported are nill 18:25:21 <nirik> +1 (although I would also say they could/should rescope the change to what can/will be done) 18:25:30 <dgilmore> but the contingency should handle that 18:25:44 <mitr> It did bring up the DNF discussion, which is more worrying… but I think we should give it some time to be discussed on the mailing list. 18:25:47 <mattdm> I would _really_ like "Python 3 is the only Python implementation on the LiveCD" to be updated for Cloud/Server/Workstation 18:26:00 <mitr> (Are we really switching to DNF for F22?) 18:26:01 <dgilmore> I think we should have the Change chnaged to reflect the reality of what we will have in F22 18:26:27 <dgilmore> mitr: thats whats in comps now 18:26:35 <nirik> mitr: I think so for a subset of 'default 18:27:15 <mitr> The build mechanism? 18:27:17 <jreznik> mitr: watching all dnf discussions, even on anaconda ml, I see DNF being risk 18:27:35 <mitr> Should be testable == deployed within the next month. 18:27:46 <jwb> can we keep the dnf discussion separate please? 18:27:50 <mitr> Sorry 18:28:00 <dgilmore> jwb: +1 18:28:39 <dgilmore> so in this case I think the python3 change should be updated to reflect the reality of what we have in f22 18:29:07 <jwb> and then what? 18:29:11 <sgallagh> Well, the Change is kind of binary 18:29:25 <sgallagh> Either the install media has only python 2 on it or it doesn't 18:29:30 <sgallagh> err, python 3 18:29:44 <dgilmore> then there needs to be a new one for f23 with whats done there 18:30:02 <nirik> sgallagh: there's a number of bullet points in the 'scope' section 18:30:22 <nirik> ie, python3 anaconda, python3 only python in buildroot, etc 18:30:25 <mitr> Yes; in the mean time, there is little FESCo can help with, and AFAICS little we could help by stopping the work. 18:30:33 <sgallagh> mitr: +1 18:30:43 <nirik> so, they could do a subset of those things for f22 and move the rest to f23 18:30:53 <dgilmore> nirik: +1 18:31:02 <dgilmore> that is what I was suggesting 18:31:28 <kalev_> it might make sense to move the whole Change to F23 just to make it clear to outside observers that we're still going to be shipping python2 on the install media for now 18:31:30 <mitr> nirik: Like everyone else… but the right time for that is really at the checkpoint, not right now ISTM. 18:31:57 <sgallagh> Yes, that's kind of the whole point of having checkpoints and contingency plans 18:32:05 <nirik> sure. 18:32:12 * nirik is still +1 to sgallagh's proposal 18:32:32 <kalev_> +1 18:32:34 <jwb> +1 to sgallagh 18:32:45 <dgilmore> 18:24 < sgallagh> proposal: We don't need to revisit this right now, since there's a contingency plan in place. Let it work itself out. 18:32:49 <mitr> +1 if I wasn’t counted. 18:32:51 <dgilmore> for those that missed it 18:32:53 <mattdm> +1 18:32:56 <dgilmore> +1 18:33:11 <sgallagh> +1 for the record 18:33:31 <dgilmore> #agreed We don't need to revisit this right now, since there's a contingency plan in place. Let it work itself out. (7+, 0-) 18:33:43 <dgilmore> #topic #1374 F22 Self Contained Changes 18:33:44 <dgilmore> .fesco 1374 18:33:45 <dgilmore> https://fedorahosted.org/fesco/ticket/1374 18:33:45 <zodbot> dgilmore: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374 18:34:03 <jreznik> mattdm: btw. comment #4 :) 18:34:20 <dgilmore> https://fedorahosted.org/fesco/ticket/1374#comment:5 18:34:24 <dgilmore> lists this weeks changes 18:35:01 <mattdm> jreznik oh yes :) 18:35:20 <mattdm> jreznik: there I _uncommented_ 18:35:22 * nirik isn't sure about the wine change. looks back to the list posts on it 18:35:29 <mitr> +1 (with the in-ticket caveat that this is not an override of the wine maintianers’ decision, if any, on D3D) 18:35:29 <sgallagh> I'm +1 to the self-contained changes, with the caveat that FESCo is not ordering the WINE folks to do work they disagree with. 18:35:47 <kalev_> +1 with the same caveat 18:35:54 <jwb> yeah +1 18:35:56 <dgilmore> +1 with the same commants as mitr and sgallagh 18:36:23 <nirik> sure, +1 18:36:36 <nirik> did the wine maintainers comment at all? 18:36:52 <sgallagh> nirik: In the thread on devel@ 18:37:01 <mitr> https://lists.fedoraproject.org/pipermail/devel/2015-January/206509.html is from a wine maintainer 18:37:54 * jreznik tried to convince change owner to talk to wine maintainers first before submitting it 18:38:23 <dgilmore> who has not voted 18:38:25 <mattdm> I am also +1-with-caveat here 18:38:35 <dgilmore> okay 18:38:44 <nirik> ah, ok, I was tripped up by fas name 18:38:48 <mattdm> I was just trying to think if there was a more clear way to split out the comment 18:40:33 <mattdm> apparently there isn't. :) 18:40:59 <dgilmore> #agreed all changes this week accepted, with the caveat that the wine maintainer is not required to take the patch for the change. (7+, 0-) on ticket tmaz was 0 to wine and +1 to others 18:41:11 <dgilmore> mattdm: not sure if that is really great 18:41:15 <dgilmore> but is my attempt 18:41:20 <mattdm> it'll do 18:42:23 <dgilmore> #topic #1384 F22 System Wide Change: Harden all packages with position-independent code 18:42:32 <dgilmore> https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code 18:42:35 <dgilmore> .fesco 1384 18:42:37 <zodbot> dgilmore: #1384 (F22 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code) – FESCo - https://fedorahosted.org/fesco/ticket/1384 18:42:37 <dgilmore> https://fedorahosted.org/fesco/ticket/1384 18:43:07 <mattdm> AGREED: System Wide Change: Harden all packages with position-independent code NOT accepted for F22 (0,-7,0) (mattdm, 19:49:04) 18:43:08 <mattdm> F23 decision defered until next week (mattdm, 19:55:43) 18:43:29 * nirik isn't sure the f23 voting will go any differently this week... we didn't have enough votes to accept it. 18:43:40 <jwb> i'm still +1 for f23 18:43:43 <moezroy> it was +4 18:43:49 <dgilmore> i am +1 to all arches on F23 18:43:50 <sgallagh> So, I promised to review this over the last week because I wasn't comfortable with my knowledge on it. 18:43:52 <kalev_> I would be interested to hear what Jakub Jelinek and other gcc people say first 18:44:07 <mitr> kalev_: Jakub is against it on performance grounds 18:44:08 <nirik> there's also a different proposal for 'modernize compiler flags' 18:44:14 <dgilmore> kalev_: Jakub seemed to be in favour of it for f23 18:44:21 <jwb> kalev_, we asked again. jakubrh didn't change his opinion from the original request 18:44:23 <dgilmore> with new binutils and gcc5 18:44:42 <dgilmore> at least he did not say do not do it 18:45:21 <nirik> https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags 18:45:26 <sgallagh> I did some reading, but came to the conclusion that I am not sufficiently well-versed in the matter to make a decision. I'm going to maintain my 0 vote for now. (Though if Jakub Jelinek came out clearly in favor, that would be enough to sway me) 18:45:44 <jakubrh> dgilmore: I'd strongly prefer to first see the results how the PIE binaries look like on x86_64 with fixed binutils 18:46:06 <mattdm> jakubrh: that seems reasonable 18:46:18 <kalev_> similar to sgallagh, I would tend to trust gcc maintainers opinions here and go with what they say 18:46:22 <mitr> So, we are at +4 to approve now, and a few people wanting to defer this to the new FESCo. So 18:46:25 <mitr> proposal: defer post-elections 18:46:44 <dgilmore> jakubrh: okay. 18:46:47 <jakubrh> dgilmore: I think the binutils fix went in like yesterday or two days ago, so don't have gcc 5 built against it yet, and that is still a few steps from actually trying it on some apps 18:47:04 <mattdm> I'm okay with that. Also gives time for the above results 18:47:28 <mitr> kalev_: I no longer think that: 1) there are _really few_ applications where the performance difference would matter, at least so far as we have been able to find any, and 2) the security situation with C is close enough to hopeless that we need all the help we can help. 18:47:37 * nirik is in favor of defer too. We should consider all the compiler flag changes/etc so we don't have to do multiple mass rebuilds IMHO. 18:48:03 <dgilmore> jakubrh: I would strongly like to not diverge something like this between arches. it may confuse people of we had it on say ppc64 ppc64le aarch64 and x86_64 only 18:48:45 <dgilmore> we can do a mass rebuild for rawhide shortly after branching assuming we make a decision on the compiler flags 18:48:51 <jakubrh> dgilmore: on i?86 it is very expensive, on ppc64*/aarch64 dunno 18:49:18 <dgilmore> jakubrh: can we look at all supported fedora arches? 18:49:23 <nirik> dgilmore: right, we need to figure out this + the 'modernise' thing 18:49:32 <dgilmore> if its only i686 that diverges I may complain less 18:49:55 <dgilmore> we do still have a very large i686 user base 18:50:16 <jakubrh> dgilmore: I'll need to have a look; generally, only very few architectures have the right hw support (like x86_64) 18:50:25 <nirik> also armv7 hasn't really been mentioned much. ;) 18:50:42 <jakubrh> dgilmore: i686 is even worse because it is register starved 18:51:12 <dgilmore> jakubrh: okay. I am assuming that armv7hl shouldn't be much of an issue 18:51:34 <jakubrh> ideally we'd have SPEC2k{,6} numbers for all the architectures (normal vs. -pie -fPIE) 18:51:57 <dgilmore> jakubrh: what can we do to get those numbers? 18:52:31 <jakubrh> dgilmore: I can ask Vlad Makarov if he'd have spare cycles (both human and machine) for some of that 18:52:33 <polacek> I support what Jakub says; without benchmarks this change is no-go IMHO 18:53:09 <dgilmore> jakubrh: lets do that then and revist this is a week or two 18:53:13 <jwb> what performance penalty is acceptable for increased security? 18:53:17 <jwb> i'm just curious. 18:53:34 <jwb> it's a tradeoff. i think we need to make sure we are prepared to deal with that fact. 18:53:36 <sgallagh> That's actually a very fair question 18:53:48 <jakubrh> perhaps we want copy relocs on other architectures, hjl did just x86_64 18:54:06 <sgallagh> I'd say 1% is negligible and 5% is probably too much, so maybe somewhere in the middle? 18:54:07 <mitr> jwb: I think the first question to ask is “what applications are even affected by a main executable performance change”, and so far the known list is precisely gcc. 18:54:08 <jakubrh> jwb: the increased security is also questionable thing 18:54:17 <polacek> 5% is certainly too much 18:54:32 <polacek> even 3% is a lot 18:55:08 <jwb> jakubrh, how so? i'm not doubting you, but we've been mostly focusing on performance so i'm interested to hear why. 18:55:53 <mitr> polacek: Why would 5% be too much for, say, gdm or gedit? 18:56:40 <dgilmore> people might complain about a 5% slowdown in starting firefox, though its also something that could do with all the security it can get 18:57:02 <moezroy> I compiled firefox with -fPIC -pie 18:57:06 <mitr> dgilmore: firefox is a few hundred kB binary + several MB shared object; it will AFAICT not be materially affected 18:57:11 <jakubrh> jwb: when I've added PIE support (together with Uli), it was really meant just for the network facing, long running, suid/sgid programs, and/or for programs that have bad security history 18:57:12 <jakubrh> mitr: how have you investigated that? Guess best would be to run oprofile or some other system wide profiling on various usage types and from the stats look at where significant time is spent in executables 18:57:13 <moezroy> it seems faster and more responsive to me 18:57:33 <jakubrh> sure, libreoffice and firefox have small executables and dlopen everything, but firefox was always supposed to be PIE 18:57:38 <dgilmore> mitr: I know they have done a bunch of funky things to make it to appear tio start faster also 18:57:42 <mitr> jakubrh: investigated what? the list of affected applications? By asking for examples that would be affected and only hearing you measuring gcc. 18:57:58 <mitr> jakubrh: Certainly not scientific 18:58:25 <jakubrh> mitr: of course the first thing I'd test would be gcc, that is what I use most of the time 18:58:39 <jwb> jakubrh, ironically, we're seeing an increase in both network facing applications and applications with bad security 18:59:18 <jakubrh> jwb: so add more PIEs, the thing I'm not convinced is making everything PIE just in case 18:59:48 <mattdm> There's also a distinction between startup time performance and all-the-time-while-it's-working performance 18:59:49 <moezroy> jakubrh, http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html 19:00:32 * dmalcolm wonders if some kind of %check e.g. in firefox.spec to ensure that relevant binaries and DSOs are PIE would be a good idea 19:00:33 <nirik> anyhow, are we going off on a tanget here? 19:00:42 <dgilmore> I think so 19:00:52 <jakubrh> moezroy: sure, strings is that I understand why should be safe to run on arbitrary garbage, running as or compiler or linker on untrusted garbage? 19:01:01 <dgilmore> so it seems we need more data 19:01:03 <nirik> well, I guess not a tanget, but if we can't approve this now, discussing it further seems premature. 19:01:07 <mattdm> So: proposal: defer to new FESCo + more data 19:01:19 <dgilmore> +1 19:01:22 <nirik> +1 19:01:26 <mattdm> ("punt!") 19:01:35 <mitr> jakubrh: I’m not doubting that result, and I’m not doubting that custom-user-built HPC applications would be affected (but are not affected by what we do in %optflag). But the other obvious examples already have the performance-critical code in DSOs. Octave? Small binary + big DSO. R? Small binary + big DSO. 19:01:36 * nirik in generally in favor of doing it, but more data would be very welcome. 19:01:58 <kalev_> +1 to mattdm's proposal 19:02:05 <mattdm> +1 to self 19:02:19 <mitr> +1 to defer (but the data I am interested first is a list of affected applications, not benchmarks) 19:02:37 <sgallagh> mattdm: +1 19:02:48 <jwb> i don't like the "new FESCo" part 19:02:56 <jwb> but whatever. +1 19:03:26 <dgilmore> jwb: well that is right around the corner so is kinda redundant 19:03:38 <jwb> i dislike it anyway. 19:03:48 <dgilmore> jwb: do not disagree 19:04:00 <moezroy> it was +4 last time and tmraz gave +1 in the fesco ticket 19:04:05 <moezroy> for 64 bit 19:04:12 <moezroy> so +5? 19:04:19 <jwb> i'll change my vote to +0 then 19:04:23 <jwb> so now we're +4 19:04:29 <jwb> and we stick with "wait for more data" 19:04:42 <dgilmore> we are going to wait on more data 19:04:43 <moezroy> how are you get more data though? 19:04:43 <mattdm> jwb do you just want to defer to next week for more info? 19:05:04 <moezroy> are we going to rebuild with the flags before branching to get this data? 19:05:08 <dgilmore> #agreed defer for more data (5+, 0-) 19:05:11 <jwb> moezroy, that is an excellent question. it would normally be the Change proposers responsiblity 19:05:26 <dgilmore> moezroy: there is no rebuild for f22 19:05:27 <jwb> mattdm, i want to defer until we have data 19:05:29 <mitr> moezroy: We are not doing a mass rebuild for F22, so we are also not doing one before branching. 19:05:31 <nirik> moezroy: jakubrh said he would ask for some people and machine time to do some benchmarking 19:05:36 <mattdm> I'm not convinced by waiting for new fesco as a general policy either 19:06:21 <dgilmore> lets move on 19:06:31 <dgilmore> we are waiting for more data on pie 19:06:41 <dgilmore> #topic #1389 F22 System Wide Change: GCC5 - https://fedoraproject.org/wiki/Changes/GCC5 19:06:49 <dgilmore> .fesco 1389 19:06:50 <dgilmore> https://fedorahosted.org/fesco/ticket/1389 19:06:50 <zodbot> dgilmore: #1389 (F22 System Wide Change: GCC5 - https://fedoraproject.org/wiki/Changes/GCC5) – FESCo - https://fedorahosted.org/fesco/ticket/1389 19:06:54 <mitr> mattdm: It’s kind of an interesting metaquestion… rather than thinking about how FESCo is affected, it is IMHO better for the Change owners to not have an unexpected accepted change refused after elections 19:07:17 <mitr> On GCC5, we said we are OK with a GCC5 in F22 that doesn’t break ABI. 19:07:22 <mitr> So +1 to the updated Change page. 19:07:29 <nirik> +1 to updated change 19:07:35 <kalev_> +1 here as well, I think it's good middle ground 19:07:36 <jwb> +1 19:07:37 <dgilmore> +1 to updated change 19:07:50 <dmalcolm> jakubrh, polacek: ^^^ ? 19:07:58 <mattdm> +1 19:08:08 <sgallagh> +1 19:08:21 <jason237> This really messes with the GCC 5 ABI change messaging 19:08:57 <jason237> If we can't tell people that when they move to GCC 5 they probably want to rebuild their C++ code and then they'll be OK going forward 19:09:28 <mitr> I guess it kind of does… but if the gcc package maintainers want gcc 5 out more than they want the ABI messaging simple, IMHO that is fine for Fedora 19:09:32 <nirik> sorry, but the alternative would be 'no gcc5 for you in f22' 19:09:46 <nirik> mitr: yeah. 19:10:01 <jason237> nirik: that would be my preference, though I know jakubrh disagrees 19:10:35 <dgilmore> #agreed updated gcc5 change accepted for f22 (7+, 0-) 19:10:38 <jakubrh> I'm not happy about that either, and if I could choose, I'd like those 2300 C++ packages rebuilt and left the rest untouched 19:11:07 <jason237> the ABI change was going to be painful enough for users already 19:11:20 <nirik> perhaps a easy doc/guide way to check flags to confirm what c++ ver would help? 19:11:42 <jwb> couldn't proactive maintainers pass the ABI changing flags themselves? 19:11:48 <jakubrh> but I think that not having gcc5 in f22 means people don't get all the other benefits of gcc 5 19:11:59 <mitr> jakubrh: Just to be sure, if we switch the ABI for f23 we will again be ABI-compatible with non-Fedora distributions, won’t we? 19:12:19 <jwb> mitr, ABI-compatible? 19:12:30 <jakubrh> jwb: that is possible, they can add a -D flag one can use; but then you need to rebuild anything you interface with using C++ APIs 19:12:35 <mitr> jwb: You could end up with depending on two different packages, each using a different ABI, and being unable to compile the application so that it can use both dependencies. 19:12:59 <jwb> jakubrh, yes, understood 19:13:01 <mitr> jwb: compatible as in “not using Fedora-specific sonames or version numbers“ 19:13:16 <jakubrh> mitr: well, libstdc++.so.6 is ABI compatible, the ABI compatibility we are talking here is what you export from other C++ libraries 19:13:26 <jason237> right 19:13:33 <jwb> mitr, i would think we'd only be compatible if they also built with the new ABI flags 19:13:38 <jakubrh> symbols involving std::string/std::list change mangling 19:13:46 <mitr> jakubrh: Right, which we are in 99% breaking anyway because C++ symbol versioning is hard. Fair enough. 19:14:39 <jakubrh> say, does firefox have C++ plugin ABI, or is that C only? 19:15:00 <kalev_> AFAIK it's C only 19:15:18 <kalev_> one common 3rd party program that many users install is Skype 19:16:08 <kalev_> I wonder if they use any of std::string/std::list from other libraries 19:16:23 <dgilmore> kalev_: do we know if that is c++? 19:16:34 <polacek> one thing is that we'd like to have gcc5 tested in the wild for DTS4 19:16:35 <kalev_> dgilmore: it uses Qt libraries which is C++ 19:16:46 <dgilmore> kalev_: okay 19:17:11 <dmalcolm> fwiw, as another (minor) change to the GCC 5 change, I'd like to add "packaging of python bindings for libgccjit" to the GCC5 feature page, with me responsible for it; makes for some nice examples, see e.g. brainf**k compiler here: https://github.com/davidmalcolm/pygccjit/commit/99396861f24e73a9ff0365bf7ee9ca1a4c0b283f 19:17:43 <jakubrh> polacek has performed a test mass rebuild (almost finished now), AFAIK more problems were with C than C++ (though of course it needs analysis of the failures and rebuilds with older compiler are still running) 19:18:15 <polacek> right, but the analysis will not be finished until next week or so 19:18:21 <jwb> DTS4? 19:19:48 <polacek> jwb: strike that 19:20:07 <dgilmore> do we want to keep discussing this and potentially revisit the vote? or should we move on? 19:20:10 <jakubrh> does the KDE team plan to rebuild all of KDE for F22? 19:20:23 <jwb> i believe so 19:20:33 <jwb> given they're moving to plasma 5.2 or propose to 19:20:34 <dgilmore> jakubrh: they frequently rebuild 19:20:48 <jwb> rdieter, if you're around ^? 19:20:57 <jakubrh> like if a significant portion of C++ would be rebuilt anyway, perhaps if we would rebuild also the other C++ packages... 19:21:02 <rdieter> here 19:21:08 * rdieter reads backscroll 19:21:51 <rdieter> jwb is right, a majority of the kde stack will get rebuilt at some point 19:22:32 <dgilmore> jakubrh: so realistically c++ programs have to be rebuilt for gcc5? 19:22:42 <mitr> jakubrh: 2k packages would probably require about the same time to fix up as the full 14k packages, i.e. too much 19:23:17 <dgilmore> if so I am tempted to say -1 to it without the propper time for any kind of rebuild 19:23:18 <nirik> I don't think it's practical to subset mass rebuild them 19:23:54 <jakubrh> dgilmore: there is a libstdc++ configure time option which does give the old ABI, at the expense of not conforming (like before) 19:24:30 <jakubrh> dgilmore: I have that configure option in my current scratch packages, but jason is upset about that, because users might be confused 19:25:11 <nirik> I don't think we can avoid confusing people given our constraints. 19:25:12 <jakubrh> as upstream GCC 5 will claim finally C++11 and C++14 feature completeness, but this switch will mean important non-conformance 19:25:33 <dgilmore> jakubrh: okay 19:25:45 <jakubrh> but perhaps just good docs on the topic will be enough 19:25:51 <dgilmore> so as soon as we branch we should change that switch for rawhide 19:26:11 <nirik> jakubrh: I hope it would help yes. 19:26:11 <dgilmore> jakubrh: I think so long as we document the situation for f22 it should be fine 19:26:23 <jakubrh> %if 0%{fedora} >= 21 && 0%{fedora} <= 22 19:26:23 <jakubrh> --with-default-libstdcxx-abi=c++98 \ 19:26:23 <jakubrh> %endif 19:26:38 <dgilmore> some people are likely to be confused but that always happens because they do not read the docs and make assumptions 19:27:14 <dgilmore> jakubrh: okay, I am fine with just documenting fedora 22's behaviour 19:27:43 <jakubrh> ok, we'll try hard to put enough info into the docs 19:28:19 <mattdm> jakubrh: put it into the documentation and release notes section of the change page, please? 19:28:31 <mattdm> or at least comments to the effect of "this needs to be written" 19:28:33 <jakubrh> ack 19:28:46 <dgilmore> #info we will make sure that Fedora's f22 behaviour is documented 19:29:12 <dgilmore> #topic #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree 19:29:20 <dgilmore> .fesco 1390 19:29:21 <dgilmore> https://fedorahosted.org/fesco/ticket/1390 19:29:22 <zodbot> dgilmore: #1390 (F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree) – FESCo - https://fedorahosted.org/fesco/ticket/1390 19:30:05 <dgilmore> I do not see how this is a dependency of the Atomic Cloud image 19:30:41 <dgilmore> I do see as lot of value in documenting to people how to make and deploy thier own atomic trees 19:30:42 <mitr> It still is unclear to me after the mailing list threads whether the /var packaging changes are required or optional, and without more detail or a proposed guideline it is difficult to evaluate impact. 19:31:05 <dgilmore> I think the proposal is not clear 19:31:42 <randomuser> I had trouble understanding the scope of composes compared to deliverables, and what would consume them 19:31:47 <dgilmore> the atomic guys are very good and not really being clear 19:31:54 * randomuser should probably have replied to the list, but is here now :P 19:31:58 <dgilmore> s/and/at/ 19:32:09 <nirik> more info would be good. 19:32:23 <nirik> I think we have updates and mirroring all set now actually. 19:32:36 <dgilmore> since we already make an atomic tree and install it into the atomic cloud image that piece is not a change 19:32:45 <dgilmore> its existing functionality 19:32:48 <nirik> the other change is a bunch more atomic images right? 19:33:05 <nirik> dgilmore: I think we didn't advertise this because we didn't have mirroring and updates in palce? 19:33:10 <nirik> so, it's a punt from f21? 19:33:12 <dgilmore> nirik: its what we delivered in f21 19:33:24 <dgilmore> https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image 19:33:27 <dgilmore> that is delivered 19:33:47 <dgilmore> we can not say that a F22 change blocks a f21 change we delivered 19:34:40 <mclasen> might we worthwhile to get walters to come in ? 19:34:43 <dgilmore> I think here Colin needs to be much clearer about what this change actually is 19:34:44 * mclasen pinged him 19:34:59 <nirik> I think he meant: https://fedoraproject.org/wiki/Changes/AtomicHost 19:35:17 <mattdm> thanks mclasen 19:35:40 <dgilmore> nirik: we have most of that already also 19:36:03 <nirik> not all those other images. 19:36:19 <dgilmore> nirik: and that is another proposal that is vague and lacks anything overly concrete 19:36:33 <dgilmore> nirik: Vagrant boxes (OS X and vagrant-libvirt) 19:36:34 <nirik> so, lets discuss this one more on list and revisit next week? 19:36:34 <dgilmore> Ultra-minimal LiveOS image designed for PXE booting diskless servers 19:36:39 <dgilmore> we do not have those 19:36:59 <dgilmore> the image we have can be uploaded to the other cloud providers thats a thing stuck in legal 19:37:00 <nirik> right. we don't have any of the other cloud images either... but at least we know what they are. ; 19:37:21 <dgilmore> nirik: we have the images we can not provide the image to the providers 19:37:27 <nirik> ah, ok. 19:37:42 <dgilmore> and of that only GCE we can't provide 19:37:57 <dgilmore> you can use the existing images today in Openstack or locally in kvm 19:38:15 <dgilmore> it is a lot of hand waviness 19:38:45 <dgilmore> so #proposal defer until we get further details on what is actually being proposed 19:39:04 <nirik> and please share concerns/questions on list 19:39:07 <nirik> +1 19:39:34 <sgallagh> +2 19:39:35 <mitr> +1 19:39:36 <mattdm> +1 19:39:39 <sgallagh> err, +1 19:39:42 <sgallagh> (mistyped) 19:39:48 <kalev_> +1 19:40:09 <jwb> +1 19:40:26 <dgilmore> #agreed defer until we get further details on what is actually being proposed (7+, 0-) 19:40:35 <dgilmore> I am +1 to my proposal 19:40:42 <dgilmore> #topic Next week's chair 19:40:51 <dgilmore> who wants next week? 19:41:24 <dgilmore> nobody at all? 19:41:37 <nirik> I guess I can do it. 19:41:43 <dgilmore> thanks nirik 19:41:59 <nirik> gonna be a long meeting. Lots of changes landing now. ;) 19:42:59 <dgilmore> #info nirik to run next weeks meeting 19:43:09 <dgilmore> #topic Open Floor 19:43:18 <dgilmore> anyone have anything? 19:43:58 <dgilmore> if no one has anything i will close the meeting in a minute 19:44:16 <nirik> did we want to look at https://fedorahosted.org/fesco/ticket/1388 ? 19:44:49 * mattdm is cleverly going to be afk next week on my way to Brussels 19:45:50 <mattdm> hmm that turns out to be relevant to ticket 1388 19:45:51 <nirik> I guess I can add meeting keyword for next week 19:45:57 <dgilmore> mattdm: I leave thursday 19:46:06 <mattdm> because Andreas Thinemann is organizing the distributions devroom 19:46:18 <nirik> mattdm: oh? interesting 19:46:27 <mattdm> yeah. so I can talk to him :)\ 19:46:36 <dgilmore> it is not the first time someone has called him out as non responsive 19:46:47 <tibbs|w> Hmm, FPC hasn't seen anything about proposed changes to packaging guidelines relating to /var. 19:47:18 <nirik> mattdm: sounds good to me. Update the ticket with that info? 19:47:32 <tibbs|w> (sorry, I'm behind). 19:47:36 <nirik> tibbs|w: for the rpmostree thing? 19:47:41 <tibbs|w> Yes. 19:48:18 <nirik> yeah, that should be another thing they need to do... 19:48:58 <tibbs|w> I think FPC and FESCo actually talked about this kind of thing. Features which need packaging guidelines should at least include the guidelines draft so things don't have to block at so many different places. 19:49:26 <dgilmore> tibbs|w: that sounds sane 19:49:32 * mattdm has to go 19:49:38 * dgilmore does soon also 19:50:14 <dmalcolm> dumb qn, but what was actually agreed to in the gcc5 discussion? if I'm reading things right, it appears that we're diverging from upstream here, by retaining gcc 4.9 ABI for std::string 19:50:16 <dgilmore> nirik: so the ticket add meeting keyword and a note that mattdm will talk to him 19:50:21 <tibbs|w> Thanks. 19:50:29 <dgilmore> dmalcolm: correct 19:50:41 <dmalcolm> s/we're diverging/we're planning to diverge/ 19:51:00 <dmalcolm> ah, ok 19:51:14 <dgilmore> dmalcolm: that will be changed to the new upstream default for rawhide 19:51:21 <dgilmore> as soon as we branch 19:51:41 <dmalcolm> tnx 19:52:27 <nirik> so f22 will be the odd one out... but at least it will have gcc5 19:54:18 * nirik has nothing more. 19:54:26 * dgilmore either 19:54:30 <dgilmore> #endmeeting