Help on updating two python packages

[Qianqian Fang]

hi everyone,

in 2020, I learned how to package debian packages and created two python 
packages


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964993
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964994

over the last few years, the upstream git repos of both projects had 
been updated but the watch files failed to detect new releases.


I still have access to both packages on salsa

https://salsa.debian.org/science-team/pyjdata
https://salsa.debian.org/science-team/pybj


I just tried the following steps to update the packages

1. modify the debian/watch file to watch pypi releases

2. run uscan, download the new upstream tarball

3. commit the change of the watch file

4. run gbp import-orig --pristine-tar  ../newpackage.orig.tar.gz

5. update files under debian/

6. git push --all


after this, I noticed that pyjdata CI failed with with the following errors

https://salsa.debian.org/science-team/pyjdata/-/pipelines/659403

dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/pyjdata_0.3.6-1+salsaci+20240330+8.diff.yssV2X
1094 
dpkg-source: 
info: Hint: make sure the version in debian/changelog matches the 
unpacked source tree
1095 
dpkg-source: 
info: you can integrate the local changes with dpkg-source --commit
1096 
dpkg-buildpackage: 
error: dpkg-source -b . subprocess returned exit status 2



for pybj, ci tasks finished ok, but the test-crossbuild-arm64 job failed

https://salsa.debian.org/science-team/pybj/-/pipelines/659410


I am wondering if anyone can help me resolve these issues - was there 
any problem for the steps I took? any pointers on how to properly update 
a package to new upstream release would be appreciated.


also, I noticed that uscan downloads from pypi appear to include an 
.egg-info folder that is not part of my git source repo. is this a 
problem? is monitoring github release/tag a better way or pypi is preferred?


thanks

Qianqian

Bug#970652: RFS: mcx/1.0-1 [ITP] -- Monte Carlo eXtreme 3D photon transport simulator

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "mcx":

 * Package name    : mcx
   Version : 2020.9-1
   Upstream Author : fan...@gmail.com
 * URL : https://github.com/fangq/mcx
 * License : GPL-3+, BSD-2-clause, MIT, public-domain, MPL-2, 
BSD-3-clause

 * Vcs : https://salsa.debian.org/pkg-octave-team/mcx
   Section : science

It builds those binary packages:

  matlab-mcxtools - mcx photon transport simulator helper functions for 
MATLAB
  octave-mcxtools - mcx photon transport simulator helper functions for 
Octave

  matlab-mcxlab - mcx photon transport simulator for matlab
  octave-mcxlab - mcx photon transport simulator for octave
  mcxstudio - unified graphical user interface for MCX/MMC/MCXCL
  mcx-demos - sample simulations for Monte Carlo eXtreme (mcx)
  mcxphoton - unified command line interface for mcx/mmc/mcxcl
  libmcx1 - library for Monte Carlo eXtreme 3D photon transport simulations
  mcx - Monte Carlo eXtreme 3D photon transport simulator

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/mcx/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mcx/mcx_2020.9-1.dsc


Changes for the initial release:

 mcx (2020.9-1) unstable; urgency=medium
 .
   * Initial release (Closes: #970475)

Regards,
--
  Qianqian Fang

Bug#964994: RFS: pybj/0.2.5-1 [ITP] -- Binary JData (BJData) encoder/decoder for Python 2

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pybj"

* Package name : pybj
Version : 0.2.5-1
Upstream Author : [fill in name and email of upstream]
* URL : https://github.com/fangq/pybj
* License : Apache-2.0
* Vcs : https://salsa.debian.org/science-team/pybj
Section : python

It builds those binary packages:

python-bjdata - Binary JData (BJData) encoder/decoder for Python 2
python3-bjdata - Binary JData (BJData) encoder/decoder for Python 3

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/pybj

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/p/pybj/pybj_0.2.5-1.dsc

Changes since the last upload:

* Initial release. (Closes: #964984)

Regards,

Bug#964993: RFS: pyjdata/0.3.5-1 [ITP] -- JData format encoder/decoder for Python 2

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pyjdata"

* Package name : pyjdata
Version : 0.3.5-1
Upstream Author : [fill in name and email of upstream]
* URL : https://github.com/fangq/pyjdata
* License : Apache-2.0
* Vcs : https://salsa.debian.org/science-team/pyjdata
Section : python

It builds those binary packages:

python-jdata - JData encoder/decoder for Python 2
python3-jdata - JData encoder/decoder for Python 3

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/pyjdata

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/pyjdata/pyjdata_0.3.5-1.dsc


Changes since the last upload:

* Initial release. (Closes: #964984)

Regards,

Bug#963789: RFS: octave-brain2mesh/0.7.9 [RFS] -- a fully automated high-quality brain tetrahedral mesh generation toolbox

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "octave-brain2mesh":

  * Package name : octave-brain2mesh
    Version : 0.7.9
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://mcx.space/brain2mesh
  * License : GPLv3+
  * Vcs : https://github.com/fangq/brain2mesh
    Section : science

It builds those binary packages:

  octave-brain2mesh - a high-quality brain tetrahedral mesh generation 
toolbox for Octave

  matlab-brain2mesh - brain2mesh toolbox for MATLAB
  brain2mesh-demos - demo script and sample data for brain2mesh


To access further information about this package, please visit the 
following URL:


   https://mentors.debian.net/package/octave-brain2mesh

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/o/octave-brain2mesh/octave-brain2mesh_0.7.9-1.dsc



Changes since the last upload:


  * Initial release (Closes: #962610)
 -- Qianqian Fang   Sat, 13 Jun 2020 15:20:58 -0400


Regards,

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

[Qianqian Fang]

On 6/21/20 12:16 AM, Boyuan Yang wrote:

After all the previous reviews and changes and base on the current
version you provide at https://mentors.debian.net/package/zmat, I think
there are several minor issues plus one last major issue. I opted to
make fixes on minor issues and list the diff here. Please consider
applying the diff.



hi Boyuan

thank you so much for the detailed feedback - should have updated you in 
this thread -


Rafael Laboissière (CCed) from the Debian octave group has been helping 
me finalizing the package (among a few others), and it is now updated at


https://salsa.debian.org/pkg-octave-team/zmat

the discussion thread can be found at

https://lists.debian.org/debian-octave/2020/06/threads.html#0

your feedback #1/2 have been fixed by Rafael, and I will fix #3 below.

also thanks for the log - Rafael also told me the building had failed, 
but it worked ok on my machine (my debhelper-compat is 12, he was using 
13), see my log


https://lists.debian.org/debian-octave/2020/06/msg00020.html


your attached log is very helpful, it appears that the "*b**uild-arch*" 
target was not executed (which calls *build-static* to create libzmat.a 
and *build-mex* to create zipmat.mex), see


https://salsa.debian.org/pkg-octave-team/zmat/-/blob/master/debian/rules#L9

are you aware any support change w.r.t. *build-arch *in compat level 13? 
or if you see any issue with my rules? (still pretty new to the rules file).


much appreciated

Qianqian



Key points:

1. The suite name in debian/changelog file will need to be set from
UNRELEASED to unstable when it's ready for upload.
2. There is no need to explicitly list out Depends: debhelper when
Depends: debhelper-compat exists since debhelper will provide package
"debhelper-compat".
3. There is no need to explicitly list out library dependency for your
libraries. Explicitly listing them out is tedious and error-prone.
Those library names will be automatically derived and generated by
dh_shlibdeps(1) during the build process and emerge from the
${shlibs:Depends} substitution marker.


diff --git a/debian/changelog b/debian/changelog
index 4beb2b1..6cd6b7c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-zmat (0.9.8-1) UNRELEASED; urgency=medium
+zmat (0.9.8-1) unstable; urgency=medium
  
* Initial release. (Closes: #962603)
  
diff --git a/debian/control b/debian/control

index 8004473..754dcca 100644
--- a/debian/control
+++ b/debian/control
@@ -3,13 +3,13 @@ Maintainer: Qianqian Fang 
  Section: libs
  Priority: optional
  Standards-Version: 4.5.0
-Build-Depends: debhelper (>= 8.1.3~), debhelper-compat (= 12), liblz4-
dev, zlib1g-dev, dh-octave
+Build-Depends: debhelper-compat (= 12), liblz4-dev, zlib1g-dev, dh-
octave
  Homepage: https://github.com/fangq/zmat
  
  Package: libzmat1

  Architecture: any
  Multi-Arch: same
-Depends: zlib1g, liblz4-1, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
  Provides: libzmat1
  Description: compression library - runtime
   ZMat is a portable C library to enable easy-to-use data compression
@@ -35,7 +35,7 @@ Package: octave-zmat
  Section: science
  Architecture: any
  Multi-Arch: same
-Depends: zlib1g, liblz4-1, ${shlibs:Depends}, ${octave:Depends},
${misc:Depends}
+Depends: ${shlibs:Depends}, ${octave:Depends}, ${misc:Depends}
  Description: in-memory data compression for Octave
   ZMat is a portable mex function to enable
zlib/gzip/lzma/lzip/lz4/lz4hc
   based data compression/decompression and base64 encoding/decoding
support




However, that is not enough: the major issue is that your package
current fails to build from source within a clean chroot environment. I
have attached the full buildlog in the attachment. It seems that the
error comes from the missing lib/libzmat.a library. I'm curious about
how you planned to generate the static library. It seems that the
Makefile does not contain related instructions. There are several
STATIC keywords in CMakeLists.txt but you did not list cmake in the
build-dependency (so cmake won't be available during building) and did
not invoke cmake anywhere in debian/rules as well. Please consider
fixing this issue.

Bug#963230: RFS: octave-iso2mesh/1.9.5 [RFS] -- a 3D surface and volumetric mesh generator for MATLAB/Octave

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "octave-iso2mesh":

  * Package name : octave-iso2mesh
    Version : 1.9.5
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://iso2mesh.sf.net
  * License : GPLv2+
  * Vcs : https://github.com/fangq/is2mesh
    Section : science

It builds those binary packages:

  octave-iso2mesh - a 3D surface and volumetric mesh generator for Octave
  iso2mesh-demos - demo script and sample data for iso2mesh

To access further information about this package, please visit the 
following URL:


   https://mentors.debian.net/package/octave-iso2mesh

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/o/octave-iso2mesh/octave-iso2mesh_1.9.5-1.dsc



Changes since the last upload:


  * Initial release (Closes: #962608)
 -- Qianqian Fang   Sat, 13 Jun 2020 15:20:58 -0400


Regards,

Bug#962854: RFS: octave-jnifti/0.6 [RFS] -- fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter for MATLAB/Octave

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "octave-jnifti":

  * Package name : octave-jnifti
    Version : 0.6
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://github.com/fangq/jnifti/
  * License : GPLv3+ or Apache_2.0
  * Vcs : https://github.com/fangq/jnifti/
    Section : science

It builds those binary packages:

  octave-jnifti -  fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter 
for Octave
  matlab-jnifti -  fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter 
for MATLAB

  matlab-jnifti -  sample files and demo scripts for JNIfTI toolbox

To access further information about this package, please visit the 
following URL:


   https://mentors.debian.net/package/octave-jnifti

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/o/octave-jnifti/octave-jnifti_0.6-1.dsc


Changes since the last upload:


  * Initial import of JNIfTI. (Closes: #962609)
 -- Qianqian Fang   Sat, 13 Jun 2020 15:18:58 -0400


Regards,

Bug#962777: RFS: jsonlab/2.0 [RFS] -- a native JSON/UBJSON/MassagePack encoder/decoder for MATLAB/Octave

[Qianqian Fang]

it looks like if I use jsonlab as the main package main, the octave 
packaging script seems to place all .m files under the jsonlab package 
instead of the octave-jsonlab package, so I had to rename the package 
name to octave-jsonlab to correctly build all subpackages.


The mentor package URL has also changed to

https://mentors.debian.net/package/octave-jsonlab

dget -x 
https://mentors.debian.net/debian/pool/main/o/octave-jsonlab/octave-jsonlab_2.0-1.dsc


do I need to create a new RFS if I change the package's name?

Bug#962777: RFS: jsonlab/2.0 [RFS] -- a native JSON/UBJSON/MassagePack encoder/decoder for MATLAB/Octave

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "jsonlab":

  * Package name : jsonlab
    Version : 2.0
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://openjdata.org/jsonlab
  * License : GPLv3+ or BSD-3-clause
  * Vcs : https://github.com/fangq/jsonlab
    Section : science

It builds those binary packages:

  octave-jsonlab - a native JSON/UBJSON/MassagePack encoder/decoder for 
Octave
  matlab-jsonlab - a native JSON/UBJSON/MassagePack encoder/decoder for 
MATLAB


To access further information about this package, please visit the 
following URL:


   https://mentors.debian.net/package/jsonlab

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

(Please note that to install the generated package, one needs to install 
a dependency:
octave-zmat, which is also currently being reviewed - 
https://mentors.debian.net/package/zmat )


Changes since the last upload:


  * Initial import of JSONLab v2.0. (Closes: #962607)
 -- Qianqian Fang   Sat, 13 Jun 2020 15:18:58 -0400


Regards,

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

[Qianqian Fang]

Just made another update to the test package on mentors, see

https://mentors.debian.net/package/zmat

after consulting the debian-octave mailing list, the octave-zmat package 
is all good now (tested and working)


I also corrected an error (due to the removal of the bundled lz4 files) 
of the orig package prep script 
, and now 
the package is compiled properly against the external liblz4 library.


feel free to take a look and let me know if any additional change is 
needed. thanks


Qianqian

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

[Qianqian Fang]

On 6/11/20 6:13 PM, Wookey wrote:

Yes. dch -r is the conventional way to do that (and change the
timestamp at the same time), but you can just edit it. The idea is
that you leave it as 'UNRELEASED' until you really have stopped
fiddling and are ready to upload. Some tools take note of this field
to stop you accidentally uploading before you are ready. (I don't
personally find this useful, but that's why it's there).


No. Someone will have to do the work of making any adjustments needed
to build in stable and doing an upload to -backports. That can't be
done until after it has been accepted into the archive (which can take
a while (days to months) after initial upload).

https://wiki.debian.org/BuildingFormalBackports
https://wiki.debian.org/Backports



thanks for the clarifications. I realized in my package uploaded 
earlier, a bunch of settings were not done correctly, so I just 
re-uploaded a new version after making a bunch of fixes


https://salsa.debian.org/fangq/libzmat/-/commits/zmat

if you have checked out the earlier upload, please retrieve it again.

I tested the generated deb files, both the lib and dev packages seemed 
to work fine, the octave package is still having some issue to be 
recognized in octave, I am seeking help on the octave list right now.




Wookey

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

[Qianqian Fang]

thank you all for sharing your feedback.

I updated my packaging files and fixed most of the issues (also received 
some help from the debian-octave list). The updated package can be found at


https://mentors.debian.net/package/zmat

A quick summary:

1. I renamed the library back to libzmat1 as many of you suggested it is 
the right naming format


2. I modified the orig package via a setup script 
 to


    - 1) remove the bundled lz4 files, and link the binary with 
system's liblz4 library, and


    - 2) add the missing octave DESCRIPTION/INDEX files,

3. bumped my debhelper compat level to 12

I hope these are acceptable solutions. the only error left is the 
"UNRELEASED" in the changelog. should I set it to "unstable"? will the 
package be backported automatically in the future to stable?


thanks

Qianqian

Re: Looking for help towards my first Debian package (ITP#962603)

[Qianqian Fang]

On 6/11/20 2:05 AM, Paul Wise wrote:

The Depends in debian/control are not the same as the dependencies of
the library file itself (although usually the library dependencies are
automatically translated to Depends using ${shlibs:Depends}). When
linking the library you need to link against libz.so, typically you
would do that like this:

gcc -o foo foo.o bar.o baz.o -lz



when dh builds the library, the linking command of the libzmat.so file 
did include the -lz flag (and the linking was successful)


gcc -shared -Wl,-soname,libzmat.so.1 -lz -o ../lib/libzmat.so zmatlib.o 

where does "library dependency" get specified in the package, if not 
Depends?




If you have users who aren't able to do compilation, you can provide
the precompiled library and other files in a separate tarball or zip.
If you are using github, you can attach those to your release tags.



that's possible. however, some of the file release systems, such as 
MATLAB File Exchange 
, 
only links to the github generated master.zip/release packages. if I 
remove the mex files from my github folder, users will not be able to 
run unless they know how to recompile.


I did have a separate github repo for binaries, but it is quite painful 
to sync and promote if I have two URLs.


for now, I will simply create a source-only orig.tar.gz file when I 
upload my package again.




Since you are upstream, check out our guide for upstreams:

https://wiki.debian.org/UpstreamGuide



thanks for the link. I agree that library bundling is a bad thing only 
if such library is*widely available and frequently updated* such as on 
Linux, but when you aim to support users cross platforms (especially 
those using windows), counting on users to install all dependencies and 
successful compile your code is simply difficult. Bundling lightweight 
dependencies (with a compatible license of course) could potentially 
save lots of time and trouble. Bundling also avoids a lot of instability 
issues when a library decides to make a non-backward-compatible 
interface changes (which happens quite often among linux libraries).


anyhow, my opinion is that while admitting bundling is not a best 
practice, it is not something that should be forbidden either. If I 
can't bundle lz4 source codes (4 files), then I will have to change my 
upstream makefile and create a new release.





This repository doesn't appear to be public, but libzmat is definitely
the wrong name for the binary package name, it should be libzmat1. It
is an acceptable source package name, but if you change the Debian
source package name you should probably also change the upstream name.
Which upstream name you want is dependent on what you intend to put
into the repository, is it just the library (use libzmat) or also other
things that use the library (use zmat). You could also put those other
things in a separate upstream repository and source package.


here is Boyuan's suggestion (see response to issue#4)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962640#14


the repo  says public, can you 
try this link again?


https://salsa.debian.org/fangq/libzmat

thanks

Re: Looking for help towards my first Debian package (ITP#962603)

[Qianqian Fang]

On 6/11/20 12:52 AM, Paul Wise wrote:

On Wed, Jun 10, 2020 at 8:25 PM Qianqian Fang wrote:


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.

The libzmat1.so.1 library needs to link against libz.so too. Probably
this needs to be fixed upstream.



hi Paul,

I listed *zlib1g* in the Depends section, isn't it the provider of libz.so?

https://packages.debian.org/buster/amd64/zlib1g/filelist



These precompiled binaries should be removed from the upstream source
repository and tarballs and always built from source at build time. If
upstream refuses to do that, you should remove them from the
orig.tar.gz before uploading your package. Using the Files-Excluded
feature of uscan is a reasonable way to achieve that.



I am the upstream author of this toolbox. I included those precompiled
mex files because most of my users do not have a dev environment to compile.

I will remove them from the orig tarball then.



The source package name should be the same as the upstream source
repository name (so zmat) and the binary package name should be named
after the SONAME of the library binary (so libzmat1).


Boyuan in an earlier message suggested to use libzmat instead of 
libzmat1. I've changed my control files on salsa


https://salsa.debian.org/fangq/libzmat

moving forward, to make these suggested changes, do I need to reupload 
the package to mentors?


thanks

Qianqian

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

[Qianqian Fang]

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!

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

[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":

  * Package name : zmat
    Version : 0.9.8
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://github.com/fangq/zmat
  * License : GPLv3+
  * Vcs : https://github.com/fangq/zmat
    Section : libs

It builds those binary packages:

  libzmat1 - a portable C library for stream-level compression
  libzmat1-dev - the library header files and samples to use libzmat
  octave-zmat - an Octave toolbox for array compression

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

need some help to go through a submission process once, first time 
contributor.


Changes since the last upload:


  * Initial release. (Closes: #962603)
 -- Qianqian Fang   Mon, 08 Jun 2020 10:30:07 -0400


Regards,

Looking for help towards my first Debian package (ITP#962603)

[Qianqian Fang]

hi there,

I am learning my way towards creating my first Debian package. The 
specific package I am working on right now is in this ITP bug


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962603

at this point, I've uploaded a set of packaging files to salsa

https://salsa.debian.org/fangq/libzmat


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.


thanks

Qianqian