mmstick / cargo-deb Goto Github PK
View Code? Open in Web Editor NEWA cargo subcommand that generates Debian packages from information in Cargo.toml
A cargo subcommand that generates Debian packages from information in Cargo.toml
Granted I'm very new to this, but I'm struggling to figure out how to take the generated debian
folder and turn it into something I can actually put in a PPA on launchpad.net. A short example in the README would go a long way here.
I've been working on this project for a while, which is implemented in Rust and generates entire debian APT repositories ready to host. It supports a number of means for practically building software from sources w/ sbuild; or grabbing pre-built debian archives that need not be built at all.
Perhaps getting support in the config for automatically pulling / building Rust projects that use cargo-deb
would be nice. I think it might be implemented as simply as
[[cargo-deb]]
git = "$git_url"
[[cargo-deb]]
url = "$tar_url"
checksum = "$SHA256"
Those interested in this project might also be interested in the project. The existing tools for generating Debian archives is kind of sad, and official solutions do not use multi-core CPUs. IE: apt-ftparchive
reads debian archives serially on a single core when generating the data for the Packages file, but debrep
can does this and more in parallel with all available CPU cores (including generating the Contents files in parallel so that tools like apt-file
are supported by your repo).
The target/debian folder contains temp files. These could be moved into sub folders or deleted to make it clear only the deb file is the product.
I want to easily put my software into a ppa, which requires me to build a src deb. I'm not super experienced with debian packaging but that sounds like the kind of thing that could be a by-product of this crate?
Is that possible?
We override CARGO_TARGET_DIR to prebuild dependencies in cached Docker layer and later to reuse them during regular builds. Right now it doesn't seem possible to encode environment-dependant path in assets property, but it would be nice to at least for this particular usecase.
Hello,
I'm running cargo-deb in the SUPERAndroidAnalyzer/super repository, and I get the following error with three files, all of them command line completions:
strip:/home/razican/workspace/super/super/target/release/super.bash: File format not recognized
cargo-deb: Command strip failed to launch
because: exit code: 1
The affected files are the following:
super.bash
super.fish
_super
In a constrained container with 1 GB RAM, cargo-deb has not enough memory:
cargo deb --no-build
warning: extended-description field missing. Using README.md, but markdown may not render well.
cargo-deb: Command ar failed to launch
because: Cannot allocate memory (os error 12)
(Building a large project with cargo before works though.)
Hi,
Since the last version, there is as behaviour change in the way assets are resolved where the project cargo-deb
is runing on is is a workspace
Here is a sample dir hierarchy with a project in a workspace
workspace-dir
|--> debified-project
| |--> src
| |--> resources
| | \-> stuff.json
| \--> Cargo.toml
|--> other-workspace-project
\--> Cargo.toml
(I run cargo-deb
on the debified-project
with a (cd debified-project && cargo-deb)
)
In previous versions, to include stuff.json
in the deb I had to add this line to the [package.metadata.deb]
of the Cargo.toml
of debified-project
assets = [ [ "resources/stuff.json", "/usr/share", 644 ] ]
with the last versions (I suspect commit dabd655 ) I now need to write this
assets = [ [ "debified-project/resources/stuff.json", "/usr/share", 644 ] ]
The root dir used to resolve assets is now the root of the workspace and not the root of the project. I'm not sure it is a good idea because:
..
is your friend)path
of a depencency)Is it possible to get back to the previous behaviour ?
Currently, if a folder wants to be added as an asset, this is not possible:
assets = [
["vendor/*", "var/lib/app/vendor/", "755"],
]
There is no option to put all the files in one folder in another folder, and we need to copy all files in that directory one by one. Could this be fixed? It would be great to be able to use wildcards at least.
https://www.debian.org/doc/debian-policy/#changelog-files -> changelog.gz
So
Line 102 in d5e7d52
Take for example the mutt
dependencies from the debian doc that is referenced in https://github.com/mmstick/cargo-deb/blob/master/README.md.
"libc6 (>= 2.2.1), exim | mail-transport-agent"
What's the recommended way to actually provide dependencies right now? Imho the simplest approach would be to test for $auto
or just pass the string literal as is.
When building a rust application that depends on libssl cargo deb
fails to correctly identify the dependencies since the path used by the linker is not the path that dpkg
knows.
The error I am seeing is:
warning: path '/lib/x86_64-linux-gnu/libssl.so.1.1' does not belong to a package: dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libssl.so.1.1
(no auto deps for /builds/foo/target/release/my-project)
When checking with dpkg-query
myself I can confirm the situation.
# dpkg-query -S /lib/x86_64-linux-gnu/libssl.so.1.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libssl.so.1.1
It looks like in the libssl
case the file in /lib/…
is being created by some kind of (multiarch?) trigger during installation of libssl:
# dpkg-query -S /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl1.1:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.1
When looking at the compiled binary it becomes clear why cargo-deb
selects those files:
# ldd target/release/my-project
[…]
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f2f19d6b000)
[…]
The files share the same inode so probably a hardlink that was installed by some postinst debian trigger.
# stat /lib/x86_64-linux-gnu/libssl.so.1.1
File: /lib/x86_64-linux-gnu/libssl.so.1.1
Size: 442920 Blocks: 872 IO Block: 4096 regular file
Device: 71h/113d Inode: 7340 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-08-30 15:08:33.773978673 +0000
Modify: 2017-06-05 09:40:42.000000000 +0000
Change: 2017-08-30 15:08:32.547311134 +0000
Birth: -
# stat /usr/lib/x86_64-linux-gnu/libssl.so.1.1
File: /usr/lib/x86_64-linux-gnu/libssl.so.1.1
Size: 442920 Blocks: 872 IO Block: 4096 regular file
Device: 71h/113d Inode: 7340 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-08-30 15:08:33.773978673 +0000
Modify: 2017-06-05 09:40:42.000000000 +0000
Change: 2017-08-30 15:08:32.547311134 +0000
Birth: -
Switching the ld.so.conf
multiarch configuration to first look in /usr/lib/
doesn't fix the issue since then all other libraries fail.
I am not sure if this a the fault of debian or cargo-deb. Any ideas? I don't mind opening a bug in the debian bug tracker (if libssl is packaged wrong or inconsistent with common practice)
Getting cargo-deb is a bit of a hassle right now. Especially if you would like to build your artifacts/debs automatically on e.g. travis, you need to checkout cargo-deb and build it at first, then modify the path to include it, before you may package your own crate.
This could be so much easier, if it would be possible to do a simple cargo install cargo-deb
.
I've two VMs with Debian Stretch 64bit and Debian Stretch 32bit. On the 64bit VM, everything's fine. But on the 32bit VM, I get the following error:
cargo deb: IO error
because: unsupported compression options
I'm pretty sure that the setup of both VMs is the same (except the architecture).
This is generally better for security reasons to not run cargo via root, and it also works well with rustup.
When trying to run cargo deb
I get error: no such subcommand: deb
.
My cargo.toml file looks like this:
[package]
name = "package-name"
version = "0.2.0"
authors = ["Alex Bowers <[email protected]>"]
[dependencies]
tiny_http = "0.5"
cargo-deb = { git = "https://github.com/mmstick/cargo-deb" }
[package.metadata.deb]
maintainer = "Alex Bowers <[email protected]>"
copyright = "2017 xxx <[email protected]>"
license_file = ["LICENSE", "3"]
depends = "$auto"
extended_description = """\
Package Description."""
section = "admin"
priority = "optional"
assets = [
["assets/org.freedesktop.policykit.systemd-manager.policy", "usr/share/polkit-1/actions/", "644"],
["assets/systemd-manager.desktop", "usr/share/applications/", "644"],
["assets/systemd-manager-pkexec", "usr/bin/", "755"],
["target/release/systemd-manager", "usr/bin/", "755"]
]
Rust/cargo make cross compilation quite easy. Just install a target std with multirust/rustup, and build like this:
cargo build --release --target $some-rust-target-triplet
The results are then in target/$some-rust-target-triplet/release/example-binary
.
Maybe cargo-deb should also accept the target flag, somehow take the assets from the right target subdirectory, and "guess" the dpkg architecture.
As suggested here, using dpkg-query --showformat='${Version}' --show PACKAGE_NAME
should be a better option to get the package version.
It is quite common for debian packages to have a split package with debug info. The main package contains stripped binaries, but there's a package with the -dbg suffix that contains extracted debug info (before the stripping), placed under /usr/src/debug
.
Would it be possible to support this?
I have some symlink files that are directly dependent on the generated binaries in the project. After cargo-deb packaging, these symlink files got copied from their real path and there are no longer symlink files. I guess this is due to the mechanism of cargo-deb.
Installing the generated deb fails because of an empty line in the Description field. I'm sure that this is an error in cargo-deb.
06d78af only partially fixes #52
Config with assets is built first, but assets need to have paths at that point, which creates a chicken-egg problem, because build depends on the config.
So either assets have to be computed in a separate post-build step, or maybe there should be a special glob type for assets? #53
Hello
It seems the binaries are not being stripped. I guess from two things:
root@39ede564bef9:/target/debian# ls -l usr/bin/pcaptain
-rwxr-xr-x 1 root root 5763920 Mar 22 10:29 usr/bin/pcaptain
root@39ede564bef9:/target/debian# strip usr/bin/pcaptain
root@39ede564bef9:/target/debian# ls -l usr/bin/pcaptain
-rwxr-xr-x 1 root root 2395096 Mar 22 10:30 usr/bin/pcaptain
Am I doing something wrong?
Also, a -dbg
package would be great, to contained the stripped-off symbols 😇.
Hi ! I there any way to add flags to the debian control to help debian package management with package transitions ? (in my case I've renamed my package)
I should add the folowing flags to my control file (as per
https://wiki.debian.org/PackageTransition )
Breaks:
Replaces:
Provides:
But I can seem to find any way to do it with cargo-deb
Hi! Thanks for this project!
Is there any possibility to attach/generate debian changelog?
Currently copyright
, changelog
and debian-binary
files have special handling, and an explicit unique generate_*
step for each.
Instead, asset's source could be an enum of PathBuf
or Vec
, which would allow these special assets to be configured in a general manner.
It seems that assets
should be specified under metadata.deb
rather than package.metadata.deb
in order to be correctly parsed.
Currently, cargo-deb
always assumes its target crate is a single binary crate that makes a single debian package. It doesn't do anything special for Cargo workspaces. Should it?
How should a Cargo workspace translate to a Debian package? If you run cargo deb
in the root of a workspace:
Would you expect cargo-deb to handle shared libraries? Do you make debs for dynamic libraries (cdylib type) and binaries that depend on them?
It seems like the package version on github has been bumped to 1.10.1
, however the crates.io
version is still on 1.10.0
. So I would appreciate it if the crates.io
package could also be bumped to the latest version since it introduces a fix which is required to build Alacritty with cargo-deb
.
I noticed that binaries got stripped after running cargo deb
, which is great for absolutely unbreakable apps, but not so great in real life, when it's time to GDB them.
Is it possible to configure stripping process somehow?
cargo-deb --no-build
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CommandError("dpkg -s", "libgcc1", [100, 112, 107, 103, 45, 113, 117, 101, 114, 121, 58, 32, 101, 114, 114, 111, 114, 58, 32, 45, 45, 115, 116, 97, 116, 117, 115, 32, 110, 101, 101, 100, 115, 32, 97, 32, 118, 97, 108, 105, 100, 32, 112, 97, 99, 107, 97, 103, 101, 32, 110, 97, 109, 101, 32, 98, 117, 116, 32, 39, 108, 105, 98, 103, 99, 99, 49, 39, 32, 105, 115, 32, 110, 111, 116, 58, 32, 97, 109, 98, 105, 103, 117, 111, 117, 115, 32, 112, 97, 99, 107, 97, 103, 101, 32, 110, 97, 109, 101, 32, 39, 108, 105, 98, 103, 99, 99, 49, 39, 32, 119, 105, 116, 104, 32, 109, 111, 114, 101, 32, 116, 104, 97, 110, 32, 111, 110, 101, 32, 105, 110, 115, 116, 97, 108, 108, 101, 100, 32, 105, 110, 115, 116, 97, 110, 99, 101, 10, 10, 85, 115, 101, 32, 45, 45, 104, 101, 108, 112, 32, 102, 111, 114, 32, 104, 101, 108, 112, 32, 97, 98, 111, 117, 116, 32, 113, 117, 101, 114, 121, 105, 110, 103, 32, 112, 97, 99, 107, 97, 103, 101, 115, 46, 10])', /checkout/src/libcore/result.rs:860
Probably because I have multiple libgcc1 installed:
dpkg -s libgcc1
dpkg-query: error: --status needs a valid package name but 'libgcc1' is not: ambiguous package name 'libgcc1' with more than one installed instance
In the following example, both mybin1 and mybin2 will show up as an executable /usr/bin inside the data archive.
[package.metadata.deb]
assets = [
["target/release/mybin1", "/usr/bin/", "755"],
["target/release/mybin2", "/usr/bin/", "755"],
]
This seems to be fixed by removing the leading /.
Line 405 in 4bd257d
Actually it can be an u32
(cargo code)
I did not totallly understand your fn strip_binaries()
, but I think it should be fine to cast a 0
to false
and any other integer to true
.
I will create a PR if this behavior suits you.
The JSON metadata contains all the required information, in more reliable form.
Currently it's not possible to run cargo deb
with --locked
, --frozen
or any other cargo build
flags. I think it would make sense to either pass any unknown options downstream, or, to prevent conflicts, accept them after --
like cargo deb --cargo-deb-option -- --cargo-build-option
.
https://github.com/mmstick/cargo-deb/blob/master/src/manifest.rs#L41
release_dir_prefix
is an absolute path derived from cargo_metadata()'s
manifest.target_path
, which is an absolute path. Thus, self.source_file.starts_with(release_dir_prefix)
will always return false
for relative paths specified in package.metadata.deb.assets
.
rustc --version
rustc 1.23.0 (766bd11c8 2018-01-01)
cargo --version
cargo 0.24.0 (45043115c 2017-12-05)
uname -a
Darwin MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
Currently, this tool expects the target project to be a binary, but my crate generates cdylib and so cargo-deb complains when binary target is not found.
It's easy to workaround with building cdylib manually, adding .so
to assets and running cargo-deb --no-build
, but thought I'd open an issue to see if it makes sense to add cdylib detection and to track it here.
$ cargo --version
cargo 0.26.0-nightly (1d6dfea44 2018-01-26)
$ git clone [email protected]:mmstick/cargo-deb.git
$ cd cargo-deb/example
$ cargo deb
warning: description field is missing in Cargo.toml
warning: license field is missing in Cargo.toml
Compiling example v0.1.0 (file:///home/hongxu/src/cargo-deb/example)
Finished release [optimized] target(s) in 0.38 secs
/home/hongxu/src/cargo-deb/example/target/debian/example_0.1.0_amd64.deb
$ dpkg-deb --contents ./target/debian/example_0.1.0_amd64.deb
drwxr-xr-x 0/0 0 2018-02-16 17:28 var/
drwxr-xr-x 0/0 0 2018-02-16 17:28 var/lib/
drwxr-xr-x 0/0 0 2018-02-16 17:28 var/lib/example/
-rw-r--r-- 0/0 6 2018-02-16 17:28 var/lib/example/1.txt
-rw-r--r-- 0/0 6 2018-02-16 17:28 var/lib/example/2.txt
-rw-r--r-- 0/0 11 2018-02-16 17:28 var/lib/example/3.txt
drwxr-xr-x 0/0 0 2018-02-16 17:28 usr/
drwxr-xr-x 0/0 0 2018-02-16 17:28 usr/share/
drwxr-xr-x 0/0 0 2018-02-16 17:28 usr/share/doc/
drwxr-xr-x 0/0 0 2018-02-16 17:28 usr/share/doc/example/
-rw-r--r-- 0/0 1159 2018-02-16 17:28 usr/share/doc/example/copyright
-rw-r--r-- 0/0 139 2018-02-16 17:28 usr/share/doc/example/changelog
Expected Result
usr/bin/example
should be inside the debian package as specified in Cargo.toml.
Possible root cause
From the logging results of cargo deb
, the installation procedure has already started while cargo build --release
hasn't finished.
Another fact is that when ./target/release/example
is already there, it will be included in the package finally.
Hi cargo-deb maintainers. I have a question.
I want to specify a revision number from cargo deb
commnad line like:
$ cargo deb --revision=1234
Because I want to updating package version(+revision) automatically using commit hash (or build number).
But supporting only revision (not support any other metadata fields dependes
, assets
, etc) seems to be unnatural ?
I have the option of accepting metadata from an external file like below:
$ cat debian.toml # include [package.metadata.deb]
assets = ...
revision = ...
...
$ cargo deb --metadata=debian.toml
Hi :)
I really like your project as it makes building packages for debian a lot easier (even if it is not the 'proper' way).
I just noticed, that the links in your README.md
are out of date.
Current tests cover only some small components. A full test of entire deb creation is needed.
Hello
I understand debian wants to have compressed (.gz
) changelogs in the package. However, it makes more sense to keep the changelog as plain text in my git repository. I actually do that and today I discovered that the changelog.gz
file bundled inside is a plain text file, not a gzip archive.
Would it be possible to check if the changelog file is already compressed (maybe by looking at the file magic) and if not, compress it?
running cargo deb --install
on the alacritty project (https://github.com/jwilm/alacritty)
I get the following error
Finished release [optimized + debuginfo] target(s) in 0.51s
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: unrecognized option: --strip-unneeded
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip [-AnuSXx] [-] [-d filename] [-s filename] [-R filename] [-o output] file [...]
cargo-deb: Command strip failed to launch
because: exit code: 1
I'm running macOs Sierra 10.12.16, using asdf to manage my rust versions. I am using rust 1.30.0 and cargo deb 1.14.0
panic = "abort" is incompatible with pkg-config resulting in the following error when compiling with release flag:
error: the crate `pkg_config` is compiled with the panic strategy `abort` which is incompatible with this crate's strategy of `unwind`
This also break cargo install --git, as cargo install uses release by default.
Please fix and consider adding --release to travis builds.
Do you think it would be possible to move some of the bits of this repo into a library and then use those bits to create an RPM packager? The deb packaging provided by this library is great but I also need rpm support for some repos :-/ Wondering what your thoughts are. This repo seems to have already worked out how to find dependencies and write a spec.
Just updated Rust via
$ curl -sSf https://sh.rustup.rs/ | sh
and then tried updating cargo-deb
(from 1.12.0 to 1.14.1) via
$ cargo install cargo-deb --force
Got the following traceback:
Updating registry `https://github.com/rust-lang/crates.io-index`
Installing cargo-deb v1.14.1
Compiling cc v1.0.25
Compiling cfg-if v0.1.6
Compiling proc-macro2 v0.4.20
Compiling itoa v0.4.3
Compiling unicode-width v0.1.5
Compiling unicode-xid v0.1.0
Compiling glob v0.2.11
Compiling typed-arena v1.4.1
Compiling byteorder v0.5.3
Compiling ryu v0.2.6
Compiling byteorder v1.2.7
Compiling build_const v0.2.1
Compiling md5 v0.5.0
Compiling serde v1.0.80
Compiling libc v0.2.43
error[E0658]: non-reference pattern used to match a reference (see issue #42640)
--> /home/rlue/.cargo/registry/src/github.com-1ecc6299db9ec823/md5-0.5.0/src/lib.rs:187:5
|
187 | / Context {
188 | | buffer,
189 | | count,
190 | | state,
191 | | }: &mut Context,
| |_____^
help: consider using a reference
|
187 | &Context {
188 | buffer,
189 | count,
190 | state,
191 | }: &mut Context,
|
error: aborting due to previous error
error: Could not compile `md5`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-deb v1.14.1`, intermediate artifacts can be found at `/tmp/cargo-install.LOcDCqB6mtHy`
Caused by:
build failed
On Debian buster.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.