Bug#827907: RFS: evil/1.2.12-1 ITP
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 <KAction@gnu.org>, 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
Reply to: