18:04:02 <smooge> #startmeeting EPEL (2019-03-13)
18:04:02 <zodbot> Meeting started Wed Mar 13 18:04:02 2019 UTC.
18:04:02 <zodbot> This meeting is logged and archived in a public location.
18:04:02 <zodbot> The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:04:02 <zodbot> The meeting name has been set to 'epel_(2019-03-13)'
18:04:02 <smooge> #meetingname epel
18:04:02 <zodbot> The meeting name has been set to 'epel'
18:04:02 <smooge> #topic Chair and Introductions
18:04:02 <smooge> #chair bstinson Evolution nirik smooge pgreco tdawson
18:04:02 <zodbot> Current chairs: Evolution bstinson nirik pgreco smooge tdawson
18:04:10 * nirik waves
18:04:16 <pgreco> hello
18:04:24 <tdawson> Hi
18:04:31 <smooge> hello
18:04:47 <carlwgeorge> howdy
18:06:22 <smooge> #topic No Agenda and No Quorum
18:06:39 <smooge> So I didn't send out an agenda so we will just go over a short meeting list.
18:06:50 <smooge> I think bstinson is out at a show and so is Evolution
18:07:06 <smooge> so I think we will keep this to a short meeting
18:07:21 <smooge> #topic EPEL-7 Python34 -> Python36
18:07:40 <smooge> #info tdawson carlwgeorge kanarip did a LOT of work this weekend to get the initial stuff done
18:07:47 <pgreco> all I have in mind today is thanks the guys how have been working on this
18:07:49 <smooge> #info we need to test a lot of things and fix them
18:08:04 <pgreco> they did a looooooooooot of work
18:09:02 <smooge> thank you all for the work
18:09:13 <smooge> any questions/comments on things?
18:09:17 <tdawson> You are very welcome
18:09:18 <carlwgeorge> how does everyone feel about having python36 conflict with python34 < 3.4.9-3
18:09:37 <tdawson> Just know that I will be gone from March 20 until around April 1 or 2.
18:09:39 <pgreco> carlwgeorge, and maybe the opposite too
18:10:03 <pgreco> python34 conflict with python36 < $oldversion
18:10:16 <carlwgeorge> adding a conflict to python34 doesn't make sense because it's already removed /usr/bin/python3
18:10:31 <kanarip> tdawson, you want me to just fix epel7/python-sphinx-autobuild and then look at master and beat that in to shape?
18:10:34 <smooge> I think that needs to be answered by mhronok (sp) and the python group. I don't know if it will impact future RHEL issues
18:10:58 <tdawson> kanarip: By *fix*, do you mean disable the 34/36 stuff?
18:11:00 <smooge> sorry for the mispelling. I am used to tab completion which isn't working
18:11:23 <kanarip> tdawson, work on it and throw a pull request in
18:11:34 <tdawson> kanarip: Sounds good
18:12:10 <nirik> I think we should have the conflict...
18:12:17 <nirik> but I'd be happier for a better solution.
18:12:27 <carlwgeorge> fyi in case anyone missed it, i changed that bug report for python36 to rlwrap https://bugzilla.redhat.com/show_bug.cgi?id=1687196
18:13:09 <carlwgeorge> there are a handful of other epel packages that require /usr/bin/python3 that will probably need a similar fix
18:14:00 <nirik> I am not sure thats the right answer.
18:14:02 <kanarip> carlwgeorge, i queried the lot and all of them got rebuilt
18:14:28 <nirik> sorry, I am getting all muddled. I meant I thought we should have the obsoletes... not the conflict.
18:14:28 <kanarip> *except* for the one package Mr bleve got from epel-testing that was never in epel-stable
18:15:07 <smooge> ok what are the top things we need to do?
18:15:12 <nirik> the problem is that yum doesn't have enough information to do the right thing when both an installed python34 and a proposed python36 both have /usr/bin/python3
18:15:47 <kanarip> i think we only needed to rebuild the packages that depend on /usr/bin/python3 with the new python34 and python36 in the build tag
18:15:50 <kanarip> which i think we have
18:16:33 <nirik> that doesn't solve it I don't think... unless it also changes the requires in those to python36 instead of python3
18:16:41 <kanarip> shebangs would be fixed not from /bin/python to /bin/python3 but from /bin/python to /bin/python36 or whatever
18:16:52 <carlwgeorge> nirik: would the conflict not be enough?  the issue that was seen was that the missing provide wasn't detected until after the transaction started, which a conflict would address.
18:17:35 <nirik> conflicts are to be avoided, they cause the user to have downloaded stuff and have to manually figure out what they want to do differently.
18:18:09 <nirik> kanarip: what do you expect does that?
18:18:30 <carlwgeorge> yes, but we have the file conflict no matter what.  the rpm tag conflict should reflect the reality.
18:18:40 <kanarip> nirik, a part of rpmbuild
18:18:52 <kanarip> mangle-shebangs iirc?
18:19:07 <nirik> kanarip: I don't think there is any such thing active in epel7... I could be wrong, but I think thats fedora only.
18:19:27 <carlwgeorge> nirik: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts
18:19:44 <nirik> well, it doesn't.
18:19:59 <nirik> or I guess it does, but has already been fixed? as the new python34 does not have that file
18:20:15 <carlwgeorge> correct, we're just talking about conflicting with the previous version
18:20:22 <nirik> what exactly do you want to add conflicts to with what value?
18:21:00 <carlwgeorge> python36 should have `Conflicts: python34 < 3.4.9-3`
18:21:01 <nirik> oh I see... Conflicts: old python34 to the python36 package?
18:21:22 <nirik> ok, that makes sense.
18:21:34 <carlwgeorge> not dissimilar from the conflict usage for splitting packages
18:21:56 <nirik> if we do that tho,, does yum exit with an error? or just pull in the 34 update?
18:22:56 <carlwgeorge> i actually haven't tested it yet, but it will either 1) exit with a conflict error while solving the transaction or 2) realize it needs to update python34 to the latest in the same transaction.
18:23:18 <carlwgeorge> both of which are better than the current error after the user presses y
18:23:19 <nirik> right, if it does 1) the user experence is horrible
18:23:29 <nirik> sure, but not great still.
18:23:46 <carlwgeorge> i know nextgen-yum4 (dnf) from extras will do 2
18:24:29 <carlwgeorge> i'll test this and see what actually happens
18:24:45 <smooge> ok put that in the thread as testing scenarios you tried and gotchas.
18:24:47 <nirik> that would be helpfull. Perhaps then that bug should move to python36 if thats where the fix is.
18:25:02 <kanarip> nirik, you're right, it doesn't in epel7, rlwrap will need to be fixed anyway
18:25:29 <carlwgeorge> yeah that bug should stay with rlwrap, i can pop a new one for this conflicts discussion
18:25:32 <nirik> well, I am not sure we need/should change those
18:25:52 <carlwgeorge> rlwrap's python dep is most likely bogus
18:25:53 <nirik> I mean, it should work with either python34 or python36 right/
18:26:11 <nirik> so, why not let someone keep python34 if they need to for some other reason?
18:27:59 <nirik> I guess it could/should be just up to the maintainer, since 'python3' doesn't tell us enough. ;)
18:28:38 <kanarip> carlwgeorge, i'm looking in to it
18:28:43 <kanarip> *rlwrap that is
18:28:57 <carlwgeorge> cool
18:29:31 <carlwgeorge> is there an overall wiki page for the py34->py36 switch i can use in a spec file comment?
18:29:52 <smooge> carlwgeorge, I don't think so.
18:30:06 <smooge> or was there
18:30:38 <nirik> not that I know of.
18:30:46 <carlwgeorge> no worries, i'll just link to https://src.fedoraproject.org/rpms/python-rpm-macros/c/99f8b82d04ce08c351bdde3a758de46e9f18a86c?branch=epel7
18:30:54 <smooge> <- oops
18:31:00 <nirik> or the discussion on the epel-devel list
18:32:08 <smooge> ok anything else on this?
18:33:03 <smooge> #topic Open Floor
18:33:15 <smooge> ok anyone have anything for the open floor
18:33:54 <kanarip> in my exercise to rebuild everything epel8 recursively, i find errors in rhel 8 ;-)
18:34:49 <smooge> noooo
18:35:24 <kanarip> moreover, i find there's quite a few python2 dependencies
18:35:42 <kanarip> which i understand we'd rather avoid or resolve at some point, right?
18:35:47 <nirik> well, python2 is available as a module
18:35:54 <nirik> ((at least I thought)
18:36:02 <kanarip> yeah, but everything rhel is built without python2 ;-)
18:36:09 <smooge> it is a module. most of the rpms are not
18:36:30 <kanarip> i'll have a list, patches, pull requests
18:36:31 <nirik> right, goes back to the ursa-major/whatever replaces it/etc thing
18:36:51 <smooge> and as Fedora 30/31 is finding out there are a TON of packages which require python2-sphinx or /usr/bin/python
18:37:13 <nirik> kanarip: so you are switching them to python3? but thats a module too?
18:37:17 <kanarip> aside from that, fedpkg's huge recursive dependency chain includes python2-only packages
18:37:39 <nirik> yeah, possibly via koji.
18:37:47 <kanarip> and bodhi iirc
18:37:55 <kanarip> and some more obscure one-offs here and there
18:38:02 <nirik> smooge: python2-sphinx got dropped from rawhide now.
18:38:38 <nirik> huh, bodhi is now python3... oh, perhaps not in epel7 tho.
18:38:47 <smooge> nirik, yeah.. and I expect that you will find that about 400 packages won't FBTFS
18:38:53 <kanarip> epel7 is not relevant ;-)
18:39:19 <smooge> so next mass-rebuild will be fun
18:39:40 <smooge> and putting in python3-sphinx doesn't seem to work for some sets of docs
18:39:55 <kanarip> i have python2-sphinx
18:39:58 <tdawson> bcond docs
18:39:58 <smooge> so again.. next summer rebuild
18:40:19 <kanarip> it's the recursive build deps that will get you ;-)
18:40:24 <tdawson> :)  ... the easy solution
18:40:37 <smooge> so for my mock I am doing the equivalent of config_opts['module_enable'] = [ '*' ] which works for a local mockchain but not for koji
18:40:53 <nirik> it's not that bad
18:41:14 <kanarip> i find it doesn't actually need that
18:41:42 <nirik> koji uses it's own mock config
18:41:46 <smooge> yeah I know
18:42:12 <nirik> looks like it was 102 packages... but a lot have been fixed. I fixed N of mine on sunday.
18:43:56 <kanarip> in either case... either everything will have to be pushed forward hard -- including code changes, or ...
18:44:16 <kanarip> python2 is a part of epel8 for the sake of the packages that matter
18:44:47 <nirik> well, one issue is that we don't know what will be in epel8 yet. Until maintainers decide they wish to support it...
18:45:26 <kanarip> not even CRB appears to be able to help us greatly
18:46:27 <kanarip> it's all python3 only by default, few exceptions, some are not build conditioned, most do not have the equivalent build condition for 'without python3' so we could end up with only the supplemental binary blob python2 rpm of something
18:47:00 <smooge> so for EPEL-8 attempt, I have 40 packages which required python2-sphinx and 18 which required python-sphinx and a lot of packages which use /usr/bin/python but don't require it so break during the build
18:47:16 <smooge> I was confusing the other problem with the first one
18:47:32 <smooge> so anyway.. I think we can close this out this week
18:47:38 <smooge> thank you all for coming
18:47:44 <nirik> on all these attempts what are you using for packages? the set of ones that are currently in epel7? or ?
18:47:46 <smooge> I hope you have a good weekend and get some rest
18:48:08 <kanarip> nirik, i list-pkgs the epel7 koji tag fwiw
18:48:33 <smooge> nirik, I am using the F28 packages as sidedeps because they are python36 versus python37/38 and I am using fedora30 src.rpms
18:49:08 <nirik> ok. but do note as I said, maintainers may well not want to maintain all the same packages in 8...
18:49:20 <nirik> but good data
18:49:30 <smooge> these are only packages which are in EPEL-7
18:49:51 <smooge> but the size of the deps grew a bit
18:49:57 <kanarip> ;-)
18:50:28 <smooge> so I had to keep expanding until I had them closed. I am at ~11000 f30 packages to equal epel-7
18:51:04 <smooge> I will have more stats next meeting
18:51:42 <smooge> as I finally got all the requires I could to rebuild so I can start on the 11000 f30 packages
18:52:14 <kanarip> how are you dealing with the multitude of packages that only 0?fedora do with python3?
18:52:24 <smooge> I am not doing anything
18:52:29 <kanarip> ohw, aha
18:52:37 <smooge> this is just a proof of concept
18:53:00 <smooge> when stuff actually gets branched etc.. those would need to be fixed
18:53:13 <smooge> but this will give an idea of what can be built without any intervention
18:53:58 <kanarip> i'm doing some actual building... so that graphs out source branches, pull requests and build order
18:54:17 <smooge> yeah.. I don't have that infrastructure set up
18:54:50 <smooge> ok I am going to close this out and go deal with my forest fire list. Thank you all for coming
18:54:58 <smooge> #endmeeting