RISC-V architecture is marked as "unofficial"

Marc Deslauriers marc.deslauriers at canonical.com
Mon May 5 15:14:24 UTC 2025


On 2025-05-05 11:00, Heinrich Schuchardt wrote:
> On 5/5/25 16:31, Marc Deslauriers wrote:
>> On 2025-05-05 10:23, Robie Basak wrote:
>>> On Sat, May 03, 2025 at 06:03:55AM +0530, Utkarsh Gupta wrote:
>>>> Hi Robie, others,
>>>> Yes - please consider marking RISC-V as an official architecture. As
>>>> far the release process goes, we already treat them as official
>>>> images.
>>>>
>>>> And as Colin said earlier in the thread, please consider doing this
>>>> for Questing onward and it'd be better to not touch the other stable
>>>> releases.
>>>
>>> Thanks! (and also to Colin and Dimitri). This gives me confidence that
>>> this change is fine to make.
>>>
>>> As an aside, I've been waiting over three days for a riscv64 build in
>>> Questing[1]. Right now the queue length is apparently 47 hours[2] while
>>> the other architectures have negligible queues. That does have a big
>>> impact wrt. proposed migration. Perhaps we should apply some expected
>>> standard that needs to be made before considering an architecture
>>> "official"? I don't think we've had anything like that before, but
>>> perhaps setting some quality expectations would be reasonable and useful
>>> for the project so as not to have yet another cause for development pace
>>> to slow?
>>>
>> Riscv64 build times are also a big challenge for the security team. We 
>> sometimes have to skip riscv64 when issuing emergency security updates. While 
>> we do try and complete the risc64 builds at a later time as much as possible, 
>> this still results in riscv64 information being absent in our USNs, and our 
>> OVAL data.
>>
>> I'm not sure we will be able to issue timely security updates if riscv64 
>> becomes an official architecture and we don't change how we build it.
>>
>> Marc.
> 
> Would we really have to change the current handling of security updates for 
> riscv64 if we remove that flag "unofficial" in Launchpad?
> 
Well, I guess that depends on what the flag actually means, and whether or not 
the security team will still use it to determine security support. I guess 
ultimately I would like the tech board to determine what the flag means.

Marc.



More information about the technical-board mailing list