cardoe / cargo-ebuild Goto Github PK

It appears (I did not investigate) that cargo-ebuild does not handle crates that are only available locally properly. E.g., try creating an ebuild for clippy @ 486300b89dd6b06f53061a193d3477ceb3740dee. Among others, the resulting ebuild will reference rustc_tools_util and that is not available on crates.io. So ultimately manifest creation for the ebuild will fail.

>>> Downloading 'https://crates.io/api/v1/crates/rustc_tools_util/0.1.0/download'
--2018-11-03 00:00:00--  https://crates.io/api/v1/crates/rustc_tools_util/0.1.0/download
Resolving crates.io... 52.0.94.50, 52.44.144.199, 52.86.186.182, ...
Connecting to crates.io|52.0.94.50|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-11-03 00:00:00 ERROR 404: Not Found.

Should/do we handle a local path inside of Cargo.toml properly?

Somebody posted this cross issue: cross-rs/cross#200

We don't know how to help the user or what it wants, but maybe somebody here knows.

cargo should be replaced with cargo-metadata.

When attempting to use cargo-ebuild to build a crate from source, it fails with the following error if using 2018 edition:

Using `cargo install` to install the binaries for the package in current working directory
is no longer supported, use `cargo install --path .` instead. Use `cargo build` if you
want to simply build the package.

This seems to be due to this change: rust-lang/cargo#5327

This error only happening when installing from a source archive (local crate), not from a downloaded crate.

cargo ebuild enhancment to git clone those really pesky SOB crates or if crate x is not in crates.io.

repoman DIE sourcing x,y but 99.5 % of crates sourced.

cargo ebuild --scrate git./bar....... --scrate url foo.git ....

git clone 2 crates that aint in crates.io or encase of know breakage under specific platforms...
git clone , >>> /work call down the crates , build done.. however such eclass sorcery might be (Gentoo Heresy at the moment)
ordo git to crate on the fly to shut up build system.
2 crates missing git clone > crate , git clone > crate done , building portage happy.
akin to EGO-sourcing in golang. as needed.

yank and bake .. do crates , cargo update toml 9999 ebuild equiv ...
might be related to workspace issues. ...

https://github.com/RustPython/RustPython not only a systems python but WASM ... lovely
gives cargo-ebuild Indigestion at times too.

starship shure it'll build fine under amd64 , however under Saki's Gentoo build for rpi4 repoman dies on the crates,
starship/starship#1431

artichoke
cannoli RUST PYTHON subset ie porthole gentoo killed might have ben able to perma freeze as a rust crate. ,

all pulls in rust overlay,..

reproduce as follows:

whubbs@whubbs1 ~ $ git clone [email protected]:wasmerio/wasmer
Cloning into 'wasmer'...
remote: Enumerating objects: 22, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 70416 (delta 5), reused 6 (delta 0), pack-reused 70394
Receiving objects: 100% (70416/70416), 57.83 MiB | 7.92 MiB/s, done.
Resolving deltas: 100% (56455/56455), done.
whubbs@whubbs1 ~ $ cd wasmer
/home/whubbs/wasmer
whubbs@whubbs1 wasmer $ git checkout 0.11.0
...
Note: switching to '0.11.0'.

...

HEAD is now at 8f50dab0f Trying to improve release process
whubbs@whubbs1 wasmer $ cargo-ebuild ebuild
failed to parse manifest at `/home/whubbs/wasmer/Cargo.toml`
whubbs@whubbs1 wasmer $

Any help would be appreciated.

Thanks,

William

cargo install --git known....

a few packages the authors are miffed by copycats on namespaces , are or ppl will poison the version update well..

cargo ebuild --git , IE add cargo vendor git-r3 9999 etc's to ebuild and git clone to rust crates / {misc auto-magically stuffs}
crates.io for more public.. crates..

other than that sub packages in project/root/sub-crate could use bits of love..

Recently I installed and configured my i3status-rust to my liking and everything but I couldn't get to specify colors to each of the blocks. I'm already using alternative_tint to change the background color of every alternate tabs but I wanted to specify colors according to my liking. So is there a way?

It seems cargo ebuild is generating a new ebuild every time, it might be a good idea to use the old ebuild as a base

it'd be great if cargo-ebuild could skip adding crates for packages present in workspace

detailed example here BurntSushi/ripgrep#1602 (comment)

build should have used local sources, instead of downloading .crate versions

for instance, for ripgrep-12.1.0 ebuild should not have contained the following lines:

globset-0.4.5
grep-0.2.6
grep-cli-0.1.4
grep-matcher-0.1.4
grep-pcre2-0.1.4
grep-printer-0.1.5
grep-regex-0.1.8
grep-searcher-0.1.7
ignore-0.4.15

because those are workspace members defined in Cargo.toml

https://github.com/BurntSushi/ripgrep/blob/e8822ce97a191d8a5830fd5b77b7ae424cd645b5/Cargo.toml#L31-L42

and I've run in situation where .crate was used instead of workspace member, and workspace member had some functionality that's not part of published .crate yet.

unable to generate working ebuild for sccache-0.2.13 for example.
seems to be omitting all deps that are marked optional or/and behind features.

sccache package is one of the few using features as useflags.

here's the diff between CRATES string generated by 0.2.0 and 0.3.0 created in the same source:

--- 0.2.0       2020-02-28 23:30:45.649771657 -0800
+++ 0.3.0       2020-02-28 23:30:03.467066148 -0800
@@ -5,6 +5,2 @@
 arc-swap-0.4.4
-arrayref-0.3.5
-arrayvec-0.5.1
-ascii-0.8.7
-ascii-0.9.3
 assert_cmd-0.9.1
@@ -20,7 +16,4 @@
 bitflags-1.2.1
-blake2b_simd-0.5.9
 block-buffer-0.7.3
 block-padding-0.1.5
-buf_redux-0.6.3
-bufstream-0.1.4
 byte-tools-0.3.1
@@ -33,8 +26,4 @@
 chrono-0.4.10
-chunked_transfer-0.3.1
 clap-2.33.0
 cloudabi-0.0.3
-combine-3.8.1
-conhash-0.4.0
-constant_time_eq-0.1.4
 cookie-0.12.0
@@ -48,3 +37,2 @@
 crossbeam-queue-0.1.2
-crossbeam-utils-0.5.0
 crossbeam-utils-0.6.6
@@ -57,3 +45,2 @@
 directories-1.0.2
-dirs-1.0.5
 dtoa-0.4.4
@@ -62,3 +49,2 @@
 env_logger-0.5.13
-error-chain-0.11.0
 error-chain-0.12.1
@@ -100,3 +86,2 @@
 jobserver-0.1.19
-jsonwebtoken-6.0.1
 kernel32-sys-0.2.2
@@ -105,4 +90,2 @@
 libc-0.2.66
-libmount-0.1.15
-libz-sys-1.0.25
 linked-hash-map-0.2.1
@@ -115,11 +98,6 @@
 maybe-uninit-2.0.0
-md-5-0.8.0
-md5-0.3.8
-memcached-rs-0.3.0
-memchr-1.0.2
 memchr-2.2.1
 memoffset-0.5.3
-mime-0.2.6
+md-5-0.8.0
 mime-0.3.14
-mime_guess-1.8.7
 mime_guess-2.0.1
@@ -132,7 +110,4 @@
 msdos_time-0.1.6
-multipart-0.13.6
 native-tls-0.2.3
 net2-0.2.33
-nix-0.11.1
-nix-0.14.1
 normalize-line-endings-0.2.2
@@ -151,6 +126,2 @@
 percent-encoding-2.1.0
-phf-0.7.24
-phf_codegen-0.7.24
-phf_generator-0.7.24
-phf_shared-0.7.24
 pkg-config-0.3.17
@@ -185,5 +156,3 @@
 rdrand-0.4.0
-redis-0.9.1
 redox_syscall-0.1.56
-redox_users-0.3.1
 regex-1.3.1
@@ -194,4 +163,2 @@
 ring-0.14.6
-rouille-2.2.0
-rust-argon2-0.5.1
 rustc-demangle-0.1.16
@@ -199,3 +166,2 @@
 ryu-1.0.2
-safemem-0.2.0
 safemem-0.3.3
@@ -215,3 +181,2 @@
 sha-1-0.8.1
-sha1-0.6.0
 sha2-0.8.0
@@ -219,3 +184,2 @@
 signal-hook-registry-1.2.0
-siphasher-0.2.3
 skeptic-0.4.0
@@ -234,3 +198,2 @@
 synstructure-0.12.3
-syslog-4.0.1
 tar-0.4.26
@@ -238,3 +201,2 @@
 tempfile-3.1.0
-term-0.5.2
 termcolor-1.0.5
@@ -242,5 +204,3 @@
 thread_local-0.3.6
-threadpool-1.7.1
 time-0.1.42
-tiny_http-0.6.2
 tokio-0.1.22
@@ -281,5 +241,3 @@
 try_from-0.3.2
-twoway-0.1.8
 typenum-1.11.2
-unicase-1.4.2
 unicase-2.6.0
@@ -290,4 +248,2 @@
 unicode-xid-0.2.0
-unix_socket-0.5.0
-unreachable-1.0.0
 untrusted-0.6.2
@@ -299,6 +255,4 @@
 vec_map-0.8.1
-version-compare-0.0.10
 version_check-0.1.5
 version_check-0.9.1
-void-1.0.2
 vte-0.3.3

Hi, I was looking into writing an ebuild script for rust-analyzer and use this tool to list all dependent crates, as per the Gentoo wiki.
However, I cloned their repository, ran cargo ebuild in the project root but it failed with

Error: cargo metadata failed to resolve the root package

I tried cargo ebuild with a bunch of other popular Rust repos such as ripgrep and bat; and it worked with all of them. There must be something with how the rust-analyzer code base is structured that cargo-ebuild doesn't like.

See the comment in this diff, generated license Apache-2.0 WITH LLVM-exception should be Apache-2.0-with-LLVM-exceptions.

A number of distros append NEEDED info into their package dependencies after the binaries have been built unlike Gentoo. So packages could get generated needing OpenSSL and the ebuild won't have that requirement. There should be some nice way around this.

I tried to use this to create an ebuild for i3status-rust but when attempting to do repoman manifest it fails since i3status-rust itself is not on crates.io

Being new to cargo & rust and trying to understand this i tried it on zoxide and du-dust (https://github.com/ajeetdsouza/zoxide, https://github.com/bootandy/dust).

In both cases it seems that when i follow the steps as described i get a good ebuild but the references to the package sources or the crate of the same is missing. Therefore i get a "error: could not find Cargo.toml in ..." for these when calling 'build'.
I can then add the package+version to the list of crates or add a reference to SRC_URI "https://github/user/{P}/archive/v${PV}.tar.gz -> ${P}.tar.gz" as i've seen it in another package.

I wanted to check if that is intended to be (then sorry for the question, might be worth mentioning in the docs) or a issue?
And of course if there is a preferred one of these two solutions.

I have a repo with two workspaces, structured like so:

my_repo
├── Cargo.toml
├── a
│   ├── Cargo.toml
│   └── src
└── b
     ├── Cargo.toml
     └── src

I want to make an ebuild for each workspace. When I use the --manifest-path flag, cargo ebuild uses the Cargo.toml in the root of the repo instead of the one in the argument, ex.

machinefossil@pc ~/my_repo $ cargo ebuild --manifest-path a/Cargo.toml
Error: cargo metadata failed: Error during execution of `cargo metadata`: error: failed to parse manifest at `/home/machinefossil/my_repo/Cargo.toml`

If I rename/remove the Cargo.toml in the root of the repo, --manifest-path then uses the path given to it as an argument.

When trying to build an ebuild for https://github.com/dani-garcia/bitwarden_rs cargo-ebuild failed over packages with versions without an official release.

What they did is adding a package version with:

rocket 0.5.0-dev (git+https://github.com/SergioBenitez/Rocket?rev=dbcb0a75b9556763ac3ab708f40c8f8ed75f1a1e)

There is no 0.5.0-dev version as this is just a commit.

Would it be possible to allow commits?

Hi,

I have a problem with cargo ebuild 0.4.0.
Whenever i try to create a ebuild from a rust project i'll get a error as follows:

Error: Failed to fetch security advisory database

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

This happens in every project. The same problem appears on a different machine too. With version 0.3.3 I don't have this problem which is why i had to downgrade now to version 0.3.3.

Hi,

I used cargo-ebuild to make an ebuild: https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/routinator/routinator-0.6.4.ebuild

But I can’t install it, I have an error:

>>> Source compiled.
>>> Test phase [not enabled]: net-misc/routinator-0.6.4

>>> Install net-misc/routinator-0.6.4 into /var/tmp/portage/net-misc/routinator-0.6.4/image
error: Using `cargo install` to install the binaries for the package in current working directory is no longer supported, use `cargo install --path .` instead. Use `cargo build` if 
you want to simply build the package.
 * ERROR: net-misc/routinator-0.6.4::SwordArMor failed (install phase):
 *   cargo install failed
 * 
 * Call stack:
 *     ebuild.sh, line 125:  Called src_install
 *   environment, line 965:  Called cargo_src_install
 *   environment, line 719:  Called die
 * The specific snippet of code:
 *       cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug --debug "") "$@" || die "cargo install failed";
 * 
 * If you need support, post the output of `emerge --info '=net-misc/routinator-0.6.4::SwordArMor'`,
 * the complete build log and the output of `emerge -pqv '=net-misc/routinator-0.6.4::SwordArMor'`.
 * The complete build log is located at '/var/tmp/portage/net-misc/routinator-0.6.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-misc/routinator-0.6.4/temp/environment'.
 * Working directory: '/var/tmp/portage/net-misc/routinator-0.6.4/work/routinator-0.6.4'
 * S: '/var/tmp/portage/net-misc/routinator-0.6.4/work/routinator-0.6.4'

When running cargo-ebuild for alacritty, the crate servo/rust-fontconfig is pulled instead of its fork (jwilm/rust-fontconfig) declared by Cargo.lock.

That causes the src_compile phase to die because cargo can't find the correct dependency.

It has been deprecated: announcement.

Looks like this is blocked on rust-lang/cargo#3944. I will follow up in this issue when they have a new release ready.

-sys crates often try to link to system libraries, and if not found will compile own private copy.
notable examples are
libgit2-sys (uses unreleased ABI and will fail at runtime if tries to link to system library), but requires setting LIBGIT2_SYS_USE_PKG_CONFIG=1 to force looking for it.
onig-sys, will try to link to system oniguruma if it's found, and will compile private version if not.
prcre2-sys, will try system, and will compile own static if not found.
and more.

is it possible to modify cargo-ebuild to place a reminder if -sys crate is found in the depgraph? so users should check.

tracker bug in gentoo https://bugs.gentoo.org/709568

Please, can you add some kind of documentation that explains how to use and invoke the command-line tool for a real case scenario? People not used to rust/cargo will have hard times figuring it out. Thank you.

crates can define features and we should enumerate them as USE flags

For example double quotes in the descriptions leak as-is into the ebuild. This is invalid, because in this ebuild the description is also enclosed in quotes

Apologies if this is not the appropriate place to report this, please feel free to redirect if so.

Upon trying to build cargo with LibreSSL 2.6.4 (upgrading from LibreSSL 2.6.0 ) on Gentoo, the build errors out with:

thread 'main' panicked at '

This crate is only compatible with OpenSSL 1.0.1, 1.0.2, and 1.1.0, or LibreSSL
2.5 and 2.6.0, but a different version of OpenSSL was found. The build is now
aborting due to this version mismatch.

LibreSSL 2.6.0 is a development release, of which LibreSSL 2.6.3 and 2.6.4 are marked as stable. It would be beneficial to allow the build dependencies for cargo to allow a match of either of these later releases so people can move away from potentially unstable development releases.

Contrast and compare the release notes:
LibreSSL 2.6.0 Release Notes
LibreSSL 2.6.3 Release Notes
LibreSSL 2.6.4 Release Notes

I've attached the full log from my attempt to emerge to LibreSSL 2.6.4.

Thanks!
cargo_build_log_failure_libressl_2.6.4.txt

Ok this is the first time i have this issue with cargo-ebuild
i was trying to make ebuild for broot version 1.2.8
running cargo ebuild generates a template successfully but with missing dependencies such as terminal-clipboard ahash and many more, i had to add them manually, is this expected behavior of this tool?

The RESTRICT="mirror" setting should be used if we cannot legally mirror certain files; files will still be downloaded from the original locations.

Mirrors – Gentoo Development Guide

Many projects written in Rust are OSS (as far as I know), and RESTRICT=mirror seems not necessary for such usual OSS applications, especially when we want ebuild files for them.

Why is this line included in default template?

If this exists for safety (i.e. to prevent accidentally mirroring proprietary stuff), then I want some comments in the template to indicate when this line is necessary and when unnecessary.

At present, the generated ebuilds seem to be licensed GPLv2 only, which seems to be incompatible with generating ebuilds for software licensed under the GPLv3.

Other package manager plugins for distros store configuration bits for packages in Cargo.toml and this project should likely do the same so that upstreams can help control how things get installed.