18:01:14 <sgallagh> #startmeeting FESCO (2015-02-25)
18:01:14 <zodbot> Meeting started Wed Feb 25 18:01:14 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:14 <sgallagh> #meetingname fesco
18:01:14 <zodbot> The meeting name has been set to 'fesco'
18:01:14 <sgallagh> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:01:14 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:01:14 <sgallagh> #topic init process
18:01:19 <jwb> I AM PRESENT
18:01:24 * ajax waves
18:01:24 <paragan> Hi
18:01:25 <sgallagh> I AM PAST
18:01:26 <nirik> morning
18:01:33 * rishi waves
18:01:46 <thozza> hi all
18:02:41 <mitr> Hello
18:03:41 <sgallagh> That's everyone except dgilmore
18:03:47 <sgallagh> Guess we'll start and see if he joins later
18:03:58 <sgallagh> #topic #1367 Please define package manager expectations
18:03:58 <sgallagh> .fesco 1367
18:03:59 <zodbot> sgallagh: #1367 (Please define package manager expectations) – FESCo - https://fedorahosted.org/fesco/ticket/1367
18:05:01 <sgallagh> So I put this on the agenda mainly because we planned to revisit at Alpha Freeze
18:05:20 <dgilmore> Im here
18:05:21 <sgallagh> Mostly, I assume, for us to decide whether we were going to try to back out of DNF as default
18:05:32 <jwb> we should probably retitle the ticket
18:05:35 <jwb> but sure
18:05:58 * jreznik is around, ping me if you need me
18:06:00 <nirik> there's a bit more wiki pages and such now.
18:06:25 <nirik> I don't know that we have any 'this is required for dnf' document asked for...
18:06:38 <dgilmore> I think we need to evaluate this after alpha
18:07:08 <mitr> nirik: I think we explicitly refused to produce that ☺
18:07:25 <nirik> yeah, I don't see us doing that...
18:07:51 <dgilmore> I think we really really need to evaluate the naming. I really think we should ask upstream to follow thier initial plan and rename it to yum when it takes over
18:07:52 <mitr> nirik: Per comment 6, the outstanding question is basically “are we happy with …/cli_vs_yum.html”
18:08:31 <nirik> dgilmore: at this point I don't think that would do anything good.
18:08:47 <randomuser> adamw has a tracker bug with some interesting depsolver issues
18:08:54 <dgilmore> nirik: maybe
18:08:55 * randomuser hunts for it
18:09:00 <paragan> there is one more document also available http://dnf.readthedocs.org/en/latest/user_faq.html
18:09:40 <rishi> nirik: Why not?
18:09:44 <mitr> dgilmore: Why does the package name matter, when the dnf-yum package provides the existing /usr/bin/yum path and command?
18:10:03 <sgallagh> Error: package dnf-yum-0.6.4-2.fc22.noarch conflicts with yum provided by yum-3.4.3-155.fc22.noarch
18:10:04 <randomuser> https://bugzilla.redhat.com/show_bug.cgi?id=1192182
18:10:11 <nirik> I'm happy with that doc, and when I haven't been in the past, I submitted bugs and they fixed it. ;) So, I'm good to go with dnf...
18:10:51 <nirik> rishi: the behavior has changed in subtle ways. I think it should be up to users to change anything that calls yum to use dnf and adjust it at that time... not silently replace the tool
18:11:09 <randomuser> I've run into a few situations where dnf seems to not use installed packages as providers for install/update requirements, inside and outside of mock; I should probably investigate and file bugs instead of getting through $TASKATHAND
18:11:12 <nirik> also it means going back to yum (for example when a bug is being fixed in dnf) hard.
18:11:27 <sgallagh> At the minimum, if we are going to make dnf-yum a default, it should happen in Rawhide for f23
18:11:29 <dgilmore> mitr: a lot when it comes to, downstreams, systems management tools, documentation etc.
18:11:34 <sgallagh> It's too late in the cycle to do that in F22
18:11:53 <mitr> dgilmore: I don’t understand.  Could you give me an example of what would be broken?
18:11:56 <dgilmore> mitr: we would really need to make dnf require dnf-yum
18:12:08 <mitr> dgilmore: The package name doesn’t matter, it is in the default set anyway, isn’t it?
18:12:17 <dgilmore> mitr: its not
18:12:59 <dgilmore> mitr: I can see downstreams wanting to have it changed.
18:13:21 <nirik> if we make dnf-yum default, it removes yum from all systems.
18:14:29 <sgallagh> Before we go too far, can we vote on this:
18:14:29 <sgallagh> Proposal: Providing /usr/bin/yum as a symlink for /usr/bin/dnf should not happen in Fedora 22
18:14:34 <rishi> nirik: the changes more significant than what would happen between yum releases? I know that dnf didn't prevent you from removing your kernel. Not sure whether that has changed now.
18:14:44 <sgallagh> I'm +1 simply because it's too late to address any fallout from it.
18:14:46 <mitr> sgallagh: then what does http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF end up meaning?
18:14:47 <rishi> *Are the changes
18:15:24 <nirik> rishi: oh yes, IMHO. Command line options that aren't accepted, different dep solving... lots of things.
18:15:29 <jwb> mitr, presumable the first two bullets under "practical changes" ?
18:15:31 <sgallagh> mitr: It means that we ship with /usr/bin/dnf by default and do not include /usr/bin/yum in the standard install,  I guess.
18:15:32 <mitr> sgallagh: At least looking at https://bugzilla.redhat.com/show_bug.cgi?id=1181567#c3 it seems that the Change owner is still assuming that will go on as planned.
18:15:45 <sgallagh> It also means that any tools that call yum directly should be migrated (I did so for rolekit, for example)
18:16:16 <mitr> sgallagh: Removing the /usr/bin/yum path from the default install seems to me worse than any other option.
18:17:03 <sgallagh> mitr: What in that bug claims they're ready to add the symlink?
18:17:03 <mitr> (and if we are not ready for having dnf-yum by default then by definition we are not ready to not have /usr/bin/yum)
18:17:46 * nirik notes that "default" is completely muddy in terms here.
18:17:51 <mitr> sgallagh: It is the original plan and there is no claim otherwise, isn’t that the default position?
18:17:58 <jwb> is anaconda using the dnf backend now?
18:18:02 <nirik> yes
18:18:02 <sgallagh> OK, fair enough
18:18:11 <jwb> is dnf installed by default and yum isnt?
18:18:21 <sgallagh> jwb: Currently both are installed
18:18:27 <dgilmore> jwb: afaik dnf is used by anaconda
18:18:27 <jwb> that seems silly
18:18:38 <dgilmore> I am not sure what you get on a minimal install though
18:18:41 <nirik> sgallagh: in what context?
18:18:55 <sgallagh> nirik: Sorry, to clarify: both were installed by the Workstation Live
18:19:01 <mkolman> I can confirm DNF is the default in Anaconda
18:19:03 <sgallagh> Which I was forced to do the other day
18:19:10 <nirik> ok. yum isn't in comps, so something is pulling it in?
18:19:14 <jwb> sgallagh, uh, the f22 live?
18:19:16 <sgallagh> (Bad upgrade forced a rebuild of my machine)
18:19:20 <sgallagh> jwb: Yes,the F22 live
18:19:27 <dgilmore> sgallagh: yum is probably pulled in by mock or something else
18:19:28 <sgallagh> I installed from the 2/21 nightly
18:19:39 <sgallagh> dgilmore: That may be true, but it was there
18:19:39 <jwb> i am surprised it even booted
18:19:50 <sgallagh> jwb: It's running quite nicely, actually
18:19:51 <dgilmore> sgallagh: a minimal base install using anaconda is what should evaluated
18:20:03 <jwb> ok, so modulo some kind of dep bug, it sounds like dnf is already the default
18:20:15 <jwb> so we're down to talking about a symlink
18:20:18 <dgilmore> jwb: yes
18:20:25 <jwb> which i frankly don't think is important either way
18:20:30 <sgallagh> dgilmore: I'm not sure that's a valid statement. I think it's not truly default if the products' default installs include both
18:20:54 <rishi> (Why do all the yum-dnf bugs have the same subject? Makes it very confusing.)
18:21:01 <ajax> so on such a setup, what did "dnf remove yum" try to remove?
18:21:03 <dgilmore> sgallagh: what do you get on server or cloud?
18:21:09 <sgallagh> jwb: I think it's important only because it didn't land earlier, but I'm willing to accept "Land it for Alpha and revert it at Beta if needed" as a compromise
18:21:27 <sgallagh> dgilmore: I haven't installed either in the last week. Sorry.
18:21:28 * nirik dislikes dnf-yum by default, but I guess I can be shouted down
18:21:35 <randomuser> I understood that F21 workstation had dnf as the preview, and am surprised that having both persisted; maybe they just haven't gotten around to discussing/changing it yet?
18:21:52 * nirik tries a dnf remove yum here
18:21:52 <jwb> nirik, i don't like it much either, but i am not willing to argue for more than 5min about it
18:21:53 <sgallagh> ajax: Just yum, actually (though it's trying to upgrade a bunch of other stuff simultaneously..)
18:22:04 <jwb> randomuser, likely
18:22:27 <nirik> it was changed in comps, so something is dragging it in... it shouldn't be needed.
18:22:29 <ajax> sgallagh: okay, i guess a better question is what does 'rpm -e yum' complain about
18:22:36 <dgilmore> nirik: mock most likely
18:22:36 <sgallagh> ajax: Oh, correction. I misread.
18:22:46 <sgallagh> It's trying to remove a whole bunch of python and rpm stuff
18:22:54 <sgallagh> And abrt...
18:23:08 <dgilmore> sgallagh: yes abrt is staill hardcoded for yum
18:23:15 <mitr> “libreport-python - port is almost finished, only one DNF feature is needed [4] (PR created).”
18:23:19 <nirik> http://paste.fedoraproject.org/190420/42488857/
18:24:22 <randomuser> out of curiosity, have you all been using dnf in mock?
18:24:44 * nirik has been using dnf-3 here for a while... not much problem with it.
18:24:55 <dgilmore> the cloud image seems to not have yum installed
18:24:57 <nirik> but no, I haven't been using the mock dnf support
18:25:05 * paragan also using dnf-3 not much problem seen
18:25:07 <dgilmore> but the kickstart does use yum to remove firewalld
18:25:46 <sgallagh> OK, we've been on this topic for more than 20 minutes.
18:25:46 <randomuser> i've been using dnf-3 cli and dnf in mock; have only run into one build failure but it was clearly dnf's fault
18:25:50 <sgallagh> Does anyone have another proposal?
18:25:51 * randomuser shuts up
18:26:15 <thozza> sgallagh: can you please repeat the current one? since I somehow lost it in the discussion
18:26:33 <nirik> proposal: close ticket, ask change owners to not make dnf-yum default, change otherwise continues for f22.
18:26:51 <dgilmore> sgallagh: that we evaluate the situation post Alpha, and we seek input from downstreams on if dnf should be renamed to yum
18:27:05 <sgallagh> nirik: That's essentially a rephrasing of my earlier proposal. I've actually changed my opinion.
18:27:30 <sgallagh> I'm fine with letting them add dnf-yum by default as long as it happens for Alpha so we have time to revert it in Beta if we need to.
18:27:31 <mitr> proposal: We are fine with the DNF change as is (dnf-yum included), close ticket.
18:27:31 <nirik> ok.
18:27:46 <sgallagh> Formally:
18:27:48 <thozza> sgallagh: I agree... I think it is now or rawhide
18:27:56 * nirik is pretty sure they said they were not going to do dnf-yum, but didn't update the change page.
18:28:16 <sgallagh> nirik: oh?
18:28:25 <nirik> but I cannot find the post.
18:28:28 <nirik> it was on devel list.
18:28:48 <thozza> nirik: So I think we should not stop them, but rather say that is has to happen now or postpone to rawhide
18:28:53 <sgallagh> /me wishes jzeleny or someone was here.
18:29:06 <nirik> I think forcing that change on our users is a very bad idea.
18:29:21 <thozza> I'm for the mitr's proposal
18:29:22 <sgallagh> Proposal: If the DNF folks want to land dnf-yum, they must do it in time for Alpha or else postpone it to F23 and get it in Rawhide ASAP.
18:29:25 <mitr> nirik: So are we removing yum _ever_?  If so, why not now?
18:29:49 <dgilmore> mitr: at some point we have to remove it
18:29:51 <nirik> mitr: sure. How about when nothing in the distro needs it? and work to that... right now, all the fedora packager tools do.
18:29:53 <mitr> sgallagh: +1
18:29:59 <jwb> dgilmore, why?
18:30:04 <nirik> so, if you don't want any fedpkg. ;)
18:30:30 <paragan> jsilhan is confirming there is no plan to add dnf-yum package default in f22
18:30:39 <mitr> nirik: fair point
18:30:42 <rishi> nirik: What is the blocking the packaging tools?
18:30:48 <jwb> work
18:30:51 <sgallagh> paragan: If that's true, then ok
18:31:08 <sgallagh> Shall we just accept that things are moving along fine, then and get to the next topic?
18:31:10 <paragan> just asked him in PM
18:31:15 <jwb> yes
18:31:16 <dgilmore> jwb: because at some point it will stop working with the metadata etc, depending on changes, and it will fall behind to the point it won't work right anymore. at least without active development, and they have said they will stop active development
18:31:21 <thozza> but dnf-yum should be at least added to rawhide as soon as possible...
18:31:37 <sgallagh> paragan: Let him know that if they want it in F23, please land it in Rawhide soon so we can shake out the bugs.
18:31:40 <nirik> thozza: it's available.
18:31:43 <dgilmore> mitr: right now we can not remove it because if we remove yum we remove the ability to make Fedora
18:31:48 <thozza> I mean install it by default
18:32:08 <thozza> nirik: ^
18:32:09 <nirik> thozza: then anyone using rawhide can't maintain packages?
18:32:10 <rishi> So how about modifying sgallagh 's proposal to say: "no dnf-yum in f22, but get it into rawhide as soon as possible" ?
18:32:11 <nirik> -1000
18:32:13 <paragan> sgallagh, ok
18:32:16 <nirik> rishi: -1
18:32:23 <mitr> nirik: Do we actually know that dnf-yum breaks packaging tools?
18:32:30 <thozza> rishi: yeah, something like that
18:32:32 <nirik> mitr: it conflicts with yum
18:32:38 <dgilmore> mitr: it breaks installing yum
18:32:40 <mitr> oh, silly me. right.
18:32:41 <nirik> you must remove yum, which removes everything that uses it
18:32:48 <dgilmore> mitr: which breaks making fedora
18:32:57 <dgilmore> mitr: what else it breaks who knows
18:33:13 <thozza> we need to do the switch anyway
18:33:18 <nirik> it's IMHO still a bad idea after that, but at least we need to fix those things first
18:33:32 <rishi> Hmm... createrepo needs yum - http://paste.fedoraproject.org/190420/42488857/
18:33:39 <sgallagh> Proposal: FESCo takes no action.
18:33:43 <sgallagh> Move on to other topics...
18:33:47 <rishi> So, I guess it is too early for dnf-yum anyway.
18:33:52 <ajax> +1 inaction
18:34:00 <nirik> sgallagh: 30mins and... ok, sure. +1 :)
18:34:06 <paragan> sgallagh, +1
18:34:08 <mitr> sgallagh: +1
18:34:09 <rishi> +1
18:34:16 <mitr> sgallagh: Actually, …and closes the ticket, right?
18:34:24 <sgallagh> Fine
18:34:33 <mitr> (probably implied)
18:35:07 <dgilmore> +1
18:35:07 <sgallagh> #agreed FESCo takes no action (+6, 0, -0)
18:35:11 <sgallagh> #undo
18:35:11 <zodbot> Removing item from minutes: AGREED by sgallagh at 18:35:07 : FESCo takes no action (+6, 0, -0)
18:35:13 <jwb> +1
18:35:19 <ajax> yes
18:35:26 <paragan> yes close the ticket and if needed open new with specific details
18:35:28 <sgallagh> #agreed FESCo takes no action (+8, 0, -0)
18:35:44 <sgallagh> #topic #1388 Remove echoping from the distribution
18:35:45 <sgallagh> .fesco 1388
18:35:48 <zodbot> sgallagh: #1388 (Remove echoping from the distribution) – FESCo - https://fedorahosted.org/fesco/ticket/1388
18:36:13 <sgallagh> This appears to have mostly resolved itself, unless we want to discuss ixs' tendency towards absentee maintainership
18:37:02 <jwb> i don't
18:37:04 <sgallagh> I'm inclined to just close it and move on
18:37:06 <nirik> perhaps we could contact him and ask if he would like us to solicit co-maintainers?
18:37:13 <nirik> sure. thats fine too
18:37:33 <sgallagh> #info Ticket has resolved itself and will be closed
18:37:43 <sgallagh> #topic #1326 change to fesco replacement process?
18:37:44 <sgallagh> .fesco 1326
18:37:46 <zodbot> sgallagh: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326
18:38:19 <sgallagh> I proposed a hopefully clearer version of my proposal
18:38:38 <thozza> sgallagh: you mean the one that was not clear for jwb?
18:38:39 <thozza> :)
18:38:44 <sgallagh> jwb: To answer your one question, let's assume that we have seats 1-9.
18:38:46 <nirik> that still seems kinda complicated, but I guess I can +1 it.
18:39:06 <sgallagh> even numbered seats are elected at the start of even-numbered Fedoras, and vice-versa
18:39:42 <sgallagh> If an even numbered seat is vacated before the election cycle for an odd-numbered Fedora, it gets added to the election for a shortened term (just one cycle) so it's back on schedule for future elections.
18:41:16 <dgilmore> sgallagh: s/The Board/Council/
18:41:31 <sgallagh> dgilmore: Yes, I mistyped. Old  habits and all that.
18:41:37 <jwb> you're already overly complicated for a situation that happens relatively infrequently
18:41:48 <jwb> but as i said, i am not opposed
18:41:56 <sgallagh> (And yet when it last happened, it was a pain in the neck)
18:42:02 <thozza> I feel the same as jwb
18:42:22 <jwb> it was a pain in the neck because you guys got all worried about concerns that nobody expressed.
18:42:43 <mitr> jwb: we already has this concept (https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=Development/SteeringCommittee lists members per term), and it is somewhat needed to make sure the number of members standing for the even/odd elections continue to have about the same size
18:43:02 <jwb> mitr, yeah, i understand that part
18:43:05 <mitr> sgallagh: +1
18:43:19 <sgallagh> +1 to my own proposal (unsurprisingly)
18:43:22 <jwb> it's the whole more than less than release cycle, and changing of the term limits depending on when they were appointed, etc
18:43:25 <jwb> i'm +0
18:43:35 <thozza> sgallagh: +1
18:43:39 <dgilmore> I am with job +0
18:44:07 <nirik> weak +1 (if only to make us not need to keep discussing this. ;)
18:44:07 <dgilmore> jwb
18:44:12 <sgallagh> jwb: The idea there is that appointees should be in power for limited time, since they aren't directly chosen by the wider community.
18:44:24 <rishi> Yeah, I agree with jwb on that. A bit too confusing.
18:44:33 <ajax> +1, it's a corner case but at least it's written down
18:44:46 <jwb> i get the idea.  i disagree that it's a concern that warrants this complexity
18:44:49 <jwb> so +0
18:45:14 <paragan> sgallagh, +1
18:45:18 <jwb> people with more patience than me can figure out how to apply it if necessary :)
18:45:18 <mitr> It could perhaps be wordsmithed a bit but the concept is IMHO sound and wordsmithing a corner case is just not worth it
18:45:54 <sgallagh> I count +6, 2, -0. Who didn't vote?
18:46:04 <rishi> I'll add a weak +1
18:46:10 <sgallagh> ok
18:46:43 <sgallagh> #agreed New policy for filling vacated FESCo seats is approved (+7, 2, -0)
18:46:53 <sgallagh> #topic #1417 Unresponsive maintainer - Axel Thimm - athimm
18:46:54 <sgallagh> .fesco 1417
18:46:55 <zodbot> sgallagh: #1417 (Unresponsive maintainer - Axel Thimm - athimm) – FESCo - https://fedorahosted.org/fesco/ticket/1417
18:46:55 <nirik> sgallagh: you will add to the wiki?
18:47:05 <sgallagh> nirik: Yes
18:47:10 <sgallagh> #undo
18:47:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x5a5ae710>
18:47:11 <nirik> thanks.
18:47:11 <sgallagh> #undo
18:47:11 <zodbot> Removing item from minutes: AGREED by sgallagh at 18:46:43 : New policy for filling vacated FESCo seats is approved (+7, 2, -0)
18:47:20 <sgallagh> #action sgallagh to update the FESCo wiki with the new policy
18:47:29 <sgallagh> #topic #1417 Unresponsive maintainer - Axel Thimm - athimm
18:47:29 <sgallagh> .fesco 1417
18:47:31 <zodbot> sgallagh: #1417 (Unresponsive maintainer - Axel Thimm - athimm) – FESCo - https://fedorahosted.org/fesco/ticket/1417
18:47:39 <sgallagh> sonofa...
18:47:46 <sgallagh> #undo
18:47:46 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x9a5ed50>
18:47:46 <nirik> didn't we have one for him a while back?
18:47:58 <sgallagh> #agreed New policy for filling vacated FESCo seats is approved (+7, 2, -0)
18:48:03 <sgallagh> #topic #1417 Unresponsive maintainer - Axel Thimm - athimm
18:48:08 <sgallagh> (too many undos...)
18:48:18 <jwb> nirik, i thought so
18:48:21 <sgallagh> That still may be wrong, but I don't care.
18:49:51 <sgallagh> So this seems like a relatively straightforward unresponsive maintainer request.
18:50:05 <sgallagh> Do we actually need to vote on this, or will nirik just press the Big Red Button?
18:50:08 <mitr> … and needs a single FESCo member ACK only
18:50:13 <jwb> mattdm was supposedly going to talk to him like 3 times
18:50:25 <sgallagh> I'll Ack it
18:50:25 <jwb> i'm guessing either that didn't happen or he got no reply?
18:50:36 <sgallagh> If he becomes responsive, he can always reapply for comaintainership
18:50:42 <mitr> jwb: No that was #1388
18:50:43 * mattdm wakes up
18:50:53 <nirik> well, was the process followed? (granted the process sucks. )
18:50:54 <mattdm> I just, a few minutes ago, got an email back
18:51:01 <sgallagh> ...
18:51:17 <mattdm> he says that he is fixed the echoping packages
18:51:25 <sgallagh> mattdm: That's ixs, different person
18:51:28 <jwb> mitry, mattdm, my confusion
18:51:34 <paragan> yes that is different person
18:51:35 <mitr> nirik: I haven’t actually checked so I am not giving the ack on this today
18:51:35 <jwb> we're talking about axel now
18:51:43 <mattdm> ohhhh. never mind :)
18:51:47 <jwb> mitr, sgallagh already gave the ack
18:51:51 <jwb> we're done now
18:52:00 <mitr> great
18:52:10 <sgallagh> nirik: Will you handle the mechanics?
18:52:30 <sgallagh> #info Axel Thimm's packages will be orphaned.
18:52:30 <nirik> sure.
18:52:40 <sgallagh> #action nirik to perform the orphaning.
18:53:05 <sgallagh> #topic #1416 F22 Changes - Progress at Change Checkpoint: Completion deadline (testable)
18:53:05 <sgallagh> .fesco 1416
18:53:06 <zodbot> sgallagh: #1416 (F22 Changes - Progress at Change Checkpoint: Completion deadline (testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1416
18:53:10 <sgallagh> jreznik: ping ^^
18:54:23 <jreznik> sgallagh: I'm here
18:54:56 <thozza> I would also discuss the BIND 9.10 Change, since there is a problem with DHCP
18:54:59 <jreznik> I think we look pretty good
18:55:01 <sgallagh> So what do we need to do here? Decide on whether to fire any contingency plans?
18:55:31 <jreznik> wine change seems to be candidate to kill it
18:55:46 <jreznik> and I'm not sure I completely understood python 3 change
18:56:09 <sgallagh> The WINE change as I understand it wasn't upstream sanctioned either
18:56:29 <mitr> jreznik: AFAICT some kind of migration will continue but we will not have any Python-2-free product
18:56:32 <sgallagh> Proposal: invoke contingency plan for the WINE Change.
18:56:54 <mitr> sgallagh: is there even anything to revert in wine?
18:57:20 <jreznik> mitr: no but this change was probably doomed from the beginning the way it was approved
18:57:25 <mitr> Proposal: ACK the status, revisit at beta checkpoint.  No changes to schedule needed.
18:58:00 <sgallagh> mitr: Before that, I'd like to hear thozza's comments about BIND
18:58:03 <mitr> jreznik: I agree but I feel too lazy to specifically single it out and make it an exception to the generic process.  It will likely be still not done by the next checkpoint and we just kill it then with the others.
18:58:09 <mitr> sgallagh: right, sorry
18:58:24 <jreznik> mitr: I'm ok with this solution too
18:58:26 <sgallagh> np
18:58:38 <thozza> sgallagh: so the current status is in https://bugzilla.redhat.com/show_bug.cgi?id=1181562
18:59:08 <thozza> the bottom line is that ISC DHCP built against BIND 9.10 does not work in the background (demonized)
18:59:23 <thozza> and upstream knows about it, because they didn't finish the work
18:59:36 <thozza> and they don't seem to have any plan/schedule
19:00:00 <thozza> so either I go to FPC and ask for exception for DHCP to build against bundled BIND version
19:00:01 <nirik> lovely
19:00:03 <sgallagh> thozza: Have you tested option 2)
19:00:04 <sgallagh> ?
19:00:04 <thozza> or revert the change
19:00:26 <thozza> sgallagh: you mean the FPC?
19:00:41 <sgallagh> thozza: I mean, you're sure that the bundled version works?
19:00:53 <sgallagh> Before asking for a bundle exception
19:01:05 <rishi> ajax: Did you look at https://fedoraproject.org//wiki/Changes/Wine_to_use_mesa_Direct3D ?
19:01:15 <thozza> sgallagh: to be honest, we didn't test it, but it is the way it worked before in Fedora
19:01:19 <thozza> before unbundling
19:01:27 <thozza> and it is the way supported by upstream
19:01:38 <thozza> also they ship the latest bind 9.9.x
19:01:41 <thozza> bundled
19:02:00 <thozza> sgallagh: but sure, I will test it before asking for exception
19:02:03 <ajax> rishi: i'd seen that mesa started building it, but i hadn't heard of the wine change until just now
19:02:28 <thozza> I think there is 99% chance it will work
19:02:39 <sgallagh> Proposal: FESCo recommends that FPC grant a bundling exception for DHCP/BIND in Fedora 22.
19:02:41 <sgallagh> +1
19:03:01 <sgallagh> (obviously contingent upon thozza's test passing)
19:03:11 <thozza> right
19:03:17 <nirik> ugly. :( Another thing to bugfix and security update...
19:03:36 <thozza> nirik: DHCP is released also on BIND CVEs
19:03:36 <ajax> i mean, yes, it's isc code
19:03:38 <sgallagh> nirik: I think it's less ugly than reverting at this stage
19:03:40 <thozza> co basically a rebase
19:03:49 <ajax> isc code has been a cve breeding ground forever
19:04:10 <mitr> Well thozza (co-)maintains both so if he’d rather bundle to get the Change through, fine.
19:04:36 <nirik> alright. and it will be only until the work is done to move to the new one?
19:04:42 <dgilmore> in this case i would go with thozza as he has to do the work
19:04:51 <ajax> +1 to the exception
19:04:55 <thozza> I think that reverting BIND 9.10 may make upstream do something, but I think we want rather 9.10 in Fedora
19:05:18 <dgilmore> +1
19:05:22 <thozza> especially because FreeIPA uses the PKCS#11 interface from 9.10
19:05:33 <thozza> sgallagh: +1 for the proposal
19:05:37 <sgallagh> thozza: Correct me if I'm wrong, but didn't FreeIPA have to adapt for 9.10? Wouldn't it cause them to have to revert as well?
19:05:47 <sgallagh> (Just adding justification for bundling rather than reverting)
19:05:58 <paragan> sgallagh, +1 for exception
19:06:06 <sgallagh> /me sees that thozza predicted my question
19:06:13 <thozza> sgallagh: no, since I backported the pkcs#11 to bind 9.9.x but it is a 22k lines patch ;)
19:06:15 <nirik> well, FPC grants these, not us. ;) But I think a limited time one in this case they might go for
19:06:20 <sgallagh> /me shudders
19:06:41 <sgallagh> nirik: I'd like to think they'd accept our recommendation (which is how I phrased it)
19:07:01 <mitr> thozza: "no plan (and estimate) on when this could be fixed" means that they do plan to eventually get this done, right?
19:07:03 <rishi> +1, I trust thozza since he owns the packages
19:07:06 <thozza> right, I know they grant it, I just wanted some recommendation from FESCo
19:07:20 <nirik> sgallagh: I'm sure they will take it into consideration. ;)
19:07:22 <thozza> mitr: once 9.9.x goes EOL
19:07:36 <thozza> but there is no plan when this will happen
19:07:45 <thozza> mitr: so basically you are right
19:07:48 <mitr> sgallagh: +1
19:08:21 <thozza> mitr: they have to fix it eventually ;)
19:08:31 <sgallagh> #agreed FESCo recommends that FPC grant a bundling exception for DHCP/BIND in Fedora 22. (+7, 0, -0)
19:08:48 <sgallagh> So with that, I think we're done with this topic?
19:08:54 * nirik nods
19:09:00 <sgallagh> #topic Next week's chair
19:09:11 <sgallagh> Who wants it?
19:09:46 <sgallagh> Bueller?
19:09:48 <ajax> i will i guess
19:09:57 <sgallagh> /me Ballmer's a chair at ajax
19:10:09 <sgallagh> #action ajax to chair next week's meeting
19:10:13 <sgallagh> #topic Open Floor
19:10:38 <sgallagh> akurtakov: Are you around? I'd like to hear the summary of the discussion you had with the FreeIPA folks today RE: tomcat 8
19:10:47 <sgallagh> I've been busy and didn't get a chance to read the whole thign
19:11:05 <akurtakov> sgallagh: on the phone now
19:11:36 <akurtakov> but if there is question I would try answering it
19:11:51 <nirik> there's still grumblings of a xfce 4.12 this coming weekend. ;) We intend to land it in rawhide when/if it releases and see how stable things look before proposing anything for f22.
19:12:09 <sgallagh> akurtakov: Short version: is it likely that dogtag can be patched to support Tomcat 8 within the next week?
19:12:17 <sgallagh> Do we know the extent of the incompatibility?
19:12:25 <sgallagh> nirik: good luck!
19:12:42 <nirik> yeah, we will see.
19:12:59 <akurtakov> sgallagh: I still haven't seen a real problem shown , there si no info that the very first one pointed to is not a single line delete
19:13:21 <sgallagh> ok
19:13:21 <akurtakov> so until more concrete info is shown I would say yes
19:13:27 <mitr> (note that I have found the patch but not even tried to understand it)
19:13:32 <sgallagh> Fair enough
19:14:01 <akurtakov> I can promise trying to provide ideas about porting
19:14:19 <akurtakov> but not actually trying/doing them
19:17:18 <sgallagh> OK, we obviously need more information here. I'll await to hear from the dogtag people.
19:17:25 <sgallagh> Any other Open Floor topics?
19:17:42 <thozza> no
19:17:55 <ajax> nope
19:18:13 <thozza> mitr: what about the whenisgood?
19:18:20 <sgallagh> Hmm?
19:18:21 <mitr> Ah.
19:18:23 <thozza> or how it's called
19:18:38 <mitr> Sorry, I was expecting that to be handled at the previous meeting
19:18:42 * mitr digs out the result link
19:18:55 <mitr> http://whenisgood.net/ykgweic/results/8dbmm43
19:19:19 <sgallagh> I forgot to reply, but I'm free either of the open slots
19:19:19 <nirik> cool. we could meet 2 times for an hour each. ;)
19:19:27 <sgallagh> But I'd prefer the Monday one
19:19:44 <jwb> i would welcome a 1 hour meeting.
19:19:45 <thozza> what time zone it is?
19:19:49 <thozza> :D
19:19:59 <sgallagh> oh, good question...
19:20:00 <sgallagh> one moment
19:20:01 <mitr> AFAICT GMT
19:20:12 <nirik> it has a timezone setting thing
19:20:32 <nirik> oh I guess thats just for submitting
19:20:40 <mitr> The "edit event" page does say GMT
19:20:57 <ajax> once you click through on a slot it shows the local time for each respndent
19:20:59 <sgallagh> OK, so if I read that correctly, it's 10:00 AM EST?
19:21:07 <sgallagh> Ah right
19:21:12 <sgallagh> OK, so my previous statement stands :)
19:21:35 <sgallagh> I can do either Monday or Friday (or, I guess, both if needed)
19:21:51 <ajax> would prefer monday, personally
19:21:54 * nirik hates early meetings, but whatever .
19:22:02 <thozza> does not matter for me
19:22:06 <thozza> monday is good
19:22:23 * dgilmore missed the announcement for teh whenisgood
19:22:46 <sgallagh> Only issue with Monday is "When does the agenda need to go out?"
19:22:53 <mitr> Monday meeting would sending the meeting agenda on Sunday, or perhaps already on Friday
19:22:59 <mitr> sgallagh: heh
19:23:13 <dgilmore> sgallagh: there is no issue, its covered in the meeting process it goes oout friday
19:23:20 <sgallagh> ok
19:23:34 <thozza> so monday it is?
19:23:44 <ajax> i say so.
19:23:52 <ajax> since i'm next at bat
19:23:52 <nirik> ugh, I guess so.
19:24:00 <sgallagh> #info FESCo meetings will be held on Mondays at 1500 UTC
19:24:09 <thozza> weeee :)
19:24:10 <dgilmore> sgallagh: thats no good
19:24:15 <sgallagh> ...
19:24:16 <thozza> why?
19:24:19 <sgallagh> #undo
19:24:19 <zodbot> Removing item from minutes: INFO by sgallagh at 19:24:00 : FESCo meetings will be held on Mondays at 1500 UTC
19:24:23 <dgilmore> sgallagh: releng meeting is mondays at 14:30
19:24:34 <dgilmore> and goes for 1 to 2 hours
19:24:37 <ajax> man that would have been nice to know
19:24:43 <ajax> alright fine
19:24:45 <ajax> friday
19:24:49 <sgallagh> dgilmore: Friday then?
19:24:52 <ajax> meaning the 6th
19:25:29 <nirik> I guess this timeslot wasn't still good
19:25:49 <jwb> which is odd, because almost everyone is here.
19:26:09 <nirik> yeah
19:26:22 <thozza> jwb: although it is not ideal
19:26:24 <sgallagh> nirik: It's generally not good for rishi and paragan IIRC
19:26:32 <mitr> whenisgood could do with a level-of-badness mechanism
19:26:43 <sgallagh> Which the whenisgood appears to agree with
19:26:50 <nirik> ah, ok.
19:26:51 <paragan> sgallagh, I am okay with 1500 UTC on any day
19:27:27 <sgallagh> paragan: That wasn't the question
19:27:37 <sgallagh> dgilmore: Does Friday work for you?
19:27:38 <paragan> ah sorry what I missed
19:28:02 <dgilmore> sgallagh: no
19:28:04 <sgallagh> paragan: This current timeslot was bad for you as an ongoing thing
19:28:11 <paragan> yes it is
19:28:15 * dgilmore just added to the results
19:28:30 <nirik> yea. 0 slots
19:28:34 <thozza> :D
19:28:45 <dgilmore> sgallagh: basewg meeting is on friday
19:28:46 <jwb> no more meetings, do everything via tickets and mail.
19:29:03 <nirik> proposal: everyone revisit their answers and try and add more times and revisit next week? ;)
19:29:44 <thozza> nirik: +1 (also to kill this meeting for today)
19:29:49 <sgallagh> The 1600 UTC slot has a different person missing it every day; maybe we rotate through those each week? :)
19:30:27 <ajax> so what i'm hearing is, same time next week.
19:30:32 <jwb> yes
19:30:35 <sgallagh> yes
19:30:37 <ajax> that's when i'll be here, y'all can do whatever i guess
19:30:39 <dgilmore> in theory nirik can't make the monday slot either
19:30:52 <nirik> true.
19:31:00 * rishi quick reads
19:31:03 <rishi> *quickly
19:31:10 <nirik> forgot about that meeting. or timezones confused me
19:31:30 <rishi> sgallagh: I am in CET.
19:31:39 <rishi> Anything not in the middle of the night works for me.
19:31:47 <paragan> so vote again for time slots only for Tue to Thu ?
19:32:17 <sgallagh> paragan: Just look at your votes a second time and remove any "no" votes that were just "inconvenient" votes, I guess
19:32:38 <paragan> um okay
19:32:48 <dgilmore> mitr: you said you can not make the current time slot. is it possible to re-evaluate that?
19:33:27 * rishi puts green on a few more boxes
19:33:29 <mitr> dgilmore: I can make the current one, but rather not the one-hour later.
19:33:44 <dgilmore> mitr: okay
19:33:44 <mitr> (the semantics for two-hour meetings is ambiguous)
19:35:10 <nirik> are we done? ;)
19:35:18 <ajax> i certainly am
19:35:27 <sgallagh> Ending the meeting.
19:35:31 <ajax> see you same time on the 4th
19:35:31 <sgallagh> 3...
19:35:40 * nirik nods
19:35:42 <sgallagh> 2...
19:35:43 <thozza> \o/
19:35:51 <sgallagh> 1...
19:35:57 <sgallagh> #endmeeting