Dear Sean,
Thank you once again for holding me to high standards and for taking
the time to point out what needs work!
1-to-5, and 8: done
>
> 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? ;)
Yes, I agree :-) however, I didn't write that part of d/NEWS and only
made in-line updates to paths. Originally I had added a message at
the top which essentially said "in your head, do s/this/that/ -e s/and
this/with this/ -e s/and don't forget/this either/". It seemed
clumsy, so I decided to merge it and put the originally author's name
unambiguously right at the top.
> 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.
That you for reminding me to fix this; my mental TODO list dropped
this item! On that topic, should examples/* be ready to copy into
place and use, or is ok to let dh_examples compress those? (related to
the answer to 10.)
> 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
E: muse-el source: license-problem-gfdl-invariants README is, to the
best of my knowledge bogus, because that documentation is stripped
from our orig.tarball. I believe it's ok to leave the README
unpatched, but I might be wrong about this.
I've contacted Michael Olson about the possibility of providing an
examples/mwolson tarball on his website, because as I see it the
external links are an integral part of the Muse-managed website
example. Specifically, I believe the intent of the example is to
provide a copy of a website that is browsable online so that the user
can explore both the source layout of a Muse-managed project and
browse the result. In the meantime, I've added an override; if that
override is unacceptable, please let me know. If we can keep the
override, I'd be happy to notify users--with NEWS--of the potential
privacy breach.
> 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.
By reading the following from getstamps.py:
Run 'python getstamps.py' from the directory that contains your
unpublished blog entries.
You may need to make some modification for your situation. This
assumes your blog entries use a .txt extension and that you generate
them from "source" files in a different directory (with an optional
.muse extension).
It would seem that these are intended to be used in the following
manner: user reads the headers of these contributed python programs,
then adapts them to his/her needs, then copies them to the blog
project dir (eg: ~/my_blog). Previous versions of src:muse-el
installed these contributed programs to
/usr/share/doc/muse-el/contrib. According to this precedent and the
intended usage described in the programs header, I believe that the
current location is correct. Alternatively, these files might exist
primarily as examples of how to configure upstream pyblosxom for use
with Muse; if this is the case, then they belong in /usr/share/doc.
> 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.
11.1. I've dropped my addition of debian/* from d/copyright, because I
read that this section is no longer necessary (upgrade checklist,
v3.9.3.0 item 12.5), and I agree with the issue you've raised. Also,
I've restored the copyright boilerplate from the original with only
the addition of the addition of paragraph breaks with ".", plus
changing the indentation of the "On Debian systems" lines, as both are
mandated by the format change.
11.2.
> 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.
Done.
11.3. The package was originally created in 2005, which IIRC was
before GPL3. Upstream COPYING is GPL3+ and d/copyright in
muse-el-3.20+dfsg-0.1 seems to have a global GPL3+ copyright. If we
consider d/* from that version as having undefined copyright, it must
nevertheless necessarily exist as both a DFSG and GPL3+ compatible
license, even if implicitly, because it was distributed in the "main"
section...else the previous package would have been unredistributable.
If d/* is both DFSG and GPL3+ compatible, then I believe I can change
the metadata headers in d/copyright so long as I do not change the
license or boilerplate content.
11.4. Here is what is common between the old src:muse-el and the new.
I used 'comm' to find this:
d/control:
Description: Author and publish projects using Wiki-like markup
Emacs Muse is an authoring and publishing environment for Emacs. It
simplifies the process of writings documents and publishing them to
various output formats, such as DocBook, LaTeX, (X)HTML, TexInfo, and
PDF. It can even produce content suitable for blogging, such as
Blosxom-style .txt files and RDF or RSS 2.0 feeds, using the
muse-blosxom and muse-journal modules.
.
Muse consists of two main parts: an enhanced text-mode for authoring
documents and navigating within Muse projects, and a set of publishing
styles for generating different kinds of output.
WRT d/control:Description, I believe that this is the upstream
description, but if I'm wrong I am willing to rewrite it.
d/NEWS: Everything but the section I added at the top. If I manage to
get in touch with Michael Olson I can ask him about the license,
because he's the exclusive author of it.
d/README.Debian:
I made one grammar change. Other than that, s/muse-el/elpa-muse/,
plus s/QuickStart.html/QuickStart.pdf/. As discussed in a previous
email, the PDF has all the information of the HTML and doesn't need to
be patched for privacy breaches. Also, hopefully I can get in touch
with Mr. Olson about this one :-)
d/rules:
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
I believe that d/copyright needs to be modified with the addition
these two lines:
Source: git://repo.or.cz/muse-el.git
Files-Excluded: texi/muse.texi
because the source in our orig.tarball does not match the gna.org
provided source, and texi/muse.texi is already excluded from our
tarball, and I want it to be automatically excluded from any future
releases. This requires a copyright format update. I find it hard to
believe that the new policy of not needing a debian/* section in
d/copyright will necessarily block future updates to copyright-format >1.0...
Should I email debian-legal@lists.d.org asking if it's ok to change
the format of the d/copyright if the content remains the same, and of
course forward to them this Bug#? I thought that Debian has always
been strict about licensing to prevent impossible situations like not
being able to update metadata like the format of a copyright
file... :-(
--
12, 15, 17, and 18: Done!
> 13. You bumped the standards-version but didn't mention it in the
> changelog. Did you review the upgrading checklist?[1] Yes, quite
carefully, and I read the full text too! With the exception of of
forgetting to mention it this in the changelog, to the best of my
knowledge, the package complies with the new standards version.
> 14. Consider s/emacs24/emacs25/ in build-depends-indep.
I've changed the end of that line to "emacs | emacs25 | emacs24",
because I want to cultivate a habit that insures that all of my future
packages are always backportable.
> 16. muse-el is not a library. It shouldn't be in section: oldlibs.
Ok, I've simply dropped the redefined section for bin:muse-el. The
reason I had put it in oldlibs is because the package renaming guide I
originally read and committed to memory said that "oldlibs" was a
special section for all dummy packages. I take it this is obsolete
now? I didn't notice anything in the upgrade checklist on this topic.
Hope to hear from you soon,
Nicholas
Attachment:
signature.asc
Description: Digital signature