20:00:46 <tdawson> #startmeeting EPEL (2021-06-16)
20:00:46 <zodbot> Meeting started Wed Jun 16 20:00:46 2021 UTC.
20:00:46 <zodbot> This meeting is logged and archived in a public location.
20:00:46 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:46 <zodbot> The meeting name has been set to 'epel_(2021-06-16)'
20:00:50 <tdawson> #meetingname epel
20:00:50 <zodbot> The meeting name has been set to 'epel'
20:00:54 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
20:00:54 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
20:00:59 <tdawson> #topic aloha
20:01:21 <dcavalca> .hi
20:01:23 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:28 <tdawson> Hi dcavalca
20:01:31 <carlwgeorge> howdy
20:01:34 <nirik> morning
20:01:48 <tdawson> Hi carlwgeorge
20:01:55 <tdawson> Hi nirik
20:02:09 <pgreco> hey everybody
20:02:21 <pgreco> dcavalca: hello mr board member!!!
20:02:53 <tdawson> Hi pgreco
20:03:14 <tdawson> dcavalca: Congratulations
20:03:49 <dcavalca> lol thanks
20:04:14 <michel> Radek: packages are not branched by default for EPEL, if something is missing please file a bug requesting it
20:04:15 <michel> .hello salimma
20:04:15 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:04:19 * michel notes that Davide does not like being called Il Direttore
20:04:20 <michel> hi all!
20:04:54 <michel> ha, having a username that is just my first name really causes confusion with the IRC->Matrix bridge
20:05:03 <tdawson> Hi michel
20:06:01 <tdawson> #topic Old Business
20:06:14 <tdawson> Let's start with the EPEL packaging SIG
20:06:16 * nirik always thinks tdawson is making fun of him with that.
20:06:33 <michel> nirik: with what?
20:06:38 <tdawson> Any new business?
20:06:42 <michel> ok, so I looked into how to create a template
20:06:43 <nirik> "old" business. :)
20:06:51 * nirik is old.
20:06:55 <michel> it looks... a bit involved. anyone knows which repo the template is in?
20:07:18 <tdawson> nirik Are you older than me?  or smooge?
20:07:25 <michel> but anyway, I'm thinking the use case we need to optimize for is if you want package A in EPEL, and it has 5 other dependencies... and you want to streamline that process
20:07:30 * michel will turn 42 later this year
20:07:31 <smooge> he is older than me
20:07:50 <pgreco> nirik I don't think you're even older than me
20:07:53 <michel> so I guess the most meaningful question in the universe is "how old is Michel"
20:08:11 <tdawson> michel: Ya, that's always a pain when you need to do alot of dependencies.
20:08:17 <michel> #info Bugzilla template instructions: https://bugzilla.readthedocs.io/en/latest/integrating/templates.html
20:08:29 <smooge> but barely
20:08:34 <nirik> I'm so old I forget how old I am. ;)
20:08:42 <michel> tdawson: so... I just started using Mutt with anger on my CentOS box, and have what I think is a perfect use case for this tool I want to write
20:08:47 <smooge> your old enough to enjoy your applesauce
20:08:57 <michel> goal: feed it a yaml (or another markup) describing the dependency tree
20:09:31 <michel> it will then autofile the bugs and link them correctly for you. so the template can just be maintained in the repo for this tool, and you don't need to even customize it, it will be prefilled
20:09:48 <tdawson> That will be cool
20:10:15 <michel> (mutt is in EPEL, but to auto-complete contacts it needs two other tools, khard and vdirsyncer, and they have about 7 Python deps between them)
20:10:58 <michel> I can probably add a way to check on stale requests there too and automate the filing of infra requests next. but yeah, going to dogfood it for this set of packages
20:11:14 * nirik has to go move water, back in a min.
20:11:16 <michel> that's it from me - just finished my second-to-last oncall before i can focus on OSS :)
20:11:45 <michel> oh, once I have something working, any preference for where the code should live? do we have a group on Pagure?
20:11:49 <tdawson> That will be nice.  I hope the dogfood tastes good ... or works, whatever the proper phrase is
20:12:05 * michel tried cat food once. it's not terible
20:12:09 * michel * tried cat food once. it's not terrible
20:13:01 <tdawson> I don't know if epel is a group - https://pagure.io/epel
20:13:22 <tdawson> But we do have a plac eto put files
20:13:32 <tdawson> Huh ... spelled right, spaced wrong
20:13:58 <tdawson> place to put files
20:14:21 <michel> that seems a repo
20:14:30 <michel> I can put it on my pagure / github for now
20:14:42 <michel> oh fun it has the old board members listed still :D
20:15:49 <tdawson> Yep ... need to be older than 50 to be on that list
20:15:58 <tdawson> Oh ... you meant something else. :)
20:16:04 * michel laughs
20:16:28 <michel> I'm charting my age by now many "Over X support groups" I can join at work
20:16:29 <Eighth_Doctor> you could make an epel group
20:16:43 <Eighth_Doctor> and then start setting things up that way
20:16:43 <michel> we grouch about how the young 'uns don't get Matrix references anymore
20:16:44 <michel> and Hackers
20:16:56 <Eighth_Doctor> that's what we did in fedora-workstation
20:17:00 <michel> <Eighth_Doctor "you could make an epel group"> won't the epel group clash with the epel repo?
20:17:05 <Eighth_Doctor> nope
20:17:19 <Eighth_Doctor> see https://pagure.io/group/fedora-workstation
20:17:25 <Eighth_Doctor> vs https://pagure.io/fedora-workstation
20:17:25 <michel> oh
20:17:31 <tdawson> Nice
20:17:38 <michel> ok, should I do that?
20:17:47 <Eighth_Doctor> yes
20:17:58 <michel> we can vote on it if people want but I forgot how to propose :p
20:18:03 <Eighth_Doctor> once you have an epel group, you can make projects in the namespace
20:18:12 <Eighth_Doctor> and you can make the epel repo as part of that group too
20:18:25 <michel> can we rehome it, or do we need to create a new one?
20:18:27 <Eighth_Doctor> (even though it's not in the namespace, because pagure considers namespace and groups separate)
20:18:32 <michel> ah ok
20:18:46 <michel> it will be in the group but still at the old URL
20:18:46 <Eighth_Doctor> yep
20:18:55 <Eighth_Doctor> namespaces are created with groups, but projects don't have to be in the namespace
20:18:57 <michel> kind of like... Matrix Spaces /ducks
20:19:10 <Eighth_Doctor> it's weird, but that quirk exists because pagure was designed with dist-git use-cases in mind
20:19:20 <michel> *nods
20:19:22 * nirik is fine either way. For something like this it seems like it would be fine to just put it in epel project, but whatever.
20:19:23 <Eighth_Doctor> as an admin, you can create namespaces with no groups
20:19:27 <michel> so all projects have to be accessible at /rpms/pkgname
20:19:30 <Eighth_Doctor> yes
20:19:55 <Eighth_Doctor> it's useful because namespaces don't wind up being tied to group permissions either
20:20:03 <Eighth_Doctor> which as far as I know, nothing else does
20:20:08 * nirik is now getting confused what you are talking about
20:20:08 <michel> nirik: it might be flexible enough to cover non-epel use cases, and... we might want a separate docs repo at some point. so, yeah, why not
20:20:32 <Eighth_Doctor> nirik: I'm just explaining how groups and namespaces work in pagure to Michel Alexandre Salim
20:20:42 <michel> I think we're ratholing a bit about how namespaces work, we can move on
20:20:51 <nirik> ok, but you are talking about pagure.io and a epel namespace, not src.fedoraproject.org right?
20:20:59 <tdawson> OK, anything else for the SIG?
20:21:35 <tdawson> Let's move on to epel-next
20:21:37 <Eighth_Doctor> nirik: yes
20:21:40 <michel> nirik: yes, but I guess they're both Pagure underneath so the same capabilities exist
20:21:44 <tdawson> carlwgeorge: Any new news?
20:22:03 <nirik> well, yeah, but src is different for groups... but anyhow
20:22:07 <michel> carlwgeorge: I forgot to test the new repo but I can do that now if needed
20:22:45 <carlwgeorge> #info epel next open for testing https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/6VAHYUU3Z7DYG6W6UBYRN3QSCDOG73TM/
20:22:58 <tdawson> Ya!!
20:23:08 <nirik> cool
20:23:17 <tdawson> How long do we plan on testing it?
20:23:20 * michel installing now
20:23:24 <carlwgeorge> i figured a few weeks
20:23:26 <michel> if I get disconnected blame carl
20:23:28 * dcavalca already added it to the internal repo slate
20:23:59 <carlwgeorge> i'd love help from people in the kde sig to request epel8-next branches
20:24:07 <tdawson> I just got my last qt5 branches, so that will give me time to get at least the qt5 updates in there.
20:24:37 <carlwgeorge> i've been doing a few scratch builds, and cherry-picking cmake fixes from rawhide to epel8 branches so they're ready (would be needed anyways since 8.4 for regular epel8 builds)
20:25:29 <carlwgeorge> in related news, the fedpkg pr was finally merged upstream https://pagure.io/fedpkg/pull-request/429 (we weren't waiting for it, but good to see)
20:25:30 <tdawson> carlwgeorge: I've got a little script for the kde branches, now that I have all my qt5 branches, I'm going to do the other 350
20:25:41 <tdawson> Ya!!
20:26:37 <michel> doesn't break anything but some Qt packages are still missing right now
20:27:17 <michel> tdawson: woot!
20:27:35 <michel> ps my use case is I have the nextcloud client installed
20:27:53 * pgreco updates epel-release and sees epel-next-release being pulled :D
20:27:56 <michel> if this is ready for others to contribute to, I can see about branching the right packages
20:28:11 <tdawson> nextcloud uses qt5 ?
20:28:19 <michel> tdawson: yup
20:28:20 <carlwgeorge> yes please, request branches
20:28:37 <nirik> the desktop client I assume?
20:28:50 <michel> the desktop client
20:28:52 <carlwgeorge> also please let me know if https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow is missing any steps
20:28:56 <tdawson> Huh ... well, I got the branches litterally minutes ago, and I plan on doing the builds this evening ... hopefully by tomorrow we'll have it in -testing
20:29:44 <michel> tdawson: is epel-packagers-sig in the ACL or just you? but I can wait until tomorrow, let's not step on each other's toes
20:30:05 <tdawson> michel: It's the kde-sig that's in the ACL, of which I'm a part of.
20:31:02 <michel> ah. I might want to join that. hm, would nextcloud-client be in scope as it's a Qt,not KDE app?
20:31:12 <tdawson> carlwgeorge: I use fedpkg instead of git  (fedpkg switch-branch epel8-next, fedpkg merge, fedpkg push)
20:31:37 <pgreco> .whoowns qt5-qtenginio
20:31:37 <michel> I can ask nextcloud-client to be branched, since it will need to be rebuilt
20:31:38 <zodbot> pgreco: owner: rdieter; admin: lupinix
20:32:02 <pgreco> carlwgeorge: that's another one that needs to be rebuilt for epel-next
20:32:13 <tdawson> michel: if rex is the owner, I'd say it's a kde thing.
20:32:18 <carlwgeorge> yeah i've got a big list from repoclosure
20:32:28 <pgreco> great
20:32:36 <michel> .whoowns nextcloud-client
20:32:38 <zodbot> michel: owner: germano; admin: nonamedotc; commit: taaem
20:32:42 <pgreco> that's the only one that was failing in my wife's laptop
20:32:47 <michel> it's germano, nonamedotc and taaem
20:32:56 <carlwgeorge> i blame Eighth_Doctor, he's the one that asked for qt to be rebased
20:33:19 <pgreco> blaiming Eighth_Doctor is always a good way to go
20:33:46 <michel> Conan Kudo: move fast and break things :p
20:33:53 <Eighth_Doctor> ....
20:33:57 <Eighth_Doctor> I hate you so much now 😛
20:34:24 <nirik> 🕺
20:34:57 <tdawson> Oh, I've already done qt5-qtenginio ... but I haven't done the update yet, I was going to do all the qt5 updates on one update... which, maybe wasn't the best idea, but saves me from having hundreds of updates at once.
20:35:08 <Eighth_Doctor> there are probably people who do really think I think like that too...
20:35:15 <tdawson> Anyway, qt5 packages should be in -testing by tomorrow, hopefully.
20:35:15 <carlwgeorge> between qt in 8.5 and cmake in 8.4, nothing but love for Eighth_Doctor's work
20:35:23 <tdawson> *laughs*
20:36:09 * Eighth_Doctor wonders when he started to care about things in RHEL so much...
20:36:10 <tdawson> Anyway, anything else for -next ?
20:36:28 <carlwgeorge> nope, we can move on
20:36:37 <tdawson> OK, moving on.
20:36:46 <tdawson> Badges and Logos
20:36:47 <Eighth_Doctor> any idea when we'll have it for cs9?
20:37:07 <tdawson> Issues opened for both
20:37:09 <carlwgeorge> i plan to start epel9-next as soon as we're "done" with epel8-next
20:37:17 <tdawson> epel commitee badge - https://pagure.io/fedora-badges/issue/829
20:37:20 <carlwgeorge> i.e. pushed to stable and announced
20:37:30 <tdawson> epel logo - https://pagure.io/design/issue/770
20:37:39 <Eighth_Doctor> 👍️
20:38:05 <michel> ooo badge!
20:38:06 <carlwgeorge> https://pagure.io/design/issue/770#comment-737519 is the one you want :D
20:38:08 <tdawson> The centaur might get pushed to be a mascot instead of a logo
20:38:37 <michel> I filed https://bugzilla.redhat.com/show_bug.cgi?id=1972910 for nextcloud-client, please correct me if I wrote anything wrong in the description
20:39:23 <michel> I like the ants. Look like... Space Ants with MBAs
20:39:30 <carlwgeorge> nextcloud-client is blocked by qt5-qtwebengine and kf5-kxmlgui, according to my scratch builds
20:40:31 <tdawson> michel: Just curious why you didn't just ask the maintainer to branch and build it on epel8-next, looks like they are quite responsive.
20:40:51 <tdawson> They've updated the package twice this year in epel8.
20:40:57 <michel> I can do that
20:41:03 <michel> are the dependencies ready?
20:41:24 <carlwgeorge> nope
20:41:56 <tdawson> Actually, yes they are, I have all the qt5 packages I've built in override
20:42:02 <carlwgeorge> neat
20:42:05 <michel> aha
20:42:16 <tdawson> And looking at it's dependencies, it doesn't need any of the missing ones.
20:42:58 <tdawson> Anyway, back to badges and logo's.  If anyone has any ideas or comments, feel free to put them on the issues.
20:43:39 <tdawson> We're getting low on time, I'm going to run through the usual topics.
20:43:45 <tdawson> #topic EPEL-7
20:43:53 <tdawson> Anything for epel7?
20:44:03 <pgreco> I think carlwgeorge solved the only thing I had
20:44:15 <carlwgeorge> yeah i retired pidgin-epel
20:44:41 <carlwgeorge> #info retired pidgin-epel from epel7 https://bugzilla.redhat.com/show_bug.cgi?id=1972323
20:44:52 <nirik> glad we don't need it anymore
20:45:02 <carlwgeorge> haven't since 7.3 lol
20:45:37 <tdawson> Yep, just that nobody noticed.
20:45:57 <tdawson> #topic EPEL-8
20:46:05 <tdawson> Anything for epel 8?
20:46:33 <carlwgeorge> i'm sure there a bunch of those, where the rhel maintainer set the version-release higher, but there is potential for issues if the epel package is upgraded
20:47:11 <michel> wait... what's the context?
20:47:22 <michel> once a package is in RHEL we're supposed to retire it from EPEL, right?
20:47:35 <carlwgeorge> correct, by policy
20:47:47 <tdawson> And technically, pidgin was retired
20:47:58 <pgreco> but sometimes the retire package has higher ENVR than the one included in RHEL
20:48:14 <pgreco> and that creates "issues"
20:48:24 <nirik> well, that was a different case... that was pidgeon-epel
20:48:25 <tdawson> But we created a pidgin-epel, because the pidgin in RHEL didn't really have "pidgin" the binary.
20:48:33 <nirik> it was missing some libs
20:48:38 <nirik> (I thought)
20:48:48 <carlwgeorge> the rhel package was just libpurple
20:48:49 <michel> pgreco: ah
20:49:04 <michel> Stream will hopefully make that easier, less opacity
20:49:05 <carlwgeorge> until 7.3 when the rest of the subpackages were added
20:49:20 <michel> hm, though we still won't know which get pulled into the stable releases
20:49:56 <Eighth_Doctor> it amazes me how schizoid RHEL is at times
20:50:43 <tdawson> Ya ... I'm not even going to comment on that cuz it gives me a headache.
20:51:00 <tdawson> Anyway, sounds like there aren't any epel8 stuff, so moving on to ...
20:51:06 <tdawson> #topic General Issues / Open Floor
20:51:34 <nirik> I wanted to bring up a epel-release bug and ask folks to add comments to it if they care to:
20:51:50 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1969500
20:52:13 <tdawson> I looked at that.  I'm for changing it to just 8
20:52:16 <nirik> basically people setting releasever to 8.4 or whatever breaks epel
20:52:38 <nirik> we could do that, or we could make the minor numbers go to the archive for that release...
20:52:39 <carlwgeorge> i'm against changing it to just 8
20:52:41 <tdawson> I think the archived 8.1, 8.2, etc ... should be a seperate issue to discuss and figure out
20:53:01 <carlwgeorge> when someone locks to an old minor release, not every epel8 package will install
20:53:11 <Eighth_Doctor> this is a bad idea
20:53:20 <nirik> right, and no updates security or otherwise
20:53:38 <carlwgeorge> i'm in favor of nirik's suggestion of adding the snapshotted epel8 archives to mirrormanager, to respond with compatible packages
20:53:41 <Eighth_Doctor> we deliberately switched to $releasever because of the minor version based snapshots
20:53:49 <michel> old minor releases get security updates for RHEL only, right?
20:53:55 <Eighth_Doctor> yeah, EPEL is frozen
20:54:14 <carlwgeorge> michel: if and only if you're using eus proper, not a local frozen snapshot
20:54:14 <michel> ah. EPEL also got snapshotted?
20:54:33 <carlwgeorge> indeed https://dl.fedoraproject.org/pub/archive/epel/
20:54:50 <nirik> yeah, it's a tradeoff for someone who sets it to say 8.2... they would get packages that would work with 8.2, but not the latest.
20:55:02 <carlwgeorge> just today i noticed some directory snafu with the 8.3 archive, and mboddu got it fixed quickly https://pagure.io/fedora-infrastructure/issue/10041
20:55:12 <pgreco> and also keeping the $releasever may be useful to "downgrade from snapshot" testing
20:55:42 <nirik> I worry that they would expect epel to behave just like rhel there tho... keep updating things in the y stream
20:56:07 <carlwgeorge> that seems like a lesser problem than "this won't install"
20:56:15 <nirik> it can't be affecting too many people... this is the first bug I have ever seen on it. ;)
20:56:43 <carlwgeorge> i checked with my old work, where i deployed rhui right before i left.  they have seen it too, just never complained.
20:56:48 <Eighth_Doctor> people being on old point releases basically should suffer for their sins
20:56:49 <tdawson> That's what I worry about to.  People start thinking that we build things for 8.2, 8.3 and so forth, when we don't.
20:57:00 <carlwgeorge> thankfully they finally stopped defaulting customers to eus and leaving them there until they complained
20:57:42 <nirik> Eighth_Doctor++ :)
20:57:47 <carlwgeorge> i prioritize uninstallable packages over "why isn't this getting updates anymore", but that's just my opinion
20:57:52 <pgreco> symlink to 8 is not an option?
20:58:05 <pgreco> if someone wants the snapshot, they should manually select it
20:58:22 <pgreco> maybe it won't install, but it won't be outdated by definition
20:58:51 <carlwgeorge> that is the question at hand, if they override their releasever to an old minor instead of just 8, do they get current epel (some uninstallable packages) or snapshoted epel at the minor they asked for
20:59:33 <pgreco> I'd go for current (and maybe failing) packages
20:59:37 <nirik> pgreco: you mean alias 8 and 8.4 to current... and snapshots to older?
21:00:03 <pgreco> I'd symlink anything to current
21:00:04 <carlwgeorge> right, 8.4 has no snapshot, so that should be a symlink to 8
21:00:12 <pgreco> if you want the snapshot, get it manually
21:00:35 <pgreco> but for older releases I'm torn
21:00:37 <nirik> but then you need to edit repo files and hardcode the snapshot ?
21:00:44 <pgreco> yes
21:01:01 <nirik> thats kind of a pain if you just want one or a few things from it.
21:01:41 <pgreco> I'm not sure what's best, tbf, but I don't like the idea of transparently offering something outdated
21:01:48 <carlwgeorge> i say we think about it for a week, and vote then
21:01:55 <michel> on the Fedora side.. we make people who insist on old releases jump through hoops, right?
21:01:59 <michel> to switch to the archive repo
21:01:59 <nirik> folks can add their thoughts to the bug also
21:02:06 <nirik> michel: nope
21:02:23 <tdawson> michel: No, if you stay on fedora 15, you still have access to all of Fedora 15, no change necessary.
21:02:28 <carlwgeorge> mirrormanager returns the thing you ask for, even if it's old
21:02:29 <nirik> I think CentOS does, but fedora just has mirrormanager send them to archive
21:02:37 <tdawson> Don't know why I picked 15 ... it's 14 that I have a machine on.
21:02:46 <Eighth_Doctor> MirrorManager is awesome like that
21:02:47 <michel> oh huh, didn't realize mirrormanager does that
21:02:51 <Eighth_Doctor> I wish CentOS used it
21:02:56 * michel built some archive-handling code for nothing
21:02:56 <Eighth_Doctor> it would make my life so much easier
21:02:58 <carlwgeorge> trying for 9
21:03:01 <tdawson> Oh ... just looked at the time
21:03:17 <tdawson> Yep, let's think/talk about this during the week, and get back for a vote next week.
21:03:28 <nirik> +1
21:03:36 <pgreco> yeah
21:03:43 <pgreco> see you next week, thanks tdawson
21:03:46 <tdawson> Thanks to everyone for coming, and for the good discussions.
21:03:54 <tdawson> #endmeeting