I have prepared a 6.5.5-1.1 NMU based on Punit and Volker's updated packaging and curent upstream 6.5.5 tarball. This is uploaded to experimental as a 5-day delayed NMU. It should be available to test from 30th Nov.
There are quite a few collected changes:
[ Punit Agrawal ]
* Switch to dpkg-source 3.0 (quilt) format
Split diff into individual patches by functionality.
* Add watch file
* Migrate local changes to latest upstream version - 6.2.11
Drop globash patch as it seems to be integrated with upstream
Drop alternate compressed suffix functionality for htags
* Update debian/rules in line with 6.2.11
* Update debian/global.manpages for 6.2.11
* Fix an error encountered while installing gtags.el
* Add debian/emacsen-compat
* Fix lintian warning debian-rules-ignores-make-clean
* Fix lintian warning debian-rules-missing-recommended-target
* Replace deprecated dh_clean -k with dh_prep in debian/rules
[ Javi Merino ]
* Build-depend on libncurses5-dev, as global requires curses
[ Punit Agrawal ]
* Fix lintian warning script-not-executable
* New upstream release - 6.2.12
* Add links to global and the package repository
[ Volker Mische ]
* Install plugins from plugin-factory
* Update to upstream release - 6.3.2
[ Wookey ]
* Non-maintainer upload.
* Update to new upstream release - 6.5.5
* Add missing emacsen-common build-dep
* Remove obsolete dpkg|install-info dependency
* Bump standards to 3.9.6
* Use system libltdl instead of embedded one
* Ensure cgi scripts are regenerated to set perl path correctly
* Recommend python for pygments support
Known issues:
* This version still includes Ron's htmake patch, but it probably needs
adjusting to work properly with the current codebase.
* The two .cgi scripts in htags/ were not cleaned by upstream, and are
shipped in the tarball (despite being generated from .cgi.in files,
which means that they didin't get their perl shebang paths set
correctly (they are left with the /opt/local/bin/perl they ship with)
I tried to do this as an upstream-ready patch
0004-Regenerate-cgi-scripts.patch to adjust the htags/Makefile.am to ensure
that these two did get cleaned.
Setting: CLEANFILES = global.cgi completion.cgi
in htags/Makefile.am seems like it might be the right thing to cause them to
be cleaned
but of course that's not in Makefile.in unless we autoreconf.
Autoreconfing didn't work (see below), so I just patched Makefile.in
as well as Makefile.am. But that still didn't work (is 'CLEANFILES'
the wrong thing?), so I just cleaned those two files in debian/rules
(which does work).
It would be nice to do this properly with an upstreamble fix.
* Lintian pointed out that libltdl is embedded. Fixing that was not
too hard, but the existence of /libltdl interacts unhelpfully with
reautoconfig (see below).
Just removing 'libltdl' from the subdirs list in Makefile.am seems
to fix things, although I think a proper fix should also change the
macros in configure.ac:
LT_CONFIG_LTDL_DIR, LT_INIT, LTDL_INIT
In fact is there any point using libtool at all? In my experience it
does nothing useful on a modern system but makes things complicated.
I'm not actually sure what libltdl is for. It's a loader, but libc
already has one of those. I guess this is a question for upstream.
* Reautoconfing
Reautoconfing is good policy and recommended in Debian (see
https://wiki.debian.org/Autoreconf). It also should mean that we
just have to make tiny patches to .ac/.am files for the 'htags/.cgi
cleaning' and 'use system libltdl' then regenerate stuff and
everything is done properly and we know it is all built from
source. However I was not able to get this to work.
I tried using dh_autoreconf to regenerate Makefile.in from
Makeilfe.am but the build fails because libtoolise carefully
replaces the shipped /libltdl with a new copy, and then dpkg-source
complains that a load of files have changed.
So then I tried removing /libltdl to shut dpkg up, as we are not
using it anyway. This works to get a build, but now we can only do
one build, not a second, because the second autoreconf fails because
/libltdl/Makefile.am gets
ACLOCAL_AMFLAGS = -I m4
changed to
ACLOCAL_AMFLAGS = -I ../m4
so now the first aclocal that autoreconf runs fails (because there is
an m4 dir but no ../m4 directory. This is beyond my autofoo competence
now. I have no idea why that's happening, nor what the right way to
fix it is.
At this point I gave up with reautoconfing, and just did a
dh_autotools-dev_update to ensure that config.{sub,guess} are up to
date.
* I've not updated any docs, and that should be done, depending on
what we do about htmake vs using upstream's recommended 'just run a
local python webserver on port 8000, if you want to expose an
indexed source's htags over http'. This is simple and works:
gtags
htags -D
cd HTML
python -m CGIHTTPServer
then browse to http://localhost:8000
(CGIHTTPServer is supplied in libpython2.7-stdlib which is pulled
in by the 'python' recommends.)
That's all I've noticed. Do please test when it hits experimental.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
