Bug#840153: Feedback, and dgit-maint-gbp(7)

[Sean Whitton]

On Sat, Oct 29, 2016 at 08:36:54AM -0700, Sean Whitton wrote:
>
> dgit-maint-dgit(7)
> ==
> 

I did, of course, mean dgit-maint-gbp(7).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840153: Feedback, and dgit-maint-gbp(7)

[Sean Whitton]

ting to dgit is reducing the amount of volunteer time spent on
busywork, so we can fix bugs instead.

> > Does --gbp work fine for a patches-applied gbp repository?  Since gbp
> > supports this (the gbp author says so), there might be some around.  If
> > dgit would get confused in this case, this manpage should mention that
> > it assumes patches-unapplied, and possibly refer to dgit-maint-merge(7).
> 
> Yes.  It should.  --gbp assumes patches-unapplied.
> 
> How does gbp tell the difference between a patches-applied and
> patches-unapplied branch ?

I don't think it needs to.  It relies on dpkg-buildpackage applying or
unapplying the patches.  In the e-mail I recall seeing from the gbp
maintainer, he suggested using d/source/local-options.  I'm not sure if
the options that were required are all permitted in d/source/options.

> I think a gbp patches-applied branch could probably be pushed with
> --quilt=dpm, but I haven't tested it.  The reason why a non-default
> quilt mode is needed is that neither dpm or gbp branches contain
> patches (in debian/patches/*) for changes to upstream gitignore.

Right, I thought it might be something to do with that.

I've added a commit saying that the tutorial is for patches-unapplied.

> Thanks for all your help!

Thanks for your feedback.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840153: Feedback, and dgit-maint-gbp(7)

[Sean Whitton]

On Sat, Oct 29, 2016 at 05:12:42PM +0100, Ian Jackson wrote:
> > Feedback on dgit-nmu-simple(7)
> > ==
> > 
> > 1. Small patch to the third paragraph in my branch: s/maintainer's
> > workflow/maintainer's git workflow/.
> > 
> > 2. I can't see why the workflow wouldn't work for a new upstream
> > version.  Could you explain, either just to me or in the manpage?
> 
> Well, the workflow as presented doesn't do anything to produce either
> a new .orig or a git tree which contains appropriate information.  And
> what exactly that git tree's history should look like depends on the
> maintainer's workflow.  The part of the presented workflow that
> updates debian/patches/* is implicit in dgit -wgf push.

I missed replying to this.

If you merged an upstream version and generated a corresponding
orig.tar, how could this be disruptive to the maintainer?  Is that issue
that dgit can't automatically refresh patches, and it would end up
adding a messy patch to the end of the queue to represent the refreshing?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840153: Feedback, and dgit-maint-gbp(7) [and 1 more messages]

[Sean Whitton]

Hello Ian,

On Sat, Oct 29, 2016 at 09:47:42PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#840153: Feedback, and dgit-maint-gbp(7)"):
> > I should say that there are some commits on my branch that I didn't
> > explicitly suggest cherry-picking in my previous e-mail.  Most of them I
> > added after sending that e-mail.  Apologies if that's inconvenient.
> 
> Oh!  Would you care to separate out the ones you would like me to
> take, into their own (sub) branch ?

I'm suggesting you take all of them -- I just didn't mention all of them
in my e-mails.  Sorry for not being clearer.

> > How about adding advice to the sponsor, saying
> > 
> > "if your sponsee has added a tag, ask them to delete it from their
> > repo /before/ you upload, as part of the review process.  This
> > avoids confusion and difficulties later"
> 
> I wonder if it would be better practice for the sponsor to make the
> tag and finalise the changelog.  With dgit, changes made by the
> sponsor are easily picked up by the sponsee.

I would not be in favour of that practice.

To my mind, the act of sponsorship is and should be limited to applying
a PGP signature to the .changes and .dsc files (sponsors tend to dput
the package too, but that's just for convenience).  Of course, a sponsor
won't be willing to apply a signature if they don't deem the package
ready for upload, but in giving feedback they're acting in the role of
reviewer -- which is a role open to non-DDs.

I see this as important because it emphasises that the package upload is
the responsibility of the sponsee, and they're no less responsible for
dealing with bugs etc. than a DD/DM would be.  When they run `dch -r`
they are taking responsibility for that upload.  Having all sponsees
take that step is important for maintaining that sense of
responsibility.  It's also a way of respecting the work of sponsees, as
being on the same level as that of DDs/DMs.

Anyway, this isn't really a discussion for this bug report.  What do you
think about adding a commit to suggest having them delete the tag, if
they added it?

> > > How does gbp tell the difference between a patches-applied and
> > > patches-unapplied branch ?
> > 
> > I don't think it needs to.  It relies on dpkg-buildpackage applying or
> > unapplying the patches.  In the e-mail I recall seeing from the gbp
> > maintainer, he suggested using d/source/local-options.  I'm not sure if
> > the options that were required are all permitted in d/source/options.
> 
> It is in impossible to reliably tell the difference between a
> patches-applied and a patches-unapplied tree.  If dpkgs-source is
> doing that it is not reliable.
> 
> Consider the following edge case:
> 
>  $ dgit clone foo
>  [ observe that actually the bug is being generated by the sole
>Debian patch ]
>  * git revert [that sole Dbian patch]
>  * [ edit changelog ]
> 
> This tree is a valid patches-unapplied tree.  But the user's intent is
> that it's a patches-unapplied tree.

Indeed.  I think we can safely ignore patches-applied gbp repositories
for now.  Someone might come up with a sensible test case at some point.

> > If you merged an upstream version and generated a corresponding
> > orig.tar, how could this be disruptive to the maintainer?  Is that issue
> > that dgit can't automatically refresh patches, and it would end up
> > adding a messy patch to the end of the queue to represent the refreshing?
> 
> dgit in the default quilt mode insists on simply adding new patches.
> 
> Even if you were prepared to --quilt=smash, the existing patch queue
> in debian/patches probably wouldn't apply anyway, so the result of
> your proposed new .orig and merge would be produce an incomprehensible
> tree.  Neither dgit nor dpkg-source could work with it.
> 
> Somehow someone would have to refresh the patch stack.  dgit can't do
> that by itself because there might not be a single commit
> corresponding to the upstream tarball; that even if there is there is
> no reasonable way to find i; and anyway the patches might have
> conflicts (which perhaps the user resolved during the merge).
> 
> The only way to make all this work is for the NMUer to explicitly set
> out to rebase the patch queue (perhaps using some tool like gbp).

Thanks for explaining that.  Sounds like we should leave that part of
the manpage as it is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842517: RFS: self-destructing-cookies/0.4.11-1

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "self-destructing-cookies".

* Package name: self-destructing-cookies
  Version : 0.4.11-1
  Upstream Author : Ove Sörensen 
* URL : 
https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/
* License : GPL-2+
  Section : web

Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/s/self-destructing-cookies/self-destructing-cookies_0.4.11-1.dsc

Or from git:

git clone 
https://anonscm.debian.org/git/pkg-mozext/self-destructing-cookies.git
cd self-destructing-cookies
git checkout debian/0.4.11-1
git verify-tag debian/0.4.11-1 # my key is in the DM keyring
gbp buildpackage

Changes since the last upload:

  * New upstream release.
  * Drop d/missing-sources.
Now included by upstream in release.
- Update d/copyright accordingly.
  * Drop 0001-fix-license-in-package.json.patch
Obsoleted by upstream change.
  * Bump debhelper compat & build-dep to 10.
  * Replace Repository: -> Repository-Browse: in upstream metadata.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841222: Acknowledgement (RFS: patat)

[Sean Whitton]

Hello Félix,

I noticed that you've published your patch-queue/master branch.  Since
that is a branch you will rebase, it's not a good idea to publish it
(the gbp documentation recommends against publishing it).  Anyone who
needs the branch can reconstruct it with `gbp pq import`.

Unfortunately, patat doesn't build against sid at present.  Hopefully
this will be resolved within the next week or so.  In the meantime,
there is some stuff you can improve:

On Tue, Oct 25, 2016 at 10:34:11PM +0200, Félix Sipma wrote:
> On 2016-10-23 11:51-0700, Sean Whitton wrote:
> > You should use "Forwarded: not-needed" (see DEP-3).
> 
> This does not seem to work with gbp-pq (see #785274), I propose to add this as
> soon as gbp-pq supports DEP-3.

Indeed.  Dmitry Bogatov pointed out to me that you can put the
Forwarded: header at the end of the patch description (just before the
---) and then gbp won't remove it.

I wanted to confirm that you'd forwarded your --version patch, but I
couldn't without this header :)

> >>> 2. You can fix all of these Lintian tags, except possibly
> >>> hardening-no-fortify-functions.  You should definitely deal with
> >>> the warnings.
> >>> 
> >>> W: patat-dbgsym: debug-file-with-no-debug-symbols
> >> 
> >> I've updated debian/rules to something matching
> >> stylish-haskell.

Your d/rules is fine, though I think that the override_dh_compress stanza
is not needed: policy says you should only compress files above a
certain size, and presumably dh_compress isn't compressing the README
because it is smaller than that size.

On the next upload of stylish-haskell I will probably remove that
stanza -- sorry to mislead you!

> >>> I: patat: spelling-error-in-binary usr/bin/patat Nam Name
> >>> I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
> >>> I: patat: spelling-error-in-binary usr/bin/patat forward forward
> >>> I: patat: spelling-error-in-binary usr/bin/patat upto up to
> >>> I: patat: spelling-error-in-binary usr/bin/patat discontigous 
> >>> discontiguous
> >>> I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
> >>> I: patat: spelling-error-in-binary usr/bin/patat The The
> >> 
> >> Not sure about this one... Is "patat" too generic for lintian? I've
> >> added this to debian/lintian-overrides.
> > 
> > I don't understand.  It is pointing out misspellings, such as
> > 'uncomplete', somewhere in the upstream source.  You can add a quilt
> > patch to fix them, and forward it upstream.
> 
> As I didn't found anything matching these errors in the source, I thought it
> was a generic error message concerning the binary name.
> 
> Now, that I understood the purpose of this check, I can only found these
> mistakes in the binary itself, so I guess these are in the dependencies...

Okay.  In that case you should override them, with a comment in the
overrides file explaining why.

> >>> I: patat: hardening-no-bindnow usr/bin/patat I: patat:
> >>> hardening-no-pie usr/bin/patat
> >>> 
> >>> I think that in order to pass hardening options to gcc, if you're
> >>> willing to work on that, you'll need to abandon the CDBS build system
> >>> you're using at present.  See the Makefile for keysafe[1] (not yet in
> >>> Debian) to see how to pass the options, and the rules file for the
> >>> stylish-haskell package to see how to do without CDBS.
> >> 
> >> After reading this Makefile, I'm not sure how keysafe avoids
> >> hardening-no-bindnow and hardening-no-pie... Do you have any clue?
> > 
> > The Makefile propagates LDFLAGS, CFLAGS and CPPFLAGS through to ghc.
> > Then you enable all hardening in your d/rules,[1] and the right flags
> > get set by debhelper.
> > 
> > [1] https://wiki.debian.org/Hardening
> 
> I would like to wait a little before adding this: the default flags added to
> gcc seems quite new, so I propose to have a look again when things stabilize.

Fair enough.

FWIW keysafe's hardening is working fine, except for PIE, which has to
be disabled for Haskell atm.  https://git.spwhitton.name/keysafe

> >>> 3. Please run upstream's test suite during the package build.
> >> 
> >> Should be done now, I'm not sure about how I run tests... See
> >> debian/rules override_dh_auto_test

Okay.  I can't test this atm because patat can't be built in sid, but
what you did looks sane.

> > If help2man is insufficient, see again stylish-haskell where I use
> 

Bug#832704: RFS: nixnote2

[Sean Whitton]

Dear Boyuan,

On Wed, Sep 21, 2016 at 07:25:22PM -0700, Sean Whitton wrote:
> I just reviewed the latest changes in your nixnote2 git repo, as part of
> confirming that nixnote2 works with the new qevercloud shlib.
> 
> I have the following remaining suggestions (none are "must fix"):

Are you waiting on qevercloud to make it through NEW to work on these?

I think it would be best to get nixnote2 into NEW sooner than that.  The
ftp-masters are probably planning to empty the queue before the soft
freeze, but there might not be enough time between the emptying of NEW
and the soft freeze to get nixnote in.  It would be a shame if
qevercloud went into stretch and nixnote2 didn't!

It's fine for packages that depend on other to be in NEW so long as the
dependency relationships are not complicated.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842608: dgit pull should bail out in splitbrain mode

[Sean Whitton]

Package: dgit
Version: 2.8
Severity: normal

Since all the other dgit commands work in splitbrain mode if you pass
(e.g.) --gbp, a user might expect dgit pull to DTRT.

Since it won't, it should exit with an error in splitbrain mode.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dgit depends on:
ii  ca-certificates   20160104
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.16.8
ii  dpkg-dev  1.18.10
ii  dput  0.10.3
ii  git [git-core]1:2.9.3-1
ii  git-buildpackage  0.8.6
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc3-3
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc3-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-1

Versions of packages dgit suggests:
ii  sbuild  0.71.0-2

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840153: Feedback, and dgit-maint-gbp(7) [and 1 more messages]

[Sean Whitton]

Hello Ian,

On Sun, Oct 30, 2016 at 05:26:32PM +, Ian Jackson wrote:
> Thanks a lot for your excellent contributions.  I rewrote my own
> wip.tutorials branch to have non-nonsense commit messages, rebased
> your branch on top, and made two new commits of my own:
>   - to fix some missing quotes in a dch rune in dgit-nmu-simple
>   - to add a `local-pod-man' convenience script
> 
> I have pushed the result to my public wip.tutorials branch.  I think I
> am going to try to avoid rebasing this again unless there's a good
> reason.  The rebasing seems just to cause trouble here, because there
> is no interaction with (eg) the test suite.

So are you saying that all the commits in my branch from yesterday are
now included in yours?  It's hard for me to tell due to the rebasing.

> I have implemented the --dgit-view-save option.  You can find it in my
> branch "wip" on chiark (very definitely rebasing, that branch!)  I
> haven't updated dgit-sponsorship(7) for it yet.

Done in my wip.tutorials-new.

> If I'm lucky I will manage to fix #841084 (gbp orig generation) and
> provide support for DELAYED, today.

I see some commits for this in your master branch, so I've gone ahead
and added a commit to my wip.tutorials-new branch mentioning the option.

On Sun, Oct 30, 2016 at 05:36:57PM +, Ian Jackson wrote:
> Reading dgit-maint-gbp(7), I see this:
> 
> INCORPORATING NMUS
>  % dgit --gbp pull
> 
> Will this actually work ?  I think it will apply the changes from the
> NMU both to debian/patches/ and to the actual files.  This will risk
> conflicts in the upstream files (if previous patches touch the same
> files) and generate a partially-applied git branch.
> 
> It will also create a patch for .gitignore changes, which is probably
> not desirable.

Yes, I thought I might be being too optimistic about that.  I've added a
commit to my wip.tutorials-new saying that it doesn't work yet.

> Maybe it is a bug that dgit --gbp pull doesn't DTRT.  It could do some
> kind of clever thing where it spots that we're in split brain mode and
> merges only changes to debian/patches.
> 
> But I think making this work in the general case (with all --quilt=
> options etc.) is beyond the scope of what I have time for in the next
> few days.
> 
> Do you think that in the meantime I should make `dgit pull' bomb out
> in split brain quilt modes ?

I've filed another bug to keep track of this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840153: Feedback, and dgit-maint-gbp(7) [and 1 more messages]

[Sean Whitton]

Hello,

On Sun, Oct 30, 2016 at 05:43:29PM +, Ian Jackson wrote:
> Oh, and: had you considered recommending `gbp dch' ?

I decided to limit the contents of dgit-maint-gbp(7) to the
dgit-specific parts of the workflow.  People already have their gbp
workflows, possibly involving `gbp dch`, and the point of the manpage is
to show how dgit can be painlessly inserted into that workflow.

Did you have a dgit-specific use of gbp-dch in mind?

Personally, I don't want to think about my changelog entries when making
commits.[1]

[1] https://joeyh.name/blog/entry/our_beautiful_fake_histories/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#761219: Also update/clarify when real package has same name as virtual package

[Sean Whitton]

Hello,

Something else that might need updating in light of dpkg's support for
versioned Provides: is the advice that

If a relationship field has a version number attached, only real
packages will be considered to see whether the relationship is
satisfied (or the prohibition violated, for a conflict or
breakage). In other words, if a version number is specified, this is
a request to ignore all Provides for that package name and consider
only real packages.

Would a versioned Provides:, too, get ignored if there is real package
with the same name present?

-- 
Sean Whitton

Bug#842885: mk-origtargz: shouldn't fail when file downloaded is uncompressed tar archive

[Sean Whitton]

Package: devscripts
Version: 2.16.8
Severity: normal
File: /usr/bin/mk-origtargz

The watch file of the seq-el source package downloads an uncompressed
tar archive.  uscan then invokes mk-origtargz to "repack" the file with
xz compression.  However, this fails because $tar_regex in mk-origtargz
doesn't match uncompressed tar archives.  Is there any reason that
\.tar$ couldn't be added to the regex?

Thanks.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_FORCE_SAVE_ON_RELEASE=no
DEBRELEASE_UPLOADER=dput
DEBSIGN_KEYID=0x0F56D0553B6D411B
DEB_SIGN_KEYID=0x0F56D0553B6D411B
DEBSIGN_PROGRAM=gpg
DSCVERIFY_KEYRINGS=~/.gnupg/pubring.kbx
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc"

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.10
ii  libc62.24-5
ii  perl 5.24.1~rc3-3
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.3.1
ii  at  3.1.20-1
ii  curl7.50.1-1
ii  dctrl-tools 2.24-2
ii  debian-keyring  2016.09.04
ii  dput0.10.3
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-2
ii  file1:5.28-4
ii  gnupg   2.1.15-4
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.24-1
ii  lintian 2.5.49
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.29
ii  python3-magic   1:5.28-4
ii  sensible-utils  0.0.9
ii  strace  4.13-0.1
ii  unzip   6.0-20
ii  wdiff   1.2.2-1+b1
ii  wget1.18-4
ii  xz-utils5.2.2-1.2

Versions of packages devscripts suggests:
ii  adequate 0.15.1
ii  autopkgtest  4.1
ii  bls-standalone   0.20151231
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
ii  build-essential  12.2
ii  check-all-the-things 2016.09.03
pn  cvs-buildpackage 
pn  devscripts-el
ii  diffoscope   61
pn  disorderfs   
ii  dose-extra   5.0.1-2
ii  duck 0.10
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-2
ii  gpgv 2.1.15-4
ii  how-can-i-help   14
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mozilla-devscripts   0.47
ii  mutt 1.7.1-2
ii  openssh-client [ssh-client]  1:7.3p1-1
ii  piuparts 0.72
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.6
ii  w3m  0.5.3-31

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841222: Acknowledgement (RFS: patat)

[Sean Whitton]

control: tag -1 +confirmed
control: noowner -1

Hello Félix,

I'm tagging this as confirmed (commit
184eb7ba0dfb453cd5aa759a1a88fdbee6ed5367) because you've addressed
everything I brought up, but I've also written some comments below in
response to your most recent message.

On Mon, Oct 31, 2016 at 05:33:16PM +0100, Félix Sipma wrote:
> > On Tue, Oct 25, 2016 at 10:34:11PM +0200, Félix Sipma wrote:
> >> On 2016-10-23 11:51-0700, Sean Whitton wrote:
> >>> You should use "Forwarded: not-needed" (see DEP-3).
> >> 
> >> This does not seem to work with gbp-pq (see #785274), I propose to add 
> >> this as
> >> soon as gbp-pq supports DEP-3.
> > 
> > Indeed.  Dmitry Bogatov pointed out to me that you can put the
> > Forwarded: header at the end of the patch description (just before the
> > ---) and then gbp won't remove it.
> 
> It seems like gbp _does_ remove the Forwarded: header put just before the
> ---...

Not on my machine -- weird.

iris ~/rfs/patat % gbp pq import
gbp:info: Trying to apply patches at
'184eb7ba0dfb453cd5aa759a1a88fdbee6ed5367'
gbp:info: 1 patches listed in 'debian/patches/series' imported on
'patch-queue/master'
iris ~/rfs/patat % gbp pq export
gbp:info: On 'patch-queue/master', switching to 'master'
gbp:info: Generating patches from git (master..patch-queue/master)
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
gbp:info: Dropped branch 'patch-queue/master'.
iris ~/rfs/patat % git diff
[no output, and indeed your Forwarded: header is present]

> > I wanted to confirm that you'd forwarded your --version patch, but I
> > couldn't without this header :)
> 
> This particular patch is not needed anymore (fixed upstream). I pushed a new
> version to my repo, and will put this new version on mentors as soon as pandoc
> gets installable again.

Looks good.

> >>>>> I: patat: spelling-error-in-binary usr/bin/patat Nam Name
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat forward forward
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat upto up to
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat discontigous 
> >>>>> discontiguous
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
> >>>>> I: patat: spelling-error-in-binary usr/bin/patat The The
>
> [...]
> 
> I guess it is better to not override this warning, so that we don't forget 
> that
> the dependencies needs to be fixed.

Fair enough.  My reasoning was that you can't fix it within this
package, so the warning shouldn't be emitted here.

> > 2. Did you generate it with help2man, in the end?  If so, there should
> > be a rule in d/rules to allow someone to regenerate the manpage for a
> > new upstream version (see the ocrmypdf package's rules file).  If
> > upstream introduces a new upstream version it should be easy to update
> > the manpage.
> 
> No. I did it by hand, help2man generated something ugly :-).

Cool!

> > 3. It might be nice to add a reference to the file in
> > /usr/share/doc/patat/examples to the manpage.  If I wanted to learn
> > how to use patat, the manpage alone wouldn't be much use.
> 
> Upstream is working on a manpage (see
> https://github.com/jaspervdj/patat/issues/19 ). I'll add this manpage later,
> for now I would like to have patat in debian. This manpage stuff is not
> essential (and it takes time to work on it, that's why I didn't want to work 
> on
> this), so I'd like to keep it like this, and update it as soon as upstream
> release a manpage.

I understand why you wouldn't want to work on a manpage in parallel with
upstream's work, as you'll have to just throw yours away once they
release theirs.  It's good to hear that they've decided to work on
that -- thanks for prompting them.

General remarks in response to what you wrote:

Debian has a lot of unmaintained and low-quality packages because people
wanted to "have it in Debian", but weren't willing to put time into
making the package high-quality.  That's why, in the RFS review process,
we try to give new contributors opportunities to demonstrate that they
want to make their package high-quality.  DDs are generally reluctant to
sponsor packages where it is not clear that the packager is planning to
continue to put time into the package after it has been uploaded.

In this case you've amply demonstrated that you're willing to maintain
the package, but I just wanted to explain to you why I've been insisting
on these things that, as you say, aren't essential.

> patat is buildable again on sid.

I just built and installed the package and everything seems to work.

You could look into adding the hardening flags, now that the Haskell
transition is almost completely finished.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#843430: RFS: ocrmypdf/4.3-1

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new release of ocrmypdf.

I have DM upload rights for this package, but this revision introduces a
new binary package, ocrmypdf-doc.

* Package name: ocrmypdf
  Version : 4.3-1
  Upstream Author : James R. Barlow 
* URL : https://github.com/jbarlow83/OCRmyPDF
* License : Expat
  Section : graphics

Changes since the last upload:

  * New upstream release.
- Remove dropped tasks.py from d/copyright.
  * New ocrmypdf-doc binary package: upstream's new HTML documentation.
- Set PYBUILD_DESTDIR in d/rules.
- Add override_dh_{auto_build,installdocs,sphinxdoc} targets to d/rules.
- ocrmypdf suggests python-watchdog.
  See "Cookbook" documentation entry.
- New build dependencies:
  - python3-sphinx
  - python3-sphinx-rtd-theme
  * Add doc-base registration.
  * Add patch-docs-for-Debian.patch
  * Add path-to-docs-for-Debian.patch
  * Add disable-mathjax.patch
  * Add pip-to-apt-get.patch
  * Bump debhelper compat & build-dep to 10.

I normally upload ocrmypdf with dgit, so I'd like to request sponsorship
using dgit so that the git history on dgit-repos is not interrupted.

% git clone https://git.spwhitton.name/ocrmypdf
% cd ocrmypdf
% git rev-parse HEAD
14ee9e157b2347d13c0dc90316514db8c36cb9c5

% origtargz # invokes pristine-tar to extract orig.tar
% sha256sum ../ocrmypdf_4.3.orig.tar.xz
dc79c4078e1fd0cb8fa5c010f418fc00a7683da3f27add7477289e38daf07b02  
../ocrmypdf_4.3.orig.tar.xz

% dgit fetch
% git diff dgit/dgit/sid..HEAD   # review my changes
% git diff dgit/dgit/sid..HEAD -- debian # review just debian/ changes

% dgit sbuild || dgit gbp-build --git-pbuilder
# ^ no source-only uploads to binNEW!
% dgit push

If you have any trouble with this, I'd appreciate if you'd ask me about
it rather than doing an upload that bypasses dgit, as that would break
the history on dgit-repos.  I'm interested in making sponsorship with
dgit a smooth and well-documented process.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832704: RFS: nixnote2/2.0~beta10+dfsg-1 [ITP] -- Open Source Evernote client

[Sean Whitton]

Hello Gianfranco,

On Fri, Nov 18, 2016 at 06:54:01PM +, Gianfranco Costamagna wrote:
> Hi, I put the package in deferred/5, because I'm not sure about the whole 
> license.
> Isn't it something like GPL-2+ instead of GPL-2?
> I agree single files are ok, but the "*" wildcard seems a GPL-2+ to me, even 
> if
> I didn't find a copying file.

See license.html.  The project is GPL-2, but some files have GPL-2+ in
their headers.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

control: retitle -1 RFS: verilog-mode/20160910.debfc6d-1 [ITP]

Dear Kiwamu,

Thank you for your work to bring this new package to Debian!  As I said,
I can't sponsor the upload, but I hope this more detailed review is
useful to you.

I've split it into two sections: things that I would consider must-fixes
before an upload to Debian, and suggested improvements.  The latter
aren't strictly necessary, but they would help demonstrate to a
potential sponsor that you are committed to maintaining this package in
Debian.

Must fixes
==

1. The line "Only support emacs and xemacs" doesn't make sense (what
else would you be supporting?).  What were you trying to say?

2. There is a Lintian error:

E: verilog-mode: info-document-missing-dir-section 
usr/share/info/verilog.info.gz

3. Some files are not GPL-3+.  For example,
tests/auto_delete_whitespace.v.  Please check every file's copyright
status and detail in d/copyright.

4. The README is useless to an end user who has already installed the
package, so you shouldn't be installing it -- it could be confusing.

5. You've missed some steps of the Emacs policy.[1]  For example, you
are missing a emacsen compat level.  Please check the policy carefully.

Suggestions
===

1. It would be best to build-depend on emacs25, not emacs24.  emacs24
might be removed from stretch.

2. At debhelper compat 10, you can probably delete
debian/verilog-mode.dirs.

3. You are generating ChangeLog.txt but not installing it.  You can use
dh_installchangelogs(1).

4. How about installing verilog-lex.el as an example?  See
dh_installexamples(1).  Or possibly somewhere else.

[1] https://www.debian.org/doc/packaging-manuals/debian-emacs-policy

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832941: RFS: 4pane (debian: to exclusive)

[Sean Whitton]

Dear David,

1. Why do you have a folder full of patches, when you are the upstream
author of 4Pane?  Have they been applied upstream, but there hasn't been
a release of 4Pane recently?  DEP-3 has a patch header to indicate that
they have been merged upstream, if this is indeed the case.

2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian
policy permits you too.  Good idea.  The only thing I'm not sure about
is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html.
It could be misleading, since Debian users expect /usr/share/doc/foo to
give them a folder containing a changelog, a Debian changelog etc.  Why
not link to /usr/share/doc/4pane?

On Mon, Nov 14, 2016 at 09:30:49PM +, David Hart wrote:
> For simplicity, I've just removed the tarball. It can always be done properly
> in the future when I understand better what is required.

Okay.

> >Also, the Vcs-* fields still point to the upstream source, not the
> >packaging repository.
> 
> Does this need to be fixed before you can use the repo.

No.

> If so, what should I enter there?  Vcs-Git:
> https://github.com/dghart/4pane-debian-dir -b master Vcs-browser:
> https://github.com/dghart/4pane-debian-dir/tree/master or something
> different?

You should look up the definitions of the Vcs-* fields in Debian policy :)

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

Package: yasnippet
Version: 0.9.0~beta1-5
Severity: important

Dear maintainer,

yasnippet is broken with emacs25.  A sampling of errors from *Messages*:

Error while loading 50yasnippet: Wrong type argument: integerp, nil

yas--define-snippets-1: Wrong type argument: integerp, nil

Error in post-command-hook (yas-global-mode-check-buffers): 
(wrong-type-argument integerp nil)

emacs24 might not be included in stretch, so this bug has the potential
to become release-critical.  It would be great to see an updated
yasnippet (ideally including a fix for #818440).

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844653: [Pkg-mozext-maintainers] Bug#844653: Bug#844653: stylish FTBFS in testing: firefox-dev won't be in stretch

[Sean Whitton]

On Sun, Nov 20, 2016 at 04:55:30PM +0900, Mike Hommey wrote:
> Wait what? Packages that build depend on a package that is not in
> stretch are in stretch? WTF?

Britney doesn't check build dependencies.

-- 
Sean Whitton

Bug#845127: xul-ext-webdeveloper: Embedded code copy of beautify.js

[Sean Whitton]

Package: xul-ext-webdeveloper
Version: 1.2.5+repack-3
Severity: normal
Control: block -1 by 816830

Dear maintainer,

xul-ext-webdeveloper contains an embedded copy of beautify.js.  This
should be packaged separately, as libjs-beautify.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xul-ext-webdeveloper depends on:
ii  firefox  50.0-2
ii  fonts-font-awesome   4.6.3~dfsg-1
ii  libjs-codemirror 5.4.0-1
ii  libjs-jquery 3.1.1-1
ii  libjs-twitter-bootstrap  2.0.2+dfsg-10

xul-ext-webdeveloper recommends no packages.

xul-ext-webdeveloper suggests no packages.

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845155: RFS: rmlint/2.4.4

[Sean Whitton]

control: retitle -1 RFP: rmlint -- file deduplication toolset
control: reassign -1 wnpp

On Sun, Nov 20, 2016 at 10:12:30PM +0100, Christopher Pahl wrote:
> In short: I'm looking for a sponsor *and* maintainer (which do not need to be 
> the same person).
> Optimally the maintainer would be someone that uses rmlint from time to time.
> The package already builds the cli and might only need minimal review.

This is an RFP, not an RFS.  Fixed :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

Hello Alberto,

On Mon, Nov 21, 2016 at 08:24:31AM +0100, Alberto Luaces wrote:
> actually I am in the process of packaging the most recent version with
> dh_elpa, so I guess I can fix this soon.

Ah.  I actually asked Barak A. Pearlmutter if I could adopt the package
on behalf of the pkg-emacsen team.  Maybe you'd like to help me with the
adoption?

https://anonscm.debian.org/cgit/pkg-emacsen/pkg/yasnippet.git/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845264: RFS: ublock-origin/1.9.16+dfsg-1~bpo8+1

[Sean Whitton]

Package: sponsorship-requests
Severity: normal
Control: block 844003 by -1

Dear mentors,

I am looking for a sponsor for a backport of ublock-origin.

* Package name: ublock-origin
  Version : 1.9.16+dfsg-1~bpo8+1
  Upstream Author : Raymond Hill
* URL : https://github.com/gorhill/uBlock
* License : GPL-3+
  Section : web

Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/u/ublock-origin/ublock-origin_1.9.16+dfsg-1~bpo8+1.dsc

Or from git:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-mozext/ublock-origin.git
cd ublock-origin
git verify-tag debian/1.9.16+dfsg-1_bpo8+1 # please obtain my key from 
keyring.debian.org
git checkout debian/1.9.16+dfsg-1_bpo8+1
gbp buildpackage

Changes since the last upload:

  * Rebuild for jessie-backports (Closes: #844003).
  * Add README.Debian (see discussion in #844003).
  * Update 'debian-branch' in d/gbp.conf for backporting.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

[CCing the bug so there is a public record that you don't consider this
a hijack!]

Dear Alberto,

On Tue, Nov 22, 2016 at 11:19:24AM +0100, Alberto Luaces wrote:
> Yes, I would be glad to help.  I have basically done the same as you,
> merging the latest release and trimming the patches that we had since
> they are of no use now.

Okay, cool.  Do you have push access to the pkg-emacsen git
repositories?  If not, please submit a request to join the pkg-emacsen
team on alioth.

So long as you use `dch` to add changelog entries you can commit freely
to the team repository.  Let's both work on the same copy of the code.

> However, I am struggling with with the installation of the package; I
> though that it would be automatically handled by dh_elpa, but
> unfortunately that is not the case (generating the
> /usr/share/emacs*/site-lisp symbolic link, the configuration of the
> snippets directory, etc).
> 
> I don't want to hinder your progress, so don't hold yourselves if you
> think it is easier done than told!

dh_elpa definitely installs the package and creates the symbolic links.
The only issue is the startup file, 50yasnippet.el.  I'm talking to the
original author of dh_elpa about that (join us in #debian-emacs if you
can).

What do you think about merging yasnippet-snippets into elpa-yasnippet?

I'm wondering whether we should have a separate package, yasnippet-doc,
containing the HTML documentation.  What do you think?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845368: haskell-devscripts: Prevent ghc from reading the package .ghci file when computing os or arch

[Sean Whitton]

control: tag -1 +moreinfo

Dear David,

On Tue, Nov 22, 2016 at 11:47:05AM -0800, David Fox wrote:
> Package: haskell-devscripts
> Version: 0.12-0+seereason1~trusty2

This version does not exist in the Debian archive.  Further, it's behind
the version in Debian unstable.

Please confirm that the patch applies to the version in unstable.  You
can indicate this using the 'found' command.[1]

[1] https://www.debian.org/Bugs/server-control

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#817951: Simple helpers for handling orig tarballs for packages where upstream's git is the canonical source

[Sean Whitton]

Hello Ian,

On Sun, Nov 13, 2016 at 08:48:44AM -0700, Sean Whitton wrote:
> I want a script that just calls git-archive(1) in the right way with a
> minimum amount of thought.  I'm planning to write it and put it in
> ~/bin, but I thought it might be useful for others, so I filed the bug.
> I understand if you think the gbp generation is sufficient.

I've written my script.  Will be testing it over the next few weeks.

https://git.spwhitton.name/?p=dotfiles.git;a=blob;f=bin/git-deborig;hb=HEAD

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845562: tracker.debian.org: Action needed item "new upstream version" should not be high priority

[Sean Whitton]

Package: tracker.debian.org
Severity: minor

Dear maintainers,

When a new upstream version of a package is available, the package
tracker displays a high priority action needed item to package the new
upstream release.  However, we normally don't consider new upstream
releases high priority: they are wishlist-severity bugs.  In particular,
it is certainly significantly more important to fix RC bugs than upload
new upstream versions (unless of course the new upstream version fixes
the RC bug).  So I think the displayed priority of the action needed
item should be lowered.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832941: RFS: 4pane (debian: to exclusive)

[Sean Whitton]

Dear David,

Here's another review, based on your 4pane-debian-dir repo.

Must-fixes
--

1. At least one of the files added by AddExtraM4Files.patch isn't
accounted for in d/copyright.

2. Vcs-* still point to the upstream code, not your 4pane-debian-dir
repo.

3. d/copyright says that only you hold copyright on MyGenericDirCtrl.cpp
and sdk/fswatcher/*, but the file headers have several other people's
names.  They should all be in d/copyright.

4. Your own copyright is not all 2016.  Some files are 2014, and
About.htm says 2007--2016.

5. Alberto Griggio and Otto Wyss also hold copyright on MyTreeCtrl.*

6. config.guess, config.sub, configure, configure.in, Makefile.in and
install-sh are not accounted for in d/copyright.

7. Some bitmaps aren't accounted for in d/copyright.  For example, I'm
guessing you didn't produce bitmaps/libreoffice.png yourself (unless you did?).

8. Further, could you confirm that, for the files in bitmaps/ and the
images in doc/ whose preferred format for modification is not .png, the
.xpm/.svg/whatever source is available?  I see some .xpm/.svg files but
not for every file.  If the preferred format for modification for those
other files is editing the .png then it's fine.

9. Lots of files in .build/ are not accounted for in d/copyright.

10. .build/DONT_README (heh) explains that the Bakefile tool is required
to regenerate the build system.  I.e. the preferred format for
modification of the buildsystem is not by editing Makefile.in, but by
changing some other files and running Bakefile (is Makefile.in the only
file that Bakefile outputs?).

As before, this is a violation of DFSG.  I think you need to package
Bakefile for Debian, unless you can think of a way around this.

11. You need to run dch -r to refresh the changelog timestamp so it is
after the various changes you've made recently.

Command I used to find the copyright issues: `licensecheck --copyright -r .`

Suggestions
---

1. You might raise the debhelper compat to 10, the latest version.  That
means you can drop '--parallel --with autoreconf' which are automatic at
compat 10.

2. At the top of d/rules you define various EXTRA_ env vars.  Could you
explain further why you can't do this "the standard way"?  Would it be
possible to make it work by patching the upstream Makefile?  Generally
speaking, it's better to have a short d/rules and move logic into the
upstream Makefile (otherwise someone trying to understand it has to flip
back and forth between two files).

3. In a previous e-mail I explained why I think it would be clearer to
call the wxWindows license "GPL-2+ or wxWindows-3.1+".  So far as I can
tell you never responded to that -- please consider the points I made.
Unless I'm missing something, it would make d/copyright clearer.

4. You should probably s/4pane/4Pane/ in 4pane.doc-base.

5. Rather than installing 4Pane.desktop twice, you could do something
like this:

override_dh_install:
dh_install
( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications )

On Sun, Nov 20, 2016 at 06:31:33PM +, David Hart wrote:
> Dear Sean,
> 
> >1. Why do you have a folder full of patches, when you are the upstream
> >author of 4Pane?  Have they been applied upstream, but there hasn't been
> >a release of 4Pane recently?
> 
> Yes. They are implementing your previous suggestions. There hasn't been a
> recent 4Pane release and, unless needed for debian packaging reasons, there
> won't be one soon.

A new release is not needed.  Thanks for the explanation.

> >2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian
> >policy permits you too.  Good idea.  The only thing I'm not sure about
> >is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html.
> >It could be misleading, since Debian users expect /usr/share/doc/foo to
> >give them a folder containing a changelog, a Debian changelog etc.  Why
> >not link to /usr/share/doc/4pane?
> 
> IIUC the current situation is correct: the debian changelog etc files are in
> /usr/share/doc/4pane/ as expected, while the symlink from /usr/share/doc/4Pane
> to html/ allows the program to find its F1 help files (which can be accessed
> outside the program using a doc-base reader).
> 
> If this is wrong please tell me.

6. It's definitely not wrong, but it might not be optimal.  What I'm
imagining is the following situation: Debian users expect to find
certain files (changelogs, copyright files) in /usr/share/doc/foo.
Since 4Pane is known as '4Pane', a user might reasonably look in
/usr/share/doc/4Pane.  But then they wouldn't be able to find the
standard files.  For this reason, I think /usr/share/doc/4Pane should be
a link to /usr/share/doc/4pane and 4Pane can be patched to find its help
files there.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#822793: closed by to...@debian.org (Dr. Tobias Quathamer) (Bug#822793: fixed in rclone 1.34-1)

[Sean Whitton]

Thanks for this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

Hello Alberto,

On Tue, Nov 22, 2016 at 07:32:50AM -0700, Sean Whitton wrote:
> dh_elpa definitely installs the package and creates the symbolic links.
> The only issue is the startup file, 50yasnippet.el.  I'm talking to the
> original author of dh_elpa about that (join us in #debian-emacs if you
> can).

This is now resolved in git.

> I'm wondering whether we should have a separate package, yasnippet-doc,
> containing the HTML documentation.  What do you think?

I no longer this this is a good idea -- the installed documentation is
tiny.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#825487: Another situation where this change would help

[Sean Whitton]

Hello,

I observed today that `dpkg -i` can fail to install a new binary package
and its transitional dummy package, whereas `apt-get install ./foo.deb
./bar.deb` succeeds.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#846048: RFS: yasnippet/0.11.0-1 [ITA]

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an ITA of yasnippet.

* Package name: yasnippet
  Version : 0.11.0-1
  Upstream Author : João Távora 
* URL : https://github.com/joaotavora/yasnippet
* License : GPL-3+
  Section : lisp

Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/y/yasnippet/yasnippet_0.11.0-1.dsc

Or from git:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-emacsen/pkg/yasnippet.git
cd yasnippet
git checkout c111fef485242fb85387ffbd503d466bd90c8516
gbp buildpackage

Changes since the last upload:

  [ Sean Whitton ]
  * New upstream release (Closes: #845061).
  * Adopt package on behalf of pkg-emacsen team.
This has been approved by the de facto maintainer, Barak A. Pearlmutter.
- Replace Julián Hernández Gómez with pkg-emacsen team as Maintainer.
- Add myself as an uploader.
- Add myself to d/copyright file for debian/.
- Update copyright years for Barak A. Pearlmutter.
  * Convert package to use dh_elpa (Closes: #671584, #818440).
- Build 'elpa-yasnippet' binary package.
- 'yasnippet' now a transition binary package.
- Rewrite d/rules.
- Add d/elpa-yasnippet.elpa & d/elpa-test control files.
- Replace build dependency on Emacs with build dependency on dh-elpa.
- Add build dependency on yasnippet-snippets for test suite.
- Drop debian/emacsen-*.
- Update doc-base registration.
  * Add 0003-Debian-yas-installed-snippets-dir.patch (Closes: #818699).
  * Add missing build dependency on emacs-goodies-el.
The documentation build process can optionally use htmlize.el.  The
version of htmlize.el present in emacs-goodies-el is currently too old
for this to work, but adding the build dependency now will make this
work as soon as emacs-goodies-el is updated.
  * Bump debhelper compat & dependency to 10.
  * Update homepage field.
  * Add Testsuite: field.
  * Fix typo in package description.
  * Add debian/clean.
  * Bump standards version to 3.9.8 (no changes required).
  * Run wrap-and-sort -abst.

  [ Barak A. Pearlmutter ]
  * Drop 0001-Deal-with-the-invalid-function-quote-error-when-gene.patch
Merged upstream.
  * Refresh 0002-Avoiding-having-git-as-a-building-dependency.patch
  * Add 0001-typos-and-grammar.patch

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#846048: RFS: yasnippet/0.11.0-1 [ITA]

[Sean Whitton]

On Mon, Nov 28, 2016 at 02:22:21PM +, Barak A. Pearlmutter wrote:
> No problem, I'll upload it.
> Updated debian/watch first

Thanks for catching that!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842166: RFS: findent-2.6.0 ITP -- indent / convert Fortran source

[Sean Whitton]

control: severity -1 wishlist
control: tag -1 +moreinfo

Dear Willem,

On Wed, Oct 26, 2016 at 04:52:49PM +0200, Willem Vermin wrote:
> It builds this binary package:
> 
> findent - indent / convert Fortran source

You need to provide us with a Debian source package that you would like
to be uploaded.  See https://mentors.debian.net/intro-maintainers

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#771159: yasnippet: Reports `flet' is an obsolete macro

[Sean Whitton]

control: reopen 771159

On Wed, Nov 30, 2016 at 03:41:21PM -0700, Sean Whitton wrote:
> This is indeed fixed in more recent upstream versions, including the one
> now on its way into Debian unstable.

Whoops, it was #846047 that was fixed.  Sorry for the noise.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

Thanks again for your work on this.  I'm looking forward to seeing the
cleaned-up package in Debian stretch.

Before I reply to your message, let me note a few more things to fix:

1. s/Muse-el/muse-el/ in the changelog

2. You need to re-run `dch -r` so the timestamp is later than your
changes.

3. "Includes changes to debian/control, debian/rules, NEWS"

This is not very informative.  I'm not saying that you have to list
every change, but see how much more informative this is:

- Update Build-Depends; Maintainer; Uploaders [or whatever fields you updated]
- Rewrite d/rules
- Update NEWS

For a sample, see the most recent changelog entry of the yasnippet
package, which I recently converted to use dh_elpa.

4. "Add patch ..."

When you say that you added a patch, it is best to explicitly state the
patch filename so that someone searching the changelog for that patch
name can find it easily.

5. "Add depends on doc-base to register Quickstart.pdf as
muse-quickstart."

Build-Depends?  Binary package dependency?

Are you sure you need this?  doc-base registration uses triggers, so you
don't generally need to depend on it.

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? ;)

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.

8. In the patch header for use_see_not_open.diff, it would be good to
know why you're applying the patch.  What's the advantage of see(1) over
open(1)?

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

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.

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.

12. Your change in the "Priority:" field is not in the changelog.

13. You bumped the standards-version but didn't mention it in the
changelog.  Did you review the upgrading checklist?[1]

14. Consider s/emacs24/emacs25/ in build-depends-indep.

15. Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment
to the control file.

16. muse-el is not a library.  It shouldn't be in section: oldlibs.

17. The deletion of d/emacsen-* is not in the changelog.  Similarly,
d/muse-el.dirs.

18. At dh compat 10, you can drop --parallel from d/rules.

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.

On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote:
> On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote:
> > In the future, when submitting a new bug, please use X-Debbugs-CC: rather
> > than CC: so that the bug gets assigned a number before reaching my
> > inbox.
> 
> Would you pleas

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Fri, Nov 25, 2016 at 09:41:16PM +0900, Kiwamu Okabe wrote:
> On Sun, Nov 20, 2016 at 5:15 AM, Sean Whitton  
> wrote:
> > Thank you for your work to bring this new package to Debian!  As I said,
> > I can't sponsor the upload, but I hope this more detailed review is
> > useful to you.
> 
> Of course, your precisive review is very useful for me. Thanks.

Just a few more things and it will be ready for upload :)

After you make changes, you need to run `dch -r` to update the timestamp
in d/changelog.

> > 1. The line "Only support emacs and xemacs" doesn't make sense (what
> > else would you be supporting?).  What were you trying to say?
> 
> Fixed. It's my simple mistake. I should say "Support emacs and xemacs."

In that case, I think you should just delete that line altogether.
Normally, uploads of new packages have a changelog entry with only a
single line, closing the ITP.

> > 2. There is a Lintian error:
> >
> > E: verilog-mode: info-document-missing-dir-section 
> > usr/share/info/verilog.info.gz
> 
> You are right. I miss it out. It's fixed by
> debian/patches/fix-dircategory.patch.
> The patch is pull-requested to upstream:
> 
> https://github.com/veripool/verilog-mode/pull/13

Good work.  Please add a DEP-3 patch header, including a Forwarded:
field to show that the patch has been forwarded upstream.

> > 3. Some files are not GPL-3+.  For example,
> > tests/auto_delete_whitespace.v.  Please check every file's copyright
> > status and detail in d/copyright.
> 
> The debian/copyright is updated.

The copyright for Makefile is still not correct.

> > 5. You've missed some steps of the Emacs policy.[1]  For example, you
> > are missing a emacsen compat level.  Please check the policy carefully.
> >
> > [1] https://www.debian.org/doc/packaging-manuals/debian-emacs-policy
> 
> I added "verilog-mode.emacsen-compat" file.
> And I think that there are no other violation.

Looks good.

> > 3. You are generating ChangeLog.txt but not installing it.  You can use
> > dh_installchangelogs(1).
> 
> I think it's not useful.

Agreed.  Thank you for confirming.

> > 4. How about installing verilog-lex.el as an example?  See
> > dh_installexamples(1).  Or possibly somewhere else.
> 
> Sorry. I can't understand why it becomes as example,
> because I'm not a expert for both Emacs and Verilog.

It has a function `verilog-lex' which might be useful to someone.

Maybe it would be better to install it with the other *.el files, and
bytecompile it?  I'm not sure what I was thinking when I suggested
installing it as an example.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#847040: evil-el: test suite fails under emacs25

[Sean Whitton]

Source: evil-el
Version: 1.2.12-2
Severity: important
Tags: upstream

Dear maintainer,

evil-el seems to be incompatible with emacs25.  The test suite fails:

Ran 181 tests, 171 results as expected, 10 unexpected (2016-12-04 
18:51:14-0700)

10 unexpected results:
   FAILED  evil-test-insert-repeat-info
   FAILED  evil-test-normal-repeat-info-char-command
   FAILED  evil-test-normal-repeat-info-simple-command
   FAILED  evil-test-repeat
   FAILED  evil-test-repeat-append
   FAILED  evil-test-repeat-append-line
   FAILED  evil-test-repeat-insert
   FAILED  evil-test-repeat-insert-line
   FAILED  evil-test-repeat-open-above
   FAILED  evil-test-repeat-open-below

While this problem does cause an FTBFS, I'm filing a separate bug from
#829299 because that one concerns buildd tty issues rather than
emacs24/emacs25 compatibility.

This will be RC if and when emacs24 is RM'd, which we are hoping to do
soon.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Tue, Dec 06, 2016 at 12:11:46AM +0900, Kiwamu Okabe wrote:
> And also some lintian errors in debian/copyright are fixed. But I can't fix
> following a lintian error. Is it a issue on the side of lintian
> command?

No, it's not Lintian's mistake.

You have:

Files: 0test.el, batch_prof.el, batch_test.el, batch_test.pl

You should have:

Files: 0test.el batch_prof.el batch_test.el batch_test.pl

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#847040: evil-el: test suite fails under emacs25

[Sean Whitton]

[removing upstream from CC since my message is about Debian]

Dear Dmitry,

On Tue, Dec 06, 2016 at 08:28:22AM +0300, Dmitry Bogatov wrote:
> Thank you for report.

Thank you for your reply!

> [Added upstream maintainer into CC: frank-fisc...@shadow-soft.de]
> 
> I just installed emacs25 and now my /usr/bin/emacs points to
> /usr/bin/emacs25-nox, and I can confirm, that `make test' do fail. Dear
> upstream maintainer, can you please take a look?

I tested `hg tip` and reported a bug upstream:
https://bitbucket.org/lyro/evil/issues/731/test-suite-fails-with-emacs-25

> [Back to Debian affairs.]
> 
> Right now it seems impossible to uninstall emacs24 without breaking a
> lot of things:
> 
>   ; sudo apt-get purge emacs24-nox emacs24-lucid emacs24
> [... reflowed a bit ...]
>   The following packages will be REMOVED:
> dash-el* dh-elpa* elpa-aggressive-indent*
> elpa-elisp-slime-nav* elpa-epl* elpa-evil* elpa-evil-leader*
> elpa-evil-paredit* elpa-flycheck* elpa-git-commit*
> elpa-goto-chg* elpa-magit* elpa-magit-popup* elpa-paredit*
> elpa-pkg-info* elpa-undo-tree* elpa-with-editor* emacs*
> emacs24-nox* haskell-mode*
> [...]
>   Do you want to continue? [Y/n] ^C
> 
> But I just switched to emacs25 and everything is fine, including
> evil. So whatever issues test suite discovers, they do not disrupt my
> emacs/evil workflow. So, if we would fail to fix test suite till emacs25
> becomes the only emacs, I would comment-out tests.  Unprincipled -- yes,
> but RM would be much greater problem. At least for me.

We won't remove emacs24 until is no longer has any reverse
dependencies.  The ftp-masters wouldn't allow it, for one thing.

Once I update dh-elpa, all the elpa-* packages you list would be fixed.
We have filed bugs against the others, and might NMU to bump
s/emacs24/emacs25/.

I have not yet updated dh-elpa because of evil-el's test suite, i.e.,
this bug is blocking updating dh-elpa.  If the upstream fix proves to be
very difficult and upstream is unable to provide a fix soon, we have two
options:

1. Update dh-elpa anyway, causing evil-el to FTBFS, and bump this bug to
RC-severity to keep evil-el out of stretch.  Not ideal, but evil-el has
never been in testing anyway thanks to #829299.

2. Update dh-elpa and comment out the failing tests in evil-el.

I don't think we should proceed with option (2) unless we are confident
that elpa-evil works fine for everyday usage under emacs25, and #829299
gets fixed.  (If #829299 is not fixed, option (2) achieves nothing.)

I'd like to ask you to do two things:

- Since you use evil, could you run elpa-evil under emacs25 for the next
  two or three weeks for your regular usage, and report back?

- Could you fix #829299 based on the private e-mails we exchanged a few
  weeks ago, please?

Thanks again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Tue, Dec 06, 2016 at 01:53:25PM +0900, Kiwamu Okabe wrote:
> Should I find a Debian Developer in
> pkg-emacsen-add...@lists.alioth.debian.org to dput the verilog-mode
> package?

Sorry, but I have a few more items...

1. I think you should tweak the copyright for Makefile.  You wrote

Copyright: 2008-2013, Michael McNamara
 2008-2013, Wilson Snyder

but I think the following is more accurate:

Copyright: 2008-2013 Michael McNamara and Wilson Snyder

IANAL but I think there might be a legal distinction between these two,
so it's best to follow what upstream wrote in the file header.

2. You should patch the "New versions" and "Installation" sections out
of the texinfo file, as these could be confusing to Debian users who
already have the package installed and will obtain new versions from
us.  Don't forget a DEP-3 patch header.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Wed, Dec 07, 2016 at 11:01:46AM +0900, Kiwamu Okabe wrote:
> > 2. You should patch the "New versions" and "Installation" sections out
> > of the texinfo file, as these could be confusing to Debian users who
> > already have the package installed and will obtain new versions from
> > us.  Don't forget a DEP-3 patch header.
> 
> Umm... I don't think so.
> I should not install the info file into the verilog-mode package, with your
> advice. Because I believe that Debian source package having big patches
> is a bad manner.
> Already the installation of the info file is removed at the git repo.

I strongly disagree.  We should install documentation with our
packages, so that users can use learn how to use the package without an
active Internet connection.

It is perfectly normal to remove installation and upgrade information
from documentation by means of a large patch.  For example, see these
patches to ocrmypdf and flycheck:

https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/patch-docs-for-Debian.patch
https://browse.dgit.debian.org/ocrmypdf.git/tree/debian/patches/path-to-docs-for-Debian.patch
https://browse.dgit.debian.org/flycheck.git/tree/debian/patches/patch-README-for-Debian.patch

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Wed, Dec 07, 2016 at 12:45:08PM +0900, Kiwamu Okabe wrote:
> Could you review it?

Looks good, but you need "Forwarded: not-needed" not "Forwarded: no".

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850630: elpa-company: Fails to upgrade from 0.8.12-4 when xemacs21 installed

[Sean Whitton]

Package: elpa-company
Version: 0.8.12-5
Severity: important
Tags: patch

Dear maintainer,

If xemacs21 is installed, apt cannot upgrade from elpa-company 0.8.12-4
to 0.8.12-5.

Steps to reproduce in a minimal sid chroot:

apt-get install xemacs21
apt-get install elpa-company=0.8.12-4
apt-get install elpa-company=0.8.12-5

Sample output:

Preparing to unpack .../elpa-company_0.8.12-5_all.deb ...
Remove elpa-company for xemacs21
remove/company-0.8.12: Skipping unsupported emacs
dh-elpa: purging flavor specific files for xemacs21
find: '/usr/share/xemacs21/site-lisp/elpa/company-0.8.12': No such file or 
directory
ERROR: remove script from elpa-company package failed
dpkg: warning: subprocess old pre-removal script returned error exit status 
1
dpkg: trying script from the new package instead ...
Remove elpa-company for xemacs21
remove/company-0.8.12: Skipping unsupported emacs
dh-elpa: purging flavor specific files for xemacs21
find: '/usr/share/xemacs21/site-lisp/elpa/company-0.8.12': No such file or 
directory
ERROR: remove script from elpa-company package failed
dpkg: error processing archive 
/var/cache/apt/archives/elpa-company_0.8.12-5_all.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1

The attached patch fixes the problem (also available as a branch
'upgrade-fix' in the team git repository).  Please consider uploading it
before 0.8.12-5 migrates to stretch.

Thanks to 'cruncher' on #debian-next for help with this fix.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elpa-company depends on:
ii  emacs  46.1
ii  emacs24 [emacsen]  24.5+1-7.1
ii  emacs25 [emacsen]  25.1+1-3
ii  emacsen-common 2.0.8

elpa-company recommends no packages.

elpa-company suggests no packages.

-- no debconf information

-- 
Sean Whitton
From d379d65b76d975b91a30f5e8905c8cabdfe96bc9 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 8 Jan 2017 10:21:21 -0700
Subject: [PATCH] add d/elpa-company.prerm to fix upgrade from -4

---
 debian/changelog  |  8 
 debian/elpa-company.prerm | 16 
 2 files changed, 24 insertions(+)
 create mode 100755 debian/elpa-company.prerm

diff --git a/debian/changelog b/debian/changelog
index 83b346b..9eabae8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+company-mode (0.8.12-6) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Add d/elpa-company.prerm to fix upgrades from 0.8.12-4 and below.
+Thanks to 'cruncher' on #debian-next for help preparing the fix.
+
+ -- Sean Whitton   Sun, 08 Jan 2017 10:20:35 -0700
+
 company-mode (0.8.12-5) unstable; urgency=medium
 
   * Rebuild with dh-elpa 1.5. Fix for removal in the presence of xemacs (fix
diff --git a/debian/elpa-company.prerm b/debian/elpa-company.prerm
new file mode 100755
index 000..905d734
--- /dev/null
+++ b/debian/elpa-company.prerm
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+set -e
+
+# fix upgrade from 0.8.12-5 and below, which can fail if xemacs21 is
+# also installed.  We manually upgrade the emacsen-common remove
+# script so that it won't exit non-zero, which blocks the upgrade
+if [ "$1" = "failed-upgrade" ] && dpkg --compare-versions "$2" lt 0.8.12-5; then
+broken_remove_script="/usr/lib/emacsen-common/packages/remove/elpa-company"
+sed --quiet -i "$broken_remove_script" \
+-e 's/find ${elc_dir} -type l -delete/[ -d ${elc_dir} ] && find ${elc_dir} -type l -delete/'
+sed --quiet -i "$broken_remove_script" \
+-e 's/emacs23)/emacs2[0123]*)/'
+fi
+
+#DEBHELPER#
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#846989: mh-e: diff for NMU version 8.5-2.1

[Sean Whitton]

Control: tags 846989 + patch
Control: tags 846989 + pending

Dear maintainer,

I've prepared an NMU for mh-e (versioned as 8.5-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sean Whitton
diff -Nru mh-e-8.5/debian/changelog mh-e-8.5/debian/changelog
--- mh-e-8.5/debian/changelog	2013-06-01 09:01:05.0 -0700
+++ mh-e-8.5/debian/changelog	2017-01-08 12:03:03.0 -0700
@@ -1,3 +1,13 @@
+mh-e (8.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Updates for emacs25 (Closes: #846989)
+- Update build-dep: emacs24 => emacs25-nox | emacs25 | emacs24
+- Update depends: emacs24 | emacs | xemacs21
+  => emacs25 | emacs24 | emacs | xemacs21
+
+ -- Sean Whitton   Sun, 08 Jan 2017 12:03:02 -0700
+
 mh-e (8.5-2) unstable; urgency=low
 
   * Bug fix: "postinst script blocks if some Recommends are not yet
diff -Nru mh-e-8.5/debian/control mh-e-8.5/debian/control
--- mh-e-8.5/debian/control	2013-06-01 09:00:35.0 -0700
+++ mh-e-8.5/debian/control	2017-01-08 11:58:39.0 -0700
@@ -2,13 +2,13 @@
 Section: mail
 Priority: extra
 Maintainer: Peter S Galbraith 
-Build-Depends: debhelper (>> 4.0.0), texinfo, emacs24, texlive-latex-base, texlive-generic-recommended
+Build-Depends: debhelper (>> 4.0.0), texinfo, emacs25-nox | emacs25 | emacs24, texlive-latex-base, texlive-generic-recommended
 Standards-Version: 3.9.2
 Homepage: http://mh-e.sourceforge.net/
 
 Package: mh-e
 Architecture: all
-Depends: emacs24 | emacs| xemacs21, nmh | mailutils-mh, dpkg (>= 1.15.4) | install-info, ${misc:Depends}
+Depends: emacs25 | emacs24 | emacs | xemacs21, nmh | mailutils-mh, dpkg (>= 1.15.4) | install-info, ${misc:Depends}
 Recommends: compface
 Suggests: mailcrypt, swish++, wget, imagemagick, picon-domains, w3m-el
 Description: Emacs interface to the MH mail system


signature.asc
Description: PGP signature

Bug#850630: [Pkg-emacsen-addons] Bug#850630: elpa-company: Fails to upgrade from 0.8.12-4 when xemacs21 installed

[Sean Whitton]

Thank you for your review!

On Sun, Jan 08, 2017 at 02:23:42PM -0400, David Bremner wrote:
> I think you mean -4 and below

Yes.

> > +# also installed.  We manually upgrade the emacsen-common remove
> > +# script so that it won't exit non-zero, which blocks the upgrade
> 
> > +if [ "$1" = "failed-upgrade" ] && dpkg --compare-versions "$2" lt 
> > 0.8.12-5; then
> > +
> > broken_remove_script="/usr/lib/emacsen-common/packages/remove/elpa-company"
> > +sed --quiet -i "$broken_remove_script" \
> > +-e 's/find ${elc_dir} -type l -delete/[ -d ${elc_dir} ] && find 
> > ${elc_dir} -type l -delete/'
> 
> this is OK, but it might be simpler to add the 'exit 0' that dh-elpa 1.6
> added to the xemacs case.

Okay.

> > + sed --quiet -i "$broken_remove_script" \ + -e
> > 's/emacs23)/emacs2[0123]*)/'
> 
> this seems unrelated to the problem in the comments. Did you mean to say
> something like "xemacs21 or gnu emacs version 20-22"

It's unrelated, but I thought it would be best to update the
emacsen-common remove script completely to avoid any other upgrade
issues that might arise.  Would you prefer to keep the fix more minimal?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850630: [Pkg-emacsen-addons] Bug#850630: elpa-company: Fails to upgrade from 0.8.12-4 when xemacs21 installed

[Sean Whitton]

On Sun, Jan 08, 2017 at 04:25:07PM -0400, David Bremner wrote:
> I agree we should fix both upgrade problems. But we should also document
> what we are actually fixing

Agreed.  I've pushed two more commits to the upgrade-fix branch.

If you approve, and have nothing else to add, I can perform a team upload.

-- 
Sean Whitton
From dc23d9be6631d1dcdbe909dde8402bf0faf8f640 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 8 Jan 2017 14:59:24 -0700
Subject: [PATCH 2/3] simplify fix for xemacs21

---
 debian/elpa-company.prerm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/elpa-company.prerm b/debian/elpa-company.prerm
index 905d734..6595b40 100755
--- a/debian/elpa-company.prerm
+++ b/debian/elpa-company.prerm
@@ -8,7 +8,7 @@ set -e
 if [ "$1" = "failed-upgrade" ] && dpkg --compare-versions "$2" lt 0.8.12-5; then
 broken_remove_script="/usr/lib/emacsen-common/packages/remove/elpa-company"
 sed --quiet -i "$broken_remove_script" \
--e 's/find ${elc_dir} -type l -delete/[ -d ${elc_dir} ] && find ${elc_dir} -type l -delete/'
+-e '/Skipping unsupported emacs ${FLAVOUR}/a \   exit 0'
 sed --quiet -i "$broken_remove_script" \
 -e 's/emacs23)/emacs2[0123]*)/'
 fi
-- 
2.11.0

From a7561341a6e9ed5b62ed46a7e39f6de6133cc4a9 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 8 Jan 2017 14:59:32 -0700
Subject: [PATCH 3/3] properly document prerm script

---
 debian/elpa-company.prerm | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/elpa-company.prerm b/debian/elpa-company.prerm
index 6595b40..6d4dc33 100755
--- a/debian/elpa-company.prerm
+++ b/debian/elpa-company.prerm
@@ -2,13 +2,19 @@
 
 set -e
 
-# fix upgrade from 0.8.12-5 and below, which can fail if xemacs21 is
-# also installed.  We manually upgrade the emacsen-common remove
-# script so that it won't exit non-zero, which blocks the upgrade
+# Pre-emptively upgrade emacsen-common remove script to deal with several
+# possible issues when upgrading from version 0.8.12-4 or older.  These can
+# cause the emacsen-common remove script to exit non-zero, breaking the package
+# upgrade
 if [ "$1" = "failed-upgrade" ] && dpkg --compare-versions "$2" lt 0.8.12-5; then
 broken_remove_script="/usr/lib/emacsen-common/packages/remove/elpa-company"
+
+# (1) exit cleanly for xemacs21 -- without this, the call to find(1) can
+# exit non-zero
 sed --quiet -i "$broken_remove_script" \
 -e '/Skipping unsupported emacs ${FLAVOUR}/a \   exit 0'
+
+# (2) exit cleanly for yet older unsupported Emacsen that might be installed
 sed --quiet -i "$broken_remove_script" \
 -e 's/emacs23)/emacs2[0123]*)/'
 fi
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sat, Dec 31, 2016 at 02:19:27PM +, Sean Whitton wrote:
> 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.

Ping?

We're running out of time!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849318: RFS: eoconv/1.5-1

[Sean Whitton]

Dear Andreas,

On Sun, Dec 25, 2016 at 02:42:42PM +0100, Andreas Henriksson wrote:
> Your changes looks fine and I can sponsor them for you if you wish
> but have some questions for you below first.

This RFS has been waiting on your response for a few weeks now, and
winter is coming.  Are you prepared to upload, or can someone else take
this RFS off your hands?

In the future, please consider taking ownership of RFS bugs that you
intend to shepherd through to upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Sean Whitton]

control: tag -1 +moreinfo

Dear Carl,

On Sun, Jan 08, 2017 at 11:38:27PM +1100, Carl Suster wrote:
> I am looking for a sponsor for my package "flask-login"

Thank you for your work to revitalise the package.

> To be clear I am not targeting stretch even if that's somehow possible at this
> stage.

Can a potential sponsor work out of your Vcs-Git repository?

I notice that the changelog suite in your repository is unstable, but in
the RFS you indicate that you want this package to be uploaded to
experimental.  Which is right?

> I have dropped the Python 2 module binary package since there were no
> rdeps and my understanding is that going forward we don't want to keep
> around unnecessary Python 2 packages.

I'm not on the python modules team -- could you how you got this
understanding?  I'm not doubting your knowledge, but I'd like to
confirm.

>   * Relicense debian/* as Expat to match upstream.

Only Tonnerre Lombard can relicense Tonnerre Lombard's work.  Please
revert this change.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850664: RFS: python-pynzb/0.1.0-3

[Sean Whitton]

control: tag -1 +moreinfo

Dear Carl,

On Mon, Jan 09, 2017 at 12:56:51PM +1100, Carl Suster wrote:
> I am looking for a sponsor for my package "python-pynzb"

Thank you for your interest!

>  The Python 2 module can still be built fine, but I removed it since
> there were no rdeps.

As in my reponse to your other RFS, I'd like to confirm that this is
DPMT policy.

> Changes since the last upload:
>
>   * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
> Tests pass for Python 2 with only this change.

Your grammar is misleading.  ITYM "Tests pass for Python 2 only with
this change."

>   * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to
> run the tests.

It would be clearer to split this into two changlog entries, i.e.

* Move lxml to Suggests [from ??].
* Add build-dep on lxml to run the tests.

>   * For Python 3, decode strings -> bytes as utf-8 for lxml.

How did you make this change?  With a patch to the upstream code?
Please explain.

>   * Fix watch file (although the last release was some time ago).

Please consider dropping the parathetical remark.  It's not really
appropriate for a packaging changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

Package: dgit
Version: 3.0
Severity: normal

Thank you for dgit 3.0!  Unfortunately:

hephaestus ~/rfs/mytop % dgit import-dsc ../mytop_1.9.1-4.dsc rfs
gpgv: Signature made Mon 09 Jan 2017 04:22:08 PM MST
gpgv:using RSA key 03B346A87E36048870E56E9C2AD2A004BFB21FE1
gpgv: Can't check signature: No public key
dgit: warning: failed to verify signature on ../mytop_1.9.1-4.dsc
Dgit metadata in .dsc: NO git hash
using existing mytop_1.9.1.orig.tar.gz
using existing mytop_1.9.1-4.debian.tar.xz
gpgv: Signature made Mon 09 Jan 2017 04:22:08 PM MST
gpgv:using RSA key 03B346A87E36048870E56E9C2AD2A004BFB21FE1
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./mytop.dsc
dpkg-source: info: extracting mytop in mytop-1.9.1
dpkg-source: info: unpacking mytop_1.9.1.orig.tar.gz
dpkg-source: info: unpacking mytop_1.9.1-4.debian.tar.xz
Use of uninitialized value $isuite in concatenation (.) or string at 
/usr/bin/dgit line 703.

There did not look to be any interesting output with -.

I attach the .dsc to this e-mail.  The repository was a fresh `dgit
clone`.  To help you repro, I will perform the upload without dgit.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dgit depends on:
ii  apt   1.4~beta2
ii  ca-certificates   20161102
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.16.14
ii  dpkg-dev  1.18.10
ii  dput-ng [dput]1.11
ii  git [git-core]1:2.11.0-1
ii  git-buildpackage  0.8.7
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc4-1

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-5

Versions of packages dgit suggests:
ii  sbuild  0.72.0-2

-- no debconf information

-- 
Sean Whitton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 3.0 (quilt)
Source: mytop
Binary: mytop
Architecture: all
Version: 1.9.1-4
Maintainer: Werner Detter 
Homepage: http://www.mysqlfanboy.com/mytop-3/
Standards-Version: 3.9.8
Build-Depends: debhelper (>= 10)
Package-List:
 mytop deb utils optional arch=all
Checksums-Sha1:
 2f245459c1f465b15f0a7fe571bd5cb559c0f02e 22095 mytop_1.9.1.orig.tar.gz
 69ad171776e44d3f413d281c75bb6da4fbbbe518 10272 mytop_1.9.1-4.debian.tar.xz
Checksums-Sha256:
 179d79459d0013ab9cea2040a41c49a79822162d6e64a7a85f84cdc44828145e 22095 
mytop_1.9.1.orig.tar.gz
 6eb177ebbf68e79b30089d635a9eab1c7915f35ed930a2d08550c1876ae1146b 10272 
mytop_1.9.1-4.debian.tar.xz
Files:
 9c9c2eee657a1ec98b5456f6ac4e0447 22095 mytop_1.9.1.orig.tar.gz
 a8a8513dedddc566694ac5874a885f53 10272 mytop_1.9.1-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEA7NGqH42BIhw5W6cKtKgBL+yH+EFAlh0GyAACgkQKtKgBL+y
H+ETkwf+NInGaNuLGyq9dk86k5elvla2ew6xc+1YLGrmnXs+OAh+nkPkH1gNPd/x
MDnsuoy2rmgyMGkX0QqAqBjqXtEND4TZxgH/nvWCsTEUI5oMkSNYtgHj70ny9iUA
Py7xFYCSYmPOyStS6Ii0FXrtw6v1QXoQ/HjNf4tNYhDqS3XLjxJj9SMCgloSNKpZ
nq8rziaO1aDmInPTHM7e5XctM1qYtCY2TORgjhCCt1sMOPfE5W0zLSGpMTzkbpmB
HT3oT48muKV02eKQZxV4+wUVN23spJUDwqUrNUFtU8o8Bo+2d6orM82YXrRXnaBi
aLL22Qv18XFVFbPNyT0PpE4pZ1fpDw==
=TJRd
-END PGP SIGNATURE-


mytop_1.9.1-4.debian.tar.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#709932: Lintian's --fail-on-warnings

[Sean Whitton]

Dear Niels,

As part of your fix for #709932, do you intend to reintroduce the option
to have Lintian exit non-zero when any warning tags are emitted, by some
means other than the old --fail-on-warnings?

I configure sbuild to pass --fail-on-warnings to Lintian, so I can see
problems clearly in sbuild's final output at the end of its run.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

On Mon, Jan 09, 2017 at 08:50:48PM -0700, Sean Whitton wrote:
> I attach the .dsc to this e-mail.  The repository was a fresh `dgit
> clone`.  To help you repro, I will perform the upload without dgit.

Of course this won't help you repro at all.  Sorry.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

On Mon, Jan 09, 2017 at 08:50:48PM -0700, Sean Whitton wrote:
> I attach the .dsc to this e-mail.  The repository was a fresh `dgit
> clone`.  To help you repro, I will perform the upload without dgit.

Of course this won't help you repro at all.  Sorry.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850849: ITP: xml-rpc-el -- Emacs Lisp XML-RPC client

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: xml-rpc-el
  Version : 1.6.12
  Upstream Author : Mark A. Hershberger 
* URL : http://github.com/hexmode/xml-rpc-el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : Emacs Lisp XML-RPC client

This is an XML-RPC client library for Emacs Lisp, capable of both
synchronous and asynchronous method calls.

I am packaging this as a dependency of debpaste-el.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850851: ITP: debpaste-el -- paste.debian.net client for Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
Control: block -1 by 850849

* Package name: debpaste-el
  Version : 0.1.5
  Upstream Author : Alex Kost 
* URL : http://github.com/alezost/debpaste.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : paste.debian.net client for Emacs

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#419510: elserv's xml-rpc.el blocks xml-rpc.el installed with dh_elpa

[Sean Whitton]

control: merge -1 552316
control: block 850849 by -1

Dear maintainer,

I intend to package the latest release of xml-rpc.el in its own source
package.  This is needed as a dependency for debpaste.el, which I also
intend to package.  At present, elserv's outdated xml-rpc.el takes
precedence over the one installed by my package.

I tried to test elserv with the new xml-rpc.el, but I couldn't find any
instructions in English.  Even with the old xml-rpc.el, `C-u M-x
elserv-demo-start RET 8080 RET` doesn't start a server.

Is this package completely broken, or am I missing something?

Thanks in advance for any help you can provide.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850757: closed by Sean Whitton (Re: Bug#850757: RFS: mytop/1.9.1-4)

[Sean Whitton]

Hello Werner,

On Tue, Jan 10, 2017 at 08:57:21AM +0100, Werner Detter wrote:
> > (1) Have you considered keeping this packaging in git?
> It's already in a private GIT repo.

I'd encourage you to make the git repo public, as then sponsors can work
out of that, rather than dealing with raw source packages.

> > (2) Please be sure to forward your new patch upstream.
> Unforunately Upstream is non responsive and non active.
> But I'll keep trying.

Thank you for your efforts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848722: Processed: dash-el: diff for NMU version 2.13.0-1.1

[Sean Whitton]

Dear Hajime,

On Tue, Jan 10, 2017 at 11:39:32PM +0900, Hajime MIZUNO wrote:
> Sorry for my late reply. Thanks for tha patch.
> I uploaded the package below.
> 
> https://mentors.debian.net/package/dash-el

Thank you for your reply.

Just to confirm, would you like me to sponsor the package on mentors?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849318: RFS: eoconv/1.5-1

[Sean Whitton]

Dear Andreas,

On Tue, Jan 10, 2017 at 01:21:36PM +0100, Andreas Henriksson wrote:
> I did not take ownership exactly because I don't intend to shepherd
> anything. Any involvement from my side is strictly "take it or leave
> it". I don't intend to owe anyone anything because I volunteered
> to review something once. My time is already too limited.

Thank you for your prompt reply, which helps keep the RFS queue moving.

I guess that I misinterpreted your remark "Your changes look fine and I
can sponsor them for you" as indicating you wanted to be more involved
in this particular RFS.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850789: Patch upload not showing up in deferred queue

[Sean Whitton]

Dear Taylor,

On Tue, Jan 10, 2017 at 05:37:33PM -0600, Taylor Kline wrote:
> I uploaded a patch for Python3 about ~15 hours ago, but it's not
> showing up on https://ftp-master.debian.org/deferred.html

It's because you're not a Debian Developer.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Hello Carl,

On Tue, Jan 10, 2017 at 03:29:47PM +1100, Carl Suster wrote:
> > Can a potential sponsor work out of your Vcs-Git repository?
> 
> The Python modules team has a standard location for git repositories on
> alioth so that's where I've kept it. Commit access is automatic for all DDs
> and by request for anyone else. You just have to abide by the policy
> (https://python-modules.alioth.debian.org/policy.html) which amounts to "use
> a git-dpm workflow unless there's a good reason not to".

Okay.  I wasn't planning to make any commits (you're the sponsee), but
I prefer to review a git tree than toss source packages around.

I found some remaining issues:

- The package does not build against sid.  See attached log.

- Updates to d/clean not mentioned in changelog.

- Lots of changes to the build-deps not mentioned in changelog.

- The new 0002 patch is not in the changelog.

- doc-base registration not in changelog

- Installation of README.md not in changelog

- Edits to d/source/options

- It's odd for the -doc package to recommend the main package.  See the
  description of Recommends: in Debian policy -- the relationship is
  quite strong, but someone might want to read the docs on their dev
  machine and use the library on some container/server.

- Could you explain why you have three "override_dh_sphinxdoc"?
  Possibly you're using some Makefile syntax I'm not familiar with.

> > I notice that the changelog suite in your repository is unstable,
> > but in the RFS you indicate that you want this package to be
> > uploaded to experimental.  Which is right?
> 
> I initially chose experimental because I didn't want to interfere with the
> stretch freeze, but I was since told that it was fine to upload to unstable
> since the migration to testing is handled differently during the freeze. I
> only want to upload to experimental if it's necessary because of the freeze
> (I'm not targeting stretch), otherwise unstable is preferable.

Indeed, unstable should be fine.

> >> I have dropped the Python 2 module binary package since there
> >> were no rdeps and my understanding is that going forward we
> >> don't want to keep around unnecessary Python 2 packages.
> >
> > I'm not on the python modules team -- could you how you got this
> > understanding?  I'm not doubting your knowledge, but I'd like to
> > confirm.
> 
> From the lintian tag new-package-should-not-package-python2-module:
> 
>   This package appears to be the first packaging of a new upstream
>   software package but it appears to package a module for Python 2.
> 
>   The 2.x series of Python is due for deprecation and will not be
>   maintained past 2020 so it is recommended that Python 2 modules
>   are not packaged unless necessary.
> 
>   This warning can be ignored if the package is not intended for
>   Debian or if it is a split of an existing Debian package.
> 
>   Severity: wishlist, Certainty: certain
> 
>   Check: scripts, Type: binary
> 
> This is not a new package obviously, but since the Python 2 module has no
> rdeps I figured that dropping it was in line with the above goal. It's no
> problem to reinstate it though.

Thanks for the info.  I'm happy to drop the python2 lib -- it can always
be added again if needed as an rdep.

> >>   * Relicense debian/* as Expat to match upstream.
> >
> > Only Tonnerre Lombard can relicense Tonnerre Lombard's work.
> > Please revert this change.
> 
> I understand, but the reason I felt I could do this was because I've
> overwritten pretty much every line under debian/ apart from the old
> changelog entry and the upstream license text. Anyway I've reverted the
> copyright to GPL-2+ in a new upload to mentors & git.

The problem was that you still listed his name in the stanza for
"debian/*".  Thanks for reverting it.

If you're able to address the issues I've raised in this message,
please remove the moreinfo tag in this bug, and don't forget to
re-run `dch -r` to refresh the changelog timestamp.

-- 
Sean Whitton
sbuild (Debian sbuild) 0.72.0 (25 Oct 2016) on iris.silentflame.com

+==+
| flask-login 0.4.0-1 (amd64)  Wed, 11 Jan 2017 00:44:23 + |
+==+

Package: flask-login
Version: 0.4.0-1
Source Version: 0.4.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-77e76

Bug#850664: RFS: python-pynzb/0.1.0-3

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Dear Carl,

Before we go any further with this one, I regret to inform you that it
fails to build.  See the attached log.

-- 
Sean Whitton
sbuild (Debian sbuild) 0.72.0 (25 Oct 2016) on iris.silentflame.com

+==+
| python-pynzb 0.1.0-3 (amd64) Wed, 11 Jan 2017 01:00:58 + |
+==+

Package: python-pynzb
Version: 0.1.0-3
Source Version: 0.1.0-3
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-efbc3a24-d5b7-4537-a747-cc3595ce7740'
 with '<>'

+--+
| Update chroot|
+--+

Get:1 http://mirror.hmc.edu/debian unstable InRelease [223 kB]
Get:2 http://mirror.hmc.edu/debian unstable/main Sources.diff/Index [27.9 kB]
Get:3 http://mirror.hmc.edu/debian unstable/main amd64 Packages.diff/Index 
[27.9 kB]
Get:4 http://mirror.hmc.edu/debian unstable/main Sources 
2017-01-10-2030.24.pdiff [21.8 kB]
Get:4 http://mirror.hmc.edu/debian unstable/main Sources 
2017-01-10-2030.24.pdiff [21.8 kB]
Get:5 http://mirror.hmc.edu/debian unstable/main amd64 Packages 
2017-01-10-2030.24.pdiff [23.9 kB]
Get:5 http://mirror.hmc.edu/debian unstable/main amd64 Packages 
2017-01-10-2030.24.pdiff [23.9 kB]
Fetched 325 kB in 2s (153 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/spwhitton/rfs/python-pynzb_0.1.0-3.dsc exists in /home/spwhitton/rfs; 
copying to chroot
I: NOTICE: Log filtering will replace 
'build/python-pynzb-fc1na8/python-pynzb-0.1.0' with '<>'
I: NOTICE: Log filtering will replace 'build/python-pynzb-fc1na8' with 
'<>'

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 
'/<>/resolver-qajMmw/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
Ign:1 copy:/<>/resolver-qajMmw/apt_archive ./ InRelease
Get:2 copy:/<>/resolver-qajMmw/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/resolver-qajMmw/apt_archive ./ Release.gpg
Get:4 copy:/<>/resolver-qajMmw/apt_archive ./ Sources [349 B]
Get:5 copy:/<>/resolver-qajMmw/apt_archive ./ Packages [434 B]
Fetched 1740 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install core build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-core-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 786 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 copy:/<>/resolver-qajMmw/apt_archive ./ 
sbuild-build-depends-core-dummy 0.invalid.0 [786 B]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 786 B in 0s (0 B/s)
Selecting previously unselected package sbuild-build-depends-core-dummy.
(Reading database ... 11455 files and directories currently installed.)
Preparing to unpack .../sbuild-build-depends-core-dummy_0.invalid.0_amd64.deb 
...
Unpacking sbuild-build-depends-core-dummy (0.invalid.0) ...
Setting up sbuild-build-depends-core-dummy (0.invalid.0) ...

+--+
| Check architectures  |
+--+

Arch check ok (a

Bug#825487: [Piuparts-devel] Bug#825487: Bug#825487: Patch

[Sean Whitton]

Hello Holger,

On Wed, Jan 11, 2017 at 12:40:49AM +, Holger Levsen wrote:
> I've finally applied your patch to git and deployed on piuparts.d.o.
> Thanks for your work on this and your patience!

Thank you for your review!

> In May 2016 you said that this would prevent elpa-ebib from being
> tested, though https://piuparts.debian.org/sid/source/e/ebib.html
> looks good today already, from before applying this patch. Do you
> understand why?

Indeed, I noticed this too.  Unfortunately, I don't know why the various
elpa-* packages that were failing started passing.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850953: dgit-maint-merge(7): Use git-deborig(1)

[Sean Whitton]

Package: dgit
Version: 3.1
Severity: minor
Tags: patch

`git deborig` has made its way into a release of devscripts, which
permits various simplifications to dgit-maint-merge(7).

Thanks.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dgit depends on:
ii  apt   1.4~beta2
ii  ca-certificates   20161102
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.17.0
ii  dpkg-dev  1.18.10
ii  dput-ng [dput]1.11
ii  git [git-core]1:2.11.0-1
ii  git-buildpackage  0.8.7
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc4-1

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-5

Versions of packages dgit suggests:
ii  sbuild  0.72.0-2

-- no debconf information

-- 
Sean Whitton
From 4270f64a2f2def463b1df431ae8333f0f4fef097 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Wed, 11 Jan 2017 08:31:54 -0700
Subject: [PATCH] dgit-maint-merge(7): Use git-deborig(1)

Signed-off-by: Sean Whitton 
---
 dgit-maint-merge.7.pod | 28 +---
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 245be4c..0d8b2da 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -34,20 +34,6 @@ that upstream makes available for download.
 
 =back
 
-=head1 GIT CONFIGURATION
-
-Add the following to your ~/.gitconfig to teach git-archive(1) how to
-compress orig tarballs:
-
-=over 4
-
-[tar "tar.xz"]
-	command = xz -c
-[tar "tar.gz"]
-	command = gzip -c
-
-=back
-
 =head1 INITIAL DEBIANISATION
 
 This section explains how to start using this workflow with a new
@@ -94,16 +80,15 @@ unless you also happen to be involved in upstream development.  We
 work with upstream tags rather than any branches, except when
 forwarding patches (see FORWARDING PATCHES UPSTREAM, below).
 
-Finally, you need an orig tarball.  Generate one with git-archive(1):
+Finally, you need an orig tarball:
 
 =over 4
 
-% git archive -o ../foo_1.2.2.orig.tar.xz 1.2.2
+% git deborig
 
 =back
 
-If you are using the version 1.0 source package format, replace 'xz'
-with 'gz'.
+See git-deborig(1) if this fails.
 
 This tarball is ephemeral and easily regenerated, so we don't commit
 it anywhere (e.g. with tools like pristine-tar(1)).
@@ -121,7 +106,7 @@ A convenient way to perform this check is to import the tarball as
 described in the following section, using a different value for
 'upstream-tag', and then use git-diff(1) to compare the imported
 tarball to the release tag.  If they are the same, you can use
-upstream's tarball instead of running git-archive(1).
+upstream's tarball instead of running git-deborig(1).
 
 =back
 
@@ -313,18 +298,15 @@ Once you're satisfied with what will be merged, update your package:
 
 =over 4
 
-% git archive -o ../foo_1.2.3.orig.tar.xz 1.2.3
 % git merge 1.2.3
 % dch -v1.2.3-1 New upstream release.
 % git add debian/changelog && git commit -m changelog
+% git deborig
 
 =back
 
 and you are ready to try a build.
 
-Again, if you are using the version 1.0 source package format, replace
-'xz' with 'gz'.
-
 =head2 When upstream releases only tarballs
 
 You will need the I from "When upstream releases only
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#850664: RFS: python-pynzb/0.1.0-3

[Sean Whitton]

control: tag -1 +moreinfo

Hello Carl,

I think you forgot to `git push` :)

Also, it would be good if you could use the Forwarded: header to
indicate whether your patches have been sent upstream or not.  This is
especially useful in team-maintained packages.  If you add this now,
don't forget `dch -r` and `git push` ;)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851071: debhelper: dh_auto_test now run twice, once under fakeroot

[Sean Whitton]

Package: debhelper
Version: 10.2.3
Severity: important
Control: block 851041 by -1
Control: fixed -1 10.2.2
Control: affects -1 dh-elpa

Dear maintainer,

dh-elpa's dh sequencer file does this:

insert_after("dh_auto_test", "dh_elpa_test");
remove_command("dh_auto_test");

At compat 10 and with debhelper 10.2.2, this caused dh_elpa_test to be
executed once, during the `dh build` sequence.

However, with debhelper 10.2.3, there is an additional call to
dh_elpa_test during the `dh binary` sequence.  Upstream test suites are
often unprepared to deal with fakeroot, and at least one package using
dh-elpa is FTBFSing as a result.

Is there a good reason why package test suites are now run under
fakeroot?  More generally, is there some reason why they are now run
twice?  When designing dh_elpa_test, we chose to require compat 10
precisely to avoid any test suites being run under fakeroot, because we
already knew that at least one of our packages couldn't handle it.  So
this seems like a regression to the behaviour we observed at compat 9.

Thank you for your attention!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.27.51.20161212-1
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.028-1
ii  dpkg 1.18.10
ii  dpkg-dev 1.18.10
ii  file 1:5.29-1
ii  libdpkg-perl 1.18.10
ii  man-db   2.7.5-2
ii  perl 5.24.1~rc4-1
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850607: Re: Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Sean Whitton]

On Thu, Jan 12, 2017 at 12:48:18PM +1100, Carl Suster wrote:
> Ok I added these headers in git under a new unreleased changelog entry so
> they'll be picked up next time there's a release.

Great work :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851333: ITP: git-annex-el -- Emacs integration for git-annex

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: git-annex-el
  Version : 1.0+git20160215.e61ef24
  Upstream Author : John Wiegley 
* URL : https://github.com/jwiegley/git-annex-el/
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : Emacs integration for git-annex

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851334: ITP: magit-annex -- git-annex subcommands for magit

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: magit-annex
  Version : 1.3.0
  Upstream Author : Kyle Meyer , Rémi Vanicat 

* URL : https://github.com/magit/magit-annex
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : git-annex subcommands for magit

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sat, Jan 14, 2017 at 09:04:28PM -0700, Nicholas D Steeves wrote:
> I think it's finally ready.

I found some more errors in the copyright file.  Rather than go back and
forth once again, I fixed them in our team git repository.  I set the
changelog back to UNRELEASED: if you are okay with the changes, please
`dch -r`, commit and push, and I will upload.

> > 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> > reflected in d/copyright.
> 
> I broke these out into individual stanzas, because I'm short on time
> right now and wasn't able to find canonical documentation quickly
> enough.  Comma separated or
> Files: file1
>file2
> 
> both seem like likely possibilities.  Would it be a nuisance to the
> maint-guide maintainers if I filed a bug requesting some guidelines on
> how to group things?  Is that the most appropriate package to file a
> bug against for this issue?

You couldn't find the info in the spec?

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> > 4) contrib/pyblosxom/make-blog has a custom license.
> This one required research.  Fixed.

Great work figuring this one out!

> > 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.
> 
> For some reason my piuparts installation isn't working properly, but
> manually I tested both clean install and upgrading in a clean sid
> chroot. (this is how I tested #1 and #6)

piuparts is failing here too, due to issues in the ldap packages.  I
also tested the manual upgrade and it works :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851517: piuparts uses apt --allow-downgrades even if it should not

[Sean Whitton]

On Sun, Jan 15, 2017 at 09:38:18PM +, Holger Levsen wrote:
> how strange, as the code from a9219384 explicitly tests this:
> 
> (status, output) = run(["dpkg-query", "-f", "${Version}\n", "-W", 
> "apt"], ignore_errors=True)
> apt_can_install_debs = LooseVersion(output.strip()) >= 
> LooseVersion("1.1")

Thank you for CCing me on this.

I tested LooseVersion with the version of apt in wheezy:

iris ~ % python
Python 2.7.13rc1 (default, Dec  4 2016, 14:12:39) 
[GCC 6.2.1 20161124] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.version import LooseVersion
>>> LooseVersion("0.9.7.9+deb7u7") >= LooseVersion("1.1")
False

So LooseVersion can handle the version number.  Possibly dpkg-query is
behaving differently on wheezy?  Perhaps you could run that dpkg-query
command on wheezy and see what you get.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821844: elpa-magit: [RFE] Please include magit subcomponents

[Sean Whitton]

On Sun, Jan 15, 2017 at 03:15:22PM -0700, Sean Whitton wrote:
> This would violate pkg-emacsen team policy[1] and standard practices.
> These addons should be in separate source packages.

[1] http://pkg-emacsen.alioth.debian.org/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821844: elpa-magit: [RFE] Please include magit subcomponents

[Sean Whitton]

control: tag -1 +wontfix

Dear Robbie,

On Tue, Apr 19, 2016 at 02:54:04PM -0400, Robbie Harwood wrote:
> 
> I'm primarily interested in magit-stgit here, though there are other git
> component integrations that upstream has available[0].  Since we have stgit
> and magit both available, it would be great if the integration glue were also
> packaged[1].  I think it makes sense to include these in the magit packaging,
> so I'm filing this rather than a RFP.

This would violate pkg-emacsen team policy[1] and standard practices.
These addons should be in separate source packages.

Thank you for your suggestion, and please consider joining our team to
package these other component integrations.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sun, Jan 15, 2017 at 04:51:24PM -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> > I found some more errors in the copyright file.  Rather than go back and
> > forth once again, I fixed them in our team git repository.  I set the
> > changelog back to UNRELEASED: if you are okay with the changes, please
> > `dch -r`, commit and push, and I will upload.
> 
> Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
> the file is time stamped <2001-08-24 emarsden>?  

Ah, sorry.

> For httpd.el, I agree that "2001, 2003" is more accurate, but is it
> allowed?  In the past, when I've submitted patches to this effect the
> maintainer of the package changed the lines to something like
> "2001-2003", even though the VCS and copyright embedded in the file
> specified discreet years rather than a range...which led me to believe
> that a discreet range is unacceptable.

A discrete range is fine.

> Ah!  Yes, this is the spec that addresses my question to #3.  That
> said, in the past some of my other work on d/copyright has been said
> to be "worse than useless" even though it adhered to the spec, and
> even though it seemed to reflect what I saw reading the packages
> COPYING file, in addition to spending a while reading VCS commits for
> stuff I wasn't sure about.  This has led me to wonder about the tribal
> rules that are not in the spec...

Could you give me an example of a rule like that?

> Would you please check to see if my latest commit to d/copyright is
> ok?  It's what makes the most sense to me.  As far as I can tell, it
> might be problematic because it infers that Eric Marsden changed
> cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

No, it doesn't actually imply that Marsden changed that file in 2004
(the spec does explain this!).

Go ahead and `dch -r`!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851547: gnome-shell: under Wayland, alt-tab switcher fails when using focus-follow-mouse

[Sean Whitton]

ackages gnome-shell recommends:
ii  gdm33.22.1-1
ii  gkbd-capplet3.22.0.1-1
ii  gnome-contacts  3.22.1-1+b1
ii  gnome-control-center1:3.22.1-1
ii  gnome-themes-standard-data  3.22.2-1
ii  gnome-user-guide3.22.0-1
ii  iio-sensor-proxy2.0-1
ii  unzip   6.0-21

gnome-shell suggests no packages.

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Sean Whitton]

Hello Alberto,

On Wed, Dec 28, 2016 at 09:31:53PM +0100, Alberto Luaces wrote:
> Thanks, Sean.  I have addressed the gbp.conf and changelog issues and I
> think the realease is ready to go.

Thanks again for your work.

gbp.conf says upstream-branch=upstream but your upstream sources are on
a branch called 'master' ...

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849489: RFS: darksnow/0.7.1-1 [QA]

[Sean Whitton]

control: owner -1 !

Hello David,

On Wed, Dec 28, 2016 at 09:12:49PM +, David Davies-Jones wrote:
> I've tried addressing the issues you've raised and re-uploaded to mentors. If
> there are any more problems please let me know

Thanks for your updated package.  I'm sorry not to have raised this in
my previous message, but there are other changes you've made that are
not documented in the changelog.  For example, you dropped some
build-dependencies, and you renamed a quilt patch.  Please check the
difference between 0.6.1-3 and 0.7.1-1 carefully.

Tip: it's easier if you work in git, rather than just handling source
packages.  This is what I just did to review your work:

% dget -d 
https://mentors.debian.net/debian/pool/main/d/darksnow/darksnow_0.7.1-1.dsc
% dgit clone darksnow
% dgit import-dsc ../darksnow_0.7.1-1.dsc david
% git checkout david
% git diff dgit/dgit/sid..HEAD

By the way, it would be good to forward your darksnow.desktop upstream
(that won't be reflected in your QA upload, of course).

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#849489: RFS: darksnow/0.7.1-1 [QA]

[Sean Whitton]

Hello David,

On Wed, Dec 28, 2016 at 10:53:00PM +, David Davies-Jones wrote:
> I shall go through it with a fine toothcomb over the next few days. Yes, this
> may be a better method. At the moment, I make changes as I can, which can
> result in loosing track of what I've done. I shall experiment with using git
> like this and see how I go on. With the packages that I've been putting up to
> mentors I've been constructing a mental checklist of what I'm learning, need 
> to
> start putting it down in writing and following it rigidly.

Cool.  It's not arduous once you're in the habit of updating the
changelog every time you make a git commit.  I'm biased here, but a
decent git workflow is in this tutorial: dgit-maint-merge(7)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Sean Whitton]

Hello Alberto,

On Wed, Dec 28, 2016 at 11:43:29PM +0100, Alberto Luaces wrote:
> I have now pushed a new release.

Did someone else upload 0~git20161123-1?

If not, you should merge the changelog entries for -1 and -2.  It's just
confusing to have changlog entries that never made it into the Debian
archive.

After merging them, be sure to run `dch -r` to update the timestamp.

Also, I think you need to put a tag '0_git20161123' on the upstream
branch.  That's how gbp generates a tarball.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849581: RFS: numpydoc/0.6.0+ds1-1

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Dear Ghislain,

On Wed, Dec 28, 2016 at 09:47:09PM +, Ghislain Vaillant wrote:
> I am looking for a sponsor for my package "numpydoc"

I can sponsor this for you, but I'd like to ask you to improve your
changelog a bit -- see below.

> Changes since the last upload:
> 
>   * Team upload
> 
>   [ Ondřej Nový ]
>   * Fixed VCS URL (https)
> 
>   [ Ghislain Antony Vaillant ]
>   * Filter upstream tarball from vendored sphinx.ext.linkcode

Why?  It's not explained anywhere why this was necessary.  It would be
good if you could note it in the changelog.

>   * New upstream release
>   * Update copyright file
>   * Bump versioned depends on Python to 2.7 and 3.4
>   * Bump standards version to 3.9.8, no changes required
>   * Add packaging testsuite

Not clear what "packaging" means.  Maybe s/packaging/autopkgtest/

>   * Rearrange copyright paragraphs to fix Lintian warnings
>   * Add build dependency on dh-python

Why?  Maybe s/Add/Add missing/

>   * Improve description of the Python 2 binary package
>   * cme fix dpkg-control:
> - Drop versioned dependency on python-all
> - Drop versioned dependency on python[,3]-sphinx
> - Wrap and sort
>   * cme fix dpkg-copyright: use HTTPS URI in Format field

note to self: checked diff from archive to 0dec799

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jörg,

On Thu, Dec 29, 2016 at 10:08:50AM +0100, Jörg Frings-Fürst wrote:
>   I am looking for a sponsor for my package "xtrkcad"

I'd like to sponsor this.

I assume it's okay for me to work out of your collab-maint repo.

>   Changes since the last upload:
> 
>   * New Maintainer (Closes: #849139):
> - debian/control: Add myself as maintainer.
> - debian/copyright: Add myself to debian/*.
>   * New upstream release (Closes: #847843, #784423).

In #847843, Mike Gabriel suggests team maintenance of xtrkcad.  Have you
got in touch with him about maintaining xtrkcad together?  Is he aware
of your ITA?  #847843 is itself almost an ITA, and it was submitted only
very recently, so you should be sure that your upload doesn't treat on
Mike's toes.

>   * Remove debian/source/options.

Why?

>   * Remove debian/source.lintian-overrides.
>   * Change debian/compat to 10 (no changes required).
>   * debian/control:
> - Bump Standards-Version to 3.9.8 (no changes required).
> - Bump debhelper B-D minimum version to 10.
> - Add Vcs-* tags.
> - Change Priority from extra to optional.

Just a reminder that you will have to submit a bug against
ftp.debian.org to have this actually take effect (post-adoption).

>   * debian/rules:
>    - Enable hardening.
>   * New debian/patches/0700-info_file.patch to add requested directory entry
> and INFO-DIR-SECTION.
>   * Rewrite debian/watch to use the sf redirector.
> - Add files to exclude in debian/copyright.
>   * Rewrite debian/copyright.

Lintian tags you can easily fix:

I: xtrkcad source: vcs-field-uses-insecure-uri vcs-git 
git://anonscm.debian.org/collab-maint/xtrkcad.git
I: xtrkcad: spelling-error-in-binary usr/bin/xtrkcad Minumum Minimum

In the future, after the stretch freeze, consider a package split:

I: xtrkcad: arch-dep-package-has-big-usr-share 16352kB 92%

It looks like you used wrap-and-sort -- please add this to the
changelog, so a future contributor knows which options to use.  E.g.

* Run wrap-and-sort -abst

You made changes to d/rules not documented in the changelog.

After making further changes, don't forget to re-run `dch -r`, and
please remove the moreinfo tag from this bug to put it back in my queue.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849581: RFS: numpydoc/0.6.0+ds1-1

[Sean Whitton]

Hello Ghislain,

On Thu, Dec 29, 2016 at 12:48:35PM +, Ghislain Vaillant wrote:
> > >   [ Ghislain Antony Vaillant ]
> > >   * Filter upstream tarball from vendored sphinx.ext.linkcode
> > 
> > Why?  It's not explained anywhere why this was necessary.  It would be
> > good if you could note it in the changelog.
> 
> sphinx.ext.linkcode -> because it is already in Sphinx?
> 
> Isn't this explicit enough?

Firstly, your grammar is wrong: it should be "filter vendored
splinx.ext.linkcode *from upstream tarball*".

Secondly, it still takes some thinking to grasp your meaning.  This
would be easier to understand: "filter vendor copy of
sphinx.ext.linkcode from upstream tarball."

A key purpose of the changelog is to communicate efficiently with other
Debian contributors.  It took me some time to understand your meaning,
so you're not achieving that purpose :)

> > >   * New upstream release
> > >   * Update copyright file
> > >   * Bump versioned depends on Python to 2.7 and 3.4
> > >   * Bump standards version to 3.9.8, no changes required
> > >   * Add packaging testsuite
> > 
> > Not clear what "packaging" means.  Maybe s/packaging/autopkgtest/
> 
> You are the first sponsor who has had problems with this terminology. I use
> packaging testsuite as the testsuite associated to the packaging, as opposed
> to the upstream testsuite associated to the upstream code.
> 
> Anyway, let me know whether this is *really* a deal breaker.

Not a deal breaker.  But since you are editing the "vendored" part, you
might as well edit this too.

How about "Add autopkgtest testsuite for packaging"

> > note to self: checked diff from archive to 0dec799
> 
> If there is more reviewing to come, please consider doing it now. My time
> working on other team-maintained packages is very limited (so is probably
> your sponsorship time) and I would appreciate limiting the number of email
> iterations to accelerate the process.

Don't worry.  I meant "everything except the contents of my e-mail LGTM
in 0dec799".

Don't forget `dch -r` after making further changes.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845710: RFS: mongovi/1.0.0-1 [ITP]

[Sean Whitton]

control: tag -1 +moreinfo

Dear Tim,

Is this package available in a git repository?

The Vcs-* headers point to a repo that does not contain a debian/
directory.  They should point to a repository containing the source
package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Sean Whitton]

Hello Alberto,

On Thu, Dec 29, 2016 at 05:01:29PM +0100, Alberto Luaces wrote:
> Sean Whitton writes:
> >
> > If not, you should merge the changelog entries for -1 and -2.  It's just
> > confusing to have changlog entries that never made it into the Debian
> > archive.
> >
> 
> Well, it seemed cleaner than modifying an already published history, but
> I understand no solution is immune to drawbacks.  I have now pushed the
> new, fixed branch.  Please note that you will have to re-synchronise, or
> clone the repository again from scratch.

Oh dear, that wasn't what I meant!  I was suggesting you just make a
commit merging the changelog entries together.  Anyway, it's done now.

I'd like to suggest some improvements to your changelog:

>   * Updated d/control according to d.e.a.p.t. guidelines.

Only an existing team member would know what d.e.a.p.t. is!  Perhaps add
the URI <http://pkg-emacsen.alioth.debian.org/elpa-hello/>?

You also rewrote d/rules, but this is not mentioned in the changelog.

>   * Update standards to 3.9.8.

Did you have to change anything in the packaging for this update?  If
not, it's conventional to write "(no changes required)".

>   * Disabled parents in clojure mode due to upgrading errors.

This is meaningless to someone not already familiar with yasnippet.  You
wrote a great patch header, so I would suggest just this changelog
entry:

* Add 0001-Avoid-.dpkg-new-upgrading-error.patch

Please accept my apologies for not raising these suggestions in a
previous e-mail, and thank you for your patience with this sponsorship
process -- I'm confident I'll be able to upload after your next update.

(don't forget dch -r)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845710: RFS: mongovi/1.0.0-1 [ITP]

[Sean Whitton]

Dear Tim,

On Thu, Dec 29, 2016 at 07:51:56PM +0100, Tim Kuijsten wrote:
> On Thu, Dec 29, 2016 at 06:46:58PM +0000, Sean Whitton wrote:
> > control: tag -1 +moreinfo
> > 
> > Dear Tim,
> > 
> > Is this package available in a git repository?
> > 
> > The Vcs-* headers point to a repo that does not contain a debian/
> > directory.  They should point to a repository containing the source
> > package.
> 
> Ah, I thought it was the general repository, not Debian specific :)
> Then I guess it's best to remove the VCS link, rigth?

I think it would be best to keep the packaging in a git repository and
point Vcs-* there, but if you prefer not to, it would be best to remove
those fields, yes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849581: RFS: numpydoc/0.6.0+ds1-1

[Sean Whitton]

Hello Ghislain,

On Thu, Dec 29, 2016 at 03:35:23PM +, Ghislain Vaillant wrote:
> I pushed a refreshed tag pointing at the latest commit already:
> 
> https://anonscm.debian.org/cgit/python-modules/packages/numpydoc.git/tag/?h=debian/0.6.0%2bds1-1
> 
> Isn't that enough?

It's fine, it just might cause some confusion later on since there are
two tags in existence, with the same name but signed by different
people.

This was basically my fault for not telling dgit not to create the
second tag.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Sean Whitton]

Hello Pierre,

On Thu, Dec 29, 2016 at 09:20:02PM +0100, Pierre-Elliott Bécue wrote:
> Le mardi 27 décembre 2016 à 22:11:38+0000, Sean Whitton a écrit :
> > Hello Pierre,
> > 
> > On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote:
> > > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> > > > control: tag -1 +moreinfo
> > > > 
> > > > Dear Pierre,
> > > > 
> > > > Thank you for your interest in adopting this package.
> > > > 
> > > > Unfortunately, your work has not been properly integrated with what is
> > > > already in Debian:
> > > > 
> > > > - you marked version 0.4.74-4 as released but it was never uploaded
> > > 
> > > True. Yet, it is in the team repo.
> > 
> > The changelog tracks the Debian archive.  You should merge the existing
> > 0.4.74-4 changelog entry with your changes.
> 
> 0.4.74-4 is not in the debian archive, only in the team repo. How should I
> merge exactly?

This is roughly what I have in mind:

pyvtk (0.5.18-1) unstable; urgency=low

  [ Jakub Wilk ]
  * Use canonical URIs for Vcs-* fields.
  * Remove obsolete Conflicts/Replaces with python2.3-pyvtk and
python2.4-pyvtk.

  [ Stefano Rivera ]
  * Convert inline patch to 3.0 (quilt) to ease git-dpm migration.

  [ Ondřej Nový ]
  * Fixed VCS URL (https)

  [ Pierre-Elliott Bécue ]
  * New maintainer (Closes: #795017).
  * New upstream release
  * Uses pybuild for building the package.
  * Cleaning debian/*

 -- Pierre-Elliott Bécue   Sat, 17 Dec 2016 00:24:15 +0200

> > > > - your work is not pushed to the team git repository
> > > 
> > > I have no permission to push.
> > 
> > Have you asked to join the team?
> 
> I don't feel that I've done enough to get permissions, maybe my
> interpretation is wrong.

I see what you mean, and every Debian team is different.

However, chances are they would prefer that you join the team and push
your git history there, as then other team members can more easily build
upon your work.

So please submit a request, explaining that you want to work on pyvtk.
If they say no, it's not a big deal!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

control: tag -1 +moreinfo

Hello Jörg,

On Thu, Dec 29, 2016 at 07:03:26PM +0100, Jörg Frings-Fürst wrote:
> first thanks for your first review.

No problem.

I've now taken a proper look at your copyright file.  Some problems:

- the "FreeBSD" license has a standard shortname: BSD-2-clause

- did you make up the 'mixed', 'BSD-Revised' and 'permissive' license
  shortnames?  I suspect there are standard names -- try
  http://codesearch.debian.net

- you can't claim 2017 copyright on debian/ since we will upload this
  before 2017 begins :)

- if you run `licensecheck --copyright -r .` you will find many files
  that are Copyright 2005 David Bullis.  Maybe you should add this to
  the "Files: *" stanza?

- Mikko Nissinen also holds copyright on app/i18n/stripmsg.c

- copyright years for getopt.*, uthash.h, gwin32.c, mswbitmap.c and
  others are wrong -- why did you add '-2015' when the file was not
  edited since the earlier year?

- copyright for app/tools/halibut/charset/macenc.c wrong

> > >   Changes since the last upload:
> > > 
> > >   * New Maintainer (Closes: #849139):
> > > - debian/control: Add myself as maintainer.
> > > - debian/copyright: Add myself to debian/*.
> > >   * New upstream release (Closes: #847843, #784423).
> > 
> > In #847843, Mike Gabriel suggests team maintenance of xtrkcad.  Have you
> > got in touch with him about maintaining xtrkcad together?  Is he aware
> > of your ITA?  #847843 is itself almost an ITA, and it was submitted only
> > very recently, so you should be sure that your upload doesn't treat on
> > Mike's toes.
> > 
> My mistake. I have only skimmed through the text. I have ask Mike per
> mail and add him as Uploader.

Great.  I suggest writing "(Closes: #847843)" next to the Uploader
change -- it is okay to 'close' a bug more than once in a single upload.

> >   * Remove debian/source/options.
> > 
> > Why?
> 
> To use the default compression. Comment is added.

Okay.

> >
> > >   * Remove debian/source.lintian-overrides.
> > >   * Change debian/compat to 10 (no changes required).
> > >   * debian/control:
> > > - Bump Standards-Version to 3.9.8 (no changes required).
> > > - Bump debhelper B-D minimum version to 10.
> > > - Add Vcs-* tags.
> > > - Change Priority from extra to optional.
> > 
> > Just a reminder that you will have to submit a bug against
> > ftp.debian.org to have this actually take effect (post-adoption).
> > 
> 
> Because of the Priority change?
> 
> The change was based on the comment at the old PTS[1].

Ah.  You could mention this in your changelog, so I wouldn't ask the
question :)  E.g.

- Change Priority from extra to optional.
  To match current ftp-master override file.

> > >   * debian/rules:
> > >    - Enable hardening.
> > >   * New debian/patches/0700-info_file.patch to add requested directory 
> > > entry
> > > and INFO-DIR-SECTION.
> > >   * Rewrite debian/watch to use the sf redirector.
> > > - Add files to exclude in debian/copyright.
> > >   * Rewrite debian/copyright.
> > 
> > Lintian tags you can easily fix:
> > 
> > I: xtrkcad source: vcs-field-uses-insecure-uri vcs-git 
> > git://anonscm.debian.org/collab-maint/xtrkcad.git
> 
> My option to not change git to https was to start a git-gui client
> directly. If you want I change it.

Are you saying that git-gui cannot use https URIs?

It's okay to keep git:// if it is more convenient for you.

> > I: xtrkcad: spelling-error-in-binary usr/bin/xtrkcad Minumum Minimum
> 
> I have add a new patch 0900-spelling-errors.patch to correct the
> spelling error.

Thanks, and great work forwarding the patch.

> > It looks like you used wrap-and-sort -- please add this to the
> > changelog, so a future contributor knows which options to use.  E.g.
> > 
> > * Run wrap-and-sort -abst

You haven't added this to the changelog yet...

> > 
> > You made changes to d/rules not documented in the changelog.
> 
> sry. Also I don't have a git commit message. I have add a comment about
>  this.

What do you mean about "git commit message"?

Changelog for d/rules LGTM.

>
>  
> > 
> > After making further changes, don't forget to re-run `dch -r`, and
> > please remove the moreinfo tag from this bug to put it back in my queue.
> > 
> done

Ditto for this second review.

We are almost ready to upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

Hello again Jörg,

On Thu, Dec 29, 2016 at 10:16:13PM +, Sean Whitton wrote:
> We are almost ready to upload.

I found one more issue...

- /usr/share/xtrkcad/{logo.bmp, html, examples, demo} should be in 
/usr/share/doc/xtrkcad

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842026: RFS: bundlewrap/2.9.1-1, ITP: 838029 -- Decentralized configuration management system with Python

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jonathan,

On Tue, Oct 25, 2016 at 01:48:49PM +0200, Jonathan Carter (highvoltage) wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors (cc debian-python),
> 
> I am looking for a sponsor for my package "bundlewrap":

I just took at look at your source package.  You are not using the
dh_python tool, which means that your package fails several points of
the Python applications packaging policy (in particular, the .py files
you install are not bytecompiled).

Further, you list each dependency manually, whereas with dh_python you
could just use the $(python:Depends) substvar.  Please check out
dh_python!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849318: RFS: eoconv/1.5-1

[Sean Whitton]

Dear Andreas,

On Sun, Dec 25, 2016 at 02:42:42PM +0100, Andreas Henriksson wrote:
> This repository looks whack. How do you build it? You should really add
> a debian/README.source with the details if you intend to use this as the
> official packaging vcs (as listed by the Vcs-* fields).

You might want to look at the origtargz(1) tool from devscripts to
handle this sort of repository.  You can just do this to get something
buildable:

% origtargz -u

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#847603: RFS: mod_pagespeed/1.11.33.4 [ITP] -- Apache module for rewriting web pages to reduce latency and bandwidth

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jeff,

On Fri, Dec 09, 2016 at 02:43:32PM -0500, Jeff Kaufman wrote:
> I am looking for a sponsor for my package "mod_pagespeed":

This looks cool.  Here are some initial comments:

- I'm not prepared to fully review a package that is not available in
  git.  We might need multiple rounds of review, and git-diff(1) is
  invaluable for that.  Please consider `gbp import-dsc` or `dgit
  import-dsc` (the former is more popular; I prefer the latter)

- Your Vcs-* headers point to the upstream repository, which does not
  contain a debian/ directory.  Vcs-* headers are meant to point at a
  packaging repository.  Do you have one available somewhere?

- You have a very long list of quilt patches.  Have you considered
  merging some of them?  For example, all the -native patches could be a
  single patch.  Quilt patches can be a pain to manage when there are
  new upstream releases.

- I note that you have '#ifdef USE_SYSTEM_FOO' but your patch just
  strips off the whole conditional.  Wouldn't it be easier to use those
  USE_SYSTEM_* flags, instead of patching?

- generate.sh runs a copy of gyp in the source tree.  But gyp is
  packaged for Debian.  Please add a build-dependency on the packaged
  gyp, and run that instead (you might need another patch...)

- The package doesn't build in a clean sid chroot.  Log attached.

-- 
Sean Whitton
sbuild (Debian sbuild) 0.72.0 (25 Oct 2016) on zephyr.silentflame.com

+==+
| modpagespeed 1.11.33.4-1 (i386)  Fri, 30 Dec 2016 07:41:56 + |
+==+

Package: modpagespeed
Version: 1.11.33.4-1
Source Version: 1.11.33.4-1
Distribution: unstable
Machine Architecture: i386
Host Architecture: i386
Build Architecture: i386

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-i386-sbuild-dcccd87b-c0a4-4d7a-9cae-4908ef6a595f'
 with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://mirror.vorboss.net/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/swhitton/rfs/modpagespeed_1.11.33.4-1.dsc exists in /home/swhitton/rfs; 
copying to chroot
I: NOTICE: Log filtering will replace 
'build/modpagespeed-vvyuTA/modpagespeed-1.11.33.4' with '<>'
I: NOTICE: Log filtering will replace 'build/modpagespeed-vvyuTA' with 
'<>'

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 
'/<>/resolver-d63B9K/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
Ign:1 copy:/<>/resolver-d63B9K/apt_archive ./ InRelease
Get:2 copy:/<>/resolver-d63B9K/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/resolver-d63B9K/apt_archive ./ Release.gpg
Get:4 copy:/<>/resolver-d63B9K/apt_archive ./ Sources [349 B]
Get:5 copy:/<>/resolver-d63B9K/apt_archive ./ Packages [430 B]
Fetched 1736 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install core build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-core-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 786 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 copy:/<>/resolver-d63B9K/apt_archive ./ 
sbuild-build-depends-core-dummy 0.invalid.0 [786 B]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 786 B in 0s (0 B/s)
Sel

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Hello Nicholas,

Just to let you know, we've already missed the deadline to add elpa-muse
to stretch (it was Christmas day, due to 10 day migrations).

I'll respond properly later.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

On Fri, Dec 30, 2016 at 04:59:11PM +, Sean Whitton wrote:
> Just to let you know, we've already missed the deadline to add elpa-muse
> to stretch (it was Christmas day, due to 10 day migrations).

Sorry, looks like we were both wrong -- the deadline for binNEW is
February 5th.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

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, be

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

Hello Jörg,

On Sun, Jan 01, 2017 at 04:06:33PM +0100, Jörg Frings-Fürst wrote:
> Am Freitag, den 30.12.2016, 19:36 + schrieb Gianfranco Costamagna:
> > did you also merge the debian improvements from Mike?
> 
> some yes, some on a other way and some not yet.
> 
> I use dh instead of cdbs and I'm working without get-orig-source.
> Compat level is 10 instead of 9.

Fine.

> Debian/copyright is completely rewritten, but I can't check against
> Mikes version.

It's fine so long as it is accurate (though unfortunate that work was
duplicated).

> On the todo list is the split into two packages. With Sean is agreed
> that to make after the freeze.

I was wrong about this.  We can upload to binNEW until the end of
January.  So how about doing the package split now?  Your choice,
depending on time available.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849844: RFS: manpages-zh/1.6.0-1

[Sean Whitton]

control: owner -1 !
control: tag -1 +moreinfo

Dear Boyuan,

Can I sponsor from
<https://anonscm.debian.org/git/chinese/manpages-zh.git>?

If so, I see changes to d/control and d/docs which are not documented in
the Debian changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849844: RFS: manpages-zh/1.6.0-1

[Sean Whitton]

Dear Boyuan,

On Mon, Jan 02, 2017 at 08:10:57PM +0800, Boyuan Yang wrote:
> I didn't document them since they look more like implementation detail (e.g,
> upstream changes in build tools, perl->python, README renaming, etc), users 
> may read upstream ChangeLog if they are interested. Anyway the version on 
> mentors and the one in Git repository are kept in consistency.

Thank you for your reply.

debian/ is not part of the upstream code, so changes should be listed in
d/changelog.  Other Debian contributors should be able to quickly
determine which uploads changed which control files, by looking at
d/changelog.  So please be more verbose.

-- 
Sean Whitton


signature.asc
Description: PGP signature