Well, vala-mode-el 0.1-2 was uploaded and in unstable on 5-Nov-2014, so
this version has had some shaking down. No issues have been noted. I
let it rest a bit before marking the bug as done, even though I was
pretty sure it was fixed, because I wanted to be positive there weren't
any latent problem in the lexical lambda stuff.
I could revert some of the non-critical tweaks, like spelling
corrections in comments or updated URLs, but that seems silly.
>> diff -Nru vala-mode-el-0.1/debian/patches/debian-changes
>> vala-mode-el-0.1/debian/patches/debian-changes
>> --- vala-mode-el-0.1/debian/patches/debian-changes 1970-01-01
>> 01:00:00.000000000 +0100
>> +++ vala-mode-el-0.1/debian/patches/debian-changes 2014-12-17
>> 14:23:05.000000000 +0000
The debian mods are maintained in git. 0.1-1 had no changes outside
debian/*. In 0.1-2 there is *one* change outside debian/*, made in a
single git commit, and it fixes the emacs24 compatibility issue.
If I were to manually put that in a quilt patch, instead of allowing the
build system to generate said patch automatically, the patch would be
identical to the above. Well, aside from the officious automatically
generated header.
I.e., either way it ends up as a single quilt patch. That's why I
turned on the single-debian-patch option.
But if you want me to turn it into a "real" quilt patch, I will!
There are three "functional" patches.
>> + * Patch away `(lambda ... ,foo ...) ickiness (closes: #702714)
>
> This is the bug fix, right?
(1) Correct. The "lexical lambdas" patch to vala-mode.el is needed for
emacs24 compatibility.
>> +++ vala-mode-el-0.1/debian/emacsen-compat 2014-12-17
>> 12:42:26.000000000 +0000
>> @@ -0,0 +1 @@
>> +0
>
> This isn't mentioned in the changelog, unless I missed it. (Neither emacs
> nor vala are in my strong set.)
(2) Without this "echo 0 > debian/emacsen-compat" the package is not in
conformance with current Debian emacsen policy, and gives a
horrendous-sounding (albeit in truth harmless) message upon
installation:
ERROR: vala-mode-el is broken - called emacs-package-install as a
new-style add-on, but has no compat file.
The "0" is telling emacsen-common to use the "new style" stuff.
Which it uses anyway. So the only effect is eliminating the above
scary message.
Its omission in 0.1-1 was basically a typo.
>> + * Add support to use C# semantics when ECB and CEDIT are both installed
>
> This sounds like a feature?
(3) ECB + wisent-csharp co-activation support, in
debian/emacsen-startup. This is (a) recommended by upstream, and
(b) cannot activate without the installation of third-party (i.e.,
not packaged by Debian) software that defines wisent-csharp.
This is a convenience measure for people who use ECB + said
third-party wisent-csharp software: they would otherwise be annoyed
and have to spend an hour figuring out what's missing from the
package integration code and how to fix it.
I think that covers everything.
I do understand not wanting to perturb testing unnecessarily, but this
stuff is really about as innocuous as anything could possibly be. The
*only* even potentially non-innocuous thing is the emacs24-compatibility
lexical lambda business.
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
