On Fri, Dec 14, 2018 at 05:14:05PM +0100, Philippe Mathieu-Daudé wrote: > >> I can certainly upload binary releases for the required ATF files in my > >> github clone of ATF, and then add links to that in the readme with the > >> instructions on how to rebuild ATF. > >> > >> However, I'd rather wait to do that until there has been an official tagged > >> new release for ATF (which would be 2.1 at this stage, since our changes > >> have been applied after 2.0), as it'll look better for Pi users to see an > >> initial ATF serial output that says "BL<#>: v2.1(release)" instead of the > >> current "BL<#>: v2.0(release):v2.0-278-gc3859557" > >> > >> How about this then: If ATF produces a formal release before this proposal > >> is integrated, I'll amend it to remove the ATF binary blobs and apply the > >> suggestion above, with the Atf/ build/link data moved out of non-osi. But > >> if > >> they don't, I'll keep the proposal for ATF as is, and then submit a patch > >> to > >> remove the non-osi data and apply the above at a later date, once there has > >> been a new ATF release. > > > > Yeah, this certainly works for me. > > I setup this Dockerfile [1] to have reproducible builds and avoid to > store those binaries in the non-osi repository, what do you think about > this approach?
Get off my lawn? :) > [1] available here: > https://gitlab.com/philmd/edk2-platforms/blob/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile I think it's a good thing to have, especially for something like the Pi. I guess if that exists, we can trust people who prefer not to use containers to be happy to follow the Readme, or grab binaries from Pete's github? / Leif _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
