Dear Sean, 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. 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 ;-) > 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). Done/pending. > 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). > 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" ;-) > 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. > > 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/* > > > 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: [...] > > 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. > > 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. You're welcome. In this particular case, I prefer to be conservative vs disruptive ;-) > > > 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. > 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. 13. This is what I went with: > - Bump standards version to 3.9.8. > Various changes elsewhere in this changelog entry. > > > > 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? Updated package should be on mentors in the next few minutes. The git repo is of course current. Cheers, Nicholas
Attachment:
signature.asc
Description: Digital signature