Alex Yukhimets <[EMAIL PROTECTED]> writes:
> When doing 'g'roup reply in elm, the e-mail of the person goes into
> the "To:" header and list address (along with all other thread
> participant's adresses) to "Cc:" header.
So, umm, fix elm?
--
James
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-m
Hi, I noticed the upstream maintainer of epic talking about a bug in
linux's writev, saying that it was not reliable. This is a pretty
incomplete request, as I have no kernel versions, libc versions, or
anything else of value, but maybe someone has heard of it?
To quote:
The change specif
Massimo Lusetti writes:
> I wish only know if out there's a .deb for PGP 2.6.3i ... tnx
Due to restrictive law it is placed on nonus.debian.org:/pub/debian-non-US
Regards
Joey
--
/ Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg /
/ http:
Massimo Lusetti <[EMAIL PROTECTED]> writes:
ML> I wish only know if out there's a .deb for PGP 2.6.3i ... tnx
Read ftp://ftp.debian.org/debian/README.pgp.
--
_
/ \ "The cat's been in the box for over
| David Maze | 20 y
Is there any way to get directories that don't have the normal
architecture structure, i.e. project/experimental, to show up in
dselect using the ftp backend? (I at least want the Packages file to
get loaded when I press [U]pdate...)
--
_
/
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. Let's just say that it's not an
'if', but a 'when' (i.e. after I finish dealing with a major upgrade
on an SGI)
Probably th
Sten Anderson <[EMAIL PROTECTED]> writes:
> If elisp files should be compiled in a postinst script, then which
> postint script should do it?
It should just be handled the same way as the menu package. It'll
usually be the postinst of the package installing the .el files. All
of these packages
"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 disappoint :>
--
Rob Browning <[EMAIL PR
On 16 Dec 1997 [EMAIL PROTECTED] wrote:
: From: [EMAIL PROTECTED]
: To: [EMAIL PROTECTED], [EMAIL PROTECTED]
: Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED]
: Date: 16 Dec 1997 22:40:10 -
: Subject: Re: SPAM to mailing lists! STOP NOW.
:
: Dear Robert,
:
: We do use qmail. If you woul
From: Ulrich Drepper <[EMAIL PROTECTED]>
Subject: Re: libc/378: Why isn't STREAM_MAX == FOPEN_MAX?
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED] (Ulrich Drepper)
[EMAIL PROTECTED] writes:
> Q: Shouldn't STREAM_MAX = FOPEN_MAX, as stated in "APUE"?
Yes, according to X/
> "James" == James Troup <[EMAIL PROTECTED]> writes:
James> Alex Yukhimets <[EMAIL PROTECTED]> writes:
>> When doing 'g'roup reply in elm, the e-mail of the person goes
>> into the "To:" header and list address (along with all other
>> thread participant's adresses) to "Cc:" he
Folks,
After seven or eight months as Debian's mailing list manager, I'm
ready for a change of pace. I'd like to offer up the position to any
interested individual(s).
I'm offering the position because I haven't been spending as many
late nights at my day job's office, and I've
I have used writev() on Linux for many years. Never had a problem.
--
Ioannis Tambouras
[EMAIL PROTECTED], West Palm Beach, Florida
Signed pgp-key on key server.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTEC
Rob Browning <[EMAIL PROTECTED]> writes:
> It should just be handled the same way as the menu package.
You are right, it might be possible. You would know that better than
me anyway. But I don't like the idea because it is unnecessary. Why
should a resource-hungry emacs compilation be executed
What the hell is all this crap?!?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> "APH" == Adam P Harris <[EMAIL PROTECTED]> writes:
APH> BTW, are .elc files arch-dependant or arch-indep? I've always
APH> wondered about this.
.elc files are architecture independent. However, they are not
emacs-independent. What happens is:
.elc files compiled with xemacs 19.x or em
On 17-Dec-1997, James Troup <[EMAIL PROTECTED]> wrote:
> Alex Yukhimets <[EMAIL PROTECTED]> writes:
>
> > When doing 'g'roup reply in elm, the e-mail of the person goes into
> > the "To:" header and list address (along with all other thread
> > participant's adresses) to "Cc:" header.
>
> So, umm
On Tue, 16 Dec 1997, Adrian Bridgett wrote:
> /usr/X11R6/bin/pppload -i 2 -p 10
[...]
> /usr/X11R6/bin/pppload $(tail -n +2 /etc/pppload)
[...]
> /usr/X11R6/bin/pppload \
> $(grep -v ^\# \
> $(if [ -r ~/.pppload ]; then \
> echo ~/.pppload; \
> else \
> ec
Quoting Gonzalo A. Diethelm ([EMAIL PROTECTED]):
> You seem to be quite happy with the configuration as it is. Good for
> you. Perhaps you could point out how I could force all of those people
> with broken mailers and/or ideas to use one of your great mail
> clients, so I won't get four, five, six
Sten Anderson <[EMAIL PROTECTED]> writes:
> You are right, it might be possible. You would know that better than
> me anyway. But I don't like the idea because it is unnecessary. Why
> should a resource-hungry emacs compilation be executed just to
> install dpkg-dev? Is it really that important th
"Larry 'Daffy' Daffner" <[EMAIL PROTECTED]> writes:
> > "APH" == Adam P Harris <[EMAIL PROTECTED]> writes:
>
> APH> BTW, are .elc files arch-dependant or arch-indep? I've always
> APH> wondered about this.
>
> .elc files are architecture independent. However, they are not
> emacs-indepe
Rob Browning <[EMAIL PROTECTED]> writes:
> OK, I haven't investigated the compilation resource requirements that
> thoroughly [1],
Well, neither have I, so you are excused :-)
> [1] Though is it really that big a deal as long as it gets forked off
> to the background like the TeX or manpage re
Sten Anderson <[EMAIL PROTECTED]> writes:
> Imagine the initial dselect session. A zillion packages with elisp
> files are being installed simultaneously with one or two emacsen...
No, you'd want to do it like the menu package. If I understand
correctly, menu forks off into the background waitin
James Troup <[EMAIL PROTECTED]> writes:
> o By linking ppp with pam you are dragging libpam0g, libpam0g-util and
> libpwdb0g into base.
>
> This is fine, *as long as* it's been discussed and agreed first, I
> don't like 3 shared library packages being silently dragged into
> base. If we'r
"Gonzalo A. Diethelm" <[EMAIL PROTECTED]> writes:
> Perhaps you could point out how I could force all of those people
> with broken mailers and/or ideas to use one of your great mail
> clients, so I won't get four, five, six or more duplicates of the
> messages sent to the list.
Gnus.
--
TO UNS
Hi,
Also consider the fact that all maintainers may not have
enough resources to have all possible flavours of Emacsen on their
machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule,
Xemacs-no-mule, ...), and keep track of which versions were elc
compatible anyway.
O
Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> In a little while I need to have a discussion with the other two
Rob> emacs maintainers to see what they think (and are willing to
Rob> try). But first I want to make sure we have a clear idea of what
Rob> the issues and possibilities ar
I think the number one question we need to address is whether we want
to support running Xemacs and GNU emacs at the *same* time.
If we do not, it becomes more difficult for users to test out the
other, but it becomes much easier to maintain the emacs setup. I do
not believe that one can sensibly
Rob Browning <[EMAIL PROTECTED]> writes:
> I think that we should have some sort of install procedure (a la
> install-info) for emacs .el files.
We keep going down this route again and again - info, elisp, menu,
mime. Maybe we should generalize this?
Let's provide a system where packages could
On Tue 16 Dec 1997, Karl M. Hegbloom wrote:
> > "James" == James Troup <[EMAIL PROTECTED]> writes:
>
> James> Alex Yukhimets <[EMAIL PROTECTED]> writes:
> >> When doing 'g'roup reply in elm, the e-mail of the person goes
> >> into the "To:" header and list address (along with all o
Rob Browning <[EMAIL PROTECTED]> writes:
> Sten Anderson <[EMAIL PROTECTED]> writes:
>
> > You are right, it might be possible. You would know that better than
> > me anyway. But I don't like the idea because it is unnecessary. Why
> > should a resource-hungry emacs compilation be executed just to
There are now some packages for m68k that make sense only on a
specific machine type. Currently we have such packages only for Atari,
but others can follow easily. The packages are nvram and setsccserial,
and atari-fdisk is about to be debianized.
Those packages are currently Architecture: m68k,
Hi everybody!
> After seven or eight months as Debian's mailing list manager, I'm
> ready for a change of pace. I'd like to offer up the position to any
> interested individual(s).
>
> I'm offering the position because I haven't been spending as many
> late nights at my day job's off
John Hasler <[EMAIL PROTECTED]> is the new dunc package
maintainer and has a new version of it ready for upload. He
needs to complete the verification process and get his
account setup, which he's doing now. Is there anything more
needed? He'll send the announcement as per the guidlines in
the l
Roman Hodek <[EMAIL PROTECTED]> writes:
> There are now some packages for m68k that make sense only on a
> specific machine type. Currently we have such packages only for Atari,
> but others can follow easily. The packages are nvram and setsccserial,
> and atari-fdisk is about to be debianized.
>
> "CL" == Christian Lynbech on satellite <[EMAIL PROTECTED]> writes:
CL: I think the number one question we need to address is whether we
CL: want to support running Xemacs and GNU emacs at the *same* time.
Of course we want. There are some *multiuser* Debian machines. :-)
Milan Zam
> "MS" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
MS: Hi, Also consider the fact that all maintainers may not have
MS: enough resources to have all possible flavours of Emacsen on
MS: their machines (Xemacs19, Xemacs20, emacs19, emacs20,
MS: emacs20-no-mule, Xemacs-no-mule
This is part of an email exchange Sven and I had. Simply put, I put
in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a
recompile to pick up new libg++, ncurses, etc. Sven suggested that
this warranted a non-maintainer-release number, whereas I had gotten
the idea that non-main
Guy Maor <[EMAIL PROTECTED]> wrote:
> When a provider first installed a hook, the system would immediately
> run the hookfile for all clients that already registered. Then
> whenever a new client registered, it would run the hookfile. The
> hookfile would be run with the same arguments that the c
> > After seven or eight months as Debian's mailing list manager, I'm
> > ready for a change of pace. I'd like to offer up the position to any
> > interested individual(s).
> >
> > I'm offering the position because I haven't been spending as many
> > late nights at my day job's office, an
"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
> My first attempt at this was to add these lines to the scripts:
>
> # These variables are for the use of the scripts run by run-parts
> PPP_IFACE="$1"
> PPP_TTY="$2"
> PPP_SPEED="$3"
> PPP_LOCAL="$4"
> PPP_REMOTE="$5"
> export PPP_IFACE
On 17 Dec 1997, Brederlow wrote:
> Roman Hodek <[EMAIL PROTECTED]> writes:
>
> > There are now some packages for m68k that make sense only on a
> > specific machine type.
>
> What about the packages that are arch-all that can be installed on any
> arch but only make sense on one or two architec
> > And there is one thing
> > which I would qualify as a mistake in the above description: $2 is
> > actually in the form "/dev/ttyS1" than just "ttyS1".
>
> Doh! I wish they wouldn't do that. I guess it's for some kinda
> security?
>
> ...A. P. [EMAIL PROTECTED]http://www.onShore.com/>
W
Hi,
>>"Arto" == Arto Astala <[EMAIL PROTECTED]> writes:
Arto> How about rigging emacsen so that when they start they will
Arto> compile these? It may even come as side effect of your scheme
Arto> already?
I rarely need to run Emacs as root, so this will not work for
me (apart from being
Hi,
>>"Guy" == Guy Maor <[EMAIL PROTECTED]> writes:
Guy> For elisp files, it might work like this.
Guy> $ register-service --help register-service --install service
Guy> package [param=value ...] register-service --remove service
Guy> package
Guy> In the dpkg postinst: register-service --install
From: Milan Zamazal <[EMAIL PROTECTED]>
Subject: Re: Taking over production of emacs20 package.
Date: 17 Dec 1997 13:37:49 +0100
> What I would prefer as a user is to have multiple packages:
>
> foo-el.deb
> foo-elc-emacs.deb
> foo-elc-xemacs.deb
> foo-elc-whateveremacs.deb
> ...
>
> I
> This sounds exactly the same as the i386 vs Pentium thing. It's the
> name BASE architecture but different... implementations?
Yep, sounds similar. I haven't closely followed followed the Pentium
discussion (too much traffic here...), but it's obvious that there are
some parallels.
> One solut
Guy Maor <[EMAIL PROTECTED]> writes:
> Gnus.
While I agree that Gnus is the best thing since sliced bread, keep in
mind those in other countries where net access is *much* more
expensive. For these people, deleting the duplicates after they
download them is closing the barn door after the horses
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 fingerprint = E8 0E 0D 04
Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> This is part of an email exchange Sven and I had. Simply put, I put
> in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a
> recompile to pick up new libg++, ncurses, etc. Sven suggested that
> this warranted a non-maintainer-rel
Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> This is part of an email exchange Sven and I had. Simply put, I put
> in a new alpha binary of dpkg-1.4.0.19 that represented nothing but
> a recompile to pick up new libg++, ncurses, etc. Sven suggested
> that this warranted a non-maintainer-rel
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Also consider the fact that all maintainers may not have
> enough resources to have all possible flavours of Emacsen on their
> machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule,
> Xemacs-no-mule, ...), and keep track of which v
[EMAIL PROTECTED] (Christian Lynbech on satellite) writes:
> I think the number one question we need to address is whether we want
> to support running Xemacs and GNU emacs at the *same* time.
The answer is "if it's not an unbelievable technical obstacle, then
yes, we do."
> I do not believe tha
> I think the number one question we need to address is whether we want
> to support running Xemacs and GNU emacs at the *same* time.
Yes, we do want to support running both Emacsen. I don't see how
dropping one for the other can even be considered a viable option.
> If we do not, it becomes mo
-BEGIN PGP SIGNED MESSAGE-
On 17 Dec 1997, James Troup wrote:
> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
>
> > This is part of an email exchange Sven and I had. Simply put, I put
> > in a new alpha binary of dpkg-1.4.0.19 that represented nothing but
> > a recompile to pick up ne
Hi, while looking through some of the code for epic4, I noticed a
reference to sun_len that I recall causing some troubles in the past.
It seems to regard the size of a sockaddr_un, in other words, the
struct that defines a unix domain socket.
The networking Stevens book defines it as:
struct so
Could Apple's Rhapsody be built on top of Mach around Linux rather than
BSD Unix?
How crazy is this idea technically?
(from a non-techie)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
On Sun, 14 Dec 1997, Adrian Bridgett wrote:
> On Sun, Dec 14, 1997 at 03:34:34PM +0100, Marcus Brinkmann wrote:
> >
> > Hello all!
> >
> > I intend to package xscavenger, a lode runner like game (remember the good
> > old commodore 64 days?).
> >
> > To be honest, I already did. I also contac
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> This will not work for packages like Gnus, bbdb, w3,
> hyperbole, vm, and psgml, since the compilation requires selectively
> preloading some files, or even running complex build-scripts during
> the compilation of the elisp files.
Well, I t
This is better.. still no version info, but.. what's the opinion on this?
---
The reason why i used writev() is because on 4.4BSD (and apparantly on
solaris), there is the guarantee that *each and every item so passed*
will be written in one, atomic segment. That is to say, if i pass the
return
> > > And there is one thing
> > > which I would qualify as a mistake in the above description: $2 is
> > > actually in the form "/dev/ttyS1" than just "ttyS1".
> >
> > Doh! I wish they wouldn't do that. I guess it's for some kinda
> > security?
> >
> > ...A. P. [EMAIL PROTECTED]http://www.
Santiago Vila <[EMAIL PROTECTED]> writes:
> This is that way because our package system does not allow several
> binary packages for the same source package. But it should.
[...]
> Again this is a limitation of our current source|binary packaging
> scheme. Does not mean it has to be that way.
Avery Pennarun writes:
> I see a couple of problems with this. First, "-i 2 -p 10" makes a bit of a
> silly looking configuration file. Secondly, placing any of the above
> commands in your "menu" entry seems wrong to me -- if the user runs pppload
> from the command line, he doesn't get the
On 17 Dec 1997, James Troup wrote:
[snip]
> If the binary changes, the version number should change.
Completely agreed. Everything else will only result in a big mess.
I'll check our how I can make policy more clearly on this point and
include something in the next policy weekly posting.
Thank
On Mon, 15 Dec 1997, Ian Jackson wrote:
> Hamish Moffatt:
> > Is the regular maintainer required to apply the diff? In doing
> > some non-maintainer upgrades just for libc6 reasons, I have
> > fixed some bugs where these are readily fixed. If the non-maintainer
> > work does not have to be used, t
I'm trying to split up the GIMP package, so that other packages that
use libgimp et al don't have to depend on the humungous gimp package.
Since the gimp source tree makes three shared libraries -- libgimp,
libgimpui, and libgck, I made a debian/shlibs.local file containing
the lines:
libgimp 1 l
Philip Hands writes:
> If people really think it is necesary I can add:
> PPP_TTYNAME=`/usr/bin/basename "$2"`
> export PPP_TTYNAME
> to the ip-{up,down} scripts.
Please do. The pppd man page is not at all clear on this point. This
addition could save a user trying to get a script working a
The XEmacs team is working on unbundling much of the elisp that used
to be included. There is a new set of functions for building and
adding packages' autoloads and `customize' dependancies. I believe
(though I am not certain) that it will require there be a `temacs'
installed, and that XEma
68 matches
Mail list logo
