> Bringing this subthread to devel@ since apparently this has a wide impact... > > On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-create-images > > > > The points you make here are completely orthogonal to tow-boot or > > upstream U-Boot, we make generic images for all our deliverables and > > while there's separate scripts at the moment there will not be once > > the Mobility initiative is fully upstreamed into Fedora. > > > > Fedora doesn't use livemedia-creator for it's arm images currently so > > Neal (AKA Conan Kudo) is wrong. It currently uses image-factory and > > will be migrating to ImageBuilder before the Mobility images become > > official so yes, you've misunderstood due to the incorrect information > > provided to you. > > > > Say *what*?!? All the arm images use ImageBuilder, they always have. Not sure what you mean by "what" here. > > Someone will have to do the work to add a plymouth OSK of some sort, > > with the work my team is doing for Edge/IoT the encryption problem is > > solved when we move to ImageBuilder, we expect the first pieces of > > that to land for Fedora IoT in F-37 and I'll be working to move all > > Fedora deliverables over to that so Mobility will be able to just > > consume that work, > > Okay, this whole idea of moving everything to Image Builder is news to > me. There's been *zero* discussion, preparation, or consultation with > literally *anyone* over this. You *do* know that people other than you > have to work with this stuff too, right? Did you (or whoever decided > we're doing this) talk to any of the WGs or SIGs about this plan? What > about feature parity? And what about teaching people to be able to > work with it? Not everything is moving to ImageBuilder for F-37, actually just IoT will be and it's been discussed there but I've never seen you there so maybe you missed it. It's a nicely contained compose where we can sort out all the problems with it without impacting the main compose and desktop deliverables. Once we know how the service looks there will be proposals to move other artifacts over but that won't be until "feature parity", and in the case of ImageFactory frankly that won't be hard. > I'm involved in two desktop SIGs/WGs and the Cloud SIG/WG, and I had > *no* idea you were planning this. I would expect at *least* a heads up > and some reference of how things are going to work so we can get > familiar with it. Well ATM it's not planned for anything outside of IoT and once we know that's going to work there will be a Fedora Change proposal for IoT so it will be following the appropriate process. > In principle, I welcome having better image build tooling if it means > that it's easier for us to work with it, but such changes are not done > unilaterally, especially if you want others to be able to help and > work with these. You've completely miss interpreted what I wrote, believe me it will be *SO* much better. > I know you've complained about being the only person working on stuff, > but I can say that one aspect of why you are the only one is because > the tooling is a royal pain to use now. Which is why I have been working with Matthew Miller, CPE and the ImageBuilder team to get the pieces in place so we can start to move over to tooling that is actively maintained and developed. Due to my available time, and the fact that I mostly care about IoT we're focusing on that to ensure that it can provide the key functionality, but as somehow being the person being the oz/ImageFactory maintainer I am well aware of the functionality it provided and will be ensuring it provides all that so we can EOL the old tools. > I personally don't use ImageFactory with the ARM kickstarts, even > though ImageFactory is what we use to produce the images. That's > because ImageFactory crashes on my computer and is basically unusable. > > Anyway, since I know now... I'm looking forward to your Change > proposal and accompanying documentation. It will have a Change Proposal, starting with IoT. It's fully planned to follow the full Fedora process. As stated above it will start with IoT where we can deal with it in a contained manner. In the case of Mobility we're some way off from being able to provide anything official so in that context it would make sense to go with that tooling from the outset. We (the RHEL for Edge team in Red Hat) are working on things like producing images in ImageBuilder that are "encrypted" with a null cypher able to be re-encrypted on first boot so it makes sense to just consume that for Mobility functionality. We will be using that in Fedora IoT (yes, there will be changes for that too, I like marketing). So please don't get your knickers in a knot, things are happening with regards to lovely enhancements to available services for infrastructure but rest assured when they are available they will be announced and when they change Fedora deliverables there will be proper change process followed. P _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
