Description of problem: From the uboot-tools package we use mkimage to create uboot files. This package is available in Fedora but not in rhel8. https://rpmfind.net/linux/RPM/fedora/updates/testing/31/x86_64/Packages/u/uboot-tools-2019.10-0.3.rc3.fc31.x86_64.html Requesting uboot-tools in EPEL 8 Version-Release number of selected component (if applicable): EPEL 8 Actual results: uboot-tools is only available for Fedora and in RHEL 6 EPEL Expected results: uboot-tools available for EPEL 8 Additional info: This was also requested for EPEL 7 which did not get resolved. https://bugzilla.redhat.com/show_bug.cgi?id=1155029
Why is it needed for el8?
It was requested for mkimage to create uboot files.
What uboot-tools features are required? If FIT support is required then it will also require DTC, currently available from rhel-8-server-codeready-builder-rpms, only. Is FIT signature verification support required?
Hi, I do not have a list of features, just that they are currently using: u-boot-mkimage-v2013.07+git0+62c175fbb8-r0.0.x86_64 regarding FIT, not, it is not required Thank you
Hi Carlos, Are we any further forward with this request? Thanks Sam
(In reply to Sam Wachira from comment #5) > Hi Carlos, > > Are we any further forward with this request? > > Thanks > > Sam As we already discussed offline, no progress so far but I don't believe that uboot-tools will be accepted as a RHEL package.
(In reply to jcastran from comment #2) > It was requested for mkimage to create uboot files. All modern U-Boot and devices use distro boot which uses standard OOTB kernel/initramfs files so there should be no need to use mkimage to create U-Boot files, Fedora hasn't used that portion of U-Boot for some time. For aarch64 we even use grub2/shim so again there's no need to do that. Why is it needed in EPEL, who is going to support/maintain it in EPEL?
Hi Peter, Use case is a customer using /usr/bin/mkimage to create images for ppc and arm boards. mkimage is currently available on Fedora from uboot-tools.x86_64 package. The request is for mkimage to be available from EPEL for use with RHEL. It is understood that no support applies for any EPEL packages and that is fine. Since uboot-tools.x86_64 package is available on Fedora, who currently supports and maintains it? Sam
> Use case is a customer using /usr/bin/mkimage to create images for ppc and > arm boards. > mkimage is currently available on Fedora from uboot-tools.x86_64 package. Why aren't they using distro-boot and hence there is no need to wrap kernel/initramfs using mkimage. > Since uboot-tools.x86_64 package is available on Fedora, who currently > supports and maintains it? I do, I have no time or interest in doing it for EPEL-8 for the next decade.
Hi Peter, > Why aren't they using distro-boot and hence there is no need to wrap kernel/initramfs using mkimage. Distro boot was suggested to the customer. However, they confirmed it is not applicable to their use case as their boards don't have local storage. > I do, I have no time or interest in doing it for EPEL-8 for the next decade. Would you be willing to formalise this response in a way that can be shared with the customer?
(In reply to Sam Wachira from comment #10) > Hi Peter, > > > Why aren't they using distro-boot and hence there is no need to wrap kernel/initramfs using mkimage. > Distro boot was suggested to the customer. However, they confirmed it is not > applicable to their use case as their boards don't have local storage. > > > I do, I have no time or interest in doing it for EPEL-8 for the next decade. > Would you be willing to formalise this response in a way that can be shared > with the customer? I will work with you Sam to provide a PM Message based on the engineering position.
Providing NACK and closing bz. Provided formal response to customer. Fedora maintainers for the uboot tooling (including mkimage) cannot provide any guarantees around ongoing support and maintenance of the uboot packages. Red Hat will not pull packages into EPEL or RHEL that lack strong upstream/Fedora support, maintenance, and testing. At this point, there is not enough confidence that Red Hat can provide an acceptable experience without significant ongoing risk for these packages, and will not be able to provide them. The source for uboot-tools is available from upstream via its GitLab page: https://gitlab.denx.de/u-boot/u-boot. Red Hat has been unable to determine alternative approaches to the requested functionality.