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