Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Sean Whitton , 2016-07-01, 08:13:
I would be grateful, Jakub, if you could try the build on your sbuild 
config before I file a bug against sbuild suggesting this be the 
default.  The repo, for your convenience:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el


Why .orig.tar from pristine-tar is different than the on uscan 
downloads?


I tried to build the package in sbuild in a (clean but not quite 
up-to-date) VM, and it indeed FTBFS:


dtach -n debian/elpa-test.sock sh -c '/usr/bin/make test && touch 
debian/elpa-test.ok'
dtach: Could not find a pty.
debian/rules:21: recipe for target 'override_dh_elpa_test' failed


I don't understand why, though.
/dev/pts is mounted in the chroot, as it should...

--
Jakub Wilk

Bug#827907: RFS: evil/1.2.12-1 ITP

[Ansgar Burchardt]

On Fri, 2016-07-01 at 08:13 +, Sean Whitton wrote:
> On Thu, Jun 30, 2016 at 10:24:51PM +0200, Jakub Wilk wrote:
> > * Dmitry Bogatov , 2016-06-30, 22:28:
> > > * default configuration of pbuilder do not provide possibility to
> > > allocate
> > > pty
> > 
> > Sounds like a bug in pbuilder.
> > 
> > > So, question is whether it is possible to allocate pty on Debian
> > > build
> > > farm.
> > 
> > Yes.
> 
> It seems that vanilla sbuild has the same problem (tested locally and
> on
> deb-o-matic), so it seems like the buildds are using some special
> sbuild
> configuration to permit allocating ptys.
> 
> I would be grateful, Jakub, if you could try the build on your sbuild
> config before I file a bug against sbuild suggesting this be the
> default.  The repo, for your convenience:
> https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el

It depends on the version of debootstrap in use. See [1].

Ansgar

  [1] 

Bug#827907: RFS: evil/1.2.12-1 ITP

[Gianfranco Costamagna]

control: owner -1 !

Hi,

>You might consider re-running dch -r to refresh the timestamp in the
>changelog so it lies after all our changes.


and ping when ready :)

G.

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

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

Hello Dmitry,

My apologies for wasting your time -- I can't reproduce it now.

I added a "Forwarded: not-needed" header and I think we're done here :)
Thank you for your time.  The only thing I couldn't test is a clean
build in pbuilder/sbuild which isn't possible due to the dtach issue.

You might consider re-running dch -r to refresh the timestamp in the
changelog so it lies after all our changes.

-- 
Sean Whitton

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> > > > > Nice work.  Have you forwarded the fix upstream?
> > > > Too much trouble. To fix it upstream, they have to deal with either:
> > > >  * evil mode is autoloaded, interactive and with sane description. 
> > > > Ugliness
> > > >in code.
> >
> > > Do you know whether the problem if Debian-specific, or if it also arises
> > > when installing evil from MELPA?
> >
> > On MELPA everything is smooth.
>
> Are you sure about this?  I tested myself, and the same problem occurs:
> M-x evil-mode doesn't work, although M-x describe-function evil-mode does.

Yes, I do.

> I consider this an upstream bug.  Although most users will call
> `evil-mode' in their init file, one of the reasons for using the
> package.el packaging format is that a user can just do `M-x
> package-install evil RET M-x evil-mode RET' to quickly try out a new
> mode without doing any config.
>
> Since we have fixed this bug in the Debian package, we ought to forward
> our work upstream.  Since we fixed it by some code in d/rules, we can't
> just send a patch they can apply.  So I suggest that you file an
> upstream bug report, explain what you did to fix the problem for the
> Debian package, and put a link to that bug report in the Forwarded:
> header of the patch and also as a comment in d/rules.

Can you please report upstream yourself? I can't reproduce bug via MELPA.
See:

 * If I build without my patch, the following autoload form will appear in
   evil-autoloads.el

(autoload 'evil-mode "evil")

   Note the lack of third and forth arguments, description and
   interactive markers.

 * With my patch, and before sed, we have following autoload:

(autoload 'evil-mode "evil-core" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn  ARG)" t nil)

   Note that "evil-core" is autoloaded -- file where evil-mode is defined,
   but not while evil suite.

 * And here is autoload from my
   ~/.emacs.d/elpa/evil-20160227.711/evil-autoloads.el:

(autoload 'evil-mode "evil" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn  ARG)" t nil)

   Everything is perfect. #'evil-mode autoloads whole evil suite.

> Another thing :)  I don't think you need to invoke find(1) in d/rules.
> You can just do something like this:
>
> sed -i 's#foo..' 
> debian/elpa-evil/usr/share/emacs/site-lisp/elpa-src/evil-*/evil-autoloads.el
>
> That's more explicit and easier to understand.

Done.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Thu, Jun 30, 2016 at 10:28:13PM +0300, Dmitry Bogatov wrote:
> I elaborated this solution and pushed to master. Following is true:
> 
>  * `make test < /dev/null' fails
>  * `dpkg-buildpackage -us -uc < /dev/null' is success now. (see 16d89)
>  * 'dtach' uses pty(7)
>  * default configuration of pbuilder do not provide possibility to allocate
>pty

Nice job.

I filed #829170 and committed a comment to your d/rules referring to that.

On Thu, Jun 30, 2016 at 10:24:51PM +0200, Jakub Wilk wrote:
> * Dmitry Bogatov , 2016-06-30, 22:28:
> >* default configuration of pbuilder do not provide possibility to allocate
> >pty
> 
> Sounds like a bug in pbuilder.
> 
> >So, question is whether it is possible to allocate pty on Debian build
> >farm.
> 
> Yes.

It seems that vanilla sbuild has the same problem (tested locally and on
deb-o-matic), so it seems like the buildds are using some special sbuild
configuration to permit allocating ptys.

I would be grateful, Jakub, if you could try the build on your sbuild
config before I file a bug against sbuild suggesting this be the
default.  The repo, for your convenience:
https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el

> > > > Nice work.  Have you forwarded the fix upstream?
> > > Too much trouble. To fix it upstream, they have to deal with either:
> > >  * evil mode is autoloaded, interactive and with sane description. 
> > > Ugliness
> > >in code.
> 
> > Do you know whether the problem if Debian-specific, or if it also arises
> > when installing evil from MELPA?
> 
> On MELPA everything is smooth.

Are you sure about this?  I tested myself, and the same problem occurs:
M-x evil-mode doesn't work, although M-x describe-function evil-mode does.

I consider this an upstream bug.  Although most users will call
`evil-mode' in their init file, one of the reasons for using the
package.el packaging format is that a user can just do `M-x
package-install evil RET M-x evil-mode RET' to quickly try out a new
mode without doing any config.

Since we have fixed this bug in the Debian package, we ought to forward
our work upstream.  Since we fixed it by some code in d/rules, we can't
just send a patch they can apply.  So I suggest that you file an
upstream bug report, explain what you did to fix the problem for the
Debian package, and put a link to that bug report in the Forwarded:
header of the patch and also as a comment in d/rules.

Another thing :)  I don't think you need to invoke find(1) in d/rules.
You can just do something like this:

sed -i 's#foo..' 
debian/elpa-evil/usr/share/emacs/site-lisp/elpa-src/evil-*/evil-autoloads.el

That's more explicit and easier to understand.

-- 
Sean Whitton

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Dmitry Bogatov , 2016-06-30, 22:28:
* default configuration of pbuilder do not provide possibility to 
allocate pty


Sounds like a bug in pbuilder.

So, question is whether it is possible to allocate pty on Debian build 
farm.


Yes.

--
Jakub Wilk

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Sean Whitton , 2016-06-30, 13:32:

   override_dh_elpa_test:
   dtach --foo --bar -- dh_elpa_test


It's probably not _that_ simple. dtach, understandably, ignores exit 
status of the program it runs.


I think you'll need something like this:

override_dh_elpa_test:
rm -f test_exit_status
dtach -c tmpsocket sh -c 'dh_elpa_test; echo $$? > test_exit_status'
rc=$$(cat test_exit_status) && exit $rc

--
Jakub Wilk

Bug#827907: RFS: evil/1.2.12-1 ITP

[Gianfranco Costamagna]

Hi,


>> > Unfortunately, upstream maintains only list of contributors. So seems

>> > best thing we can do is to count 60 years from last debian upload.
>> 
>> I'm not sure whether this is likely to be acceptable to the ftp-masters
>> or not.  Perhaps someone more experienced on debian-mentors can chime
>> in.
>
>Gianfranco, your opinion?


I'm far from being expert here, but I think ftpmasters care more about
licenses and dfsg-freeness instead of copyrights.
As long as the license is dfsg they are fine, specially because in the
*worst case* the license will be dfsg, in the best case it *might* be public
domain.

So, in every case we have a "good" license (Debian-wise, I don't personally
like GPL-3+ and I prefer GPL-2+)

Gianfranco

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

Try removing the call to dh_auto_build from your override_dh_auto_build.
It's doing a bunch of byte compilation that is unnecessary because
dh-elpa will do that later on.

On Tue, Jun 28, 2016 at 02:01:41PM +0300, Dmitry Bogatov wrote:
> In general, do we have any script, that automates process of writing
> watch files? Every time I need to write watch file for github, I
> copy-and-paste from comments in /usr/bin/uscan.

There is the uscan manpage, rather than looking at the code, which you
might consider slightly better.

On Tue, Jun 28, 2016 at 04:49:33PM +0300, Dmitry Bogatov wrote:
> Do not understand. I alread have tarball content, as I downloaded
> it at 'upstream/1.2.12'. What more we need?

It just means that your tarball will be different from the one that
actually gets uploaded by the DD who sponsors the RFS.  Hopefully it is
not materially different (just timestamps etc.) but I think that
settings in ~/.gbp.conf could mean a materially different tarball gets
generated on the DD's machine.  It's a nice safety check if we can check
out your tarball from the pristine-tar branch.  But not a big deal and
certainly doesn't block sponsorship.

> Here is script, that does same as dh_elpa_test:
> 
>   emacs -batch -Q -L . --eval "(require 'evil)" -l package \
> --eval "(add-to-list 'package-directory-list 
> \"/usr/share/emacs/site-lisp/elpa\")" \
> --eval "(add-to-list 'package-directory-list 
> \"/usr/share/emacs/site-lisp/elpa-src\")" \
> -f package-initialize \
> -L . \
> -l evil-tests.el \
> -l lib/ert.el \
> -L lib \
> -f evil-tests-initialize
> 
> It reports 22 failures. If I replace -batch with -nw, all tests
> passes. So seems tty is really needed, but I do not understand why.

This is not what dh_elpa_test is actually running ;)  It's calling
`ert-batch-run-tests-and-exit' instead of `evil-tests-initialize'.  Before
we can debug this properly, we need to make dh_elpa_test do the same
thing that upstream's makefile does (except the -nw/-batch).  Please
investigate DH_ELPA_TEST_ERT_RUNNER (hint: add debian/run-tests.el).

In the worst case, if we can confirm that some of tests really do
require a tty (it would be good to figure out why -- maybe ask
upstream?), you can add a patch disabling those tests in particular.

> > It seems it wasn't enough.  If I move my .emacs.d out of the way and
> > then run it, and M-x evil-mode, I get this:
> >
> > Error in post-command-hook (evil-repeat-post-hook): (void-function 
> > evil-repeat-post-hook)
> > Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
> > evil-repeat-pre-hook)
> 
> Patched it. Check again.

Nice work.  Have you forwarded the fix upstream?

-- 
Sean Whitton

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> > 2. In d/copyright, I think you need to specify copyright years for the
> > copyright holders.  Just their names is not enough, since on a desert
> > island ~60 years from now with no newer versions of evil available for
> > download, the code would become public domain :) (well, I guess the
> > old version of the code would be public domain on the mainland too)
> > 
> > Unfortunately, upstream maintains only list of contributors. So seems
> > best thing we can do is to count 60 years from last debian upload.
> 
> I'm not sure whether this is likely to be acceptable to the ftp-masters
> or not.  Perhaps someone more experienced on debian-mentors can chime
> in.

Gianfranco, your opinion?

> > > 3. Any particular reason you are using gz and not xz compression in
> > >gbp.conf?  Also, it might be a good idea to check the tarball into
> > >git with pristine-tar so that a sponsor has exactly the same one (I
> > >generated my own for testing).
> > No. Moved to xz.
> I still don't see a pristine-tar branch :)

Do not understand. I alread have tarball content, as I downloaded
it at 'upstream/1.2.12'. What more we need?

> > 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
> >the tests for you, though you'll probably need to give it some hints.
> >See dh_elpa_test(1) for how to do this: basically, raise to compat
> >level 10 and then set DH_ELPA_TEST_* env vars.
> > 
> > Tests want tty on stdin. Added note and disabled tests. Any good
> > ideas, how to run them in background?

> It's unlikely that the tty issue is the problem: ERT tests are supposed
> to be runnable in batch mode.  Although perhaps evil is different.

> First, though, we need to fix your dh_elpa_test usage.  You don't need
> DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
> because it contains ERT test definitions.  Instead, you need to use
> DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
> Makefile does.

Here is script, that does same as dh_elpa_test:

emacs -batch -Q -L . --eval "(require 'evil)" -l package \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" \
  -f package-initialize \
  -L . \
  -l evil-tests.el \
  -l lib/ert.el \
  -L lib \
  -f evil-tests-initialize

It reports 22 failures. If I replace -batch with -nw, all tests
passes. So seems tty is really needed, but I do not understand why.

> > 5. Please add a d/watch.
> > 
> > Problem. Mercurial upstream repository, and tarballs are named not
> > after version, but after hashes. I fail to extract anything useful
> > from this page: [1]
> > 
> > [1] https://bitbucket.org/lyro/evil/downloads
> Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

Jakub Wilk found solution. Now we have another way to
get tarball.

> > > The function `evil-mode' doesn't seem to be properly autoloaded.
> > > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > > evil-mode is not available.  However, if I type M-x describe-function
> > > RET evil-mode RET it works.  Something is going wrong with the
> > > autoloading.
> >
> > I think I fixed it. Please, check.
>
> It seems it wasn't enough.  If I move my .emacs.d out of the way and
> then run it, and M-x evil-mode, I get this:
>
> Error in post-command-hook (evil-repeat-post-hook): (void-function 
> evil-repeat-post-hook)
> Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
> evil-repeat-pre-hook)

Patched it. Check again.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> * Dmitry Bogatov , 2016-06-27, 17:32:
> >Mercurial upstream repository, and tarballs are named not after 
> >version, but after hashes. I fail to extract anything useful from this 
> >page: [1]
> >
> >[1] https://bitbucket.org/lyro/evil/downloads

> This seems to work for me:
> version=3
> https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz

Thanks a lot. Pushed.

In general, do we have any script, that automates process of writing
watch files? Every time I need to write watch file for github, I
copy-and-paste from comments in /usr/bin/uscan.

If not, it may be useful addition to devscripts.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Dmitry Bogatov , 2016-06-27, 17:32:
Mercurial upstream repository, and tarballs are named not after 
version, but after hashes. I fail to extract anything useful from this 
page: [1]


[1] https://bitbucket.org/lyro/evil/downloads


This seems to work for me:

version=3
https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz

--
Jakub Wilk

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> 2. In d/copyright, I think you need to specify copyright years for the
> copyright holders.  Just their names is not enough, since on a desert
> island ~60 years from now with no newer versions of evil available for
> download, the code would become public domain :) (well, I guess the
> old version of the code would be public domain on the mainland too)
> 
> Unfortunately, upstream maintains only list of contributors. So seems
> best thing we can do is to count 60 years from last debian upload.

I'm not sure whether this is likely to be acceptable to the ftp-masters
or not.  Perhaps someone more experienced on debian-mentors can chime
in.

> > 3. Any particular reason you are using gz and not xz compression in
> >gbp.conf?  Also, it might be a good idea to check the tarball into
> >git with pristine-tar so that a sponsor has exactly the same one (I
> >generated my own for testing).
> 
> No. Moved to xz.

I still don't see a pristine-tar branch :)

> 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
>the tests for you, though you'll probably need to give it some hints.
>See dh_elpa_test(1) for how to do this: basically, raise to compat
>level 10 and then set DH_ELPA_TEST_* env vars.
> 
> Tests want tty on stdin. Added note and disabled tests. Any good
> ideas, how to run them in background?

It's unlikely that the tty issue is the problem: ERT tests are supposed
to be runnable in batch mode.  Although perhaps evil is different.

First, though, we need to fix your dh_elpa_test usage.  You don't need
DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
because it contains ERT test definitions.  Instead, you need to use
DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
Makefile does.

> 5. Please add a d/watch.
> 
> Problem. Mercurial upstream repository, and tarballs are named not
> after version, but after hashes. I fail to extract anything useful
> from this page: [1]
> 
> [1] https://bitbucket.org/lyro/evil/downloads

Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

> PS. Your email formatting is amazing. Thank you.

Thanks!  Plaintext e-mail is very efficient if you use it right.

On Mon, Jun 27, 2016 at 05:46:58PM +0300, Dmitry Bogatov wrote:
> 
> > The function `evil-mode' doesn't seem to be properly autoloaded.
> > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > evil-mode is not available.  However, if I type M-x describe-function
> > RET evil-mode RET it works.  Something is going wrong with the
> > autoloading.
> 
> I think I fixed it. Please, check.

It seems it wasn't enough.  If I move my .emacs.d out of the way and
then run it, and M-x evil-mode, I get this:

Error in post-command-hook (evil-repeat-post-hook): (void-function 
evil-repeat-post-hook)
Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
evil-repeat-pre-hook)

Does that happen for you if you move .emacs.d?  I'm actually testing on
Ubuntu 16.04 instead of Debian but it shouldn't be relevant.

-- 
Sean Whitton

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> The function `evil-mode' doesn't seem to be properly autoloaded.
> I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> evil-mode is not available.  However, if I type M-x describe-function
> RET evil-mode RET it works.  Something is going wrong with the
> autoloading.

I think I fixed it. Please, check.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

1. How about using the source package name "emacs-evil"?  I've been
   doing this for my packages where upstream's name is a very generic
   word (e.g. emacs-buttercup), but maybe evil is a significant enough
   package that it can just be "evil", I'm not sure.  Your judgement.

Renamed as evil-el

2. In d/copyright, I think you need to specify copyright years for the
   copyright holders.  Just their names is not enough, since on a desert
   island ~60 years from now with no newer versions of evil available
   for download, the code would become public domain :)  (well, I guess
   the old version of the code would be public domain on the mainland too)

Unfortunately, upstream maintains only list of contributors. So seems
best thing we can do is to count 60 years from last debian upload.

3. Any particular reason you are using gz and not xz compression in
   gbp.conf?  Also, it might be a good idea to check the tarball into
   git with pristine-tar so that a sponsor has exactly the same one (I
   generated my own for testing).

No. Moved to xz.

4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
   the tests for you, though you'll probably need to give it some hints.
   See dh_elpa_test(1) for how to do this: basically, raise to compat
   level 10 and then set DH_ELPA_TEST_* env vars.

Tests want tty on stdin. Added note and disabled tests. Any good
ideas, how to run them in background?

5. Please add a d/watch.

Problem. Mercurial upstream repository, and tarballs are named not
after version, but after hashes. I fail to extract anything useful
from this page: [1]

[1] https://bitbucket.org/lyro/evil/downloads

PS. Your email formatting is amazing. Thank you.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

One more thing:

The function `evil-mode' doesn't seem to be properly autoloaded.
I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
evil-mode is not available.  However, if I type M-x describe-function
RET evil-mode RET it works.  Something is going wrong with the
autoloading.

Generally with Debian's ELPA packages, the user should be able to just
M-x foo-mode RET but in this case that doesn't work.  Please investigate!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

control: tag -1 +moreinfo

Ha, I was typing this e-mail just as yours came in, Gianfranco :)

Hello Dmitri:

1. How about using the source package name "emacs-evil"?  I've been
   doing this for my packages where upstream's name is a very generic
   word (e.g. emacs-buttercup), but maybe evil is a significant enough
   package that it can just be "evil", I'm not sure.  Your judgement.

2. In d/copyright, I think you need to specify copyright years for the
   copyright holders.  Just their names is not enough, since on a desert
   island ~60 years from now with no newer versions of evil available
   for download, the code would become public domain :)  (well, I guess
   the old version of the code would be public domain on the mainland too)

3. Any particular reason you are using gz and not xz compression in
   gbp.conf?  Also, it might be a good idea to check the tarball into
   git with pristine-tar so that a sponsor has exactly the same one (I
   generated my own for testing).

4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
   the tests for you, though you'll probably need to give it some hints.
   See dh_elpa_test(1) for how to do this: basically, raise to compat
   level 10 and then set DH_ELPA_TEST_* env vars.

5. Please add a d/watch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#827907: RFS: evil/1.2.12-1 ITP

[Gianfranco Costamagna]

control: owner -1 spwhit...@spwhitton.name



yes, I did that ^^ :D

and I have *no* regrets :p

BTW I'm thrilled about bringing VIM to EMACS :D



>I am looking for a sponsor for my package "evil"
I think Sean can give a more appropriate review, but lets go:

"make" in rules --> $(MAKE) please

apt-get install -t experimental check-all-the-things

check-all-the-things:

some codespell typo reported

$ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect 
FSF address'
./lib/goto-chg.el: GPL (v2 or later) (with incorrect FSF address)


$ grep -riE 'fixme|todo|hack|xxx' .


I would like to see them reported upstream, they seem to be not bad enough to 
cherry Debian patches
(but well, if you want to patch, go ahead :p )

the other stuff looks good


one copyright issue
./lib/goto-chg.el: GPL (v2 or later) (with incorrect FSF address)

(note: gpl-v2)

thanks,

Gianfranco

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "evil"

* Package name: evil
  Version : 1.2.12-1
  Upstream Author : Vegard Øye 
* Url : https://bitbucket.org/lyro/evil/wiki/Home
* Licenses: GFDL-1.3+, GPL-3+
  Section : lisp

It builds those binary packages:

elpa-evil -- extensible vi layer for Emacs

To access futher information about this package, visit the following URL:

http://mentors.debian.net/package/evil

Alternatively, one can download the package with dget using this command:

http://mentors.debian.net/debian/pool/main/e/evil/evil_1.2.12-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil.git

More information about evil can be obtained from 
https://bitbucket.org/lyro/evil/wiki/Home

Changes since last upload:

  * Initial release. (Closes: #827897)

Regards,
  Dmitry Bogatov