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

[Wookey]

On 2020-06-11 17:58 -0400, Qianqian Fang wrote:
> I hope these are acceptable solutions. the only error left is the "UNRELEASED"
> in the changelog. should I set it to "unstable"?

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

> will the package be backported
> automatically in the future to stable?

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

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

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

Bug#962684: RFS: fclib/3.1.0+dfsg-2 -- read and write problems from the Friction Contact Library (library)

[Stephen Sinclair]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fclib
   Version : 3.1.0+dfsg-2
   Upstream Author : fclib-proj...@lists.gforge.inria.fr
 * URL : https://frictionalcontactlibrary.github.io/
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/science-team/fclib
   Section : science

It builds those binary packages:

  libfclib0 - read and write problems from the Friction Contact
Library (library)
  libfclib-dev - read and write problems from the Friction Contact
Library (headers)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fclib/fclib_3.1.0+dfsg-2.dsc

Changes since the last upload:

   * Patch wrong argument to cs_transpose which leads to segfault.
 (Closes: #927761)

The previous upload, 3.1.0+dfsg-1, failed on buildd and this patch
fixes the problem.  This package is required for siconos 4.3.0+dfsg-1,
uploaded in parallel, with RFS #962441:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962441

Regards,

--
  Stephen Sinclair

Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adrian Bunk]

Control: tags 962669 moreinfo

On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:
> On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> > On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > > Just to confirm - will the certificates be automatically re-added
> > > (assuming that users have either the automatically trust or prompt
> > > options enabled)?
> > 
> > (stretch-pu report cc'ed, since same applies)
> > 
> > Excellent question. I believe we're going to hit #743339 "Previously 
> > removed certificates not added again". I had not found a reasonable
> > fix for that case in general, to preserve a user's selections. Maybe
> > a "good enough" fix will have to do for the specific ones added back.
> 
> OK.
> 
> In that case, how does this seem as an SUA text?
> 
> 
> The ca-certificates update described in SUA 182-1 removed some
> certificates issued by Symantec (under various brand names).
> Unfortunately, this removal led to a number of reported regressions.
> The affected certificates have therefore been reintroduced.
> 
> If you have already installed the package from SUA 182-1, and need to
> use the affected certificates, you may need to manually enable them by
> running "dpkg-reconfigure ca-certificates" as root.
> 

This does not work in various embedded scenarios.

Would it work to force-enable them in /etc/ca-certificates.conf
from the preinst when upgrading from old-version matching 20200601* ?

Unrelated to that, please keep the Python 2 -> 3 build dependency
change out of this emergency update.

> Regards,
> 
> Adam

cu
Adrian

Bug#962679: RFS: idle3-tools/0.9.1-6 [QA] -- idle3-tools - change the idle3 timer of recent Western Digital Hard Disk Drives

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "idle3-tools"

 * Package name: idle3-tools
   Version : 0.9.1-6
   Upstream Author : [fill in name and email of upstream]
 * URL : http://idle3-tools.sourceforge.net/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/idle3-tools
   Section : admin

It builds those binary packages:

  idle3-tools - change the idle3 timer of recent Western Digital Hard Disk 
Drives

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

  https://mentors.debian.net/package/idle3-tools

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/idle3-tools/idle3-tools_0.9.1-6.dsc

Changes since the last upload:

   * QA upload.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Added Vcs-* fields to source stanza.
   - Removed trailing whitespace.
   * debian/copyright:
   - Added 'hdparm' License block.
   - Added Leandro Ramos and myself to packaging block.
   - Updated block for 'sqio.c'.
   - Updated packaging years.
   - Updated short license fields.
   - Using a secure URI in Format field.
   - Using a secure URI in Source field.
   * debian/patches/01-695876-idle3ctl.8.patch: updated header.
   * debian/patches/02_fix-spelling-errors.patch: created to fix spelling errors
 in the manpage.
   * debian/patches/03_fix-makefile-for-hardening.patch: created to fix Makefile
 to use flags for gcc hardening.
   * debian/patches/04_fix-typo-in-idle3ctl.c.patch: added.
   * debian/rules:
   - Added flags for gcc hardening.
   - Removed DH_VERBOSE export.
   - Removed trailing whitespace.
   - Removed unnecessary override for dh_auto_install.
   * debian/salsa-ci.yml: added to provide CI tests for Salsa.
   * debian/upstream/metadata: created.
   * debian/watch: created.

Regards,

--
  Fabio Augusto De Muzio Tobich


pgpjyaiHVF2MM.pgp
Description: PGP signature

Bug#962678: RFS: m2vrequantiser/1.1-5 [QA] -- MPEG-2 streams requantization

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: m2vrequantiser
   Version : 1.1-5
   Upstream Author : Martin Wimpress 
 * URL : https://launchpad.net/m2vrequantiser
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/m2vrequantiser
   Section : video

It builds those binary packages:

  m2vrequantiser - MPEG-2 streams requantization

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/m2vrequantiser/m2vrequantiser_1.1-5.dsc

Changes since the last upload:

   * QA upload.
   * debian/control: added 'Rules-Requires-Root: no' to source stanza.
   * debian/copyright: updated packaging years.
   * debian/patches/: updated patches headers.
   * debian/rules:
   - Added DEB_BUILD_MAINT_OPTIONS variable to improve GCC hardening.
   - Removed unnecessary dh argument.
   * debian/tests/control: created to perform trivial CI test.
   * debian/upstream/metadata: created.
   * debian/watch:
   - Bumped version to 4.
   - Improved search regex.

Regards,

--
  Fabio Augusto De Muzio Tobich


pgp7K0YuvRaDr.pgp
Description: PGP signature

Looking for a sponsor for my "git-subrepo" package

[Samo Pogačnik]

Dear mentors,

Hello to every one. I kindly ask, if somebody would help me contribute to the
Debian project by packaging a new Debian package named git-subrepo. This is an
alternative to git submodules functionality. It is already quite mature sw
project based on git and advanced bash programming and it has been actively
developed on github since 2013. I feel that the project deserves a wider
audience and the upstream project maintainers support my Debian packaging
attempt.

I prepared an initial git-subrepo Debian packaging project in git, itself using
the git-subrepo functionality to maintain the upstream code. It is currently a
native package, because i found the provided package the most simple. The
uploaded package does not show any errors. I hope that this approach is not
against Debian policy, as the quilt format is preferred.

Please excuse me for any procedural mistakes i made reporting the RFS bug report
(now #962385 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962385) after
the package upload, since there has been no real ITP request filed in-front. I
was only able to find almost two years old #911397 RFP: git-subrepo -- Git
Submodule Alternative (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911397)
, which i did not know how to relate to.

best regards, Samo

p.s.
There are also my private git-subrepo Debian packages available for latest
Ubuntu distros at https://launchpad.net/~spog

Bug#962669: RFS: ca-certificates/20200611 [RC] -- Common CA certificates

[Michael Shuler]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ca-certificates"

 * Package name: ca-certificates
   Version : 20200611
 * License : Mozilla Public License Version 2.0
 * Vcs : https://salsa.debian.org/debian/ca-certificates
   Section : misc

It builds those binary packages:

  ca-certificates - Common CA certificates
  ca-certificates-udeb - Common CA certificates - udeb

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


  https://mentors.debian.net/package/ca-certificates

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200611.dsc


Changes since the last upload:

   * mozilla/blacklist:
 Revert Symantec CA blacklist (#911289). Closes: #962596
 The following root certificates were added back (+):
 + "GeoTrust Global CA"
 + "GeoTrust Primary Certification Authority"
 + "GeoTrust Primary Certification Authority - G2"
 + "GeoTrust Primary Certification Authority - G3"
 + "GeoTrust Universal CA"
 + "thawte Primary Root CA"
 + "thawte Primary Root CA - G2"
 + "thawte Primary Root CA - G3"
 + "VeriSign Class 3 Public Primary Certification Authority - G4"
 + "VeriSign Class 3 Public Primary Certification Authority - G5"
 + "VeriSign Universal Root Certification Authority"
 .
   [ Gianfranco Costamagna ]
   * debian/{rules,control}:
 Merge Ubuntu patch from Matthias Klose to use Python3 during build.
 Closes: #942915

Regards,

--
  Michael Shuler

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

[Wookey]

On 2020-06-11 15:35 +0800, Paul Wise wrote:
> Looks like what you haven't isn't correct, it should be libzmat1
> instead of libzmat in the control file, since the library package name
> is supposed to be based on the SONAME of the library.

Are you sure you are not being excessively categorical here? libzmat1
is preferred, but libzmat is not 'wrong'. (Hmm, checks policy - OK, maybe it is 
wrong :-)

The point is that when the SONAME is included in the package name then
packages depending on this library can transition to the new libzmat2
one by one, as they are built after the SONAME=2 version of zmat is
uploaded one day. Older packages built earlier which depend on libzmat
(SO=1) and depend on libzmat1 package carry on working and libzmat1
package stays on the system until nothing depends on it any more
because the depending packages have all been upgraded to depend on
libzmat2.

If you just have 'libzmat' then this process is not possible and when
you upload a new libzmat (SO=2) one day all the packages that depend
on it have to be rebuilt against the new version, and only when all
are done can the packages transition into testing. In practice this
can cause huge delays, so we developed the practice of putting
SONNAMES into package names to make the whole thing work rather better. 

So if for some reason it is not safe to have two versions of the
library simultaneously installed then an unversioned library package
(libzmat) makes sense but that's rare.

So Bouyang's "Either one is okay in this case." is misleading.

The -dev package should usually not contain the SONAME in the package
name - that's only needed when you need people to be able to link
explicitly against libzcat1 or libzcat2. (makes sense for something
like a big GUI toolkit: QT4 and QT5, but not a leaf compression library) 

Library naming conventions are subtle and the reasons for _why_ one
might want to do one thing or another are not obvious.

Details are given in policy: 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

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

[Paul Wise]

On Thu, 2020-06-11 at 02:53 -0400, Qianqian Fang wrote:

> 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 think I would just change the MATLAB download link to the github
releases page, which then links to source/binaries for each release.

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

That doesn't seem like the correct solution to me, one should never
keep generated nor bundled files in git.

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

Thanks.

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

I suggest that users should be provided with pre-compiled binaries
instead of source. On platforms that don't have sane dependency
systems, you would obviously need to provide copies of all
dependencies, but that should happen in the binary packages for those
platforms, not in the source code repository.

> Bundling lightweight dependencies (with a compatible license of
> course) could potentially save lots of time and trouble.

Pre-compiled binaries saves even more time.

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

Pre-compiled binaries avoids this too. For compiling from source you
can add version constraints in most build systems, but eventually you
just need to support newer the interface versions.

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

For a library like lz4, with a small record of security issues, I don't
think it is appropriate to statically link it nor embed copies of it
unless of course the platform the binaries are for doesn't have a sane
dependency system. For those platforms you need to ensure your binaries
use the newest version of the library with no security bugs. If you are
not embedding the library in your source code, a simple rebuild updates
the binaries for those platforms but if you are embedding then you need
to manually update the embedded version before you can rebuild and then
release, so embedding libraries in your source is less efficient.

https://security-tracker.debian.org/tracker/source-package/lz4

> the repo says public, can you try this link again?
> 
> https://salsa.debian.org/fangq/libzmat

I made a typo on your username, sorry.

Looks like what you haven't isn't correct, it should be libzmat1
instead of libzmat in the control file, since the library package name
is supposed to be based on the SONAME of the library.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[Andrey Rahmatullin]

On Thu, Jun 11, 2020 at 02:53:47AM -0400, Qianqian Fang wrote:
> 
> 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 
With --as-needed enabled by default, -l arguments should come after the .o
files that require them. As you construct the link command manually, you
need to distinguish between flags, that usually come before sources, and
libs, that should come after them, and split your ARFLAGS accordingly.

> where does "library dependency" get specified in the package, if not
> Depends?
The shared library dependencies of the binary files are specified in the
ELF headers.
They are not the same as Debian package dependencies.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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)

[Paul Wise]

On Thu, 2020-06-11 at 01:52 -0400, Qianqian Fang wrote:

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

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

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

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.

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

https://wiki.debian.org/UpstreamGuide

> I will remove them from the orig tarball then.

Thanks.

> 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

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.

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

Yes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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