On 6/10/20 11:28 PM, Boyuan Yang wrote:
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.
thanks Boyang for chiming in.
I did some search later on, and realized the same.
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.
great to know. I would be appreciated if you can point me to one of
the accepted git repos, it is a lot easier to follow an example regarding
the folder structure and branch names.
also, by using a git, is there a preference using the ones on salsa or
github/gitlab is ok too?
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:
thanks for pointing out, will do next time (had created a worklist of 6-7
ITPs today, will work on them one after another)
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.
those pre-compiled binaries were included in the source package solely
for the purpose of easy installation for the end users. I don't need them
for this package.
In a similar package I maintained for Fedora, I had to remove those
unwanted binaries in the "setup" phase in the packaging file
https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave-iso2mesh.spec#_68
for Debian, do I have to modify the orig package or there is a setting
that I can exclude (or remove) these files?
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).
got it. I fixed the lib name in this commit
https://salsa.debian.org/fangq/libzmat/-/commit/fee2578b9b17356d0dbf7e0ae11fab6848aa773f
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.
the decision was made largely for portability - a pretty big portion of the
users are windows/mac users, so, letting them compile these libraries on
their systems is a nightmare if I don't provide.
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.
the bundled lz4 code is actually newer than the versions included in Debian
because I took it from its git repo last year. While I prefer to keep
those as is
but I will be happy to read the policy regarding bundling, if you can
point me to,
and see what I can do.
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.
appreciated for the commends!
