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

Re: [autopkgtest 879622]



Dear Andreas,

Thank you so much for all your comments! I confirm i pushed the changelog entry , i hope i did it right ;)

I would love to go on with adding an autopkgtest to another package, i was thinking to continue with rsem (n.890792 ), if that is ok for everyone!

I would also kindly like to express my interest to apply to either outreachy or GSoC. I had a look to the Outreachy announcement for this round of applications and as i did not see any proposed project by the debian med team (especially the one about adding autopkgtest suites),  i was thinking about the GSoC as an alternative. As my PhD thesis will be ready in the end of March but i will still be a student until the beginning of June, i was thinking if it would be possible for me to apply.

Anyway, apart of the internships, i would like to continue contributing to the debian med project , it is a truly unique experience!

Thank you so much again for all the help and comments!

Kind regards,
Kate

On Mon, Feb 19, 2018 at 11:01 AM, Andreas Tille <andreas@an3as.eu> wrote:
Dear Kate,

On Mon, Feb 19, 2018 at 12:21:35AM +0200, Kalou.Katerina wrote:
> Thank you for your comments!! I tried to push the files again , i think
> that now it worked :)

I confirm the push worked now.  I've pushed some more commits - partly
related to your work.  Please keep on reading my comments below.

> > > Any
> > > comments and corrections will be much welcome!! In my linux machine the
> > > 'autopkgtest -- null' command reports a pass.
> > >
> > > In the example folder i have put two sample data that i managed to found
> > at
> > > 'https://github.com/arq5x/bedtools2'. These two files are '.BED' file
> > > extensions. The example at the macs package install instructions is using
> > > the 'BAM' extension , if anyone has any recommendation on where to find
> > > these, it will be much appreciated!! :)
> >
> > In any case make sure you document the origin of the example filese in
> > debian/README.source (may be you add your question also in this file).

I've seen you have give some (rather vague) pointer in README.test
(which is fine - no need to create an extra README.source.  Besides the
fact that all Debian related stuff needs to be in debian/ dir (I just
moved the file) I wished you would add some more specific pointer.  The
best thing would be something like

    wget URL_to_example_file1
    wget URL_to_example_file2

So everybody can immediately reproduce what you did to get the files.
To express what I mean I did so in the latest commit.  I also left the
files compressed as downloaded which requires an extra file

    debian/source/include-binaries

(dpkg-buildpackage will tell you about this so this is no knowledge you
need to keep by heart. ;-) )

Regarding how to get BAM files instead of BED files I'm hoping for
comments here on the list but for the moment macs2 seems to do something
sensible which should qualify for a first test.

> > > Finally , i included the files 'README.test',
> > 'macs-example-data.install'

The file macs-example-data.install is wrong.  In the other package you
worked on we have created an extra data package.  I do not think that
the amount of extra data in the macs example rectifies an additional
package and thus we have no such package macs-example-data defined in
debian/control.  Thus this file is simply ignored.  You rather need to
put files in debian/macs.examples (and make sure those files are really
existing - since I bumped debian/compat in some unrelated change
mentioning non-existing files has lead to build problems).

> > > and 'macs.install', taking inspiration from the previous packages like
> > > rapmap i worked on. The purpose was to send the examples folder to the
> > > 'usr/share/doc' directory during installation , i do not know if i did it
> > > right!

I've now fixed it - please check all my according commits.

Finally please always add a changelog entry to the package documenting
your changes.  I'd recommen to use the dch tool for this.  For instance
you can do

    dch --team "Add autopkgtest (Closes: #879622)"

specifically the "Closes:" is important to automatically close the bug.
(You can also use `dch --team` and add the string manually with the
editor.)

I would like you to take over the changelog entry (that's why the --team
option - see `man dch`) since I want to give credit to the person who
has written the test and has fixed the bug.

I think the package is ready once you have done the changelog entry and
I'll upload once I have seen your commit.  Yesterday I added a set of
new bugs for packages in need of an autopkgtest.  So there is a plenty
to pick from and as I wrote here before I issued an according GSoC
project proposal (which can be also picked for outreachy as far as I
know).

Kind regards

       Andreas.

--
http://fam-tille.de



Reply to: