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
Description: Digital signature
