Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

[Yann E. MORIN]

Simon, All,

On 2022-10-19 18:15 +0200, Simon Richter spake thusly:
> Use the `cargo vendor` output to generate the vendor configuration.
> 
> Fixes the need to patch the configuration if there are
> dependencies that do not come from crates.io.

Could you provide a bit more details on how this works?

For example, we create a config file with:

    [source.crates-io]
    replace-with = "vendored-sources"
    [source.vendored-sources]
    directory = "VENDOR"

What would a similar config be like when using dependencies not coming
from crates.io?

Also, can we have a package that uses non-crates.io dependencies, so
that we have a test-case to ensure we have no regression?

> Signed-off-by: Simon Richter <simon.richter@ptwdosimetry.com>
> ---
>  support/download/cargo-post-process | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/support/download/cargo-post-process b/support/download/cargo-post-process
> index a4a4718a2a..7d6ecdb030 100755
> --- a/support/download/cargo-post-process
> +++ b/support/download/cargo-post-process
> @@ -22,17 +22,14 @@ post_process_unpack "${base_name}" "${output}"
>  
>  # Do the Cargo vendoring
>  pushd "${base_name}" > /dev/null
> -cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR
>  
>  # Create the local .cargo/config with vendor info
>  mkdir -p .cargo/
> -cat <<EOF >.cargo/config
> -[source.crates-io]
> -replace-with = "vendored-sources"
> +cargo vendor \
> +	--manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
> +	--locked VENDOR 2>&1 \
> +	| sed -ne '1,/To use vendored sources, add/!p' > .cargo/config

This means that vendoring step is then entirely silent, and there is no
progress report.

Since the download during the vendoring can be quite big, that means a
long pause without any feedback to the user that something is going on.

Also, if there is a download issue, there is no way to find what
happened.

Can we keep the vendoring to stdout as it currently is, and re-run it
right after, just to generate the config.toml file? I.e. something like:

    cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR
    cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR 2>&1 \
    |sed -ne '1,/To use vendored sources, add/!p' > .cargo/config

I've quickly hacked the existing script to run it twice, and it looks
like the second call generates the exact same output, so we should be
covered.

Finally, unrelated to your change: if the package already has a
.cargo/config.toml, then we irremediably override it. Is there something
in that file that would otherwise be required to do the build?

Can we simply append to the file rather than overwrite it, i.e.:
    .... >> .cargo/config.toml

Note that if we want to change that, this should be a different patch,
of course.

Regards,
Yann E. MORIN.

> -[source.vendored-sources]
> -directory = "VENDOR"
> -EOF
>  popd > /dev/null
>  
>  post_process_repack "$(pwd)" "${base_name}" "${output}"
> -- 
> 2.38.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

[Richter Simon]

Hi Yann,

Am 19.10.22 um 22:52 schrieb Yann E. MORIN:
> Could you provide a bit more details on how this works? 

Sure.
Currently the script generates a config file containing:
    [source.crates-io]
    replace-with = "vendored-sources"

    [source.vendored-sources]
    directory = "VENDOR"

This works for most projects since they do not use dependencies
from other sources besides crates.io.

But if a project needs dependencies from other sources, say github,
there needs to be an extra entry for each non-crates.io dependency.

As an example, here is the needed vendor config for conduit - a 
matrix homeserver.
(https://gitlab.com/famedly/conduit
rev cb2b5beea8a3fb27ed514ee9e46b5729aa272179)

    [source.crates-io]
    replace-with = "vendored-sources"
    
    [source."https://github.com/ruma/ruma"]
    git = "https://github.com/ruma/ruma"
    rev = "fba6f70c2df8294f96567f56464a46e3d237a8e9"
    replace-with = "vendored-sources"
    
    [source."https://github.com/timokoesters/heed.git"]
    git = "https://github.com/timokoesters/heed.git"
    rev = "f6f825da7fb2c758867e05ad973ef800a6fe1d5d"
    replace-with = "vendored-sources"
    
    [source."https://github.com/timokoesters/reqwest"]
    git = "https://github.com/timokoesters/reqwest"
    rev = "57b7cf4feb921573dfafad7d34b9ac6e44ead0bd"
    replace-with = "vendored-sources"
    
    [source.vendored-sources]
    directory = "vendor"

For the current script this means one has to create a patch for
the generated .cargo/config to contain the missing lines. That is not
nice for two reasons:

1. the corresponding package must contain a patch that
patches a file that is not part of the original sources of the package.

2. every time one or more dependencies are updated, the patch has to be changed.

> Also, can we have a package that uses non-crates.io dependencies, so
> that we have a test-case to ensure we have no regression?

I'm not sure if i understood that correctly. Do you mean bringing a
package into buildroot or if we already have a package that can be used
for a test?

If the second, no, i did not find any package that has non-crates.io
dependencies.

> This means that vendoring step is then entirely silent, and there is no
> progress report.
>
> Since the download during the vendoring can be quite big, that means a
> long pause without any feedback to the user that something is going on.
>
> Also, if there is a download issue, there is no way to find what
> happened.

That's correct, did not think about that.

> Can we keep the vendoring to stdout as it currently is, and re-run it
> right after, just to generate the config.toml file? I.e. something like:
>
> cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR
> cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR 2>&1 \
> |sed -ne '1,/To use vendored sources, add/!p' > .cargo/config

While digging around i found the following solution:
    cargo vendor \
        --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
        --locked VENDOR \
    | tee .cargo/config

Cargo seems to print all progress output to stderr but not the needed
output for the config. This goes to stdout. So we only have to tee stdout 
to the .cargo/config file. I will update the patch accordingly.

> Finally, unrelated to your change: if the package already has a
> .cargo/config.toml, then we irremediably override it. Is there something
> in that file that would otherwise be required to do the build?

Yes, i noticed that too. Overwriting a possibly existing project specific
configuration is not good.
I think this also should be changed (in a different patch, as mentioned).

> Can we simply append to the file rather than overwrite it, i.e.:
> .... >> .cargo/config.toml

Unfortunately it is not that simple because of two reasons:

1. cargo looks for a .cargo/config or (up from cargo 1.39) a 
.cargo/config.toml file for configuration. If both files exist, cargo uses 
.cargo/config and ignores the .cargo/config.toml file.

2. if configuration entries for vendoring already exist in a configuration, 
it is not allowed to add them again. Cargo will not build the project if a 
corresponding entry exists more than once.

The first case would be quiet easy to address but the second one would
need some sort of merging.

> Note that if we want to change that, this should be a different patch,
> of course.

Absolutely.


So, speaking for this patch, i would keep the current behavior "overwrite
every possibly existing config with the vendoring information".

Regards,
Simon
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

[Yann E. MORIN]

Simon, All,

On 2022-10-20 18:16 +0000, Richter Simon spake thusly:
> Am 19.10.22 um 22:52 schrieb Yann E. MORIN:
> > Could you provide a bit more details on how this works? 
[--SNIP--]
> But if a project needs dependencies from other sources, say github,
> there needs to be an extra entry for each non-crates.io dependency.
> As an example, here is the needed vendor config for conduit - a 
> matrix homeserver.
> (https://gitlab.com/famedly/conduit
> rev cb2b5beea8a3fb27ed514ee9e46b5729aa272179)
> 
>     [source.crates-io]
>     replace-with = "vendored-sources"
>     
>     [source."https://github.com/ruma/ruma"]
>     git = "https://github.com/ruma/ruma"
>     rev = "fba6f70c2df8294f96567f56464a46e3d237a8e9"
>     replace-with = "vendored-sources"
>     
>     [source."https://github.com/timokoesters/heed.git"]
>     git = "https://github.com/timokoesters/heed.git"
>     rev = "f6f825da7fb2c758867e05ad973ef800a6fe1d5d"
>     replace-with = "vendored-sources"
>     
>     [source."https://github.com/timokoesters/reqwest"]
>     git = "https://github.com/timokoesters/reqwest"
>     rev = "57b7cf4feb921573dfafad7d34b9ac6e44ead0bd"
>     replace-with = "vendored-sources"
>     
>     [source.vendored-sources]
>     directory = "vendor"

Ok, thanks, that helps see the overal concept.

I see all the above use git repositories directly, so I suspect this is
going to cause explicit git-clone + build (that's OK). However, I was
also wondering if one could have a "registry" like crates.io, either
internal to a company, or another public resource elsewhere, and how
that would work...

> > Also, can we have a package that uses non-crates.io dependencies, so
> > that we have a test-case to ensure we have no regression?
> I'm not sure if i understood that correctly. Do you mean bringing a
> package into buildroot

Yes, I was wondering if there was a publicly visible package that we
could cary in Buildroot, so that we know the feature would be regularly
exercised. You pointed to conduit: it wouldbe good to have it packaged
in Buildrooot.

[--SNIP--]
> > Can we keep the vendoring to stdout as it currently is, and re-run it
> > right after, just to generate the config.toml file? I.e. something like:
[--SNIP--]
> While digging around i found the following solution:
>     cargo vendor \
>         --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
>         --locked VENDOR \
>     | tee .cargo/config
> 
> Cargo seems to print all progress output to stderr but not the needed
> output for the config. This goes to stdout. So we only have to tee stdout 
> to the .cargo/config file. I will update the patch accordingly.

Great! :-)

Please, also note that this has the potential to generate different
hashes, so please check existing cargo packages to see what breaks.

If we can't keep generating the same archives, then we must find a way
to dfferentiate the newer archives so they do not clash with the older
ones. Something like:

    diff --git a/package/pkg-download.mk b/package/pkg-download.mk
    index 0718f21aad..e247fd38c5 100644
    --- a/package/pkg-download.mk
    +++ b/package/pkg-download.mk
    @@ -22,6 +22,7 @@ export LOCALFILES := $(call qstrip,$(BR2_LOCALFILES))
     # download backend:
     BR_FMT_VERSION_git = -br1
     BR_FMT_VERSION_svn = -br2
    +BR_FMT_VERSION_cargp = -cargo1

     DL_WRAPPER = support/download/dl-wrapper

    diff --git a/package/pkg-utils.mk b/package/pkg-utils.mk
    index 0945e6ed31..7486d12499 100644
    --- a/package/pkg-utils.mk
    +++ b/package/pkg-utils.mk
    @@ -48,7 +48,7 @@ pkgname = $(lastword $(subst /, ,$(pkgdir)))
     # Helper to build the extension for a package archive, based on various
     # conditions.
     # $(1): upper-case package name
    -pkg_source_ext = $(BR_FMT_VERSION_$($(1)_SITE_METHOD)).tar.gz
    +pkg_source_ext = $(BR_FMT_VERSION_$($(1)_SITE_METHOD))$(BR_FMT_VERSION_$($(1)_DOWNLOAD_POST_PROCESS)).tar.gz

     # Define extractors for different archive suffixes
     INFLATE.bz2  = $(BZCAT)

Note: this is probably not sufficient, but that gives you a lead if
needed. Also, we'd need a comment at the top of the cargo-post-process
helper, like we have at the top of the git helper for example.

> > Finally, unrelated to your change: if the package already has a
> > .cargo/config.toml, then we irremediably override it. Is there something
> > in that file that would otherwise be required to do the build?
> 
> Yes, i noticed that too. Overwriting a possibly existing project specific
> configuration is not good.
> I think this also should be changed (in a different patch, as mentioned).

Or we can wait for until something actually needs it, so that we do have
an actual case to look at.

> > Can we simply append to the file rather than overwrite it, i.e.:
> > .... >> .cargo/config.toml
> 
> Unfortunately it is not that simple because of two reasons:
> 
> 1. cargo looks for a .cargo/config or (up from cargo 1.39) a 
> .cargo/config.toml file for configuration. If both files exist, cargo uses 
> .cargo/config and ignores the .cargo/config.toml file.
> 
> 2. if configuration entries for vendoring already exist in a configuration, 
> it is not allowed to add them again. Cargo will not build the project if a 
> corresponding entry exists more than once.
> 
> The first case would be quiet easy to address but the second one would
> need some sort of merging.

Yes, so that all calls for waiting until we do have an actual issue.

> So, speaking for this patch, i would keep the current behavior "overwrite
> every possibly existing config with the vendoring information".

Yes, because that has so far not caused an issue (at least that we
noticed), so this means it is not an actual problem.

Thanks!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

[Richter Simon]

Hi Yann,

Am 20.10.22 um 22:25 schrieb Yann E. MORIN:

> I see all the above use git repositories directly, so I suspect this is
> going to cause explicit git-clone + build (that's OK). However, I was
> also wondering if one could have a "registry" like crates.io, either
> internal to a company, or another public resource elsewhere, and how
> that would work...

It is possible to use an own registry, yes, but i did not use that yet.
However, i checked the code of cargo vendor and have seen that
alternative registries are handeled. That means that `cargo vendor`
should print the needed config and we would use it with this patch.

As i have understood it so far, a corresponding entry would look like this:

    [crates-io]
    replace-with = "vendored-sources"
    
    [my-own-registry]
    replace-with = "vendored-sources"
    
    [vendored-sources]
    directory = "vendor"

> Yes, I was wondering if there was a publicly visible package that we
> could cary in Buildroot, so that we know the feature would be regularly
> exercised. You pointed to conduit: it wouldbe good to have it packaged
> in Buildrooot.

I can try to do that. But that should be done in a different patch i think?

> Please, also note that this has the potential to generate different
> hashes, so please check existing cargo packages to see what breaks.

I did, and with my last suggestion (using cargo and tee) those packages 
broke. The problem is that `cargo vendor` outputs a preceding newline
that must be removed.
I came up with this:

    cargo vendor \
        --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
        --locked VENDOR \
    | tail --lines=+2 | tee .cargo/config

This removes the first (and empty) line. 

With this, all packages i checked were fine. These were:
 - bat
 - dust
 - hyperfine
 - ripgrep
 - tealdeer
 - python-rtoml
 - python-orjson
 - python-cryptography
 - host-python-maturin

I hope i've got all.

> Or we can wait for until something actually needs it, so that we do have
> an actual case to look at.
>
>>> Can we simply append to the file rather than overwrite it, i.e.:
>>> .... >> .cargo/config.toml
>>
>> Unfortunately it is not that simple because of two reasons:
>>
>> 1. cargo looks for a .cargo/config or (up from cargo 1.39) a 
>> .cargo/config.toml file for configuration. If both files exist, cargo uses 
>> .cargo/config and ignores the .cargo/config.toml file.
>>
>> 2. if configuration entries for vendoring already exist in a configuration, 
>> it is not allowed to add them again. Cargo will not build the project if a 
>> corresponding entry exists more than once.
>>
>> The first case would be quiet easy to address but the second one would
>> need some sort of merging.
>
> Yes, so that all calls for waiting until we do have an actual issue.
>
>> So, speaking for this patch, i would keep the current behavior "overwrite
>> every possibly existing config with the vendoring information".
>
> Yes, because that has so far not caused an issue (at least that we
> noticed), so this means it is not an actual problem.

Agreed.


If you agree so far, I would send the new version of the patch.


Regards,
Simon

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] support/download/cargo-post-process: use cargo output for vendor config

[Yann E. MORIN]

Simon, All,

On 2022-10-21 12:10 +0000, Richter Simon spake thusly:
> Am 20.10.22 um 22:25 schrieb Yann E. MORIN:
> > I see all the above use git repositories directly, so I suspect this is
> > going to cause explicit git-clone + build (that's OK). However, I was
> > also wondering if one could have a "registry" like crates.io, either
> > internal to a company, or another public resource elsewhere, and how
> > that would work...
> 
> It is possible to use an own registry, yes, but i did not use that yet.

OK, that's fine!

> > Yes, I was wondering if there was a publicly visible package that we
> > could cary in Buildroot, so that we know the feature would be regularly
> > exercised. You pointed to conduit: it wouldbe good to have it packaged
> > in Buildrooot.
> I can try to do that. But that should be done in a different patch i think?

Yes, as a followup patch, that way you provide the new feature, and you
show how it is used. And we get a new interesting package! :-)

> > Please, also note that this has the potential to generate different
> > hashes, so please check existing cargo packages to see what breaks.
> I did, and with my last suggestion (using cargo and tee) those packages 
> broke. The problem is that `cargo vendor` outputs a preceding newline
> that must be removed.
> I came up with this:
> 
>     cargo vendor \
>         --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
>         --locked VENDOR \
>     | tail --lines=+2 | tee .cargo/config

Now, one last issue: if the 'cargo' call fails, the script won't fail,
because cargo is part of a pipe.

The script is already "set -e", but we also need "set -o pipefail".

> This removes the first (and empty) line. 
> 
> With this, all packages i checked were fine.

OK, so don't forget to mention that in your new commit log.

Also, the rationale that we can change it, is that it produces the exact
same output that we do, and if for some package it would not generate
the same output, that package was not working anyway because it was
missing parts of its vendored sources anyway. So, that can't regress.

> These were:
>  - bat
>  - dust
>  - hyperfine
>  - ripgrep
>  - tealdeer
>  - python-rtoml
>  - python-orjson
>  - python-cryptography
>  - host-python-maturin
> 
> I hope i've got all.

You missed: host-sentry-cli (is a host-cargo-package).

> If you agree so far, I would send the new version of the patch.

Yes, with all we discussed, it looks in good way.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2] support/download/cargo-post-process: cargo output for vendor config

[Simon Richter]

Use the output of `cargo vendor` to generate the vendor configuration.

Fixes the need to patch the generated configuration if there are
non-crates.io dependencies.

Note:
  `cargo vendor` currently prints a newline before it prints the
  needed configuration.

  This is fixed in +nightly, will end up in +stable soon and must
  be considered when updating cargo.
  See: https://github.com/rust-lang/cargo/pull/11273

  Until then it is needed to remove this first line to make sure
  that the contents of .cargo/config will be the same as they were
  generated with the earlier version of the script. Thus, the
  hashes of the packages that use this script remain the same.

Signed-off-by: Simon Richter <simon.richter@ptwdosimetry.com>
---
 support/download/cargo-post-process | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/support/download/cargo-post-process b/support/download/cargo-post-process
index a4a4718a2a..186e9eb69b 100755
--- a/support/download/cargo-post-process
+++ b/support/download/cargo-post-process
@@ -1,6 +1,7 @@
 #!/usr/bin/env bash
 
 set -e
+set -o pipefail
 
 . "${0%/*}/helpers"
 
@@ -22,17 +23,28 @@ post_process_unpack "${base_name}" "${output}"
 
 # Do the Cargo vendoring
 pushd "${base_name}" > /dev/null
-cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR
 
 # Create the local .cargo/config with vendor info
+#
+# The first line of the output to stdout is empty.
+# So skip it to have the file start with the vendoring
+# configuration (`tail --lines=+2`).
+#
+# NOTE:
+#   There is  a patch for cargo to remove the first empty line:
+#   See: https://github.com/rust-lang/cargo/pull/11273
+#
+#   The patch already landed in +nightly and will end up
+#   in +stable soon.
+#
+# ->  When updating rust/cargo, the call to `tail` must be removed.
+#
 mkdir -p .cargo/
-cat <<EOF >.cargo/config
-[source.crates-io]
-replace-with = "vendored-sources"
+cargo vendor \
+    --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
+    --locked VENDOR \
+    | tail --lines=+2 | tee .cargo/config
 
-[source.vendored-sources]
-directory = "VENDOR"
-EOF
 popd > /dev/null
 
 post_process_repack "$(pwd)" "${base_name}" "${output}"
-- 
2.38.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2] support/download/cargo-post-process: cargo output for vendor config

[Yann E. MORIN]

Simon, All,

On 2022-10-25 12:02 +0200, Simon Richter spake thusly:
> Use the output of `cargo vendor` to generate the vendor configuration.
> 
> Fixes the need to patch the generated configuration if there are
> non-crates.io dependencies.
> 
> Note:
>   `cargo vendor` currently prints a newline before it prints the
>   needed configuration.
> 
>   This is fixed in +nightly, will end up in +stable soon and must
>   be considered when updating cargo.
>   See: https://github.com/rust-lang/cargo/pull/11273

This is going to need care when we bump, so I added a little comment in
rust-bin.mk and rust.mk tocheck that a version bump still generates the
same archives.

>   Until then it is needed to remove this first line to make sure
>   that the contents of .cargo/config will be the same as they were
>   generated with the earlier version of the script. Thus, the
>   hashes of the packages that use this script remain the same.
> 
> Signed-off-by: Simon Richter <simon.richter@ptwdosimetry.com>

Applied to master, thanks.

Regards,
Yann E. MORIN.

> ---
>  support/download/cargo-post-process | 26 +++++++++++++++++++-------
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/support/download/cargo-post-process b/support/download/cargo-post-process
> index a4a4718a2a..186e9eb69b 100755
> --- a/support/download/cargo-post-process
> +++ b/support/download/cargo-post-process
> @@ -1,6 +1,7 @@
>  #!/usr/bin/env bash
>  
>  set -e
> +set -o pipefail
>  
>  . "${0%/*}/helpers"
>  
> @@ -22,17 +23,28 @@ post_process_unpack "${base_name}" "${output}"
>  
>  # Do the Cargo vendoring
>  pushd "${base_name}" > /dev/null
> -cargo vendor --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} --locked VENDOR
>  
>  # Create the local .cargo/config with vendor info
> +#
> +# The first line of the output to stdout is empty.
> +# So skip it to have the file start with the vendoring
> +# configuration (`tail --lines=+2`).
> +#
> +# NOTE:
> +#   There is  a patch for cargo to remove the first empty line:
> +#   See: https://github.com/rust-lang/cargo/pull/11273
> +#
> +#   The patch already landed in +nightly and will end up
> +#   in +stable soon.
> +#
> +# ->  When updating rust/cargo, the call to `tail` must be removed.
> +#
>  mkdir -p .cargo/
> -cat <<EOF >.cargo/config
> -[source.crates-io]
> -replace-with = "vendored-sources"
> +cargo vendor \
> +    --manifest-path ${BR_CARGO_MANIFEST_PATH-Cargo.toml} \
> +    --locked VENDOR \
> +    | tail --lines=+2 | tee .cargo/config
>  
> -[source.vendored-sources]
> -directory = "VENDOR"
> -EOF
>  popd > /dev/null
>  
>  post_process_repack "$(pwd)" "${base_name}" "${output}"
> -- 
> 2.38.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot