Dear Nicholas,
On Thu, Dec 29, 2016 at 09:10:28PM -0700, Nicholas D Steeves wrote:
> I hope you're enjoying the holidays. Mine have been busy, and I hope
> this version of src:muse-el is of sufficient quality to be uploaded to
> the archive, because the addition of the new package elpa-muse won't
> be possible after Jan 5th.
Thank you for your updated package. As mentioned previously, we're
still in time for binNEW. I've found six remaining issues. All are
very easy to fix/check. Some of these I should have found earlier, so
my apologies for that. Some of them are due to your most recent
changes, though.
1) From running adequate:
2m48.4s ERROR: FAIL: Inadequate results from running adequate!
muse-el: obsolete-conffile /etc/emacs/site-start.d/50muse-el.el
Please read dpkg-maintscript-helper(1) to fix this.
2) "License: MIT" should be "License: Expat".
"MIT" is ambiguous between various different licenses.
3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
reflected in d/copyright.
4) contrib/pyblosxom/make-blog has a custom license.
5) COPYING is not copyright the muse-el authors! By convention, we
ignore copies of licenses in d/copyright, so you can just remove it.
6) elpa-muse_3.20+dfsg-1_all.deb did not install cleanly. I pushed a
commit fixing the problem -- please check it is okay with you.
Don't forget to update the changelog for the above, and `dch -r`. I
would recommend testing with piuparts to confirm the (1) and (6) are
resolved. I'm confident that I'll be able to upload once you've
resolved these six points, though I've replied to your other comments
below.
> On Sat, Dec 10, 2016 at 02:46:11PM -0700, Sean Whitton wrote:
> > 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.
>
> I'm collecting a list of mistakes I'm likely to make when I'm not 100%
> focused on the work I'm doing; in the future, I plan to use it as a
> personal checklist. If any of these mistakes fall into the "useful
> for other new packages" category, please let me know and I'll find a
> wiki.d.org article to contribute to. On the other hand, maybe they're
> just dumb mistakes ;-)
I'd just recommend the technique of putting your work aside for a few
hours and coming back to it. I.e., fix everything, walk away and do
something else, come back and look over what you did before, and then
upload.
> > 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.
> >
> Ah, specifically with a comment in d/control vs d/changelog. Fixed,
> plus a mistake I missed; in d/changelog I had intended to compromise
> with recommends vs requires, but failed to make the change to
> d/control).
Great.
> > 4. "- Change section to editors; Change priority to optional."
> >
> > This should be two separate lines.
>
> Notice of this kind of convention I'd like to see in a "New Packages
> Guide" ;-)
This should probably be in maint-guide. You could file a bug if there
is no mention there. The idea is simply that each '*' is a separate
change.
> > 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?
>
> Sorry, unfortunately I have not. Yes, please help me with this and
> feel free commit directly to pkg-emacsen.
Sorry -- I couldn't figure out what your problem was, from your previous
message. If you'd like me to try to help, please have another go at
explaining it (or we can just forget about it if you have other things
to do).
> > > 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/*
>
> Originally I tried (and failed) to limit the override, so fell back to
> the sloppy glob approach. For future reference to anyone reading this
> thread, this is the syntax that worked for me:
>
> elpa-muse binary: privacy-breach-generic usr/share/doc/elpa-muse/examples/mwolson/*
Cool! It's a more explanatory override.
> > > > 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?
> [ see previous emails for details ]
> >
> > 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/.
>
> I failed to understand the hungry glob behaviour of the new spec. Sorry!
>
> > 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?
>
> My only motivation for repackaging was because you recommended
> transitioning to elpa packaging (on #debian-mentors, IIRC) as part of
> adopting the package. While I still haven't backported magit, I
> really appreciate the fact that you backported dh-elpa, so it's also
> my way of saying thank you. :-)
>
> For primary motivation for changes to d/copyright, please refer to the
> "Fix misattributed source" section of the d/changelog. It may be that
> one of the two possible upstreams changed something, thus invalidating
> the original claim to origin. I'm not sure if there are legal
> ramifications to a broken chain of origin, or if it's purely academic,
> but I cannot in good good conscious adopt this package without
> implementing the "Fix misattributed source" change.
Okay, sounds reasonable.
> > 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?
>
> Given that the Jan 5th deadline is just around the corner, I'm going
> to go with option 2 for my first release. Unless Alex Ott makes a new
> release of muse-el ( https://github.com/alexott/muse ), option 2 might
> actually work in this case, because v3.20 is probably the last release
> ( https://www.emacswiki.org/emacs/EmacsMuse#toc8 ). I've contacted
> debian-legal for advice and have CCed you, because I agree that option
> 2 would normally be untenable in the long-term.
Okay, option (2) it is!
> 13. This is what I went with:
> > - Bump standards version to 3.9.8.
> > Various changes elsewhere in this changelog entry.
> >
That's fine.
> > > > 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.
> Ahh. Thank you for clearing this up for me! Would you like to add
> this to the "RenamingPackages" wiki entry, or would you prefer if I
> quote you?
Done. Thanks.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature