meta-rust / cargo-bitbake Goto Github PK

I am using cargo-bitbake to create a recipe for the project cloud-hypervisor (https://github.com/cloud-hypervisor/cloud-hypervisor/)
After starting the build using meta-rust layer it got failed with the following error.

error: failed to select a version for vmm.
| ... required by package cloud-hypervisor v0.4.0 (/home/muislam/work/linux-yocto/image-x86-64/tmp/work/core2-64-msft-linux/cloud-hypervisor/git.AUTOINC+7cb61d3960-r0/git)
| versions that meet the requirements = 0.1.0 are: 0.1.0
|
| the package cloud-hypervisor depends on vmm, with features: cmos, pci_support, acpi but vmm does not have these features.

Generated recipe:

`
inherit cargo

SRC_URI += "git://github.com/cloud-hypervisor/cloud-hypervisor.git;protocol=https;nobranch=1"
SRCREV = "7cb61d396032aa982e974c36d205aecdd43d67a9"
S = "${WORKDIR}/git"
CARGO_SRC_DIR = ""
PV_append = ".AUTOINC+7cb61d3960"

SRC_URI += "
crate://crates.io/aho-corasick/0.6.10
crate://crates.io/ansi_term/0.11.0
crate://crates.io/anyhow/1.0.26
crate://crates.io/arc-swap/0.4.4
crate://crates.io/arrayref/0.3.6
crate://crates.io/arrayvec/0.5.1
crate://crates.io/atty/0.2.14
crate://crates.io/autocfg/0.1.7
crate://crates.io/autocfg/1.0.0
crate://crates.io/backtrace-sys/0.1.32
crate://crates.io/backtrace/0.3.43
crate://crates.io/base64/0.11.0
crate://crates.io/bitflags/0.5.0
crate://crates.io/bitflags/1.2.1
crate://crates.io/blake2b_simd/0.5.10
crate://crates.io/byteorder/1.3.2
crate://crates.io/c2-chacha/0.2.3
crate://crates.io/cast/0.2.3
crate://crates.io/cc/1.0.50
crate://crates.io/cfg-if/0.1.10
crate://crates.io/clap/2.33.0
crate://crates.io/cloudabi/0.0.3
crate://crates.io/constant_time_eq/0.1.5
crate://crates.io/credibility/0.1.3
crate://crates.io/crossbeam-utils/0.7.0
crate://crates.io/dirs-sys/0.3.4
crate://crates.io/dirs/2.0.2
crate://crates.io/epoll/4.1.0
crate://crates.io/failure/0.1.6
crate://crates.io/failure_derive/0.1.6
crate://crates.io/fuchsia-cprng/0.1.1
crate://crates.io/getrandom/0.1.14
crate://crates.io/glob/0.2.11
crate://crates.io/hermit-abi/0.1.6
crate://crates.io/ipnetwork/0.15.1
crate://crates.io/itoa/0.4.5
crate://crates.io/kernel32-sys/0.2.2
crate://crates.io/kvm-bindings/0.2.0
crate://crates.io/kvm-ioctls/0.5.0
crate://crates.io/lazy_static/1.4.0
crate://crates.io/libc/0.2.66
crate://crates.io/libssh2-sys/0.2.14
crate://crates.io/libz-sys/1.0.25
crate://crates.io/lock_api/0.3.3
crate://crates.io/log/0.3.9
crate://crates.io/log/0.4.10
crate://crates.io/memchr/2.3.0
crate://crates.io/openssl-sys/0.9.54
crate://crates.io/parking_lot/0.10.0
crate://crates.io/parking_lot_core/0.7.0
crate://crates.io/pkg-config/0.3.17
crate://crates.io/pnet/0.25.0
crate://crates.io/pnet_base/0.22.0
crate://crates.io/pnet_datalink/0.25.0
crate://crates.io/pnet_macros/0.25.0
crate://crates.io/pnet_macros_support/0.25.0
crate://crates.io/pnet_packet/0.25.0
crate://crates.io/pnet_sys/0.25.0
crate://crates.io/pnet_transport/0.25.0
crate://crates.io/ppv-lite86/0.2.6
crate://crates.io/proc-macro2/1.0.8
crate://crates.io/quote/1.0.2
crate://crates.io/rand/0.4.6
crate://crates.io/rand/0.7.3
crate://crates.io/rand_chacha/0.2.1
crate://crates.io/rand_core/0.3.1
crate://crates.io/rand_core/0.4.2
crate://crates.io/rand_core/0.5.1
crate://crates.io/rand_hc/0.2.0
crate://crates.io/rdrand/0.4.0
crate://crates.io/redox_syscall/0.1.56
crate://crates.io/redox_users/0.3.4
crate://crates.io/regex-syntax/0.6.14
crate://crates.io/regex/1.0.6
crate://crates.io/remain/0.2.1
crate://crates.io/remove_dir_all/0.5.2
crate://crates.io/rust-argon2/0.7.0
crate://crates.io/rustc-demangle/0.1.16
crate://crates.io/rustc-serialize/0.3.24
crate://crates.io/rustc_version/0.2.3
crate://crates.io/ryu/1.0.2
crate://crates.io/scopeguard/1.0.0
crate://crates.io/semver-parser/0.7.0
crate://crates.io/semver/0.9.0
crate://crates.io/serde/1.0.104
crate://crates.io/serde_derive/1.0.104
crate://crates.io/serde_json/1.0.46
crate://crates.io/signal-hook-registry/1.2.0
crate://crates.io/signal-hook/0.1.13
crate://crates.io/smallvec/1.2.0
crate://crates.io/ssh2/0.7.1
crate://crates.io/strsim/0.8.0
crate://crates.io/syn/1.0.14
crate://crates.io/synstructure/0.12.3
crate://crates.io/syntex/0.42.2
crate://crates.io/syntex_errors/0.42.0
crate://crates.io/syntex_pos/0.42.0
crate://crates.io/syntex_syntax/0.42.0
crate://crates.io/tempdir/0.3.7
crate://crates.io/tempfile/3.1.0
crate://crates.io/term/0.4.6
crate://crates.io/textwrap/0.11.0
crate://crates.io/thiserror-impl/1.0.10
crate://crates.io/thiserror/1.0.10
crate://crates.io/thread_local/0.3.6
crate://crates.io/unicode-width/0.1.7
crate://crates.io/unicode-xid/0.0.3
crate://crates.io/unicode-xid/0.2.0
crate://crates.io/utf8-ranges/1.0.4
crate://crates.io/vcpkg/0.2.8
crate://crates.io/vec_map/0.8.1
crate://crates.io/virtio-bindings/0.1.0
crate://crates.io/vmm-sys-util/0.4.0
crate://crates.io/wasi/0.9.0+wasi-snapshot-preview1
crate://crates.io/winapi-build/0.1.1
crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0
crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0
crate://crates.io/winapi/0.2.8
crate://crates.io/winapi/0.3.7
crate://crates.io/ws2_32-sys/0.2.1
git://github.com/firecracker-microvm/firecracker;protocol=https;nobranch=1;name=micro_http;destsuffix=micro_http
git://github.com/rust-vmm/linux-loader;protocol=https;nobranch=1;name=linux-loader;destsuffix=linux-loader
git://github.com/rust-vmm/vfio-bindings;protocol=https;nobranch=1;name=vfio-bindings;destsuffix=vfio-bindings
git://github.com/rust-vmm/virtio-bindings;protocol=https;nobranch=1;name=virtio-bindings;destsuffix=virtio-bindings
git://github.com/rust-vmm/vm-memory;protocol=https;nobranch=1;name=vm-memory;destsuffix=vm-memory
"

SRCREV_FORMAT .= "_linux-loader"
SRCREV_linux-loader = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/linux-loader"
SRCREV_FORMAT .= "_micro_http"
SRCREV_micro_http = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/micro_http"
SRCREV_FORMAT .= "_vfio-bindings"
SRCREV_vfio-bindings = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/vfio-bindings"
SRCREV_FORMAT .= "_virtio-bindings"
SRCREV_virtio-bindings = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/virtio-bindings"
SRCREV_FORMAT .= "_vm-memory"
SRCREV_vm-memory = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/vm-memory"

LIC_FILES_CHKSUM = "
"

SUMMARY = "DDD"
HOMEPAGE = "https://github.com/cloud-hypervisor/cloud-hypervisor"
LICENSE = "CLOSED"

include cloud-hypervisor-${PV}.inc
include cloud-hypervisor.inc
`

Hello,

I'm having trouble using cargo-bitbake to generate a recipe for a crate that has workspace dependencies. For example, if a dependency is declared like this in one of the workspace members:

foo123 = { workspace = true }

I have the following error:

error: no matching package named `foo123` found
location searched: registry `crates-io`
required by package `foo v0.1.0 (...)`

Something interesting is that if instead of foo123 I use a name that exists on crates.io it will resolve to this crate instead of the crate defined in the workspace Cargo.toml.

I made a minimal example that reproduces this bug here.

Please let me know if I can be of any help for resolving this issue!

Hi, this might be my relative inexperience with bitbake speaking but I was quite surprised when my package, foo_bar encountered a bunch of (nothing provides foo_bar) errors when using the recipe generated by this crate.

Turns out the problem was that bb doesn't allow underscores in package names and changing it to foo-bar fixed everything.

I feel like cargo-bitbake could at least produce a warning in this case, since the file it is producing is not a valid bitbake file.
I'm not sure I'd advocate for a hard error or an implicit transformation of the name, since it's always possible to change the generated file by hand.

Hi,

I've used cargo-bitbake to generate recipe for netvark. I'm trying to compile it in poky kirkstone but getting this error:

| DEBUG: Executing shell function do_compile
| NOTE: cargo = /data/projects/test/project/build/tmp/work/cortexa53-crypto-poky-linux/netavark/1.8.0-r0/recipe-sysroot-native/usr/bin/cargo
| NOTE: rustc =
| NOTE: cargo build -v --target aarch64-poky-linux --release --manifest-path=/data/projects/test/project/build/tmp/work/cortexa53-crypto-poky-linux/netavark/1.8.0-r0/git//Cargo.toml
| error: failed to get `anyhow` as a dependency of package `netavark v1.8.0 (/data/projects/test/project/build/tmp/work/cortexa53-crypto-poky-linux/netavark/1.8.0-r0/git)`
|
| Caused by:
|   failed to load source for dependency `anyhow`
|
| Caused by:
|   Unable to update registry `crates-io`
|
| Caused by:
|   failed to update replaced source registry `crates-io`
|
| Caused by:
|   failed to parse manifest at `/data/projects/test/project/build/tmp/work/cortexa53-crypto-poky-linux/netavark/1.8.0-r0/cargo_home/bitbake/regex-1.9.5/Cargo.toml`
|
| Caused by:
|   namespaced features with the `dep:` prefix are only allowed on the nightly channel and requires the `-Z namespaced-features` flag on the command-line
| WARNING: exit code 101 from a shell command.

Any ideas what would be needed to have it working please? Thanks.

I'm getting the following error:

error: failed to parse lock file at: Cargo.lock

Caused by:
  invalid serialized PackageId for key `package.dependencies`

Probably this is caused by rust-lang/cargo#7579 (I found this reference in sfackler/cargo-tree#80, where the same issue was reported).

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.

When running cargo-bitbake bitbake in a package containing a Git SSH dependency, the URL is then mangled and copied into SRC_URI. This is an unnecessary step as the Git dependency does not need to be in the SRC_URI (the package builds fine without it) and the URL string is malformed.

For example, the following dependency in Cargo.toml:

[dependencies]
testlib = { git = "ssh://[email protected]:10022/test/testlib.git" }

Is converted to the following in SRC_URI:

git://ssh///[email protected]/10022/test/testlib.git;protocol=ssh;nobranch=1;name=testlib;destsuffix=testlib 

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?

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'm working on a recipe for OpenEthereum.
I ran $ cargo-bitbake bitbake on a clone of the repository (checked out at v3.2.5 tag).

However BitBake wasn't able to parse the resulting recipe:

                     try:
    >                    self.ud[url] = FetchData(url, d, localonly)
                     except NonLocalMethod:
  File "/home/bernardo/develop/oe-dev/oe-core/bitbake/lib/bb/fetch2/__init__.py", line 1277, in FetchData.__init__(url='git://github.com/gnosis/reth.git;protocol=https;nobranch=1;name=reth-util;destsuffix=reth-util', d=<bb.data_smart.DataSmart object at 0x7fa853421970>, localonly=False):
             if hasattr(self.method, "urldata_init"):
    >            self.method.urldata_init(self, d)
     
  File "/home/bernardo/develop/oe-dev/oe-core/bitbake/lib/bb/fetch2/git.py", line 243, in Git.urldata_init(ud=<bb.fetch2.FetchData object at 0x7fa8532f6a30>, d=<bb.data_smart.DataSmart object at 0x7fa853421970>):
                         ud.unresolvedrev[name] = ud.revisions[name]
    >                ud.revisions[name] = self.latest_revision(ud, d, name)
     
  File "/home/bernardo/develop/oe-dev/oe-core/bitbake/lib/bb/fetch2/__init__.py", line 1581, in Git.latest_revision(ud=<bb.fetch2.FetchData object at 0x7fa8532f6a30>, d=<bb.data_smart.DataSmart object at 0x7fa853421970>, name='reth-util'):
             except KeyError:
    >            revs[key] = rev = self._latest_revision(ud, d, name)
                 return rev
  File "/home/bernardo/develop/oe-dev/oe-core/bitbake/lib/bb/fetch2/git.py", line 703, in Git._latest_revision(ud=<bb.fetch2.FetchData object at 0x7fa8532f6a30>, d=<bb.data_smart.DataSmart object at 0x7fa853421970>, name='reth-util'):
                         return sha1
    >        raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git repository in git ls-remote output for %s" % \
                 (ud.unresolvedrev[name], ud.host+ud.path))
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve '573e128' in upstream git repository in git ls-remote output for github.com/gnosis/reth.git

It seems BitBake doesn't understand the reduced version of the commit hash 573e128.
So I did a $ grep -rn . -e 573e128 inside the openethereum local clone and arrived to the following line of Cargo.lock:

source = "git+https://github.com/gnosis/reth.git?rev=573e128#573e128487d5651f301e21faa97fc8e80f91dee8"

So I applied the following modification to the generated BB recipe:

- SRCREV_reth-util = "573e128"
+ SRCREV_reth-util = "573e128487d5651f301e21faa97fc8e80f91dee8"

And BitBake was able to parse it.

I would love to submit a PR to help cargo-bitbake avoid this error in the future.
Should we modify some of the logic here? (tagging @cardoe cause I believe you wrote this block)

                let rev = match *src_id.git_reference()? {
                    GitReference::Tag(ref s) | GitReference::Rev(ref s) => s.to_owned(),
                    GitReference::Branch(ref s) => {
                        if s == "master" {
                            String::from("${AUTOREV}")
                        } else {
                            s.to_owned()
                        }
                    }
                    GitReference::DefaultBranch => String::from("${AUTOREV}"),
                };

The idea is to have the rev variable pick up the entire commit hash (instead of the reduced form) whenever the package is listed in Cargo.lock under the following format:

source = "git+https://<URL>?rev=<reduced_hash>#<full_hash>"

Perhaps a new match case? Or some specific function from git2 crate?

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

cargo-bitbake doesn't support edition 2021 in Cargo.toml

$ cargo bitbake
error: failed to parse manifest at `/home/snke/git/xxx/Cargo.toml`

Caused by:
  failed to parse the `edition` key

Caused by:
  this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.
$ cargo bitbake --version
cargo-bitbake 0.3.15

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.

Installed with cargo install cargo-bitbake --locked, as per the workaround in #29 (comment) .

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"

It has been deprecated: announcement.

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'?

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.

When the key rust-version.workspace is used in the [package] group, i get this error:

error: failed to load manifest for workspace member `/home/devel/projects/slintui/slint/api/cpp`

Caused by:
  failed to parse manifest at `/home/devel/projects/slintui/slint/api/cpp/Cargo.toml`

Caused by:
  invalid type: map, expected a string for key `package.rust-version`

Contents of the Config.toml:

[package]
...
rust-version.workspace = true

The build fails with todays stable and nightly; I successfully built the tip today.

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,
We tried to build cargo-bitbake as part of yocto.
Yocto is upgraded to openssl-3.0 so cargo-bitbake recipe fails while building openssl-sys v0.9.54 which is dependent for carg-bitbake.

Recipe(.bb) and build failure log is attached,

Below patch resolves the issue

sfackler/rust-openssl@b4c735e
But the patch is not mainlined :(.

build_failure.txt

cargo-bitbake_0.3.16-alpha.0.bb.txt

Any plan on supporting openssl3 for cargo-bitbake?

Similar to a cargo.lock file containing the exact revision of a git repo, I want my bitbake recipes, especially when covering internal deps, to do the same. I don't think this should necessary be the default behavior, but I think it should be an option.

I have posted a pull request to accomplish this.

I have a simple project consisting of a core library, the main package and a helper script:

project
|- Cargo.toml
|- lib
   |- Cargo.toml
|- pkg1
   |- Cargo.toml
|- pkg2
   |- Cargo.toml

The root Cargo.toml is virtual, meaning it only defines the workspace members:

[workspace]
members = ["lib", "pkg1", "pkg2"]

I would expect cargo-bitbake to generate a bitbake recipe including the dependencies for all three packages.

Thanks.

I see multiple important PRs, solving many of the issues raised. Is this repo still maintained?

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"

Looking at the same output as #17, the FIXME message for incomplete license file checksums is present in the recipe even if all checksums have been successfully resolved:

# FIXME: update generateme with the real MD5 of the license file
LIC_FILES_CHKSUM = " \
    file://hello/LICENSE;md5=86d3f3a95c324c9479bd8986968f4327 \
"

This is liable to confuse anyone searching for FIXME tags in a repository.

I see that this line is present in the template text. Perhaps instead there should be a placeholder like {lic_files_fixme} which can be set to an empty string if all checksums are resolved, or to the fixme warning if some checksums were not resolved.

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?

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.

As in the title - running cargo-bitbake modifies my Cargo.lock, and removes a dependency (valuable-derive).

The issue seems to revolve around honoring the dependency chain tracing-core->valuable->valuable-derive. In tracing the support (and requirement) for valuable depends on a configuration flag (--cfg tracing_unstable). It is set in my $HOME/.cargo/config.toml, but cargo-bitbake seems to not honor it.

I can confirm that manually adding the depenency, either in my Cargo.toml, or in the generated bitbake file, fixes the build.

Overall, this is kind of weird, and raises a few questions:

• Why is cargo-bitbake modifying Cargo.lock in the first place?
• Why is cargo-bitbake not honoring my .cargo/config.toml settings?
• How can this be fixed?
• Is there any workaround?

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.

Hi,

I am trying to use "cargo bitbake" to generate a recipe for the gst-plugins-rs 0.12.4 version:

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/0.12?ref_type=heads

but I am getting the following error:

$ cargo bitbake
error: failed to load manifest for workspace member `/home/fabio/gst-plugins-rs/tutorial`

Caused by:
  failed to parse manifest at `/home/fabio/gst-plugins-rs/tutorial/Cargo.toml`

Caused by:
  invalid type: map, expected SemVer version for key `package.version`

The Cargo.toml that fails to parse is this one:

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/0.12/tutorial/Cargo.toml?ref_type=heads

Any ideas, please?

Currently we will always use the git fetcher but there are situations when the git submodule fetcher needs to be used instead and we need to detect those.

Request

add two options to cargo bitbake to add specific files and all source files to the recipe SRC_URI variable.

example specific files:

    > cargo bitbake --add-source ./resources/config.toml  --add-source ./src/mod1/lib.rs
    # adds the repo to SRC_URI
    # adds additional two files to SRC_URI

example all files:

    > cargo bitbake --no-repo --add-all-source 
    # does not add the repo url to SRC_URI
    # adds all sources to the SRC_URI

Reasons

one may have multiple recipes in one repository (e.g. we have a repo for driver, one for tools and one for client apps). Currently cargo bitbake cannot create recipes for rust projects if they are not separated each into one repository.

When using a git url in a dependency, the following error appears:

    Updating git repository `https://github.com/slint-ui/slint`
error: no matching package named `slint` found
location searched: https://github.com/slint-ui/slint?branch=master#ef82edca
required by package `slint-text-rendering-artifact-demo v0.1.0 (/home/devel/repos/slint-text-rendering-artifact-demo)`

The Cargo.toml looks like this:

[package]
name = "slint-text-rendering-artifact-demo"
version = "0.1.0"
edition = "2021"
build = "build.rs"

[dependencies]
slint = { git = "https://github.com/slint-ui/slint", branch = "master" }

[build-dependencies]
slint-build = { git = "https://github.com/slint-ui/slint", branch = "master" }

In order to use auto-generated recipe without changes, one needs to edit the usage of '_' in the recipe name references.

Example Rust project

registration_server

Auto-generated

registration_server_0.4.0.bb
registration_server-${PV}.inc
registration_server.inc

In order to build correctly OE recipe requires changing '_' to '-'. Such as:

registration-server_0.4.0.bb

The '_' is used to prefix ${PV}

Cargo bitbake should automatically handle this, so the auto-generated recipe can be used as-is.

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-index`
error: no matching version ^0.4 found for package num-bigint (required by rsa)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.2.3, 0.2.2, 0.2.1, ...
`

cargo 1.37.0 (9edd08916 2019-08-02)

I have a workspace with two simple projects in it: a hello project with no dependencies and a print-rand project that depends on the rand crate. This workspace can be seen here: https://gitlab.com/pbarker.dev/learn-rust/-/tree/711141cb58ccb241b1c6b13454746bd28b106de7

If I run cargo bitbake in the directory of the hello project, the dependencies of the print-rand project are also included in SRC_URI.

[pbarker@ar2 hello]$ cargo bitbake --version
cargo-bitbake 0.3.14
[pbarker@ar2 hello]$ cargo bitbake
Wrote: hello_0.1.0.bb
[pbarker@ar2 hello]$ cat hello_0.1.0.bb 
# Auto-Generated by cargo-bitbake 0.3.14
#
inherit cargo

# If this is git based prefer versioned ones if they exist
# DEFAULT_PREFERENCE = "-1"

# how to get hello could be as easy as but default to a git checkout:
# SRC_URI += "crate://crates.io/hello/0.1.0"
SRC_URI += "git://[email protected]/pbarker.dev/learn-rust.git;protocol=ssh;nobranch=1;branch=dev"
SRCREV = "711141cb58ccb241b1c6b13454746bd28b106de7"
S = "${WORKDIR}/git"
CARGO_SRC_DIR = "hello"
PV_append = ".AUTOINC+711141cb58"

# please note if you have entries that do not begin with crate://
# you must change them to how that package can be fetched
SRC_URI += " \
    crate://crates.io/cfg-if/0.1.10 \
    crate://crates.io/getrandom/0.1.15 \
    crate://crates.io/libc/0.2.77 \
    crate://crates.io/ppv-lite86/0.2.9 \
    crate://crates.io/rand/0.7.3 \
    crate://crates.io/rand_chacha/0.2.2 \
    crate://crates.io/rand_core/0.5.1 \
    crate://crates.io/rand_hc/0.2.0 \
    crate://crates.io/wasi/0.9.0+wasi-snapshot-preview1 \
"



# FIXME: update generateme with the real MD5 of the license file
LIC_FILES_CHKSUM = " \
    file://hello/LICENSE;md5=86d3f3a95c324c9479bd8986968f4327 \
"

SUMMARY = "Hello World application"
HOMEPAGE = "https://gitlab.com/pbarker.dev/learn-rust/-/tree/dev/hello"
LICENSE = "Apache-2.0"

# includes this file if it exists but does not fail
# this is useful for anything you may want to override from
# what cargo-bitbake generates.
include hello-${PV}.inc
include hello.inc

I suspect that the dependencies are being resolved at the workspace level instead of at the project level but I'm not familiar enough with the cargo API to be sure on this or to suggest how to fix it.

If we run cargo-bitbake for a Rust project which has a multi-line description entry in the Cargo.toml file, it generates a recipe which bitbake cannot parse.

For example, running cargo-bitbake for ripgrep 12.1.1 results in this issue. See the Cargo.toml file: https://github.com/BurntSushi/ripgrep/blob/def993bad1a9275cdc249f04048e5b2065b79f05/Cargo.toml

cargo-bitbake should either generate a shorter summary, merge the description onto one line or use line continuation characters (i.e. \) in the recipe.

Currently, cargo-bitbake generates the appropriate license metadata so that bitbake can verify the license file of the top-level crate. However, it also needs to generate the license metadata for dependent crates so that bitbake can verify all of the licenses when building the package.

When trying to build a recipe generated by the latest master cargo bitbake with Bitbake 4.0, the following error is thrown:

do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)

This check was recently added: https://lists.openembedded.org/g/bitbake-devel/topic/89051455#13344

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>