Hi John, John Kehayias <john.kehay...@protonmail.com> writes:
> I actually added rust-cbindgen-0.23 and 0.24 for another channel which > needs them for a similar purpose (I will not link the channel but I > think you will know which I mean). So I can submit the patches here, > though I'm not familiar with all the ins and outs of rust packaging I > can at least take care of the basic updates and needed dependencies. > > One slight wrinkle is that there is a bug for using version 0.24 for > some Firefox versions > <https://bugzilla.mozilla.org/show_bug.cgi?id=1773259> Though that > should be fixed on newer ones, I'm not sure if that affects what will > end up as IceCat: > <https://bugzilla.mozilla.org/show_bug.cgi?id=1773259#c5> > > Normally I would just go with the latest cbindgen to have that for > future uses, but maybe we should just have 0.23 and 0.24? I have > patches for both, just trying to see what would be cleanest here. Thanks for pointing this out. IceCat 102 will almost surely be affected by the same issues that affect Firefox 102 ESR, so I guess we'll need rust-cbindgen-0.23 until a better solution is found. > Finally, should these be based on staging or master? I hear we'll have > staging in master in the near future, let me know what will work best > for these patches. Hmm. That's a good question. I guess that the work of properly integrating rust-cbindgen-0.23 into Guix proper would most naturally be done on the 'staging' branch, since that branch already has pending changes to our rust packages. However, there's a problem: we absolutely must have these packages on the 'master' branch by the morning of September 20th. I don't know that we can predict with certainty that 'staging' will be ready to merge by then. Therefore, I think we also need to temporarily add these packages to 'master' before the 'staging' merge happens. I see two possible approaches: (1) If it's easy to do, and the risk of unintended breakage seems low, selected changes could be cherry-picked from 'staging' to 'master', taking care to facilitate the upcoming merge. (2) Alternatively, we could temporarily add private package definitions to (gnu packages gnuzilla) on 'master' for the exclusive use of IceCat 102, as a stopgap measure. These could be removed after the required packages have been properly integrated into 'master'. It seems to me that (1) is the right approach for 'rust-1.59', because I guess we can simply copy the definitions of 'rust-1.58' and 'rust-1.59' from 'staging' to 'master', while leaving the 'rust' variable unchanged, and exporting 'rust-1.59'. I don't know which approach is best for rust-cbindgen-0.23. It depends on how much work has been done on the dependencies of rust-cbindgen on the 'staging' branch. If in doubt, (2) might be the right approach. What do you think? Thanks very much for working on it. Regards, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
