18:01:14 #startmeeting FESCO (2015-02-25) 18:01:14 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:14 #meetingname fesco 18:01:14 The meeting name has been set to 'fesco' 18:01:14 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:01:14 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:01:14 #topic init process 18:01:19 I AM PRESENT 18:01:24 * ajax waves 18:01:24 Hi 18:01:25 I AM PAST 18:01:26 morning 18:01:33 * rishi waves 18:01:46 hi all 18:02:41 Hello 18:03:41 That's everyone except dgilmore 18:03:47 Guess we'll start and see if he joins later 18:03:58 #topic #1367 Please define package manager expectations 18:03:58 .fesco 1367 18:03:59 sgallagh: #1367 (Please define package manager expectations) – FESCo - https://fedorahosted.org/fesco/ticket/1367 18:05:01 So I put this on the agenda mainly because we planned to revisit at Alpha Freeze 18:05:20 Im here 18:05:21 Mostly, I assume, for us to decide whether we were going to try to back out of DNF as default 18:05:32 we should probably retitle the ticket 18:05:35 but sure 18:05:58 * jreznik is around, ping me if you need me 18:06:00 there's a bit more wiki pages and such now. 18:06:25 I don't know that we have any 'this is required for dnf' document asked for... 18:06:38 I think we need to evaluate this after alpha 18:07:08 nirik: I think we explicitly refused to produce that ☺ 18:07:25 yeah, I don't see us doing that... 18:07:51 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 nirik: Per comment 6, the outstanding question is basically “are we happy with …/cli_vs_yum.html” 18:08:31 dgilmore: at this point I don't think that would do anything good. 18:08:47 adamw has a tracker bug with some interesting depsolver issues 18:08:54 nirik: maybe 18:08:55 * randomuser hunts for it 18:09:00 there is one more document also available http://dnf.readthedocs.org/en/latest/user_faq.html 18:09:40 nirik: Why not? 18:09:44 dgilmore: Why does the package name matter, when the dnf-yum package provides the existing /usr/bin/yum path and command? 18:10:03 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 https://bugzilla.redhat.com/show_bug.cgi?id=1192182 18:10:11 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 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 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 also it means going back to yum (for example when a bug is being fixed in dnf) hard. 18:11:27 At the minimum, if we are going to make dnf-yum a default, it should happen in Rawhide for f23 18:11:29 mitr: a lot when it comes to, downstreams, systems management tools, documentation etc. 18:11:34 It's too late in the cycle to do that in F22 18:11:53 dgilmore: I don’t understand. Could you give me an example of what would be broken? 18:11:56 mitr: we would really need to make dnf require dnf-yum 18:12:08 dgilmore: The package name doesn’t matter, it is in the default set anyway, isn’t it? 18:12:17 mitr: its not 18:12:59 mitr: I can see downstreams wanting to have it changed. 18:13:21 if we make dnf-yum default, it removes yum from all systems. 18:14:29 Before we go too far, can we vote on this: 18:14:29 Proposal: Providing /usr/bin/yum as a symlink for /usr/bin/dnf should not happen in Fedora 22 18:14:34 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 I'm +1 simply because it's too late to address any fallout from it. 18:14:46 sgallagh: then what does http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF end up meaning? 18:14:47 *Are the changes 18:15:24 rishi: oh yes, IMHO. Command line options that aren't accepted, different dep solving... lots of things. 18:15:29 mitr, presumable the first two bullets under "practical changes" ? 18:15:31 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 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 It also means that any tools that call yum directly should be migrated (I did so for rolekit, for example) 18:16:16 sgallagh: Removing the /usr/bin/yum path from the default install seems to me worse than any other option. 18:17:03 mitr: What in that bug claims they're ready to add the symlink? 18:17:03 (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 sgallagh: It is the original plan and there is no claim otherwise, isn’t that the default position? 18:17:58 is anaconda using the dnf backend now? 18:18:02 yes 18:18:02 OK, fair enough 18:18:11 is dnf installed by default and yum isnt? 18:18:21 jwb: Currently both are installed 18:18:27 jwb: afaik dnf is used by anaconda 18:18:27 that seems silly 18:18:38 I am not sure what you get on a minimal install though 18:18:41 sgallagh: in what context? 18:18:55 nirik: Sorry, to clarify: both were installed by the Workstation Live 18:19:01 I can confirm DNF is the default in Anaconda 18:19:03 Which I was forced to do the other day 18:19:10 ok. yum isn't in comps, so something is pulling it in? 18:19:14 sgallagh, uh, the f22 live? 18:19:16 (Bad upgrade forced a rebuild of my machine) 18:19:20 jwb: Yes,the F22 live 18:19:27 sgallagh: yum is probably pulled in by mock or something else 18:19:28 I installed from the 2/21 nightly 18:19:39 dgilmore: That may be true, but it was there 18:19:39 i am surprised it even booted 18:19:50 jwb: It's running quite nicely, actually 18:19:51 sgallagh: a minimal base install using anaconda is what should evaluated 18:20:03 ok, so modulo some kind of dep bug, it sounds like dnf is already the default 18:20:15 so we're down to talking about a symlink 18:20:18 jwb: yes 18:20:25 which i frankly don't think is important either way 18:20:30 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 (Why do all the yum-dnf bugs have the same subject? Makes it very confusing.) 18:21:01 so on such a setup, what did "dnf remove yum" try to remove? 18:21:03 sgallagh: what do you get on server or cloud? 18:21:09 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 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 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 nirik, i don't like it much either, but i am not willing to argue for more than 5min about it 18:21:53 ajax: Just yum, actually (though it's trying to upgrade a bunch of other stuff simultaneously..) 18:22:04 randomuser, likely 18:22:27 it was changed in comps, so something is dragging it in... it shouldn't be needed. 18:22:29 sgallagh: okay, i guess a better question is what does 'rpm -e yum' complain about 18:22:36 nirik: mock most likely 18:22:36 ajax: Oh, correction. I misread. 18:22:46 It's trying to remove a whole bunch of python and rpm stuff 18:22:54 And abrt... 18:23:08 sgallagh: yes abrt is staill hardcoded for yum 18:23:15 “libreport-python - port is almost finished, only one DNF feature is needed [4] (PR created).” 18:23:19 http://paste.fedoraproject.org/190420/42488857/ 18:24:22 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 the cloud image seems to not have yum installed 18:24:57 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 but the kickstart does use yum to remove firewalld 18:25:46 OK, we've been on this topic for more than 20 minutes. 18:25:46 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 Does anyone have another proposal? 18:25:51 * randomuser shuts up 18:26:15 sgallagh: can you please repeat the current one? since I somehow lost it in the discussion 18:26:33 proposal: close ticket, ask change owners to not make dnf-yum default, change otherwise continues for f22. 18:26:51 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 nirik: That's essentially a rephrasing of my earlier proposal. I've actually changed my opinion. 18:27:30 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 proposal: We are fine with the DNF change as is (dnf-yum included), close ticket. 18:27:31 ok. 18:27:46 Formally: 18:27:48 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 nirik: oh? 18:28:25 but I cannot find the post. 18:28:28 it was on devel list. 18:28:48 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 /me wishes jzeleny or someone was here. 18:29:06 I think forcing that change on our users is a very bad idea. 18:29:21 I'm for the mitr's proposal 18:29:22 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 nirik: So are we removing yum _ever_? If so, why not now? 18:29:49 mitr: at some point we have to remove it 18:29:51 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 sgallagh: +1 18:29:59 dgilmore, why? 18:30:04 so, if you don't want any fedpkg. ;) 18:30:30 jsilhan is confirming there is no plan to add dnf-yum package default in f22 18:30:39 nirik: fair point 18:30:42 nirik: What is the blocking the packaging tools? 18:30:48 work 18:30:51 paragan: If that's true, then ok 18:31:08 Shall we just accept that things are moving along fine, then and get to the next topic? 18:31:10 just asked him in PM 18:31:15 yes 18:31:16 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 but dnf-yum should be at least added to rawhide as soon as possible... 18:31:37 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 thozza: it's available. 18:31:43 mitr: right now we can not remove it because if we remove yum we remove the ability to make Fedora 18:31:48 I mean install it by default 18:32:08 nirik: ^ 18:32:09 thozza: then anyone using rawhide can't maintain packages? 18:32:10 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 -1000 18:32:13 sgallagh, ok 18:32:16 rishi: -1 18:32:23 nirik: Do we actually know that dnf-yum breaks packaging tools? 18:32:30 rishi: yeah, something like that 18:32:32 mitr: it conflicts with yum 18:32:38 mitr: it breaks installing yum 18:32:40 oh, silly me. right. 18:32:41 you must remove yum, which removes everything that uses it 18:32:48 mitr: which breaks making fedora 18:32:57 mitr: what else it breaks who knows 18:33:13 we need to do the switch anyway 18:33:18 it's IMHO still a bad idea after that, but at least we need to fix those things first 18:33:32 Hmm... createrepo needs yum - http://paste.fedoraproject.org/190420/42488857/ 18:33:39 Proposal: FESCo takes no action. 18:33:43 Move on to other topics... 18:33:47 So, I guess it is too early for dnf-yum anyway. 18:33:52 +1 inaction 18:34:00 sgallagh: 30mins and... ok, sure. +1 :) 18:34:06 sgallagh, +1 18:34:08 sgallagh: +1 18:34:09 +1 18:34:16 sgallagh: Actually, …and closes the ticket, right? 18:34:24 Fine 18:34:33 (probably implied) 18:35:07 +1 18:35:07 #agreed FESCo takes no action (+6, 0, -0) 18:35:11 #undo 18:35:11 Removing item from minutes: AGREED by sgallagh at 18:35:07 : FESCo takes no action (+6, 0, -0) 18:35:13 +1 18:35:19 yes 18:35:26 yes close the ticket and if needed open new with specific details 18:35:28 #agreed FESCo takes no action (+8, 0, -0) 18:35:44 #topic #1388 Remove echoping from the distribution 18:35:45 .fesco 1388 18:35:48 sgallagh: #1388 (Remove echoping from the distribution) – FESCo - https://fedorahosted.org/fesco/ticket/1388 18:36:13 This appears to have mostly resolved itself, unless we want to discuss ixs' tendency towards absentee maintainership 18:37:02 i don't 18:37:04 I'm inclined to just close it and move on 18:37:06 perhaps we could contact him and ask if he would like us to solicit co-maintainers? 18:37:13 sure. thats fine too 18:37:33 #info Ticket has resolved itself and will be closed 18:37:43 #topic #1326 change to fesco replacement process? 18:37:44 .fesco 1326 18:37:46 sgallagh: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326 18:38:19 I proposed a hopefully clearer version of my proposal 18:38:38 sgallagh: you mean the one that was not clear for jwb? 18:38:39 :) 18:38:44 jwb: To answer your one question, let's assume that we have seats 1-9. 18:38:46 that still seems kinda complicated, but I guess I can +1 it. 18:39:06 even numbered seats are elected at the start of even-numbered Fedoras, and vice-versa 18:39:42 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 sgallagh: s/The Board/Council/ 18:41:31 dgilmore: Yes, I mistyped. Old habits and all that. 18:41:37 you're already overly complicated for a situation that happens relatively infrequently 18:41:48 but as i said, i am not opposed 18:41:56 (And yet when it last happened, it was a pain in the neck) 18:42:02 I feel the same as jwb 18:42:22 it was a pain in the neck because you guys got all worried about concerns that nobody expressed. 18:42:43 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 mitr, yeah, i understand that part 18:43:05 sgallagh: +1 18:43:19 +1 to my own proposal (unsurprisingly) 18:43:22 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 i'm +0 18:43:35 sgallagh: +1 18:43:39 I am with job +0 18:44:07 weak +1 (if only to make us not need to keep discussing this. ;) 18:44:07 jwb 18:44:12 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 Yeah, I agree with jwb on that. A bit too confusing. 18:44:33 +1, it's a corner case but at least it's written down 18:44:46 i get the idea. i disagree that it's a concern that warrants this complexity 18:44:49 so +0 18:45:14 sgallagh, +1 18:45:18 people with more patience than me can figure out how to apply it if necessary :) 18:45:18 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 I count +6, 2, -0. Who didn't vote? 18:46:04 I'll add a weak +1 18:46:10 ok 18:46:43 #agreed New policy for filling vacated FESCo seats is approved (+7, 2, -0) 18:46:53 #topic #1417 Unresponsive maintainer - Axel Thimm - athimm 18:46:54 .fesco 1417 18:46:55 sgallagh: #1417 (Unresponsive maintainer - Axel Thimm - athimm) – FESCo - https://fedorahosted.org/fesco/ticket/1417 18:46:55 sgallagh: you will add to the wiki? 18:47:05 nirik: Yes 18:47:10 #undo 18:47:10 Removing item from minutes: 18:47:11 thanks. 18:47:11 #undo 18:47:11 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 #action sgallagh to update the FESCo wiki with the new policy 18:47:29 #topic #1417 Unresponsive maintainer - Axel Thimm - athimm 18:47:29 .fesco 1417 18:47:31 sgallagh: #1417 (Unresponsive maintainer - Axel Thimm - athimm) – FESCo - https://fedorahosted.org/fesco/ticket/1417 18:47:39 sonofa... 18:47:46 #undo 18:47:46 Removing item from minutes: 18:47:46 didn't we have one for him a while back? 18:47:58 #agreed New policy for filling vacated FESCo seats is approved (+7, 2, -0) 18:48:03 #topic #1417 Unresponsive maintainer - Axel Thimm - athimm 18:48:08 (too many undos...) 18:48:18 nirik, i thought so 18:48:21 That still may be wrong, but I don't care. 18:49:51 So this seems like a relatively straightforward unresponsive maintainer request. 18:50:05 Do we actually need to vote on this, or will nirik just press the Big Red Button? 18:50:08 … and needs a single FESCo member ACK only 18:50:13 mattdm was supposedly going to talk to him like 3 times 18:50:25 I'll Ack it 18:50:25 i'm guessing either that didn't happen or he got no reply? 18:50:36 If he becomes responsive, he can always reapply for comaintainership 18:50:42 jwb: No that was #1388 18:50:43 * mattdm wakes up 18:50:53 well, was the process followed? (granted the process sucks. ) 18:50:54 I just, a few minutes ago, got an email back 18:51:01 ... 18:51:17 he says that he is fixed the echoping packages 18:51:25 mattdm: That's ixs, different person 18:51:28 mitry, mattdm, my confusion 18:51:34 yes that is different person 18:51:35 nirik: I haven’t actually checked so I am not giving the ack on this today 18:51:35 we're talking about axel now 18:51:43 ohhhh. never mind :) 18:51:47 mitr, sgallagh already gave the ack 18:51:51 we're done now 18:52:00 great 18:52:10 nirik: Will you handle the mechanics? 18:52:30 #info Axel Thimm's packages will be orphaned. 18:52:30 sure. 18:52:40 #action nirik to perform the orphaning. 18:53:05 #topic #1416 F22 Changes - Progress at Change Checkpoint: Completion deadline (testable) 18:53:05 .fesco 1416 18:53:06 sgallagh: #1416 (F22 Changes - Progress at Change Checkpoint: Completion deadline (testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1416 18:53:10 jreznik: ping ^^ 18:54:23 sgallagh: I'm here 18:54:56 I would also discuss the BIND 9.10 Change, since there is a problem with DHCP 18:54:59 I think we look pretty good 18:55:01 So what do we need to do here? Decide on whether to fire any contingency plans? 18:55:31 wine change seems to be candidate to kill it 18:55:46 and I'm not sure I completely understood python 3 change 18:56:09 The WINE change as I understand it wasn't upstream sanctioned either 18:56:29 jreznik: AFAICT some kind of migration will continue but we will not have any Python-2-free product 18:56:32 Proposal: invoke contingency plan for the WINE Change. 18:56:54 sgallagh: is there even anything to revert in wine? 18:57:20 mitr: no but this change was probably doomed from the beginning the way it was approved 18:57:25 Proposal: ACK the status, revisit at beta checkpoint. No changes to schedule needed. 18:58:00 mitr: Before that, I'd like to hear thozza's comments about BIND 18:58:03 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 sgallagh: right, sorry 18:58:24 mitr: I'm ok with this solution too 18:58:26 np 18:58:38 sgallagh: so the current status is in https://bugzilla.redhat.com/show_bug.cgi?id=1181562 18:59:08 the bottom line is that ISC DHCP built against BIND 9.10 does not work in the background (demonized) 18:59:23 and upstream knows about it, because they didn't finish the work 18:59:36 and they don't seem to have any plan/schedule 19:00:00 so either I go to FPC and ask for exception for DHCP to build against bundled BIND version 19:00:01 lovely 19:00:03 thozza: Have you tested option 2) 19:00:04 ? 19:00:04 or revert the change 19:00:26 sgallagh: you mean the FPC? 19:00:41 thozza: I mean, you're sure that the bundled version works? 19:00:53 Before asking for a bundle exception 19:01:05 ajax: Did you look at https://fedoraproject.org//wiki/Changes/Wine_to_use_mesa_Direct3D ? 19:01:15 sgallagh: to be honest, we didn't test it, but it is the way it worked before in Fedora 19:01:19 before unbundling 19:01:27 and it is the way supported by upstream 19:01:38 also they ship the latest bind 9.9.x 19:01:41 bundled 19:02:00 sgallagh: but sure, I will test it before asking for exception 19:02:03 rishi: i'd seen that mesa started building it, but i hadn't heard of the wine change until just now 19:02:28 I think there is 99% chance it will work 19:02:39 Proposal: FESCo recommends that FPC grant a bundling exception for DHCP/BIND in Fedora 22. 19:02:41 +1 19:03:01 (obviously contingent upon thozza's test passing) 19:03:11 right 19:03:17 ugly. :( Another thing to bugfix and security update... 19:03:36 nirik: DHCP is released also on BIND CVEs 19:03:36 i mean, yes, it's isc code 19:03:38 nirik: I think it's less ugly than reverting at this stage 19:03:40 co basically a rebase 19:03:49 isc code has been a cve breeding ground forever 19:04:10 Well thozza (co-)maintains both so if he’d rather bundle to get the Change through, fine. 19:04:36 alright. and it will be only until the work is done to move to the new one? 19:04:42 in this case i would go with thozza as he has to do the work 19:04:51 +1 to the exception 19:04:55 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 +1 19:05:22 especially because FreeIPA uses the PKCS#11 interface from 9.10 19:05:33 sgallagh: +1 for the proposal 19:05:37 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 (Just adding justification for bundling rather than reverting) 19:05:58 sgallagh, +1 for exception 19:06:06 /me sees that thozza predicted my question 19:06:13 sgallagh: no, since I backported the pkcs#11 to bind 9.9.x but it is a 22k lines patch ;) 19:06:15 well, FPC grants these, not us. ;) But I think a limited time one in this case they might go for 19:06:20 /me shudders 19:06:41 nirik: I'd like to think they'd accept our recommendation (which is how I phrased it) 19:07:01 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 +1, I trust thozza since he owns the packages 19:07:06 right, I know they grant it, I just wanted some recommendation from FESCo 19:07:20 sgallagh: I'm sure they will take it into consideration. ;) 19:07:22 mitr: once 9.9.x goes EOL 19:07:36 but there is no plan when this will happen 19:07:45 mitr: so basically you are right 19:07:48 sgallagh: +1 19:08:21 mitr: they have to fix it eventually ;) 19:08:31 #agreed FESCo recommends that FPC grant a bundling exception for DHCP/BIND in Fedora 22. (+7, 0, -0) 19:08:48 So with that, I think we're done with this topic? 19:08:54 * nirik nods 19:09:00 #topic Next week's chair 19:09:11 Who wants it? 19:09:46 Bueller? 19:09:48 i will i guess 19:09:57 /me Ballmer's a chair at ajax 19:10:09 #action ajax to chair next week's meeting 19:10:13 #topic Open Floor 19:10:38 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 I've been busy and didn't get a chance to read the whole thign 19:11:05 sgallagh: on the phone now 19:11:36 but if there is question I would try answering it 19:11:51 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 akurtakov: Short version: is it likely that dogtag can be patched to support Tomcat 8 within the next week? 19:12:17 Do we know the extent of the incompatibility? 19:12:25 nirik: good luck! 19:12:42 yeah, we will see. 19:12:59 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 ok 19:13:21 so until more concrete info is shown I would say yes 19:13:27 (note that I have found the patch but not even tried to understand it) 19:13:32 Fair enough 19:14:01 I can promise trying to provide ideas about porting 19:14:19 but not actually trying/doing them 19:17:18 OK, we obviously need more information here. I'll await to hear from the dogtag people. 19:17:25 Any other Open Floor topics? 19:17:42 no 19:17:55 nope 19:18:13 mitr: what about the whenisgood? 19:18:20 Hmm? 19:18:21 Ah. 19:18:23 or how it's called 19:18:38