Hi!

Is there a way to note required DEPENDS arguments for the recipe? We have a project that requires that the system has openssl, and need to add it manually for each new version by adding:

DEPENDS += " openssl"

to the recipe.

Is there any way we can add into some file (maybe cargo.toml) that we need some extra arguments in the recipe file?

Hi, when I'm trying to install cargo BitBake, I get the following error:

error[E0283]: type annotations needed --> /home/noel/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-0.49.0/src/cargo/util/config/de.rs:530:63 | 530 | seed.deserialize(Tuple2Deserializer(1i32, env.as_ref())) | ^^^^^^ cannot infer type for struct std::string::String | = note: cannot satisfy std::string::String: std::convert::AsRef<_>

error: aborting due to previous error

For more information about this error, try rustc --explain E0283. error: could not compile cargo.

To learn more, run the command again with --verbose. warning: build failed, waiting for other jobs to finish... error: failed to compile cargo-bitbake v0.3.15, intermediate artifacts can be found at /tmp/cargo-installYXjK6b

Caused by: build failed

I tried it on ubuntu 16, 18 and 20. I once had it running on Ubuntu 18, but I can't remember what changed in the meantime.

Any help appreciated.

When attempting to run cargo bitbake inside a CI/CD pipeline, which runs in a Docker container, or locally within WSL2 (which is based on Docker), I get the following error.

thread 'main' panicked at 'attempted to zero-initialize type `sized_chunks::sized_chunk::Chunk<(core::package_id::PackageId, im_rc::OrdMap<core::package_id::PackageId, std::vec::Vec<core::dependency::Dependency>>)>`, which is invalid', /hom
e/<user>/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:622:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

cargo bitbake runs fine in Windows locally.

We had some issues on crates using newer cargo features. We're successfully using the updated version internally.

The only non-mechanical parts are:

• add docopt as a dependency since cargo removed it from itself
• add failure as a dependency to interact with cargo's various Result types

Cargo bitbake won't generate a recipe when there is no license info in Cargo.toml However for internal projects there might not be a license.

LICENSE = "CLOSED"

in a recipe is a valid way to signal yocto that there is no valid license. However if I use that I still get

# FIXME: update generateme with the real MD5 of the license file
LIC_FILES_CHKSUM=" \
file://CLOSED;md5=generateme \
"

in the generated file.

It would be nice if that could be left out

i dont know why but it crashes even on a clean hello_world.

steps to reproduce

> cargo new --bin hello_world
> cd hello_world
> cargo bitbake
Package name contains an underscore
thread 'main' panicked at 'attempted to zero-initialize type `sized_chunks::sized_chunk::Chunk<(core::package_id::PackageId, im_rc::OrdMap<core::package_id::PackageId, std::vec::Vec<core::dependency::Dependency>>)>`, which is invalid', /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:636:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

> env RUST_BACKTRACE=1 cargo bitbake
Package name contains an underscore
thread 'main' panicked at 'attempted to zero-initialize type `sized_chunks::sized_chunk::Chunk<(core::package_id::PackageId, im_rc::OrdMap<core::package_id::PackageId, std::vec::Vec<core::dependency::Dependency>>)>`, which is invalid', /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:636:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/panicking.rs:50:5
   3: cargo::core::resolver::encode::EncodableResolve::into_resolve
   4: cargo::ops::lockfile::load_pkg_lockfile
   5: cargo::ops::resolve::resolve_with_registry
   6: cargo::ops::resolve::resolve_ws
   7: cargo_bitbake::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

> env RUST_BACKTRACE=full cargo bitbake
Package name contains an underscore
thread 'main' panicked at 'attempted to zero-initialize type `sized_chunks::sized_chunk::Chunk<(core::package_id::PackageId, im_rc::OrdMap<core::package_id::PackageId, std::vec::Vec<core::dependency::Dependency>>)>`, which is invalid', /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:636:9
stack backtrace:
0:     0x557864e0aa10 - std::backtrace_rs::backtrace::libunwind::trace::hb4de9797f80b7b8c
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
1:     0x557864e0aa10 - std::backtrace_rs::backtrace::trace_unsynchronized::h59566d0bd20efff7
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2:     0x557864e0aa10 - std::sys_common::backtrace::_print_fmt::hcfa5ce6be50275d4
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/sys_common/backtrace.rs:67:5
3:     0x557864e0aa10 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd8c307a38b9bab04
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/sys_common/backtrace.rs:46:22
4:     0x557864e2ef6c - core::fmt::write::h3868db8542c90941
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/fmt/mod.rs:1092:17
5:     0x557864e05022 - std::io::Write::write_fmt::hab90295d5a0f197d
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/io/mod.rs:1568:15
6:     0x557864e0d385 - std::sys_common::backtrace::_print::h19224910b8700cf1
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/sys_common/backtrace.rs:49:5
7:     0x557864e0d385 - std::sys_common::backtrace::print::h25dedfa68c5fb84a
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/sys_common/backtrace.rs:36:9
8:     0x557864e0d385 - std::panicking::default_hook::{{closure}}::h12c5765653a72a42
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:208:50
9:     0x557864e0ce33 - std::panicking::default_hook::he65cee71c4209f0c
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:225:9
10:     0x557864e0db21 - std::panicking::rust_panic_with_hook::h01a674d863fe0d8a
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:591:17
11:     0x557864e0d637 - std::panicking::begin_panic_handler::{{closure}}::h9b9fecf185178864
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:495:13
12:     0x557864e0aeac - std::sys_common::backtrace::__rust_end_short_backtrace::h57be46a42dc7f24b
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/sys_common/backtrace.rs:141:18
13:     0x557864e0d5c9 - rust_begin_unwind
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:493:5
14:     0x557864e2d711 - core::panicking::panic_fmt::h20225113c4a2f8fd
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/panicking.rs:92:14
15:     0x557864e2d65d - core::panicking::panic::h35b77276aa4b0c12
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/panicking.rs:50:5
16:     0x557864a87314 - cargo::core::resolver::encode::EncodableResolve::into_resolve::h2f748dd6fbb45b10
17:     0x557864add504 - cargo::ops::lockfile::load_pkg_lockfile::h890294a2b2ae1271
18:     0x55786499c2b2 - cargo::ops::resolve::resolve_with_registry::hc17182a46b1ce1f3
19:     0x55786499bffc - cargo::ops::resolve::resolve_ws::h756b4fb615ab36cc
20:     0x5578649845b5 - cargo_bitbake::main::h5a9984559c9d0925
21:     0x55786497a1e6 - std::sys_common::backtrace::__rust_begin_short_backtrace::h9efb7d1592b8fc7e
22:     0x55786498bacc - std::rt::lang_start::{{closure}}::h8bcc286ab3d85600
23:     0x557864e0e02a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h2c4fd7d4128112a8
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/core/src/ops/function.rs:259:13
24:     0x557864e0e02a - std::panicking::try::do_call::h41fb7dbbbe7bece6
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:379:40
25:     0x557864e0e02a - std::panicking::try::hd38008ccba72bce1
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panicking.rs:343:19
26:     0x557864e0e02a - std::panic::catch_unwind::h057e765cd60f2d13
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/panic.rs:431:14
27:     0x557864e0e02a - std::rt::lang_start_internal::hdb9d0b9d2cdcda8b
							at /rustc/3e826bb11228508fbe749e594038d6727208aa94/library/std/src/rt.rs:51:25
28:     0x5578649869c5 - main
29:     0x7f0aa33d21e2 - __libc_start_main
30:     0x557864972f4e - _start
31:                0x0 - <unknown>

Installed with cargo install cargo-bitbake --locked, as per the workaround in https://github.com/meta-rust/cargo-bitbake/issues/29#issuecomment-841929943 .

cargo bitbake fails with the following output:

$ cargo bitbake
    Updating crates.io index
error: failed to get `simplelog` as a dependency of package `proto-test v0.1.0 (/home/jaskij/projects/rust/proto_test)`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  invalid version 0 on git_proxy_options; class=Invalid (3)

curiously, cargo update works:

$ cargo update
    Updating crates.io index

my Cargo.toml:

[package]
name = "proto-test"
version = "0.1.0"
edition = "2018"

[dependencies]

flatbuffers = "^2.0.0"
protobuf = "^2.25.1"

log = "^0.4.14"
simplelog = "^0.10.2"

[build-dependencies]

flatc-rust = "^0.2.0"
protoc-rust = "^2.25.1"

How do I ensure license gets resolved? In the case of a nested project would it make sense to pass in option for file name? Something like 'cargo bitbake -l ../LICENSE'?

This might not be an issue, however:

cargo build succeeds.

Cargo.toml:

[dependencies] serde = { version = "1.0", features = ["derive"] } # Derive Deserialization for the config struct serde_json = "1" # serde_json base64 = "0.10" reqwest = "0.9" rsa = "0.1.3" log = "0.4" simple_logger = "1.3.0" hex = "0.3.2" openssl = { version = "0.10", features = ["vendored"] }

And cargo bitbake:

cargo bitbake Updating registryhttps://github.com/rust-lang/crates.io-indexerror: no matching version^0.4found for packagenum-bigint(required byrsa) location searched: registryhttps://github.com/rust-lang/crates.io-indexversions found: 0.2.3, 0.2.2, 0.2.1, ...

cargo 1.37.0 (9edd08916 2019-08-02)

I tried to install cargo-bitbake on Ubuntu 22.04, with locked version and without the locked parameter (see the errors in the log files: the "not locked" version causes "error[E0283]: type annotations needed" and the locked version causes "error: failed to run custom build command for openssl-sys v0.9.54"). Note that libssl-dev and pkg-config are installed on the system. Is it a known issue?

packages.txt cargo-bitbake-locked.txt cargo-bitbake-not-locked.txt

The generated recipe never actually invokes cargo directly, so where is that done?

I'd like to be able to pass --features "feat1, feat2, feat3" when the code is actually built. This is probably due to my lack of understanding of Yocto in general. Where should I be passing feature flags for conditional compilation? Is this outside the scope of cargo bitbake?

I am currently building a project that has a development dependency on mockall, which should not be included bitbake recipe. Removing the mockall crates from the list of source crates in the resulting bitbake recipe is not that of a big issue, but mockall itself pulls in additional dependencies. This makes cleaning up the resulting recipe a very tedious process. It would be nice if the development dependencies are excluded from the recipe by default and could be included with a new flag. If this is too restrictive a flag excluding the development dependencies could also do the trick.

Thanks.

I am trying to generate a bitbake recipe without any windows dependencies.

The application I am building depends on log4rs, which depends on the winapi crate. However, this dependency is only enabled when building for windows systems as it is placed in the [target.'cfg(windows)'.dependencies] section in the log4rs Cargo.toml. Thus, I would expect that these dependencies are not included in the generated bitbake recipe. When checking the dependency tree with cargo tree these dependencies are not included, as my currently configured default toolchain is stable-x86_64-unknown-linux-gnu and I have to explicitly ask for a windows target using cargo tree --target x86_64-uwp-windows-gnu to see the windows dependencies in the graph. Moving all dependencies into a [target.'cfg(linux)'.dependencies] does no fix this issues.

Why are windows dependencies included at all in the bitbake recipes, as "The Yocto Project (YP) is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture."

Removing the windows dependencies from the generated bitbake recipe works perfectly fine, however there might be dependencies which are not that easy to identify as windows dependencies.

Is there a quick fix for this issue and is this considered expected behavior?

Thanks.

I am trying to create a recipe for a fairly simple package and ran into a problem. I have reproduced the issue with the following trivial Cargo.toml for a simple "Hello World" example:

[package]
name = "hello"
description = "Hello, World example"
license = "BSD"
version = "0.1.0"
repository = "https://helloworld.com/hello_cargo"
edition = "2018"

[dependencies]

Note that the real package I am working on has a github repository set, so the fake repository used here is not the issue.

The error is the following:

No package.homepage set in your Cargo.toml, trying package.repository
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /usr/local/rust/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-bitbake-0.3.16/src/git.rs:69:66
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Ignore the homepage part, that is easily fixed but the failure in git.rs remains.

With backtrace:

No package.homepage set in your Cargo.toml, trying package.repository
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /usr/local/rust/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-bitbake-0.3.16/src/git.rs:69:66
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
   3: cargo_bitbake::git::git_to_yocto_git_url
   4: cargo_bitbake::git::ProjectRepo::new
   5: cargo_bitbake::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I am using Rust version 1.64.0 (a55dd71d5 2022-09-19) on Linux Mint 21 (based on Ubuntu 22.04) on an x86-64 host.

Is this a bug or am I missing something in the Cargo.toml file?

cargo bitbake has trouble parsing a workspace Cargo.toml (root).

error: failed to parse manifest at `.../Cargo.toml`

Caused by:
  feature `resolver` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["resolver"]` to enable this feature

Adding cargo-features = ["resolver"] and moving to nightly still ends in failure.

This is from the root of a project with many packages. The root Cargo.toml looks something like this:

[workspace]
resolver = "2"
members = [
  "pkg_a",
  "pkg_a_tests",
  "pkg_b",
  "pkg_b/a/*",
  "pkg_b/b/a",
  "pkg_c",
  "pkg_d",
  "pkg_e",
  "pkg_f",
  "pkg_g",
  "pkg_h",
  "pkg_i",
  "pkg_j",
  "pkg_k",
  "pkg_l",
]

[profile.dev]
codegen-units = 1
split-debuginfo = "unpacked"

[profile.release]
codegen-units = 1
lto = true
opt-level = "z"

I wrote #34 . Since then my company has adopted a policy of always using -R. Is there any reason to behave the other way? I think it should probably be the default behavior, if not the only behavior.