18:00:01 <smooge> #startmeeting EPEL (2018-05-16)
18:00:01 <zodbot> Meeting started Wed May 16 18:00:01 2018 UTC.
18:00:01 <zodbot> This meeting is logged and archived in a public location.
18:00:01 <zodbot> The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <zodbot> The meeting name has been set to 'epel_(2018-05-16)'
18:00:01 <smooge> #meetingname EPEL
18:00:01 <smooge> #topic aloha
18:00:01 <smooge> #chair avij bstinson Evolution nirik smooge
18:00:01 <zodbot> The meeting name has been set to 'epel'
18:00:01 <zodbot> Current chairs: Evolution avij bstinson nirik smooge
18:00:01 <smooge> #topic agenda
18:00:39 <smooge> Hello everyone?
18:00:41 <avij> hello
18:01:06 <bstinson> hi all
18:02:11 <nirik> morning
18:02:23 <smooge> ok so here is what I have for today
18:02:38 <smooge> #topic agenda
18:02:38 <smooge> #info EPIC
18:02:38 <smooge> #info flock talks?
18:02:38 <smooge> #info smbios
18:02:39 <smooge> #info open floor
18:02:47 <smooge> any other items need to be added?
18:03:33 <smooge> ok I am going to swap things around
18:03:38 <Evolution> if I could type, I'd be here on time
18:03:43 <smooge> #topic smbios
18:03:48 <Evolution> feodra-meeting is someting entirely different
18:03:57 <avij> there's something about python2-s3transfer, but I think I'll have that discussion on the mailing list to get some more opinions
18:04:26 <smooge> so mostly we have the usual "hey its a new release and stuff is conflicting"
18:05:00 <smooge> the first one is that smbios from upstream doesn't work with upstreams products
18:05:10 <avij> this time it's "RHEL adopted some EPEL packages and broke things in the process" ..
18:05:22 <smooge> s/with upstreams/with another upstreams/
18:06:00 <avij> it's actually the same upstream
18:06:08 <avij> smbios is a Dell project
18:07:08 <nirik> is there a bug on this one?
18:07:34 <avij> #link https://bugzilla.redhat.com/show_bug.cgi?id=1570019
18:07:43 <smooge> thanks
18:08:25 <avij> #link https://access.redhat.com/solutions/3409271
18:08:57 <nirik> anoying thats closed as a duplicate.
18:09:07 <avij> indeed
18:09:45 <smooge> #link https://bugzilla.redhat.com/show_bug.cgi?id=1562440 ?
18:09:59 <avij> not visible to us mere mortals
18:10:20 <nirik> yeah, I can't see it either. ;)
18:10:54 <Evolution> same. even with rh account it's invisible.
18:11:11 <Evolution> your bug report is in another castle.
18:11:28 <smooge> oooh
18:11:33 <nirik> anyhow, the only action I could see here is that we bump the epel one so people could keep using it... but that might mess up any plans dell/rhel has
18:11:47 * carlwgeorge waves
18:12:41 <carlwgeorge> i was working with it quite a bit, it's a bigger problem than just the disabled c++ interface.  red hat added ~20 patches, and one of them causes one of the commands to segfault.
18:13:16 <avij> and EPEL's libsmbios might not be compatible with RHEL's fwupd. fwupd was the reason RHEL shipped libsmbios in the first place
18:13:16 <nirik> oops
18:13:58 <carlwgeorge> on the rackspace/red hat call, i suggested that rackspace rebuild the rhel srpm with the c++ interface and the bad patch disabled.  rh engineers specifically asked us to just rebuild the epel rpm at a higher release instead, because they haven't tested their patchset with the c++ interface.
18:14:12 <pjones> oy, this bug
18:14:26 <carlwgeorge> speak of the devil, hey pjones
18:15:05 <pjones> really, ideally the way through here is a) finish debugging what's going wrong in the RHEL package, and also b) rebuild the /epel/ rpm with just the c++ bits.
18:15:06 <nirik> I'd be happy for epel to do whatever helps out best, but not sure how to get that info
18:15:31 <pjones> but for various reasons debugging has been stalled
18:15:37 <carlwgeorge> the epel rpm already has the c++ bits, but the rhel package is a higher nvr
18:15:38 <nirik> pjones: you mean have rhel provide most of it, but epel provide c++ interface?
18:15:46 <pjones> I mean split the c and c++ bits
18:15:48 <nirik> that will need a package rename in epel.
18:15:52 <pjones> and make them different packages, yes
18:15:59 <Evolution> pjones: woun't that require keeping the two packages in tight alignment for versioning?
18:16:08 <carlwgeorge> nirik: no, because the rhel package also causes segfaults with the c interface in one of the commands
18:16:10 <pjones> Evolution: no, the two APIs are basically unrealted
18:16:11 <avij> the KB article does not really provide much details of what Dell/RH are planning to do. at most it suggests that a future release of OMSA will fix this.
18:16:13 <pjones> unrelated
18:16:39 <nirik> carlwgeorge: well, that's a short term bug hopefully fixed by a rhel update?
18:16:53 <pjones> yeah, that just means I have to figure out why and fix it
18:17:24 <carlwgeorge> right, but until that's fixed, the easiest fix is to rebuild the epel rpm with a higher nvr than the rhel one.  that is the fix rh asked rackspace to do locally, might as well do it for the world.
18:17:26 <nirik> do things use the c++ interface? I guess yes?
18:17:31 <carlwgeorge> omsa does
18:17:50 <carlwgeorge> and it rpm requires it, so updates from 7.4+omsa to 7.5 fail
18:17:54 <pjones> right, but let's try to discuss the outcome we want, not the intermediate workarounds we could use
18:18:09 <Evolution> pjones: who maintains the package internally? is that you?
18:18:12 <pjones> Evolution: yes
18:18:27 <pjones> and I can say for sure we're not going to carry the C++ impl in rhel.
18:18:34 <Evolution> pjones: if we bump epel as a stop-gap, can we ensure that the future rhel (corrected) package will surpass the epel NVR?
18:18:47 <pjones> sure.
18:18:50 <carlwgeorge> the outcome i want is for rh to ship smbios that meets all the requirements of omsa, and doesn't cause commands to segfault.
18:18:55 <Evolution> okay. so I see two things to be done here.
18:19:03 <Evolution> as an intermediate, we bump epel as carlwgeorge suggests
18:19:22 <Evolution> then we work to create a separate package for just the c++ bits for once RHEL releases a corrected one
18:19:29 <pjones> ... before.
18:19:29 * nirik nods
18:19:37 <pjones> before RHEL releases a corrected one
18:19:48 <Evolution> right
18:19:49 <Evolution> yes.
18:19:49 <carlwgeorge> yup
18:20:04 <nirik> it's going to have to be a new package... libsmbios would need to be retired when the fixed one comes out
18:20:29 <Evolution> right. with a requires for libsmbios from base/updates from rhel/whatever
18:20:42 <smooge> libsmbios-cpp
18:20:51 <Evolution> does that seem a sane path for everyone?
18:20:56 <smooge> it does to me
18:21:02 <carlwgeorge> no, omsa would require the c and c++ interfaces individually.  the deps don't need to require each other.
18:21:30 <carlwgeorge> that way when omsa finally stops requiring the c++ interface, omsa can just be installed with the one interface.
18:21:47 <pjones> right, so:
18:21:49 <nirik> seems good. Who will bell the cat? :)
18:21:55 <pjones> yeah
18:22:21 <Evolution> pjones gets the internal one, and I'd vote for carlwgeorge to get the epel one
18:22:26 <nirik> I can update the existing package if someone tells me whats exactly needed. Just a release bump?
18:22:27 <Evolution> since he's doing it locally anyway
18:22:36 <Evolution> or that
18:22:50 <carlwgeorge> nirik: bump the epel spec file to a -7 release
18:23:29 <nirik> carlwgeorge: can you make the new package? and one of us can review?
18:23:50 <carlwgeorge> rackspace is currently shipping -6.3 internally, to stay under -7 just in case, but since pjones confirmed he can make sure rh's is eventually higher we can use simple digits
18:24:06 * bstinson is strongly in favor, but in the interest of governance i think we should record a vote on this
18:24:17 <carlwgeorge> nirik: yes, i'll try to make a libsmbios-cpp package
18:24:42 <smooge> #proposal: Nirik will update libsmbios to -7. carlwgeorge will make a libsmbios-cpp package
18:25:06 <bstinson> +1
18:25:09 <smooge> #proposal nirik will update libsmbios to -7. carlwgeorge will make a libsmbios-cpp package
18:25:21 <avij> libsmbios-cpp that provides libsmbios.so.2()(64bit) and bumping EPEL's libsmbios to -7 gets +1 from me,
18:25:30 <smooge> +1
18:25:50 <nirik> +1
18:26:09 <carlwgeorge> +1
18:26:51 <Evolution> wfm
18:27:48 <smooge> #agreed nirik will update libsmbios to -7. carlwgeorge will make a libsmbios-cpp package
18:27:53 <smooge> Ok next up
18:27:59 <Evolution> I've been marginally effective here. it's time for me to take credit, and then swoop in on another call.
18:28:00 <smooge> oh wait.. anything else on this ?
18:28:04 <Evolution> sorry.
18:28:07 <smooge> see you
18:28:09 <smooge> thanks
18:28:13 <Evolution> </manager-hat>
18:28:28 <smooge> #topic EPIC (or why Evolution doesn't get any cake)
18:28:40 <Evolution> :-(
18:28:54 <nirik> I finally sat down and replied to this. ;) Thanks for writing it up smooge.
18:29:05 <smooge> As Kevin said, after years of talking, I wrote up the proposal and sent it out.
18:29:11 <avij> many words of wisdom there
18:29:35 <smooge> The original is an adoc which I can put up somewhere for people to peruse/edit if so desired
18:30:12 <nirik> I think it's pretty doable, but I am concerned about enough releng manpower. I don't think fedora releng has any spare cycles... so it would just be us. ;)
18:30:17 <carlwgeorge> link?
18:30:47 <bstinson> i have a draft of my response percolating somewhere. thanks smooge for putting together the extensive background information too, that really frames it
18:31:05 <avij> #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/MWKF7JQ4DTJZHAN6SMCWD4JTWD56AEGI/
18:31:46 <smooge> avij thanks
18:33:14 <nirik> might want to post a pointer on fedora devel / centos devel lists pointing to that thread for input?
18:33:27 <smooge> so I am not expecting much discussion in this meeting about it since it went out yesterday. I would like to have the discussion on lists..
18:33:45 <smooge> my next step was to put it on the fedora/centos lists if people felt that was what was needed
18:34:35 <smooge> .. has discovered his AC is broke again
18:34:58 <smooge> sorry wrong channel.
18:35:34 <smooge> nirik, I will put in a post to the lists tomorrow after I try to put in the feedback you and others have had.
18:35:49 <smooge> I will put the docuemtn in the epel git repository also
18:36:40 <nirik> cool.
18:37:20 <smooge> does anyone have any feedback like "Dear god man, use a spell checker."
18:37:21 <avij> there's a slight technical challenge with the versioned directories. CentOS 7 (1804) does not know it's really 7.5.
18:38:10 <nirik> we could have 7.5 link to 1804 or vice versa
18:38:16 <avij> same for 6 actually, but at least on CentOS 6 /etc/centos-release says honestly that it's 6.9.
18:38:50 <smooge> avij, oh ok I was looking at CentOS Linux release 7.5.1804 (Core)
18:39:11 <avij> from the mirrorlist.centos.org point of view, the only input given is either 6 or 7, not 6.9 or 7.anything
18:39:32 <smooge> well the same is with RHEL in RHN
18:39:52 <smooge> there is only 6 and 7.. however CentOS has CR which makes it different
18:40:28 <smooge> so this X.Y is mostly for our 'benefit'
18:41:02 <smooge> to try and deal with the window where CR has stuff but base/updates does not
18:41:46 <smooge> does that make sense? or is there a different way to describe this?
18:43:41 <nirik> sidetrack: libsmbios update: /home/kevin/git/pkgs/libsmbios/epel7/libsmbios-2.3.3-7.el7.src.rpm
18:43:42 <avij> well, I'm wondering how this would work from the "package consumer" angle
18:44:23 <smooge> what do you mean?
18:44:43 <avij> in that if someone was running 7.4 they'd need to use 7.4 EPIC packages, 7.4+CR would need to use 7.5 EPIC packages, and 7.5 would need to use 7.5 EPIC packages
18:45:54 * avij rereading some parts of the email to see if I missed something
18:46:12 <smooge> so I would run it like follows: regular person doesn't care they get epel-base/epel-updates. The CR person would get epel-base/epel-updates/epel-cr
18:46:54 <smooge> If a person wants to stay on 7.4 after 7.5 is made official it would be the same if they wanted to do so with CentOS. They point to the equivalnet to the vault til the end of time
18:47:03 <smooge> does that help?
18:47:29 <avij> ah ok, if there's a separate epel-cr repo then that'd work
18:49:05 <smooge> I will clarify tht
18:49:07 <smooge> thanks
18:49:43 <smooge> does anyone have anything else? Otherwise I can go to the last topic
18:49:58 <carlwgeorge> that seems like overkill.  cr is opt in, so i would expect the process would be "opt in to cr and 7.5"
18:50:42 <nirik> carlwgeorge: but if there's a epic-cr repo the 'opt in' is just enabling it. ;)
18:51:14 <bstinson> and we likely need it anyways to allow us to cycle builds against CentOS CR before they both go GA
18:51:15 <smooge> yes that was what I was thinking
18:51:52 <carlwgeorge> so opt in to cr + epic-cr, instead of opt in to cr + epic-7.5?
18:51:59 <avij> well, might work for CentOS, but then again, RHEL users would need to enable the epel-cr repo to get their new packages without waiting
18:52:10 <smooge> this is meant to deal with several problems: 1. packages which are in CR we need to drop. 2. packages needing rebuilds because cr has more stuff
18:52:59 <avij> anyway, I'll need to spend some more time forming my opinion of this. we can go forward.
18:53:03 <smooge> avij, yes. I don't see a way to have it work for the 2 communities otherwise
18:53:09 <smooge> ok
18:53:20 <smooge> #topic Flock Talks or Open Floor (you decide)
18:53:32 <smooge> So I know what my Flock Talk is going to be
18:54:39 <smooge> I figure we will try to get a round-table session
18:54:46 <bstinson> smooge: i can tackle a chunk of the CI portion of the EPIC proposal for Flock
18:54:51 <smooge> thanks
18:55:05 <bstinson> i'm probably going to submit a couple of other buildsys/CI integration topics
18:56:19 <smooge> anything else for the moment? I am at the its 90F in my office and I need to get something cold to drink
18:56:37 <carlwgeorge> yall are gonna get me to try and get rackspace to buy a germany plane ticket, aren't yall
18:56:48 <mattdm> carlwgeorge: yes :)
18:57:04 <smooge> or we are going to get mattdm to buy one for you
18:57:08 <nirik> carlwgeorge: definitely. ;)
18:57:10 <carlwgeorge> i couldn't even get them to sponsor texas linux fest
18:57:28 <smooge> I am pretty sure the second option will be more likely
18:57:40 <nirik> there is some sponsorship via fedora...
18:58:00 <carlwgeorge> i'm all ears
18:58:15 <nirik> well, it's all TBD at this point
18:58:37 <bstinson> do we know when the CFP will be up?
18:59:22 <smooge> not yet
18:59:28 * nb is hoping that mattdm will buy nb a ticket to flock :)
18:59:40 <mattdm> nb: it's pretty likely
18:59:44 <smooge> that is what mattdm gets for showing up in a meeting
18:59:47 <Evolution> I'm happy with spending mattdm's money
18:59:57 <Evolution> but I could be convinced to pony up for some myself
18:59:59 <smooge> he becomes mr moneybags
19:00:03 <mattdm> bstinson: we can hassle bexelbie about that cfp in the next meeting, starting when this one ends
19:00:05 <smooge> ok I need to head out
19:00:11 <smooge> thank you all for coming
19:00:13 <mattdm> and to be clear, it's Fedora's community money, not mine :)
19:00:15 <smooge> #endmeeting