Bug#827907: RFS: evil/1.2.12-1 ITP
> 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.
Removed. Nice hint, cut build time.
> 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.
Okay. Probably worth make some scripting.
> > 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.
Ah, found it. Should be there.
> > Here is script, that does same as dh_elpa_test:
> > [...]
> > 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 ;)
Well, I was not explicit enough.
> 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.
Simple. Replace in upstream Makefile -nw with -batch and get 22 failures.
So I think we should accept it -- no tests for us.
> 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, but not as interactive. Status-quo. Usually
it is okay, since evil-mode is enabled once in .emacs and forever.
* evil-mode is autoloaded, interactive, but without sane description.
Ugly.
* evil mode is autoloaded, interactive and with sane description. Ugliness
in code.
* move definition of evil-mode from evil-core.el to evil.el. Ugly code.
--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io
Reply to: