From: John Kehayias <john.kehayias@protonmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23
Date: Tue, 20 Sep 2022 16:15:56 +0000 [thread overview]
Message-ID: <87bkra58eg.fsf@protonmail.com> (raw)
In-Reply-To: <87tu5bdont.fsf@netris.org>
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
next prev parent reply other threads:[~2022-09-20 21:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 5:11 Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23 Mark H Weaver
2022-09-13 13:50 ` John Kehayias
2022-09-13 14:30 ` Maxime Devos
2022-09-13 14:35 ` John Kehayias
2022-09-13 14:36 ` Maxime Devos
2022-09-13 20:06 ` Mark H Weaver
2022-09-20 16:15 ` John Kehayias [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-09-13 17:49 John Kehayias
2022-09-13 20:11 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkra58eg.fsf@protonmail.com \
--to=john.kehayias@protonmail.com \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).