18:01:17 #startmeeting EPEL 18:01:17 Meeting started Wed Aug 17 18:01:17 2016 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:17 The meeting name has been set to 'epel' 18:01:22 #meetingname EPEL 18:01:22 The meeting name has been set to 'epel' 18:02:27 #chair smooge nirik Evolution avij bstinson 18:02:27 Current chairs: Evolution avij bstinson nirik smooge 18:03:10 I am not sure we have any form of quorum today and Fedocal has decided meeting is later 18:03:15 \o/ 18:03:18 greetings 18:03:44 And I honestly thought today was Tuesday and was going to send out the mail for the meeting this evening 18:04:25 #topic EPEL outstanding issues 18:04:55 OK we have quorum. And I see builds for i386 and aarch64 in the CentOS build system 18:05:15 the aarch64 ones look to be a long list of "not on this arch" type things :/ 18:05:34 the i386 ones are getting to that point 18:06:16 still building all those 18:06:39 the nodejs and some others 18:07:11 Anything else on the list? 18:08:31 bstinson, Evolution any other news in CentOS land? 18:09:03 and I see we are competing with a CentOS meeting right now. 18:09:08 mostly waiting for the go-ahead on aarch64. 18:09:36 once epel has that in place we can stop our epel builds and use actual-epel. 18:09:44 I'm hoping to work on some sort of proposal for how to collaborate on non-RHEL arches 18:09:48 ok will see with pbrobinson what is needed 18:09:57 it's on one of my lists from FLOCK 18:10:01 afaik it's a firmware patch from HP 18:10:07 yeah.. 18:10:13 any day now 18:10:17 ... 18:10:20 heh 18:10:37 what aarch64 ? we have this lovely itanium which emulates it. you want that? 18:11:22 ok I still have a backlog of packages to make also for EL7 18:11:48 #EPEL New Business 18:11:56 Does anyone have any open/new business? 18:12:23 smooge: at one point you and bstinson were talking about amending/rewriting the epel charter 18:12:24 I saw that mock builds are 'broke' for people due to EPEL configs pointing to centos keys 18:12:49 hmm? bz/url? 18:13:10 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IBOEOVPWNEDXEJI3ZIF26LAAVAFS253G/ 18:13:22 Evolution, the EPEL charter stuff needs to be dealt with. 18:14:09 I am declaring round tuit bankruptcy and hoping that a refinance will give me time to start on it this weekend. 18:14:30 Evolution, the link was for the mock borkness. it should be fixed soon 18:14:33 ah, that didn't go to epel-devel. that's why I missed it 18:14:35 got it. 18:14:41 yeah. 18:16:58 yeah I got it because someone found it some other way this morning 18:17:36 bstinson, Evolution while i have a blank paper for Charter here.. is there anything you think should be in the first draft? 18:18:08 smooge: well, I did notice spot's request for devtools scl bits. 18:18:30 how are those available in CentOS? 18:18:41 because the mock would need to have them also 18:18:42 as a sig. additional repo for someone to enable. 18:18:55 so reasonably similar to rhel in that regard. 18:19:39 and at the risk of sysadmin related heresy.. but with an eye to the future, we might consider containers in some form 18:19:49 smooge: bstinson: Evolution: I think we're looking OK for aarch64 once we have moonshot in prod 18:20:14 smooge: bstinson: Evolution: from the non RHEL arches 18:20:40 pbrobinson, cool 18:20:44 pbrobinson: I'm assuming that's the generic "two weeks" placeholder timeframe until further notice? 18:20:48 I think it would be useful to take it to the list, I have some ideas but I suspect I'm treading on a meeting :) 18:21:07 but if there's time I can do some brief brain dump here 18:21:23 brain dump on EPEL or Architectures :)? 18:21:26 Evolution: :-D 18:21:46 on support for non RHEL in EPEL (ie i686/armv7hl 18:21:52 ) 18:22:01 pbrobinson, ah ok 18:22:11 pbrobinson, we have 20 minutes so dump 18:22:24 I'm on smooge's schedule. lets do it 18:22:48 so the major issue is we get all RHEL arches at the same time. RHEL-7 is moving quick 18:23:16 the ppc644le bootstrap was terrible because I had to fix a crap ton of issues where RHEL bumped stuff 18:23:39 so I had to do huge amount of fixes to deal with that even to just build on x86_64 18:24:01 so chatting with bstinson at flock about the problem 18:24:26 the major issue is that do we hold and have broken primary support arches until the others catch up 18:24:59 or do we push and have an issue where koji pulls in external deps and have some arches build with one soname and others with the old one 18:25:31 so bstinson mentioned maybe we should basically branch with each el7 release and do 7.x branches 18:26:12 which kind of makes sense as we'll have a bunch of el7 x86_64 customers that want to stick on a .x long term branch too 18:26:30 can you convince a maintainer to build to .x branch? 18:26:31 sadly I think it's a process that's going to add a bunch of work 18:26:44 well maybe you don't need to 18:26:57 if they don't it sticks on the last known good 18:27:09 that doesn't deal with CVEs etc 18:27:20 but it also doesn't actively break shit 18:27:39 those that want it can do so, those that don't have branches stuck at a point in time 18:27:59 it also doesn't 100% deal with the non RHEL arches 18:28:27 but nor does the current situation 18:28:34 there's a fair bit of matrixing and engineering for that. 18:28:40 yep 18:28:57 the only thing that gets us is a well-known point for 'breaking' things 18:29:16 that's a valuable thing. I'm not discounting the idea 18:29:19 but I think we're going to need to do something like that because of the way el7 is changing compared to old releases 18:29:22 which would be handy in the case of arch work 18:29:29 I'm trying to sort out mentally if it's worth the pain it incurs 18:29:46 I'm not convinced it's the solution 18:30:19 does it feel like it gets us closer to a solution (even if we don't know what it is)? 18:30:31 but after the pain of 7.2 and ppc64le bootstrap I know it's something we're going to need to address at some point 18:30:31 the other option is to have a 'breakage window' around RHEL releases, and start doing mass rebuilds 18:30:49 but that again doesn't solve the non-RHEL arch problem directly 18:30:51 well that was my take on it 18:31:24 basically I know I'm doing aarch64 before 7.3 lands because I know epel isn't too broken given the work I did for ppc64le so it will be less painful for me 18:31:43 I estimated 2-3 days work, it ended up being like 10 days of 12 hours 18:32:27 pbrobinson, looking at the builds the main aarch64 stuff looks currently like nodejs and similar all the world is x86_64 isn't it? 18:32:45 s/stuff/bad stuff/ 18:33:18 some of that is just needlessly exclusive-arch'd 18:33:42 so I am trying to see how this branch issue is different from 'breakage window' around RHEL releases 18:34:24 since the amount of things changing in 7.x looks to be bigish until 7.<2nd stage of support starts> 18:34:26 smooge: yes, but I know sgallagh has plans for nodejs 4 for EPEL and that will add both ppc64le and aarch64 and people will be happy 18:34:43 ah ok 18:34:50 well as long as people are happy 18:35:04 the 'breakage window' gives room for packagers to update their packages, and for us to schedule a mass rebuild. which feeds into the arch discussion because we don't have CentOS versions for non-RHEL arches for a certain period of time 18:35:08 and there's an issue with haskell but the maintainer also has a plan to fix that (time @ flock was awesome!) 18:35:13 pbrobinson: We're actually considering Node.js 6 for EPEL, but we're going to hold off a couple months until it enters LTE phase. 18:35:42 sgallagh: awesome! so basically I meant nodejs 4+ ;-) 18:35:45 But the rest of that (arch support) is accurate 18:36:19 There is a 3rd option. We just have regular breakage windows in EPEL. 18:36:45 not linked to RHEL releases but just its been 9 months and the CHaos monkey has awoken 18:37:10 smooge: big problem there is enterprise users 18:37:29 the issues with non EL arches is hard to articulate on irc 18:37:34 pbrobinson, bstinson if you guys could write up the hypothesis plan to the mailin glist 18:37:42 happy to have a voice chat with those interested 18:38:00 mailing list discussion is probably better 18:38:03 * pbrobinson throws that to bstinson as I did at flock :-P 18:38:20 pbrobinson, when the enterprise customers start paying for both stability and we want the latest (since they are also the ones asking that)... I will be happy to try and keep them happy :) 18:38:22 yeah, i promised a write-up :P 18:38:27 which is what I asked bstinson to do :) 18:38:48 bstinson, I will find wet fish and mail them to you to slap yourself to remind you 18:38:52 smooge: what is the point of doing it if not for the enterprise customers? 18:38:54 he owes so many writeups.... 18:39:01 * Evolution taps foot in bstinson's general direction 18:39:05 smooge++ 18:39:05 pbrobinson: Karma for smooge changed to 8 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:39:26 pbrobinson, the point is that the Enterprise customers want both never changing and always changing 18:39:36 from a volunteer group. 18:40:04 and they rarely show up except when they didn't get one of the two things above. 18:40:22 of course! all the stability none of the contribution 18:40:53 so if we tell them that every 12 months we are looking to change things (they may not change because alpine is just as good as it was before.. but they may change a lot because nethack is now written in JS) 18:41:14 it gives them a window to say "no we really want the C version of nethack." 18:41:49 a window that's tied to a schedule that they already know (point release time) 18:42:06 well the problem is that no one knows what the point release time is 18:42:09 no one 18:42:30 TBH not even internally via the PM :-D 18:42:44 * pbrobinson will burn in hell at some point!! 18:43:11 so we can tie it to the point release or to a set date. 18:43:26 each has its bonus and each has its problems. 18:43:50 I will write up the breakage and set date ones as proposals. 18:44:03 [although the breakage one might be already done.] 18:44:21 ok meeting time is coming to a close. 18:44:39 #topic open floor 18:44:44 does anyone have any other items? 18:44:57 I can close the meeting otherwise and give you all back 6 minutes 18:45:07 none here 18:45:34 none here either 18:45:36 none here 18:46:46 I love exits like: 18:46:49 var/tmp/rpm-tmp.IE05K8: line 30: fg: no job control 18:46:49 error: Bad exit status from /var/tmp/rpm-tmp.IE05K8 (%build) 18:46:49 Bad exit status from /var/tmp/rpm-tmp.IE05K8 (%build) 18:46:49 Child return code was: 1 18:46:50 EXCEPTION: Command failed. See logs for output. 18:47:05 the logs of course say nothing 18:47:15 ok with that enlightening tidbit 18:47:19 good night everyone 18:47:23 #endmeeting