From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CF0BC4167B for ; Sat, 17 Dec 2022 01:20:32 +0000 (UTC) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by mx.groups.io with SMTP id smtpd.web11.970.1671240024756939660 for ; Fri, 16 Dec 2022 17:20:24 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: gmail.com, ip: 209.85.166.176, mailfrom: aehs29@gmail.com) Received: by mail-il1-f176.google.com with SMTP id y2so2135106ily.5 for ; Fri, 16 Dec 2022 17:20:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iRIoN1F6gYuSJjk5SGDfc49gavkzxvX5njoBJKjOBYM=; b=wBt2xVp8ZAodIeA4b3SsLCuDmaG10uTWosVNZVxka2CX56LVedTpbo2fe8gjPRLLBA UiR58fD199o6Mlt4W7rXprAlbViiClpjgVfAZVKbkBPYkUmNQ39+eWho9KrYckYsgCBo MZVfKpoFFBmBKaWtBYdYvREyivVx5GvrHxnO9P9CSiOpM1xaL4uZ7e0tZFBfzlkYpTz7 Gmz//rC4v9qZHnYQ4yj+P5VD6+HndEtWcVbbIBV5LEUg/sskjAWYBH/cTCa5JdpvzY3Y D0F0p7wazPwI9zY+P+pKmn3+XYKe0slbkUltIlTLaYdrKBh7/kH9RDs75lpaNcDrlKPU CznQ== X-Gm-Message-State: ANoB5pnBPY8g53EUlSmCU+l3kmH26SMh6O4AEc3yLOfl2YvUyZC/dqOB wpsbsMP9kV6d1wG9hmACQdKu38TnanrbJg== X-Google-Smtp-Source: AA0mqf50FPPbcxz9wXqTJds4CpQTGxkyWj/mdmh8lPWBOcW68bI3ReYH3/zedXaqc/nkTqC6gbK53w== X-Received: by 2002:a92:dd03:0:b0:303:2528:6d90 with SMTP id n3-20020a92dd03000000b0030325286d90mr18209974ilm.24.1671240023884; Fri, 16 Dec 2022 17:20:23 -0800 (PST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com. [209.85.166.48]) by smtp.gmail.com with ESMTPSA id i7-20020a05663815c700b00374bf3b62a0sm1192184jat.99.2022.12.16.17.20.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Dec 2022 17:20:23 -0800 (PST) Received: by mail-io1-f48.google.com with SMTP id n63so2111211iod.7 for ; Fri, 16 Dec 2022 17:20:23 -0800 (PST) X-Received: by 2002:a05:6638:240a:b0:38a:2f56:d739 with SMTP id z10-20020a056638240a00b0038a2f56d739mr14956353jat.111.1671240022915; Fri, 16 Dec 2022 17:20:22 -0800 (PST) MIME-Version: 1.0 References: <20221215073224.3061128-1-alejandro@enedino.org> <1731096B411C6A99.9432@lists.openembedded.org> In-Reply-To: From: Alejandro Enedino Hernandez Samaniego Date: Fri, 16 Dec 2022 18:20:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels To: Alex Kiernan Cc: Alexander Kanavin , OE-core Content-Type: multipart/alternative; boundary="000000000000e6878705effbe3a4" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sat, 17 Dec 2022 01:20:32 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/174765 --000000000000e6878705effbe3a4 Content-Type: text/plain; charset="UTF-8" On Thu, 15 Dec 2022 at 22:33, Alex Kiernan wrote: > On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego > wrote: > > > > > > > > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan > wrote: > >> > >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego > >> wrote: > >> > > >> > > >> > > >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego < > alejandro@enedino.org> wrote: > >> >> > >> >> > >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin < > alex.kanavin@gmail.com> wrote: > >> >>> > >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via > >> >>> lists.openembedded.org gmail.com@lists.openembedded.org> > >> >>> wrote: > >> >>> > Ok, I think what we should do first is to actually drop the > version > >> >>> > from all of the .bb file names, and set it once, inside some > .inc, and > >> >>> > probably next to SRC_URI and tarball checksum. Then this should > allow > >> >>> > a convenient scheme for including and overriding things. > >> >>> > > >> >>> > rust_1.65.0.bb - > rust.bb, and so on. > >> >>> > >> >>> Oh, and upstream version checks must be kept functional. It needs to > >> >>> both correctly report a newer version, and match the recipe version > >> >>> with upstream if it is already the latest. > >> >>> > >> >>> Alex > >> >> > >> >> > >> >> How should I test that upstream checks are still functional? > >> >> > >> >> > >> > Actually how would this make it any simpler?, if we remove PV from > the filenames, the correct place to put the variable is in rust-source.inc > since all others include it (rust-cross-canadian, rust, rust-llvm), if like > I said, rust-source.inc gets included from somewhere else, wouldnt that > override PV for the other recipe as well? beating the whole purpose of the > change, this, or creating a new .inc file just for this seems too > convoluted IMO. > >> > > >> > If changing RUST_VERSION is too problematic on every upgrade I think > approach #2 its a lot simpler just specifying RUST_VERSION on other recipes > since it would be very seldom used and it wont conflict with upgrades > >> > > >> > >> Actually changing it is clearly straightforward, the problem is that > >> upgrading the rust version is already tricky because of the need to > >> regenerate the cargo checksums, so every extra step is something that > >> you have to remember to do. > >> > >> Which leaves me wondering how introducing nightly/beta actually work > >> with those patches? > > > > > > I understand that , the checksums/patches shouldn't cause any problem > since as its explained in the commit message beta/nightly builds from the > exact same sources, hence patches should apply and checksums wouldn't > change. > > > > Sorry, now I'm properly confused, if the sources don't change, how is > this beta/nightly? > > cargo-checksum.json is basically completely non-patch friendly, you > have to fix it up every time as its based on the vendored sources in > the tarball. > > -- > Alex Kiernan > Yes, I was confused at first myself, the channel actually works as a build time flag, setting it to "beta" would enable the beta features that already in the source code at the time of every release, same with nightly hence why there are no extra conflicts when doing upgrades.. I actually just did the upgrade from 1.65.0 to 1.66.0 to test this (I just wasn't able to test target/native/nativesdk and all the arch variants before yours went in) and using different channels worked like a charm, no extra checksum changes other than the ones we have in our patches already. I'll be sending a v2 rebased on top of your 1.66.0 upgrade. Alejandro --000000000000e6878705effbe3a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Thu, 15 Dec 2022 at 22:33, Alex Kiernan <alex.kiernan@gmail.com>= wrote:
On Thu, = Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego
<alejandro@en= edino.org> wrote:
>
>
>
> On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> wrote:<= br> >>
>> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samani= ego
>> <ale= jandro@enedino.org> wrote:
>> >
>> >
>> >
>> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Sam= aniego <aleja= ndro@enedino.org> wrote:
>> >>
>> >>
>> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.c= om> wrote:
>> >>>
>> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> >>> lists.openembedded.org <alex.kanavin=3Dgmail.co= m@lists.openembedded.org>
>> >>> wrote:
>> >>> > Ok, I think what we should do first is to actual= ly drop the version
>> >>> > from all of the .bb file names, and set it once,= inside some .inc, and
>> >>> > probably next to SRC_URI and tarball checksum. T= hen this should allow
>> >>> > a convenient scheme for including and overriding= things.
>> >>> >
>> >>> > rust_1.65.0.bb - > rust.bb, and so on.
>> >>>
>> >>> Oh, and upstream version checks must be kept function= al. It needs to
>> >>> both correctly report a newer version, and match the = recipe version
>> >>> with upstream if it is already the latest.
>> >>>
>> >>> Alex
>> >>
>> >>
>> >> How should I test that upstream checks are still function= al?
>> >>
>> >>
>> > Actually how would this make it any simpler?, if we remove PV= from the filenames, the correct place to put the variable is in rust-sourc= e.inc since all others include it (rust-cross-canadian, rust, rust-llvm), i= f like I said, rust-source.inc gets included from somewhere else, wouldnt t= hat override PV for the other recipe as well? beating the whole purpose of = the change, this, or creating a new .inc file just for this seems too convo= luted IMO.
>> >
>> > If changing RUST_VERSION is too problematic on every upgrade = I think approach #2 its a lot simpler just specifying RUST_VERSION on other= recipes since it would be very seldom used and it wont conflict with upgra= des
>> >
>>
>> Actually changing it is clearly straightforward, the problem is th= at
>> upgrading the rust version is already tricky because of the need t= o
>> regenerate the cargo checksums, so every extra step is something t= hat
>> you have to remember to do.
>>
>> Which leaves me wondering how introducing nightly/beta actually wo= rk
>> with those patches?
>
>
> I understand that , the checksums/patches shouldn't cause any prob= lem since as its explained in the commit message beta/nightly builds from t= he exact same sources, hence patches should apply and checksums wouldn'= t change.
>

Sorry, now I'm properly confused, if the sources don't change, how = is
this beta/nightly?

cargo-checksum.json is basically completely non-patch friendly, you
have to fix it up every time as its based on the vendored sources in
the tarball.

--
Alex Kiernan

Yes, I was confused at= first myself, the channel actually works as a build time flag, setting it = to "beta" would enable the beta
features that alrea= dy in the source code at the time of every release, same with nightly hence= why there are no extra conflicts
when doing upgrades..

I actually just did the upgrade from 1.65.0 t= o 1.66.0 to test this (I just wasn't able to test target/native/natives= dk and all the arch
variants before yours went in) and using = different channels worked like a charm, no extra checksum changes other tha= n the ones
we have in our patches already.

=
I'll be sending a v2 rebased on top of your 1.66.0 upgra= de.

Alejandro=C2=A0
--000000000000e6878705effbe3a4--