Bug 2057005

Why? What components of U-Boot do you want built of U-Boot, who is going to maintain it?

I just need uboot-tools (specifically mkimage right now, and possibly a few of the other tools down the road), not U-Boot proper. We use it as part of the update flow for a BMC, among other things. Happy to maintain it for EPEL if you'd like, both individually and as part of the EPEL Packagers SIG. I just noticed this needs python3-libfdt to build, which is currently unshipped, so I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2057180 to get that added.

It's a common occurrence that a package's Fedora maintainer does not care about EPEL; in this case it looks like Dan Horak is already marked as the EPEL maintainer anyway (but there's no EPEL build at all, curiously).

The SIG definitely can co-maintain this package - this is similar to how many Python and Rust packages are co-maintained by the respective SIGs, though with a focus on EPEL branches (if you want to make sure the EPEL Packagers SIG members don't interfere with the Fedora branches, granting them collaborator access to epel* ensures this, and we can then file PRs if we need something merge). We discuss our issues in the weekly EPEL meeting on Wednesdays.

see https://docs.fedoraproject.org/en-US/epel/epel-packagers-sig/ for reference

I think my name for EPEL is an historical relic from some plans to have uboot-tools in EPEL-7 or EPEL-8 :-) I have no objections to make the tools available in EPEL-9.

TBH I don't particularly either. They provide less value TBH if the system was EBBR compliant because it would just boot like any other device and the requirement for mkimage becomes a lot less (eg we no longer ship them by default at all in Fedora arm). But if it's just a random release of the tools I'll put the pieces in place for that shortly in rawhide and will build it once 2022.04 goes GA in ~ 2 weeks.

FTR, I'd prefer to see a full build of U-Boot in EPEL 8/9 so that SIGs like Hyperscale, Automotive, and others who may want to build ARM images with U-Boot stuff can do so. The image building tools I maintain in EPEL can use it if it's available, for example.

(In reply to Neal Gompa from comment #6)
> FTR, I'd prefer to see a full build of U-Boot in EPEL 8/9 so that SIGs like
> Hyperscale, Automotive, and others who may want to build ARM images with
> U-Boot stuff can do so. The image building tools I maintain in EPEL can use
> it if it's available, for example.

Why? This makes no sense.

1) The standard RHEL kernel doesn't support SystemReady IR devices so we're providing firmware that they can't actually use out of the box
2) Automotive will use UEFI and specific devices so they will need to provide their own firmware
3) Hyperscalers and others will no doubt provide their own firmware and are unlikely to actually use these builds for the devices we provide.

And the request above is for mkimage to be able to produce uImage and friends kernels which from my understanding is foe when they generate images for OpenBMC images which are generally Yocto images running on either ARMv6 or ARMv7 hardware. So even the above request for tools is no even for typical RHEL use cases, and we've not made active use of the tools package in Fedora since about Fedora 17.

(In reply to Peter Robinson from comment #7)
> (In reply to Neal Gompa from comment #6)
> > FTR, I'd prefer to see a full build of U-Boot in EPEL 8/9 so that SIGs like
> > Hyperscale, Automotive, and others who may want to build ARM images with
> > U-Boot stuff can do so. The image building tools I maintain in EPEL can use
> > it if it's available, for example.
> 
> Why? This makes no sense.
> 
> 1) The standard RHEL kernel doesn't support SystemReady IR devices so we're
> providing firmware that they can't actually use out of the box
> 2) Automotive will use UEFI and specific devices so they will need to
> provide their own firmware
> 3) Hyperscalers and others will no doubt provide their own firmware and are
> unlikely to actually use these builds for the devices we provide.
> 

U-Boot can provide a UEFI environment for devices that don't offer it themselves, so it's still useful in that context.

The Hyperscale SIG will not be providing its own firmware, as we use commodity stuff that typically has enablement in Fedora. The goal is to use upstreamed stuff, not special stuff.

> And the request above is for mkimage to be able to produce uImage and
> friends kernels which from my understanding is foe when they generate images
> for OpenBMC images which are generally Yocto images running on either ARMv6
> or ARMv7 hardware. So even the above request for tools is no even for
> typical RHEL use cases, and we've not made active use of the tools package
> in Fedora since about Fedora 17.

This stuff is also used on AArch64-class hardware too for similar reasons.

Will you be able to branch and build uboot-tools in epel9?
The EPEL Packagers SIG would be happy to be a co-maintainer
if you do not wish to build it on epel9.

(In reply to Davide Cavalca from comment #9)
> Will you be able to branch and build uboot-tools in epel9?
> The EPEL Packagers SIG would be happy to be a co-maintainer
> if you do not wish to build it on epel9.

Still blocking on the lack of a dependent package when I tried a scratch build the other day.

Looks like we need one more dependency in https://bugzilla.redhat.com/show_bug.cgi?id=2143981 but once that's sorted out this should be good to go.

(In reply to Davide Cavalca from comment #11)
> Looks like we need one more dependency in
> https://bugzilla.redhat.com/show_bug.cgi?id=2143981 but once that's sorted
> out this should be good to go.

That dependency is not needed just for the tools.

FEDORA-EPEL-2022-ed4f363862 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ed4f363862

FEDORA-EPEL-2022-ed4f363862 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ed4f363862

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2022-ed4f363862 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.