18:01:38 <smooge> #startmeeting EPEL
18:01:38 <zodbot> Meeting started Wed Apr  4 18:01:38 2018 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:38 <zodbot> The meeting name has been set to 'epel'
18:01:38 <smooge> #meetingname EPEL
18:01:38 <zodbot> The meeting name has been set to 'epel'
18:01:39 <smooge> #chair smooge nirik Evolution bstinson avij
18:01:39 <zodbot> Current chairs: Evolution avij bstinson nirik smooge
18:01:39 <smooge> #topic aloha
18:01:55 <nirik> morning
18:01:56 <avij> hello
18:02:04 <smooge> hello this should be a fairly short meeting
18:02:27 <smooge> #topic Agenda?
18:02:31 <bstinson> hi all
18:02:38 <smooge> Does anyone have items for the agenda today?
18:03:33 <smooge> On the EPEL irc channel there have been a couple of items about SCL's and about signed repository metadata
18:04:25 <smooge> There was also a couple of packages which had gotten popped out of el6 due to a 'bug' that puiterwijk fixed. He also retagged the packages
18:04:41 <smooge> so becrypt and a few others should show up again
18:04:57 <puiterwijk> I'm sorry for that. If anyone finds any other packages that got obliterated, please let me know immediately.
18:05:50 <nirik> I don't know of any others.
18:06:20 <smooge> The SCL one was whether SCLs would be allowed in EPEL or packages inside of EPEL to rely on SCL's (aka NextCloud).
18:08:05 <nirik> I'd like to hear how the user experence would be there first.
18:08:17 <nirik> say I enabled epel and did 'yum install nextcloud'
18:08:40 <smooge> I think it would explode
18:08:41 <nirik> do I have to enable SCL's somehow before that works? are SCL's all available in centos? in rhel by some channel?
18:10:17 <smooge> I would expect you have to enable scls somewhere. I think that for a better user experience that things that need stuff outside of EPEL should be in the repository they need. AKA new PHP packages would work better in scl.org versus EPEL
18:10:29 <smooge> or a EPEL-scl would be needed where they get put
18:10:59 <nirik> the problem with epel-scl is we have no guidelines...
18:11:07 <bstinson> that was my thought conditional on the big "IF" of if we allow them in the first place
18:11:51 <smooge> I figure that a lot of things would be needed to make an EPEL-SCL repository... and people who are interested in that can help
18:12:54 <smooge> anyway.. it was brought up
18:12:55 <avij> well, we've allowed SCL as a build requirement, but not as a runtime requirement.. that'd be a few steps further.
18:13:58 <smooge> I think it is possible, but there needs to be a large pile of round tuits delivered to make it happen
18:14:05 <bstinson> i'd gently nudge toward the CentOS SCL SIG as a starting point
18:14:39 <orc_fedo> as Nextcloud will seemingly need a php-7 soon, another approach be to have a 'alongside' php-7 just for nextcloud, inside the nextcloud as a sub-package
18:15:12 <orc_fedo> this is readily doable, and would permit slipping in new php when new php-7 holes turn up
18:16:15 <smooge> all I know on having multiple php stacks in the distro is that it always leads to headaches
18:16:17 <bstinson> pretty sure that would trigger some bundling grumpiness relative to the packaging guidelines
18:16:58 <avij> I don't fancy having a yet another php that would need to be maintained by someone(tm)
18:18:13 <orc_fedo> I think you'll be grumpier still without an explicit locally controlled epel-scl.  pointing epel users toward C kind of runs counter to the purpose of buying an RHEL license in the first place
18:18:33 <orc_fedo> my $0.02
18:18:49 <nirik> orc_fedo: rhel has SCLs too...
18:18:58 <orc_fedo> nirik: true enough
18:19:46 <orc_fedo> which causes me to next lean to a epel-scl as the hammer to select, if parallel sub-packaging is disfavored
18:20:29 <smooge> it is more that someone has to step up and maintain that to some level of maintenance and the main php maintainers have negative interest in it
18:21:40 <smooge> and parallel sub-packaging becomes a "nextcloud has php72 and wordpress has php73 and myphpadmin has php69999999"
18:21:47 <orc_fedo> perhaps Remi might be asked if adding a parallel sub-package php7 process to graft in as needed, would fit in his present worlflow without too much hassle
18:22:06 <orc_fedo> myphpadmin is of course, The Devil
18:22:30 <orc_fedo> along with her sister, phpmysqladmin
18:25:00 <smooge> in the end, my useless opinion is that if your PHP application moves faster than Fedora/Ubuntu can keep up, expecting EL to somehow do so is foolish
18:25:38 <smooge> s/PHP/language of the moment/
18:26:27 <smooge> in any case.. I think it needs a bigger rethink and support structure than this meeting can come up with
18:27:02 <smooge> The otehr item which came up was that CentOS and RHEL can install in a way which won't allow EPEL to be installed because we don't sign our repository metadata
18:27:30 <orc_fedo> interesting STIG post, btw, smooge
18:27:42 <orc_fedo> smooge: ++1
18:27:57 <smooge> I laid out my opinion in the post that it is working as designed.
18:28:14 <smooge> You can't just accept random crap from the internet even if it is random crap we compiled
18:28:35 <smooge> and do our best to support
18:28:59 <smooge> that said, I am not sure how much this affects us
18:30:12 <smooge> #topic Open Floor
18:30:16 <smooge> I forgot to change the topic
18:30:24 <smooge> do we have anything from the floor today?
18:30:34 <avij> CentOS release notes have "Some security profiles enable a global repo_gpgcheck option in /etc/yum.conf to cryptographically verify the repository metadata. While this works for CentOS repositories, some third party repositories (such as EPEL) do not support GPG signed metadata. You may need to either remove repo_gpgcheck from /etc/yum.conf or set repo_gpgcheck=0 for each individual repository that does not support GPG signed metadata." at the momen
18:31:01 <smooge> I am going to put this in the EPEL faq next week
18:31:02 <avij> nobody reads those, but it's there.
18:31:48 <avij> so we (CentOS folks) can point them to https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7 and blame them for not reading the release notes
18:33:28 <smooge> thanks. I didn't know if we should add a #repo_gpgcheck=0 into the repository data?
18:35:06 <orc_fedo> smooge: I don't see a downside for doing that as it refers one to the man page, and optionally to your blog post, and thence to the RHEL doco
18:35:09 <avij> that would be an option
18:35:29 <smooge> ok I will look at getting that in.
18:36:02 <smooge> Outside of that, I am going to close this meeting unless someone else has something. I have to go reboot a bunhc of boxes it would seem
18:36:21 * orc_fedo thinks: The Grim reaper approacheth
18:36:52 <smooge> #endmeeting