18:00:40 #startmeeting EPEL (2019-02-20) 18:00:40 #meetingname epel 18:00:40 Meeting started Wed Feb 20 18:00:40 2019 UTC. 18:00:40 This meeting is logged and archived in a public location. 18:00:40 The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:40 The meeting name has been set to 'epel_(2019-02-20)' 18:00:40 The meeting name has been set to 'epel' 18:00:40 #topic Chair and Introductions 18:00:40 #chair avij bstinson Evolution nirik smooge pgreco tdawson 18:00:40 Current chairs: Evolution avij bstinson nirik pgreco smooge tdawson 18:00:51 hi all 18:00:54 * pgreco present 18:00:56 morning 18:01:00 hello 18:01:10 Hi 18:01:19 hello all 18:01:21 Hey 18:01:32 #topic Agenda 18:01:32 #info EPEL-7 Proposal: Release_based_package_lifetimes 18:01:32 #info EPEL-7 Proposal: Minor_release_based_composes 18:01:32 #info EPEL-8 Tentative Proposal 18:01:32 #info Python36 Flag Day 18:01:55 Does anyone else have items for the agenda today? 18:02:03 or a reordering of items? 18:02:24 well, I kind of have one point that I'd like to add 18:03:02 smooge: I was going to follow up on the expat21 issue, but that's a minor question for the end, if there's time. 18:03:03 but maybe we can discuss these actual agenda items first 18:03:38 ok so #topic EPEL-7 Proposal: Release_based_package_lifetimes 18:03:38 #info https://fedoraproject.org/wiki/EPEL/Changes/Release_based_package_lifetimes 18:03:47 #topic EPEL-7 Proposal: Release_based_package_lifetimes 18:03:49 #info https://fedoraproject.org/wiki/EPEL/Changes/Release_based_package_lifetimes 18:04:07 there.. order maerstt 18:04:34 I put this out last week and got a lot of +1's on the list so wanted to know if we were ready for a vote on it? 18:04:53 or if more information is needed for that to happen? 18:06:28 I don't find anything bad with it so far, and it would help users to downgrade, 18:06:31 * nirik meant to read it carefully, but I have been swamped 18:06:42 do we need to delay a week then? 18:06:48 I'm pretty sure we'll need to tweak a few things, but +1 18:06:52 it does mean releng work, but I like the idea of it for sure. 18:06:58 For this one, I am clear on it ... but I understand if we delay it for a week. 18:07:26 ok let us delay this a week and then the questions on what the releng work is and who and how it is done can be dealt with 18:07:45 the proposal does seem ok to me 18:07:46 switching people might need some thought too 18:07:55 i'll be ready with a vote next week 18:08:02 but it seems ok by me 18:08:09 howdy everyone 18:08:11 ie, we may need to get iit all in place and get mirrormanager all updated, then push new epel-release to the old setup, etc 18:09:21 #idea We table this til next week 18:09:22 I think we are getting things mixed up ... isn't this one, the "Release_based_package_lifetimes" really just a policy change... it's the other proposal that is going to need alot of IT work. 18:09:47 oh right, I am talking about the other one 18:10:07 Although this proposal, the lifetime proposal, does depend on the other one 18:10:08 I wondered why you'd need a new epel-release .. 18:10:23 yeah. 18:10:47 do we want to vote on this one then and do the next one next week or both next week? 18:11:44 should we add a step to send to epel-announce? or have some report that goes there? 18:11:57 (for people who just want announcements, not epel-devel traffic) 18:12:11 I'd say both next week. The lifetime proposal depends on the release based lifetimes 18:12:13 otherwise it seems fine to me. 18:12:40 ok table this til next week. 18:13:19 #agreed Table Release Based Lifetimes til next week 18:13:22 #topic EPEL-7 Proposal: Minor_release_based_composes 18:13:22 #info https://fedoraproject.org/wiki/EPEL/Changes/Minor_release_based_composes 18:13:50 This one does take a lot of releng work to get done so it would be good if people can fill out the parts or tell me where i need to research them for you 18:15:02 yeah, I can try and add more detailed tasks... 18:15:07 the topic of packages appearing in el-"core" and disappearing from el-"core" that are still needed is a topic for me, so minor releases for epel would be supported from where i'm sitting 18:15:33 also, this isn't going to get any less volatile with modules -- is my thinking 18:16:40 #action nirik will try to add items to this 18:17:07 #action everyone will review and comment on the list for changes. [Or make them to the document. it is a wiki] 18:17:15 one important point for this is compatibility 18:17:19 in epel-release 18:17:27 can you explain? 18:17:54 I mean, what should we have in the old dir? 18:18:20 maybe moving all content to the new format, and leaving just epel-release there 18:18:20 old dir? 18:18:34 separating os/ and updates/ 18:18:42 we can possibly/hopefully just repurpose the existing dir to updates... 18:18:51 now we have everything together 18:19:01 pgreco, actually we don't 18:19:06 * kanarip has to go, ttyl 18:19:06 we just have the latest 18:19:14 nirik, I was thinking os instead of updates 18:19:15 so it is always the latest stuff 18:19:34 smooge, I know, what I mean is, if I don't update epel-release 18:19:54 right, we can't make people update 18:20:13 where am I pointing at? os/, updates/ ? or just an empty dir with the new epel-release 18:20:21 nirik, actually we have already 18:21:18 hum? 18:21:25 There's a similar case for those installing epel-release from centos base, but that's one of the details to flesh out I'm sure. 18:21:27 when we changed the directory layout previously with Packages etc and we changed some other items which caused people to do an explicite update of epel-release before they could get stuff 18:22:04 tmz, right, in centos/extras there is epel-release, and doesn't matter which version 18:22:10 because it will be updated 18:22:24 I think we can make the new setup, and get mm to point the old repos to the new updates one (so they get updated epel-release and then get the base repo) 18:22:52 I will put in a transition plan 18:24:52 nirik, do you want to point it to updates and not to base? 18:25:07 #action smooge will outline possible transition plan so that we have an order operations 18:25:10 yes, because base is only initially needed to downgrade 18:25:25 at first they will have the same content... 18:25:48 nirik, yes, but in that case, we'll have to always keep epel-release in base and in updates 18:25:59 because if a user "skips" one version 18:26:00 it will be 18:26:04 unless we retire it. 18:26:23 he'll loose the ability to get both dirs 18:26:42 and also what tmz said, but it could be fix updating the one in centos/extras 18:27:16 well, I guess it depends... I was thinking we would start with the repo we have... I don't know that it's going to be possible to make a base repo with the epel packages as of 7.6 release. 18:27:40 I was going with we make a repo on flag day 18:27:40 so, both epel-releases in base and updates will start the same and can be the one with the 2 repos 18:27:57 versus just what we had when 7.6 happened 18:28:24 if we always have an updated epel-release in updates, it doesn't matter where we point to 18:28:25 yeah. 18:29:04 sorry I will add that problem somewhere because that was what I was seeing but it clearly isn't obvious 18:29:26 we also know a little bit about CentOS Extras :) keeping that in sync will be pretty easy 18:30:06 ok are there any other items I should add before Sunday so people have time to read/digest by next Wednesday? 18:31:04 if not I will move to the next item 18:31:09 #topic EPEL-8 Tentative Proposal: 18:31:09 #info https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 18:31:41 This is more of a steering committee announcement of the page.. I will further publish to the list and a further blog by tomorrow. 18:32:21 yeah, will be good to have a roadmap out there... 18:32:32 We need a lot of feedback on this to try and make this happen.. parts of this are currently reliant on the proposals we have 18:33:12 smooge, it is strange to read "Fiscal Year" in a technical proposal ;) 18:33:52 yeah.. this falls under work that Fedora Infrastructure has to do and aligns with that orgs year 18:34:58 the work that releng needs to do to make EPEL-7 releases would also fall under this and they are mostly aligned to try and make less special cases in code 18:35:42 015637 18:35:42 I like Assumptions 3.1 ... I was wondering about that question specifically. I like what you have written. 18:36:44 ok does anyone have anything they want to bring up on it right now.. or should I move on? 18:38:18 I see you have arm32 listed as an arch 18:38:43 RHEL8 won't have a release for that ... was that going to be coming from CentOS? 18:39:07 tdawson: I think that was under 'hard to do, so we will not do it to start with' ? 18:39:27 Ah ... yes it is ... understood. 18:39:51 tdawson, most of that should fall on me 18:40:01 I mean the centos/arm32 18:40:06 pgreco: OK 18:40:24 there also needs to be a change proposal for us to write on how we are going ot do alternative architectures 18:41:03 and yeah as nirik says.. not to start with until the first ones are done 18:41:35 ok I iwll move on 18:41:36 #topic Python36 Flag Day 18:41:37 #info How does 2019-03-06 sound? 18:41:43 ugh I mistyped 18:41:48 #undo 18:41:48 Removing item from minutes: INFO by smooge at 18:41:37 : How does 2019-03-06 sound? 18:41:57 #info How does 2019-03-07 sound still? 18:42:01 smooge: Just so you know, with item 5 on task-breakdown. The initial list of CRB packages was gotten by rebuilding all of EPEL7 on RHEL8 and seeing what packages were missing. So the list of missing packages should be small 3 18:42:55 understood. the issue will come as more stuff gets put in there than is in currently EPEL-7 18:43:00 do note that for epel7 we did not mass branch anything, we asked people to branch what they wanted to maintain... 18:43:05 2019-03-07 sounds good to me. 18:43:42 sounds good. +1 18:43:47 sure, +1 18:43:47 True, and with the KDE build, I've found about 10 more packages that needed to go into CRB. I submitted them ... but at this point, who knows if they will make it in. 18:44:34 +1 from me for 2019-03-07 18:45:42 +1 from me also 18:45:56 +1 18:46:00 Evolution is probably in meetings 18:46:40 #agreed Python36 flag day is 2019-03-07. A formal plan of what to be done will be written, passed by python group and provenpackagers will stand by to fix things 18:47:14 damn it my #propose didn't get sent 18:47:34 Control-A in hexchat strikes again iguess 18:47:54 do you guys need me to resend? since that isn't what you voted on? 18:48:36 the above 'agreed' is fine for me 18:48:47 I'm fine with the agreed 18:49:02 ok thanks. I apologize for that 18:49:07 #topic Open Floor 18:49:13 ok, so, I've recently started at a new $dayjob and it seems to be taking quite a lot of my time, in addition to my studies which I'm also trying to finish. I'm struggling to keep up with the EPEL things, so I'd like to step down from my EPSCO position and nominate someone like pgreco to take my seat. he has proven to know his stuff, esp. regarding altarch things. 18:49:23 avij I think you have it first and then tmz 18:49:54 understood. I wanted to thank you very much for your work on this. 18:50:21 I had kind of added pgreco to the committee by fiat a couple of weeks ago since he has done a LOT of things 18:50:34 I'd still hang around on #epel and provide assistance there like before, but I'd like to let someone else participate in making the decisions. 18:51:10 +1 to thank avij for his work and help in making this better. +1 to pgreco to taking his place on the committee 18:51:17 if we can add (like smooge did) instead of replace, I'd like that 18:51:51 avij, I would consider you emeritus like dgilmore 18:52:04 +1 on emeritus ;) 18:53:15 thanks for your comments. feel free to decide as you see fit, but nevertheless, I'd prefer to step down from my official role. 18:53:30 bstinson, nirik, anything on this? 18:53:56 not off hand. 18:54:02 many thanks avij! 18:54:11 ok for pgreco to take the spot? 18:54:14 agreed, thanks avij 18:54:23 +1 on my side for pgreco as well 18:55:38 sure, if they are willing. ;) +1 18:56:01 ok thanks pgreco report to duty 18:56:14 thanks 18:56:21 tmz, you had something to report? 18:56:36 avij, thanks! 18:56:43 pgreco: thanks to you! 18:57:09 smooge: Not much to report. Just wanted to see what we should do about expat21 in epel-6, particularly. 18:57:44 well, didn't the maintainer say he was going to adjust it? 18:58:00 I cc:d besser82 on the epel-devel thread a week or so ago, but didn't hear back. (I suspect he was busy doing f30 rebuilds) 18:58:11 I thought I saw a reply on irc from him 18:58:34 nirik: That was the idea, though it was to say something like "give me a day or two to look at the existing CVE's" 18:58:42 Feb 03 09:33:11 smooge, I've seen your mail about expat21 on el6. Please give me a day or two to fix the CVEs and the provides. I'll push an updated package then. 18:58:44 I will ping besser82 on it and see if I can help any with it. We can try and get it resolved by next week? 18:59:36 Fixing the extra requires is simple, of course. But if the package has unfixed CVE's and no one to backport them, it might be time to kill it. 18:59:53 Though the interesting part of this is why that package is in the internal koji repo. 19:00:31 that I am not sure why koji is pulling it in when it should have been doing that for a long time 19:00:31 internal == epel? 19:00:47 ie, internal == koji 19:00:48 That seems recent. Either that or something in koji started using the yum-builddep from dnf to pull in the build deps. 19:00:55 nirik, yeah.. the problem is that tmz's builds started pulling it in when it didn't before 19:01:08 oh, I have a thought... let me check something. 19:01:22 yum-builddep from yum-utils works. yum-builddep from dnf-utils pulls in expart21-devel. 19:02:28 yeah, thats my thought... the new mock switched and we didn't switch it back. 19:02:41 it's going to take me a few minutes to sort this, so perhaps we should do it out of meeting. 19:02:56 in this case tho pulling that is actually right? 19:03:21 nirik: Sure, this is definitely a low priority. 19:03:45 ok 19:04:20 And yeah, the dnf yum-builddep is doing the right thing. That's a fix that exposed the bug. One step forward... and all that. ;) 19:04:59 ok lets take this out of meeting 19:05:13 thank you all for coming this week 19:05:22 will look forward to input etc for next week 19:05:26 #endmeeting