Dear Nicholas,
Thanks again for your work on this. I'm looking forward to seeing the
cleaned-up package in Debian stretch.
Before I reply to your message, let me note a few more things to fix:
1. s/Muse-el/muse-el/ in the changelog
2. You need to re-run `dch -r` so the timestamp is later than your
changes.
3. "Includes changes to debian/control, debian/rules, NEWS"
This is not very informative. I'm not saying that you have to list
every change, but see how much more informative this is:
- Update Build-Depends; Maintainer; Uploaders [or whatever fields you updated]
- Rewrite d/rules
- Update NEWS
For a sample, see the most recent changelog entry of the yasnippet
package, which I recently converted to use dh_elpa.
4. "Add patch ..."
When you say that you added a patch, it is best to explicitly state the
patch filename so that someone searching the changelog for that patch
name can find it easily.
5. "Add depends on doc-base to register Quickstart.pdf as
muse-quickstart."
Build-Depends? Binary package dependency?
Are you sure you need this? doc-base registration uses triggers, so you
don't generally need to depend on it.
6. In d/NEWS,
> Unfortunately, it is not possible to distribute this manual with the
> muse-el Debian package because the Debian project has chosen to remove
> most GFDL'd documentation.
Wouldn't you say the unfortunate thing is that the manual has not been
relicensed under a DFSG-compatible license? ;)
7. I'm pretty sure you shouldn't compress
/usr/share/doc/elpa-muse/QuickStart.pdf. It might break doc-base
clients, and in any case, I doubt that gzip compression is very good for
PDFs.
8. In the patch header for use_see_not_open.diff, it would be good to
know why you're applying the patch. What's the advantage of see(1) over
open(1)?
9. There is still a lot of Lintian output. Please make the package
Lintian clean. Please ensure you turn on experimental and informational
tags:
I: muse-el source: binary-control-field-duplicates-source field "priority" in package muse-el
E: muse-el source: license-problem-gfdl-invariants README invariant part is: with no invariant sections, and with the front-cover texts and back-cover texts as specified in the manual
I: muse-el source: debian-watch-file-is-missing
I: elpa-muse: debian-news-entry-uses-asterisk
X: elpa-muse: privacy-breach-generic usr/share/doc/elpa-muse/examples/mwolson/templates/generic-header.html (http://www.mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic usr/share/doc/elpa-muse/examples/mwolson/templates/header.html (http://blog.mwolson.org/index.rss)
X: elpa-muse: privacy-breach-generic usr/share/doc/elpa-muse/examples/mwolson/templates/header.html (http://mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic ... use --no-tag-display-limit to see all (or pipe to a file/program)
I: muse-el: debian-news-entry-uses-asterisk
I: muse-el: description-synopsis-might-not-be-phrased-properly
10. How are the *.py files meant to be used? Are they supposed to be
copied into a pyblosxom installation, or run directly from where they
are installed? If the latter, they should be bytecompiled and installed
into /usr/share/elpa-muse/contrib. If the former, they are fine as they are.
11. I've now reviewed d/copyright. Unfortunately, you can't claim that
the debian/ directory is GPL-3+ without contacting each of the authors
you name and confirming they are happy to release their contributors
under that license, since it was not explicitly stated. What happens if
one of them is only happy with GPL-2, and no later versions?
I think this means that you can't switch to copyright format 1.0, and
have to keep the old copyright file. You could add credit for revamping
the package for yourself if you like.
12. Your change in the "Priority:" field is not in the changelog.
13. You bumped the standards-version but didn't mention it in the
changelog. Did you review the upgrading checklist?[1]
14. Consider s/emacs24/emacs25/ in build-depends-indep.
15. Why does elpa-muse depend on emacs-goodies-el? Maybe add a comment
to the control file.
16. muse-el is not a library. It shouldn't be in section: oldlibs.
17. The deletion of d/emacsen-* is not in the changelog. Similarly,
d/muse-el.dirs.
18. At dh compat 10, you can drop --parallel from d/rules.
19. I think you should remove Joey Hess's copyright notice in d/rules,
since you're not using old-style debhelper at all anymore.
On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote:
> On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote:
> > In the future, when submitting a new bug, please use X-Debbugs-CC: rather
> > than CC: so that the bug gets assigned a number before reaching my
> > inbox.
>
> Would you please share how to get X-Debbugs-CC: to show up in mutt's
> edit_headers? It seems to be ignored unless it is set using this:
> my_hdr X-Debbugs-CC: bogus_value
You can just add it. Just add it to the end of the block of headers.
Or you can include it at the beginning of the message as a
pseudo-header, like "Control:" and "Version:" etc.
> Close the ITA bug in the changelog? Do I need to send a control email
> to the ITA bug (something like "also affects")? I anticipate a
> "closes bugs improperly" lintian error.
* New Maintainer. (Closes: #xxxxxx)
This is fine for the wnpp pseudo-package. No need to affects/reassign.
> > - "Update format." -- from what to what?
>
> I'm not sure what format the old copyright was. Where "Format:" is
> usually found it said this:
> This package was debianized by Trent Buck <trentbuck@gmail.com> on
> Thu, 23 Jun 2005 13:12:12 +1000.
>
> Updated to this:
> Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Right. So you should say "Rewrite d/copyright to use machine-readable
format 1.0." Anyway, see above :(
> > 3. README.Debian should have a single timestamp. Remove the
> > previous maintainer's timestamp, add subheadings for the parts added
> > by each of you, and put your timestamp at the bottom.
>
> I'm not adding any new information so much as updating the paths to
> reflect the new install locations. Please let me know if this is a
> more clear to do it this way than my original "Whenever path X is
> mentioned, it actually refers to path Y". The upside is the paths can
> now be copied and pasted, useful full-text search, usefully grepped
> etc, but I'm not sure if I've sufficiently attributed the original
> author.
What you've done looks good to me.
> > > Do my patches look ok?
> >
> > 8. They need patch headers, preferably conforming to DEP-3, explaining
> > what each of them is for. Try to include a Forwarded: header, in
> > particular.
>
> I've added headers, and I've added you to the "Reviewed-by: " one. Why
> do I need the "Forwarded: " header when my patch is already checked into
> git.debian.org?
You need "Forwarded: not-needed" to indicate that the patch is Debian-specific.
> > > Should elpafied packages continue to be arch-independent?
> >
> > Yup.
>
> When debugging some of my failed experimental modifications I noticed
> that this is a binary package. Is arch-independent interpreted source
> + docs still a binary package? As far as I can tell, the
> QuickStart.pdf is the only binary.
I'm not sure what you mean when you say "binary package". In Debian,
"binary package" is the "Package:" field in d/control. Could you
rephrase your question?
> Please let me know if I've correctly addressed all ellipted items.
All looks good aside from mentioning the priority change in the
changelog.
[1] https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature