| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
In the best case, if autoscript_sed becomes public, we need a versioned
build depends on debhelper. Anyway, we can always go this way in the
future.
|
| |
|
|
| |
make more robust, fix name error, fix chmod error
|
| |
|
|
|
| |
somehow passing back a ref and using a local file handle both contained
silly bugs
|
| | |
|
| |
|
|
| |
It's a hack, but let's at least use the same hack everywhere.
|
| |
|
|
|
|
|
| |
This file is in pseudo-RFC822 form; it is a fatal error if emacs didn't
create it.
Currently this calls an unexported sub from Dh_Lib
|
| |
|
|
|
| |
We want to grab the description file from emacs also for single file
packages.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The elisp code dies mysteriously if it isn't there
|
| |
|
|
| |
This produces more standard looking messages
|
| | |
|
| |
|
|
|
| |
This is a suggestion of Nils Thykier, to avoid adding special handling
for keeping temporary files. This is removed by dh_clean.
|
| |
|
|
| |
Thanks lintian!
|
| |
|
|
|
|
| |
dh-elpa.el needs to be loaded from the "never-byte-compiled" path, but
other packages might need to be loaded from the
"not-yet-byte-compiled" path"
|
| |
|
|
|
|
| |
This means no fancy predepends are needed because we just copy the
scripts in at build time. Of course bug fixes for the helper scripts
require package rebuilds.
|
| |
|
|
|
| |
In particular --no-byte-compile allows building dh-elpa without
worrying about where to find the maintainer script helpers.
|
| |
|
|
| |
The tarball creation is reasonably well tested at this point.
|
| |
|
|
|
|
|
| |
My initial plan to have both the generic install and the bytecompiled
version in different places in package-directory-list didn't work out,
so move the non-bytecompiled version out of the default
package-directory-list.
|
| | |
|
| |
|
|
| |
Hopefully I'm doing this "read back the temp file" thing correctly
|
| |
|
|
| |
This is probably not the best solution, but it works for now.
|
| |
|
|
| |
A refined version of this should perhaps be pushed into debhelper.
|
| |
|
|
| |
Still no byte compilation, and grotesque amounts of output
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out this isn't $MESSY_CONFLICT_ZONE, there are rules about
writing debhelper extensions.
This is mainly cargo culting from dh_installdocs.
- compute destination directory, support multiple binary packages.
- add debian/elpa file, test the "standard" codepath. Still not very
standard because it's a single file elpa package.
|
| |
|
|
| |
This would all be easier if I didn't insist on using emacs -Q
|
| |
|
|
|
| |
Since the whole point of this package is to simplify other packages,
try to set a good example.
|
| |
|
|
|
| |
This is not the most elegant solution in the world, but impovements
only need to change this package's debian/rules.
|
|
|
Scripts using emacs lisp require wizard level hackishness to get
execed. Let's do things the simple way.
|
