all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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



  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

* 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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.