18:01:38 #startmeeting EPEL 18:01:38 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:38 The meeting name has been set to 'epel' 18:01:38 #meetingname EPEL 18:01:38 The meeting name has been set to 'epel' 18:01:39 #chair smooge nirik Evolution bstinson avij 18:01:39 Current chairs: Evolution avij bstinson nirik smooge 18:01:39 #topic aloha 18:01:55 morning 18:01:56 hello 18:02:04 hello this should be a fairly short meeting 18:02:27 #topic Agenda? 18:02:31 hi all 18:02:38 Does anyone have items for the agenda today? 18:03:33 On the EPEL irc channel there have been a couple of items about SCL's and about signed repository metadata 18:04:25 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 so becrypt and a few others should show up again 18:04:57 I'm sorry for that. If anyone finds any other packages that got obliterated, please let me know immediately. 18:05:50 I don't know of any others. 18:06:20 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 I'd like to hear how the user experence would be there first. 18:08:17 say I enabled epel and did 'yum install nextcloud' 18:08:40 I think it would explode 18:08:41 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 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 or a EPEL-scl would be needed where they get put 18:10:59 the problem with epel-scl is we have no guidelines... 18:11:07 that was my thought conditional on the big "IF" of if we allow them in the first place 18:11:51 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 anyway.. it was brought up 18:12:55 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 I think it is possible, but there needs to be a large pile of round tuits delivered to make it happen 18:14:05 i'd gently nudge toward the CentOS SCL SIG as a starting point 18:14:39 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 this is readily doable, and would permit slipping in new php when new php-7 holes turn up 18:16:15 all I know on having multiple php stacks in the distro is that it always leads to headaches 18:16:17 pretty sure that would trigger some bundling grumpiness relative to the packaging guidelines 18:16:58 I don't fancy having a yet another php that would need to be maintained by someone(tm) 18:18:13 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 my $0.02 18:18:49 orc_fedo: rhel has SCLs too... 18:18:58 nirik: true enough 18:19:46 which causes me to next lean to a epel-scl as the hammer to select, if parallel sub-packaging is disfavored 18:20:29 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 and parallel sub-packaging becomes a "nextcloud has php72 and wordpress has php73 and myphpadmin has php69999999" 18:21:47 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 myphpadmin is of course, The Devil 18:22:30 along with her sister, phpmysqladmin 18:25:00 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 s/PHP/language of the moment/ 18:26:27 in any case.. I think it needs a bigger rethink and support structure than this meeting can come up with 18:27:02 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 interesting STIG post, btw, smooge 18:27:42 smooge: ++1 18:27:57 I laid out my opinion in the post that it is working as designed. 18:28:14 You can't just accept random crap from the internet even if it is random crap we compiled 18:28:35 and do our best to support 18:28:59 that said, I am not sure how much this affects us 18:30:12 #topic Open Floor 18:30:16 I forgot to change the topic 18:30:24 do we have anything from the floor today? 18:30:34 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 I am going to put this in the EPEL faq next week 18:31:02 nobody reads those, but it's there. 18:31:48 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 thanks. I didn't know if we should add a #repo_gpgcheck=0 into the repository data? 18:35:06 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 that would be an option 18:35:29 ok I will look at getting that in. 18:36:02 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 #endmeeting