[Pkg-rust-maintainers] [RFH] packing kmon

[Wolfgang Silbermayr]

On 4/3/20 1:37 AM, Stephan Lachnit wrote:
> Hi,
> 
> I'm interested in packing kmon (https://github.com/orhun/kmon), a Linux Kernel Activity Monitor. However, I'm completely new to Rust, and I got a bit confused, so I would like to ask for help here.

Hi Stephan, great to see you're attempting to work on this crate. I've
seen announcements about it and thought that looks like great functionality.

> First of all, my current attempt is here: https://salsa.debian.org/stephanlachnit-guest/kmon

We usually don't use debcargo directly, but it's called by scripts that
live in our https://salsa.debian.org/rust-team/debcargo-conf/
repository. You might want to take a look at the README.rst in this repo
for a general short introduction. There is also a blog entry by guiding
through first steps at
https://blog.hackeriet.no/packaging-a-rust-project-for-debian/

> I didn't create it with debcargo, it wouldn't let me because of this:
> 
> Suspicious file, should probably be excluded: "kmon-1.0.0/example/lkm_example.c"
> Something failed: ErrorMessage { msg: "Suspicious files detected, aborting. Ask on #debian-rust if you are stuck." }
> 
> And I have no clue whatsoever what to do but asking :)

Asking is the correct approach in this case. :-)

The problem at hand is that we take cautions to not distribute files
that might cause problems, in this case source files written in the C
language. Several rust projects include copies of C projects that they
use, and in Debian, we attempt to not include the copies distributed
with the rust projects, but instead have them packaged separately (most
of the time, also by different people).

This case here is more of a false positive, as it looks like an example
of a minimal kernel module used for demonstration purposes. I think the
best in this case is to exclude it. You might as well decide to include
it, but I assume it doesn't add a lot of value. You just have to
consider, once the .orig.tar.*z file is in the Debian archive, it can't
be changed in retrospective, so you'll have to decide with way to go,
otherwise you'll have to wait for the next release of the crate in order
to change your decision. Whichever you choose, you'll find an example
`debcargo.toml` file in the https://salsa.debian.org/rust-team/debcargo
repo. The fields are `excludes` and `whitelist`.

> Ignoring the dependencies for now, when building I immediately get an error:
> 
> cp: cannot stat './debian/cargo-checksum.json': No such file or directory
> 
> I tried to understand what to put in there, but I didn't really understand it. I guess this is not a problem if debcargo would work.

You're right, it's probably a follow-up error.

> Also, three of the dependencies are currently missing (marked with #), or at least it couldn't find them. Can someone help me with them? As far as I see it, they all work fine with debcargo, but I'm not a DD so I don't have upload rights.

Neither am I at the moment.

We coordinate the packaging efforts in the #debian-rust IRC channel on
OFTC. Feel free to join there, there are usually some DDs online who we
can ask for uploads. The typical procedure is to start by creating MRs
on salsa for the `debcargo-conf` repository. Just expect the whole
process to take some time, as each new crate needs to go through the NEW
queue for the first upload. You can use
https://crates.io/crates/cargo-debstatus for analysis, just consider
that it's not packaged yet, and you'll have to install it with `cargo`
for now.

HTH,
Wolfgang.