Rob Browning writes:
> And finally, we'd like to remove emacs24 from the archive as soon as
> it's feasible, so please try to upgrade to emacs25, or add optional
> support for emacs25 as soon as you can.
>
> For example, assuming the package works with emacs25, a depe
Bill Allombert writes:
> The transition freeze was the 5 of November, so I suggest you ask the
> opinion of the release team before proceeding.
Done, and thanks. (Message presenting the situation sent to
debian-release and debian-emacsen.)
--
Rob Browning
rlb @defaultvalue.o
as-is, but now that we've resolved the emacs25
stability issues, having to support emacs24 throughout stretch is an
outcome we'd all be better off avoiding if we can.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E
does matter (or might matter in the future), then the
dependency should probably look more like this:
emacs25-nox | emacs25 | emacs24
This will have the buildds use the lighter-weight emacs25-nox flavor,
but will allow any emacs24 or emacs25 flavor already installed to
satisfy the dependency (si
ble, so please try to upgrade to emacs25, or add optional
support for emacs25 as soon as you can.
For example, assuming the package works with emacs25, a dependency like
emacs25-nox | emacs25 | emacs24
should suffice.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 20
?
$ dpkg --listfiles emacs24-el | fgrep .el | xargs zfgrep export-as-ascii
...
/usr/share/emacs/24.4/lisp/org/ox-ascii.el.gz:(defun org-ascii-export-as-ascii
If so, suppose you might need a (require 'ox-ascii) if it's not already
available.
--
Rob Browning
rlb @defaultvalue.org and
, mipsel, powerpc, s390x, sparc
emacs23-nox | 23.4+1-4.1+b1 | amd64, armel, armhf, i386, kfreebsd-amd64,
kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
Maintainer: Rob Browning
--- Reason ---
--
Checking reverse
Gabriele Giacone <1o5g4...@gmail.com> writes:
> mass bug filer on behalf of Rob Browning, emacs maintainer
> --- debian/control.orig 2014-07-06 13:10:21.364467678 +0200
> +++ debian/control2014-07-06 13:10:36.516651745 +0200
> @@ -11,7 +11,7 @@
>
:
> | # Currently, emacs23 is required (xemacs is not sufficient).
> | EMACS := emacs23
Assuming I understand what you're saying, the emacs metapackage is
solely for FSF emacs. Currently:
Depends: emacs24 | emacs24-lucid | emacs24-nox, ${misc:Depends}
Presumably there could eventually
nd these specific permissions on
/usr/local/ and its subdirectories (9.1.2):
http://www.debian.org/doc/debian-policy/ch-opersys.html
http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
I'm copying this to debian-policy so that they may comment.
Thanks
--
Rob Browning
rlb @
ar library
> handle (that you got from dlopen()). The version check you're
> doing is relevant to the library version that piece of code intends
> to use.
I think this may be more relevant to libs ld.so linked indirectly
against two different versions of the same lower lib. Th
otal evidence
that libfoo can actually end up with access to a mixture of symbols
from both versions of libbaz. If true, this would make it extremely
difficult to actually use a "version check" function to make sure you
loaded and were calling functions from the version you exp
es if
there are no other subsequent, more specific assignments.
Given that, you can get delete to delete the character under the
cursor like this:
(global-set-key [delete] 'delete-char)
Now the only question is, should I make this the default Debian
configuration?
--
Rob Browning
lly
*everyone* else. That's also a major reason why they can have *much*
more powerful macro systems. When Apple switched Dylan from prefix to
infix, they had to abandon a large fraction of the power of their
macro system...
I'm sure I can get my hands on several small prefix parsers if w
r number 3, and do something truly radical.
People have talked about killing off /usr/X11R6 altogether. Are we
actually entertaining this idea, or is it just someone's pipe dream?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email t
Yann Dirson <[EMAIL PROTECTED]> writes:
> 1.0~1foo-1
> 1.0~2bar-1
> ...
> 1.0-1
So far, I think this is what everyone has intended. I can agree that
"negative" is a misnomer in this case.
--
Rob Browning <[EMAIL PROTECTED]> PGP
right sorting behavior, specifically
foo_2.1.110-pre2-2 < foo_2.1.110
All that said, I think "-" has problems. As Jason mentioned, we may
not want to have:
1.1 < 1.1-1
and, as Adrian pointed out, I agree that it is somewhat hard to parse
visually.
--
Rob Browning <[EMAIL PRO
even if update-alternatives fails, but
it also notifies dpkg of the problem.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
that we were working toward, but we would make
releases on a more regular basis, goals met or not. This was related
to some ideas about changing the way we make releases...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
local data, user data, and information
from the outside world like mail, news, lpr spools, etc...) So for me
files controlling the DNS behavior of the machine would have fallen in
this category.
I'm not saying this is the "right" way to think about it, just
explaining where my r
or
backwards compatibility...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
eakness.
Basically *any* file that records local configuration information goes
in /etc., no exceptions.
This restriction does conflict with the way many other "traditional"
unices have handled some files, but on a Debian system, there should
be no system-wide "configuration" fi
, and advertise it on debian-devel. This will
just cause a short-term confusion.
2) Put a test into dpkg-buildpackage like:
(if (exists? "gpg") (use "gpg") (use "pgp"))
> This means forcing all
> developers to generate gnupg keys;
Big deal.
Unless there
yone else, and the maintainers are fairly well versed
> in the Bug system; merging bugs is not all that hard.
Yeah, I just got finished merging several duplicate bugs for
emacsen-common.
> Yes. It is a good idea. It just should not be mandatory.
OK, I'll buy that. We should just *sugges
ht discover a workaround in the bug log
that helps them out. This might be the best way to "sell" the idea :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
you mostly mean editing of the policy
document? Much of implementing policy is, of course, things that
others need to do.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
u put another dash in. The
packaging manual makes it clear that this would just be a bug in the
tool.
In fact, until we implement the "~" feature that it looks like we've
settled on, I'm using a dash in the libgc4 (Boehm GC) version number.
--
Rob Browning <[EM
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hmm. I think I would prefer 2.0.7-2.0.8pre1 or some thing to 2.0.7~1
Right. I'm going to do this for now.
> 2.0.8~pre1 is even better, I think.
And hope this is implemented soon.
--
Rob Browning <[E
is could be avoided if
dpkg stashed a timestamp when it started up. Then emacsen-common
could use this (and a per/add-on package timestamp of its own) to keep
from running package install/removes redundantly during a given run.
> And then prior art may be used to leverage a change in
that
2.0.7~1 is actually equivalent to the upstream 2.0.8pre1, whereas
2.0.8~pre1 makes it pretty clear.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
belong in a
more sophisticated dpkg).
Thoughts?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lib (or the base system), and then mandate that everyone
use that. After that changes like this will be painless for
everything except perhaps dftp (which is designed to run on non-debian
systems).
Given the shared lib, it would also be trivial to support access from
dpkg-perl, python, guile, whate
> ambiguity.
Apologies. I obviously wasn't reading carefully enough.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Well, it's definitely broken. Totally unclear what the Debian
revision is. Sounds like a good thing for lintian to be checking.
Using package names or version numbers that violate our standard could
get us in all kinds of trouble...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80
fast and loose with the grammar may also break some hidden
assumptions in some of our auxilliary tools. We really should be
reasonably strict in specifying the makeup of the version string, or
it will be really hard to design tools that aren't likely to break.
You don't have to be nearl
but acceptable, in my opinion.
I don't think it's a good idea to do anything to make developmental
versions "second-class citizens", especially since we've had many
cases where these versions were the only reasonable versions to be
using at the time.
--
Rob Browning <
om here, then my only
> recourse is to not release "pre-release" versions. I don't think
> that is a good idea, as it wastes our testing manpower, and weakens
> the final product.
Of course. That would be ridiculous. No one sane is arguing in favor
of that.
--
Rob Browning
st place, but it would IMO
be a "cleanish" solution to the problem.
I've probably overlooked something obvious, so flame away...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
just a little cooperation between the maintainers of the two
packages in question (i.e. just agree on a file that must exist
if the package in question is installed, say /usr/lib/vm/version,
or whatever).
Thoughts.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Rob Browning <[EMAIL PROTECTED]> writes:
> Manoj, do you have a list of these packages handy? If so, could you
> file a bug, or send me the list so I can? I believe this is broken.
> Nothing should depend on emacsen-common, only emacsen.
Ok, now I'm not so sure abo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Except for the emacsen themselves, of course. As I see it,
> this is hyperlatex, elib, and cvs-pcl
Thanks. This is quite helpful. I'll file bugs soon.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 0
control over the upstream version numbers, so we
need some standard solution.
Of course your final scheme *is* a bit more flexible, but as you point
out, it may be overkill, and it does require modifications to dpkg.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94
ld depend on emacsen-common, only emacsen.
I'll try to remember to clarify this in the policy doc...
Thanks
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "un
ript ought really to read that information from
> another file that is a conffile?
I've sometimes wondered why it wasn't like the other /etc/init.d
scripts. I've several times wished it had start, stop, reload,
etc. options...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerpr
e/file&
BADGER=$!
# Do something with /some/file here
kill $!
lockfile -u /some/file
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> liblockfile-dev
> qpopper
>
> emacs19 (?)
> xemacs20 (?)
I modified emacs20's movemail to use liblockfile, so any package that
uses that will be safe. The other emacsen can probably just copy my
diffs.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04
to assign the degree of relationship between vm and make.
I think I've come to the conclusion that vm should just depend on
make.
> we are still hammering out the details of the policy and
> implementation.
Definitely. I'm all for bright ideas :>
--
Rob Browning <[EMA
it, so I didn't have that
much extra energy for flowery prose :>
But it is definitely too dense...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
that breaks during
the upgrade of an emacs flavor. Manoj brought this up, but I haven't
dealt with it yet. Elib was the offending package, but we need to
determine how we want to handle this in the general case.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21
it looks like Manoj has summarized them pretty well later
in this thread. I'll comment there...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e size of make, and it is critical to the install process in
many cases.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
elpful if you're too
harsh when you think they've make mistakes.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
add-on
> packages know which one is being run. Who knows?
Right, but this would just require them to define unique symbols, and
modify themselves to provide the correct directories. The latter's
not something I could easily do from emacsen-common anyway.
--
Rob Browning <[EMAIL
t superior. The argument was just that we should
probably have *one* common language, and right now, that seems likely
to be English (for better or worse).
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> The duplication of a small startup file is not so bad, after
> all.
Especially if it's a symlink...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUB
macs binary package itself that knows what flavor it is.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
s, I/O programming, and resource management in
> something less bulky than the average dictionary.
But what facinating reading it would be likely to be. Seriously, I
think this could be a tremendously useful reference (for Debian and
even the broader community), even if it became huge.
--
have to check to see what I wrote in debian-emacs-policy about
this, but is there any reason this wouldn't be OK?
> emacs19 does not seem to define debian-emacs-flavor. I haveg
> to do it manually in my .emacs.
I think this was a bug that might be fixed now...
--
Rob Brownin
e line in debian/rules. How's
that hard to maintain?
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
incorrect.
Since David is one of the ld.so upstream authors, I'd be inclined to
believe him.
> Does someone know which technical aspects we forgot in all these
> discussions or which part of it has changed now??
I'd send the bit of proposed manual text to David Engel
<[EMAIL PRO
be a tremendous help to new developers as well as
> experienced developers.
Yeah. I have on my to-do list going back through and figuring out
*exactly* when the emacsen-common scripts need to be called. It's
possible that it's happening in completely redundant cases right now,
bu
umably you
want to preserve permissions and ownership, and using these methods
will also preserve the hardlinks.
> Then there is consistency issue. Package X uses symlinks but package
> Y hard links.
What difference does this make?
--
Rob Browning <[EMAIL PROTECTED]>
PGP finger
s it OK to compile Debian packages with egcs now? Also if egcs is
now the standard, then shouldn't it provide /usr/bin/gcc, or are we
supposed to just stick calling cc? If the latter, then why does the
egcs C++ package provide g++?
Thanks
--
Rob Browning <[EMAIL PROTECTED]>
PGP fing
asswd run that
tells everyone what's going on, why they probably need to do this,
saying yes to the questions, yadda, yadda, yadda...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Scott Ellis <[EMAIL PROTECTED]> writes:
> Probably :)
> However, it was just hacked out recently, so the policy manual hasn't been
> updated yet.
Yep. Christian said the pointer was coming soon...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 2
xchanges on debian-policy a
while back.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
a command name would be troubling, please speak up.
Maybe a dumb question, but what about bash's {,} syntax? If you have
commands with commas in the names, it could make this somewhat
awkward.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F
especially indicated if the bugs filed
are not part of existing policy. On the other hand, it doesn't hurt
to leave them open while the issue's being discussed. It's just a
little annoying.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2
; Actually, just fixing up the documentation (packaging manual, etc)
> would be of the greatest help.
Things are getting much better now that Christian's on the job. I'm
not sure where he comes up with all that time and energy. Maybe he's
got a temporal distortion field sta
for now; good practice if nothing else :>
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
E-mail the word "unsubscribe" to [EMAIL PROTECTED]
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED]
e allowed
to touch /usr/local, but only to *try* to create directories (like
/usr/local/emacs/site-lisp), but you're not allowed to die if it
fails. That's primarily to accomodate systems with read-only
/usr/locals.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 0
n't think it'll affect me one way or the other. I
did have the emacsen-common package doing some final cleanup in the
postrm (removing files that had been created in the preinst). I
suppose given this policy, I should probably change that too...
--
Rob Browning <[EMAIL PROTECTED]>
are less, but some people seem to. I'm
certainly not going to be leading the crusade for (or making) the
changes, but I don't mind accomodating them if the people who care
have a reasonable counter-proposal that works and doesn't break
anything.
--
Rob Browning <[EMAIL PROTECT
.e.,
> '1'.
I think I understand, and I think it would be fine. It would
certainly eliminate the once an epoch, always an epoch problem that
seems to bother some developers...
But it doesn't matter unless someone's willing to hack dpkg.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
clear to me that it can be done without
creating problems with other cases, and epochs seem to solve the
problem with no hassle. I don't really care either way, but my rule
of thumb is "If dpkg --compare-versions gives the wrong answer, change
the version string. If there's no go
Yep.
> Hmm, that's not so bad, though, is it?
Nope. You'll never see it, so who cares.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
essary modification of the upstream version number?
I don't know. That's what they're for, but I've noticed that people
still seem to have some kind of aversion.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
ion tool
that can have local config info in something like /etc/dpkg.conf
similar to:
no_touch_dirs: /usr/share /usr/doc
compress_manpages: yes
etc...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
ers (new and old) know *why* you're
uncomfortable. It wasn't until a debate (ages ago) that came up over
this issue, that made it clear to me that I didn't want to use these
tools.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
opy this page, modify it
to fit their package, and put in the relevant manpage symlinks for
"foo, bar, and baz". Note that the Debian package name should always
be one of the symlinks.
Bad idea?
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
willingness to ask questions on debian-mentor, debian-devel, or
wherever. Granted, that may be a tall order, but it is possible.
> I do not wish to promote quantity at the expense of
> quality. If it is in Debian, it is a high quality product. I never
> want that diluted.
Absolu
nd coincidentally, what name to use to
invoke the right emacsen for the compilation (that's what the
"mandatory binary symlink" is for).
> manoj
> who rarely gets this flummoxed
The early version of the document was a mess. I hope it's somewhat
better now, but it
t how to you recursively search an html
tree for the info you want (like Ctrl-s in info, Meta-s in emacs, or
"/" in manpages with less?)
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
x27;m not necessarily claiming that this is a great idea, and
it's certainly not anything that would work for security purposes, but
it might be useful for other things.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
gger unless they could be gzipped.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
ories.
Note that this indicates that in these cases it's up to the maintainer
to determine when performance is an issue. For example, if there's
only one .el file, and it just contains
(setq load-path (cons "/some/load/dir") load-path)
Then I don't think byte-compilin
ockfile_touch(const char *lockfile);
Ignore what I said about publib-dev. These are the functions I was
really looking for. I could have sworn I searched for them and didn't
find them, which is what made me go off searching elsewhere, but I
must have overlooked them.
Thanks Christian.
--
Rob Bro
clude/publib/lockfile.h (which is included from
/usr/include/publib.h):
int lockfile_create(const char *);
int lockfile_remove(const char *);
Hope this helps.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
got all the weird cases right (NFS being the main
one I can think of).
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
oesnt' look like we've done anything that will preclude
doing the things that we see we might need in the future. So we
should let these changes settle in a bit, during which time it should
become clear what should be added next.
Of course, I could be wrong :>
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
with this in principle, I'm not ready to make policy
about it. For now, it'll just be up to the maintainers to decide.
After we get things rolling (and the users start complaining :>), then
we can deal with this on a case by case basis.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
ions so far. So, unless someone objects now, I'll add that package
> to our authoritative list. Here is the entry (please tell me if this is
> fine):
>
> emacsen Anything providing the GNU emacs or a compatible editor
Looks good to me.
--
Rob Browning <[EMAIL PROTECTED]&g
package may just include files located
in the standard emacs add-on directories:
/etc//site-start.d
/usr/share//site-lisp
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
hink we're doing anything now that
precludes doing this stuff later, but if you have a good proposal, I'd
be happy to hear it.
> No thanks, I don't have very much free time now, better wait for the new
> emacs19, before I start playing with it (I have no spare machines handy
> an
oloads are set up properly. I think tm already does require
you to do something to "turn it on".
> I plan to release AUC TeX and Mailcrypt using /usr/share as soon as the
> new emacsen come out: is there an estimate time?
Well, I'm ready to go, but we really have to wait for a
m ${elc_dir}/*.el
fi
exit 0;
#!/bin/sh
# /usr/lib/emacsen-common/packages/remove/foo
# [ This particular script hasn't been tested either, so be careful. ]
set -e
FLAVOR=$1
echo remove/foo: Handling removal of emacsen flavor ${FLAVOR}
if [ ${FLAVOR
Steve Greenland <[EMAIL PROTECTED]> writes:
> 2. Build it as part of the post install, and possibly provide scripts
> for other packages to modify it.
The packages can use update-alternatives here to make sure that when
magicfilter's uninstalled, lprng's printcap comes b
> file.) [Currently debview has (load "deb-view") in
> /etc/emacs/site-start.d/50debview.el; should I file a bug report?]
That sounds like a good idea. Since I seem to be making the "big
emacs policy document" I'll stick it in as a recommendation.
> It isn&#
me (1) again, and that someone removes tm.
Nothing particular happens, but tm is responsible for cleaning up
any files it put into it's allowed locations:
/etc//site-start.d/
/usr/lib//site-lisp/tm
Thanks for your patience.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
lib directories. I'm not sure how they get there.
[1] According to the ldso maintainer.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
1 - 100 of 115 matches
Mail list logo
