Why isn't STREAM_MAX == FOPEN_MAX?
[ sent to debian-devel, and bcc'd to the local user's group ] Please direct me to where I ought to be asking this question so that I'm most likely going to get an answer, if here's not the place. I'm working the examples in "Advanced Programming in the UNIX Environment", by W. Richard Stevens. In chapter 2, "Unix Standardization and Implementations", the first program is one that calls on the `sysconf' and `pathconf' functions to print various limits. On my system, which has several kernel patches and one patch to "types.h" applied[1] (hence the large value for OPEN_MAX), the program produces the following output: 504$ ./print-limits . ARG_MAX = 131072 CHILD_MAX = 999 clock ticks/second = 100 NGROUPS_MAX = 32 OPEN_MAX= 3000 STREAM_MAX = 8 < Isn't this too low? TZNAME_MAX = 3 _POSIX_JOB_CONTROL = 1 _POSIX_SAVED_IDS= 1 _POSIX_VERSION = 199309 MAX_CANON = 255 MAX_INPUT = 255 _POSIX_VDISABLE = 0 LINK_MAX= 127 NAME_MAX= 255 PATH_MAX= 1024 PIPE_BUF= 4096 _POSIX_NO_TRUNC = 1 _POSIX_CHOWN_RESTRICTED = 1 On page 36, there is a table (figure 2.5), and in that table, it says, under STREAM_MAX, that "if defined, it must have the same value as FOPEN_MAX". A `gid' search for FOPEN_MAX turned it up in "stdio_lim.h", defined as 256. STREAM_MAX is defined in "xopen_lim.h" as _POSIX_STREAM_MAX, which in turn is defined in "posix1_lim.h" as 8. Q: Shouldn't STREAM_MAX = FOPEN_MAX, as stated in "APUE"? I'm just a beginner, and have no way of knowing how these defines are used in real life, or whether the values are reasonable or not. Footnotes: [1] I've applied the patches from www.linuxhq.org for max num subprocesses, max open files, and max socket conn. The "types.h" patch changes __FD_SET_SIZE. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
gone for a week
I will be traveling from the 16th to the 23rd, and won't be able to work on my packages. I'd appreciate non-maintainer releases if anything serious comes up. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
On Mon, 15 Dec 1997, Brian Bassett wrote: > I recently switched to Debian from RedHat 4.2 and the one thing that I > think that Debian could really use is an administration tool. > > Thus, I've decided to try and write such a tool. I've set up a webpage > (http://www.butterfly.ml.org/debadmin/) and a mailing list (instructions > at the webpage). If you are interested in helping, feel free to subscribe > to the list and offer any advice. The current plan calls for three > interfaces (text-based curses, X, and Web/CGI). I think that the project > would be benefitted by anyone who has experience programming X or X > toolkits, or Perl CGIs. There are several Linux configuration projects going on already. It would be nice not to duplicate effort, so you might want to start a new one only if an existing system can't be extended to do what you want. See also: - The Dotfile Generator - Linuxconf - cfengine - COAS (Caldera's thingy at http://www.caldera.com) - figurine - kde/gnome have config systems I think. My web page about the "perfect" configuration system lists most things I've thought of on this subject: http://www.worldvisions.ca/~apenwarr/figurine/ideal.html (this is part of figurine, which is on indefinite hold at the moment) Have fun, Avery -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
> "Brian" == Brian Bassett <[EMAIL PROTECTED]> writes: Brian> The current plan calls for three interfaces (text-based Brian> curses, X, and Web/CGI). `deity' works on console, xterm, and X. Perhaps you can utilize that toolkit? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
> "Enrique" == Enrique Zanardi <[EMAIL PROTECTED]> writes: Enrique> Any ideas? `publib' has some editor buffer stuff in it... could you use that somehow? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Buffer overrun in Redhat 5.0 (fwd)
Hi,
This concerns a potential buffer overrun problem with glibc2 -- wanted to
make sure that the relevant Debian people were aware of it. I'm not
running a hamm system anymore so I can't test it against the Debian libc6.
TL
-- Forwarded message --
From: Wilton Wong - ListMail <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Mon, 15 Dec 1997 06:57:45 -0700
Subject: Re: Buffer overrun in Redhat 5.0
So far I've gotten a few reports back saying that my trace_sehll program
doesn't work as expected, all I can say is it worked for me. In most cases
it just returned "XXX..XXX: host unknown" or something similar..
BUT if you increased the buffer size the programs still segfaults,
although they do not immediatly yield a root shell..
A buffer overrun != a root shell in all cases, although in about 99% of
them they do, the problem is finding the right spot to put the shellcode
or whatever it is that you want the thing to return..
Getting root is not important here, what is important is that there is a
buffer overrun and you can get at it, whether or not you can get a shell
out of it is irrelavent, a buffer overrun is shoddy programming on
someone's part and that's the real problem not if you can get root or
not. Root is just a bonus, and yes it's nice but..
Story thus far:
Okay I noticed that if I ran tracroute with a really long param it
segfaults and I wondered if I could exploit this, I could, I checked to
see that I didn't have a twisted version of traceroute, I didn't, so I
tried ping as well same result. That's when I posted.
Then almost immediatly afterward I also notice rsh and rlogin as they too
were suid and I posted that too..
Then I noticed I could also segfault telnet.. that was odd..
I downloaded sources for all of there and built them myself and scanned
thru most of the code to see if there were any obviuos holes there wern't
I wasn't expecting to find any as these program come standard with almost
every OS.
The problem lise deep within one of the libraries.. glibc2 joy... the
programs themselves are not vulnerable. For example a simple program like
this should in no cases yield a segfault:
vulnerable.c
#include
void main(int argc, char *argv[]) {
struct hostent *hostinfo = 0;
if (argc > 1) {
hostinfo = gethostbyname(argv[1]);
}
if(hostinfo)
printf("Host name: %s\n", hostinfo->h_name);
}
but it can be made to segfault with a extra long parameter..
The gdb output wasn't much help:
---
[EMAIL PROTECTED]:~/src/test$ ./vulnerable `buff-over`
Segmentation fault (core dumped)
[EMAIL PROTECTED]:~/src/test$ gdb vulnerable core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-redhat-linux), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `./vulnerable
XX'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error
#0 0x2e726174 in ?? ()
(gdb) bt
#0 0x2e726174 in ?? ()
#1 0x74656e in ?? ()
Cannot access memory at address 0x736b6361.
(gdb) quit
[EMAIL PROTECTED]:~/src/test$
---
Ahh.. symbolic names of ?? and ?? I know what that is brilliant!!
But the strace of it shows that before the program segfaults it opens
libresolve, and I suspect that is where the overrun lies..
Why it will yield a root shell for me and not for you I don't know..
could be a million number of things all I know is that there is a buffer
overrun and for me it is exploitable... =)
- Wilton
-
Wilton WongBlackStar Communications
URL: http://www.blackstar.net 16121 - 57 Street
Email: [EMAIL PROTECTED] Edmonton AB T5Y 2T1
Tel: (403) 486-7783 Fax: (403) 484-6004
-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
On Mon, 15 Dec 1997, Brian Bassett wrote: > I recently switched to Debian from RedHat 4.2 and the one thing that I > think that Debian could really use is an administration tool. I suggested something similar a couple weeks ago and was informed that this discussion had taken place already. I guess the general consensus was that we (the Debian folks) should wait for the COAS project (http://www.caldera.com/coas/) to come to fruition. COAS looks to be promising. Caldera's outlines for it call for it to have curses (text), X, and web interfaces. Supposely, the front-ends will interact with "configurators" for the various installed packages. The configurators would, ostensibly, be provided with their respective packages. Caldera even went so far as to stipulate that configurators have to display some sort of intelligence (for example, not letting people enter octets higher than 255 in IP addresses). Caldera says that it's all going to e GPL'd. The only question now is, how long it is going to take. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How to detach debug symbols from libraries
Fabrizio Polacco writes: > Yann Dirson wrote: > > Problem: it's really a mmap image (thus works only for executables, > > not libs), and includes the libs symbols: > > > > But the real problem is that the sizes are ... unmanageable > the shared lib is half the size of the static one, while the .syms file > is double! > -rw-r--r-- 12242044 Dec 13 19:20 libdb2.a > -rwxr-xr-x 11129332 Dec 13 19:18 libdb2.so > -rw-r--r-- 15246976 Dec 15 13:26 libdb2.so.syms Does gdb reads in the libs yours depends on ? This might explain that... > So I loose all interest in using .syms files instead of unstripped > static libs. OK. Did you try objcopy(1) ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
I stand corrected. DebAdmin looks dead before it gained life. A note to whoever is now maintaining the WNPP list: You probably want to remove the mention from section 7 about the need for an admin tool. Brian On Mon, 15 Dec 1997, Joe Emenaker wrote: > > On Mon, 15 Dec 1997, Brian Bassett wrote: > > > I recently switched to Debian from RedHat 4.2 and the one thing that I > > think that Debian could really use is an administration tool. > > I suggested something similar a couple weeks ago and was informed that > this discussion had taken place already. I guess the general consensus was > that we (the Debian folks) should wait for the COAS project > (http://www.caldera.com/coas/) to come to fruition. > > COAS looks to be promising. Caldera's outlines for it call for it to have > curses (text), X, and web interfaces. Supposely, the front-ends will > interact with "configurators" for the various installed packages. The > configurators would, ostensibly, be provided with their respective > packages. Caldera even went so far as to stipulate that configurators have > to display some sort of intelligence (for example, not letting people > enter octets higher than 255 in IP addresses). > > Caldera says that it's all going to e GPL'd. The only question now is, how > long it is going to take. > > - Joe > > > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
freeciv needs help (1 of 2)
Folks, Richard emailed me this. Unfortunately, I won't have time to deal with this. And I don't even know what freeciv is ... It would be great if someone else could help out. Thanks, Dirk --- Begin Message --- Hi. I will be in Sweden until next Monday, perhaps you've seen my mail to debian-devel about that. I wonder if I might impose on you :) You see, there is an upstream release in the works for FreeCiv, a Civilization clone for X11. It will be released this Wednesday evening. I'd like to package it up right away, since they're really gung-ho about the release and a quick response from Debian would be a morale booster. I like to encourage free games since that's the area where free software seems weakest. I've already explained to them that I'll be gone for a week, but it would be nice if you or someone else packaged it up instead of me. I'm asking you because I won't be able to coordinate this, being in Sweden and all :-) I'll include the debian-diffs I made for the beta version that was released last week. That one worked fine, but I don't know what has changed in the meantime. My apologies for not bringing this up sooner. I didn't realise until today that their date for the release would be right in the middle of my trip. Richard Braakman -- [EMAIL PROTECTED] According to the latest official figures, http://rosebud.ml.org/~edd43% of all statistics are totally worthless. --- End Message ---
freeciv needs help (2 of 2)
Here are the diffs related to the (1 of 2) mail.
Thanks, Dirk
--- Begin Message ---
--- freeciv-1.4.3.orig/common/registry.c
+++ freeciv-1.4.3/common/registry.c
@@ -187,7 +187,8 @@
}
}
- fclose(fs);
+ if (ferror(fs) || fclose(fs) == EOF)
+return 0;
return 1;
}
--- freeciv-1.4.3.orig/debian/changelog
+++ freeciv-1.4.3/debian/changelog
@@ -0,0 +1,77 @@
+freeciv (1.4.3-1) unstable; urgency=low
+
+ * New upstream source (BETA).
+ * Renamed README.debian to README.Debian.
+ * Recommend at least version 0.10 of xaw-wrappers.
+ * Don't make clean target depend on configure target.
+
+ -- Richard Braakman <[EMAIL PROTECTED]> Thu, 4 Dec 1997 17:52:15 +0100
+
+freeciv (1.0k-4) unstable; urgency=low
+
+ * Added entries for (libc5) xaw3d and nextaw to xaw-wrappers file,
+to avoid coredumps.
+ * Added entry for compat xaw95 and libc6 xaw95g even though they
+do not exist yet.
+ * Oops, when I made freeciv recommend xaw-wrappers I accidentally
+made it recommend (rather than depend on) its shared libraries too.
+Fixed.
+
+ -- Richard Braakman <[EMAIL PROTECTED]> Mon, 17 Nov 1997 13:07:25 +0100
+
+freeciv (1.0k-3) unstable; urgency=low
+
+ * Added note by upstream author to README.debian.
+ * Patched save-game routine to check for write errors. (#11521)
+
+ -- Richard Braakman <[EMAIL PROTECTED]> Mon, 17 Nov 1997 11:53:25 +0100
+
+freeciv (1.0k-2) unstable; urgency=low
+
+ * Installed config entry for xaw-wrappers, because freeciv requires
+the original Xaw library.
+ * Recommend xaw-wrappers for that reason.
+ * Previous changelog was incorrect: I decided not to install menu
+entries after all, because the programs are not very useful when
+run without flags.
+
+ -- Richard Braakman <[EMAIL PROTECTED]> Sun, 9 Nov 1997 12:01:12 +0100
+
+freeciv (1.0k-1) unstable; urgency=low
+
+ * New maintainer.
+ * New upstream release.
+ * Use pristine upstream source.
+ * Application defaults file no longer a conffile. (fixes bug #11230)
+ * Changed debian/rules layout.
+ * Use debian-specific civ script, changed $* to ${1+"$@"}. (fixes bug #10157)
+ * Removed "ser" script; it just called civserver and polluted the namespace.
+ * Recompiled for libc6. (fixes bug #12953)
+ * Installed menu entries for server and client.
+
+ -- Richard Braakman <[EMAIL PROTECTED]> Thu, 6 Nov 1997 21:46:14 +0100
+
+freeciv (1.0j-2) unstable; urgency=low
+
+ * Imakefile: set XAWLIB to use libXaw.
+
+ -- Karl Sackett <[EMAIL PROTECTED]> Thu, 5 Jun 1997 09:47:47 -0500
+
+freeciv (1.0j-1) unstable; urgency=low
+
+ * New upstream release.
+ * freeciv library files moved to /usr/lib/games/freeciv, FREECIV_
+DATADIR changed accordingly.
+
+ -- Karl Sackett <[EMAIL PROTECTED]> Mon, 26 May 1997 11:26:48 -0500
+
+freeciv (1.0i-1) unstable; urgency=low
+
+ * First Debian release.
+ * civ: FREECIV_DATADIR set to /usr/games/freeciv/data.
+
+ -- Karl Sackett <[EMAIL PROTECTED]> Tue, 1 Apr 1997 10:37:50 -0600
+
+Local variables:
+mode: debian-changelog
+End:
--- freeciv-1.4.3.orig/debian/control
+++ freeciv-1.4.3/debian/control
@@ -0,0 +1,20 @@
+Source: freeciv
+Section: games
+Priority: optional
+Maintainer: Richard Braakman <[EMAIL PROTECTED]>
+Standards-Version: 2.3.0.1
+
+Package: freeciv
+Architecture: any
+Depends: ${shlibs:Depends}
+Recommends: xaw-wrappers (>= 0.10)
+Description: A free Civilization clone for Unix and X.
+ FreeCiv is a clone of Civilization, distributed under the GPL and
+ implemented for X. Freeciv is a turn-based strategy game, in which
+ each player becomes leader of a civilization, fighting to obtain
+ the ultimate goal: The extinction of all other civilizations.
+ .
+ FreeCiv recommends xaw-wrappers because it requires the original
+ Xaw library and cannot work with replacements like xaw3d and nextaw.
+ The xaw-wrappers package is necessary if you have such replacement
+ libraries installed.
--- freeciv-1.4.3.orig/debian/copyright
+++ freeciv-1.4.3/debian/copyright
@@ -0,0 +1,28 @@
+This is the Debian GNU/Linux prepackaged version of freeciv.
+
+This package was put together by Karl Sackett <[EMAIL PROTECTED]>.
+Maintenance was taken over by Richard Braakman <[EMAIL PROTECTED]>.
+
+The sources were obtained from:
+
+ ftp://ftp.daimi.aau.dk/pub/stud/pjunold/freeciv/freecivdec4.tgz
+
+For more information see:
+
+ http://www.daimi.aau.dk/~allan/freeciv.html
+
+Freeciv is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 2, or (at your option) any
+later version.
+
+Freeciv is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License with
+your Debian GNU/Linux system, in /usr/doc/copyri
Re: Work-Needing and Prospective Packages for Debian GNU/Linux
wnpp> o Removed perl documentaion from works in progress, as the wnpp> provided manpages are sufficient. There really needs to be a `perl-info' package, with the Perl TeXinfo docs in it. `cperl-mode' in the emacs editors has the ability to look up perl functions in the info. It's indispensable. Yes, I should `bug' the maintainer... ;-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
> (I need that to display messages directed to stderr from busybox when
> linked to a Slang program, as in:
Uh? Why don't you just do...
int p[2];
pipe(p);
if(!fork())
{
dup2(p[1],2);
exec...
}
/* now you can read the output from the p[0] file descriptor... */
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
A. P. Harris 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/.
> This would allow, for instance, MTA packages to ship little scripts to
> flush the mail queue when the link comes up, pop-deamons to start up,
> bind to reload, clock sync daemons to re-sync, firewall and masquerading
> rules to run, and dynamic PPP hosts to update some file on some server
> indicating their current IP.
This a good idea, as long as we make sure the user knows about it and can
shut it off. Otherwise it will be rather inconvenient for people who don't
always connect to the same server, or who use ppp as a poor man's LAN, as I
do.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Karl M. Hegbloom writes: > I think the main thing is that a person with very little experience > should be led through the initial setup by a script, at the very least. > It would be good to tell them about `minicom', with some instructions on > how to use it to get the info they need to construct a working chat > script. I hope to address this with dunc (which I expect to be taking over soon). I am presently of two minds as to whether I should develop dunc into a powerful and general pppconfig tool, or just write a simple but limited script. How fast are isp's converting to pap? No point in putting a lot of work into dealing with chatscripts if they are going away soon. Does mschap require any special user configuration? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
> So do I. I first asked Christoph for this back in the spring, and I've since > asked Phil Hands about it when he took over the package and I've seen nothing > happen yet.. It's on my TODO list. I was intending to release a package including this this evening, but I've just wasted a couple of hours trying to get MSCHAP to do something useful :-( (BTW has anyone got this stuff working ?). Anyway, I may have chance to do something about it tomorrow. On a related topic: I thought I'd call the PAM-free ppp package ppp-base, like perl-base. I'm still not sure about the best way to do this though. It looks like the only thing that needs to be different is the pppd binary, so: Should I make ppp contain only the pppd with PAM binary, and have it depend on ppp-base (which would contain most of the rest of ppp), and use alternates on pppd ? Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Yann Dirson <[EMAIL PROTECTED]> writes:
> Adam P. Harris 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/.
> >
> > This would allow, for instance, MTA packages to ship little scripts to
> > flush the mail queue when the link comes up, pop-deamons to start up,
>
> I had the idea of adding such actions (flush mailqueue, fetch mail,
> etc.) to my ip-up, but I didn't do that.
>
> This is because some of these actions (eg. mail fetching) may be quite
> long to complete, and may act badly if interrupted by a 'poff'
> (eg. fetched messages from the interrupted session not erased from my
> POP account - guess it's a security feature in fetchmail).
>
> The solution I used was to manually ask to fetch my mail. Another
> would be to have a (hopefully generic) mean of forcing the line to
> stay up while such an action is taking place. But I'm not sure it
> would be a good solution either, since fetching 200 mails/day from the
> debian lists takes some time, and then the user would be compelled to
> want till fetch is done.
>
> In other words:
>
> * we can't decide for the sysadmin what actions will take place on
> boot.
>
> * if we build such a system, a standard way of disabling parts of
> these directories (maybe like what /etc/init.d/rc allows with 'S' and
> 'K' names ?)
Yes. Definitely ensure that it is easy to disable (and of course
re-enable) these automatic scripts, and ship everything _off_ by default.
IMO nothing is more annoying than these kind of surprises. I want to
know what is being started when I dial into my ISP.
For example, I have configured my ip-up script to start fetchmail (in
daemon mode) and grab articles for my local news spool unless the file
/etc/no_mail exists. Therefore, if I need to quickly dial in, say to
fetch a file, I create this file before starting pppd so that I can
hang up as soon as I am done without waiting for POP and NNTP transfers
to finish.
Brian
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Strange mail problem
liiwi> Hello! I'm having trouble with fetchmail and procmail. The trouble liiwi> is that fetchmail ignores the 'mda "formail -s procmail"' line liiwi> totally and delivers all mail to port 25. nice. I can't remember, liiwi> how many times I have checked everything. Which version are you using? The following works with 4.3.4-1, and has been for a long time with older versions: ~/.fetchmailrc - defaults fetchall mda "formail -s procmail" # mda "/usr/bin/formail -s procmail" stripcr poll some.pop.server.net protocolapop usersomeuser passwordsomepassword ~/.fetchmailrc - but notice how I used to use a complete path to formail as fetchmail (2.x or 3.x) used fail at bott. -- [EMAIL PROTECTED] According to the latest official figures, http://rosebud.ml.org/~edd43% of all statistics are totally worthless. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: SPI money out
On 14 Dec, [EMAIL PROTECTED] wrote: > More expected money out: > > About $2000 for the 501(c)3 non-profit status. This > was waiting for all those papers we were fedexing around. > > We have an undedicated $2000 to $3000 to spend on Debian and other > SPI programs. Part of this was supposed to be for trade-show travel, but > the shows are paying my expenses - anyone else speaking? I figure the 2.0 > release and its successors should bring our income back to the $1000/month > level. Also, we might do an official T-shirt, which will bring in bucks, too. > > Bruce > Sir, I would also like to suggest a print or two. I do not know if this idea would actually make money, but I would buy one. I know the official logo is the first priority. But, with all the entries in the logo contest, you would not be lacking for material for a wide variety of pictures. -- Dale James Thompson ([EMAIL PROTECTED]) He who wonders discovers that this in itself is wonder. -- M.C. Escher -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
"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]>
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] .
Taking over production of emacs20 package.
Mark recently informed me that he'd accepted my offer to work on the new emacs20 package. I just wanted to let everyone know that I was getting started. I'd like to get something out very soon, but the holidays may interfere a little. Feel free to let me know if you have suggestions 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 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] .
Re: SPI money out
> I would also like to suggest a print or two. I do not know if this > idea would actually make money, but I would buy one. Uh-oh, you moved this topic from the other mailing list. Consider your knuckles rapped :-) No harm done this time, but be careful. We were discussing t-shirts and such for fund-raising, which we will definitely have. Art prints? Hm. Perhaps we can get Simon to make a signed and numbered penguin. Thanks Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: status of bzip
Paul Slootman <[EMAIL PROTECTED]> writes: > So, perhaps the bunzip code could be included in the bzip2 package; That sounds like the best idea. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
sell
DEAR SIRS: 1. We produce items as follows: [EMAIL PROTECTED]@ ILLEX SOUID CLEANED TUBE Origin of squid is Argentina. We also can offer Milkfish and Tilapia. [EMAIL PROTECTED]@ We'll give you best price&good quailty. 2. We are more than eager to make you satisfied with quick and precise service. We hope we can have a long term, mutually beneficial business relationship with you. We shall be grateful if you could give us details and information of your company needs. Thank you, please contact us soon. Tony Fu President -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
(no subject)
DEAR SIRS: 1. We produce items as follows: [EMAIL PROTECTED]@ ILLEX SOUID CLEANED TUBE Origin of squid is Argentina. We also can offer Milkfish and Tilapia. [EMAIL PROTECTED]@ We'll give you best price&good quailty. 2. We are more than eager to make you satisfied with quick and precise service. We hope we can have a long term, mutually beneficial business relationship with you. We shall be grateful if you could give us details and information of your company needs. Thank you, please contact us soon. Tony Fu President -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: I take debmake
Joey Hess <[EMAIL PROTECTED]> writes: > With debmake, new functionality was added all the time, and was added into > the same debstd program, changing its behavior, and so different versions > could have widly differing results on the same package. > > With debstd, each individual program has a well-defined job, and so their > behavior will not change, execpt for bugfixes, and to comply with changes > in debian policy. I'm sure you realize that this is not a very good argument. "To comply with changes in debian policy" means that Rob's sample conversation could still take place. An extremist might argue that we should include the source for gcc, binutils, perl, along with the package as a change in them could also affect the build. It's all a matter of how volatile the tools are: debmake debstd gcc, binutils, make, ... high medium low On this scale, we draw a line somewhere. Everything to the left of the line we either can't use or must include the source for. Everything to the right is ok. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
(no subject)
DEAR SIRS: 1. We produce items as follows: [EMAIL PROTECTED]@ ILLEX SOUID CLEANED TUBE Origin of squid is Argentina. We also can offer Milkfish and Tilapia. [EMAIL PROTECTED]@ We'll give you best price&good quailty. 2. We are more than eager to make you satisfied with quick and precise service. We hope we can have a long term, mutually beneficial business relationship with you. We shall be grateful if you could give us details and information of your company needs. Thank you, please contact us soon. Tony Fu President -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
[EMAIL PROTECTED] writes: > How fast are isp's converting to pap? No point in putting a lot of > work into dealing with chatscripts if they are going away soon. I believe that there will soon (if not already) be very few ISPs which don't support PAP or CHAP. chat isn't going to be used for anything except dialing the modem. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Questions about emacs20 file system layout.
The newer emacs source wants to put some files in /usr/share/emacs and /usr/libexec/emacs by default. The emacs 19 package put all these files together in /usr/lib/. I would assume /usr/share is now OK since it's in the FSSTND (to some extent) and other packages are using it, but what 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 PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Philip Hands <[EMAIL PROTECTED]> writes: > I thought I'd call the PAM-free ppp package ppp-base, like perl-base. > I'm still not sure about the best way to do this though. It looks like the > only thing that needs to be different is the pppd binary, so: > > Should I make ppp contain only the pppd with PAM binary, and have it depend > on > ppp-base (which would contain most of the rest of ppp), and use alternates on > pppd ? That sounds pretty complicated with little gains. What's the disadvantage of having PAM in the normal pppd. More complicated to setup? Much bigger binary? Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems compiling packages
Martin Schulze <[EMAIL PROTECTED]> writes: > I'd suggest that all such packages only try to compile and package the > libc5 packages if there is a libc5 installed. No, that's a bad idea. A package might silently build incorrectly because a developer didn't have libc5 or libc5-dev installed. Unfortunately hard-coding the architectures which do (or don't) have libc5 isn't very aesthetic. Does anybody have a better idea? Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
intent to package nmap
For the record: I have need of a port scanner tonight, I don't see one packaged, I happen to like nmap, and I see no record that anyone else has indicated they are packaging it... Expect a package upload shortly... I've got the sources reworked for libc6, and am finishing up the package now. For the impatient and/or curious, nmap is documented at http://www.dhp.com/~fyodor/nmap/ Bdale -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Why isn't STREAM_MAX == FOPEN_MAX?
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: > STREAM_MAX is defined in > "xopen_lim.h" as _POSIX_STREAM_MAX, which in turn is defined in > "posix1_lim.h" as 8. I agree that defining STREAM_MAX as _POSIX_STREAM_MAX is a bug, and that you should file a bug with `glibcbug'. The _POSIX_*_MAX defines are (somewhat confusingly) actually minimums that a system has to provide in order to be POSIX compliant. You are always guaranteed that foo_MAX >= _POSIX_foo_MAX on a POSIX system. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
`cvs add' is dumping core
Has anyone else had trouble with `cvs add' dumping core? I've tried upgrading to the latest `diff', various libc6's, and the hexagram key. Nothing helps. What could be wrong with it? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Thinking about packaging sash
The README says: The purpose of this program is to make replacing of shared libraries easy and safe. It does this by firstly being linked statically, and secondly by including many of the standard utilities within itself. I needed it the other day. And maybe other's could need it, too. So maybe I package it up. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ppp & pam (was: Re: ppp's ip-{up,down} and possible utilization of 'run-parts')
> Philip Hands <[EMAIL PROTECTED]> writes: > > > I thought I'd call the PAM-free ppp package ppp-base, like perl-base. > > I'm still not sure about the best way to do this though. It looks like the > > only thing that needs to be different is the pppd binary, so: > > > > Should I make ppp contain only the pppd with PAM binary, and have it > > depend on ppp-base (which would contain most of the rest of ppp), and > > use alternates on pppd ? > > That sounds pretty complicated with little gains. What's the > disadvantage of having PAM in the normal pppd. More complicated to > setup? Much bigger binary? ppp is needed for doing an install from the internet via a dialup link. PAM is not needed until you want people to log into the system, so libpam is a waste of space on the install disks. I'm not certain it's worth the effort either, since libpam is only 21k and binary is almost exactly the same size (112 bytes bigger) --- opinions ? BTW does libpam0 need to be recompiled for libc6 before I can use it in ppp ? Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: ppp & pam (was: Re: ppp's ip-{up,down} and possible utilizati on of 'run-parts')
libc6 version of libpam0 is in incoming.
Michael
--
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED] | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> -Original Message-
> From: Philip Hands [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, December 16, 1997 11:30 AM
> To: debian-devel@lists.debian.org
> Subject: ppp & pam (was: Re: ppp's ip-{up,down} and possible
> utilization of 'run-parts')
>
> > Philip Hands <[EMAIL PROTECTED]> writes:
> >
> > > I thought I'd call the PAM-free ppp package ppp-base, like
> perl-base.
> > > I'm still not sure about the best way to do this though. It looks
> like the
> > > only thing that needs to be different is the pppd binary, so:
> > >
> > > Should I make ppp contain only the pppd with PAM binary, and have
> it
> > > depend on ppp-base (which would contain most of the rest of ppp),
> and
> > > use alternates on pppd ?
> >
> > That sounds pretty complicated with little gains. What's the
> > disadvantage of having PAM in the normal pppd. More complicated to
> > setup? Much bigger binary?
>
> ppp is needed for doing an install from the internet via a dialup
> link. PAM is not needed until you want people to log into the system,
> so libpam is a waste of space on the install disks.
>
> I'm not certain it's worth the effort either, since libpam is only 21k
> and binary is almost exactly the same size (112 bytes bigger) ---
> opinions ?
>
> BTW does libpam0 need to be recompiled for libc6 before I can use it
> in ppp ?
>
> Cheers, Phil.
>
>
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe"
> to
> [EMAIL PROTECTED] .
> Trouble? e-mail to [EMAIL PROTECTED] .
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-devel subscriber count
-Original Message- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org Date: Saturday, December 13, 1997 2:39 PM Subject: Debian-devel subscriber count >Goodness gracious. Debian-devel has >400 subscribers. Must be a lot of >lurkers. > > Bruce > > >-- >TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to >[EMAIL PROTECTED] . >Trouble? e-mail to [EMAIL PROTECTED] . > I am not a Debian developer, but a Linux kernel developer(H.323 video conferencing). I watch debian-devel to learn, and keep up-to-date on new programs coming out. I also plan on eventually releasing a H.323 proxy in deb format. Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H323 effort. Email http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with http://wwp.mirabilis.com/3375265 - Page Me the word subscribe in the body. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
Mark W. Eichin <[EMAIL PROTECTED]> wrote: > ps. Of course the behaviour in paragraph 2 has nothing to do with unix > either; unix terminal handling is far too primitive for that. Long > Live Multics :-) Of course, nowadays the "interact" command under expect can easily handle this kind of thing... -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Moving topics from debian-private (was Re: SPI money out)
Tyson Dowd: > A couple of us discussed this (and other problems with the mailing > list), in the thread "Duplicate messages on this list" in debian-devel > about a week ago and eventually came to a standstill where most people > in the discussion were happy with the following solution: > > Set the mailing lists up so that the headers are munged > in the following way: > [deleted] Please let noone think that just because that absurd and awful suggestion was the last thing anyone said that everyone is happy with it. Rather, the rest of us have more important things to do than to fight battles with people with broken mailers and broken ideas about how mailers ought to work. The list configuration should be left the way it is. Ian. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
SPAM to mailing lists! STOP NOW.
Dear Postmaster, PLEASE STOP this SPAM now. This is SPAM, because is unsolicited and unwanted. If there is no notice from you that it has been fixed, you and maybe all your domain and your ip-networks will be blackholed at maps.vix.com (see http://maps.vix.com for more information) There is no excuse, the same message has been mailed to the list *THREE* times. Stop unauthorized relaying by outsiders, use anti-spam software like Qmail, http://www.qmail.org/ If you are using sendmail, look at http://www.sendmail.org/, you can install anti-spam sendmail.cf rules. For more information on SPAM in general, see http://spam.abuse.net/ Regards, Roberto Lumbreras [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391 Lander Internet, Madrid-Spain-UE; http://www.lander.es -- Forwarded message -- Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 9013 invoked from network); 16 Dec 1997 07:52:19 - Received: from lince.lander.es ([EMAIL PROTECTED]) by leon.lander.es with SMTP; 16 Dec 1997 07:52:19 - Received: (qmail 10966 invoked by alias); 16 Dec 1997 07:52:18 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 10961 invoked from network); 16 Dec 1997 07:52:16 - Received: from debian.novare.net (205.229.104.5) by lince.lander.es with SMTP; 16 Dec 1997 07:52:16 - Received: (qmail 11493 invoked by uid 38); 16 Dec 1997 07:43:33 - Resent-Date: 16 Dec 1997 07:43:33 - Resent-Cc: recipient list not shown: ; X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 11395 invoked from network); 16 Dec 1997 07:43:27 - Received: from ns.tp.silkera.net ([EMAIL PROTECTED]) by 205.229.104.5 with SMTP; 16 Dec 1997 07:43:27 - Received: from pc (ts076.56K.tp.silkera.net [203.70.2.96]) by ns.tp.silkera.net (8.8.5/8.8.4) with ESMTP id PAA17725 for ; Tue, 16 Dec 1997 15:44:45 +0800 (CST) Message-ID: <[EMAIL PROTECTED]> Date: Tue, 16 Dec 1997 15:53:34 +0800 From: tony <[EMAIL PROTECTED]> X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: debian-devel@lists.debian.org Subject: sell X-Priority: 3 (Normal) Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"zGvqBC.A.VyC.kEjl0"@debian> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/12593 X-Loop: debian-devel@lists.debian.org Precedence: list Resent-Sender: [EMAIL PROTECTED] DEAR SIRS: 1. We produce items as follows: [EMAIL PROTECTED]@¡@ ILLEX SOUID CLEANED TUBE Origin of squid is Argentina. We also can offer Milkfish and Tilapia. [EMAIL PROTECTED]@¡@ We'll give you best price&good quailty. 2. We are more than eager to make you satisfied with quick and precise service. We hope we can have a long term, mutually beneficial business relationship with you. We shall be grateful if you could give us details and information of your company needs. Thank you, please contact us soon. Tony Fu President -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- Forwarded message -- Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 9023 invoked from network); 16 Dec 1997 07:52:42 - Received: from lince.lander.es ([EMAIL PROTECTED]) by leon.lander.es with SMTP; 16 Dec 1997 07:52:42 - Received: (qmail 10983 invoked by alias); 16 Dec 1997 07:52:41 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 10980 invoked from network); 16 Dec 1997 07:52:40 - Received: from debian.novare.net (205.229.104.5) by lince.lander.es with SMTP; 16 Dec 1997 07:52:40 - Received: (qmail 11983 invoked by uid 38); 16 Dec 1997 07:44:03 - Resent-Date: 16 Dec 1997 07:44:01 - Resent-Cc: recipient list not shown: ; X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 11791 invoked from network); 16 Dec 1997 07:43:50 - Received: from ns.tp.silkera.net ([EMAIL PROTECTED]) by 205.229.104.5 with SMTP; 16 Dec 1997 07:43:50 - Received: from pc (ts076.56K.tp.silkera.net [203.70.2.96]) by ns.tp.silkera.net (8.8.5/8.8.4) with ESMTP id PAA17754 for ; Tue, 16 Dec 1997 15:45:09 +0800 (CST) Message-ID: <[EMAIL PROTECTED]> Date: Tue, 16 Dec 1997 15:53:59 +0800 From: tony <[EMAIL PROTECTED]> X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: debian-devel@lists.debian.org Subject: (no subject) X-Priority: 3 (Normal) Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"9U0Xb.A.y6C.AFjl0"@debian> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/12594 X-Loop: debian-devel@lists.debian.org Precedence: list Resent-Sender: [EMAIL PROTECTED] DEAR SIRS: 1. We produce items as follows: [EMAIL PROTECTED]@¡@ ILLEX SOUID CLEANED TUBE Origin of squid is Argentina. We also can offer Milkfish and Tilapia. [EMAIL PROTECTED]@¡@ We'll give you best price&good quailty. 2. We are more than eag
Re: Problems compiling packages
Guy Maor writes: > > I'd suggest that all such packages only try to compile and package the > > libc5 packages if there is a libc5 installed. > > No, that's a bad idea. A package might silently build incorrectly > because a developer didn't have libc5 or libc5-dev installed. > > Unfortunately hard-coding the architectures which do (or don't) have > libc5 isn't very aesthetic. Does anybody have a better idea? That's what I wanted to prevent but I'd be happy with any other mechanism. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
On Mon, 15 Dec 1997, Nicolás Lichtmaier wrote:
> > (I need that to display messages directed to stderr from busybox when
> > linked to a Slang program, as in:
>
> Uh? Why don't you just do...
>
> int p[2];
> pipe(p);
> if(!fork())
> {
> dup2(p[1],2);
> exec...
> }
> /* now you can read the output from the p[0] file descriptor... */
>
Memory penalty. As busybox and dinstall are linked together in this
implementation, forking implies doubling the already big memory
requirements. Perhaps we should implement a libbusybox.so ...
(I wouldn't like to substantially modify busybox right now. We already
have enough work with the rewriting, and we need a set of working libc6
boot-floppies ASAP, but if someone wants to take care of busybox, he is
welcome).
--
Enrique Zanardi[EMAIL PROTECTED]
Dpto. Fisica Fundamental y Experimental Univ. de La Laguna
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
> Please let noone think that just because that absurd and awful
> suggestion was the last thing anyone said that everyone is happy with
> it.
>
> Rather, the rest of us have more important things to do than to fight
> battles with people with broken mailers and broken ideas about how
> mailers ought to work.
>
> The list configuration should be left the way it is.
>
> Ian.
Ian,
it is not that I want to change the mailing list headers at all cost or
whatever, but could you please give some explanaion why you think this
way?
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Rob Browning <[EMAIL PROTECTED]> writes: > Feel free to let me know if you have suggestions 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. I am not a developer, but I have a few comments. When I run dselect, I see some Emacs packages as seperate deb packages, e.g. auctex. Now, I prefer XEmacs, which includes auctex, but how could I know that? Either make such packages shared between GNU and XEmacs, or write in the control file: GNU Emacs only. In the /etc dir, I have three site-start dirs: /etc/emacs/site-start.d, /etc/xemaxs/site-start-19.d, and /etc/xemacs/site-start-20.d. I haven't touched these dirs (except by installing debs), and now I see their contents differ. We need some coordination here. The same problem applies to the site-lisp dirs in /usr/lib. Maybe the Debian Policy should be extended to cover the usage of these dirs. - Sten Anderson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On Tue, 16 Dec 1997, Alex Yukhimets wrote: > > Please let noone think that just because that absurd and awful > > suggestion was the last thing anyone said that everyone is happy with > > it. > > > > Rather, the rest of us have more important things to do than to fight > > battles with people with broken mailers and broken ideas about how > > mailers ought to work. > > > > The list configuration should be left the way it is. > > > > Ian. > > Ian, > > it is not that I want to change the mailing list headers at all cost or > whatever, but could you please give some explanaion why you think this > way? Please check out http://www.unicom.com/pw/reply-to-harmful.html . The page contains several arguments against the use of "Reply-To". I fully agree to what Ian said. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
On 16 Dec 1997, Rob Browning wrote: > The newer emacs source wants to put some files in /usr/share/emacs and > /usr/libexec/emacs by default. The emacs 19 package put all these > files together in /usr/lib/. > > I would assume /usr/share is now OK since it's in the FSSTND (to some > extent) and other packages are using it, but what about /usr/libexec? > Am I correct in assuming that it should still be avoided until FHS? IMHO, it's generally ok if a package places arch-indep files into /usr/share instead of /usr/lib, unless this introduces incompatibilities with other packages. As the current emacs package installs its libs into /usr/lib/emacs/19.34/..., will moving this below /usr/share break other packages? 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. (For all that have missed the previous announcement: Debian 2.0 will use FSSTND and we are expecting to switch over to FHS for Debian 2.1.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On 16-Dec-1997, Ian Jackson <[EMAIL PROTECTED]> wrote: > Tyson Dowd: > > A couple of us discussed this (and other problems with the mailing > > list), in the thread "Duplicate messages on this list" in debian-devel > > about a week ago and eventually came to a standstill where most people > > in the discussion were happy with the following solution: > > > > Set the mailing lists up so that the headers are munged > > in the following way: > > [deleted] > > Please let noone think that just because that absurd and awful > suggestion was the last thing anyone said that everyone is happy with > it. > > Rather, the rest of us have more important things to do than to fight > battles with people with broken mailers and broken ideas about how > mailers ought to work. > I'm sorry that you think a simple fix that would solve a potentially very embarrasing problem is too distateful to discuss. I have brought the matter up only when the current mail configuration has caused problems. I figured if it was important enough for Bruce to reply to the original poster and give a rap on the knuckles for jumping lists, then it's important enough to stop. If I've gone too far wasting people's time with these issues, I won't bring it up again - but I'd seriously recommend not using debian-private for anything that should remain private, until the world upgrades their mailers. Tyson. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
Christian Schwarz <[EMAIL PROTECTED]> wrote: > Please check out http://www.unicom.com/pw/reply-to-harmful.html . The page > contains several arguments against the use of "Reply-To". I fully agree to > what Ian said. I personally find header-munging of any sort distasteful, however I think a couple of points should be made clear: (1) a good mail client (e.g. a properly configured mutt) will give you the option of respecting reply-to, or ignoring it. (2) changing an existing reply-to to an x-reply-to is a fairly minor losage, given a good mail client. (3) a good mail client can thread duplicate replies together, making them easy to manage. A really good email client would probably have a mechanism for indicating that the previous message's author prefers to receive list mail only via the list address. Admittedly, this solution hasn't been designed, and debian-devel probably isn't the right place to design it, but it shouldn't be too hard to hack up mutt, gnus, and whatever other readers people like to support such a mechanism. I prefer to use reply to all recipients rather than reply to list. This is because I've been stung in cases where one of the recipients was not on the list I was replying to. Also, there are times when the list and/or the author's personal address have problems, and sending to both is just plain more robust. Anyways, a solution aimed at bad mail clients cannot be a solution (in my opinion). -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On 16-Dec-1997, Christian Schwarz <[EMAIL PROTECTED]> wrote: > > Please check out http://www.unicom.com/pw/reply-to-harmful.html . The page > contains several arguments against the use of "Reply-To". I fully agree to > what Ian said. Please don't quote this URL as if all the issues in this web page haven't already been discussed. Just because it's on a web page and uses the trendy "considered harmful" phrase doesn't mean it's relevant, and doesn't mean it's right. The reply-to munging solution is unfairly attacked, while the current configuration has at least as many drawbacks. The fact is, the current mail RFCs are not designed to cope with mailing lists. New mailers do a better job, but when we have new mail standards that have better mailing list support, their solutions will be considered impure too. I've also presented another solution, which is to just clearly document the problems on the web pages, so that developers are aware they need to be careful, and they should upgrade their software. I've offered to do the work for this solution, but haven't receieved any feedback on whether it should be done or not (I am truly more interested in stopping the various mail problems than winning any arguments). Tyson. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian web pages need help
The Debian web pages need the help of someone who follows bugtraq. Currently the security web page is updated at random times (and not very well). If you already follow bugtraq then you could help Debian a lot by sending updates to [EMAIL PROTECTED] If you already follow bugtraq, then this won't be much work. You simply need to find out if the current Debian package is vulnerable and send the relevant info to webmaster. If we are vulnerable, you then send an update to webmaster when a fix is released (possibly sending another update when the fix makes it into stable). Note that most package maintainers will do the vulnerability detection for you. If interested, please write to [EMAIL PROTECTED] - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
Christian Schwarz <[EMAIL PROTECTED]> writes: > As the current emacs package installs its libs into > /usr/lib/emacs/19.34/..., will moving this below /usr/share break other > packages? I'll certainly make sure that's not a problem before I do it, but so far, I doubt it 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 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] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
"Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
> Yann Dirson <[EMAIL PROTECTED]> writes:
>> Adam P. Harris 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/.
>>>
>>> This would allow, for instance, MTA packages to ship little scripts to
>>> flush the mail queue when the link comes up, pop-deamons to start up,
[...]
>> I had the idea of adding such actions (flush mailqueue, fetch mail,
>> etc.) to my ip-up, but I didn't do that.
>> This is because some of these actions (eg. mail fetching) may be
>> quite long to complete,
That's just a question of looking into how run-parts serializes
execution, and maybe using backgrounded subshell for faster script
completion.
>> and may act badly if interrupted by a
>> 'poff' (eg. fetched messages from the interrupted session not
>> erased from my POP account - guess it's a security feature in
>> fetchmail).
Well, that's an example of an application that works fine when the
link goes down in midstream! No worries!
I'm sure some processes aren't as graceful. However, the system I'm
proposing (and there's no guarantee Phil Hands won't adopt some
radically different scheme), which just talks about:
/etc/ppp/ip-up.d/
/etc/ppp/ip-down.d/
Wouldn't be making the situation any worse than it already is. Not
that that's an excuse, but the fact is, by the time the scripts in
ip-down.d are run, it's too late anyhow!
>> The solution I used was to manually ask to fetch my mail.
Yeah, me too, but that sucks!
>> Another
>> would be to have a (hopefully generic) mean of forcing the line to
>> stay up while such an action is taking place.
Well, that's outside of the scope of what I was trying to propose, it
takes power away from the user, etc etc.
>> * we can't decide for the sysadmin what actions will take place on
>> boot.
We do have an initial descision, which is what 98% of users will
stick with. Yes, allow them to override, of course.
>> * if we build such a system, a standard way of disabling parts of
>> these directories (maybe like what /etc/init.d/rc allows with 'S'
>> and 'K' names ?)
I just feel that the SYSVINIT model is too elaborate for what we're
doing here (running scripts on link up and link down). 'run-parts is
stock debian, and already used by cron etc.
> Yes. Definitely ensure that it is easy to disable (and of course
> re-enable) these automatic scripts, and ship everything _off_ by
> default. IMO nothing is more annoying than these kind of surprises.
> I want to know what is being started when I dial into my ISP.
But of course. Actually, it would be up to the individual packages to
be reasonable.
The beauty of run-parts is that all a local sysadmin has to do is say
`chmod a-x ' to disable a file.
> For example, I have configured my ip-up script to start fetchmail
> (in daemon mode) and grab articles for my local news spool unless
> the file /etc/no_mail exists. Therefore, if I need to quickly dial
> in, say to fetch a file, I create this file before starting pppd so
> that I can hang up as soon as I am done without waiting for POP and
> NNTP transfers to finish.
I'm not sure we can accomodate this ;)
My goal is to find a 90% solution. If it doesn't work for 10%'ers,
well, those 10%ers are generally hacker types and they are generally
able to hack on the system to get it to work "their way".
.A. P. [EMAIL PROTECTED]http://www.onShore.com/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
[You (Rob Browning)] >Christian Schwarz <[EMAIL PROTECTED]> writes: >> As the current emacs package installs its libs into >> /usr/lib/emacs/19.34/..., will moving this below /usr/share break other >> packages? > >I'll certainly make sure that's not a problem before I do it, but so >far, I doubt it will be. I don't think that the old and new emacs >will be sharing many files. Rob, you're talking about moving Xemacs arch-independant files from /usr/ lib/xemacs-XX.XX to /usr/share, right? I think this is a good idea. When we do this for Emacs 19.XX we'll need to make sure to change AucTeX and the lisp packages. BTW, are .elc files arch-dependant or arch-indep? I've always wondered about this. .A. P. [EMAIL PROTECTED]http://www.onShore.com/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Example library, please
Hi, I'm trying to build packages for a library and running into a number of problems. I've build a package for a regular executable by following the instructions in the Debian Packaging Manual. However, I haven't found a step-by-step dicussion of how to build a library. I was hoping someone on this list could email me a uuencoded tar file of a directory setup for a simple library. I'm good with UNIX, but new to Debian. I don't need hand holding, just an example to go by. Thanks, Mike -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp & pam (was: Re: ppp's ip-{up,down} and possible utilization of 'run-parts')
[ Brokenly-long lines wrapped ] Philip Hands <[EMAIL PROTECTED]> writes: > ppp is needed for doing an install from the internet via a dialup > link. PAM is not needed until you want people to log into the > system, so libpam is a waste of space on the install disks. > > I'm not certain it's worth the effort either, since libpam is only > 21k and binary is almost exactly the same size (112 bytes bigger) > --- opinions ? libpam0g is 103k; libpam0g-util is 625k; libpwdb0g is a further 135k. That's 863k. My complaints about pam and ppp are this: o When I filed the bug you were linking a libc6 application with a libc5 library. That's not good. There is now a libc6-based pam in Incoming, once this gets processed, this objection, obviously disappears. o I've heard[1] that the pam support in ppp is badly broken. I don't know if this is still the case with 2.3.2, I don't do ppp and can't test it. If someone who can test it does so and says it's okay, then this objection goes away too. 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're going to do PAM for 2.0, then this will have to be done anyway. But have really got the time to PAM-ify critical applications like the shadow suite and have them working and debugged and have 2.0 released before the next millennium? > BTW does libpam0 need to be recompiled for libc6 before I can use it > in ppp ? Yes; linking with both libc5-based and libc6-based libraries is plain Evil. (At least, I sincerely hope no one is going to dispute that) [1] According to Michael Johnson on the pam list, which, unfortunately, doesn't seem to be archived. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Mark recently informed me that he'd accepted my offer to work on the new emacs20 package. I just wanted to let everyone know that I was getting started. I'd like to get something out very soon, but the holidays may interfere a little. I had already offered to package up emacs20 myself, but I found out that it was a pain, so I guess I don't care any more. Take it. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
"Adam P. Harris" <[EMAIL PROTECTED]> writes: > BTW, are .elc files arch-dependant or arch-indep? I've always > wondered about this. They're architecture independent. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
From: Enrique Zanardi <[EMAIL PROTECTED]> > Memory penalty. As busybox and dinstall are linked together in this > implementation, forking implies doubling the already big memory > requirements. No, sorry, that's not right. Busybox is actually much more efficient than you think. The text of the busybox executable is shared between all processes that are running it, just as if it were a shared library. The data is partially shared in that all processes inherit copy-on-write data pages after a fork(). These are kernel features that apply to all of our executables. Thus, running multiple instances of busybox should be more economical than running its components as separate executables. Why did you think I linked all of those programs together? It was to save memory. Thanks Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
On Tue, Dec 16, 1997 at 11:35:23AM +0500, Adam P. Harris wrote: > ... > > For example, I have configured my ip-up script to start fetchmail > > (in daemon mode) and grab articles for my local news spool unless > > the file /etc/no_mail exists. Therefore, if I need to quickly dial > > in, say to fetch a file, I create this file before starting pppd so > > that I can hang up as soon as I am done without waiting for POP and > > NNTP transfers to finish. > > I'm not sure we can accomodate this ;) > So don't use plain "pon", use #!/bin/sh touch /etc/no_mail ; exec pon and your ip-up.d/fetchmail would be #!/bin/sh if [ -f /etc/no_mail ] then fetchmail -d 600 fi FWIW I've been using run-parts in ip-up and ip-down for some time now, the scripts reconfigure stuff based on my ip address (2 ISPs) etc. and everything works like a charm. I dunno about packages placing scripts in ip-[up|down].d/ -- I'd rather put them in /usr/doc//examples. -- Dimitri emaziuk at curtin dot edu dot au Entia non sunt multiplicanda praeter necessitatem -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
"Adam P. Harris" <[EMAIL PROTECTED]> writes: > Rob, you're talking about moving Xemacs arch-independant files from /usr/ > lib/xemacs-XX.XX to /usr/share, right? No, this is only for emacs20, James LewisMoss <[EMAIL PROTECTED]> maintains xemacs. > I think this is a good idea. When we do this for Emacs 19.XX we'll need > to make sure to change AucTeX and the lisp packages. See my recent post about improving the handling of .el files. I believe it address this. > BTW, are .elc files arch-dependant or arch-indep? I've always wondered > 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 the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Mirror: VA's mirror
Just a warning to everyone running mirror scripts. Something happened to va's FTP mirror last night and it has been erased. Please stop mirroring va untill it can be restored! The web site hosted at va still seems to be okay but mirroring of it's components may have stopped. I belive James is working on the problem so hang tight. Thanks, Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
sorry
Sorry... I really got very angry with that stuff. Rover. On Tue, 16 Dec 1997, I wrote: : From: Roberto Lumbreras <[EMAIL PROTECTED]> : To: [EMAIL PROTECTED] : Cc: [EMAIL PROTECTED], debian-devel@lists.debian.org : Date: Tue, 16 Dec 1997 12:40:12 +0100 (CET) : Subject: SPAM to mailing lists! STOP NOW. : : Dear Postmaster, : : PLEASE STOP this SPAM now. : : [blah blah blah...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
[EMAIL PROTECTED] (Enrique Zanardi) wrote on 16.12.97 in <[EMAIL PROTECTED]>:
> On Mon, 15 Dec 1997, Nicolás Lichtmaier wrote:
> > Uh? Why don't you just do...
> >
> > int p[2];
> > pipe(p);
> > if(!fork())
> > {
> > dup2(p[1],2);
> > exec...
> > }
> > /* now you can read the output from the p[0] file descriptor... */
> Memory penalty. As busybox and dinstall are linked together in this
> implementation, forking implies doubling the already big memory
> requirements. Perhaps we should implement a libbusybox.so ...
I don't think so. That's what virtual memory and copy-on-write are for. If
you fork() your program, you should only actually duplicate pages that are
written to by one of the sides (and the management stuff in the kernel, of
course).
Now, if you exec(), then libs come in handy.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
[You ([EMAIL PROTECTED])] >FWIW I've been using run-parts in ip-up and ip-down for some time now, >the scripts reconfigure stuff based on my ip address (2 ISPs) etc. >and everything works like a charm. I dunno about packages placing >scripts in ip-[up|down].d/ -- I'd rather put them in >/usr/doc//examples. One question. You're obviously carrying along the `ip-up' argument list, i.e., Arg Name Example $1 Interface name ppp0 $2 The ttyttyS1 $3 The link speed 38400 $4 Local IP number12.34.56.78 $5 Peer IP number12.34.56.99 These variables are clearly being propogated to your (custom rolled) ip-up.d/* scripts. How are you propogating these values? Environment variables? We'd have to std'ize the variable names too, if so. .A. P. [EMAIL PROTECTED]http://www.onShore.com/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
[CC trimmed to ] [Raul Miller] >Hmm.. seems like XEmacs should Provide: auctex. I can't see any >formal problem if auctex is installed as a separate package as >well... [Why someone would want to is beyond me.] What if you have Xemacs *and* Emacs installed, and want to use auctex from both? .A. P. [EMAIL PROTECTED]http://www.onShore.com/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
"Adam P. Harris" <[EMAIL PROTECTED]> writes: > What if you have Xemacs *and* Emacs installed, and want to use auctex > from both? My suggestion would be that whichever package provides auctex, whether it's xemacs or a separate package, would register the .el files 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 = 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] .
Re: Taking over production of emacs20 package.
Adam P. Harris <[EMAIL PROTECTED]> wrote: > What if you have Xemacs *and* Emacs installed, and want to use auctex > from both? Last time (a couple weeks ago) I tried selecting both xemacs and emacs, I found that they conflicted. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
> > [You ([EMAIL PROTECTED])] > >FWIW I've been using run-parts in ip-up and ip-down for some time now, > >the scripts reconfigure stuff based on my ip address (2 ISPs) etc. > >and everything works like a charm. I dunno about packages placing > >scripts in ip-[up|down].d/ -- I'd rather put them in > >/usr/doc//examples. > > One question. You're obviously carrying along the `ip-up' argument list, > i.e., > Arg Name Example > $1 Interface name ppp0 > $2 The ttyttyS1 > $3 The link speed 38400 > $4 Local IP number12.34.56.78 > $5 Peer IP number12.34.56.99 > > These variables are clearly being propogated to your (custom rolled) > ip-up.d/* scripts. How are you propogating these values? Environment > variables? We'd have to std'ize the variable names too, if so. > > .A. P. [EMAIL PROTECTED]http://www.onShore.com/> 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 PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE run-parts /etc/ppp/ip-up.d Any better suggestions ? Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Adopting arpd
I found arpd on the WNPP list as being orphaned, and I'd like to pick it up as maintainer. I tried contacting dominik, but his debian.org address is no longer current, so the WNPP maintainer suggested I post this here. I've got an updated package (upstream source hasn't changed yet) with fixed init.d/postinst scripts sitting in my home directory on master; as this is my first official package, any comments on it before I upload it for committing to unstable would be appreciated. (I brought it up to libc6, as well) -- Elie Rosenblum <[EMAIL PROTECTED]> That is not dead which can eternal lie, <[EMAIL PROTECTED]> And with strange aeons even death may die. Developer / Mercenary / System Administrator - _The Necromicon_ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: header munging, mail reader configs, Gnus propaganda
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> (1) a good mail client (e.g. a properly configured mutt) Raul> will give you the option of respecting reply-to, or ignoring Raul> it. I use Gnus, and used `G p' in the *Groups* buffer to set the group properties of this mail group, adding: (to-address . "Debian Developers' Forum ") ... to the list. Now when I push the follow-up key, that's the only header that gets inserted. It omits the uneccesary `Cc:' list, so people won't get two copies. Raul> (3) a good mail client can thread duplicate replies Raul> together, making them easy to manage. Gnus can be configured to drop or elide duplicate messages, based on the Message-Id: header that `sendmail' (and probably other mailer daemons) adds. Raul> A really good email client would probably have a mechanism Raul> for indicating that the previous message's author prefers to Raul> receive list mail only via the list address. It supports a `Mail-Replys-To:' header, which many people set to "never". -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.3.1+hamm Linux 2.0.32 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On Dec 16, 1997, at 11:22, Ian Jackson wrote: > Tyson Dowd: > > A couple of us discussed this (and other problems with the mailing > > list), in the thread "Duplicate messages on this list" in debian-devel > > about a week ago and eventually came to a standstill where most people > > in the discussion were happy with the following solution: > > > > Set the mailing lists up so that the headers are munged > > in the following way: > > [deleted] > > Please let noone think that just because that absurd and awful > suggestion was the last thing anyone said that everyone is happy with > it. > > Rather, the rest of us have more important things to do than to fight > battles with people with broken mailers and broken ideas about how > mailers ought to work. > > The list configuration should be left the way it is. 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 or more duplicates of the messages sent to the list. The amended suggestion that I replied with a little earlier seemed to please everyone, even those recalcitrant types who wouldn't hear about adding Reply-To headers to the messages. You offer no alternative whatsoever to those of us with a very real problem: net access is expensive for some people, and shorter download times mean money saved. So, again, I vote for applying the suggestion mentioned before. Not on philosophical grounds, but because of very practical reasons. > Ian. -- Gonzalo Diethelm # Windows 95: n. 32-bit extensions and a graphical shell for [EMAIL PROTECTED] # a 16-bit patch to an 8-bit operating system originally =Debian Linux= # coded for a 4-bit microprocessor, written by a 2-bit www.debian.org # company that can't stand for 1 bit of competition. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Hmm.. seems like XEmacs should Provide: auctex. I can't see Raul> any formal problem if auctex is installed as a separate Raul> package as well... [Why someone would want to is beyond Raul> me.] There's support for that in XEmacs-20.3. The XEmacs developers are unbundling most of the packages, and setting up support for packaged elisp software that will be installed in a separated directory from the core elisp. You can find the NEWS file on their web site and read about it: http://www.xemacs.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Philip Hands <[EMAIL PROTECTED]> wrote: > Any better suggestions ? run-parts should pass arguments which follow the directory. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: SPAM to mailing lists! STOP NOW.
Dear Robert, We do use qmail. If you would like to maintain our spam filter, I will give you a login on the list server. Thanks Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
["Gonzalo A. Diethelm" ] Re: Moving topics from debian-private (was Re: SPI money out)
--- Start of forwarded message --- Resent-Date: 16 Dec 1997 22:24:45 - Resent-Cc: recipient list not shown: ; Date: Tue, 16 Dec 1997 15:38:16 -0300 Message-Id: <[EMAIL PROTECTED]> From: "Gonzalo A. Diethelm" <[EMAIL PROTECTED]> To: Ian Jackson <[EMAIL PROTECTED]> Cc: Debian developers list [ ... ] --- End of forwarded message --- [Note the Cc: to iwj, despite the fact he's obviously on debian-devel] Interesting to note that those whining about duplicate mails and advocating the Reply-To munging are themselves creating duplicates. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
> >FWIW I've been using run-parts in ip-up and ip-down for some time now,
> >the scripts reconfigure stuff based on my ip address (2 ISPs) etc.
> >and everything works like a charm. I dunno about packages placing
> >scripts in ip-[up|down].d/ -- I'd rather put them in
> >/usr/doc//examples.
>
> One question. You're obviously carrying along the `ip-up' argument list,
> i.e.,
> Arg Name Example
> $1 Interface name ppp0
> $2 The ttyttyS1
> $3 The link speed 38400
> $4 Local IP number12.34.56.78
> $5 Peer IP number12.34.56.99
>
> These variables are clearly being propogated to your (custom rolled)
> ip-up.d/* scripts. How are you propogating these values? Environment
> variables? We'd have to std'ize the variable names too, if so.
>
> ...A. P. [EMAIL PROTECTED]http://www.onShore.com/>
Why not as the same command-line arguments?
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".
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
On Tue, Dec 16, 1997 at 12:01:28PM +0500, Adam P. Harris wrote: > > [You (Sten Anderson)] > > >I am not a developer, but I have a few comments. > > > >When I run dselect, I see some Emacs packages as seperate deb > >packages, e.g. auctex. Now, I prefer XEmacs, which includes auctex, > >but how could I know that? Either make such packages shared between > >GNU and XEmacs, or write in the control file: GNU Emacs only. > > Ick. Well that would break developer policy in the sense that you'd have > to pretty significantly hack on the stock XEmacs distibution (which > bundles all this) if you wanted to cut out these lisp packages. And I > don't think it would be worth it since sometimes they are slightly > different versions. > > Really, the way for a user to know is to either notice that the package > depends on Emacs19 (not XEmacs) and/or if there's a blurb in the > description that says that the package is part of XEmacs. I'm pretty > sure most of the lisp packages already have this blurb; I encourage you > to go thru and check and submit bug report (wishlist items?) if not. I've had a look at all the current packages, details are below (some programs are probably fine). I think most of these packages should be "fixed" is someway - either: depending on emacs|xemacs description includes "does not work with Xemacs" description includes "already included with Xemacs" As an aside, these packages *shouldn't* have "conflicts Xemacs" as you might want to install emacs and Xemacs at the same time. One of the things about installing xemacs and emacs was sharing files (just the .els?) - if this is done, is there a problem when someone installs auctex for emacs and they have xemacs installed? Cheers - details follow... packages which seem fine vm (depends on emacs, says it is already included in xemacs) cvs-pcl (ditto) tm (depends on xemacs|emacs) packages with bugs? --- suggests emacs, no mention of xemacs: elisp-manual gnats gnats-user depend on emacs, no mention of xemacs: hyperlatex auto-pgp w3-el mailcrypt (emacs >=19.28-1) gnuserv bbdb crypt++ elib calc (emacs >=19.34) auctex emacspeak debview emacs-czech (emacs >=19.30) Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proxy server policy [was Re: gated]
On Thu, Dec 11, 1997 at 12:15:11PM -0500, Charles Briscoe-Smith wrote: > Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > >On 10 Dec 1997, Charles Briscoe-Smith wrote: > >> ...and so on. I'm not sure that you can ever have a scheme that will work > >> for -all- the wierd and wonderful proxies, caches and firewalls out there. > >> > >> (This cache is something that was knocked up locally, I think. It's > >> integrated with the HENSA mirrors, but fetches updates to individual > >> files on demand, too.) > > > >Yes, this is most unusual. If it was created locally I would suggest you > >use something more 'normal' for instance: > [...] > > Knocked up locally, but not by me, I'm afraid. And since it now > certainly has hundreds (or maybe thousands) of users, I suspect it would > be impractical to change it now... > > My point was simply that there are sure to be many different proxy > configurations, so you can't hope to support all of them out of the box. > It might well be possible to support all the popular ones, but there > ought to be a way of customising for strange setups like ours. My original point was that at the moment you need to configure various things to identical strings. If you have a proxy which is configured as "[EMAIL PROTECTED]:8013", but program "freds-ftp" doesn't support the "username@" bit, then tough - we havn't broken anything, we just havn't fixed it either. We should also standardize the environment variables that are used. Once again, if the program doesn't support environment variables, tough - although of course maintainers are encouraged to "fix" the programs :-) If people could be kind enough to email sample proxy configurations to me (ones that are supported by some non-customized program), then I'll come up with a proposed scheme. I'll include some sample code to make it easier for maintainers to convert a program. Alternatively, how about doing something like update-menus? Maintainers could make "update-lynx", "update-wget" etc programs and then by executing an overall "update-proxies" program, the various lines in /etc/program.conf or ~/.program.conf could be changed. Or do people think the whole thing, or even this entire email, are a waste of time? I mean - how many people want this sort of thing? Or is it just me with a choice between a dodgy proxy and a dead slow one :-) To start off, here are some that we need to support (any mistakes?) http_proxy http://[EMAIL PROTECTED]:port https_proxy http://[EMAIL PROTECTED]:port ftp_proxy http://[EMAIL PROTECTED]:port gopher_proxyhttp://[EMAIL PROTECTED]:port news_proxy http://[EMAIL PROTECTED]:port newspost_proxy http://[EMAIL PROTECTED]:port newsreply_proxy http://[EMAIL PROTECTED]:port snews_proxy http://[EMAIL PROTECTED]:port snewspost_proxy http://[EMAIL PROTECTED]:port snewsreply_proxyhttp://[EMAIL PROTECTED]:port nntp_proxy http://[EMAIL PROTECTED]:port wais_proxy http://[EMAIL PROTECTED]:port finger_proxyhttp://[EMAIL PROTECTED]:port cso_proxy http://[EMAIL PROTECTED]:port no_proxyhost.domain.dom, more.debian.org socks_server[EMAIL PROTECTED]:port auto_proxy http://[EMAIL PROTECTED]:port Cheers Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
options for menu packages
A wishlist priority bug report was filed against pppload as it's menu entry contained this as the command: /usr/X11R6/bin/pppload -i 2 -p 10 The bug reporter (bugger :-) - Yann Dirson suggested a conffile would be nice. So I made a new conffile /etc/pppload and changed command to this: /usr/X11R6/bin/pppload $(tail -n +2 /etc/pppload) This is a bit limiting on a multi-user system (I don't think Debian should ever assume that the sys-admin is the only user - and there are some pretty unfriendly^H^H^Hbusy sys-admins out there). So now I'm thinking about using this instead: /usr/X11R6/bin/pppload \ $(grep -v ^\# \ $(if [ -r ~/.pppload ]; then \ echo ~/.pppload; \ else \ echo /etc/pppload; \ fi)) I realise that user can override the menu system by making entries in ~/.menu/, but that is more effort (albeit not much). I'd like to hear what other people think (particularly Yann!) Implementing this scheme is not much work, but if it's unneccessary, I'd rather not do it. If OTOH, people think it's a good idea, I'll update any other packages that could benefit from this. PS: I think that whatever is decided, the original scheme (or having a conffile) is a very good idea that is easily implemented and Yann's suggestion should be mentioned in the menu package itself. Cheers Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Plan to package xscavenger
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 contacted the author, and we work > together on a new upstream release. > > The whole thing is GPL, and it includes a level editor and some dozen > levels, sound and nice animations. Oh, you can create own animations, too. > > However, there is an issue with the sound server. It was taken from koules, > and Hubicka took it from xgalaga. I will check this soon. > > As soon I become registered as a developer, I will upload my package. I've already packaged version 1.3 - it's in hamm. I changed the locations of the files to fit in with Debian and changed things so that everything is called xscavenger rather than half being xscavenger and half being scavenger. I wasn't aware of the sound server problem as the README said it was GPLed. You certainly welcome to take maintainership. If you have a look at debian/dists/unstable/main/source/games/ their should be a file called "xscavenger-1.3-1_i386.diff.gz (or something like that) which has all the changes I made to it - you should keep the changelog file, but the rest can be changed. PS: You wouldn't know how to do level 13 would you - I'm stuck and I can't think of any other possible combinations I can do :-) There is no way to get back inside the yang-yang once you have gone outside it AFAIK, and when I get the bottom lot of gems, the man kills me as he is right behind me :-( Cheers Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
intent to package xlaby and xnetload
xlaby traps your mouse cursor in one of the mazes generated by "maze", you must move around until you can escape - invisible walls is an option! xnetload is like xload for network connections (similar to pppload and half a dozen other utils, you takes your pick!) Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packaging agrep
On Fri, Dec 12, 1997 at 03:00:32PM -0500, Chris Fearnley wrote: > 'Sven Rudolph wrote:' > > > >G John Lapeyre <[EMAIL PROTECTED]> writes: > > > >> > I am planning to package agrep, a grep-like tool that allows to > >> > >>We have it already. I think it comes with glimpse . > > > >So it should be split into an extra package ? > > No. Well that was helpful - you explained your carefully thought-out reasons really well :-) I happened to see agrep and was also thinking of packaging it. I certainly have no plans to install glimpse. What's wrong with splitting it off and making glimpse depend on it? Adrian (who hates it when people don't explain reasons when they aren't obvious) email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ["Gonzalo A. Diethelm" ] Re: Moving topics from debian-private (was Re: SPI money out)
> --- Start of forwarded message ---
> Resent-Date: 16 Dec 1997 22:24:45 -
> Resent-Cc: recipient list not shown: ;
> Date: Tue, 16 Dec 1997 15:38:16 -0300
> Message-Id: <[EMAIL PROTECTED]>
> From: "Gonzalo A. Diethelm" <[EMAIL PROTECTED]>
> To: Ian Jackson <[EMAIL PROTECTED]>
> Cc: Debian developers list
>
> [ ... ]
>
> --- End of forwarded message ---
>
> [Note the Cc: to iwj, despite the fact he's obviously on debian-devel]
>
> Interesting to note that those whining about duplicate mails and
> advocating the Reply-To munging are themselves creating duplicates.
>
> --
> James
Hi.
And that's exactly the point!
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.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: SPAM to mailing lists! STOP NOW.
On 16 Dec 1997 [EMAIL PROTECTED] wrote: > We do use qmail. It might be worth applying the MAPS RBL (Realtime Blackhole List) patches to qmail available at http://www.qmail.org/rbl/ Given the volume of the debian lists, it would make sense for a DNS server on the lists.debian.org LAN to be a secondary of the rbl.maps.vix.com zone (details are at http://maps.vix.com/rbl/usage.html#DNSsub ) TL -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
PGP pack.
I wish only know if out there's a .deb for PGP 2.6.3i ... tnx -- \ Massimo Lusetti|The biMboMIx / Team OS/2 Italy Univ. of Modena FidoNet 2:332/533 E-Mail [EMAIL PROTECTED] PGP 2.6.3i Key Available ...to rich the hell?? ... setup Windoze -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
"Adam P. Harris" <[EMAIL PROTECTED]> writes:
>
>
> Maybe I should submit this as a wishlist to the bug system, but I was
> interested in getting some comments first.
>
> 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/.
>
> This would allow, for instance, MTA packages to ship little scripts to
> flush the mail queue when the link comes up, pop-deamons to start up,
> bind to reload, clock sync daemons to re-sync, firewall and
> masquerading rules to run, and dynamic PPP hosts to update some file
> on some server indicating their current IP.
Well, the recent discussion of using run-parts in ip-up and ip-down
finally convinced me to doing a little cleaning up of my hacked
together system. I've basically implemented what Adam Harris was
asking for, together with a HTML form, so that my wife can control our
expensive (UK) modem link from her Windows 95 box.
I'll launch straight into the scripts and describe as I go along.
Here's my ip-up script...
/etc/ppp/ip-up ===
#!/bin/sh
#
# This script is run by the pppd after the link is established.
# It should be used to add routes, set IP address, run the mailq
# etc.
#
# This script is called with the following arguments:
#Arg Name Example
#$1 Interface name ppp0
#$2 The ttyttyS1
#$3 The link speed 38400
#$4 Local IP number12.34.56.78
#$5 Peer IP number12.34.56.99
#$6 Something passed with the 'ipparam' option for pppd
# Save the options for possible later use
INTERFACE=$1
TTY=$2
SPEED=$3
LOCAL_IP=$4
PEER_IP=$5
# Set up the runtime flag directory
RUNDIR=/var/run/ppp
# Set defaults
FLASH=/bin/false
# Parse the flags
# Note that $6 is not protected in quotes here, so to break it up into
# fields again.
set $6
while [ "$1" != "" ]
do
case "$1" in
flash) FLASH=/bin/true ;;
"get-mail") touch $RUNDIR/get-mail ;;
"send-mail")touch $RUNDIR/send-mail ;;
"get-news") touch $RUNDIR/get-news ;;
"get-www") touch $RUNDIR/get-www ;;
esac
shift
done
# Do all the things we want to when we're connected
/bin/run-parts /etc/ppp/ip-up.d
# If it's a flash session, wait until all done, then kill link.
if $FLASH
then
while [ "`/bin/ls $RUNDIR`" != "" ]
do
sleep 5
done
killall -TERM pppd
fi
exit 0
# End of file.
EOF /etc/ppp/ip-up
It is important that pppd is called in a statement in the form
pppd ipparam "flash get-news get-mail"
Notice the quoting around the argument. It is there since only one
argument gets passed to the ip-up script, not the rest of the command
line.
Each of the lines in the case statement correspond to a script in the
/etc/ppp/ip-up.d/ directory, apart from the FLASH check. I've
borrowed the 'flash session' name from AOL (hope it's not
trademarked!) The flags to `pppd ipparam [flags]` pass on the
information as to which services to run in this ppp session. Each
required service results in a flag file being touched in /var/run/ppp,
and the scripts check for this flag.
There are two types of script in ip-up.d. These which we always want
to run (bind, masq, etc) and those we only want to run on choice.
When a script is done, it removes the corresponding flag file. The
ip-up script, if it's been called as a flash session loops until there
are no flag files left, and then brings the ppp link down. Otherwise,
it exits gracefully, and awaits the user/admin to close the link when
they wish to.
Here's my getnews script...
/etc/ppp/ip-up.d/50getnews
#!/bin/sh
# This script will exchange news with the outside world
FLAG=/var/run/ppp/get-news
if [ -f $FLAG ]
then
if [ -x /usr/sbin/get-news ] ; then
( \
if [ -x /usr/bin/logger ] ; then \
/usr/bin/logger -t get-news -p news.info "Starting to get news..."; \
fi ; \
/usr/sbin/get-news ; \
/bin/rm -f $FLAG ; \
if [ -x /usr/bin/logger ] ; then \
/usr/bin/logger -t get-news -p news.info "Finished getting news."; \
fi ; \
) &
else
/bin/rm -f $FLAG
fi
fi
exit 0
=== EOF /etc/ppp/ip-up.d/50getnews ==
So, it basically checks for the flag file set in ip-up script and runs
only if it's there. There's a similar sequence of scripts in
ip-down.d which clean up the flags if any are left (modem lines do
die), and remove masquerading, reset bind for offline mode, etc.
Here's the whole tree of scripts. Feel free to criticise, alter,
and use freely.
begin 644 etc.ppp.tar.gz
M'XL(`.T)ES0``^U;6V_;[EMAIL PROTECTED])[EMAIL PROTECTED]:N8-/[EMAIL
PROTECTED];!\<'+1%
M2HE+B3!%,MQE%/_[SBPONE&B;4ARTW`,6!)W=W;(G6]F=G;(Q'APM/ZZC&IH7-U
Re: Taking over production of emacs20 package.
Rob Browning <[EMAIL PROTECTED]> writes: > For .el files like debian-changelog-mode.el that are generic enough > elisp that they should work with any emacs (19, 20, or x) we need a > shared directory or something. The only problem with this is that > when the files are byte-compiled there's a naming conflict since at > least xemacs and GNU emacs don't speak the same byte-code right now. > Because of this foo.el would need to produce two (or three) .elc > files, one for each emacs. Forget about byte-compiling these files, it only complicates things more than necessary. If elisp files should be compiled in a postinst script, then which postint script should do it? What is installed first - dpkg-dev or emacs? In addition, an otherwise portable elisp file becomes unportable when compiled. There is no need to require that a file like debian-changelog-mode.el is compiled. If the user wants such a file compiled he can do it himself and put the compiled file in a /usr/local directory. Large elisp packages, like auctex or vm, are either included in the emacsen, or specific for GNU or XEmacs, thus they are already compiled in the package. 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. - Sten Anderson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
