Debian Bug report logs - #863216
ITP: emacs-ivy -- a generic completion frontend for Emacs

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Tue, 23 May 2017 20:22:19 +0100

[Message part 1 (text/plain, inline)]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves <nsteeves@gmail.com>

* Package name    : emacs-ivy
  Version         : 0.9.1
  Upstream Author : Oleh Krehel <ohwoeowho@gmail.com>
* URL             : https://github.com/abo-abo/swiper
* License         : GPL-3+
  Programming Lang: Emacs Lisp
  Description     : a generic completion frontend for Emacs

While upstream's git repo is called 'swiper', it's clear that the
overarching project has been renamed to 'ivy' -- see the releases
page.[1]

Filing this RFP and immediately converting to an ITP for Nicholas, who
is busy IRL but has 90% of the packaging in hand.

[1]  https://github.com/abo-abo/swiper/releases

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: Sean Whitton <spwhitton@spwhitton.name>, 863216@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Sun, 28 May 2017 14:27:04 -0400

[Message part 1 (text/plain, inline)]

Hi Sean,

On Tue, May 23, 2017 at 08:22:19PM +0100, Sean Whitton wrote:
> 
> While upstream's git repo is called 'swiper', it's clear that the
> overarching project has been renamed to 'ivy' -- see the releases
> page.[1]
> 
> Filing this RFP and immediately converting to an ITP for Nicholas, who
> is busy IRL but has 90% of the packaging in hand.
> 
> [1]  https://github.com/abo-abo/swiper/releases

Thank you for filing this on my behalf :-)  I've pushed a preliminary
package to ssh://git.debian.org/git/pkg-emacsen/pkg/emacs-ivy.git

Unfortunately one test fails:
...
Running 16 tests (2017-05-28 13:30:14-0400)
Test colir-color-parse backtrace:
  (let ((fn-220 (function equal)) (args-221 (list (colir-color-parse "
  (lambda nil (let ((fn-220 (function equal)) (args-221 (list (colir-c
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test colir-color-parse nil (lambda nil (
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test c
  ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test colir-color-parse condition:
    (void-function colir-color-parse)
   FAILED   1/16  colir-color-parse
...
dh_elpa_test: emacs -batch -Q -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
ivy-test.el --eval (ert-run-tests-batch-and-exit) returned exit code 1
debian/rules:4: recipe for target 'build' failed make: *** [build]
Error 2 dpkg-buildpackage: error: debian/rules build gave error exit
status 2

The test in question is around L210 of ivy-test.el.  If I manually
load-file colir.el and eval-expression (colir-color-parse "#ab1234")
with emacs25, it returns the correct triplet as a list, so I'm not
sure where the problem is or how to proceed.  Commenting out
autopkgtest-pkg-elpa in d/control doesn't seem to help.  Any advice
for debugging this with greater verbosity, since my
ignorance/inexperience is preventing further progress on this ITP?
Not installing ivy-test.el seems sloppy...

Cheers,
Nicholas

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Nicholas D Steeves <nsteeves@gmail.com>

Cc: 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Sun, 28 May 2017 21:54:24 +0100

[Message part 1 (text/plain, inline)]

Hello Nicholas,

On Sun, May 28, 2017 at 02:27:04PM -0400, Nicholas D Steeves wrote:
> Test colir-color-parse condition:
>     (void-function colir-color-parse)
>    FAILED   1/16  colir-color-parse
> ...
> dh_elpa_test: emacs -batch -Q -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
> ivy-test.el --eval (ert-run-tests-batch-and-exit) returned exit code 1
> debian/rules:4: recipe for target 'build' failed make: *** [build]
> Error 2 dpkg-buildpackage: error: debian/rules build gave error exit
> status 2
> 
> The test in question is around L210 of ivy-test.el.  If I manually
> load-file colir.el and eval-expression (colir-color-parse "#ab1234")
> with emacs25, it returns the correct triplet as a list, so I'm not
> sure where the problem is or how to proceed.  Commenting out
> autopkgtest-pkg-elpa in d/control doesn't seem to help.  Any advice
> for debugging this with greater verbosity, since my
> ignorance/inexperience is preventing further progress on this ITP?
> Not installing ivy-test.el seems sloppy...

I think it's just a missing (require 'colir) at the top of ivy-test.el.
You could patch it in, or since upstream might not be willing to merge
such a patch, use in d/elpa-test:

    ert_eval = (load-file "colir.el")

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: Sean Whitton <spwhitton@spwhitton.name>, 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Mon, 29 May 2017 14:53:57 -0400

[Message part 1 (text/plain, inline)]

Hi Sean,

On Sun, May 28, 2017 at 09:54:24PM +0100, Sean Whitton wrote:
> On Sun, May 28, 2017 at 02:27:04PM -0400, Nicholas D Steeves wrote:
>
> > The test in question is around L210 of ivy-test.el.  If I manually
> > load-file colir.el and eval-expression (colir-color-parse "#ab1234")
> > with emacs25, it returns the correct triplet as a list, so I'm not
> > sure where the problem is or how to proceed.  Commenting out
> > autopkgtest-pkg-elpa in d/control doesn't seem to help.  Any advice
> > for debugging this with greater verbosity, since my
> > ignorance/inexperience is preventing further progress on this ITP?
> > Not installing ivy-test.el seems sloppy...
> 
> I think it's just a missing (require 'colir) at the top of ivy-test.el.
> You could patch it in, or since upstream might not be willing to merge
> such a patch, use in d/elpa-test:
> 
>     ert_eval = (load-file "colir.el")

Thanks for the tip, that did the trick.  I added a quilt patch, marked
it as Forwarded: No; although, I plan to submit it upstream.  When a
"locally modified source" error appeared and I diffed against upstream
release tag I noticed that upstream seems to accept this type of
patch, so I remain optimistic that they'll accept this one when it is
forwarded.  As for:

E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.org
E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.texi

I'd like to generate a non-free emacs-ivy-doc package for these, so
long as there isn't a pkg-emacsen policy that prevents this.  IIRC,
DFSG-free packages cannot recommend non-free ones, but can they
suggest non-free ones?  Also, when I adopted src:muse-el I noticed
that the previous author had stripped GFDL docs, and I forget if
they're permitted in Alioth git repos.  If they're not I'm going to
have to remove them, rebase, and force push...and either learn how to
exclude them when using a upstream-in-git workflow, or switch back to
using github-generated tarball releases (and repack as a
dfsg-versioned package).  Worst-case scenario, I guess I can maintain
a local non-dfsg-free branch that only generates the docs...

Other than this, I'm perplexed by the following, because I thought
that dependencies would recurse, eg: elpa-swiper depends on elpa-ivy,
which has ${elpa:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8):

W: emacs-ivy source: debhelper-but-no-misc-depends elpa-swiper
W: emacs-ivy source: debhelper-but-no-misc-depends elpa-counsel
W: emacs-ivy source: debhelper-but-no-misc-depends elpa-ivy-hydra

Cheers,
Nicholas

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Nicholas D Steeves <nsteeves@gmail.com>

Cc: 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Tue, 30 May 2017 07:53:51 +0100

[Message part 1 (text/plain, inline)]

Dear Nicholas,

On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote:
> E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.org
> E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.texi
> 
> I'd like to generate a non-free emacs-ivy-doc package for these, so
> long as there isn't a pkg-emacsen policy that prevents this.

There isn't.

> IIRC, DFSG-free packages cannot recommend non-free ones, but can they
> suggest non-free ones?

This sounds sensible but it's not in Policy.

> Also, when I adopted src:muse-el I noticed that the previous author
> had stripped GFDL docs, and I forget if they're permitted in Alioth
> git repos.

Don't worry.  It's fine for them to be on alioth.

> Other than this, I'm perplexed by the following, because I thought
> that dependencies would recurse, eg: elpa-swiper depends on elpa-ivy,
> which has ${elpa:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8):
> 
> W: emacs-ivy source: debhelper-but-no-misc-depends elpa-swiper
> W: emacs-ivy source: debhelper-but-no-misc-depends elpa-counsel
> W: emacs-ivy source: debhelper-but-no-misc-depends elpa-ivy-hydra

The dependencies do recurse but debhelper might need to add different
entries to ${misc:Depends} for different binary packages -- it is not
able to look down the dependency graph and insert those entries into the
${misc:Depends} of a different binary package.  So you need to add it to
all of them.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Nicholas D Steeves <nsteeves@gmail.com>, 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Tue, 30 May 2017 08:12:34 +0100

[Message part 1 (text/plain, inline)]

On Tue, May 30, 2017 at 07:53:51AM +0100, Sean Whitton wrote:
> On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote:
> > IIRC, DFSG-free packages cannot recommend non-free ones, but can they
> > suggest non-free ones?
> 
> This sounds sensible but it's not in Policy.

... but it is in the upcoming Policy 4.0.0 that packages should Suggest
their -doc packages.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: Sean Whitton <spwhitton@spwhitton.name>, 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Thu, 8 Jun 2017 18:14:53 -0400

[Message part 1 (text/plain, inline)]

Hi Sean,

On Tue, May 30, 2017 at 07:53:51AM +0100, Sean Whitton wrote:
> Dear Nicholas,
> 
> On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote:
> > E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.org
> > E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.texi
> > 
> > I'd like to generate a non-free emacs-ivy-doc package for these, so
> > long as there isn't a pkg-emacsen policy that prevents this.
> 
> There isn't.
> 
> > IIRC, DFSG-free packages cannot recommend non-free ones, but can they
> > suggest non-free ones?
> 
> This sounds sensible but it's not in Policy.
> 
> > Also, when I adopted src:muse-el I noticed that the previous author
> > had stripped GFDL docs, and I forget if they're permitted in Alioth
> > git repos.
> 
> Don't worry.  It's fine for them to be on alioth.

I've renamed emacs-ivy/master to emacs-ivy/master-nonfree, and pushed
and renamed new master and upstream branches that automatically strip
out the non-DFSG stuff when uscan is run--using upstream tarball,
because that's what I'm familiar with rather than a git-based
Files-Excluded work-flow.  HEAD still points to master-nonfree.  Do you
think the following is the best course of action?:

Rename master-nonfree to something that better signifies it's only
used for merging (from upstream git remote) upstream docs; document
this somehow (README.sources? In both branches, or just in one of
them?); maybe drop upstream-nonfree, strip out all non-docs from
newname-for-master-nonfree, and build the non-free emacs-ivy-docs
orig.source using deborig?  This orig.source seems like it only needs
to contain the emacs-ivy/docs subdir.  Finally, debian/* on the
newname-for-master-nonfree branch would need to be modified.

At this point I don't think that the change in the git repo will
affect more than three people...and maybe git does something magical
and automatic that makes it a non-issue?

> > Other than this, I'm perplexed by the following, because I thought
> > that dependencies would recurse, eg: elpa-swiper depends on elpa-ivy,
> > which has ${elpa:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8):
> > 
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-swiper
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-counsel
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-ivy-hydra
> 
> The dependencies do recurse but debhelper might need to add different
> entries to ${misc:Depends} for different binary packages -- it is not
> able to look down the dependency graph and insert those entries into the
> ${misc:Depends} of a different binary package.  So you need to add it to
> all of them.

Thanks! :-)  Fixed.

On 30 May 2017 at 03:12, Sean Whitton <spwhitton@spwhitton.name>
wrote:
> On Tue, May 30, 2017 at 07:53:51AM +0100, Sean Whitton wrote:
>> On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote:
>> > IIRC, DFSG-free packages cannot recommend non-free ones, but can they
>> > suggest non-free ones?
>>
>> This sounds sensible but it's not in Policy.
>
> ... but it is in the upcoming Policy 4.0.0 that packages should
> Suggest
> their -doc packages.

Oh wow.  I wonder if this will reignite the GFDL debate...  In the
case of emacs-ivy-doc the main issues are something to the affect of
"This is a GNU manual" front cover and "This document can be freely
distributed and modified" back cover...but after having learned that
GNU licenses are only valid in English, the back cover doesn't seem
like an issue to me.  That said, it is mildly troubling that the front
cover must always be in English (and only in English) and cannot be
modified to be more informative...

Cheers,
Nicholas

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Nicholas D Steeves <nsteeves@gmail.com>

Cc: 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Fri, 9 Jun 2017 15:18:40 +0100

[Message part 1 (text/plain, inline)]

Hello Nicholas,

On Thu, Jun 08, 2017 at 06:14:53PM -0400, Nicholas D Steeves wrote:
> Do you think the following is the best course of action?:
> 
> Rename master-nonfree to something that better signifies it's only
> used for merging (from upstream git remote) upstream docs; document
> this somehow (README.sources? In both branches, or just in one of
> them?); maybe drop upstream-nonfree, strip out all non-docs from
> newname-for-master-nonfree, and build the non-free emacs-ivy-docs
> orig.source using deborig?  This orig.source seems like it only needs
> to contain the emacs-ivy/docs subdir.  Finally, debian/* on the
> newname-for-master-nonfree branch would need to be modified.

Renaming branches is equivalent to rewinding history, so please avoid
that.

We're going to need two source packages, so I think we should have two
repos, organised like this:

emacs-ivy-doc -- just 'master' branch

emacs-ivy -- 'upstream' branch with cleaned sources, 'master' branch
including debian/ dir

--
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: Sean Whitton <spwhitton@spwhitton.name>, 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Fri, 9 Jun 2017 16:24:33 -0400

[Message part 1 (text/plain, inline)]

Hello Sean,

On Fri, Jun 09, 2017 at 03:18:40PM +0100, Sean Whitton wrote:
> 
> Renaming branches is equivalent to rewinding history, so please avoid
> that.
> 
> We're going to need two source packages, so I think we should have two
> repos, organised like this:
> 
> emacs-ivy-doc -- just 'master' branch
> 
> emacs-ivy -- 'upstream' branch with cleaned sources, 'master' branch
> including debian/ dir

Thanks again for the help :-) Emacs-ivy currently has a master-dfsg
branch created by copying the debian/* from master to the imported
upstream-dfsg source.  I've renamed upstream-dfsg to upstream.
Unfortunately I didn't 'git checkout master -- debian' from within the
master-dfsg branch, so when I merged master-dfsg to master I had to
allow unrelated histories and the end result is messier than I'd like.

The emacs-ivy-doc repo is going to be easier because I can rebase as
necessary before the initial push.  Would you like to see all the docs
in emacs-ivy-doc, or only the two non-free ones?

By the way, how soon do we (as pkg-emacsen) have to implement policy
12.4, and can you provide an example of the style we're going to use?
Do we also provide the .org and .md markdown files or convert
everything using pandoc and install that?

Sincerely,
Nicholas

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: Nicholas D Steeves <nsteeves@gmail.com>, 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Sat, 10 Jun 2017 07:39:26 +0100

[Message part 1 (text/plain, inline)]

Hello Nicholas,

Nicholas D Steeves <nsteeves@gmail.com> writes:

> The emacs-ivy-doc repo is going to be easier because I can rebase as
> necessary before the initial push.  Would you like to see all the docs
> in emacs-ivy-doc, or only the two non-free ones?

This is up to your judgement.  If they are very small, it might be
better to have them in the main archive.

> By the way, how soon do we (as pkg-emacsen) have to implement policy
> 12.4, and can you provide an example of the style we're going to use?

I don't think that anyone on the team has done any work on this.  Feel
free to take the initiative, if it interests you.

> Do we also provide the .org and .md markdown files or convert
> everything using pandoc and install that?

I would say that the HTML alone would be enough.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 863216@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: Sean Whitton <spwhitton@spwhitton.name>

Cc: 863216@bugs.debian.org

Subject: Re: Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

Date: Sun, 11 Jun 2017 17:00:26 -0400

[Message part 1 (text/plain, inline)]

Hi Sean,

On Sat, Jun 10, 2017 at 07:39:26AM +0100, Sean Whitton wrote:
> Hello Nicholas,
> 
> Nicholas D Steeves <nsteeves@gmail.com> writes:
> 
> > The emacs-ivy-doc repo is going to be easier because I can rebase as
> > necessary before the initial push.  Would you like to see all the docs
> > in emacs-ivy-doc, or only the two non-free ones?
> 
> This is up to your judgement.  If they are very small, it might be
> better to have them in the main archive.

Hmm...  I'm going to have to investigate this some more.  From what
I've read, the info pages (and optionally the man pages) are intended
to be built from those non-free sources.  This makes it seem like
emacs-ivy-doc should contain the bulk of the documentation; however,
there is one exception that ivy.el references.

> > By the way, how soon do we (as pkg-emacsen) have to implement policy
> > 12.4, and can you provide an example of the style we're going to use?
> 
> I don't think that anyone on the team has done any work on this.  Feel
> free to take the initiative, if it interests you.

Maybe later? :-)  At this point in time I'd like to focus on my RFPs
and ITPs.  It's something that will need to be done, but it seems a
bit early still.

> > Do we also provide the .org and .md markdown files or convert
> > everything using pandoc and install that?
> 
> I would say that the HTML alone would be enough.

Hmm, I've decided to strip documentation from emacs-ivy for now,
because I recently read (on debian-devel) that html documentation is
supposed to go in the -doc package and not the primary package.  If,
as I wait for the conversation to develop on -devel, a user files a
request for documentation bug, then I'll rename it as an ITP for
emacs-ivy-doc and will have to prioritise all of this.

Cheers,
Nicholas

P.S. The git repo is an a reasonable state and I think it might be
time for a preliminary RFS.

[signature.asc (application/pgp-signature, inline)]

Message #69 received at 863216-close@bugs.debian.org (full text, mbox, reply):

From: Nicholas D Steeves <nsteeves@gmail.com>

To: 863216-close@bugs.debian.org

Subject: Bug#863216: fixed in emacs-ivy 0.9.1+dfsg-1

Date: Sat, 05 Aug 2017 01:00:13 +0000

Source: emacs-ivy
Source-Version: 0.9.1+dfsg-1

We believe that the bug you reported is fixed in the latest version of
emacs-ivy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 863216@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nicholas D Steeves <nsteeves@gmail.com> (supplier of updated emacs-ivy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


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

Format: 1.8
Date: Fri, 23 Jun 2017 13:41:41 -0400
Source: emacs-ivy
Binary: elpa-ivy elpa-swiper elpa-counsel elpa-ivy-hydra
Architecture: source all
Version: 0.9.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Emacs addons team <pkg-emacsen-addons@lists.alioth.debian.org>
Changed-By: Nicholas D Steeves <nsteeves@gmail.com>
Description:
 elpa-counsel - Collection of Ivy-enhanced versions of common Emacs commands
 elpa-ivy   - Generic completion mechanism for Emacs
 elpa-ivy-hydra - Additional key bindings for Emacs Ivy
 elpa-swiper - Alternative to Emacs' isearch with an overview
Closes: 863216
Changes:
 emacs-ivy (0.9.1+dfsg-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #863216)
   * Add 0001-Prevent-void-function-colir-color-parse-in-ivy-test.patch
     - Needed for self-tests to succeed
   * debian/copyright: Exclude non-free GFDL docs (doc/ivy.org and
     doc/ivy.texi)
Checksums-Sha1:
 c88e7de3e008bc5e9b69099b1c33461d6f696238 2194 emacs-ivy_0.9.1+dfsg-1.dsc
 79a2bb205fea63b66a3ab920b0ef9bea73582109 82564 emacs-ivy_0.9.1+dfsg.orig.tar.xz
 0b1639451e1040d3c553262bcfe521129eeb3f17 3440 emacs-ivy_0.9.1+dfsg-1.debian.tar.xz
 2de419347b144e3baa16195840cb5c17f63a5d39 54420 elpa-counsel_0.9.1+dfsg-1_all.deb
 088dd80276bdfba2fc13812f4266e92fd75acfc7 28622 elpa-ivy-hydra_0.9.1+dfsg-1_all.deb
 d57b9f165570e76a5e15c2f43e9ea71cf95e8f87 60130 elpa-ivy_0.9.1+dfsg-1_all.deb
 49da0d219e700a7ef366a588aa63f0aefe052626 35110 elpa-swiper_0.9.1+dfsg-1_all.deb
 fe784a86b533a180a91c177ec9a5f1da98f0dee3 8519 emacs-ivy_0.9.1+dfsg-1_amd64.buildinfo
Checksums-Sha256:
 ce1bcecb2e14cce9d5f781134e779a0911b16ea0bbfe2ec41886e32a289aae2f 2194 emacs-ivy_0.9.1+dfsg-1.dsc
 f575f19e8cee206962b547141415a4776d5b6a143b2262e69e8ecd66d5883d4a 82564 emacs-ivy_0.9.1+dfsg.orig.tar.xz
 b3e6fef187b4ffed747d7e67e5d66fa7be5558ba89ce9b173287da0578a67d7b 3440 emacs-ivy_0.9.1+dfsg-1.debian.tar.xz
 7c34dfbd5acd17c36c60d0c1cbd2c16aba0a7fcd692547396aac80a595d8ebf3 54420 elpa-counsel_0.9.1+dfsg-1_all.deb
 c39dfd6a1058c6e319e15bb070fb2e6fc126f693c4aef9182861ffa685f7fb93 28622 elpa-ivy-hydra_0.9.1+dfsg-1_all.deb
 cb7cf90a268d2b637084af5b7259ae42e193b2f8e85d6de71c730fec3bbb5fa1 60130 elpa-ivy_0.9.1+dfsg-1_all.deb
 8aaa2fb30c2328f21ebed7c284d8d6b90295742f6c9bb2a9eb4d23ca7a44a0cf 35110 elpa-swiper_0.9.1+dfsg-1_all.deb
 436c883036056657c3e43968407452801d8668b3996b641260171d7593223277 8519 emacs-ivy_0.9.1+dfsg-1_amd64.buildinfo
Files:
 65367db603029e5b476a3eb2e3072e15 2194 lisp optional emacs-ivy_0.9.1+dfsg-1.dsc
 8f951039476de2d2274dbc4d7aa39206 82564 lisp optional emacs-ivy_0.9.1+dfsg.orig.tar.xz
 f19b149fdb86ebc270cb7728e79eee13 3440 lisp optional emacs-ivy_0.9.1+dfsg-1.debian.tar.xz
 28c816fcd536a919ae95e8e77c7785a3 54420 lisp optional elpa-counsel_0.9.1+dfsg-1_all.deb
 bc3f7b210efb44a76a6043251e8537e7 28622 lisp optional elpa-ivy-hydra_0.9.1+dfsg-1_all.deb
 457be3760d9c29ef7ecf045f391e1cdc 60130 lisp optional elpa-ivy_0.9.1+dfsg-1_all.deb
 2fff118e7bd9bbdccfabe751707a4c53 35110 lisp optional elpa-swiper_0.9.1+dfsg-1_all.deb
 10f62f4390c55ab6a5f0e92e92be0450 8519 lisp optional emacs-ivy_0.9.1+dfsg-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjckBzmQUbASK1Q+7eSFSUnt1kh4FAlmE/zQACgkQeSFSUnt1
kh4Cqw//ZNP/DWbq3+l/r9xtBJ+gxByRI0kdDSNkZM1j8sPdwu36jbJ/sMuBJN6u
LtARHcGbtnRcVo9c8OMoECXyr9+TqrEPcJ9+ul1LS/WGTD2AV8U7fGW3TVvkVv8o
iKm+vEge6THHCiu36Y59OUtkHbG9GpvvRHnC3UCd2asCMKUOpRqdbSnZusROloq0
enXKwfEwJe0vIoRQzuhnU5VlOQYJSsfGUldUoylKxRktuaI3ZAyHcpxZr+KutEIy
byN7Nr8ubk588obyar5Zqhv5afNbMJNOw7RiGoPMN4EbWZiwW8zctZvXz5JhZH5l
1RceAqaZTi2GuFo9gyuo7wctXtcg5+N4LX8Qv4ZiJ4FgAPDFf0ku6RD1isvJXmne
RqyemGOAllZfKl8DKLiHtX/nqOkU5bkZmfxQ0TGRpVtSysH8q9Hpk6Z5G286pbsX
/KKNMs8/lsLRo7h1pQwH9nZPCM41WLY02/sfedQC1QU3imIyeYZNBC+ZTER00sgy
KWu9kVyjwXFOv6nJdIuV66FXU5//PigspgvHgjZMf1w2G0FdLQZb/pDKweZL/HGP
BhT9JarKh8Yfd7caui5IFYQE8wz8kpmLZWa+/0eHrZcpos3B3kpj58C0UkBEyH3A
QtBfJF68Hf+qme6QSqidmiEigC4ooZASz6DmkIeMuQm1aJqooTw=
=0IJB
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.