20:00:20 <tdawson> #startmeeting EPEL (2021-07-14)
20:00:20 <zodbot> Meeting started Wed Jul 14 20:00:20 2021 UTC.
20:00:20 <zodbot> This meeting is logged and archived in a public location.
20:00:20 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:20 <zodbot> The meeting name has been set to 'epel_(2021-07-14)'
20:00:20 <tdawson> #meetingname epel
20:00:20 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
20:00:20 <zodbot> The meeting name has been set to 'epel'
20:00:20 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
20:00:21 <tdawson> #topic aloha
20:00:28 <nirik> morning
20:00:31 <michel-slm> .hi salimma
20:00:31 <zodbot> michel-slm: Sorry, but you don't exist
20:00:36 <michel-slm> .hello salimma
20:00:37 <tdawson> Hi nirik
20:00:38 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:00:41 <michel-slm> hi nirik!
20:00:47 <pgreco> hello everybody!
20:00:47 <tdawson> Hi michel-slm
20:00:55 <tdawson> Hi pgreco
20:01:16 <michel> I'm surprised Matrix flagged the mention of my IRC-only nick too, wow
20:01:47 <tdawson> Hi other michel :)
20:02:08 <carlwgeorge> .hi
20:02:11 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:02:22 <tdawson> Hi carlwgeorge
20:02:23 * nirik watches the power9 firmware upload. Hopefully everyone elses week is going better. ;)
20:02:49 <michel-slm> Davide sends his regrets, he's at the board meeting again
20:02:56 <pgreco> ohh, watching firmware updates is fun/tense/scary.....
20:02:58 <michel-slm> nirik: oof.
20:03:15 * michel-slm is spending today in either meetings or writing performance review. the meetings are the high points :)
20:03:29 <nirik> yeah... always wondering if it will work or not. :)
20:03:36 <tdawson> Let Davide know we missed him.
20:04:24 <michel-slm> 'tell Davide we miss him' sung to the 'Tell Laura I love Her' tune? ok
20:04:31 <tdawson> This meeting is always the high point of my week ... except when I realize how much I didn't get done.
20:04:42 <tdawson> Ha!
20:04:46 <michel-slm> yeah, me too
20:04:50 <tdawson> sounds good.
20:05:02 <rsc> .hello robert
20:05:03 <michel-slm> having it on Wednesday helps a bit, that means there's time to squeeze in more work before the weekend
20:05:03 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:05:09 <michel-slm> hi rsc!
20:05:21 <tdawson> Hi rsc
20:05:28 <carlwgeorge> yeah i like the wednesday scheduling, lines up with my other big weekly meeting
20:05:45 <tdawson> #topic Old Business
20:06:05 <tdawson> Any SIG related news?
20:07:08 <tdawson> michel How is your script that opens bugs for all the dependencies coming along?
20:07:18 <michel-slm> my automated tool work is slightly blocked on python-bugzilla being unexpectedly slow with RH BZ (they use the old fallback API because I think they mostly support upstream Bugzilla these days). I plan to have more time on it once I'm (ironically) on leave tomorrow
20:07:41 <michel-slm> but I've been experimenting with the wordings on some of the bugs I opened in the past week.
20:08:17 <michel-slm> also discovered that our documented procedure for requesting a branch is a bit vague - for example, we always tell people 'file against Fedora EPEL if the package has been branched for EPEL before' but that's not written
20:08:26 <michel-slm> https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
20:08:42 <michel-slm> not urgent, but we should probably update this at some point. should I file an issue so we don't forget?
20:09:06 <tdawson> Sounds like a good thing to do.
20:09:13 <michel-slm> ack, will do
20:09:22 * nirik nods, we should update it for sure.
20:09:43 <michel-slm> https://bugzilla.redhat.com/show_bug.cgi?id=EPELPackagersSIG for the status of what we're currently tracking. I'm about ready to escalate the Phoronix request to fesco
20:10:25 <tdawson> Which one is that?
20:10:26 <michel-slm> (in this case the maintainer seems totally awol on the fedora side too... nirik, when FESCO grants approval, what access do they normally give? admin or just commit)
20:10:37 <michel-slm> https://bugzilla.redhat.com/show_bug.cgi?id=1976280
20:11:07 <nirik> I think admin... but we didn't have 'collaborator' before...
20:11:22 <tdawson> michel-slm: Why don't you just use the "Stalled EPEL package" request, it doesn't have to go through Fesco
20:11:23 <carlwgeorge> when i did the process i got collaborater
20:11:31 <nirik> and if they aren't responding at all, might orphan their fedora packages too.
20:11:36 <michel-slm> tdawson: I thought the stalled thing goes to fesco
20:11:48 <nirik> nope, doesn't have to.
20:11:49 <michel-slm> my bad, rel-eng
20:11:57 <tdawson> Nope, just 1 week, ping, 1 week, releng
20:12:18 <michel-slm> right. there's another bug for getting the Fedora package updated, so I'll do the non-responsive process there
20:12:23 <tdawson> Ah ... ok.  Yep
20:12:56 <carlwgeorge> i know a few people that will be happy to see that updated in fedora
20:13:03 <michel-slm> that's it from me. I have something for EPEL8 later
20:13:09 <michel-slm> carlwgeorge: phoronix? yeah
20:13:10 * mboddu reading back
20:13:27 <tdawson> OK, moving on to -next
20:13:38 <tdawson> carlwgeorge: mboddu: any news for epel-next ?
20:14:05 <carlwgeorge> nothing new to report, except mboddu and me are going to present on it at nest (if accepted)
20:14:21 <tdawson> That will be nice
20:14:25 * michel-slm amazed at the new non-responsive maintainer template, wondering if that's new
20:14:34 <nirik> cool.
20:14:36 <tdawson> When do we find out if things are accepted?
20:14:40 <mboddu> tdawson: Nope, just that email
20:15:01 <mboddu> And the NEST proposal
20:15:46 <tdawson> OK, moving on.
20:16:12 <carlwgeorge> since we're still in old business, any word on tesseract?
20:16:43 <tdawson> Oh yes ... and the word is that they are sticking with tesseract 3 :(
20:17:06 <nirik> thats unfortunate
20:17:13 <tdawson> opencv was compiled with tesseract 3, and they don't want to break ABI's on that.
20:17:18 * michel-slm notes Nest still accepts CFPs - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AK42WP2CHGTXEIOZA6ILRO7ITXP4KYOX/
20:17:51 <tdawson> Yep.  I did ask them to open a bugzilla on the epel version of tesseract.
20:18:31 * carlwgeorge is not clear on how opencv's abi could be broken by that
20:19:06 <tdawson> If you read the bugzilla, you will see that you aren't the only one, it isn't just me asking for version 4.
20:19:24 <tdawson> I think I'm just the most blunt.
20:20:32 <tdawson> For documentation ... I think Petr's just too busy to do the whole thing.  I'm going to ask him to just get us a skelaton setup, and let us know how to update, and then we can bring things over a page or two at a time.
20:20:54 <michel-slm> +1, I think it's just harder to get started so a skeleton makes sense
20:21:15 <nirik> yeah.
20:21:24 <nirik> if there's something there we might be able to get moving on it.
20:22:02 <tdawson> Petr's working on Fedora, ELN, CentOS Stream, and possibly other documentation ... he's got a lot on his plate ... so hopefully he'll be able to get something setup without too much effort.
20:22:31 <tdawson> I might also try Adam S., he's good with documentation, but he didn't want to do it unless it had the OK from Petr.
20:22:48 <michel-slm> minimization Adam?
20:22:49 <nirik> yeah
20:22:51 <tdawson> But, I'll give Petr one more try.
20:22:52 <tdawson> Ya
20:24:08 <tdawson> I think that's all I have on documentation
20:25:03 <tdawson> Badges are still ... stalled, haven't been touched.  Logo's have had a few more variations thrown around
20:25:16 <tdawson> https://pagure.io/fedora-badges/issue/829   and https://pagure.io/design/issue/770
20:25:38 <tdawson> If you want to see the variations, 770 is the issue to look at.
20:26:12 <tdawson> Any other old business that I might have missed?
20:26:42 <tdawson> #topic EPEL-7
20:27:16 <tdawson> Anything for EPEL-7 ?
20:27:25 <tdawson> I don't remember any EPEL-7 stuff this week.
20:27:45 <pgreco> do we have a magic bugzilla query to get open cves on epel7?
20:27:55 <michel-slm> a quick one - I comaintain some packages (mostly for either Fedora or EPEL8) and I notice the packager dashboard shows epel7 bugs... some of them CVEs
20:28:16 <michel-slm> should I just... retire them if they can't be quickly fixed?
20:28:45 <pgreco> can you send me a link after the meeting?
20:29:25 <pgreco> I don't want to stall the meeting over this, but I'd like to pick your brain
20:29:26 <carlwgeorge> case by case i'd say, it would be a shame for a moderate cve to cause the package to be retired from epel7
20:29:51 * Eighth_Doctor waves
20:29:52 <michel-slm> yeah. epel is different enough that I wish there's a way to indicate a POC per release, not just for all of EPEL
20:29:55 <tdawson> Hi Eighth_Doctor
20:29:57 <michel-slm> (and I'm so glad epel6 is gone)
20:30:23 <Eighth_Doctor> michel-slm: RH Product Sec knows how to do this :)
20:30:29 <Eighth_Doctor> I've had sec bugs filed against me for epel stuff before
20:30:57 <michel-slm> Eighth_Doctor: ya but I want to be able to say "I care about epel8 but not epel7"
20:31:30 <michel-slm> speaking of epel8, I do have two items for it
20:31:31 <Eighth_Doctor> ahh
20:31:40 <tdawson> #topic EPEL-8
20:31:46 <tdawson> L)
20:31:48 <tdawson> :)
20:31:51 <michel-slm> yay
20:31:56 <michel-slm> ok, #1 -- rpmautospec
20:32:03 <michel-slm> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/2QRIX4SJFNE65BJGHHKXOHT7G63NAC7Q/
20:32:29 <michel-slm> now that it's in Rawhide, should we build and require it from epel-rpm-macros? (the same question holds for F34 but this is the epel meeting)
20:32:42 <tdawson> That is a very good question
20:32:47 <nirik> I didn't follow closely how they implemented it.
20:32:59 <nirik> I think it would be good to enable in epel* tho...
20:33:11 <Eighth_Doctor> it should be possible
20:33:11 <Eighth_Doctor> and we probably should
20:33:14 <michel-slm> I could see it making Rawhide<->EPEL sync much easier, since... the only merge conflict you'll hopefully have is in the changelog, if you want to prune the change log to not mention Rawhide specific stuff
20:33:19 <Eighth_Doctor> it was designed to be backward compatible to epel7
20:33:47 <Eighth_Doctor> there will probably not be much pruning, since commits are likely to be fast forwarded
20:33:47 <michel-slm> so... no objection if I try it? just build a POC locally, demonstrate it works, then request a branch and do a PR for epel-rpm-config
20:33:49 <Eighth_Doctor> but it's at least a thing
20:33:51 <carlwgeorge> i've never bothered pruning changelogs when merging from rawhide back to epel branches
20:34:05 <michel-slm> Eighth_Doctor: yeah, I'm just thinking of packages that have already diverged
20:34:16 <nirik> michel-slm: if thats the way to enable it. We might make sure with the folks working on it.
20:34:19 <michel-slm> e.g. because of epel-playground. for those I normally also prune the changelog, since, why not
20:34:25 <tdawson> michel-slm: No objection, and something I'd like to see
20:34:37 <michel-slm> nirik: yeah, that post is cross posted to devel, so I'm hoping the devs respond
20:34:41 <carlwgeorge> linear commit history for one
20:35:09 <michel-slm> #action Michel to try enabling rpmautospec for EPEL8, subject to feasibility and feedback from Change owners
20:35:15 * decathorpe notes: rpmautospec works fine in F34
20:35:16 <nirik> michel-slm: I think a ticket asking for what would be needed to enable for epel would be good.
20:35:33 <nirik> there was one issue with it already... getting stuck in a loop. ;(
20:35:44 <michel-slm> nirik: good point. where should I file it?
20:36:04 <nirik> https://pagure.io/fedora-infra/rpmautospec/issues
20:36:11 <michel-slm> given that this is optional, as long as we don't have EPEL specific issues I think that's ok. thanks!
20:36:41 <michel-slm> ok, second topic. Davide asked me to bring this up: can we have an EPEL equivalent of fedora's archive repo?
20:37:25 <tdawson> https://archives.fedoraproject.org/pub/archive/epel/
20:37:27 <michel-slm> FB is willing to provide hosting on mirror.facebook.net, and an S3 bucket to dump the packages for processing, but we'd need it to be hooked to Bodhi I guess so we can catch everything that's ever published
20:37:31 <nirik> hum?
20:37:35 <tdawson> something beyond that?
20:37:37 <michel-slm> oh dear, I didn't think to check and didn't realize it exists
20:37:38 <nirik> we already do?
20:37:44 <michel-slm> oh wait, no
20:38:08 <michel-slm> basically if EPEL has 5 copies of package X ever published in, say, epel8
20:38:13 <michel-slm> we want to be able to grab all 5
20:38:13 <tdawson> Those are just snapshots we take at each Major/Minor RHEL release.
20:38:35 <nirik> ah that has been a long time discussion
20:38:36 <michel-slm> yeah, that's different then. fedora-archive is something IIRC the Core OS folks flipped on when F32 comes out
20:38:38 <pgreco> michel-slm: I'm guessing you need  all the builds and not just the snapshots
20:38:47 <nirik> thats fedora-updates-archive
20:38:51 <michel-slm> we have a similar use case but based on EPEL. sometimes we need older updates
20:39:09 <michel-slm> pgreco: yeah, we want something like fedora-updates-archive for epel. sorry for being unclear earlier
20:39:38 <nirik> well, you can get things from koji... but yes, I understand the appeal of wanting to be able to downgrade
20:39:42 <michel-slm> nirik: yeah, I can imagine the discussion. hoping that since we're shouldering the bill the infra effect is minimal here
20:40:06 <michel-slm> just polling koji for packages that are tagged for release? I guess we can do that
20:40:13 <nirik> the big problem is that we are then publishing all the insecure versions and it becomes easer to trick someone into installing those. ;(
20:40:17 <pgreco> nirik: how often does koji prune the signed packages?
20:40:41 <michel-slm> nirik: yeah, same problem with fedora-updates-archive I expect
20:40:43 <nirik> I can't recall... a month?
20:41:11 <pgreco> that sounds about right
20:41:12 <nirik> yeah, in that case it's really only used by coreos to be able to downgrade their ostree stuff, it's not used by end users really.
20:41:33 <michel-slm> I expect that we probably would also check for security updates, and potentially remove versions before the last security update for each package
20:42:14 <michel-slm> nirik: we enable the updates-archive repo on our Fedora fleet too, for 'break glass' emergencies normally involving kernel / driver updates breaking functionality (we needed to use it once when ALSA broke on X1 Carbons)
20:42:16 <nirik> but thats very hard to do in an automated way.
20:43:16 <nirik> I guess we could see if we can just add it on to the existing fedora-updates-archive process... but the security thing worries me.
20:43:18 <michel-slm> so... if we siphon off packages from Koji/Bodhi, with a pull model rather than push, and try to not do it too often, that's OK for the infra team?
20:43:30 <nirik> sure, thats fine.
20:43:41 <michel-slm> adding to the existing process will be ideal, so maybe we can discuss both in parallel
20:44:12 <michel-slm> we can unblock our team that requested this by doing our own rebuild while waiting for the discussion to be resolved. where should I ask this, fedora-infra ticket?
20:44:25 <carlwgeorge> i lost track, are we still on the epel8 topic?
20:44:33 <tdawson> carlwgeorge: Yes
20:44:44 <carlwgeorge> i got a thing for it before we move on
20:44:57 <rsc> Same
20:45:04 <tdawson> carlwgeorge: I think the other has wound down, go for it
20:45:12 <pgreco> michel-slm: wondering about modules when getting them from koji/bodhi....
20:45:34 <nirik> michel-slm: sure. We can rope in dustymabe there (he's the one doing that stuff)
20:45:55 <michel-slm> nirik: got it, thanks! pgreco: I hope our team does not care about modules, but good point
20:46:06 <michel-slm> carlwgeorge: go ahead
20:46:25 <carlwgeorge> xapian-core is being added to rhel 8.5 (already in cs8), but no -devel package.  it's currently in epel8 and will need to be retired.  more than a few epel packages will be impacted by the lack of a -devel package.
20:46:39 <carlwgeorge> https://bugzilla.redhat.com/show_bug.cgi?id=1982029
20:47:17 <michel-slm> will the version in 8.5 be compatible with the current version in EPEL?
20:47:33 <carlwgeorge> yes, it's just slightly ahead so it's a fine upgrade
20:47:34 <michel-slm> in which case, should we just keep the dependents around knowing they will eventually continue to work?
20:48:05 <michel-slm> can't wait til we resolve this -devel package issue :(
20:48:08 <carlwgeorge> from that bug and the related private one, it sounds like the maintainer is ok adding xapian-core-devel to crb, but not ok with the acg level going up, which sounds like a conflict
20:48:20 <tdawson> No, those are on my list of packages ... and they are already built on epel8-next
20:49:12 <michel-slm> for context... what's acg? sorry
20:49:32 <carlwgeorge> i put a build requirements tree of affected packages in the bug, lots of kf5 stuff
20:49:41 <carlwgeorge> michel-slm: https://access.redhat.com/articles/rhel8-abi-compatibility
20:49:49 <michel-slm> oh, compatibility guarantee
20:49:58 <michel-slm> thanks
20:50:01 <tdawson> carlwgeorge: I'll keep an eye on this one, and if nobody files a bugzilla requesting the -devel by ... tomorrow, I will
20:50:16 <tdawson> This totally affects me and my builds ... alot.
20:50:19 <carlwgeorge> tdawson: see https://bugzilla.redhat.com/show_bug.cgi?id=1918908#c16 (private)
20:51:12 <carlwgeorge> michel-slm: tldr, this is the core of the unshipped -devel thing.  if the -devel is not shipped, maintainers can bump the library soname all they want.  shipping the -devel makes the -libs acg level 2, so no soname changes.
20:51:17 <michel-slm> speaking of which... can we get a bugzilla group for epel sig, and have them sometimes added to this private bugs?
20:51:19 <carlwgeorge> *without strong justification
20:51:40 <michel-slm> carlwgeorge: makes sense, yeah
20:52:11 <carlwgeorge> probably not worth it.  i think this bug has customer stuff in it.  and any time a bug doesn't have customer stuff, we should just ask for it to be public in general.
20:52:30 <carlwgeorge> i can't think of a situation where it's appropriate for the epel sig to see a bug where it's not appropriate to just make it public for everyone
20:52:59 <tdawson> carlwgeorge: I'll file a seperate bug.  A) So it's public, and B) because this hits me and my builds hard, so I want them to explain it, in the open.
20:52:59 <michel-slm> time's getting short so we probably should let rsc go
20:53:08 <carlwgeorge> tdawson++
20:53:08 <rsc> I would like to bring up something like a "gcc-extras" package for EPEL 8 to bring back some missing GCC extensions in order to build software requiring it (which might require bootstrapping based on existing binaries).
20:53:18 <carlwgeorge> i've got one more, super quick
20:53:36 <tdawson> carlwgeorge: OK ... but we're getting short, and rsc said he had something.
20:53:51 <tdawson> rsc: Oh, is the gcc-extras what you were bringing up?
20:54:17 <rsc> tdawson: yes
20:54:18 <michel-slm> gcc-extras sounds great. is the worry the bootstrapping process?
20:54:36 <rsc> Question are: Would "gcc-extras" be suitable? And how could I do gcc-gnat bootstrapping in an acceptable way, given gnat requires gnat. Putting "own" binaries into the buildsystem was disliked in the past.
20:54:45 <pgreco> doesn't rust normally do that?
20:54:58 <rsc> No idea, I'm not rusty. ;)
20:55:07 <tdawson> Ha!
20:55:16 <pgreco> bootstrap itself from rustup binaries
20:55:39 <rsc> And last but not least...does this require a package review or would it be under an exception.
20:55:55 <pgreco> https://src.fedoraproject.org/rpms/rust/blob/rawhide/f/rust.spec
20:56:25 <carlwgeorge> why not gcc-epel like other epel-only things we've done recently?
20:56:27 <tdawson> rsc: It really depends.  If the missing packages were built in RHEL gcc, but never shipped, then it certainly qualifies as an exception.
20:56:37 <pgreco> from what I remember, it pushes the binaries as sources for all arches and bootstraps from there
20:56:45 <michel-slm> would src: gcc-epel and binary package: gcc-gnat be OK?
20:57:05 <rsc> (it's not only gcc-gnat, but gcc-objc etc., too)
20:57:15 <tdawson> rsc: If it's additions to it, then I believe it will require a package review.
20:57:29 <rsc> tdawson: no additions, just what Red Hat crippled.
20:57:34 <Eighth_Doctor> yeah, I'd also probably want it synchronized with devtoolset
20:57:42 <Eighth_Doctor> or system compiler version
20:58:07 <carlwgeorge> rsc: crippled in what what?  disabled in the build, or just built and not shipped?
20:58:12 <carlwgeorge> *what way
20:58:13 <Eighth_Doctor> so it would require some care to make that work
20:58:25 <rsc> carlwgeorge: disabled in build for RHEL 8 the first time (while it's there in RHEL < 8 and Fedora)
20:58:44 <carlwgeorge> so that would require a package review
20:58:49 <rsc> Plan is to take gcc SRPM from RHEL 8 and flip the flags and put some "%if 0" to avoid duplicate binary RPMS for gcc/gcc-++ etc.
20:59:20 <carlwgeorge> the package review exception is just when you're basically rebuilding the unshipped (but built) packages
20:59:24 <rsc> Okay. Is the "-epel" somewhere documented? Or are there examples from other packages? I just remember to "php-extras" in old times.
20:59:51 <carlwgeorge> lmdb-epel is the most recent example i can think of.  i don't think we've documented it anywhere.
21:00:08 <pgreco> rsc, it may need more than that, when I bootstrapped gcc-gnat for armhfp/c7, the main rpm had requires/provides in a way that made the install of gcc-gnat impossible
21:00:36 <carlwgeorge> getting my last thing in before we close up, while looking into potential epel-next rebuilds, i noticed several things (plasma-nm and nextcloud-client subpackages) that don't install on epel8 or epel8-next due to missing run time deps.  take a look at the open bugs for those components if you're curious to get involved.
21:00:57 <rsc> pgreco: yes, I saw things in the spec file already... ;-(
21:01:15 <michel-slm> carlwgeorge: uh, I did the nextcloud-client rebuild. will check
21:01:30 <carlwgeorge> michel-slm: nextcloud-client-nemo
21:01:30 <tdawson> carlwgeorge: I know about the plasma-nm packages ... still debating the best to handle those ... do you have a bugzilla for them?
21:02:10 <michel-slm> carlwgeorge: just because nemo is not available on epel, right? so I can just fix the spec to exclude it
21:02:17 <Eighth_Doctor> what's wrong with plasma-nm?
21:02:22 <carlwgeorge> tdawson: https://bugzilla.redhat.com/buglist.cgi?component=plasma-nm&list_id=12013072&product=Fedora%20EPEL
21:02:35 <carlwgeorge> -vpnc, -ssh, and -iodine
21:02:52 <tdawson> Eighth_Doctor: There are three packages it builds for that aren't in RHEL or EPEL, so they can't install.
21:03:03 <Eighth_Doctor> ah
21:03:13 <michel-slm> carlwgeorge: would I have to ask rel-eng to block nextcloud-client-nemo?
21:03:28 <michel-slm> since they've already escaped into the repo. or would pushing an update get them cleaned up automatically
21:03:29 <tdawson> plasma-nm-iodine plasma-nm-ssh plasma-nm-vpnc
21:03:36 <carlwgeorge> michel-slm: best solution since it's already shipped would be to add the missing runtime dep to epel8
21:03:57 <michel-slm> carlwgeorge: so request nemo to be branched for epel8? yeah, I can do that
21:04:04 <nirik> well, no one could have installed them without --force --nodeps. :)
21:04:08 * michel-slm 's famous last words
21:04:30 <carlwgeorge> oh one more thing i forgot this during the epel-next section, we had a bug where things were going straight to stable skipping testing.  i fixed it by setting the mandatory_days_in_testing to 7 (like fedora, regular epel is 14).
21:04:49 <michel-slm> carlwgeorge: I noticed that in my first -next build!
21:04:59 <carlwgeorge> yeah auto went to 0, whoops
21:05:00 <michel-slm> I'm also OK with setting it to 3 like Fedora pre-release
21:05:14 <michel-slm> but I guess 7 is a nice compromise
21:05:40 <tdawson> That's right ... we were going to bring up moving EPEL's default time to 7 days
21:05:47 <tdawson> I'll put it on next weeks agenda.
21:06:02 <michel-slm> if EPEL goes to 7, should EPEL-next be shorter? or the same
21:06:06 <michel-slm> I guess we can discuss that next week
21:06:19 * michel-slm noticed tdawson's agenda also has EPEL9
21:06:20 <tdawson> That's a good question for next week. :)
21:06:29 <tdawson> Ha!  It does
21:06:40 <tdawson> Thanks everyone for coming, and the good discussion.
21:06:52 * michel-slm now reads emails after switching back to Mutt :p
21:06:53 <carlwgeorge> never enough time
21:07:00 <michel-slm> tdawson++ thanks for hosting!
21:07:02 <tdawson> We're out of time, so I'm going to close up shop for the next meeting.
21:07:09 <tdawson> #endmeeting