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

Re: Low-hanging fruits reminder for 2021-04-21, 19:00 UTC (tomorrow)



hi gregor,

cross-posted to debian-med, as maybe someone with more adequate
background than myself on libchado-perl might be of help on its
test suite.

gregor herrmann, on 2021-04-22 18:53:37 +0200:
> On Wed, 21 Apr 2021 22:42:10 +0200, Étienne Mollier wrote:
> > The only problem I caught is libchado-perl autopkgtest.  The
> > package does not declare any Testsuite, and the d/rules test
> > target is skipped, due to needing a database access.  But if I
> > trigger an autopkgtest, then the autodep8 starts, and chokes on
> > a couple of issues.  I'm not too sure whether this is blocking,
> > but if so, will need to ping Debian Med.
> 
> Hm … Good question. And it raises some questions :)
> 
> - Do the problems happen with the libgraph-perl version in stable and
>   testing/unstable as well?

Yes, problems do happen with unmodified libgraph-perl from
stable, testing and sid.  That is why I think they are most
likely unrelated to the security fix you cherry picked.

> - What did you do to run which tests? (I stared at the package bit
>   but it's not really obvious to me).

I mostly stuck to running the entire autopkgtest, with bells and
whistles:

	autopkgtest libchado-perl -- schroot sid-amd64-sbuild
	autopkgtest libchado-perl -- schroot testing-amd64-sbuild
	autopkgtest libchado-perl -- schroot buster-amd64-schroot

Variations around --no-auto-control do behave though, since
there are no tests in the package:

	autopkgtest --no-auto-control libchado-perl -- schroot sid-amd64-sbuild

that is why I am not too sure how much of a blocker it would be
for the libgraph-perl upgrade.  Maybe it will be recognized as
"Not a regression".

> - Which tests fail how? (I only see ./t/01_okay.t which triest to
>   load Bio::Chado::LoadDBI which doesn't exist anywhere in Debian ?!)

By order of appearance in an autodep8 run against the Testing
distribution, i.e. without the patched libgraph-perl:

- test autodep8-perl-build-deps t/01_okay.t catches the use
  Bio::Chado::LoadDBI you mention, the nearest file I find in
  Debian is the following Perl5 module source:

	libchado-perl: /usr/share/gmod/chado/load/tt2/LoadDBI.tt2

  which by the way contains the following:

	<!-- Not creating LoadDBI.pm at make time anymore (now it depends on Bio::GMOD::DB::Config)

- test autodep8-perl-recommends returns a bunch of various
  issues:
  - a series of syntax.t issues like:
      #   Failed test '/usr/bin/perl -wc /usr/share/perl5/Bio/FeatureIO/chado.pm exited successfully'
      #   at /usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t line 124.
  - Can't locate Bio/Chado/LoadDBI.pm in @INC [...] at /usr/share/perl5/Bio/FeatureIO/chado.pm line 7
  - a couple of the following in various files:
    Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/share/perl5/Bio/GMOD/DB/Adapter.pm line 498.
  - Can't locate Chado/AutoDBI.pm in @INC [...] at /usr/share/perl5/Bio/GMOD/Load/GFF.pm line 5
  - Can't locate GMOD/Chado/LoadDBI.pm in @INC [...] at /usr/share/perl5/Bio/GMOD/SeqUtils.pm line 41

> - Does this package actually use modules from libgraph-perl?
>   (Grepping show some Bio::Graphics stuff but libbio-graphics-perl
>   doesn't depend on libgraph-perl.)  

It does not appear so on grepping libgraph-perl source code, or
binary packages content, on my end neither.  Removing dependency
on libgraph-perl does not visibly affect buildability of the
package, and does not seem to make differences in the test
suite.  It happens that the libgraph-perl is pulled as a
transitive recommends of the binary packages though.

> - Do you have any output or any other details?

I added an sbuild with autopkgtest output of the libchado-perl
against sid in attachment, without dependency to libgraph-perl.
The output is a bit trimmed down for readability, and reduce the
weight on mailboxes.

As far as I can see, although it is a Perl package, it looks
like provided elements are mostly supposed to be used like a
regular application.  Maybe all these issues are just not caught
in regular package usage?

> Cheers,
> gregor, cc'ing the bug report

I'm sorry, I hope it is not too much at once.

Kind Regards, keeping the bug report around,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

Attachment: signature.asc
Description: PGP signature


Reply to: