Re: Bug#909716: Request for sponsoring changes in idba
Hi Pranav,
On Tue, Mar 10, 2020 at 01:42:41AM +0530, Pranav Ballaney wrote:
> > I hope you are happy with your result.
>
> Thank you, they went quite well.
That's very nice to hear.
> > Yes, for instance in an extra binary package. While we could even run
> > autopkgtest inside a compiled source tree I personally prefer to ship
> > every tool inside some binary Debian package to enable users reproducing
> > the test results on their installation.
>
> Yes, this makes sense. I have added another package called idba-extra.
Fine. That works. Sorry when I have given a bit short-cutted advise.
I've completed the long description.
> One small problem I ran into: There was no debian/install file originally,
> so I couldn't figure out how it is that these files are being copied. Is it
> something to do with make install?
I'd recommend
man dh_install
This debhelper module reads debian/PACKAGENAME.install and does basically
moving files around. If there are two binary packages dh_auto_install
does not know what location to use for what file. So it installs to
debian/tmp
and leaves it to dh_install (controled by debian/*install files) to move
files around.
> I've added debian/idba.install and debian/idba-extra.install, and
> everything works as expected.
> Although, the following warnings are generated during testing.
>
> dh_missing: warning: usr/bin/idba_tran exists in debian/tmp but is not
> installed to anywhere
> dh_missing: warning: usr/bin/validate_blat_parallel exists in debian/tmp
> but is not installed to anywhere
> dh_missing: warning: usr/bin/validate_blat exists in debian/tmp but is not
> installed to anywhere
> dh_missing: warning: usr/bin/idba_ud exists in debian/tmp but is not
> installed to anywhere
> dh_missing: warning: usr/bin/scan.py exists in debian/tmp but is not
> installed to anywhere
> dh_missing: warning: usr/bin/idba_hybrid exists in debian/tmp but is not
> installed to anywhere
> dh_missing: warning: usr/bin/run-unittest.py exists in debian/tmp but is
> not installed to anywhere
> dh_missing: warning: usr/bin/idba exists in debian/tmp but is not installed
> to anywhere
>
> Please check debian/*.install and see if these are right.
These are at least not wrong (= the result is correct). ;-)
The dh_missing warnings are caused since you told dh_install to use the
original locations of the files before upstreams `make install` was
moving these to debian/tmp. So debian/tmp/usr/bin remained filled with
files (since you took them from somewhere else) and dh_missing is warning
you about this. This is helpful if you might *really* forget to install
some files.
In my commit 6cff0c2377861eb179d4ec06514df75df1323510 I tried to fix this
but did not test which I'll leave you for an exercise. ;-)
When doing so I stumbled upon the script run-unittest.py which I think
should not end up in /usr/bin. I installed it into docs and your second
exercise could be to check whether it really does some sensible testing
at all. As far as I can see it is just triggering the build time test
but it does not look as if it be useful to install on users machines.
Even if it would make sense the name /usr/bin/run-unittest.py is way to
generic and should be avoided. Same with /usr/bin/scan.py - please
check whether this script makes sense in /usr/bin it should be probably
renamed (to something like idba_scan.py). Otherwise it should also go
to /usr/share/doc/idba (or left out fully).
> I have also changed the test files now. Only a few necessary files are
> included, and the rest are generated during testing.
That's really good! The only think I'm missing now is that we should
always mention the origin where the data were obtained from (may be in
a script calling wget for downloading). It makes also sense to drop
some note about the license of these files.
> Let me know if I missed anything, otherwise please review and sponsor these
> changes.
What you did is basically correct and extremely helpful to finalise the
autopkgtest. Please inspect my recent commits and try to provide the
missings I mentioned above in this mail.
> > Hope this short intro is helpful.
>
> It was very helpful, indeed. I have a few more queries, though.
> I was trying to find more information about the structure of packages and I
> found these two guides:
> https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
> https://www.debian.org/doc/manuals/maint-guide/dother.en.html
> Are these okay, or would you recommend some other resource?
These are the usually recommended manuals. For the work inside the
Debian Med team I usually recommend the Debian Med team policy:
https://med-team.pages.debian.net/policy/
(which also mentions beginners documentation on top).
> Also, now that we have included some new programs in the idba-extra
> package, how can I generate man pages for them? I noticed that it is the
> debian/*.1 files that correspond to manpages, and are generated using
> help2man.
I added a few examples by extending the debian/createmanpages script.
I'd perfectly accept some kind of "lazyness" here. I would not mind
uploading the current incomplete status despite of the lintian warnings.
I usually decide according to the "importance" of the tool that needs a
manpage. My motivation was to get "the first three in list" and also
the ones we are using in autopkgtest. Feel free to decide whether you
want a complete set of manpages or not.
> But as far as I understand, help2man needs the executable, which is
> produced only inside the testing chroot. So, do I run help2man inside the
> chroot, or is there another way?
Yes, you can run help2man at package build time as an alternative to
what I'm doing inside debian/createmanpages. Just specify the PATH to
the tools explicitly. It could look like
override_dh_installman:
export PATH=$(CURDIR)/bin:$(PATH) ; \
help2man ...
While this is also kind of another build time test (program runs and
issues help) I somehow stopped what I did for instance inside the
last-align package which looks exactly like this. It just happened
that some additional manual edits might be needed. So what I'm
doing in idba is:
1. Build packages
2. Install packages
3. debian/createmanpages
# using the installed programs
4. git add ; git commit
The advantage is that you can inspect and edit the manpages before
building. The disadvantage is that these are not automatically updated
for new program versions with potentially different text.
> And does anything else need to be done, when a new package is added?
If the program is important for the user another manpage should be
added.
> Please reply whenever it is convenient for you.
My general strategy is to avoid that newcomers need to wait for me.
Thus I try to be as quick as possible.
Kind regards and thanks for your great work
Andreas.
--
http://fam-tille.de
Reply to: