Bug#822722: RFS: tldp/0.7.7 [ITP #822181]
Hello bug #822722 and Gianfranco,
In the below, I have snipped everything that you have helped me fix
and/or is now immaterial. Everything else, I address inline. (Oh,
and this is a reply to two distinct earlier exchanges.)
The debian/copyright file
-------------------------
>>Is it considered embedded if it is in the source tarball, but not
>>in >the binary package?
>
>yes, but not a big issue, just mention them in copyright correctly
>(you might want to look at copyrights of the respective Debian
>packages)
>>Perhaps I can simply remove all of the commented out bits of the
>>debian/copyright file, if you can confirm that the copyright
>>information is only required for the binary package.
>
>no, all the source needs to be listed here.
OK, got it. I think I have then restored the copyright entries
appropriately to reflect the provenance of the pieces. See also
below for a few specific comments.
># Files: extras/dsssl/* extras/css/*
># Copyright: 2000-2003 - Greg Ferguson (gferg@metalab.unc.edu)
># License: GPL-2.0+
>#
>Files: extras/dsssl/* extras/xsl/* extras/css/*
>Copyright: 2000-2002 - David Horton (dhorton@speakeasy.net)
>License: GFDL-1.2
>
>this is conflicting even if commented (but using debian stuff, and
>removing them from the tarball will fix automagically the issue)
Ugh! Yes, I had some bad lines in the debian/copyright file. I
have corrected those and double-checked the licenses against the
original sources. Again, these files are only used to allow the
test suite to succeed. They will never be shipped with the software
(I intend to overhaul ldp-docbook-xsl and ldp-docbook-dsssl later).
* I checked all files again.
* I added a copyright year to all of the *.py files.
* I included the GFDL-1.2 short text block in debian/copyright.
* I uncommented all of the blocks covering source/test stuff.
The actually-not-so-good $(BUILD_DATE) trick
--------------------------------------------
>>was generated during build, rather than using the checked-in
>>ldptool.1 file.
>
>actually the timestamp seems correctly added, so it should work to me
I think it's an oops (on my part). I think 'sphinx' is smart. In
my Makefile $(BUILD_DATE) was undefined, meaning that I was running:
sphinx-build -b man -D today="" -d _build/doctrees . _build/man
And, sphinx was smart enough to notice that the variable today
contained nothing, so it replaced the value with its stock date
generation. I adjusted this line:
sphinx-build -b man -d _build/doctrees . _build/man
My question about .egg-info (now using debian/clean)
----------------------------------------------------
>>I added this .egg-info removal line because the directory did remain
>>even after 'debclean', That meant that a second build from the same
>>directory would fail.
>
>I did remove the rm line, did twice the dpkg-buildpackage and it
>was successful. maybe you aren't calling correctly the
>./debian/rules clean target?
I addded a pair of debian/clean entries according to advice from a
thread on debian-python:
https://lists.debian.org/debian-python/2016/04/msg00098.html
https://lists.debian.org/debian-python/2016/04/msg00101.html
This works just fine when building on 'sid'.
This does not work correctly when building on 'jessie'. Given that
'sid' is the recommended build platform and that this seems to be
small difference between devscripts-2.15 and devscript-2.16, I'm
going to ignore this.
Binary package dependency specification (corrections)
-----------------------------------------------------
>>Not really. Not all systems have these files. And, some that have >been distributed are different or broken. But!
>>
>>The short version is that all of these files are used only for the
>>testing suite and are, therefore, included in the release tarball,
>>but are not shipped with the software.
>>
>>In the installed package, yes, the 'ldptool' software would rely on:
>>
>> ldp-docbook-dsssl
>> ldp-docbook-xsl
>> docbook-dsssl
>>
>>Oh, and yes, that means I should add all of the other dependencies
>>so that 'ldptool' works. I forgot about that step.
I have adjusted all of the runtime dependencies I had forgotten to
add to debian/control and installed the resulting package on a
barren (freshly installed) system and tested. It works very well.
Testing
-------
>indeed, and what about running the testsuite against the system
>packages? if you use them at runtime, you need also to run tests
>against them :)
OK, I can do that. Is that a requirement for submitting the
package? I added the bits and bobs that are not provided with
every system to allow testing of all documentation generation on any
platform or distribution. Test coverage is at 92%:
https://travis-ci.org/martin-a-brown/python-tldp/jobs/126230165
That example shows running the long tests, but even during the
shorter version of the tests, which run during a typical
dpkg-buildpackage execution run, many of the executables are run.
I can try to figure out how to run the long tests during the Debian
build if you think that's wise. Just let me know what I should do.
If I were to enable the long tests for the Debian package build AND
add a few more sample document processing steps to the test suite,
it would probably exercise nearly all of the dependencies on things
like jing, xsltproc, jade, opensp, asciidoc, etc... But, they do
get tested during my CI runs (on an Ubuntu system, I think), so if
it is not necessary, I'd prefer to leave the package build stuff
separate (and fast).
Remaining lintian comments
--------------------------
This is all what lintian remarks.
P: tldp source: debian-watch-may-check-gpg-signature
X: python3-tldp: library-package-name-for-application usr/bin/ldptool
Maintaining a debian release in the same git tree
-------------------------------------------------
>maintain an upstream "master" branch without debian directory
>maintain a debian branch with the debian packaging and the upstream one
>
>git merge master when a new release is out in debian branch, and
>dpkg-buildpackage it (using the upstream tarball to be sure there
>aren't unwanted changes).
>
>or gbp buildpackage -S -sa --git-debian-branch=debian
>
>this will avoid having debian stuff in the upstream tarball, and
>letting you develop debian/specific fixes without having to release
>a new tarball
[...]
>nope :( nothing comes in my mind right now (well I maintain
>borgbackup in a similar way FWIW)
I looked at the upstream source for borgbackup:
https://github.com/borgbackup/borg
And, I did not find a 'debian' branch. Could you perhaps point me
to a URL?
And, lastly, check-all-the-things
---------------------------------
>automatic checks (check-all-the-things package)
I had never heard of 'check-all-the-things', which is certainly a
cantankerous and picky little fellow. He did notice and criticize a
few of my recent Python changes/commits after which I had must not
have had any pep or flakiness.
In response to the various outputs of check-all-the-things, I
noticed that several were false hits, e.g. finding '/home' in
documentation, so I took the suggestions with a grain of salt.
I fixed these though:
* many/most PEP8 and pyflakes suggestions
* the test data which was duplicated; each file now is unique
* added some debian/upstream/metadata
The other comments from check-all-the-things touched on the test
tools or data, documentation or made suggestions which are counter
to my style (i.e. bashate). It certainly is a handy one-line
command to run to apply some sort of judgement on the style and
consistency of the code in the package.
I think it's quite funny that the isutf8 program complained about my
iso-8859-1 file and that xmllint found my deliberately broken XML
test data.
Anyway, I'm happy to know about check-all-the-things.
Review request #4 (or #7 or, maybe this is #683?)
-------------------------------------------------
I used dput 'dput mentors tldp_0.7.12-1_source.changes' and I got
back a bunch of output (ending like this).
Uploading to mentors (via http to mentors.debian.net):
Uploading tldp_0.7.12-1.dsc: done.
Uploading tldp_0.7.12.orig.tar.xz: done.
Uploading tldp_0.7.12-1.debian.tar.xz: done.
Uploading tldp_0.7.12-1_source.changes: done.
Successfully uploaded packages.
But, I do not see the package listed when I refresh the page on
mentors.debian.net which I created. Hopefully you can find it?
If not, everything is updated in the canonical VCS location:
http://github.com/tLDP/python-tldp.git
Thank you again for your effort and time, Gianfranco,
-Martin
--
Martin A. Brown
http://linux-ip.net/
Reply to: