Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

[John Kehayias]

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.kehayias@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