Hi Antoine and Sean, If you don't know each other yet, I'll just say that you two of the most friendly and patient people I've met through Debian.
Sean, I've CC'ed you because Antoine expressed interest in joining the pkg-emacsen team, and he asked me a couple of questions about dh-elpa and dh-make-elpa that I couldn't answer. I'd be happy to work your replies into a documentation patch, or a wiki page if you're busy. The questions we need help with are at 2. and especially 4. On 25 April 2017 at 19:07, Antoine Beaupré <anar...@debian.org> wrote: > On 2017-04-25 18:27:11, Nicholas D Steeves wrote: >> On Tue, Apr 25, 2017 at 01:37:12PM -0400, Antoine Beaupré wrote: >>> On 2017-04-25 11:17:28, Nicholas D Steeves wrote: >>> > >>> > It will take some time to learn how this one works, but another reason >>> > I'm interested in maintaining writegood-mode is I'm certain I can >>> > contribute to it. Preliminary packaging is here: >>> > ssh://git.debian.org/git/pkg-emacsen/pkg/writegood-mode.git >>> >>> Excellent. Same remark than writeroom about uploading to >>> mentors.debian.net. :) But it's great you pushed into git! >>> >>> (It's just that I'm lazy: mentors.debian.net shows lintian output for >>> me... ;)) >> >> I've uploaded a package for review. Since I'm still a DM, would you >> please sponsor it if it looks good? I'd be happy to add you to >> uploaders, if you'd like. >> >> https://mentors.debian.net/package/writegood-mode >> dget -x >> https://mentors.debian.net/debian/pool/main/w/writegood-mode/writegood-mode_2.0.2-1.dsc > > thanks! > > here's a short review. > > 1. the package's description doesn't mention "emacs" or "english" - in > the original RFP, i used this instead: > > Description : Minor mode for Emacs to improve English writing > This is a minor mode to aid in finding common writing > problems. Matt Might’s weaselwords scripts inspired this mode. > . > It highlights text based on a set of weasel-words, passive-voice > and duplicate words. My apologies, I failed to scrutinise the differences between the description you provided and the one dh-make-elpa generated. I've merged your copy and credited you in d/copyright. D/* uses the same license as upstream package, which you said was your preference in another thread, so I assume this is ok. By the way, dh-make-elpa and gbp make it really easy to do these packages. From the manpage (plus addition of the gbp repo creation) % git clone -o upstream https://foo.org/foo.git % cd foo % git reset --hard 1.0.0 # package latest stable release % dh-make-elpa --pkg-emacsen % git add debian && git commit -m "initial Debianisation" % git deborig % dpkg-buildpackage -us -uc % gbp create-remote-repo --remote-url-pattern=ssh://git.debian.org/git/pkg-emacsen/pkg/foo.git > 2. that version patch - really necessary? if upstream screwed up their > versioning, it's kind of their problem no? since it's just a > cosmetic change, I would avoid it, personnally. Is it just a cosmetic change? I chose to be cautious out of ignorance of how elpa/MELPA works, because I wonder if it uses this versioning to decide whether to download local-to-$USER updates. We don't recommend that users mix packaging systems like this, of course, and I guess it could be argued that if the system provided version (unpatched is 2.1) is higher than the upstream one (2.0.1), then MELPA would refuse to download locale-to-$USER updates until upstream tagged 2.1.0. I plan to drop a similar patch for writeroom-mode, because the convention of most of these upstreams seems to be to only increment major and minor versions but not patch-level versions. > 3. if you still think it's necessary, explain *why* it is there in the > changelog, not just "it's there". :) same in the patch: not "what" > but "why" in commitlogs... " * Add filename.patch for maximal correctness and just to be extra safe" didn't seem like a strong enough case, and I prefer to do the work when I have time and revert if unnecessary. If it's truly just cosmetic I'll drop it. 'good for some gbp pq practice and another lesson in how *self describing file names are not sufficient for debian changelogs* ;-) > 4. picking a random elpa package (elpa-helm), i notice it depends on > "emacs" while yours depend on "emacs-common" - why? and why the > versioned dependencies? > > > https://anonscm.debian.org/git/pkg-emacsen/pkg/helm.git/tree/debian/control My best guess is it's the difference between a package converted to elpa vs a package created with dh-make-elpa, and I Sean has reasons for generating versioned dependencies by default. This is actually one of the reasons I was paranoid about 2. ;-) > I'm not very familiar with "elpa" packages, so I don't know if it works > or not - did you actually test this? :) Yes, and I was surprised to see teal squiggly lines appear...for passive voice :-o Also, at the moment, the versioned dependencies for sid can be satisfied on stretch. (I built in a sid cowbuilder but installed on stretch). Cheers, Nicholas
