[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression



Control: owner -1 !
Control: block 962603 by 962640

Hi Qianqian,

Thanks for being the upstream as well as a new packager. I am assuming
that you have have read https://mentors.debian.net/intro-maintainers
and know the key info about becoming a new packager.

在 2020-06-10星期三的 22:35 -0400,Qianqian Fang写道:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> (new contributor here. the package has been uploaded to
> mentors https://mentors.debian.net/package/zmat, but showed
> several warnings/errors that I need help to fix.)
> 
> I am looking for a sponsor for my package "zmat":
> To access further information about this package, please visit the 
> following URL:
> 
>     https://salsa.debian.org/fangq/libzmat
> 
> Alternatively, one can download the package with dget using this
> command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/z/zmat/zmat_0.9.8-1.dsc
> 
> ** sorry, the above command failed on my machine due to the below
> error:
>    gpg: Can't check signature: No public key

This is because the PGP key you used to sign the source package is not
trusted by default in Debian (which is natural since you are not an
official member of Debian). According to the manual page of dget
(dget(1)), you may use -u/--allow-unauthenticated option when calling
dget to circumvent this problem.

Uploading to mentors.debian.net is recommended but not compulsory. If
you can prepare a git packging repo following the DEP-14 layout (
https://dep-team.pages.debian.net/deps/dep14), the review can also take
place there.

I saw your submission at https://mentors.debian.net/package/zmat .
Before we start the review, I'd suggest to take a look at those
automatic lintian warnings and error messages. They often indicate
important problems with your packaging.

There are several questions listed on mentors.debian.net/package/zmat
and I believe it might be better to send them together with your RFS
email (this is more likely to be read by mentors). For now I will copy
them here and I will answer some of them below:

==============================================
I'd like to have someone take a look, and help me figure out some of
the remaining issues.

Specifically, here are the things I want to fix

1. one of the 3 subpackages is an Octave toolbox (as a mex file).
Although the binary was compiled during the packaging process, I wasn't
able to find a template to assemble the octave package. can someone
point to me if there is a template (for a similar mex-based toolbox)
for octave?

2. when running debuild, I got the below warning

dpkg-shlibdeps: warning: symbol deflateBound used by
debian/libzmat1/usr/lib/x86_64-linux-gnu/libzmat.so.1 found in none of
the libraries

although, I've already added zlib1g-dev to Build-Depends and zlib1g to
the Depends fields, I am wondering what else do I need to add.

3. I have two errors from lintian:

E: zmat source: source-is-missing private/zipmat.mexa64
E: zmat source: source-is-missing octave/linux64/zipmat.mex

these two folders (private/octave) are precompiled binary (mex) files
using the same source codes. They are not installed anyways, I am
wondering if I can set a flag to skip these files (or run a pre-build
script to remove them?)

4. naming convention: did I do this correctly? can I use libzmat or
zmat as the main package name?

if you can provide additional feedback on this package, I am very much
appreciated.
==========================================

For 1: unfortunately I am not an expert in dealing with Octave. Maybe
someone from the Debian Science Team or Octave Group (
https://wiki.debian.org/Teams/DebianOctaveGroup) can help you with it.

For 2: This will need some more closer look into your code; I may do it
later.

For 3: If you are _sure_ that your source code will regenerate those
binary files during the building process from source code, this warning
can be treated as false-positives and can be overridden.

For 4: Either one is okay in this case. BTW: I'm unsure if you are
indeed going to add SONAME into the -dev package name (using libzmat1-
dev instead of libzmat-dev). If you are to use libzmat1-dev and
encounter SONAME bump later, the package name for development package
will have to change as well, which may affect other packages that
build-depend on your library (if any).

I took a very quick glimpse on the library source code and it seems
that you are bundling some 3rd-party libraries, including lz4 and
easylzma. Debian is largely against bundling 3rdparty libraries: if
possible, please consider using libraries from Debian archive instead
of bundled ones. In this case, at least we need a switch to
enable/disable using bundled library copy in Makefile/CMakeLists.txt.

For lz4, you are almost surely required to adjust your code to use
external library (https://tracker.debian.org/pkg/lz4); for easylzma it
might be okay to use the bundled one for now since Debian hasn't
packaged it separately; however I personally suggest moving away from
such library since this one looks largely unmaintained and hasn't seen
development activity for 10+ years (https://github.com/lloyd/easylzma).
Stripping the bundled libraries is not required since they are still
free software and have compatible licenses with your whole project.

I will stop here for now. Thanks for your work and maybe we could fix
the issues mentioned previously first to properly shape your package.

-- 
Regards,
Boyuan Yang

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: