18:00:49 <smooge> #startmeeting EPEL
18:00:49 <zodbot> Meeting started Wed Nov  2 18:00:49 2016 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:49 <zodbot> The meeting name has been set to 'epel'
18:00:49 <smooge> #meetingname EPEL
18:00:49 <zodbot> The meeting name has been set to 'epel'
18:00:49 <smooge> #chair smooge nirik Evolution bstinson avij
18:00:49 <zodbot> Current chairs: Evolution avij bstinson nirik smooge
18:00:49 <smooge> #topic aloha
18:01:00 <smooge> .hello smooge
18:01:01 <zodbot> smooge: smooge 'Stephen J Smoogen' <smooge@gmail.com>
18:01:08 <avij> .hello avij
18:01:09 <zodbot> avij: avij 'Anssi Johansson' <rhbugs@miuku.net>
18:01:20 <nirik> .hello kevin
18:01:21 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
18:01:56 <smooge> ok I am pinging Evolution and bstinson
18:02:17 <bstinson> .hello bstinson
18:02:18 <zodbot> bstinson: bstinson 'Brian Stinson' <bstinson@ksu.edu>
18:02:40 <moto-timo> .hello ttorling
18:02:42 <zodbot> moto-timo: ttorling 'Tim Orling' <ticotimo@gmail.com>
18:03:01 <smooge> ok we have quorum
18:03:11 <smooge> The topics I have fo rthis weeek
18:03:26 <smooge> #info Topic: mongodb update
18:03:48 <smooge> #info Topic: django death in EL6/ big update in EL7
18:04:34 <smooge> #info Topic: ...
18:04:47 <smooge> Anything else?
18:04:49 <nirik> meeting time I guess
18:04:56 <nirik> if we want to paint the DST bikeshed
18:05:31 <smooge> AH ok. I thought we painted it last time where I thought it changed and everyone said no it is always at the same UTC timestamp :)
18:05:42 <smooge> but it is time for a fresh coat
18:05:52 <smooge> #topic Meeting time change?
18:06:15 <smooge> Does keeping the meeting at 1800 UTC cause problems for people?
18:06:23 <moto-timo> not here
18:06:33 <avij> 19:00 UTC is OK for me. it does not make much of a difference to me in this timezone, it'll be an evening nevertheless.
18:06:37 <bstinson> UTC wfm
18:06:41 <avij> sorry, 18:00 UTC :)
18:06:54 <avij> (I can't count)
18:07:11 <smooge> nirik, does this cause a conflict for you next week?
18:07:20 <nirik> nope, staying is fine with me...
18:08:14 <smooge> well that leaves manager man..
18:08:35 <smooge> I hope it is ok for him. but we have 4 +1
18:08:36 <Evolution> ....
18:08:40 <Evolution> +1
18:08:48 <smooge> yay
18:09:02 <smooge> #agreed Meeting stays at 1800 UTC
18:09:13 <smooge> #topic mongodb update
18:09:56 <smooge> so this has been part of the conversation on the list this week. I believeMarek Skalický would like to update due to various issues
18:10:08 <smooge> it will cause problems so he was looking for guidance/approval
18:11:25 <smooge> I am of the "its a web-architecture software which runs on different time scales than "Enterprise" software"
18:12:06 <Evolution> it's mongodb. causing problems means it's working as expected.
18:12:09 <nirik> as always we do the best we can. If something is no longer supported upstream and backporting security/major fixes is not doable, upgrading is the only choice.
18:12:25 <avij> wise words from nirik
18:12:43 <bstinson> yeah i think wide-announcement + time in epel-testing is the way to go
18:13:01 <Evolution> that works fine for me.
18:13:04 <smooge> proposal: EPSCO has no problems with plan of wide-announcement + time in epel-testing
18:13:09 <moto-timo> seems very reasonable
18:13:31 <nirik> +1
18:13:35 <avij> +1
18:13:35 <smooge> +1
18:13:40 <Evolution> +1
18:13:44 <bstinson> +1
18:13:51 <smooge> thanks bstinson for the wording
18:14:14 <smooge> #agreed EPSCO has no problems with plan of wide announcement + time in EPEL-testing for mongodb upgrade
18:14:30 <smooge> #topic django heartache
18:15:04 <smooge> OK I got a bug yesterday for the version of django in EL6 which has a couple of security bugs in it.
18:16:06 <smooge> I took over the package because it was orphaned and was causing a long list of other stuff to be pulled. However i am not seeing an easy way to fix/keep up with the problems in this package so am going to do what mrunge felt should have been done 4 months ago.. orphan/retire
18:16:39 <nirik> fair enough. That will need to light a fire under one of our services, but thats ok... needs to be done
18:16:44 <smooge> the only fix I can 'see' would be to build a python27 for RHEL6 and redo all the python items for it
18:17:13 <moto-timo> yep
18:17:15 <mrunge> smooge, nirik isn't there a python34 stack now on epel6?
18:17:20 <smooge> however I am not a python guru and not sure I would be "reasonable" to take it over
18:17:21 <bstinson> that will need to be done...carefully. something in the python-fedora universe needs a chunk of that iirc
18:17:21 <nirik> IMHO, ENOTWORTHIT
18:17:22 <smooge> ask
18:17:35 <moto-timo> yes, orion and I brought python34 to el6
18:17:36 <orionp> mrunge: just starting, but yes
18:17:49 <mrunge> that would be an option for django-1.8, i.e long term supported version
18:18:01 * orionp is currently battling with acient sphinx...
18:18:10 <moto-timo> I am willing to consider that path
18:18:27 <smooge> orionp, why do you need an ancient sphinx?
18:18:28 <moto-timo> as a non-proven packager it is a tough slog for me
18:18:30 * nirik would like 1.8 for epel7 too... if they both used python34 it might be spreading that work around
18:18:39 <mrunge> but still smooge is right, web apps and lts and stable infra don't mix well
18:18:40 <orionp> smooge: I don't need it, EL6 has it
18:19:13 <mrunge> nirik, I would *love* django-1.8 in epel7, but that would break e.g reviewboard
18:19:13 <moto-timo> python3-pytest depedency <- sphinx
18:19:16 <smooge> orionp, ah.. I was thinking there would be a python34-sphinx instead but I expect that breaks things
18:19:32 <bmbouter> when django14 was retired last time boy was it bad for the software I work on
18:19:43 <nirik> mrunge: I thought they had moved up... but I haven't looked in a long time
18:19:45 <bmbouter> I begged mrunge to bring it back
18:19:52 <mrunge> sorry about that, bmbouter
18:20:01 <orionp> yeah, I maintain cobbler and use it on EL6 which needs django
18:20:14 <mrunge> still it's time to move on. django 1.4 is dead for a long time now
18:21:41 <orionp> agreed
18:21:44 <bmbouter> the new package wouldn't be called Django14 though, could we just keep that one there
18:22:14 <bmbouter> we are moving our community off of it, but existing users would loose access to the bits
18:22:26 <mrunge> if I remember right, there were a few cve, which are not patched in 1.4
18:22:36 <mrunge> but, they are not that ugly
18:22:37 <nirik> well, the problem is that the longer it sits there, the more security issues pile up
18:23:31 <mrunge> you have to use specific options like debug mode turned on, or oracle as database backend
18:24:28 <nirik> well, if the issues aren't major we could keep it limping along, but not sure we even really know...
18:25:03 <bmbouter> I can't speak for other usages, but our project looked at the cve's when Django14 was removed last time and found none of the cves affected us
18:25:48 <smooge> well I would like to figure out what packages require this one and what either needs a major bump or removal also
18:26:38 <moto-timo> plus some kind of cve audit
18:27:20 <bmbouter> I remember there being several issues with upgrading django in epel6, mainly that the current django LTS 1.8 and it requires a newer python than is in base or epel
18:27:36 <smooge> correct.
18:27:46 <moto-timo> so will python34 meet the need?
18:27:52 <bmbouter> yes it would
18:27:57 <mrunge> yep, python 2.7 vs. 2.6. but 3.4 is fine
18:28:12 <bmbouter> the LTS needs 2.7 as I remember it also
18:28:13 <moto-timo> again, I am willing to support that path
18:28:14 <bmbouter> 2.7+
18:28:16 <smooge> bmbouter, basically it is a forklift to a newer version of python and we might as well look at 3.x
18:28:42 <smooge> ok next questions since we are in python land.. when does 3.4 go EOL?
18:28:43 <bmbouter> this path is great for us, we are actually doing the same thing
18:30:52 <moto-timo> 2.7 EOL is 2020
18:31:04 <nirik> for epel7 we already have packages for django1.8/python34
18:31:20 <mrunge> we do?
18:31:37 <bmbouter> nirik is right I think
18:31:48 <bmbouter> we just looked at this in the project I work on
18:32:18 <nirik> we being fedora infrastructure.
18:32:26 <nirik> abompard has made them for our mailman3 setup
18:32:33 <mrunge> I know I built 1.8 on centos 7
18:32:39 <mrunge> I see
18:32:43 <moto-timo> if they follow the 10 year support path, 3.4 will EOL in 2024
18:33:07 <mrunge> when will el6 go out of support?
18:34:06 <nirik> @rhel6eol
18:34:37 <mrunge> roughly about the same as python2.7
18:35:09 <moto-timo> https://www.python.org/dev/peps/pep-0373/
18:35:45 <smooge> ok here is the part I am wondering.. if we do the python3x in both EL6 and EL7 route.. it makes it 'simpler' when 3.4 goes to 3.5 or some other nonsense
18:36:02 <moto-timo> yes please
18:36:10 <bmbouter> that would be good
18:37:33 <smooge> however I need info from people who have done this work eg orionp and moto-timo .. how hard does it look to get it shoehorned into EL6?
18:38:11 <smooge> no need for an answer at this moment. more of can you get an answer in 1-2 weeks?
18:38:32 <moto-timo> I'll investigate
18:38:34 <orionp> what exactly, going from 3.4 to 3.X ?
18:39:08 <moto-timo> specifically, getting django 1.8 in EL6 is what I am hearing
18:39:20 <moto-timo> using python34
18:39:30 <smooge> well my first question is: getting python34 fully into EL6
18:39:37 <smooge> how hard is that to complete?
18:39:43 <smooge> how much help do you need and where
18:39:50 <orionp> hopefully not too bad, but we are running into some issues
18:40:01 <orionp> many things just build fine
18:40:21 <moto-timo> many python-* packages need the new macros (they call out python3 specifically)
18:40:39 <moto-timo> but agreed with orionp
18:40:39 <nirik> this would also require anything using that version to switch to python34 I would think... dunno if there's any apps that would break
18:40:41 <orionp> but, for example, old el6 sphinx is causing issues
18:40:44 <smooge> 2nd is does it look like we will need to do 34 -> 35 ->36 firedrills yearly or just every now and then
18:41:04 <nirik> not yearly I don't think, but every once in a while...
18:41:15 <orionp> nirik: yeah, that's a concern as welll
18:45:10 <bmbouter> would this be scl based? as in python34 scl?
18:45:17 <nirik> no
18:45:37 <bmbouter> how will the 3.4 runtime coexist with the base python provided in EL6?
18:45:55 <nirik> it's parallel installable... like any other package
18:46:07 <bmbouter> that makes sense thanks
18:47:19 <smooge> ok I have another ping going on.
18:48:02 <nirik> so I think we need to look into things and revisit next week or something...
18:48:10 <moto-timo> agreed
18:49:20 <smooge> #agreed table this til next week
18:49:29 <smooge> #topic Open Floor
18:49:37 <smooge> anything else for this meeting? open floor itmes
18:50:04 <avij> RHEL 7.3 seems to be close to release, some bugs have changed to RELEASE_PENDING state
18:50:50 <avij> #info RHEL 7.3 seems to be close to release, some bugs have changed to RELEASE_PENDING state
18:51:07 <moto-timo> any hints about RHEL 8 timeline?
18:51:09 <smooge> and we are 5 months til EOL RHEL-5
18:51:16 <smooge> moto-timo, none that I know of.
18:51:43 <smooge> sorry
18:52:00 <moto-timo> np, thanks
18:53:35 <smooge> It used to be every 6 releases (6,12,18) but that was different release cadences so 24 wasn't it
18:54:12 <smooge> ok if we have nothing else.
18:54:25 <smooge> I am going to close out at the top of the minute
18:54:29 <smooge> thank you all for coming
18:54:35 <moto-timo> thanks
18:54:42 <avij> thanks
18:55:20 <smooge> #endmeeting