The ELNBuildSync automation currently has exceptions to not attempt to build the packages
grub2
fwupd
fwupd-efi
pesign
This is due to the fact that these packages, being part of the "secure boot" chain, are built in a special channel in Koji, restricted to a limited set of packagers. The problem we have is that this also means that if those packagers do not manually build these packages for ELN, the versions we are carrying often lag quite far behind.
We previously attempted to address this by modifying fedpkg to allow the use of package.cfg files to trigger a build for ELN when the package was manually built for Rawhide, however this is not working for unknown reasons. (It works when I attempt it - without secure boot privileges - but it does not trigger the ELN build for the real maintainers who do have those privileges.)
fedpkg
package.cfg
We would like to request that the FAS account distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org be granted the necessary privileges to build in the secure boot channel. Once that is done, we will amend the configuration to not ignore the packages listed above. They will be automatically rebuilt any time that the Rawhide package reaches the stable tag.
distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org
The sooner, the better.
If the Fedora Project ever ceases to sign packages for secure boot.
The status quo is maintained, wherein the ELN maintainers need to constantly keep watch over these packages and bother the maintainers to manually trigger builds for ELN.
CC @yselkowitz @rhughes @nfrayer
Sounds good, ack from me in case that was needed.
Metadata Update from @phsmoura: - Issue tagged with: low-trouble, medium-gain
@kevin @phsmoura what is needed to move this forward?
I was hoping to get an ack from @pjones I can try and ask him tomorrow...
ping @kevin @pjones
fwupd in ELN continues to fall behind rawhide without automation in place.
ok. I haven't been able to get an ack on this, but I can't imagine why it would be bad.
So, I have added the permission to it, and if someone finds that that is bad for some reason, please let me know and I can revoke it.
Let me know if you need anything further here or if we can close this now?
@sgallagh, do you think changes made by @kevin fixed the issue? If yes, can we close this ticket?
I've been on PTO for the last four days.
It looks like https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync-config/-/blob/main/distrobaker.yaml hasn't yet been updated to remove the secureboot packages from the exclusion list, so I don't think this has actually been attempted yet.
I'll get that adjusted and we'll keep an eye on things for the next updates to those packages.
This is working and can be closed.
Metadata Update from @kevin: - Issue close_status updated to: Fixed with Explanation - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.