mmstick / cargo-deb Goto Github PK

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.

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.

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.

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.

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.

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.

• How to reproduce

$ 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.

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?

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.

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.

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).

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.

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.

It seems that assets should be specified under metadata.deb rather than package.metadata.deb in order to be correctly parsed.

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.)

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)

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?

Current tests cover only some small components. A full test of entire deb creation is needed.

So

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.

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

https://lintian.debian.org/tags/copyright-should-refer-to-common-license-file-for-gpl.html

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:

• Should it be an error?
• Should it merge all sub crates into one deb package?
• Should it create a separate deb package for each crate in the workspace? Should there also be a root package that depends on all the sub packages?
• ???

Would you expect cargo-deb to handle shared libraries? Do you make debs for dynamic libraries (cdylib type) and binaries that depend on them?

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?

Hello

It seems the binaries are not being stripped. I guess from two things:

• When I'm cross-compiling, it doesn't fail despite me not specifying the strip command.
• When I run strip on the binary manually, it significantly decreases its size:

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 😇.

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.

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?

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

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

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

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.

https://lintian.debian.org/tags/description-too-long.html

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

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

Hi! Thanks for this project!

Is there any possibility to attach/generate debian changelog?

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.

Hi cargo-deb maintainers. I have a question.

motivation

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).

design choice

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

question

1. Can the cargo-deb support replacing revision nubmer from cli command ?
2. Which approach is better ? Is there a better design ?

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.

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).

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 /.

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.

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"]
]

As suggested here, using dpkg-query --showformat='${Version}' --show PACKAGE_NAME should be a better option to get the package version.

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:

• Files to be included are most likely in the project dir (and it it is not the case .. is your friend)
• In other places in Cargo.toml where path are supplied they are relative to the project and not the workspace (for example the path of a depencency)
• Behaviour changes whether the project is included in the workspace or not, which doesn't smell good

Is it possible to get back to the previous behaviour ?

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.

This is generally better for security reasons to not run cargo via root, and it also works well with rustup.

https://www.debian.org/doc/debian-policy/#changelog-files -> changelog.gz

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.