[Buildroot] [PATCH 1/1] package/python-rpds-py: bump to version 0.16.2

[Antoine Coutant]

On 06/02/2024 15:53, Yann E. MORIN wrote:
> Antoine, All,
>
> On 2024-02-06 15:09 +0100, Antoine Coutant spake thusly:
>> On 11/01/2024 06:17, James Hilliard wrote:
>>> Signed-off-by: James Hilliard<james.hilliard1 at gmail.com>
> [--SNIP--]
>>> -PYTHON_RPDS_PY_VERSION = 0.12.0
>>> +PYTHON_RPDS_PY_VERSION = 0.16.2
>> rpds depends on the crate pyo3. This crate uses
>> "std::sync::atomic::AtomicI64" which doesn't exist for 32 bits
>> targets. That leads to an error [1].
> I have been discussing this with Romain IRL, and he explained that the
> issue _already_ happenned with 0.12.0, so this is not a regression and
> thus reverting this patch will not fix the issue.
>
> Is that correct?

Yes, this patch is not a regression. I did a test with Buildroot 2023.11

and it failed. This bug is old but i described it here because I was

working on it when the version bump was applied and I thought

it was related.

>
> Also, will std::sync::atomic::AtomicI64 ever be available for 32-bit
> targets? If not, would that be considered a bug in the std lib?

according to the rust doc, std::sync::atomic::AtomicI64 is only available

on platforms that support atomic loads and stores of i64 [1]. Moreover,

std::sync::atomic types might not be available on all platforms [2].


That's why the crate portable-atomic [3] have been created. It provides

atomic types and compare and swap operations for all targets that can use

std. That's the crate used by pyo3 upstream to solve the problem [4].

>> An issue have been opened on pyo3's github [2]. A fix have been accepted [3]
>> but it isn't in the last release. Thus, this version bump doesn't
>> fix this problem.
>> [1]:https://gitlab.com/buildroot.org/buildroot/-/jobs/6093854842
>> [2]:https://github.com/PyO3/pyo3/issues/3614
>> [3]:https://github.com/PyO3/pyo3/pull/3619
> It is not going to be easy to carry this change as a patch in Buildroot:
> it would require that we be able to patch a package during the vendoring
> step.
>
> In this case, we'd need to do the vendoring (because we need the pyo3
> crate to be downloaded), then apply the patch (with mangled paths) to
> add the new dependency, then restart the vendoring. In the generic case,
> we'd even need to be able to repeat the process in case that new
> dependency has to be patched and so on and so on... That's not going to
> be easy, by far...
>
> Meh...
>
> We can't even update to a random sha1 from the rpds git tree, because
> they do nit even have an update to switch to a newer (even if
> unreleased) pyo3.
>
> Meh, again...
>
> Not sure what to do...
>
> What about adding a dependency on BR2_ARCH_IS_64 to python-rpds-pym and
> propagate that to all its dependencies?

I think this is the best way to avoid this bug. Patching during the

vendoring process seams to be possible. But it will be quite

impossible to maintain.


The dependency on BR2_ARCH_IS_64 must be removed when

the version of spo3 used by rpds will use portable-atomic.

>
> Regards,
> Yann E. MORIN.


[1]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI64.html

[2]: https://doc.rust-lang.org/std/sync/atomic/index.html#portability

[3]: https://github.com/taiki-e/portable-atomic

[4]: https://github.com/PyO3/pyo3/pull/3619/files


Regards,

Antoine Coutant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20240206/c08ad8a3/attachment-0001.html>