Hi Mark, Sorry, lost track of the dates on this!
On Tue, Sep 13, 2022 at 04:06 PM, Mark H Weaver wrote: > 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? > I see you took the packages that existed for these and put on the gnuzilla-updates branch here. Thanks for doing that, sorry I didn't respond quicker. Hopefully you saw that it was pretty straight forward, a few rust and rust packages updates/new inclusions, but nothing needed anything special. Does everything build okay for the new icecat now? Do you need anything else? If I remember, with staging we will only then remove the local rust-1.58 and rust-1.59 packages. The inclusion of the newer rust-cbindgen will also mean a lot of <https://issues.guix.gnu.org/57702> is in gnuzilla.scm and can be coordinated with that patch series. (I'm not on that series but can send a message to that thread.) > Thanks very much for working on it. > Well, thanks for doing the work of getting things moving over here! Hopefully that previous work made it easier. Sorry for dropping the ball earlier. John
