@humaton you were already working on this?

Heh, I was just looking at 3.7.0 and here you go with 3.8.0 I will build it.

I had to bump the release because one of the changelog entries was preventing epel7 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=95084321

We ran into some dep problems I think, so @dherrera was going to look into moving this into openshift. It would be easier to manage there for sure.

I was able to build 3.8.0 on el7

First had to fix the spec file a bit because some dependencies were missing, I also fixed the python2 filter considering that el8 and el9 work with py3 just fine. We made the changes on the infra branch but I left a PR open with the fixes on the main branch JIC

Also there were a couple of problems that arrised when building this specifically with the epel7-infra tag:
- the libmodulemd lib packaged in epel7-infra-build is older than the one in rhel7-rhel-extras, which conflicts with some deps (python2-hawkey, python2-libdnf and libdnf)
- the openstack repo that is used on the epel7-infra provides a version of python-twisted that doesn't build because of a missing dependency (python-service-identity)
Both are already resolved btw.

I also researched what we needed for mbs to work on el8 and el9.

EL8

There are a few python dependencies needed that could be packaged on EPEL. Specifically python-funcsigs and python-fedmsg.

python-fedmsg needs python-vcrpy and python-boto (which the maintainer deprecated it), but since they are just testing stuff, it's an option to get that stuff patched out on python-fedmsg for EPEL8, fixing them would be preferable.

EL9

This is a bit tricky because there are 30+ dependencies needed for it to build. I was able to build it in COPR with not many problems. Some of the dependencies built right away and most of them built after adding the proper dependencies.

One of the problems I noticed is that some of the dependencies need the python-mock package, which is deprecated since the implementation of it was integrated in python since 3.6. Dealing with it shouldn't be hard, but there are 9+ packages depending on it.

Another thing I noticed is that the python3-attrs version that was packaged couldn't satisfy twisted dependencies... I had to update it for the package to actually build correctly... so that's something that needs to be fixed.

I also made a diagram that shows which dependencies are needed by which package, it's a bit of spaghetti, but it's expected with so many dependencies needed. Regarding the colors I used for the packages, the red one is python-mock and the orange ones are the packages that depend on it. I marked the pytest ones on blue and the ones that depend on them in light blue since they are testing dependencies. Green ones are the ones that can get packaged right away since they don't need any dependency for them to just work.

@torsava is there anybody who could possibly help with this?

Hey Diego. Thanks for working on this! and great detective work on epel7-infra finding those tag issues.

I'd love to move mbs to rhel9 (and fedora-messaging!) but I understand it can be a long haul, but if we chip away at it we can get there.

In the mean time I think the next step is to update our staging infra with the epel7-infra package, do some testing/checking and then schedule a time to upgrade production.
(likely after beta freeze)

I've been working on getting this updated to EPEL8 since I noticed that fedmsg was updated to 1.1.6.

After researching for a while on how python-vcrpy works, I noticed that the python-boto requirement can simply get removed from the specfile and the package will build without problems, so I took care to submit it and now is waiting to get into EPEL8 [0]. This is the only dependency left that was needed forfedmsg, so fedmsg can get packaged into EPEL8 without any changes as soon as that is finished.

I also checked about getting thepython3-funcsigs and I noticed that its an unneeded dependency for mbs since its there just to backport the functionality for python < 3.3 [1]. It makes sense for this to be available on EPEL7 that runs python2, but not for EPEL8 that runs a newer version of python3. I added this patch to my former mbs PR to remove the dependency [2].

Considering that bothpython-vcrpy and fedmsg get packaged into EPEL8, It should be straightforward to get mbs 3.8.0 there too [3].

[0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0c9e522b34
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1758822#c1
[2] https://src.fedoraproject.org/rpms/module-build-service/pull-request/8
[3] https://copr.fedorainfracloud.org/coprs/dherrera/mbs-epel8/builds/

We have this built in epel7-infra now. Should we upgrade? Any problems just doing so? or things we need to change?

@breilly ^

Just to give an update on this issue, fedmsg is in progress to getting into EPEL8 [0] (thx @zlopez for helping with the testing certs issues). After that sets in, getting mbs 3.8.0 to build into EPEL8 should be straightforward.

Also, after @kevin mentioned me that EPEL7-infra version of mbs wasn't installing cos of a dependency problem (python-packaging if I recall correctly) ... I noticed that I was actually forgetting to test installation too. Checked EPEL8 version of mbs locally in a container and noticed it actually had problems with some deps, but also noticed that those deps weren't really needed and were actually removed from upstream [1]. I added those changes to my mbs PR [2].

[0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8e729603b6
[1] https://pagure.io/fm-orchestrator/pull-request/1769
[2] https://src.fedoraproject.org/rpms/module-build-service/pull-request/8

Update: The mbs package was updated to 3.9.2, which integrates the patches that were required to build mbs on epel8. The maintainer also merged the required packaging changes [0], so we only need to wait for him to branch the package for epel8 to be able to run that version.

[0] https://src.fedoraproject.org/rpms/module-build-service/pull-request/10

Apologies, missed the earlier ping - will this be deployed on RHEL 7 or 8?

3.8.0 should be okay to upgrade in RHEL 7; there were minimal changes from 3.6.1 for the infra environment, due to the backport patches that were already deployed (and I assume were removed for the build). I was not aware of the dependency issue, but I can help investigate if needed.

If deploying on RHEL 8, 3.8.0 requires a patch - this patch is integrated into 3.9.2. If releasing 3.9.2 on RHEL 7, it would require a revert patch, which I'm finalizing now and can provide soon.

@breilly Would it be ok to upgrade our EPEL7 instance running 3.6.1 directly to an EPEL8 instance running 3.9.2?

As long as the instance is RHEL 8 / has python 3 available, that should be fine. I'll work on getting the EPEL 8 branch set up for MBS.

MBS is built for EPEL 8, currently in Bodhi updates.

While checking on some related things I noticed that on my last patches on MBS for EPEL8 I forgot to remove a runtime dependency. I already sent a patch that got merged, but well have to wait for it to go through updates for this to work.

Ping, any update here, please?

It's been hard for me to move this up the priority list, since we are not doing modules for new releases anymore.

Is this still worth doing?

For me this is the feature I am interested in. Since I hope that "Fedora first" is still the think, I'd be happy to see this in Fedora. And I would hope that this will help to have the updates smoother on other places such as CentOS.

ok. I'll see about doing this after beta freeze if I can.

I'm not sure I see 'Fedora First' connecting with installing a buildsystem we are going to retire on rhel8 which has been released for years, but ok...

[backlog_refinement]
As the end of MBS is near (it will be retired after F38 EOL) it doesn't make much sense to update it. But let's keep it open for now if anybody wants to work on that.