RFS: prinseq-lite: added dependencies to fix autopkgtest failures

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Everyone,

I had a look at the QA page of prinseq-lite and saw a failure in
the autopkgtest[1].  The prinseq-graphs command is missing two
dependencies, and thus choke on the following test:

        prinseq-graphs --version

[1] https://ci.debian.net/data/autopkgtest/testing/amd64/p/prinseq-lite/5496117/log.gz

I brought the adequate fix on Salsa, and readied the version
0.20.4-4 for upload in sid.

Bringing tests is definitely a good thing for verifying the
packaging, even the simpler tests are most welcome!  :)

Kind Regards
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Andreas Tille-5
Hi Étienne,

On Sat, May 16, 2020 at 09:53:08AM +0200, Étienne Mollier wrote:
> I had a look at the QA page of prinseq-lite and saw a failure in
> the autopkgtest[1].  The prinseq-graphs command is missing two
> dependencies, and thus choke on the following test:
>
> prinseq-graphs --version

Thanks again for the valuable input!
 
> [1] https://ci.debian.net/data/autopkgtest/testing/amd64/p/prinseq-lite/5496117/log.gz
>
> I brought the adequate fix on Salsa, and readied the version
> 0.20.4-4 for upload in sid.

... just building for upload.
 
> Bringing tests is definitely a good thing for verifying the
> packaging, even the simpler tests are most welcome!  :)

I fully agree.  BTW, in the debian/TODO you wrote about the missing
Statistics::PCA.  As far as my experience with Perl modules packaging
reaches its relatively easy to create Perl packages.  Do you want to
take the challenge to enable us providing fully featured prinseq-graphs?

You might like to ask for help in Debian Perl team which is extremely
supportive.

BTW, next time please make sure that the changelog date is later
than the previous changelog - lintian throws errors about it.  I
usually create the last changelog entry by doing

   dch -r

(if not using routine-update -f which is doing the very same).

Thanks again

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Andreas,

Andreas Tille, on 2020-05-16 11:35:48 +0200:
> I fully agree.  BTW, in the debian/TODO you wrote about the missing
> Statistics::PCA.  As far as my experience with Perl modules packaging
> reaches its relatively easy to create Perl packages.  Do you want to
> take the challenge to enable us providing fully featured prinseq-graphs?

Sure!  Maybe not immediately, as may be a bit offline this week
end, but probably in the coming week.

> You might like to ask for help in Debian Perl team which is extremely
> supportive.

Sounds good, I understood they may have some routines for
converting CPAN entries into Debian packages.  Will check with
them.

> BTW, next time please make sure that the changelog date is later
> than the previous changelog - lintian throws errors about it.  I
> usually create the last changelog entry by doing
>
>    dch -r
>
> (if not using routine-update -f which is doing the very same).

I really ought to use the latter systematically, especially past
a certain hour...  :)

> Thanks again

You're welcome,
Thank you for the reminders!

Kind Regards,
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

merkys
Hello,

On Sat, 16 May 2020, 12:56 Étienne Mollier, <[hidden email]> wrote:
Sounds good, I understood they may have some routines for
converting CPAN entries into Debian packages.  Will check with
them.

There's dh-make-perl tool from similarly named Debian package. In your case the following should be a good starting point:

dh-make-perl --cpan Statistics::PCA

Best,
Andrius
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Andrius,

Andrius Merkys, on 2020-05-16 14:41:53 +0300:
> There's dh-make-perl tool from similarly named Debian package. In your case
> the following should be a good starting point:
>
> dh-make-perl --cpan Statistics::PCA

Thank you, that does quite a job to put a decent git repository
together!

I had a look at the dependencies necessary to get the module to
operate properly on Debian, and I noted the following tree:

        libstatistics-pca-perl (To do)
        |-> libtest-simple-perl
        |-> libtext-simpletable-perl
        |-> libcontextual-return-perl
        |-> Math::Cephes (Missing libmath-cephes-perl)
        `-> Math::MatrixReal (Missing libmath-matrixreal-perl)
            `-> libtest-most-perl

With the Statistics::PCA and its missing dependencies, there
would be a total of three packages to create.  The module
Math::MatrixReal[1] looks easy enough; the result from
dh-make-perl builds successfully out of git-buildpackage.  There
will a few fields to fill here and there I guess, to get the
package to be clean toward Debian policy.

I'm a bit more concerned on Math::Cephes[2] side, but not from a
technical point of view though; it is seamless on the side of
git-buildpackage as well.  From a copyright standpoint, the
module embeds C code provided on netlib[3] but originating from
a book and a commercial product, accompanied with a "readme"
notice[4] indicating that said code "may be used freely",
fortunately.  But maybe an extra-careful examination of the
source code for extra copyright statements will be needed here.
Hopefully, should DFSG changes be required, they won't impede on
the proper operation of the package.

[1] https://metacpan.org/pod/Math::MatrixReal
[2] https://metacpan.org/pod/Math::Cephes
[3] http://www.netlib.org/cephes/
[4] http://www.netlib.org/cephes/readme

Not sure where is the best location to put the various packaging
repositories at the moment.  I suppose Debian Perl Team
namespace would be such a place; I'll probably contact them
tomorrow.

Kind Regards,
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

merkys
Hi Étienne,

On 2020-05-19 00:30, Étienne Mollier wrote:
> Thank you, that does quite a job to put a decent git repository
> together!

Glad this helped!

> I'm a bit more concerned on Math::Cephes[2] side, but not from a
> technical point of view though; it is seamless on the side of
> git-buildpackage as well.  From a copyright standpoint, the
> module embeds C code provided on netlib[3] but originating from
> a book and a commercial product, accompanied with a "readme"
> notice[4] indicating that said code "may be used freely",
> fortunately.  But maybe an extra-careful examination of the
> source code for extra copyright statements will be needed here.
> Hopefully, should DFSG changes be required, they won't impede on
> the proper operation of the package.
>
> [1] https://metacpan.org/pod/Math::MatrixReal
> [2] https://metacpan.org/pod/Math::Cephes
> [3] http://www.netlib.org/cephes/
> [4] http://www.netlib.org/cephes/readme
Embedded copies of netlib seem abundant in Debian [1]. I suggest looking
into debian/copyright of these packages. It is curious, however, that
netlib is not packaged as a stand-alone package, but embedded everywhere
instead.

[1]
https://codesearch.debian.net/search?q=Cephes+Math+Library&literal=1&perpkg=1

> Not sure where is the best location to put the various packaging
> repositories at the moment.  I suppose Debian Perl Team
> namespace would be such a place; I'll probably contact them
> tomorrow.

Perl modules belong under salsa.org/perl-team/modules/packages. To put
them there one has to be in Debian Perl Team. I suggest joining it.

Best,
Andrius



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Andreas Tille-5
On Tue, May 19, 2020 at 06:45:41AM +0300, [hidden email] wrote:

> > source code for extra copyright statements will be needed here.
> > Hopefully, should DFSG changes be required, they won't impede on
> > the proper operation of the package.
> >
> > [1] https://metacpan.org/pod/Math::MatrixReal
> > [2] https://metacpan.org/pod/Math::Cephes
> > [3] http://www.netlib.org/cephes/
> > [4] http://www.netlib.org/cephes/readme
>
> Embedded copies of netlib seem abundant in Debian [1]. I suggest looking
> into debian/copyright of these packages. It is curious, however, that
> netlib is not packaged as a stand-alone package, but embedded everywhere
> instead.

I think libblas-dev is your friend - may be discussing on Debian Science.
 

> [1]
> https://codesearch.debian.net/search?q=Cephes+Math+Library&literal=1&perpkg=1
>
> > Not sure where is the best location to put the various packaging
> > repositories at the moment.  I suppose Debian Perl Team
> > namespace would be such a place; I'll probably contact them
> > tomorrow.
>
> Perl modules belong under salsa.org/perl-team/modules/packages. To put
> them there one has to be in Debian Perl Team. I suggest joining it.
 
+1
Debian Perl Team is very welcoming, helpful and inviting ... even if
you are not a Perl programmer like me. :-)

Kind regards

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

merkys

Hi Andreas,

On 2020-05-19 09:55, Andreas Tille wrote:
On Tue, May 19, 2020 at 06:45:41AM +0300, [hidden email] wrote:
Embedded copies of netlib seem abundant in Debian [1]. I suggest looking
into debian/copyright of these packages. It is curious, however, that
netlib is not packaged as a stand-alone package, but embedded everywhere
instead.
I think libblas-dev is your friend - may be discussing on Debian Science.

This is interesting. It is worth checking whether Math::Cephes could be linked against BLAS. If so, embedded netlib sources could be excluded.

Best,
Andrius

Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Andreas, Hi Andrius,

[hidden email], on 2020-05-19 12:02:15 +0300:
> On 2020-05-19 09:55, Andreas Tille wrote:
> > On Tue, May 19, 2020 at 06:45:41AM +0300, [hidden email] wrote:
> > > Embedded copies of netlib seem abundant in Debian [1]. I suggest looking
> > > into debian/copyright of these packages. It is curious, however, that
> > > netlib is not packaged as a stand-alone package, but embedded everywhere
> > > instead.
> > I think libblas-dev is your friend - may be discussing on Debian Science.
> This is interesting. It is worth checking whether Math::Cephes could be
> linked against BLAS. If so, embedded netlib sources could be excluded.

For what it's worth, looking at the C code embeded into the Perl
modules, this seems to be the result of a swig wrapping.  I'm a
bit unsure how the relinking is supposed to occur in that kind
of cases (maybe it's not too hard, I just haven't dived into
this sort of thing yet).  But yes, I understand that avoiding
convenience copies in the source code is definitely wanted by
the Debian Policy.

Kind Regards,
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

merkys
Hi Étienne,

On 2020-05-19 23:01, Étienne Mollier wrote:
> For what it's worth, looking at the C code embeded into the Perl
> modules, this seems to be the result of a swig wrapping.  I'm a
> bit unsure how the relinking is supposed to occur in that kind
> of cases (maybe it's not too hard, I just haven't dived into
> this sort of thing yet).  But yes, I understand that avoiding
> convenience copies in the source code is definitely wanted by
> the Debian Policy.

Swig wrappers could (and, in my understanding of Debian policies of
rebuilding things from source, should) be regenerated from Cephes.i file.

Best,
Andrius



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Andrius,

[hidden email], on 2020-05-20 06:24:47 +0300:

> On 2020-05-19 23:01, Étienne Mollier wrote:
> > For what it's worth, looking at the C code embeded into the Perl
> > modules, this seems to be the result of a swig wrapping.  I'm a
> > bit unsure how the relinking is supposed to occur in that kind
> > of cases (maybe it's not too hard, I just haven't dived into
> > this sort of thing yet).  But yes, I understand that avoiding
> > convenience copies in the source code is definitely wanted by
> > the Debian Policy.
>
> Swig wrappers could (and, in my understanding of Debian policies of
> rebuilding things from source, should) be regenerated from Cephes.i file.
It makes sense.  In that particular case though, after a bit of
reading and quite some testing, the resulting Cephes.pm
regenerated by swig fails the build time testing.  I don't
exclude this is caused by a mishandling of mine with swig.
Here is the kind of command I was considering in d/rules:

        swig -perl5 -module Math::Cephes -I$(CURDIR)libmd/ \
                -o $(CURDIR)/lib/Math/Cephes.pm Cephes.i

But I'm afraid to suspect manual modifications in Cephes.pm.
Maybe I'll leave these files as such for the moment.

Anyway, thanks for the pointer!
I believe I learned something useful with swig.

Kind Regards,
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Andreas Tille-5
Hi Étienne,

On Tue, May 26, 2020 at 07:41:48PM +0200, Étienne Mollier wrote:

> > Swig wrappers could (and, in my understanding of Debian policies of
> > rebuilding things from source, should) be regenerated from Cephes.i file.
>
> It makes sense.  In that particular case though, after a bit of
> reading and quite some testing, the resulting Cephes.pm
> regenerated by swig fails the build time testing.  I don't
> exclude this is caused by a mishandling of mine with swig.
> Here is the kind of command I was considering in d/rules:
>
> swig -perl5 -module Math::Cephes -I$(CURDIR)libmd/ \
> -o $(CURDIR)/lib/Math/Cephes.pm Cephes.i
>
> But I'm afraid to suspect manual modifications in Cephes.pm.
> Maybe I'll leave these files as such for the moment.
>
> Anyway, thanks for the pointer!
> I believe I learned something useful with swig.

If I were you I would formally commit your try and ask on debian-mentors
(may be adding some diff between the upstream version and the generated
one).  In case it does not trigger some help I agree that for the moment
the upstream provided file might be OK.

Sorry, but I can not help with swig.

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

Étienne Mollier
Hi Andreas,

Andreas Tille, on 2020-05-26 22:01:41 +0200:
> If I were you I would formally commit your try and ask on debian-mentors
> (may be adding some diff between the upstream version and the generated
> one).  In case it does not trigger some help I agree that for the moment
> the upstream provided file might be OK.

Good idea, I subscribe!
(to both the idea and the mailing list... :)

Cheers,
--
Étienne Mollier <[hidden email]>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFS: prinseq-lite: added dependencies to fix autopkgtest failures

merkys
In reply to this post by Étienne Mollier
Hi Étienne,

On 2020-05-26 20:41, Étienne Mollier wrote:

> It makes sense.  In that particular case though, after a bit of
> reading and quite some testing, the resulting Cephes.pm
> regenerated by swig fails the build time testing.  I don't
> exclude this is caused by a mishandling of mine with swig.
> Here is the kind of command I was considering in d/rules:
>
> swig -perl5 -module Math::Cephes -I$(CURDIR)libmd/ \
> -o $(CURDIR)/lib/Math/Cephes.pm Cephes.i
>
> But I'm afraid to suspect manual modifications in Cephes.pm.
> Maybe I'll leave these files as such for the moment.
This is an interesting data point. I have some experience with swig, and
I could give it a look. I suggest opening a git branch with your attempt
to rebuild swig bindings. Thus your attempt will not interfere with
packaging and uploading Math::Cephes with upstream-provided bindings.

Best,
Andrius



signature.asc (849 bytes) Download Attachment