16:01:05 <sgallagh> #startmeeting FESCO (2016-08-12)
16:01:05 <zodbot> Meeting started Fri Aug 12 16:01:05 2016 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:05 <zodbot> The meeting name has been set to 'fesco_(2016-08-12)'
16:01:05 <sgallagh> #meetingname fesco
16:01:05 <zodbot> The meeting name has been set to 'fesco'
16:01:05 <sgallagh> #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann
16:01:05 <zodbot> Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh
16:01:05 <sgallagh> #topic init process
16:01:10 <jsmith> .hello jsmith
16:01:10 <sgallagh> .hello sgallagh
16:01:11 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:13 <jwb> hi
16:01:14 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:21 <paragan> .hello pnemade
16:01:24 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
16:01:34 <nirik> morning
16:01:46 <Rathann> afternoon ;)
16:01:49 <Rathann> o/
16:02:42 <maxamillion> .hello maxamillion
16:02:43 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:02:44 <maxamillion> sorry I'm late
16:03:06 <jwb> so late maxamillion
16:03:11 * pbrobinson is here
16:04:06 <sgallagh> OK, I think that's enough to get started
16:04:18 <sgallagh> #topic #1592 - Redefinition of what constitutes a secondary/alternate architecture in Fedora
16:04:18 <sgallagh> .fesco 1592
16:04:19 <zodbot> sgallagh: #1592 (Redefinition of what constitutes a secondary/alternate architecture in Fedora) – FESCo - https://fedorahosted.org/fesco/ticket/1592
16:04:37 <sgallagh> pbrobinson: take it away
16:04:59 <pbrobinson> I think it's mostly answered in the ticket and devel@ thread
16:05:25 <pbrobinson> what would you like covered here without rehashing the contents of the ticket?
16:06:11 <nirik> pbrobinson: is there resources/ETA on the koji patch to make it continue all builds until they finish or fail? or is that just a config adjustment?
16:06:52 <pbrobinson> I covered it off quite extensively with mikem at flock and he now has all the details he needs (CentOS and internally want it too)
16:07:02 <pbrobinson> I don't have ETA but I can follow that up
16:07:13 <nirik> cool.
16:07:25 * jsmith has read the ticket comments, the FAQ, etc. and is fine with the proposal
16:07:27 <maxamillion> pbrobinson: did he commit to making the necessary change(s)?
16:07:34 <pbrobinson> as we're merging architectures in a staggered manner I think this will assist here too
16:07:47 <jwb> maxamillion: yes.  the important point is that it was mostly answering implementation details
16:07:55 <maxamillion> jwb: ah ok, cool cool
16:08:07 * nirik is +1 here
16:08:19 <sgallagh> pbrobinson: The wiki page needs to be updated to reflect that change
16:08:32 <sgallagh> RE: https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures#Q:_Will_a_single_arch_failure_affect_the_overall_build_failure.3F
16:08:52 <pbrobinson> sgallagh: it's a wiki ;-) but will look
16:09:24 <sgallagh> I don't see anything personally that concerns me. I think the wiki asks and answers all of the questions I would have had.
16:09:59 <sgallagh> Proposal: FESCo approves the new alternative architectures plan
16:10:01 <sgallagh> +1
16:10:02 <nirik> +1
16:10:05 <maxamillion> +1
16:10:06 <paragan> +1
16:10:25 <jwb> +1
16:10:36 <Rathann> +1
16:11:14 <sgallagh> jsmith: ?
16:11:25 <jsmith> +1
16:11:29 <sgallagh> #agreed FESCo approves the new alternative architectures plan (+7, 0, -0)
16:11:47 <sgallagh> pbrobinson: thanks for moving this along!
16:12:02 <sgallagh> #topic #1605 - finish retirement of sysvinit-only packages
16:12:03 <sgallagh> .fesco 1605
16:12:04 <zodbot> sgallagh: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605
16:12:16 <paragan> added the details in the ticket
16:12:23 <maxamillion> pbrobinson++
16:12:46 <paragan> someone from cvsadmin group need to finish the remaining retirement process
16:12:56 <nirik> paragan: so, the git repos have dead.package and the pkgdb info says  retired, it's just that they aren't blocked?
16:13:10 <paragan> I think so
16:13:32 <paragan> I have checked only oribted is blocked, all others are not yet
16:13:52 <nirik> ok, I can do that, but hopefully it doesn't cause disruption for alpha
16:14:34 <sgallagh> nirik: Do you think it would? Nothing on that list is on any install media so far as I am aware.
16:14:44 <sgallagh> (And if it is, I'd rather we figure that out sooner rather than later)
16:14:54 <paragan> what about yum-utils? are we also retiring it?
16:14:56 <nirik> I'm just wary of changes during freezes. ;)
16:15:05 <paragan> jsut thought some people should be there using it
16:15:08 <paragan> *just
16:15:27 <Rathann> I have taken psad and I will update it to the latest version (it's several behind) which has systemd support
16:15:28 <nirik> why is it on the list?
16:15:59 <sgallagh> nirik: Same SRPM as yum-updateonboot
16:16:22 <sgallagh> paragan: Do you want to just use your provenpackager powers to kill off that subpackage?
16:16:30 <nirik> I don't see it in the list
16:16:39 <sgallagh> nirik: https://fedorahosted.org/fesco/ticket/1605#comment:10
16:16:41 <nirik> also, some of the packages appear now owned...
16:16:44 <paragan> sgallagh, I can do that
16:17:04 <paragan> nirik, yes I too found that, running the check on acls
16:17:34 <paragan> like I said last week in ticket people can own the package back and looked like they did
16:17:54 <sgallagh> paragan: They were supposed to be required to re-reviwe
16:18:15 <paragan> not if they were added back within 2 weeks I guess
16:18:43 <sgallagh> paragan: That might be the technical situation, but it wasn't the policy we decided on
16:18:44 <nirik> well, it looks like it orphaned not retired
16:19:04 * sgallagh sighs
16:19:07 <nirik> and perhaps some of them got fixed too. ;( So, perhaps we should generate a new list.
16:19:22 <jsmith> Sounds reasonable
16:19:34 <paragan> I wish if I were knew this needed cvsadmin people, I would have not taken this task
16:19:40 * jsmith will be back in three minutes
16:19:55 <nirik> yeah. ;(
16:20:01 <sgallagh> Proposal: someone looks through the set of the packages that were un-orphaned and retire them if they still aren't fixed.
16:20:16 <sgallagh> (They've had plenty of warning and this smells of trying to bypass the process to me)
16:20:30 <nirik> should we retire the ones that also were just orphaned too?
16:20:38 <sgallagh> Yes
16:20:40 <paragan> yes
16:20:43 <sgallagh> (IMHO)
16:20:46 <maxamillion> agreed ,yes
16:20:51 <maxamillion> bleh ... minus the typo
16:21:14 <nirik> I guess I can do it, but I am down with some post flock crud now, so I am not sure when I will get to it.
16:21:37 <sgallagh> Sorry to hear that, nirik.
16:21:57 <tibbs> I can do cvsadmin stuff if needed.
16:22:33 * jsmith agrees with the plan to retire the ones that were just orphaned too
16:22:39 <jwb> yes
16:23:00 <nirik> tibbs: if you want to do it that would be lovely.
16:23:25 <tibbs> Just send me a list of the packages that need admin stuff.
16:23:43 <sgallagh> paragan: Can you get tibbs the list?
16:23:59 <nirik> https://fedorahosted.org/fesco/ticket/1605#comment:8
16:24:06 <paragan> sgallagh, I think its in ticket
16:24:07 <paragan> yes
16:24:25 <sgallagh> Ah, so it is
16:24:25 <paragan> all those packages need to be retired
16:24:34 <nirik> and f25 and rawhide right?
16:24:44 <paragan> yes that is what we decided
16:24:50 <sgallagh> right
16:25:13 <sgallagh> Anyone opposed to the provenpackager intervention on yum-updateonboot subpackage?
16:25:22 <maxamillion> not I
16:25:36 <jsmith> Not I
16:25:56 <paragan> so I need to obsolete it and build new yum update?
16:26:28 <sgallagh> paragan: Don't play with obsoletes, we didn't do that for any of the retired packages
16:26:40 <sgallagh> Just kill the subpackage and its contents and build the update.
16:26:52 <paragan> okay
16:27:50 <paragan> so for this ticket 2 tasks, one tibbs to retire all those 41 packages given in https://fedorahosted.org/fesco/ticket/1605#comment:8 and I will be only removing yum-updateonboot from yum package.
16:28:17 <paragan> Does this looks okay?
16:28:26 <sgallagh> Looks right to me
16:28:49 <nirik> yep.
16:29:00 * nirik can go in and fix nagios, they still don't seem to have
16:30:16 <sgallagh> #action paragan to remove yum-updateonboot subpackage
16:30:29 <sgallagh> #action tibbs to retire remaining packages that were only orphaned
16:30:40 <sgallagh> #topic #1609 - Fedora 26 schedule proposal
16:30:40 <sgallagh> .fesco 1609
16:30:41 <zodbot> sgallagh: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609
16:31:56 <sgallagh> dgilmore requested that we move the branch date to Feb 7
16:31:57 <nirik> so, should we try and determine the fate of Alpha before we decide the schedule?
16:32:27 <maxamillion> nirik: the fate of alpha? .... I think I missed something
16:32:34 <sgallagh> Is there a problem with just shortening the period between branch and alpha?
16:32:55 <sgallagh> maxamillion: There is effort going into making Rawhide always alpha quality, thus eliminating the need for the Alpha release in the schedule
16:32:58 <jwb> i'm not understanding the desire to get rid of Alpha
16:33:05 <maxamillion> sgallagh: ohhh right right, ok
16:33:20 <maxamillion> sgallagh: I thought there was potentially some issue with the current cycle that I missed
16:33:28 <sgallagh> not that I am aware.
16:33:34 <jwb> i mean, yeah that's a great goal and we should work towards it, but Alpha as a sync point still has utility, yes?
16:33:45 <jsmith> Yes, it should
16:33:45 <sgallagh> I'm also not sure there's an advantage... yeah
16:33:50 <nirik> I think the thought is that it doesn't have too many users anyhow, and it would be better to just keep working than try and freeze things at that point
16:33:59 <sgallagh> jwb: That's pretty much where I was going
16:34:11 * nirik is also not the one making the proposal, so I can't really argue for it.
16:34:34 <sgallagh> But my original question stands: is a week enough time between freeze and Alpha (assuming Alpha remains)?
16:34:43 <sgallagh> Because if so, we can just keep the schedule largely as it is right now
16:35:48 <sgallagh> I'm also really concerned about GCC
16:35:59 <Rathann> I'll be back in 5 mins, sorry, guests at the door
16:36:00 <sgallagh> It doesn't look like their schedule lines up very well
16:36:01 <maxamillion> sgallagh: why the concern about GCC?
16:36:04 <maxamillion> oh
16:36:05 <maxamillion> :/
16:36:15 <nirik> freeze and alpha release 1 week? thats...
16:36:26 <sgallagh> They're asking for us not to do the mass rebuild until at least Jan 25
16:36:30 <sgallagh> nirik: I meant branch, not freeze
16:36:37 <nirik> ah, ok
16:37:23 <sgallagh> If we need three weeks after mass rebuild, that means the earliest we could branch would be Feb 15th.
16:38:27 <sgallagh> nirik: Actually, why is there a gap between branch and freeze at all?
16:38:57 <sgallagh> Especially if we are moving towards Rawhide always being alpha quality.
16:39:15 <sgallagh> Could we just do the branch the moment we enter Freeze?
16:39:23 <maxamillion> I would think so
16:39:29 <nirik> there's always some churn after branching... people wake up and realize they forgot to push something, etc.
16:39:36 <nirik> yes, but then all those people will be mad.
16:39:41 <maxamillion> ah
16:39:43 <nirik> which isn't anything new, but just noting
16:39:45 <maxamillion> well ...
16:39:47 <maxamillion> :/
16:39:51 <sgallagh> nirik: But it might go away if we make it very loud that this is Alpha Freeze
16:40:15 <sgallagh> Or at least it'll mean they have to go through the FE process, which isn't necessarily a bad thing
16:40:36 <tibbs> All of those packages have been retired in pkgdb.
16:40:43 <sgallagh> tibbs: Thank you kindly
16:40:43 <jwb> Alpha aside, i think it would benefit us to push things out to accommodate gcc
16:40:52 <nirik> jwb: agreed
16:41:10 <sgallagh> Yeah, although I'd like to see if we can talk them into adjusting earlier for 2018
16:41:20 <sgallagh> Just to get us in closer alignment
16:41:25 <nirik> How about we gather more info/proposals in ticket and see if we can't get qa and releng here next week and discuss the alpha stuff.
16:42:04 <sgallagh> nirik: I'd prefer to get that QA/releng input in advance of the next meeting if we can manage it
16:42:32 <nirik> sure.
16:42:38 <nirik> I just don't think we should decide something today
16:43:17 <sgallagh> agreed
16:43:42 <maxamillion> oops
16:44:26 <Rathann> ok, I'm back
16:45:48 <sgallagh> OK, I guess I'll try to summarize my thoughts on the ticket after the meeting and try to reach out to QA and releng
16:45:51 <sgallagh> Shall we move on?
16:46:00 <jwb> sgallagh: you mean adjusting upstream gcc?
16:46:10 <sgallagh> jwb: Yes
16:46:23 <sgallagh> I'm hoping that with 12 months advance notice, this could be possible
16:46:30 <jwb> i don't disagree but that seems fairly bold
16:46:34 <sgallagh> Well, more than 12 months
16:46:47 <jwb> i suspect the reply will be "the world is not Fedora"
16:46:57 <jwb> anyway, we can always try
16:46:59 <sgallagh> jwb: Yeah, but they're also slightly out of alignment with glibc
16:47:03 <sgallagh> So that's worth pointing out
16:47:33 <sgallagh> Because the world *is* glibc :)
16:47:41 <fweimer> I don't think there's a need for glibc/GCC alignment.
16:48:12 <fweimer> I hope there won't be another libstdc++-type issue (if there will be, we need a better solution).
16:48:37 <sgallagh> Shall we move on for now?
16:48:43 <fweimer> Yes, please.
16:48:54 <sgallagh> #topic #1611 - Continued lack of support for RPM weak dependencies in distribution tooling
16:48:54 <sgallagh> .fesco 1611
16:48:56 <zodbot> sgallagh: #1611 (Continued lack of support for RPM weak dependencies in distribution tooling) – FESCo - https://fedorahosted.org/fesco/ticket/1611
16:49:18 <sgallagh> So, yet again we have a disconnect between our packaging tools and our distribution tools.
16:49:20 <jsmith> This concerns me...
16:49:36 <sgallagh> Caused by releng not having the resources to finish switching over to DNF
16:50:14 <nirik> so, one thing we can try short term is switch bodhi to run on a Fedora instance. I'm not sure that solve the issue tho. I was meaning to test, but haven't had time
16:50:16 <pingou> it's as much a switch as the possibility to running/maintaining two tools side by side
16:50:39 <sgallagh> pingou: I don't follow.
16:51:18 <pingou> sgallagh: well, we can't switch entirely to dnf as the entire EPEL stack does not have it, so switching to dnf means maintaing two stacks: dnf in Fedora and yum in epel
16:51:31 <nirik> I'm unsure what fesco can do here.
16:52:02 <nirik> I guess ban all weak and rich deps, which seems a shame.
16:52:07 <jwb> if dnf were available in EPEL or even RHEL, that would help though yes?
16:52:14 <sgallagh> nirik: I think our choices are basically "tell everyone to stop using useful RPM features" or "hope releng works something out"
16:52:25 <pingou> jwb: we still have epel6 and 5 :s
16:52:29 <fweimer> nirik: It's too late for a ban on weak deps, removing them from the distribution again would be a lot of work.
16:52:38 <nirik> sgallagh: right. well, only the first of those is a fesco action... the second is a inaction. ;)
16:52:58 <fweimer> pingou: But those need only a subset of the tooling.
16:52:59 <maxamillion> jwb: dnf is in EPEL7, but I'm not sure that would solve this for older epel
16:53:09 <jwb> epel makes me sad
16:53:35 <nirik> jwb: do note that epel is a lot more popular than fedora. ;) (at least by downloads/mirror use)
16:53:59 <maxamillion> nirik: +1
16:54:12 <jwb> nirik: it doesn't make me sad that it exists.  it makes me sad that it and fedora continue to hobble each other because they're tied together for really no good reason
16:54:15 <nirik> anyhow, I'm willing to try bodhi backend on fedora and if that doesn't work, look at the createrepo_c patches someone said they had...
16:54:52 <pingou> fweimer: true there
16:54:53 <nirik> sure, but I am not sure what the tie is here...
16:55:19 <fweimer> Do these tools support installing packages in a specific order?  This would allow us to work around some of the yum bugs related to weak dependencies.
16:55:42 <nirik> you will have to be more specific I fear.
16:55:51 <paragan> fweimer, how does the specific order matter here?
16:56:10 <nirik> I thought the current issue was repodata not containing weak deps or containing them as requires instead of suggests,etc
16:56:15 <maxamillion> jwb: we could try to transition epel into CentOS land now that the projects are far more collaborative than ever before in the history of time ... but I suspect that's a massive undertaking
16:56:16 <paragan> right
16:56:17 <fweimer> paragan: releng wasn't very forthcoming with details, so I assume it's a yum issue.
16:56:46 <paragan> the basic issue is not using the createrepo_c for generating repodata
16:56:51 <fweimer> In this case, yum sees a Requires: for something which is provided by libcrypt and libcrypt-nss, and picks libcrypt because it is lexicographically first.
16:57:24 <fweimer> It later reaches glibc and treats the Recommends: libcrypt-nss as a Requires:, resulting in the conflict.
16:57:32 <paragan> right that is related to package managers yum and dnf
16:57:32 <nirik> paragan: not entirely
16:57:43 <paragan> nirik, what am i missing?
16:57:53 <nirik> rpm also has to support it
16:57:57 <fweimer> So if we start with libcrypt-nss or glibc, yum should handle the dependencies just fine.
16:58:04 <nirik> bodhi (updates) runs on a rhel7 instance.
16:58:15 <paragan> oh right the new rpm version that supports weak/rich deps
16:58:22 <nirik> it uses createrepo, but also rhel7 rpm... which has no idea about weak deps and ignores them
16:58:59 <fweimer> nirik: Ignoring weak dependencies would be fine, it's turning them into strong ones without backtracking that causes the problem.
16:59:21 <fweimer> I think the affected tool by releng was said to be mash, not bodhi, assuming they aren't the same thing.
16:59:24 <maxamillion> "without backtracking" ?
16:59:28 <maxamillion> I'm not sure I follow that
16:59:45 <nirik> bodhi -> mash -> createrepo -> yum/rpm
17:00:02 <jwb> maxamillion: backtracing.  crashing.
17:00:24 <sgallagh> maxamillion, jwb: I don't think that's what he meant, actually.
17:00:25 <fweimer> maxamillion: The yum dependency resolvers is not strong enough, it can't recover once it has painted itself into a corner.
17:00:26 <Rathann> ideally, that should be s/yum/dnf/ and s/createrepo/createrepo_c/ by now
17:00:34 <sgallagh> I think I understand the problem, and it's a resolver bug that isn't in dnf
17:00:39 <maxamillion> jwb: ah
17:00:43 <sgallagh> And is probably prohibitively expensive to backport
17:00:48 <fweimer> maxamillion: Backtracking as a problem solving strategy.
17:00:53 <maxamillion> fweimer: ohhh hok
17:00:57 <maxamillion> fweimer: gotchya
17:01:00 <maxamillion> alright, well crud
17:01:04 <jwb> oh
17:01:31 <fweimer> Again, I didn't receive much detail on the issue, this is just what I have pieced together by myself.
17:01:47 <sgallagh> Basically, DNF looks at the total transaction as a whole and will revise earlier decisions if there is a potential conflict.
17:01:56 <fweimer> If I had testcases, I could probably adjust things on the glibc side without loss of functionality.
17:01:59 <nirik> well, dnf also understands weak deps
17:02:03 <sgallagh> yum isn't that smart and would probably have to be ported to libsolv to accommodate it
17:02:10 <sgallagh> Which would basically make it... dnf
17:02:43 <Rathann> I've always agreed with the camp that said dnf should've been just yum-4.0 ;)
17:03:31 <fweimer> The main problem I see is how we can provide guidance to packagers what works today and what does not.
17:04:19 <sgallagh> fweimer: We don't actually know that information, so it's hard to provide it.
17:04:50 <nirik> it only adds to the confusion that this all works in the non update path
17:05:34 <Rathann> why is bodhi still using mash, by the way? I thought it was supposed to be replaced with pungi?
17:06:23 <nirik> I don't know that was ever the plan. There is koji signed repos that were supposed to replace mash, but they aren't done yet
17:07:01 <jsmith> Yeah... I'm confused as to how/why Pungi would be involved
17:07:24 <Rathann> well that's what kparal said in the issue I opened against mash
17:08:38 <Rathann> is there any ETA on the signed repos thing?
17:08:54 <nirik> it was a f25 change, but didn't make it, I don't know the current status.
17:09:23 <nirik> ok, it looks like making a fedora bodhi-backend to do updates on will quite possibly fix the weak deps thing
17:09:54 <sgallagh> OK, so want to try that and reconvene if it doesn't work?
17:09:59 <maxamillion> sgallagh: +1
17:10:15 <nirik> sure. I don't know what else we can do here in this meeting
17:10:34 <Rathann> nirik: https://fedoraproject.org//wiki/Changes/KojiInstallMedia ?
17:10:58 <jsmith> sgallagh: +1
17:11:02 <nirik> https://fedoraproject.org/wiki/Changes/KojiSignedRepos
17:11:02 <sgallagh> #action nirik to investigate running Bodhi on a Fedora 24 VM as a solution to the weak dependency issue
17:11:11 <sgallagh> Shall we continue?
17:11:21 <maxamillion> yes please :)
17:11:23 <sgallagh> #topic Next week's chair
17:11:35 * sgallagh pulls the pin, tosses the grenade. Catch!
17:11:41 <maxamillion> I can do it next week
17:11:57 <sgallagh> #info maxamillion to chair 2016-08-19 meeting
17:12:06 <sgallagh> #topic Open Floor
17:12:11 * jsmith has nothing for the open floor
17:12:29 <sgallagh> #info Thanks to everyone who came to Flock last week. It was a fantastic conference!
17:12:55 <Rathann> indeed it was
17:12:58 <maxamillion> +1
17:13:00 <jsmith> +1
17:13:11 * maxamillion has nothing for open floor
17:13:17 <nirik> quite right. great time, glad to talk to so many people
17:14:27 <jflory7> +1 sgallagh :)
17:14:47 <sgallagh> Anyone have anything else for Open Floor?
17:15:31 <Rathann> nope
17:15:54 <sgallagh> Alright, thanks for coming, everyone!
17:15:56 <paragan> sorry got network issue
17:15:57 <sgallagh> #endmeeting