Hi Philippe, Hi Leif,
On 2018.12.14 16:36, Leif Lindholm wrote:
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?
That's one way to do it. As I indicated, as soon as ATF creates a 2.1
tagged release, I will look into removing the binary blobs from non-osi.
However I am not planning to do that sooner. As a matter of fact, given
that this is not a blocking issue and given the scope of what still
needs to be addressed for RPi3 integration, I am kind of hoping we won't
see an ATF release for another month or two, so that we can get through
the current integration process, with the current binary blobs in
non-osi, and then sort out their removal post integration.
Personally, I also expect that anybody who wants to build the binaries
locally, can simply be directed to follow the official ATF build notes
on how to set up their tool chain, and then refer to the build
parameters from our readme. But then again, if we have a nice Docker
solution to provide, I don't see why we shouldn't also point to it.
On the other hand, when it comes to providing trustworthy links, and
since there exists a MinGW32 version of the Linaro GCC compilers, I'd
much rather use AppVeyor for automated build of ATF binaries. The nice
thing is that AppVeyor can keep and serve its build artefacts, so we'd
be able to directly link to those, which should give some level of trust
that the binaries haven't been tampered with by the owner of the repo
(or at least that, if they have, the source would reflect it). And you
can also easily configure AppVeyor to only build on tagged commits,
which I think is what we want.
At any rate, I think there exists more than one solution to address the
ATF binary provision problem for RPi3, while also not having to ask
users to blindly trust any binaries we might link to. Maybe Docker or
AppVeyor are what we want to use. Maybe there is yet another option on
the table that we haven't talked about yet.
If we believe this is necessary, I can look into adding AppVeyor builds
of the official ATF ASAP. But for the time being, I would prefer if we
start discussing this in earnest once ATF 2.1 has been tagged for
release, and I send a formal proposal to address the removal of the
non-osi ATF binaries.
Regards,
/Pete
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
