Re: Outreachy 2017 (Round 14)
Hi Nadiya,
On Mon, Mar 27, 2017 at 02:52:25PM -0700, Nadiya Sitdykova wrote:
> 1) Yes, I mean after I tried
>
> apt-get source r-cran-rcppgsl
> LC_ALL=C R --no-save < r-cran-rcppgsl*/tests/doRUnit.R
>
> There was an error "gsl-config not found". Unfortunately, I didn't save
> that log and can't reproduce it now =(
I was able to reproduce the issue in a clean chroot and have filed bug
#858882. Thanks for spotting this issue.
> 2) I executed autopkgtest . -- null and run-unit-test failed after linker
> call, I saved that log so it's attached
It seems that mapDamage is somehow creating some source code and builds
it. It might be interesting to understand what's really happening behind
the scened and what plugin created this source code that starts with
// includes from the plugin
The missing libraries can be found in three packages:
$ apt-file search /liblapack.a
libatlas-base-dev: /usr/lib/atlas-base/atlas/liblapack.a
liblapack-dev: /usr/lib/lapack/liblapack.a
libopenblas-dev: /usr/lib/openblas-base/liblapack.a
$ apt-file search /libblas.a
libatlas-base-dev: /usr/lib/atlas-base/atlas/libblas.a
libblas-dev: /usr/lib/libblas/libblas.a
libopenblas-dev: /usr/lib/openblas-base/libblas.a
I admit I personally have not yet found out the difference between these
but I think to decide this fits perfectly into the topic of the
outreachy project to evaluate those options regarding performance issues
The solution is probably some set of alternative dependencies in the
mapdamage package like
Depends: ...
libatlas-base-dev | libopenblas-dev | libblas-dev | libblas.so
libatlas-base-dev | libopenblas-dev | liblapack-dev | liblapack.so
The last alternative is obtained from the Provides field
(see apt-cache source package_name ).
Could you please check whether any of those alternatives enables the
test passing or whether we need to exclude one out of this list?
> 3) Done
Hmmm, I beg your pardon but I think I need to introduce you a bit into
the list policy:
1. We assume that people who are writing here are subscribed to the
list themselves (or tell in their mail otherwise). So it is not
needed to add the original poster in CC/To field. Mail User Agents
like mutt have a "List reply" feature - I think there is no
equivalent in GMail web mailer. So if it happens that you forget
to remove the original poster from the list of receivers when
pressing "Reply to all" nobody will blame you about this but I
wanted to give this slight hint since on other Debian lists sometimes
people are allergic against ignoring this rule. ;-)
2. Usually we are doing inline quoting to better understand what the
poster is really replying to. When using the GMail web mailer the
easiest way to do so is to press <Ctrl-A> (to mark the whole text)
and than remove formatting (my interface says it is <Ctrl-\> but this
key does not work - just press the most right icon in the lower icon
bar locking like T_x. This would be really helpful to enhance the
understanding of your responses - at least when adapted to the
reading habits on this list.
So if you wanted to tell me with "3) Done" I assume you mean you have
forwarded the issue upstream. If yes, it would be great to add also the
URL to the issue you opened of if you reported via e-mail to always CC
this list if you contact some upstream. Thus other team members will
know that something interesting is happening.
In summary:
* Please investigate in the correct dependencies to finally fix the
mapdamage test suite (specifically whether all options will work in
general and which one is the most favourable combination regarding
speed).
* Please give a link to your upstream contact (or clarify what you
have really done ;-))
Kind regards and thanks for your excellent work so far
Andreas.
> On Mon, Mar 27, 2017 at 2:03 PM, Andreas Tille <andreas@an3as.eu> wrote:
>
> > Hi Nadiya,
> >
> > thanks for your patience. It seems we have spotted here a really buggy
> > package with missing dependencies.
> >
> > On Mon, Mar 27, 2017 at 01:20:30PM -0700, Nadiya Sitdykova wrote:
> > > Here is the output of apt-cache policy r-cran-rcppgsl:
> > >
> > > r-cran-rcppgsl:
> > > Installed: 0.3.2-1
> > > Candidate: 0.3.2-1
> > > Version table:
> > > *** 0.3.2-1 500
> > > 500 http://ftp.us.debian.org/debian sid/main amd64 Packages
> > > 100 /var/lib/dpkg/status
> > >
> > > tests for r-cran-rcppgsl crashed because of absence of gsl-config.
> >
> > Do you want to say that after installing r-cran-rcppgsl on a clean
> > system is not able to run the test suite of r-cran-rcppgsl itself and
> > the installation of gsl-config is required to do so?
> >
> > Or is it rather that gsl-config is required to run the test suite of
> > mapdamage?
> >
> > > So I've
> > > done some googling, installed gsl-devel and it helped with
> > > run-r-packages-check but I still didn't get the same error for
> > > run-unit-test as you, I got:
> > >
> > > Compilation ERROR, function(s)/method(s) not created! /usr/bin/ld:
> > > cannot find -llapack
> > > /usr/bin/ld: cannot find -lblas
> >
> > Hmmm, at what point of the test is the linker ld called?
> >
> > > So I also installed libopenblas-base and libopenblas-dev. NOW I got the
> > > same error as you.
> >
> > I wonder in how far the development package is needed in the test suite.
> > May be it would be enlightening if you always would write down the
> > command you called and add a larger chunk of the resulting output.
> >
> > As you describe things it seems this is another missing dependency.
> >
> > > I looked into it, and it seems that the problem is that
> > > in the test data nucleotide frequency array looks like 0.5555556
> > 0.2222222
> > > 0.2222222 0,
> > > i.e. frequence for T is zero, which is not what expected by mapdamage
> > from
> > > line 4 in
> > > https://github.com/ginolhac/mapDamage/blob/master/
> > mapdamage/Rscripts/stats/function.R#L4
> > > Even though documentation doesn't say that zero frequences are not
> > allowed.
> > >
> > > I changed reference file from "CGAGGGCGA" to "TGAAAACGA" (so all
> > frequences
> > > > 0) and now it executes without errors.
> >
> > Would you mind reporting this in the upstream issue tracker?
> >
> > Thanks for your patient work on this
> >
> > Andreas.
> >
> > --
> > http://fam-tille.de
> >
> >
--
http://fam-tille.de
Reply to: