Dear Nicholas,
On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
> Thank you once again for holding me to high standards and for taking
> the time to point out what needs work!
And thank you for your patience with this review process.
I saw some more problems. Some of these are quite elementary errors:
1. You're still not closing the ITA properly. You are missing a '#'
character.
2. There is a spurious '+' character in your rules file that is subtly
breaking the build.
I notice that you have an application to be a DM. These sorts of errors
can cause broken uploads, and confusion among collaborators. Please try
to get into the habit of checking your commits very carefully,
especially when they are intended for upload to Debian.
Okay, now the less elementary stuff:
2. Upstream's README says that the license for contrib/*blosxom is
different from the main project. This should be reflected in
d/copyright (though see below for other issues to resolve first).
3. Point 15 from my previous e-mail not yet addressed:
> Why does elpa-muse depend on emacs-goodies-el? Maybe add a comment to
> the control file.
4. "- Change section to editors; Change priority to optional."
This should be two separate lines.
5. Have you figured out that "binary package" stuff discussed in your
previous e-mail by yourself, or is that something I can help you with?
> > 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.
Okay.
> > 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.)
I think it's fine to let examples be compressed.
> > 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.
Yes, it's fine to leave it unpatched.
> 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.
Looks good to me -- thanks for figuring out the warnings.
It would be good to limit the override to that directory. Lintian
overrides support wildcards, so you should be able to do something like
this (not tested):
elpa-muse binary: privacy-breach-generic*/usr/share/doc/elpa-muse/examples/mwolson/*
> > 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.
I would be inclined to put them in /usr/src/elpa-muse. The propellor
package puts a copy of its upstream source code in /usr/src/propellor.
The current location is fine if you prefer. Thanks for the explanation.
> > 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.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:
> [...]
> 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... :-(
Okay, let's see if I've fully understood the situation.
Firstly, your current copyright file is definitely not right. It
implies that upstream holds copyright on the debian/ directory, which is
false. It also implies that debian/ is GPL-3+, which you definitely
cannot assume (some people believe very strongly that their code should
not automatically upgrade to new versions of the GPL, for one thing).
This is a limitation of the machine-readable copyright format. As the
spec says, "Exclusions are only supported by adding Files paragraphs to
override the previous match." In other words, if you have "Files: *",
the copyright file cannot be silent about the status of debian/.
You are correct, though, to assume that debian/ is DFSG-free.
Secondly, the upgrade checklist point v3.9.3.0 item 12.5 is irrelevant,
because your copyright file *does* say something (incorrect) about
debian/. Deleting the stanza doesn't avoid this, as I just explained.
Thirdly, have I understood you correctly as trying to argue that
everything in debian/ has been edited sufficiently that only you and
Michael Olson hold copyright? And your motivation for doing this is so
that you can have a Files-Excluded: setting at the top of the file?
I think you have three options.
- Make that argument to people on debian-legal. I really don't feel
qualified to assess it.
- Replace "Files: *" with "Files: AUTHORS ChangeLog.* contrib ..." so
that you don't say anything about debian/. This would be extremely
inconvenient as the copyright file would have to be carefully checked
for every upstream release to see if new files were added.
- Just revert to the old copyright file, and use another method to
to the DFSG-filtering, such as the filter setting in d/gbp.conf.
Since the first option is legally murky, and the second is inconvenient,
I would go with the third.
Is that a fair summary of the situation, or have I missed something?
> 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.
Thanks for checking carefully. It's conventional to write something
like this:
- Bump standards version to 3.9.8 (no changes required).
or I suppose if necessary you could write
- Bump standards version to 3.9.8.
Various changes elsewhere in this changelog entry.
> > 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.
Good habit!
> > 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.
Most package renaming is in response to SONAME changes, in which case
'oldlibs' makes sense. But this is not a SONAME change.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature