als here when gnu.org was
compromised (for example).
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
we
changed our policies or perhaps my memory is mistaken.
Also, I wonder if our handling of /usr/local isn't a bit inconsistent
since it doesn't look like we include /usr/local/lib in the ld.so
defaults.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.e
so it's not a big deal. I'm not sure where I got
the idea things were otherwise.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> rather than be scattered to the four [why four?] winds.
N, S, E, and W
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I would really like to get into using CVS for my package
> development tree, but I have been held back by the hassle of
> releasing packages.
I wondered about this, and I had a question. I looked around in the
CVS manual a little and didn't
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> Nothing. When you check it into CVS it will rewrite all of the $Id: $
> markers and friends to reflect your CVS tree. It shouldn't have any
> problems. You might not want that so you can turn off substitution with
> -ko I think.
I guess I was looking
Is anyone else running the latest unstable kernels on a uniprocessor?
I have noticed that with many of the recent kernels (including
2.1.40), time appears to be stopped. With these kernels, on my
machine clock never returns anything but zero, and things like
procmeter never register anything for
When the machine I have that's tracking unstable is rebooted, the xdm
login screen will not appear until I use ssh to remotely connect to
the machine. Until then the screen is blank. I don't know what's
causing this, or I'd file a bug with the responsible package, but
removing ssh makes the prob
Galen Hazelwood <[EMAIL PROTECTED]> writes:
> I think it also chooses some instructions differently for a 486, and
> these choices are also good on the pentium. That's why, when building
> binaries for my use, I use -m486 but add flags which turn off the
> alignment.
Right, I had heard that thes
[EMAIL PROTECTED] (joost witteveen) writes:
> One possible solution is to link Xaw statically in the freeciv binary.
> That's what I do with aXe.
Or you can just use -rpath when you compile to force it to use a
particular dynamically linked libXa*. I think that was the solution
used in gv.
--
I'm moving this over to debian-devel. Hope that's OK.
Joey Hess <[EMAIL PROTECTED]> writes:
> The real reason I'm replying to this: I wonder what the other developers
> think about bug reports that just say a new version is available (as opposed
> to, a new version is available, and fixes this
Camm Maguire <[EMAIL PROTECTED]> writes:
> Greetings! I've been reading here recently about the mgetty package
> looking for a new maintainer. What's the status on this? I'd like to
> suggest to the new maintainer to rebundle the vgetty extension, as the
> program is quite usable, IMHO, in spit
Sorry about the runaway mail headers in my previous article re-post.
Emacs was hiding them from me.
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Nathan E Norman <[EMAIL PROTECTED]> writes:
> Not that anyone necessarily has the time, but would it be worthwhile to
> create some documents listing categories of packages, comparing and
> contrasting the competing packages?
Right. I'm about to help someone set up a relatively busy mailserver,
Guenter Geiger <[EMAIL PROTECTED]> writes:
> - libraries should be compiled reentrant
This has been on the list of things to do (for bo and now for hamm)
for a while. It'll propagate eventually.
Note that just compiling with -D_REENTRANT doesn't mean that the
library is suddenly multi-thread s
Douglas L Stewart <[EMAIL PROTECTED]> writes:
> It's just a matter of making sure all of the other libraries get thread
> safe, which will get partially done I'm sure. The ones that aren't, you
> can work around it by just using them in a single thread usually.
or often by just using a mutex to
Mark Eichin <[EMAIL PROTECTED]> writes:
> debian's Xfree86 3.2 packages were not built reentrant. I'm working
> on the 3.3 libraries now, and once they're stable and working, I'll
> be adding other support to them. (have you ever tried programming
> with X and threads? you probably want to onl
Guenter Geiger <[EMAIL PROTECTED]> writes:
> Yes, I've tried - that's how I came to this topic.
> The problem is with the global errno variable. As Xlib does a lot of
> error checking using errno. After X encounters an error it checks what
> kind of error ocurred with errno and deals with it.
> I
Andy Mortimer <[EMAIL PROTECTED]> writes:
> Although how well this interacts with dynamically-loaded shared libraries
> is anyone's guess;
What do you mean?
> I suspect I may have to go the global-variable route myself, which
> is why I was asking for examples/docs.
Bruce is right that in gener
Helmut Geyer <[EMAIL PROTECTED]> writes:
> - compile the library using -D_RENTRANT or -D_THREAD_SAFE
There was some talk about adding -D_REENTRANT to the list of flags
that are automatically included by gcc/g++. I don't recall what the
resulting decision was, if there was one.
> - there
Andy Mortimer <[EMAIL PROTECTED]> writes:
> the basic question I want to answer is: if I open a library in one
> thread, is it then always accessible to all threads (presumably),
> and what happens to any global variables in that library?
Threading shoudln't have any affect on this. All the thre
[EMAIL PROTECTED] (Mark Baker) writes:
> Would programs _have_ to use this library, or is implementing the same thing
> in acceptable? The latter has problems in that it forces us to keep the same
> method, but I don't want to see lots of #ifdef debian appearing in the
> original source; apart fro
Does anyone know of any document comparing comparing sendmail, exim,
and qmail. The recent discussions and some upcoming installs here
have made me start contemplating the issue again.
I've poked around, but came up with nothing. I did see some bits in
the Qmail+MH mini howto, claiming all its
Alexander Koch <[EMAIL PROTECTED]> writes:
> (I'd vote for exim if uucp is guaranteed to work)
Ok, so what are the arguments for exim over qmail (at least why do you
prefer it?)
I've heard arguments for qmail and exim over sendmail.
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the
Christian Schwarz <[EMAIL PROTECTED]> writes:
> This really is an _excellent_ idea! So, we just need a volunteer to
> implement and maintain this "upstream library". (The packaging for Debian
> should not be a problem.)
Ideally we could provide C, perl, python, etc versions of the code.
--
Rob
I'd like to officially offer dftp up for adoption. I don't use it
anymore -- dselect works much better for me now that I came to terms
with it -- and so I don't really have much interest in maintaining
dftp anymore (that and the fact that I have a bunch of other things
I'm supposed to be doing).
Roman Hodek <[EMAIL PROTECTED]> writes:
> I'd volunteer for maintaining dftp, at least for a while, if nobody
> else does. I also have a lot of things to do and not too much time
> left, but I need dftp for my two machines at home
Right. Just in case you hadn't thought of it you could use dselec
Chris Fearnley <[EMAIL PROTECTED]> writes:
> If I might speculate on my "winning" sendmail configuration strategy:
> ignore the irrelevant (like rule sets).
Say you have three users who have accounts on your system, but their
primary accounts are elsewhere. Now you want their email headers to
be
I had posted earlier about a problem getting Debian 1.2/1.3 installed
on a 365x thinkpad. Several solutions were offered and in the end it
turned out that the people claiming that some thinkpads could not
handle the bzImage format were correct. It was not the
"floppy=thinkpad" problem. I didn't
John Goerzen <[EMAIL PROTECTED]> writes:
> Why are we using dotfile locking only? There are much better
> mechanisms (flock, etc.) that should be used instead. I can see no
> place where dotfile locking would work and flock-style locking would
> fail...
I think flock can fail across NFS in cert
Bruce Perens <[EMAIL PROTECTED]> writes:
> Is this when booting from the floppy only, or from hard disk too?
> I suspect a software bug in SysLinux, the floppy bootstrap. Once I
> get some more data from you I will take it up with H. Peter Anvin,
> the SysLinux author.
Hmm. I don't have access t
John Goerzen <[EMAIL PROTECTED]> writes:
> However, why is it bad if a given program (like Elm-ME+ which I
> maintain, which brought the issue to my attention this time) uses
> *both* locking mechanisms?
The only problem I know of is that with two locking schemes, if all
programs don't agree on t
"Scott K. Ellis" <[EMAIL PROTECTED]> writes:
> Okay, show me how to search a HTML version of the bash info documentation
> for a concept and I'll believe you.
Absolutely, anything without regex and incremental search is broken
and unacceptable for documentation purposes (IMO).
--
Rob
--
TO UN
Bruce Perens <[EMAIL PROTECTED]> writes:
> Install a bzImage kernel on the hard disk using LILO, and see if it will
> boot. If it boots, it's only a problem with the floppy bootstrap. All of
> our kernels are bzImage, so that should be easy to test.
Tried it, and it hangs when booting bzImage fro
[EMAIL PROTECTED] (Martin Schulze) writes:
> I don't like the idea of splitting packages that much. It increses
> the confusion for users. For new users it is incredible difficult
> to install Debian because of >1000 packages.
I think keeping the user from having to deal with this complexity
(
Bruce Perens <[EMAIL PROTECTED]> writes:
> From: Rob Browning <[EMAIL PROTECTED]>
> > Tried it, and it hangs when booting bzImage from the hard drive too.
>
> Please tell me exactly what ThinkPad model this is.
I believe it's a 365X (16MB, ~800MB drive).
--
R
Erv Walter <[EMAIL PROTECTED]> writes:
> Bruce Perens <[EMAIL PROTECTED]> wrote:
> > I'd rather fix the software bug that prevents bzImage from working on
> > some computers. Thus, I need good data on what those computers are,
> > and I need people with those computers to test new boot floppies.
>
I was going to try out qmail, and I just wanted to see if anyone had
made a package of 1.01. I mailed Christian, but I haven't heard back
from him yet, and I thought someone else might have packaged it for
their own internal use.
Thanks
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail
Ricardas Cepas <[EMAIL PROTECTED]> writes:
> As of current documentation, you can search only current
> .html file. This is not very usefull.
> Lynx ( on non-gzipped docs) is much slower then info ( on
> gzipped).
Oh, right I forgot to add "recursive" to my previous comment about
[EMAIL PROTECTED] (joost witteveen) writes:
> No, what I had in mind is changing chmod, chown and frends, and make
> them log the intended permissions in a file (specified somewhere in
> a environment variable), and then changing tar to look for that file
> (agian in that environment variable), an
Galen Hazelwood <[EMAIL PROTECTED]> writes:
> /lib/cpp has _always_ been a symlink to /usr/bin/cpp. It has been that
> way for years. And it's only _now_ causing a problem? Have you never
> installed cpp or gcc before?
>
> Furthermore, symlinks are definitely allowed across devices. It's hard
Philip Hands <[EMAIL PROTECTED]> writes:
> libmailaccess should be something like PAM for mail delivery,
> providing access to a user's mailbox by use of either Maildir, or
> dot-locking (via libnfslock say), or whatever other method --- as
> selected by the user.
Sounds good to me.
--
Rob
--
[EMAIL PROTECTED] (Bruce Perens) writes:
> Uh-oh, I can't duplicate the bug today. I wonder if it has to do
> with the fact that I was running kernel 2.1.43 yesterday, and not
> today?
A-ha. I'm running 2.1.43 on the relevant machine as well. I had to
upgrade to that version because earlier ver
Mark Eichin <[EMAIL PROTECTED]> writes:
> I'd prefer that this only be done using tar itself -- because debian
> has had such a bad track record with handling tar format, particularly
> in the fringes (long file names in particular -- I think dpkg might
> have been fixed, but dpkg-source is still
[EMAIL PROTECTED] (Bruce Perens) writes:
> Get that 2.1.43 kernel off of there, and do an "fsck -f" (for _force_) on
> all filesystems. On my system I had a lot of null-named directory entries
> and other distressing but non-fatal filesystem problems. And that was without
> the directory-cache cod
[EMAIL PROTECTED] (Bruce Perens) writes:
> Get that 2.1.43 kernel off of there, and do an "fsck -f" (for
> _force_) on all filesystems. On my system I had a lot of null-named
> directory entries and other distressing but non-fatal filesystem
> problems. And that was without the directory-cache cod
[EMAIL PROTECTED] (Bruce Perens) writes:
> Someone brought up the point of recursive regular-expression
> searching. Of course this should be done with a CGI script rather than
> as a browser facility, so that it would be browser-independent. One
> could build a tiny search engine with zgrep and
[EMAIL PROTECTED] (Bruce Perens) writes:
> I-search would take a Java-equpped browser as far as I can tell. It's
> not do-able all in free software today. That will not be the case forever.
Right. Also might be do-able as a hack in something like dwww
(assuming I understand what it's doing) or w
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
>
> IMO we should go with the simplest solution: {chmod,chown}.sh and modify
> the packages.
Well, if we do this, we need
ar as I can tell, there are corrupted files on master. I had to
re-upload perl-tk (with a new revision) to fix the problem.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word &quo
t;relatively untestable" packages, and would fair better under someone
> elses care.
>
> Please contact me if you are interested in any of these packages.
I'll take m4 for you.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5
uld just have a file in /usr/lib/cron/auto (or
whatever) which would be used to (re)build the contents of this
section whenever a relevant package was installed.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM
le:
The only advantage to the monolithic section I can see is that then
you only have one block that the tool is ever manipulating, and since
the entire block is regenerated anytime any piece changes, it seemed
like it might make the setup less affected by minor corruptions.
Proabably not a big deal e
ny of the others. Is this possible? I've looked
through the ld info pages several times and haven't found anything
that works.
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 FROM THIS MAILING
Stephen Zander <[EMAIL PROTECTED]> writes:
> Do you only have access to the sub-libraries as *.so files?
Yes.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word &
handle this) I'll just figure out some other way to deal with it.
I think I can restructure the make process to get access to the .o
files earlier.
Thanks, though.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIB
it *really* necessary to provide the upgrade?
Don't forget that installing this *minor* upgrade would break *all*
the packages like perl-tk that depend on a particular version of
perl. Come to think of it, I think I need to change my perl-tk
Depends to be more restrictive...
--
Rob Browning
th the right name to the original
tarfile.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
n.org rather than debian-devel.
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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
a big hassle before that. The tulip cards are cheaper and
better supported. I'd go with that, and I have both. Note that I'm
not using them at 100Mbit if it matters.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
-Wall -o testx testx.c -L/usr/X11R6/lib -lX11 -lXt
$ testx
Xt thread safe: 1
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
eptions, so even if we wanted to
make it the default, we couldn't just specify it for both compilers.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
case for any Debian libraries. I'm a little fuzzy on the
details, though.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECT
x27;t know if cp -a is frowned upon, but if so, I need to
change at least one of my packages.
In any case, here's a reasonable substitute:
(cd src-dir && tar cf - .) | (cd target-dir && tar xpf -)
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 2
des the stuff,
then a week later realizes that someone may be trying to hack their
system. The go to "who" (and friends) to see what's going on, and
they get an empty listing. This is going to cause someone to need
heartburn medication.
(Hope I've got my facts straight and I&
ded commands up to the
current packaging tool standards.
FWIW, I agree that Ian's objections are valid, and I think his
approach should be preferred if someone gets the chance to implement
it.
(Sorry if I misrepresented your objection, Ian.)
--
Rob Browning <[EMAIL PROTECTED]>
PGP finge
ery package built with them include a specific version dependency to
guarantee reproducable builds. That's pretty ugly IMO.
All that said, I understand the vaporware argument. I'm not talking
about whether or not we should continue to maintain debmake/debhelper,
but about where future deve
"Adam P. Harris" <[EMAIL PROTECTED]> writes:
> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
Stunningly good idea. Make it so :>
--
Rob Browning <[EMAIL PROTECTED]>
about how this
package should be handled. I'm planning to cooperate with the xemacs
and emacs (19) package maintainers to make sure we support the
simultaneous installation of all three packages.
The new main package will be named emacs20, and there will be an
auxilliary emacs20-el pa
about /usr/libexec?
Am I correct in assuming that it should still be avoided until FHS?
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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL
t will be. I don't think that the old and new emacs
will be sharing many files.
> The use of /usr/libexec is currently under discussion on debian-policy.
> Please wait a few more days until we've decided of how to treat this
> directory.
No problem.
--
Rob Browning <[EMAIL
ered
> about this.
I was under the impression that they're architecture independent.
Please correct me if I'm wrong.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail th
es
somehow so that when say emacs20 is installed, it will knows to go
find these files and byte compile them to a private location.
This, of course, only applies for packages with .el files that are
compatible with more than one of the emacsen.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint
a scalable solution.
> The most important thing is that the shared directory issue is
> solved, and this is best done by not compiling elisp files from
> packages otherwise unrelated to emacsen.
I agree that the shared directory is important; I disagree with your
solution.
--
Ro
"Simon's Mailing List Account" <[EMAIL PROTECTED]> writes:
> Well, I'm not a developer (yet), but am in the process of switching
> various servers from Redhat to Debian, and wanted to get a feel for
> how active the developer community is.
Hope we didn't
cs installed will be wasting about 5MB of hard drive
space for no reason.
[1] Though is it really that big a deal as long as it gets forked off
to the background like the TeX or manpage rebuilds?
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F
(and are willing to try).
But first I want to make sure we have a clear idea of what the issues
and possibilities are.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
lled?)
Oh, I'm planning for that to be automatic. The emacs maintainer will
just have to have an appropriate call in the postrm.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail t
after the horses have eaten the
chickens.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Please also involve the people who maintain emacs lisp
> packages as well, since the decision shall have major impact on us.
Oh, of course. I certainly meant to include you.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerp
ractice, at least, is that code changes are not a
necessary criteria.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
files
for all the byte-incompatible emacsen within one debian package.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
one central location to
> stuff things into.
Absolutely.
> Requiring all packages to come compiled with both variants is NOT the
> way to go. It will waste diskspace, both on users and for the
> maintainers of packages containing elisp, that now *has* to have both
> variants ins
able to handle the more complex emacs cases as well.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
bugs worked out before tackling the bigger issues.
Comments?
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
arguement used to invoke pppd
will *never* be crucial, you shouldn't mangle it.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
nk
at this point I favor Guy's service registration proposal, but there
are some details that have to be considered.
I won't be doing anything about any of this fancier stuff for a couple
of weeks, though.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A
#x27;s no reason the hook file for tm in
Guy's proposal couldn't just execute
(cd && make)
I do agree that there are other complexities to work out.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRI
king a mistake.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Raul Miller <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> wrote:
> > Note, that I'm not saying that I can come up with a good argument why
> > it would be important to be able to make this distinction (or to even
> > do what I'm depi
very carefully!)
If emacs' current mechanism *is* compatible, then I could save some
hassle.
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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
med emacs20. The older one may
or may not be renamed to emacs19, and unless there's a reason not to,
I agree that all three emacsen should "Provide: emacs".
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRI
s to check the implementation in maillock
to see if you're compatible, and the manpage for maillock says to see
lockfile_create(3), which doesn't exist. I'll have to UTLSL, but I
may release an initial package before doing all that. Things won't be
any worse than they are now, and the
ges that do not need to be
> installed.
I think that the dpkg-mountable package might eliminate this problem
if you use it as the access method, but I haven't tried it yet.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 3
some mayhem
when this pair of packages is released and other people doing
something similar suddenly have to treat /usr/src/linux as read only
without being warned.
[1] Why Linus has linux-.tar.gz unpack linux rather than
linux- has never made much sense to me.
--
Rob Browning <[EMAIL PROTECTE
advertised with the new libc6 arrangement. I
don't know if I'd go so far as an actual pause in the postinst, but
this could be a fairly serious problem.
People who weren't using kernel-headers before (because they never
needed it), may be in for a shock.
--
Rob Browning <[
ay I can see around this problem is to have emacs
spawn a small process to keep touching the lockfile (every 4 minutes
or so) whenever it acquires the lock, and kill that process when the
lock is released. Does that seen reasonable to everyone else?
--
Rob Browning <[EMAIL PROTECTED]>
PGP fin
r/src/linux is a link, then it is safe to unpack there.)
I'm not sure what the right answer is, but I think we need to consider
the problem before the new libc6-dev gets released from the
experimental stages, and we certainly need a long-term policy.
--
Rob Browning <[EMAIL PROTECTE
hen
if we patch movemail to use liblockfile, we should be fine.
I'm under the impression that liblockfile handles everything,
including nfs. I believe libnfslock is transitional, for use until
everything's migrated to liblockfile.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E
e lockfile then becomes
/var/spool/mail/username.lock. Maillock uses an NFS safe
algorithm that is documented in lockfile_create(3).
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
1 - 100 of 234 matches
Mail list logo
