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*?!? > 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? 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. 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. 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-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/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
