raspberrypi-firmware: Resort to github APIs for tarballs #1298
Conversation
kraj
changed the title
|
I think the previous firmware update broke picamera-libs: I don't use picamera-libs nor python3-picamera (which depends on picamera-libs), aren't they replaced by libcamera stuff? |
|
I think picamera should be replaced with https://github.com/raspberrypi/picamera2 since it supports 64bit as well as 32bit, unlike picamera which only works with precompiled userland VC drivers and 32bit only. |
Signed-off-by: Khem Raj <[email protected]>
The firmware repo is huge ( 36G ) to clone is onerous using shallow clone tarballs require them to be pre-populated at some mirror which we don't have. Third option is to let github provide the tarball, there is concern that tarballs might change the compression etc and thus checksum would change that is something github would communicate to users in advance [1] Therefore this is the best solution for us right now. Also upgrade to latest while here and drop PR settings [1] https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives#stability-of-source-code-archives Signed-off-by: Khem Raj <[email protected]>
This file is now used to fetch binary blobs used by picamera and vc library recipes, which are only compatible with 32bit userspace Perhaps we need to sunset these recipe as some point and repace with alternatives like picamera2 which is built on top of libcamera and works on both 32bit and 64 bit rpi-bootfiles is fetching from latest firmware. Signed-off-by: Khem Raj <[email protected]>
I have separated 32bit only recipe needs from rpi-bootfiles and that should fix the issue. |
|
I'm wandering whether |
sadly, bitbake fetcher does not accept git commands directly, it has to be modified for that. |
|
@agherzan we need to merge this quickly, or else everyone will be fetching ~36G of firmware repo and break the internet :) |
|
@agherzan can you please merge this. It's blocking me to use meta-raspberrypi master branch for test build. Thanks. |
The firmware repo is huge ( 36G ) to clone is onerous using shallow clone tarballs require them to be pre-populated at some mirror which we don't have. Third option is to let github provide the tarball, there is concern that tarballs might change the compression etc and thus checksum would change that is something github would communicate to users in advance [1]
Therefore this is the best solution for us right now.
Also upgrade to latest while here and drop PR settings
[1] https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives#stability-of-source-code-archives
- What I did
- How I did it