Re: Bug#10089: Experiences with 1.3 ("bo")
On Mon, 26 May 1997, Dale Scheetz wrote: > > A few minor problems: > > > > In dselect, running "configure packages" multiple times, as suggested in > > the documentation, did not seem to correct some of the misinstalled > > packages (Xserver, xext). > > > The documentation should suggest re-running Install, not Configure. > Running Install until all errors cease is the prescribed work around > for dselect. Configure followed by Install is the best way. Configure will get all the packages which were installed before the packages they depended upon. Install will get all the restand will run faster because it won't have to re-install the packages which only failed to configure because of a minor dependancy problem. The usual order I run dselect in is: 1. I usually upgrade dpkg, ldso, libc[56], and other important packages by hand before starting dselect if there are new versions in my mirror. 2. run dselect. 3. UPDATE 4. SELECT 5. INSTALL 6. if there are problems, sometimes i press ^Z to suspend dselect, cd to the appropriate subdirectory of my debian mirror and install a few packages by hand...then type 'fg' to return to dselect. 7. CONFIGURE 8. sometimes REMOVE is required, e.g. when a package replaces another package but the control information is incorrect. 9. if there were any installation problems, repeat from step 5. (alternatively, repeat from step 4 and de-select problem packages or select extra packages) 10. QUIT Until dselect can install in dependancy order, this is the least hassle way to complete a dselect installation or upgrade. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Sat, 31 May 1997, Richard G. Roberto wrote:
> Well, I promised myself I wasn't going to get involved in this kind of
> thing, but I'm about to get a private internet connection so I should
> be able to insulate my job from these discussions soon. I would like
> to make the following requests of those working on this project:
>
> Please do not create a proprietary configuration interface.
I couldn't agree more.
The config database should be regarded as a convenience for
{pre,post}{inst,rm} scripts and /etc/init.d/ boot time scripts only.
It should NOT attempt to be some universal replacement for
package-specific config files.
All that is needed is a set of "key=value" pairs in a plain text file. Take
a look at FreeBSD's /etc/sysconfig or NextStep's /etc/hostconfig for an
example.
This is not only simple to implement, but it is also simple to
parse...and it allows the sysadmin to change the setup with
vi/pico/ae/joe/emacs or whatever. Later, a GUI or web front end can be
layered ON TOP of this.
parsing the files in shell is simple:
source /etc/sysconfig
parsing it in perl is almost as easy. The following code fragment reads
/etc/sysconfig into an associative array called $config.
$sysconfig="/etc/sysconfig" ;
open(SYSCONFIG,"$sysconfig") || die "can't open $sysconfig: $!\n" ;
while () {
s/#.*$//; # strip out comments
next if /^$/ ; # ignore blank lines
($variable, $value) = /^(.*)=(.*)/ ;
$config{$variable} = $value ;
} ;
close(SYSCONFIG) ;
i'm not a great perl programmer, so the above can probably be improved.
i'm making myself NOT do everything in sh, and forcing myself to learn
how to do it in perl instead.
Here's some example usage of the array:
print $config{hostname} ;
print $config{ip_address} ;
# print out the entire array:
foreach $item (sort keys(%config)) {
print $item, "=", $config{$item}, "\n" ;
}
This perl fragment is good enough for simple assignments like:
domainname=taz.net.au
hostname=siva.taz.net.au
it's not yet smart enough to do:
domainname=taz.net.au
hostname=siva.$domainname
but it wouldn't be hard to modify it to do so.
So, a decision needs to be made: whether to allow only simple
assignments or to also allow complicated assignments like
"foo=`cat /etc/bar`". Parsing the former is easy in any scripting
language. Parsing the latter could get quite difficult in languages
other than sh.
at minimum, we need to support sh/bash/ksh/zsh, and perl. we should also
support csh and probably python. The sh family are easy. perl, csh,
python and others will require a "library" or set of standard code fragments
for parsing the /etc/sysconfig file.
we need code fragments in all of these languages to add, read, modify,
and delete (comment out) "name=value" pairsand do it WITHOUT
disrupting any comments or the order of assignment statements in the
file.
btw, i don't care what the file is called. /etc/sysconfig is just an
example.
craig
--
craig sanders
networking consultant Available for casual or contract
temporary autonomous zone system administration tasks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Sun, 1 Jun 1997, Lars Wirzenius wrote: > Craig Sanders: > > This is not only simple to implement, but it is also simple to > > parse... > > Not quite so simple. If you need to allow all characters in the > values, which requires using escapes and stuff, and consequently > also makes it more difficult to parse. The /bin/sh syntax is > inadequate (the rules are way too complicated). true, that's why i said my example would only work with simple 'name=value' assignments. anything more complicated needs more work. > Making it a requirement for the files to be parsable by the `.' > (source) command in /bin/sh is a bad idea. If nothing else, it makes > it complicated to have multiple locations for the data, and to change > the locations. > You want multiple locations, so that you can have a master database, > shared by all nodes in a network, with local modifications overriding > the master, as necessary. This could be done using your favourite text processing tools (sed, perl, m4, make, whatever) and rdist. I don't agree that multiple locations are necessary - there's more than one way to skin a cat. > Having shell scripts run a `cfgtool' -like program is a much > better idea. My implementation would work, mostly, but if another > is used, I don't mind. As long as the config database is editable with vi (or other text editor), I don't mind. As far as I am concerned, the file format can be anything that works as long as I can still drive it from the command line over a ppp connection and can write whatever sh, ed, sed, awk, or perl scripts i need to automate modification of the file. Craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks.
Re: Editor wars considered harmful
On Mon, 23 Jun 1997, Bruce Perens wrote: > The problem is that no editor is popular with everyone, and nobody is > learning VI any longer, and Emacs isn't so popular either. lots of people are learning still vi nowadays for pretty much the same reasons that they learnt it in the past: it's small, it's lean, it's fast, it's powerful, it does regular expressions, it's flexible, it's on every unix system (and many other systems too), AND it's the only thing that's actually USABLE over a slow network connection. (slow being anything with, say, greater than 200ms ping times. e.g. a ppp/slip modem connection, a machine that's 10 or 15 hops away over the internet, a machine that's 1 hop away over a completely flooded ethernet) > The solution is to put up a menu of check-boxes of what editor you > want, and install it from packages as soon as possible after the > system is installed. Adding editors to the base is a slippery slope. yes, there should be a veritable plethora of editors available for installation AFTER the base system is up and running. The more the better. The base system should have ae (or similar newbie editor like pico) and the smallest possible implementation of vi that works. period. If something has to go to make room for it on the disks, then so be it. There's lots of non-essential bloat that can go. e.g. there's quite a bit of necessary documentation which is useful for getting the system up to a point where it can install the rest of the packages. This stuff should undoubtedly stay. However, there's also a lot of extra documentation which could/should be installed later with the rest of the packages. This can go if space is tight. This can easily be automated with debian's packaging system - just make the debian version number on the base disks -0 or something, and it will be upgraded to the latest version with full docs when dselect is run. > The reason you add one is just as good to add the next... No it's not. The reason for installing vi is that it is THE standard editor for all unixes. It is the one editor which is guarranteed to be on ANY unix system. Having a version of vi (no matter how primitive) available for initial system config and install is essential. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz - tool for converting anchors to gzipped files
On Sat, 28 Jun 1997, Jim Pick wrote: > > You are proposing that a web-server is supposed to be searching > > through the .html code it serves and replace all links referring to > > .html.gz by .html links? > > dwww does this - it's not trivial. This is definitely not the job of a > web server. I agree 100%. A web server should NOT mess with the content. If we do this then we will make it difficult (or impossible) to serve .gz compressed files from debian-based web-servers. remember that not all .gz files are compressed documentation that needs to be decompressed on the fly. e.g. you put the linux kernel source on your web server for anyone to download. Do you really want apache or whatever to decompress a 6+MB .tar.gz file on-the-fly while sending it out to someone? > So here's my stand: > > - let's munch up the links to point to ".html.gz" files. Ugly, I know, > and a bit of work, but then we don't need to force people to install a > web server. I think it's pretty important that we don't force people > to run stuff they don't want. no, that will make it a pain to download files which are already compressed. The "smarts" should be in the web browser. > - we should compress html, because lots of people (like me) are using > Debian on machines with almost no hard drive. > > - Lynx and Netscape work with the compressed links (correct me if I'm wrong), > and we could use a web server/dwww combination to allow other browsers > to work too. I think that the correct place for this translation is in the web browser (as many others have suggested). modify lynx, mosaic, chimera, etc so that: 1. when a NON- .gz link is selected, try to fetch it. 2. if it fails, try to fetch .gz version and decompress it. 3. if that fails too, report an error to user. 4. if the link was pointing to a .gz file then DO NOTHING TO IT. If I download a compressed file from the net, then i want to save it as a compressed file. I certainly dont want my browser mangling the file for me. point 2. should probably be restricted to localhost or `hostname -d`. i don't know. will have to think some more about it. It may also be worthwhile doing this for file managers like mc, git, tkdesk. It would definitely be worthwhile to use less' LESSPIPE feature to do this. we can't patch netscape, but that's not our problem. people using netscape will just have to use dwww (which should be the preferred way of browsing debian docs anyway). I can't wait for the Mnemonic project to get off the ground...an extensible, modular, freeware web browser written using the Gimp's GTK widget set: Heaven! I'm getting really tired of netscape 4.0b5 crashing when I do Really Bad Things like click on a page to select a link or foolishly try to use it's drag and drop feature (it worked in 4.0b3, crashes almost 100% of the time under 4.0b5), or leave a netscape window idle for a while and have it just die for no apparent reason. Netscape is becoming yet another example of why free software is better than commercial/non-free. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks.
gated
On Thu, 4 Dec 1997, Dermot John Bradley wrote: > - gated (proposed): I built a package about 8-10 months ago but due to the > requirement for a license (because of the OSPF code) it couldn't go into > Debian (this was discussed on debian-devel back then). I still have my > .dsc and .diffs.gz files for this for an older version and I started work > on packaging gated 3.5.7 for libc6 last week (I see 3.5.8 has *just* come > out). Any suggestions what to do with the finished version? could it go in > non-free or would that still cause license problems? i think an installer package in contrib is the best solution. the installer should: - download the gated sources (using wget or lwp-request or snarf or an ftp script) - extract into /usr/src/debian/gated - apply debian patches - build the package this can either be done in the post-inst or by installing a /usr/sbin/make-gated script. the postinst version couldn't offer to install the built package (dpkg is not re-entrant) but the make-gated script could. note that there are no problems with DOWNLOADING gated sources. The weird licensing is only a problem if you want to DISTRIBUTE it. debian can't distribute any gated sources because we wont sign the distribution license agreement. > - ldap (proposed): built an unreleased package but could never get slurpd > to work (threads problem). Intending to build under libc6 which is > supposed to have better threads support. An alternative option is that > Critical Angle have an RPM version of their heavily hacked Umich ldap. Critical Angle's ldapd is non-free as far as i can tell from their license. craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 2.0.5c has a leak in inet_ntoa
On Wed, 26 Nov 1997, Philippe Troin wrote: > Libc6 2.0.5c has a leak in inet_ntoa. > > [...deleted...] > > The inside story is: due to a problem with libc6, libc_create_key is > not declared as a weak symbol of libpthread, and it's not wrapped in > a macro which detects if the program is linked with libpthread. The > result is that during the first call to inet_ntoa(), a libc_once > initialization routine is called, it thinks it's linked with > libpthread and attempts to create a thread-specific return buffer > through libc_create_key. > > [...deleted...] > > In the meantime, you can link programs which do heavy inet_ntoa with > libpthread, it will cure the leak (diald 0.16.4-11 does this, as a > temporary measure while waiting for libc6 2.0.6). ok, this is the bug i was looking for. anyone know if there is a fix for this yet? i just ran ldd on a random sample of daemons (sendmail, proftpd, squid, inetd, rpc.nfsd and apache...all latest versions as of yesterday) - none of them are linked with libpthread. imo it should be fixed in libc6 not in the daemonshowever, if a fix isn't going to be out for a while then these and other programs need to be recompiled asap. this bug is critical severity for any moderate-to-heavy use server. (it's crashed one of my mail servers and one of my gateway boxes already) anyone got a fix apart from recompiling everything that uses inet_ntoa? i've started a cron job to stop and restart various services every few hours, but that's a real crappy solutionespecially for squid - squid can take half an hour or more to restart on a big cache. any news on libc6 2.0.6? an ETA, perhaps? craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 2.0.5c has a leak in inet_ntoa
On 10 Dec 1997, Miquel van Smoorenburg wrote: > >ok, this is the bug i was looking for. anyone know if there is a fix > >for this yet? > > Yep, download libc6_2.0.6-0.2 (prerelease 2) from > ftp://ftp.ods.com/pub/linux/ and send [EMAIL PROTECTED] an email > with your experiences .. THANK YOU!! i wasn't expecting that this would be fixed yet. you've made my day! (and thanks to whoever compiled it too) > Has been running fine here for two or three weeks. excellent. craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 2.0.6 coredumps portmap (was Re: Libc6 2.0.5c has a leak in inet_ntoa)
On 10 Dec 1997, Miquel van Smoorenburg wrote:
> Yep, download libc6_2.0.6-0.2 (prerelease 2) from
> ftp://ftp.ods.com/pub/linux/ and send [EMAIL PROTECTED] an email
> with your experiences ..
>
> Has been running fine here for two or three weeks.
seems to cause portmap to core dumpwhich messes up nfs.
here's what strace says:
# strace /usr/sbin/portmap -d -v
execve("/usr/sbin/portmap", ["portmap", "-d", "-v"], [/* 39 vars */]) = 0
brk(0) = 0x804f43c
open("/etc/ld.so.preload", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
mmap(0, 16, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x4000c000
close(3)= 0
open("/lib/nfslock.so", O_RDONLY) = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000d000
munmap(0x4000d000, 4096)= 0
mmap(0, 7868, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000d000
mprotect(0x4000e000, 3772, PROT_NONE) = 0
mmap(0x4000e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x4000e000
close(3)= 0
munmap(0x4000c000, 16) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
mmap(0, 9821, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000f000
close(3)= 0
open("/lib/libnsl.so.1", O_RDONLY) = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)= 0
mmap(0, 21556, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40012000
mprotect(0x40016000, 5172, PROT_NONE) = 0
mmap(0x40016000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000)
= 0x40016000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)= 0
mmap(0, 663036, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000
mprotect(0x400a7000, 77308, PROT_NONE) = 0
mmap(0x400a7000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x8e000) = 0x400a7000
mmap(0x400ae000, 48636, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400ae000
close(3)= 0
mprotect(0x40018000, 585728, PROT_READ|PROT_WRITE) = 0
mprotect(0x40018000, 585728, PROT_READ|PROT_EXEC) = 0
mprotect(0x40012000, 16384, PROT_READ|PROT_WRITE) = 0
mprotect(0x40012000, 16384, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX) = 0
getpid()= 1376
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getpid()= 1376
bind(3, {sin_family=AF_INET, sin_port=htons(704),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EINVAL (Invalid argument)
bind(3, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = -1 EINVAL (Invalid argument)
getsockname(3, {sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
brk(0) = 0x804f43c
brk(0x804f484) = 0x804f484
brk(0x805) = 0x805
brk(0x8053000) = 0x8053000
getrlimit(RLIMIT_NOFILE, {rlim_cur=256, rlim_max=256}) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
bind(4, {sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
bind(4, {sin_family=AF_INET, sin_port=htons(705),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EINVAL (Invalid argument)
bind(4, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = -1 EINVAL (Invalid argument)
getsockname(4, {sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
listen(4, 2)= 0
setuid(1) = 0
sigaction(SIGINT, {0x804a7b0, [],
SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffa90}, {SIG_DFL}) = 0
sigaction(SIGCHLD, {SIG_IGN}, {SIG_DFL}) = 0
select(256, [3 4], NULL, NULL, NULL)= 1 (in [3])
working fine up until now.
at this point, on another VC i run "/etc/init.d/netstd_nfs start", and
portmap coredumps.
recvfrom(3, "5\205!\362\0\0\0\0\0\0\0\2\0\1\206"..., 8800, 0,
{sin_family=AF_INET, sin_port=htons(707), sin_addr=inet_addr("127.0.0.1")},
[16]) = 56
write(2, "server: about do a switch\n", 26server: about do a switch
) = 26
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
ioctl(5, SIOCGIFCONF, 0xbfffd4b8) = 0
ioctl(5, SIOCGIFFLAGS, 0xb4c0) = 0
ioctl(5, SIOCGIFADDR, 0xb4c0) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
hosts.allow is set up correctly for portmap. allows my local net numbers
and 127.0.0.1 and 255.255.255.255/0.0.0.0 as specified in
/usr/doc/netbase/portmapper.txt.gz
any ideas?
craig
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 2.0.6 coredumps portmap (was Re: Libc6 2.0.5c has a leak in inet_ntoa)
On Wed, 10 Dec 1997, Craig Sanders wrote: > On 10 Dec 1997, Miquel van Smoorenburg wrote: > > > Yep, download libc6_2.0.6-0.2 (prerelease 2) from > > ftp://ftp.ods.com/pub/linux/ and send [EMAIL PROTECTED] an email > > with your experiences .. > > > > Has been running fine here for two or three weeks. > > seems to cause portmap to core dumpwhich messes up nfs. more on this problem. portmap doesn't segfault on a freshly built hamm system (i.e. one built with bo and upgraded to hamm immediately a few days ago - which is acting as an NFS server, exporting a mirror of debian to the local network). portmap only coredumps on all of my systems which have been upgraded continuously since debian 0.93 or so. craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 2.0.6 coredumps portmap (was Re: Libc6 2.0.5c has a leak in inet_ntoa)
On Tue, 9 Dec 1997, David Engel wrote: > On Wed, Dec 10, 1997 at 12:12:21PM +1100, Craig Sanders wrote: > > more on this problem. portmap doesn't segfault on a freshly built > > hamm system (i.e. one built with bo and upgraded to hamm immediately > > a few days ago - which is acting as an NFS server, exporting a > > mirror of debian to the local network). > > Interesting. even more interesting is that some hamm machines i built a few weeks ago also had the portmap segfault problemwhatever it is must have changed in hamm recently. > Rebuilding netbase and netstd with libc6-2.0.6-0.2 appears to > fix it for me. I've put non-maintainer releases of both at > ftp://ftp.ods.com/pub/linux. fixes it for me too, on all machines. thanks for the quick fix (you must have a fast machine to recompile netbase & netstd so quickly :-) craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 2.0.5c has a leak in inet_ntoa
On Wed, 10 Dec 1997, Nils Rennebarth wrote: > On 10 Dec 1997, Miquel van Smoorenburg wrote: > > > In article <[EMAIL PROTECTED]>, > > Yep, download libc6_2.0.6-0.2 (prerelease 2) from > > ftp://ftp.ods.com/pub/linux/ and send [EMAIL PROTECTED] an email > > with your experiences .. > > > > Has been running fine here for two or three weeks. > > Could that bug be responsible for my rcp.nfsd growing to 30MB after heavy > use as an NFS server? > > I'll give that package a try. yep, that's the bug. also see the thread about libc6_2.0.6 coredumping portmap. to fix that, you also need to upgrade netbase and netstd to versions compiled with libc6_2.0.6. download and install the following files from ftp://ftp.ods.com/pub/linux: libc6_2.0.6-0.2_i386.deb locales_2.0.6-0.2_i386.deb timezones_2.0.6-0.2_i386.deb netbase_3.01-1.1_i386.deb netstd_3.00-1.1_i386.deb libc6-dev_2.0.6-0.2_i386.deb craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ipgrab package
On Wed, 10 Dec 1997, Michael Borella wrote: > I've built a package for ipgrab 0.4a1, a tcpdump-like utility > that prints out extensive Ethernet/IP/TCP/UDP/ARP header info. > It was built against libc5 so I don't know how useful it will be > for now. I'll upload it as soon as I get an account on debian.org. > If anybody wants to test it, go to > http://www.xnet.com/~cathmike/MSB/Software/ it coredumps on a hamm system, but easily fixed by recompiling. you might want to put the .dsc and .diff.gz file up on your web site too so that a debian package can easily be built for libc6. i just compiled it in /tmp and replaced /usr/sbin/ipgrab with the one i built. craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect features request
On Fri, 19 Dec 1997 [EMAIL PROTECTED] wrote: > While I had been a devoted Slackware fan, trying Debian convinced me > that it is far superior a distribution. However, in the process of > installing Debian 1.3.1 at least 15 times (several computers and > several different plans on how to install them all) it occurred to me > that two features in `dselect` would be WONDERFUL!!! > > 1) Once all packages are selected, be able to dump the selections to > a file that could be later read in for subsequent identical > installations. 'dpkg --get-selections' will output all selections to stdout, and 'dpkg --set-selections' will set selections from stdin. you can use this to redirect selections to a file and/or over a network connection with rsh or ssh. this isn't perfect, but can save a lot of time when you are building a lot of identical (or nearly identical) systems. > 2) Once all packages are selected, don't skip packages that are > deselected, just ignore them. Dselect for ftp install works this > way, why can't the disk based dselect as well? It looks like much > time is spent "skipping" packages that do not need to be > installed. try installing the dpkg-mountable package and selecting that as the access method (first option on the dselect menu). dpkg-mountable is a greatly improved install method which does what you want. it's close to perfect. IMO it would be perfect if it sorted the packages into dependancy order before installing them (maybe by making use of manoj's pkg-order stuff). craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
file descriptors??
is there any debian policy on number of file descriptors compiled into the kernel? (and also in limits.h in libc6-dev - AFAIK pretty much everything that uses select() will need to be recompiled if the limit is increased). some time ago the debian kernels came patched with 1024 fd's. this meant that squid and apache and other servers could run out of the box without running out of file descriptors (linux crashes badly when it runs out of fd's - not a pretty sight). recent kernels seem to have reverted back to 256 fd's. imo, 256 just isn't enough...especially when nearly the entire distribution has to be recompiled if a user wants to recompile a kernel with the >256 fd's patch. the latest ">256 fd's patch" mallocs an arbitrary number of file descriptors. should something be done about this for 2.0? or wait until 2.1? btw, we'll face have to face this problem when the 2.1 kernel is released as 2.2. craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: file descriptors??
On Tue, 6 Jan 1998, Elie Rosenblum wrote:
> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100:
> > is there any debian policy on number of file descriptors compiled into the
> > kernel? (and also in limits.h in libc6-dev - AFAIK pretty much everything
> > that uses select() will need to be recompiled if the limit is increased).
>
> This has been sysctl configurable in the runtime kernel since at most 2.0,
> probably 1.3.
>
> deliverator:[~]-#cd /proc/sys/kernel/
> deliverator:[/proc/sys/kernel]-#ls -l *-max *-nr
> -rw-r--r-- 1 root root0 Jan 6 13:40 file-max
> -r--r--r-- 1 root root0 Jan 6 13:40 file-nr
> -rw-r--r-- 1 root root0 Jan 6 13:40 inode-max
> -r--r--r-- 1 root root0 Jan 6 13:40 inode-nr
> deliverator:[/proc/sys/kernel]-#cat file-max inode-max
> 1024
> 4096
> deliverator:[/proc/sys/kernel]-#echo 2048>file-max; echo 8192>inode-max
> deliverator:[/proc/sys/kernel]-#cat file-max inode-max
> 2048
> 8192
> deliverator:[/proc/sys/kernel]-#
so why have there been patches to increase the number of available fd's
right up until recent kernel versions (e.g. 2.0.30)? here's what happens on
my 2.0.32 system:
[EMAIL PROTECTED] [08:41:43] kernel# cd /proc/sys/kernel/
[EMAIL PROTECTED] [08:41:58] kernel# ls -l *-max *-nr
-rw-r--r-- 1 root root0 Jan 7 08:40 file-max
-r--r--r-- 1 root root0 Jan 7 08:40 file-nr
-rw-r--r-- 1 root root0 Jan 7 08:40 inode-max
-r--r--r-- 1 root root0 Jan 7 08:40 inode-nr
[EMAIL PROTECTED] [08:42:34] kernel# cat file-max inode-max
1024
3072
[EMAIL PROTECTED] [08:42:41] kernel# echo 2048>file-max; echo
8192>inode-max
bash: file-max: Bad file descriptor
bash: inode-max: Bad file descriptor
[EMAIL PROTECTED] [08:42:48] kernel# cat file-max inode-max
1024
3072
strange. your system reports 1024 and 4096 for file-max and inode-max.
mine reports 1024 and 3072. yours allows it to be changed. mine doesn't.
what kernel version are you running? any patches? standard
linux-x.x.x.tar.gz or a debian patched kernel-source-x.x.x.deb (many of
the debian kernels were patched with various fixes and enhancements -
maybe debian's kernel should come with the linux "big-mama" or "big-mama's
best child" patch sets)?
anyway, here's what i'm running:
[EMAIL PROTECTED] [08:42:52] kernel# uname -a
Linux siva.taz.net.au 2.0.32 #1 Wed Dec 3 10:31:25 EST 1997 i486 unknown
bash seems to know that 256 fd's are available per process.
[EMAIL PROTECTED] [08:47:36] kernel# ulimit -a | grep files
open files 256
squid too (from the cachemgr.cgi):
File descriptor usage for squid:
Maximum number of file descriptors:256
Largest file desc currently in use: 25
Number of file desc currently in use: 25
Available number of file descriptors: 231
Reserved number of file descriptors:64
craig
--
craig sanders
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: file descriptors??
On 7 Jan 1998, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Craig Sanders <[EMAIL PROTECTED]> wrote: > > > >On Tue, 6 Jan 1998, Elie Rosenblum wrote: > > > >> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100: > >> > is there any debian policy on number of file descriptors compiled > >> > into the kernel? (and also in limits.h in libc6-dev - AFAIK > >> > pretty much everything that uses select() will need to be > >> > recompiled if the limit is increased). > >> > >> This has been sysctl configurable in the runtime kernel since at > >> most 2.0, probably 1.3. > > Not true. That's the global limit. The per-process limit is hardcoded > at 256 fds per process in the 2.0.x kernel yep. i realised after i sent this last message that i should have specified that i was talking about the per process fd limit, not the global limit. > > [EMAIL PROTECTED] [08:41:43] kernel# cd /proc/sys/kernel/ > > [EMAIL PROTECTED] [08:41:58] kernel# ls -l *-max *-nr > > -rw-r--r-- 1 root root0 Jan 7 08:40 file-max > > -r--r--r-- 1 root root0 Jan 7 08:40 file-nr > > -rw-r--r-- 1 root root0 Jan 7 08:40 inode-max > > -r--r--r-- 1 root root0 Jan 7 08:40 inode-nr > > [EMAIL PROTECTED] [08:42:41] kernel# echo 2048>file-max; echo > > 8192>inode-max > > bash: file-max: Bad file descriptor > > bash: inode-max: Bad file descriptor > > You forgot a space. Try echo 2048 > file-max. 2048>file-max means something > entirely different in shell-syntax.. that works now. which is odd because i cut and pasted Elie's example. anyway, as you point out, that only sets the global limit, not the per-process limit. i've tried applying the "gt256 fd patch" but that causes some NFS problems (i use nfs to mount my debian mirror for upgrades) which would probably go away if netstd and netbase were recompiled with the new fd limit. I feel that it's a bit unreasonable to expect debian users to recompile the entire system if they happen to be building a server (e.g. squid proxy or apache web server) that needs more than 256 fds. Given that debian makes an excellent web server or proxy or internet gateway machine out of the box it's not an uncommon thing to want to do... btw, as background info for this, i'm building a squid box with dual ppro 200 cpus, 512mb memory, 40GB disk (32gb cache, 8gb system, logging, etc and hot-swap root fs). this machine is expected to be able to handle at least 150 simultaneous users (with netscape's default of 4 connections at once) at any given moment. this is expected _average_ usage. peak usage could be double that. squid could quite easily require several thousand file descriptors under peak load. to add more temptation for murphy, this box is to be installed remotely - several thousand kilometres away. it's being built with the latest unstable now because i don't want to have to do a libc5 to libc6 upgrade remotely when hamm gets released...and debian's upgradability (for bug fixes and security fixes) is absolutely vital for a remote server like this, imo. you got any good ideas on what to do about the fd limits? is my assumption that increasing the per process limit will require re-compiling just about every package (e.g. squid, apache, netstd, netbase, libc6, . etc) correct or have i misunderstood something fundamental? how do you handle this issue on your squid box(es)? craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: file descriptors??
On 7 Jan 1998, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Craig Sanders <[EMAIL PROTECTED]> wrote: > >i've tried applying the "gt256 fd patch" but that causes some NFS > >problems (i use nfs to mount my debian mirror for upgrades) which would > >probably go away if netstd and netbase were recompiled with the new fd > >limit. > > What I do is something different. I put this in /etc/initscript: > > # Set # of fd's to 256 for all processes. > ulimit -S -n 256 > > That sets the soft limit for all processes to 256 fds. It can be raised > by an individual process if needed. My /etc/init.d/squid script contains: > > MAXFD=`ulimit -H -n` > if [ "$MAXFD" -gt 1024 ] > then > MAXFD=1024 > fi > ulimit -n $MAXFD > > So this way, the number of file descriptors for squid is 1024 max, but > for all other proceses it's limited to 256. i'll have to think about this. Does this mean that you don't have to actually patch the kernel any more? all you have to do is set the appropriate values in /proc/sys/kernel and then increase the ulimit? i just ran 'ulimit -H -n' on my linux 2.0.32 machines and got 256. Did you have to recompile the kernel to get more than that? what kernel version are you running? i think there's something quite basic that i must be missing...something must have changed. it used to be that you hacked limits.h and fs.h in /usr/src/linux/include/linux and recompiled the kernel and then recompiled whatever apps needed more fd's. sounds like that's not true any more. > >btw, as background info for this, i'm building a squid box with dual > >ppro 200 cpus, 512mb memory, 40GB disk (32gb cache, 8gb system, > >logging, etc and hot-swap root fs). > > That's a nice box. But don't expect any extra performance because it's > a SMP machine - squid is one monolithic process and will not benefit > from a second processor. yes. very nice. wish i had one here at home. the extra cpu is for the redirectors. this machine will also have to do a lot of filtering (using a redirector program rather than squid's acls so we can offload the processing load to the 2nd cpu). it's going into a school network and has to to provide the teachers with "access control". > 32 GB cache and 512MB of mem sounds about right for squid, you could > do with 256 or 384 MB if you'd run squid-novm (but squid-novm uses a > lot more file descriptors). i don't believe in squid-novm :-). file descriptors are a scarcer resource than memory. > >this box is to be installed remotely - several thousand kilometres > >away. it's being built with the latest unstable now because i don't > >want to have to do a libc5 to libc6 upgrade remotely when hamm gets > >released...and debian's upgradability (for bug fixes and security > >fixes) is absolutely vital for a remote server like this, imo. > > Don't worry - we have exactly the same setup (only 9GB of cache tho') > and it hasn't crashed ever. Except for the libc6 problems, but these > are now solved. I sacrificed myself as guinea pig when the box was > still installed here locally, and I think all bugs are gone now. yep, i've built several debian-based squid proxies of around the 256MB RAM and 9GB disk size - they work wonderfully. These machines have worked so well that a few people who started out with anti-linux attitudes have admitted that they were wrong :-) (you may remember that i was the one who made the first debian package for squid back in june '96, and then ran out of time to maintain it) craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc5 to libc6 auto-upgrade script
i think we're going to need some sort of auto-upgrade script to include on the hamm release CD rom, because dselect just can't do the libc6 upgrade safely (AFAIK). The CD will also Need a top-level README.NOW file saying run this script first or suffer the consequences...would be nice if we could have a note printed on the "Oficial" :-) CD-ROMS produces by various manufacturers too. Anyway, I wrote a primitive one based on Scott Ellis' HOWTO. Here it is. This script is untested. I've never actually run it. It is, however, an accurate duplicate of what I've done by hand over a dozen times by now. It will probably need some tweaking, in particular, the command line options for dpkg may need some --force- options. Also, all the "*/foo_*.deb" filenames should probably be replaced with the correct section directories. Anyone got a bo machine they want to test this on? I haven't got any left, they're all upgraded now :-) --- cut here --- #! /bin/sh # upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document. # first, build up a list of installed -dev packages so that we can # remove them. # # this is necessary even on machines which aren't doing libc6 # development because libc5 can't be upgraded to latest without removal # of libc5-dev which also necessitates removal of other -dev packages # like libdb1-dev and libdl1-dev if they are installed. DEVPACKAGES=`dpkg --get-selections | grep -- -dev | grep -v deinstall | cut -f1` dpkg --purge $DEVPACKAGES # now install the new versions of things. Just the bare minimum to let # the user safely run dselect for the rest of the upgrade. # change this to prompt the user for the location of the debian archive. cd /debian/dists/unstable/main/binary-i386 # libc # dpkg -iB */ldso_*.deb */libc5_*.deb */libc6_*.deb # bash # dpkg -iB */ncurses3.0_*.deb */ncurses3.4_*.deb dpkg -iB */libreadline2_*.deb */libreadlineg2_*.deb # paranoia says run ldconfig NOW. don't laugh, i've needed to do this on # some libc5-libc6 upgrades. i know that the postinst scripts for the # libs are supposed to do it but ldconfig dpkg -iB */bash_*.deb # new dpkg # dpkg -iB */libg++272_*.deb dpkg -iB */dpkg_*.deb */dpkg-dev_*.deb */dpkg-ftp_*.deb # perl # dpkg -iB */libgdbm_*.deb */libgdbm1g_*.deb # paranoia says "run ldconfig now". ldconfig dpkg -iB */perl-base_*.deb */perl_*.deb # the user can now run dselect and select any -dev packages they want # (and other packages too, of course :-) --- cut here--- -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 to libc6 auto-upgrade script
On Thu, 8 Jan 1998, Hamish Moffatt wrote: > On Thu, Jan 08, 1998 at 09:52:00AM +1100, Craig Sanders wrote: > > # development because libc5 can't be upgraded to latest without removal > > # of libc5-dev which also necessitates removal of other -dev packages > > # like libdb1-dev and libdl1-dev if they are installed. > > > > DEVPACKAGES=`dpkg --get-selections | > > grep -- -dev | > > grep -v deinstall | > > cut -f1` > > Is there any way you could mark these dev packages to be installed > at the end, by dselect when next run? That would be a nice touch I think. not really. they're obsolete libc5 versions which may or may not have libc6 and/or -altdev replacement packages. otherwise it would be trivial to pipe into dpkg --set-selections: ( for i in $DEVPACKAGES ; do echo "$i install" ; done ) | \ dpkg --set-selections craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 to libc6 auto-upgrade script
On Thu, 8 Jan 1998, Lindsay Allen wrote: > I did a new licb5 install and ran your script. Here are some > suggested changes. There may be more, but I wanted to get this out > the door to save everyone from covering the same ground. > > I put a " || exit" after the bash upgrade and suggest that more use be > made of this to bring the script to a halt after an error. done. > Is it OK to do the reboot asked for by the libc5 upgrade at the > completion of the script? yes, it's ok to type 'shutdown -r now'. no, i wont make the script do it. imo, you may as well run dselect and upgrade everything to hamm before rebooting so that you get a nice clean hamm system with only one reboot. here's an updated version of the script which includes suggestions from a few people, including yourself and a few improvements of my own. This is still mostly untested software. It probably wont completely destroy your system but I am making no guarrantees at all: USE AT YOUR OWN RISK. ---cut here--- #! /bin/sh # safely upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document. # Author: Craig Sanders <[EMAIL PROTECTED]> # # Copyright Status: This script is hereby placed in the public domain # # Revision History: # v0.0: 19980801 (morning) # - a rough transcript of scott's doc and my own experiences # v0.1: 19980801 (night) # - a few bugfixes # - i got unlazy and put in the right subdirectories for each package. # should run a lot faster. # - now checks for failure at critical points and exits with a different # exit code for each failure. # - now uses 'binary-$(dpkg --print-installation-architecture)' instead # of 'binary-i386'. # # TODO: (probably by somebody else. this script is mostly good enough imo) # - error checking # - be smarter about locating the hamm rootdir (or just assume we're in # the right directory to start with. look for ./base/libc6_*.deb as a # sanity check). # first, build up a list of installed -dev packages so that we can # remove them. remove wg-15-locale too. # # this is necessary even on machines which aren't doing libc6 # development because libc5 can't be upgraded to latest version without # removal of libc5-dev which also necessitates removal of other -dev # packages like libdb1-dev and libdl1-dev if they are installed. DEVPACKAGES=`dpkg --get-selections | grep -- -dev | grep -v deinstall | cut -f1` dpkg --remove -B $DEVPACKAGES wg-15-locale || exit 1 # now install the new versions of things. Just the bare minimum to let # the user safely run dselect for the rest of the upgrade. # change this to prompt the user for the location of the debian archive. cd /debian/dists/unstable/main/binary-$(dpkg --print-installation-architecture) # libc # dpkg -iB base/ldso_*.deb base/libc5_*.deb base/libc6_*.deb \ base/timezones_*.deb admin/locales_*.deb || exit 2 # libreadline, ncurses, and bash # dpkg -iB base/ncurses3.0_*.deb libs/ncurses3.4_*.deb || exit 3 dpkg -iB oldlibs/libreadline2_*.deb || exit 4 dpkg -iB base/libreadlineg2_*.deb || exit 5 # paranoia says run ldconfig NOW. don't laugh, i've needed to do this on # some libc5-libc6 upgrades. i know that the postinst scripts for the # libs are supposed to do it but ldconfig dpkg -iB base/bash_*.deb || exit 6 # new dpkg # dpkg -iB devel/libg++272_*.deb || exit 7 dpkg -iB base/dpkg_*.deb base/dpkg-dev_*.deb # strictly speaking, dpkg-ftp and dpkg-mountable are not essential to upgrade # right now but they're both very useful. dpkg -iB utils/dpkg-ftp_*.deb admin/admin/dpkg-mountable_*.deb # perl # dpkg -iB base/libgdbm1_*.deb devel/libgdbmg1_*.deb || exit 8 # paranoia says "run ldconfig now". ldconfig dpkg -iB base/perl-base_*.deb interpreters/perl_*.deb # the user can now run dselect and select any -dev packages they want # (and other packages too, of course :-) cat <<__EOF__ libc6 is now installed. Now run dselect to upgrade the rest of your system. Reboot for the utmp/wtmp wrapper functions in the upgraded libc5 to take effect. Also remember to fix up wtmp and utmp, otherwise last and who and sac etc wont work. here's what Miquel van Smoorenburg <[EMAIL PROTECTED]> had to say about this recently in debian-user mailing list: > 1. You need to update ALL your packages to hamm > 2. Reboot if you haven't done that already > 3. You need to move the wtmp file and truncate the utmp file: >cd /var/log >mv wtmp wtmp.libc5 >touch wtmp >cd /var/run >cp /dev/null utmp > 4. You might want to reboot again to make sure > > This is because the "struct utmp" and thus the utmp and wtmp > "databases" are different between libc5 and libc6 __EOF__ ---cut here--- -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 to libc6 auto-upgrade script
On Thu, 8 Jan 1998, Lindsay Allen wrote: > On Thu, 8 Jan 1998, Craig Sanders wrote: > > > dpkg -iB base/perl-base_*.deb interpreters/perl_*.deb > > Did you miss the change re perl? > > # perl-base must be configured before installing perl > dpkg -iB */perl-base_*.deb && dpkg -iB */perl_*.deb missed it entirely. ok, here's the next revision: ---cut here--- #! /bin/sh # safely upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document at http://www.gate.net/~storm/FAQ/libc5-libc6-Mini-HOWTO.html # Author: Craig Sanders <[EMAIL PROTECTED]> # # Copyright Status: This script is hereby placed in the public domain # # Revision History: # v0.0: 1998-01-08 (morning) # - a rough transcript of scott's doc and my own experiences # v0.1: 1998-01-08 (night) # - a few bugfixes # - i got unlazy and put in the right subdirectories for each package. # should run a lot faster. # - now checks for failure at critical points and exits with a different # exit code for each failure. # - now uses 'binary-$(dpkg --print-installation-architecture)' instead # of 'binary-i386'. # v0.2: 1998-01-09 # - fixed the perl-base/perl install (thanks Lindsay!) # - improved the DEVPACKAGES=$(dpkg --get-selections...) and added -dbg # packages. # # TODO: (probably by somebody else. this script is mostly good enough imo) # - error checking # - be smarter about locating the hamm rootdir (or just assume we're in # the right directory to start with. look for ./base/libc6_*.deb as a # sanity check). # first, build up a list of installed -dev packages so that we can # remove them. remove wg-15-locale too. # # this is necessary even on machines which aren't doing libc6 # development because libc5 can't be upgraded to latest version without # removal of libc5-dev which also necessitates removal of other -dev # packages like libdb1-dev and libdl1-dev if they are installed. DEVPACKAGES=$( dpkg --get-selections | grep -v deinstall | cut -f1 | grep -- "-dev$\|-dbg$" ) dpkg --remove -B $DEVPACKAGES wg-15-locale || exit 1 # now install the new versions of things. Just the bare minimum to let # the user safely run dselect for the rest of the upgrade. # change this to prompt the user for the location of the debian archive. cd /debian/dists/unstable/main/binary-$(dpkg --print-installation-architecture) # libc # dpkg -iB base/ldso_*.deb base/libc5_*.deb base/libc6_*.deb \ base/timezones_*.deb admin/locales_*.deb || exit 2 # libreadline, ncurses, and bash # dpkg -iB base/ncurses3.0_*.deb libs/ncurses3.4_*.deb || exit 3 dpkg -iB oldlibs/libreadline2_*.deb || exit 4 dpkg -iB base/libreadlineg2_*.deb || exit 5 # paranoia says run ldconfig NOW. don't laugh, i've needed to do this on # some libc5-libc6 upgrades. i know that the postinst scripts for the # libs are supposed to do it but ldconfig dpkg -iB base/bash_*.deb || exit 6 # new dpkg # dpkg -iB devel/libg++272_*.deb || exit 7 dpkg -iB base/dpkg_*.deb base/dpkg-dev_*.deb # strictly speaking, dpkg-ftp and dpkg-mountable are not essential to # upgrade right now but they're both very useful. dpkg -iB utils/dpkg-ftp_*.deb admin/admin/dpkg-mountable_*.deb # perl # dpkg -iB base/libgdbm1_*.deb devel/libgdbmg1_*.deb || exit 8 # paranoia says "run ldconfig now". ldconfig dpkg -iB base/perl-base_*.deb || exit 9 dpkg -iB interpreters/perl_*.deb # paranoia says: "run sync", so lets do it :-) sync ; sync ; sync # the user can now run dselect and select any -dev packages they want # (and other packages too, of course :-) more <<__EOF__ libc6 is now installed. Now run dselect to upgrade the rest of your system. When that's done, reboot with "shutdown -r now" for the utmp/wtmp wrapper functions in the upgraded libc5 to take effect. BTW, if you aren't using it already, check out dselect's "mountable" access method. It's much faster than the standard "mounted" method, and it logs everything that happens in /var/log/dpkg-mountable. You'll want to set "Allow overwriting repeated files?" to yes, and for extra speed set "Enable MD5 checksumming?" to no. Finally, remember to fix up wtmp and utmp, otherwise last and who and sac etc wont work. here's what Miquel van Smoorenburg <[EMAIL PROTECTED]> had to say about this recently in debian-user mailing list: > 1. You need to update ALL your packages to hamm > 2. Reboot if you haven't done that already > 3. You need to move the wtmp file and truncate the utmp file: >cd /var/log >mv wtmp wtmp.libc5 >touch wtmp >cd /var/run >cp /dev/null utmp > 4. You might want to reboot again to make sure
Re: libc5 to libc6 auto-upgrade script
On Fri, 9 Jan 1998, Lindsay Allen wrote: > Still one problem. /wg-15-locale/s//wg15-locale/ damn. i thought i got that one this morning. i wont bother posting the script again. it's easy enough to fix. craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: file descriptors??
On 7 Jan 1998, Kai Henningsen wrote: > [EMAIL PROTECTED] (Craig Sanders) wrote on 07.01.98 in <[EMAIL PROTECTED]>: > > > On 7 Jan 1998, Miquel van Smoorenburg wrote: > > > > > In article <[EMAIL PROTECTED]>, > > > Craig Sanders <[EMAIL PROTECTED]> wrote: > > > > > > > >On Tue, 6 Jan 1998, Elie Rosenblum wrote: > > > > > > > >> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100: > > > i've tried applying the "gt256 fd patch" but that causes some NFS > > problems (i use nfs to mount my debian mirror for upgrades) which would > > probably go away if netstd and netbase were recompiled with the new fd > > limit. I feel that it's a bit unreasonable to expect debian users to > > recompile the entire system if they happen to be building a server (e.g. > > squid proxy or apache web server) that needs more than 256 fds. Given > > that debian makes an excellent web server or proxy or internet gateway > > machine out of the box it's not an uncommon thing to want to do... > > Well, with libc6, they don't have to, unles they need more than 1024 files > per process. Kernel and maybe libc, but not the rest. so if i need more than 1024 file descriptors (say 4096 fds for squid and 1024 for everything else == 5120 total) for squid then all i have to recompile is squid and libc6 and the kernel??? as long as i have the soft ulimit set in /etc/initscript as mvs suggested then everything else will work without recompilation? btw, Miquel said: > What I do is something different. I put this in /etc/initscript: > > # Set # of fd's to 256 for all processes. > ulimit -S -n 256 > > That sets the soft limit for all processes to 256 fds. It can be > raised by an individual process if needed. My /etc/init.d/squid script > contains: > > MAXFD=`ulimit -H -n` > if [ "$MAXFD" -gt 1024 ] > then > MAXFD=1024 > fi > ulimit -n $MAXFD i'd change that to MAXFD=4096 of course. > See this excerpt from /usr/include/gnu/types.h: > > > > /* One element in the file descriptor mask array. */ > typedef unsigned long int __fd_mask; > > /* Number of descriptors that can fit in an `fd_set'. */ > #define __FD_SETSIZE 1024 so, change this to 5120, then recompile libc6 and and the kernel and squid... > > you got any good ideas on what to do about the fd limits? is my > > assumption that increasing the per process limit will require > > re-compiling just about every package (e.g. squid, apache, netstd, > > netbase, libc6, . etc) correct or have i misunderstood something > > fundamental? > > That depends on how far you want to increase it. 3 or 4 thousand fds for squid should be enough, plus 1000 for everything else running on the systemso round it off to 5120. any more than that and the machine probably wouldn't be able to cope with the load anyway. craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: time stamps tomorrow?
On Fri, 9 Jan 1998 [EMAIL PROTECTED] wrote: > Some files at llug.sep.bnl.gov/pub/debian/Incoming are stamped on 10 January > 1998. As I write, nowhere on Earth is it now 10 January. that just proves how advanced debian is, doesn't it :-) craig -- craig sanders Debian: ahead of it's time. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 to libc6 auto-upgrade script
On Fri, 9 Jan 1998, Turbo Fredriksson wrote: > On Fri, 9 Jan 1998, Craig Sanders wrote: > > > On Fri, 9 Jan 1998, Lindsay Allen wrote: > > > Still one problem. /wg-15-locale/s//wg15-locale/ > > damn. i thought i got that one this morning. > > i wont bother posting the script again. it's easy enough to fix. > > Could this script be uploaded to ftp.debian.org (Preferably in the tools > directory) and updated every time someone make improvments to it? good idea. while we're at it, lets make subdirectories for the upgrades directory: rex-to-bo/ (obsolete ???) and bo-to-hamm/ who's got write permission on the ftp site to do this? (i don't think i have). craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re:libc5 to libc6 auto-upgrade script
here's another update to igor's latest version. this one: - avoids duplicated code - tells the user what it's doing - has more error checking - guesses at the location of the mirror enjoy! ---cut here--- #! /bin/sh DPKG=`which dpkg` LDCONFIG=`which ldconfig` # uncomment for debugging #set -x #DPKG="echo dpkg" #LDCONFIG="echo LDCONFIG" # upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document at http://www.gate.net/~storm/FAQ/libc5-libc6-Mini-HOWTO.html # Author: Craig Sanders <[EMAIL PROTECTED]> # # Copyright Status: This script is hereby placed in the public domain # # Revision History: # v0.0: 1998-01-08 (morning) # - a rough transcript of scott's doc and my own experiences # v0.1: 1998-01-08 (night) # - a few bugfixes # - i got unlazy and put in the right subdirectories for each package. # should run a lot faster. # - now checks for failure at critical points and exits with a different # exit code for each failure. # - now uses 'binary-$(dpkg --print-installation-architecture)' instead # of 'binary-i386'. # v0.2: 1998-01-09 # - fixed the perl-base/perl install (thanks Lindsay!) # - improved the DEVPACKAGES=$(dpkg --get-selections...) and added -dbg # packages. # v0.3: 1998-01-09 (p.m.) # - fixed some directories # - changed "-iB" to "-iBE" so that if the script fails and is run again # it will not disturb things already in place. # - added a final "dpkg --configure --pending". # - sanity check that we are in the right place added # v0.4: 1998-01-10 (Igor Grobman) # - made it possible to place all packages in current dir. # - added -pic packages to removal list. # - make sure dpkg-dev does not get selected for removal. # - moved dpkg-ftp and dpkg-mounted to the end. #v0.5: 1998-01-10 (Igor Grobman) # - added a note about upgrading libraries #v0.6: 1998-01-11 (Craig Sanders) # - restructured code to avoid code duplication. # - cleaned up a few things # - prints advisory notes telling user what's happening. # - added some more instructions on what to do about development packages. # - added code to guess some obvious locations for the mirror, otherwise # ask user. # # TODO: (probably by somebody else. this script is mostly good enough imo) # - this script _still_ needs more error checking :-) PKGS_LIBC6="base/ldso_*.deb base/libc5_*.deb base/libc6_*.deb \ base/timezones_*.deb admin/locales_*.deb" PKGS_NCURSES="libs/ncurses3.0_*.deb base/ncurses3.4_*.deb" PKGS_LIBRL="oldlibs/libreadline2_*.deb" PKGS_LIBRLG="base/libreadlineg2_*.deb" PKGS_BASH="base/bash_*.deb" PKGS_LIBGPP="devel/libg++272_*.deb" PKGS_DPKG="base/dpkg_*.deb utils/dpkg-dev_*.deb" PKGS_LIBGDBM="base/libgdbm1_*.deb devel/libgdbmg1_*.deb" PKGS_PERLBASE="base/perl-base_*.deb" PKGS_PERL="interpreters/perl_*.deb" PKGS_MOREDPKG="base/dpkg-ftp_*.deb admin/dpkg-mountable_*.deb" cat <<__EOF__ This script will install the packages necessary to ensure a safe upgrade to hamm. You need to either have a local or remote mirror mounted, or have the latest versions of the following packages from hamm available in the current directory: ldso, libc5, libc6, timezones, locales, ncurses3.0, ncurses3.4, libreadline2, libreadlineg2, bash, libg++272, dpkg, dpkg-dev, dpkg-ftp, dpkg-mountable, libgdbm1, libgdbmg1, perl-base, and perl. If you are using a mirror, press 'm'. __EOF__ echo -n "if you have the files in the current dir, press 'c': (m/c) " read answer case "$answer" in m|M) # local mirror available # ask where the mirror is (this could do with some error checking) echo echo "enter the full path to your local mirror of debian: " echo "e.g. /debian/dists/unstable/main/binary-i386/" echo TRY="/debian/dists/unstable/main/binary-i386 ~ftp/debian/dists/unstable/main/binary-i386 " for i in $TRY ; do if [ -d $i ] ; then DEFAULT=$i fi done [ -n "$DEFAULT" ] && echo or just hit enter to use "$i". read DM [ -z "$DM" ] && DM=$DEFAULT SEDSCRIPT="s:\([^ /]*/\):$DM/\1:g" ;; c|C) # current directory SEDSCRIPT='s:[^ /]*/::g' ;; esac echo "building list of package filenames to install..." # convert PKGS_ variables to correct directory location PKGS_LIBC6=$( echo $PKGS_LIBC6 | sed -e "$SEDSCRIPT" ) PKGS_NCURSES=$( echo $PKGS_NCURSES | sed -e "$SEDSCRIPT" ) PKGS_LIBRL=$( echo $PK
Re:libc5 to libc6 auto-upgrade script
oops. i hard-coded 'binary-i386'. mea culpa. ---cut here--- #! /bin/sh DPKG=`which dpkg` LDCONFIG=`which ldconfig` # uncomment for debugging #set -x #DPKG="echo dpkg" #DCONFIG="echo LDCONFIG" # upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document at http://www.gate.net/~storm/FAQ/libc5-libc6-Mini-HOWTO.html # Author: Craig Sanders <[EMAIL PROTECTED]> # # Copyright Status: This script is hereby placed in the public domain # # Revision History: # v0.0: 1998-01-08 (morning) # - a rough transcript of scott's doc and my own experiences # v0.1: 1998-01-08 (night) # - a few bugfixes # - i got unlazy and put in the right subdirectories for each package. # should run a lot faster. # - now checks for failure at critical points and exits with a different # exit code for each failure. # - now uses 'binary-$(dpkg --print-installation-architecture)' instead # of 'binary-i386'. # v0.2: 1998-01-09 # - fixed the perl-base/perl install (thanks Lindsay!) # - improved the DEVPACKAGES=$(dpkg --get-selections...) and added -dbg # packages. # v0.3: 1998-01-09 (p.m.) # - fixed some directories # - changed "-iB" to "-iBE" so that if the script fails and is run again # it will not disturb things already in place. # - added a final "dpkg --configure --pending". # - sanity check that we are in the right place added # v0.4: 1998-01-10 (Igor Grobman) # - made it possible to place all packages in current dir. # - added -pic packages to removal list. # - make sure dpkg-dev does not get selected for removal. # - moved dpkg-ftp and dpkg-mounted to the end. #v0.5: 1998-01-10 (Igor Grobman) # - added a note about upgrading libraries #v0.6: 1998-01-11 (Craig Sanders) # - restructured code to avoid code duplication. # - cleaned up a few things # - prints advisory notes telling user what's happening. # - added some more instructions on what to do about development packages. # - added code to guess some obvious locations for the mirror, otherwise # ask user. #v0.7: 1998-01-11 (CS) # - uh oh. i hard-coded in binary-i386. quick...better release another # version before James notices. # # TODO: (probably by somebody else. this script is mostly good enough imo) # - this script _still_ needs more error checking :-) ARCH="binary-$(dpkg --print-installation-architecture)" PKGS_LIBC6="base/ldso_*.deb base/libc5_*.deb base/libc6_*.deb \ base/timezones_*.deb admin/locales_*.deb" PKGS_NCURSES="libs/ncurses3.0_*.deb base/ncurses3.4_*.deb" PKGS_LIBRL="oldlibs/libreadline2_*.deb" PKGS_LIBRLG="base/libreadlineg2_*.deb" PKGS_BASH="base/bash_*.deb" PKGS_LIBGPP="devel/libg++272_*.deb" PKGS_DPKG="base/dpkg_*.deb utils/dpkg-dev_*.deb" PKGS_LIBGDBM="base/libgdbm1_*.deb devel/libgdbmg1_*.deb" PKGS_PERLBASE="base/perl-base_*.deb" PKGS_PERL="interpreters/perl_*.deb" PKGS_MOREDPKG="base/dpkg-ftp_*.deb admin/dpkg-mountable_*.deb" cat <<__EOF__ This script will install the packages necessary to ensure a safe upgrade to hamm. You need to either have a local or remote mirror mounted, or have the latest versions of the following packages from hamm available in the current directory: ldso, libc5, libc6, timezones, locales, ncurses3.0, ncurses3.4, libreadline2, libreadlineg2, bash, libg++272, dpkg, dpkg-dev, dpkg-ftp, dpkg-mountable, libgdbm1, libgdbmg1, perl-base, and perl. If you are using a mirror, press 'm'. __EOF__ echo -n "if you have the files in the current dir, press 'c': (m/c) " read answer case "$answer" in m|M) # local mirror available # ask where the mirror is (this could do with some error checking) echo echo "enter the full path to your local mirror of debian: " echo "e.g. /debian/dists/unstable/main/$ARCH/" echo TRY="/debian/dists/unstable/main/$ARCH ~ftp/debian/dists/unstable/main/$ARCH " for i in $TRY ; do if [ -d $i ] ; then DEFAULT=$i fi done [ -n "$DEFAULT" ] && echo or just hit enter to use "$i". read DM [ -z "$DM" ] && DM=$DEFAULT SEDSCRIPT="s:\([^ /]*/\):$DM/\1:g" ;; c|C) # current directory SEDSCRIPT='s:[^ /]*/::g' ;; esac echo "building list of package filenames to install..." # convert PKGS_ variables to correct directory location PKGS_LIBC6=$( echo $PKGS_LIBC6 | sed -e "$SEDSCRIPT" ) PKGS_NCURSES=$( echo $PKGS_NCURSES | sed -e "$SEDSCRIPT" ) PKGS_LIBRL=$( ech
version 0.8 of libc5 to libc6 auto-upgrade script
I just ran this script on an old system (somewhere between rex and bo) with lots of -dev packages installed. found and fixed two bugs. - libc6 conflicts with libpthread0 - i made a typo... PKGS_GPP instead of PKGS_LIBGPP. - some old version of perl's postrm didn't delete a .packlist file from /usr/lib/perl5/i486-linux/5.003/auto/Mail/.packlist. check for it and delete if found before installing perl. apart from those problems, it ran through cleanly. i think it's nearly finished (but i said that around version 0.2 didn't I :-) ---cut here--- #! /bin/sh DPKG=`which dpkg` LDCONFIG=`which ldconfig` # uncomment for debugging #set -x #DPKG="echo dpkg" #LDCONFIG="echo LDCONFIG" # upgrade a libc5 (bo) machine to libc6 (hamm). # based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO" # document at http://www.gate.net/~storm/FAQ/libc5-libc6-Mini-HOWTO.html # Author: Craig Sanders <[EMAIL PROTECTED]> # # Copyright Status: This script is hereby placed in the public domain # # Revision History: # v0.0: 1998-01-08 (morning) # - a rough transcript of scott's doc and my own experiences # v0.1: 1998-01-08 (night) # - a few bugfixes # - i got unlazy and put in the right subdirectories for each package. # should run a lot faster. # - now checks for failure at critical points and exits with a different # exit code for each failure. # - now uses 'binary-$(dpkg --print-installation-architecture)' instead # of 'binary-i386'. # v0.2: 1998-01-09 # - fixed the perl-base/perl install (thanks Lindsay!) # - improved the DEVPACKAGES=$(dpkg --get-selections...) and added -dbg # packages. # v0.3: 1998-01-09 (p.m.) # - fixed some directories # - changed "-iB" to "-iBE" so that if the script fails and is run again # it will not disturb things already in place. # - added a final "dpkg --configure --pending". # - sanity check that we are in the right place added # v0.4: 1998-01-10 (Igor Grobman) # - made it possible to place all packages in current dir. # - added -pic packages to removal list. # - make sure dpkg-dev does not get selected for removal. # - moved dpkg-ftp and dpkg-mounted to the end. #v0.5: 1998-01-10 (Igor Grobman) # - added a note about upgrading libraries #v0.6: 1998-01-11 (Craig Sanders) # - restructured code to avoid code duplication. # - cleaned up a few things # - prints advisory notes telling user what's happening. # - added some more instructions on what to do about development packages. # - added code to guess some obvious locations for the mirror, otherwise # ask user. #v0.7: 1998-01-11 (Craig Sanders) # - uh oh. i hard-coded in binary-i386. quick...better release another # version before James notices. #v0.8: 1998-01-11 (Craig Sanders) # - added libpthread0 to the remove list. # - fixed PKGS_LIBGPP (i mistyped it as PKGS_GPP) # - some old version of perl's postrm didn't delete a .packlist file # from /usr/lib/perl5/i486-linux/5.003/auto/Mail/.packlist. check for # it and delete if found before installing perl. # # TODO: (probably by somebody else. this script is mostly good enough imo) # - this script _still_ needs more error checking :-) ARCH="binary-$(dpkg --print-installation-architecture)" PKGS_LIBC6="base/ldso_*.deb base/libc5_*.deb base/libc6_*.deb \ base/timezones_*.deb admin/locales_*.deb" PKGS_NCURSES="libs/ncurses3.0_*.deb base/ncurses3.4_*.deb" PKGS_LIBRL="oldlibs/libreadline2_*.deb" PKGS_LIBRLG="base/libreadlineg2_*.deb" PKGS_BASH="base/bash_*.deb" PKGS_LIBGPP="devel/libg++272_*.deb" PKGS_DPKG="base/dpkg_*.deb utils/dpkg-dev_*.deb" PKGS_LIBGDBM="base/libgdbm1_*.deb devel/libgdbmg1_*.deb" PKGS_PERLBASE="base/perl-base_*.deb" PKGS_PERL="interpreters/perl_*.deb" PKGS_MOREDPKG="base/dpkg-ftp_*.deb admin/dpkg-mountable_*.deb" cat <<__EOF__ This script will install the packages necessary to ensure a safe upgrade to hamm. You need to either have a local or remote mirror mounted, or have the latest versions of the following packages from hamm available in the current directory: ldso, libc5, libc6, timezones, locales, ncurses3.0, ncurses3.4, libreadline2, libreadlineg2, bash, libg++272, dpkg, dpkg-dev, dpkg-ftp, dpkg-mountable, libgdbm1, libgdbmg1, perl-base, and perl. If you are using a mirror, press 'm'. __EOF__ echo -n "if you have the files in the current dir, press 'c': (m/c) " read answer case "$answer" in m|M) # local mirror available # ask where the mirror is (this could do with some error checking) echo echo "enter the full path to your local mirror of debian: " echo "e.
Re:libc5 to libc6 auto-upgrade script
On Sun, 11 Jan 1998, Shaya Potter wrote: > You should make sure that you record which -dev packages are > installed. You also might be able to set up a script that can take a > list of -dev packages from bo, and tell dpkg to install the comparable > packages from Hamm. somebody's already suggested that. i don't think it's worth the effort - partly because there is no one-to-one mapping between bo and hamm -dev packages, and partly because it would be a long and tedious job...made more difficult by the fact that you need both a bo system and a hamm system to compare package lists on. i'm not against it. i think it would be a good thing. if somebody feels like modifying the script to do that then they're perfectly welcome to do so. my autoupgrade script was written to do the dangerous part of the upgrade and leave the rest for the user to do in dselect. it does that quite well. imo, except for bugfixes and maybe polishing the user input bits it's basically finished. i ran it earlier tonight on an old rex (or rex++, not quite bo anyway) system, and it even worked on that. craig -- craig sanders -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [info@troll.no] The KDE Free Qt Foundation
On 8 Apr 1998, Stephen Zander wrote: > Anyone care to comment? the announcement doesn't mention any change to the Qt license, just the formation of a Qt foundation. if this results in a new Qt license which meets the DFSG (specifically the items regarding modifying source and non-discrimination) then both KDE and Qt can go into debian main. i hope that this is what will happen. if not, then KDE still belongs in contrib. this is definitely worth investigating, anyway. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Mon, 6 Apr 1998, Santiago Vila Doncel wrote: > Well, this is what I use it for myself. I use PS1='\h:\w\$ ' for an > ordinary user and PS1='[EMAIL PROTECTED]:\w\$ ' for root. Rationale: I'm root > only > in my machine (as most Debian users, I think) and therefore when I'm > "sanvila" I am not usually interested in the username. > > However, I'm willing to set default root's prompt in base-files to > '\h:\w\$ ' if enough people prefer it to '[EMAIL PROTECTED]:\w\$ '. i prefer '[EMAIL PROTECTED] \w\$ '. username in the prompt is very useful. root has to su to several different uids in order to do certain types of mainte.g. su postgres, su uucp, su news. working directory in the prompt is essential. how else can you keep track of where each one of dozens of different shells are? hostname is vital. anyone working on more than one machine knows this. FWIW, i don't care too much what's in the default anyway. I always copy in ~/.bashrc, ~/.bash_profile, and my own ~/.bash-aliases (which is sourced by .bashrc) onto every new machine i build. i also edit /etc/profile to what i want it to bePATH, MANOPT, EDITOR, LESSPIPE and others. whatever the debian default is, it's NOT going to be what i need because what i need probably isn't what other people need, and vice-versa. btw, a couple of useful aliases: alias savealias='alias >~/.bash-aliases' alias loadalias='. ~/.bash-aliases' i create aliases interactively at the shell prompt and run savealias whenever i have a good new one i want to keep. loadalias is only there so i can easily load newly created aliases into already running bash xterms. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
autoup.sh v0.24 released (was Re: autoup.sh bug)
On Mon, Apr 20, 1998 at 07:15:23PM +0100, Philip Hands wrote: > I did a bo--hamm upgrade over the weekend using your autoup.sh: > > $Id: autoup.sh,v 0.23 1998/03/26 15:31:10 root Exp root $ > > and got this when it got to installing dpkg: > > > dpkg: regarding .../base/dpkg_1.4.0.22.deb containing dpkg, pre-dependency > problem: > dpkg pre-depends on libstdc++2.8 > libstdc++2.8 is not installed. > dpkg: error processing > /mirror/Debian/dists/frozen/main/binary-i386/base/dpkg_1.4.0.22.deb > (--install): > pre-dependency problem - not installing dpkg > > > which suggests to me that the libstdc++ needs to be added to the list of > things that are installed before dpkg. I've just released version 0.24 which fixes this (and a few minor problems too). v0.24: 1998-04-21 (Craig Sanders) - added libstdc++, libslang0.99.34 (libc5), libslang0.99.38 (libc6), netbase, and netstd to the list of packages to install. - changed 'unstable' to 'frozen' in various places. - [EMAIL PROTECTED] reported that the downloading the files to /var/lib/dpkg/methods/ftp messes up the ftp method somehow. changed TRY to /tmp/autoup. -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoup.sh v0.25 released
BTW, i've also made some changes to my http://debian.vicnet.net.au/autoup site. 1. updated autoup.tar.gz to have the latest versions of all the needed packages. 2. made it accessible as ftp://debian.vicnet.net.au/autoup (some people requested this) 3. made a debfiles/ directory which contains all the individual packages in autoup.tar.gz for people who want to download them one at a time. if anyone mirrors this then they should probably just exclude the large binaries from their mirror and run the make-tarfiles.sh script locallysaves mirroring 14mb of stuff which they should already have in their local mirror. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoup.sh v0.25 released
> I've just released version 0.24 which fixes this (and a few minor problems > too). > > v0.24: 1998-04-21 (Craig Sanders) > - added libstdc++, libslang0.99.34 (libc5), libslang0.99.38 (libc6), >netbase, and netstd to the list of packages to install. > - changed 'unstable' to 'frozen' in various places. > - [EMAIL PROTECTED] reported that the downloading the files to >/var/lib/dpkg/methods/ftp messes up the ftp method somehow. changed >TRY to /tmp/autoup. make that 0.25. i forgot to disable the debugging stuff before releasing it. v0.25: 1998-04-21 (Craig Sanders) - remembered to disable debugging stuff so that the script actually does something. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: uedit
On Wed, Apr 29, 1998 at 09:32:04PM +0200, Santiago Vila wrote:
> > To get maximum speed uedit will disable the wasteful multi-tasking
> > behaviour of Linux and make it do the Right thing, DOS-style
> > single-tasking. Obviously neither X nor networking survive, yay!
> > Network users should stop wasting bandwidth and use a local machine.
>
> I hope you will give it a priority of "extra", then.
and don't forget these:
Conflicts: Clue
Recommends: dos-weenie-attitude
craig
--
craig sanders
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Fri, May 01, 1998 at 12:32:26PM +0200, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Thu, 30 Apr 1998, Rev. Joseph Carter wrote: > > > The postinst for the .deb will compile the source, install the .deb, and > > clean up after itself if you so desire for a -src package... > > Well, I don't plan to do that. I think it would be too much for a -src > package. > > I will simply add a README saying how to unpack the source and build it. > The main point is to make it available from dselect. All other concerns > are secondary. dpkg isn't 're-entrant', anyway, so you couldn't install another package from within a postinst script. what you could do, though, is do what the qmail-src package does. include a build-pine script (which does the things mentioned above), and also print a message telling the user about it in the postinst script. the qmail-src package works very nicely (i tried it out on a 'spare' machine recently - qmail's quite nice...if it wasn't for the license and attitude problems i'd be quite tempted to switch to it) and the build-qmail script could probably be very easily modified to be a build-pine script. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On Sat, 2 May 1998, Rev. Joseph Carter wrote: > smail is NASTY to configure over dialup links. And getting worse it seems. > I couldn't do it. sendmail is clearly not suited for the task. ^^^ why? sendmail configuration is a no-brainer with debian's sendmailconfig script. it can handle probably 99% of cases likely to be needed by most users...all the user has to do is answer a few questions (which have sensible defaults). configuring sendmail only becomes difficult when you need to do weird or complicated things. craig -- craig sanders
Re: Time to say goodbye...
On Mon, 4 May 1998, Michael Meskes wrote: > Jim Pick writes: > > I must admit, I've been entirely negligent in following the policy > > discussions - due to lack of time, I've skipped them entirely. > > Me too. > > > I suspect that most of the other "older" maintainers are the same way > > - they've skipped the policy discussions altogether - which would > > explain your perceived lack of support. > > Yes. This holds for me too. me too. (ordinarily, i wouldn't make a "me too" post but i think it's important for Christian to see that he does have support and that we do appreciate the work he's done) craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New APT version
On Tue, 5 May 1998, Jason Gunthorpe wrote: > On Tue, 5 May 1998, Joey Hess wrote: > > > This makes me wonder if we should think about dropping autoup as > > the preferred way to upgrade to hamm, and switch to apt. On the one > > hand, autoup has been tested pretty thouroghly and we shouldn't risk > > postponing debian 2.0 to work out bugs in apt. On the other hand, > > I've never seen autoup as anything but a hack. Apt also lets people > > accomplish the entire bo -> hamm upgrade from inside dselect, which > > is much cleaner. i agree. if apt can do it and is ready in time for testing then we should certainly drop autoup and use apt instead. autoup *is* just a hack to get around a few deficiencies in dselect/'dpkg -iGROEB'. if it's no longer needed, then throw it awayit served it's purpose for the time it *was* needed. > Well, not to belittle auto-up, but has it been kept up with the new > bo->hamm elements? yep. > Dpkg now depends on libstdc++ for instance. i released a new version to cope with this (and slang dependancies and other stuff) only a week or so ago. i update it as required, and as people inform me that it has problems. > As far as bugs in apt go, I have been running a beta for the past > month on alot of different machines and system and people. I have > monitored about 5 bo upgrades that apt didn't have any problem with > (there were package bugs though) if apt can do a complete bo -> hamm upgrade without requiring the user to install a few packages by hand then we should use it. > The very nice thing about apt is that it is highly deterministic in > it's ordering, if you do one upgrade you can be pretty sure that alot > of other similar ones will work correctly as well. I tried to do alot > to make things happen in a highly predictable and constant order. yes, i really like apt. i've been using it to upgrade my own systems for a few weeks now. it works. i've used 'apt-get upgrade' from the command line, and apt as a dselect access method...i am very impressed with apt's performance. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: so what? Re: Debian development modem
On Fri, 29 May 1998, Philip Hands wrote: > > Sorry, now I don't understand. I think we should release twice a year. > > What about encouraging people to press ``Debian Unstable Snapshots'' > once every couple of months. > > We could do the snapshot images ourselves (so that everyone's ``May > 98'' image was exactly the same), give it a few days testing to ensure > that it's not completely broken, and suggest in the documentation that > people look at the web site for any problems and work-arounds found > after release. > > As long as it is published with warnings that it is just a snapshot, > and not a tested release, we should not be tarnish our image, while > providing the bandwidth limited folks with an alternative ``download'' > method. yes, i think this is essentialbut it should be every month, not every 2 or 3. so this means we need automated tools which can seamlessly make a snapshot cd image from the current unstable tree. i also think that debian should have three main teams: 1. developers. this is everyone, including members of teams 2 & 3. release packages into unstable as usual. develop neat things like install-mime and menu and so on. hack, hack, hack. 2. release team. they do whatever they need to do to make a release. if they need to modify a package, they just do it without waiting for the package maintainer to get around to it. they should submit their mods to the maintainer, but are not bound by the maintainer's packaging decisions - the release is their baby, and their word is final. 3. marketing and market research team. promotion of debian, and researching user's needs/wants. drafting proposals to implement those needs. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: so what? Re: Debian development modem
On Sat, 30 May 1998, Bdale Garbee wrote: > I had an interesting chat with one of my cohorts at work today about > this topic. We spent some time thinking about the various Debian > users we know, and tried to characterize what they want from the > distribution. What we came up with was the notion that it splits > three ways. > [...deleted...] Wow! an excellent post. couldn't agree with it more. (btw, this sort of thing is one the things i envisioned being done by the 'marketing & market research' team i suggested). > We think the third group represents the primary target market for a > distribution like Debian. This group has good net access, wants to > stay reasonably current, but can't tolerate dealing with the worst 10% > or so of the package churn that happens in a bleeding-edge "unstable" > tree. They would prefer not to bump into any real problems, but > they're willing to stumble once in a while if that's the price of > keeping up with security patches, new development tool releases, > and the like. This group might be characterized by those who are > currently running 'hamm' on production servers, as we do at work. these are the people who would really benefit from having monthly or bi-monthly snapshot cd-roms. i think that some, but not all, would have good net access. if they all had net access then the number of people in group 1 would be much higher as their desires are closer to group 1 than group 2. So regular snapshot CDs are very important for these people. > [...deleted...] but also to build a "stable but unreleased" tree for > this third group. The key concept is that if a package version has > been released for some period of time (a week, a month, not sure how > long makes sense) without being retracted or superceded, then it is, > by definition, "stable"... even though it's absolute quality is still > an unknown. yes, this is a great idea too. and as you say, quite easy to automate. > So, group one wants nothing between them and the developer's uploads, > group two wants a human testing team to have reviewed and approved > each package that is on their CD, and group three doesn't want to wait > for a human testing team, but wants to distance themselves a touch > from the bleeding edge. so: group 1 - usually upgrades via ftp or from a nfs-mounted local mirror. probably a debian developer. group 2 - upgrades from a CD release which has been through the unstable -> frozen -> stable testing cycle. group 3 - upgrades from monthly snapshot CD, and occasional via ftp for some urgent fix. this is just a 'me too' post in disguise. what you wrote says it all, really. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf
On Tue, 2 Jun 1998, Jules Bean wrote:
> >> So support the full grammar of the file.
> >
> > debian currently has 1956 packages. most of them require a config file.
> > do you think having that many individual parsers is viable?
>
> Ooh.. debian has 1956 packages. Do you think having that many postrm
> scripts is viable?
postinst scripts are rarely anywhere near as complicated as a config
file parser.
the majority of packages don't even have any {pre,post}{rm,inst}
scripts, and most of those that do don't do anything particularly
complicated.
> Of course it's viable. It just becomes a package maintainer
> responsibility. In the vast majority of cases, the package maintainer
> ought to be able to use the *same code* as the package itself for
> parsing config files.
>
> In many well factored cases, this will be as simple as extracting
> config.c or some similarly named file from the distribution and making
> a few changes to it.
no, it's not that simple.
it needs to read and parse the config file, allow the user to manipulate
it, and then write it back out again (if the user chooses to save any
changes) WITHOUT losing any information, including comments and the
order of the comments.
craig
--
craig sanders
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf
On Tue, 2 Jun 1998, Jules Bean wrote: > > The solution of course is to extend the m4 stuff to support all the > > things linuxconf does, but that's not so easy. Also, note that > > slackware didn't at last look have m4 sendmailconfig. Another > > example of where slackware is doing more harm than good these days > > by not adopting things the rest of the world has... =p > > This sounds foolish to me. > > The solution is to switch to a better designed mailer (exim springs to > mind) with easier to manage configuration. yes, that's a perfect solution.for those who choose to use exim. it does absolutely nothing at all for those who prefer to use sendmail. BTW, the fact that you don't understand sendmail doesn't prevent others from doing so. sendmail really isn't that difficult, and is simpler in some ways because you don't have multiple config files scattered across multiple directories. sendmail.mc and the sendmailconfig script are mind-bogglingly simple to use, and will get a working configuration for 99% of cases in a minute or two. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf
On Tue, 2 Jun 1998, Rev. Joseph Carter wrote: > > RE: sendmail.cf > > > > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. > > That would be more reasonable, however not all that sendmail can do is > supported with the m4 rules and such. Not at the moment at least. anything you can do in sendmail.cf can also be done in sendmail.mc. you can put any sendmail rulesets you like in the m4 file. sendmail.mc is actually a very good example of a template-style configuration tool. it greatly increases the ease-of-use, WITHOUT losing *any* of the flexibility and power of the previous "arcane" way of configuring sendmail. > Sendmail is their selling point because of how complex it is, how > little m4 helps and how much they can do with it. The motivation for > the project is that sendmail if easy to configure could sell linux and > the opensource paradigm to a few people. This is good. but sendmail is already trivial to configure using the m4 macros, for nearly all common setups. the only time you need to hack sendmail rulesets manually is when you're doing something truly weird / non-standard with sendmail. The m4 macros cover just about any configuration requirement you could think of. > The solution of course is to extend the m4 stuff to support all the > things linuxconf does, but that's not so easy. no, the solution would be to make linuxconf a front-end for the m4 stuff rather than mess with sendmail.cf directly. whoever wrote the sendmail module for linuxconf should take a good look at debian's sendmailconfig script and see what can be done using just a shell script. it asks a dozen or so simple questions and uses the answers (with sensible defaults) to build a sendmail.mc file, which is then piped into m4 to produce sendmail.cf. > Also, note that slackware didn't at last look have m4 sendmailconfig. > Another example of where slackware is doing more harm than good these > days by not adopting things the rest of the world has... =p IMO, slackware doesn't matter....it's a zombie OS (dead as a dodo, but just doesn't realise it yet). craig -- craig sanders
Re: Linuxconf not losing info.
On Tue, 2 Jun 1998, Shaya Potter wrote: > Sorry for not responding directly, I only get debian-devel-digest, so I can > only respond to what I catch. > > I believe linuxconf will version every change that it makes, i.e. if you > make changes w/ linuxconf and see that it didn't work, you can go back to > your previous configuration or any one of many previous configurations, this > will probably work if you edited it outside of linuxconf, you then edited > the file manually, and then went into linuxconf, somehow or another > linuxconf messed up the file (though when I was playing with it last year, > it couldn't grok our dns setup, and just complained, didn't mess with it), > you should theoreticly be able to go back to the version you modified by > hand, because linuxconf should have saved it before modifying the file. good. i like the sound of that. does it use RCS or similar to store the previous versions? if not, how hard would it be to make it do so? craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: another look at release-critical bugs: lpr
On Sat, 30 May 1998, Jay Wardle wrote: > [...Raul wrote...] > > If this can't be fixed easily, perhaps we ought to promote lprng to > > standard and demote lpr to optional. Yes, I know that bug-for-bug > > compatability is a nice thing, but in my experience lprng is superior to > > lpr. > > > > -- > > Raul > > In my (admittedly limited) experience, lpr is superior to lprng. Both > a friend and I could not get lprng setup on our systems. It requires > a lot of configuration work. We had both spent a significant amount of > time with lprng, and lpr was a snap. we have the exact opposite experience then. i found lprng to be a breeze - the package basically configures itself, especially if you also install magicfilter. I don't use lpr on any system any more. if i find anyone on my network has installed lpr (i have several debian users at work now...converting them was easy, once they realised it was convert or perishmwahahahaha!) then i remove it and replace it with lpr. > lpr is clearly the best choice for most of the small system users. i disagree. i find that the integration between lprng and magicfilter makes it the best choice for anyone who just wants something that works "out of the box" lprng, magicfilter, gs (or gs-aladdin), and enscript : THE printing suite for linux systems. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf
On Tue, 2 Jun 1998, Joel Klecker wrote: > At 07:40 -0700 1998-06-02, Craig Sanders wrote: > > BTW, the fact that you don't understand sendmail doesn't prevent > > others from doing so. sendmail really isn't that difficult, and is > > simpler in some ways because you don't have multiple config files > > scattered across multiple directories. > > FUD, exim also uses only one configuration file. > > I'm sure I could understand sendmail if necessary, but I have the > luxury of not needing to, and since I don't want to, I don't have to. i may be confusing exim's config with smail. when i (very briefly) looked at it last year, it seemed to be "smail done right". i don't like smail (even when it is done right) so gave up on it after a few days. i also looked at zmailer. now that definitely has zillions of config files scattered over zillions of directories. ok, "zillions" is a slight exaggeration, but not by much :-). looked to have some nice ideas, but not my cup of tea. qmail was the only "alternative" mailer i looked at that i actually liked. It's the only one i would even consider as a replacement for sendmail. I'd be running it now except for two things: 1. the license, 2. the Qmail Attitude Problem (QAP). Actually, there are two QAPs. The first is the unbearable and unjustifiable defensive arrogance on the part of the author and certain over-zealous users. The second is the attitude that "your legacy systems are a crock of shit, throw it all out and do it the Qmail Way"e.g. getting majordomo to work with it is a major pain in the arse - and the fact that ezmlm exists is irrelevant if i've got 83 users with 83 different majordomo lists which they have been running for years. Right now, all but one of my systems is running sendmail. I have one box running qmail (being used as an outbound relay...my main sendmail box at works relays all non-local mail via the qmail box to take advantage of qmail's faster queueing and delivery). i'm waiting for vmail to come out of vapourwarethen i'll check that out too. it *sounds* good. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf not losing info.
On Wed, 3 Jun 1998, Shaya Potter wrote: > > does it use RCS or similar to store the previous versions? if not, > > how hard would it be to make it do so? > > don't know, as it's been a year since I've played with it on debian. > However, that was one of the big things I requested, and from reading > the linuxconf web pages, it seems he has added it, though I'm not > sure how it does it. Why RCS? if it uses it's own system of just > versioning the files, wouldn't that be good enough as well? if it works, then yeah it's fine. however, why re-invent a perfectly good wheel which happens to have lots of compatible utilities? e.g. various diff utils like rcsdiff and tkdiff. i prefer incremental, evolutionary growth built upon existing tools. sometimes (rarely) you have to throw out the old stuff and start afresh, but usually not. it's unfortunately very common for wheels to be re-invented simply because people don't know that they already exist or how to use them, or it never occurs to them that a tool which is well-known for one particular use (e.g. make) is also very useful for another (e.g. building and managing config files instead of compiling programs) craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release management
On Tue, 25 Jun 1996, Scott Barker wrote: > Ian Jackson said: > > We *must* provide a tree which contains only the most rcently > > bug-fixed versions of everything, and we *must not* require people to > > download broken packages only to have to download good ones too. > > ok. This is important, and I hadn't thought of it. But: yeah. i can see both sides of this issue, and am still undecided as to what i think is best. i tend towards agreeing with ian, mostly because the debian version number is IMHO completely irrelevant - our version differentiation is much more granular than that...it's the package versions which matter, not the total distribution version. however, i don't think it would be a good idea to change the way things are currently done without a lot of promotion of the the ideas behind dpkg. I talk to a lot of people about debian, and most are very happy with the improvement over their old slackware or redhat system...BUT...they haven't yet figured out what dpkg allows them to do. Debian is not just a different distribution, it's a different *type* of distribution. All other dists that i know of (with the single exception of redhat) are monolithic beasts, with little or no control over the individual software components. The packaging system (and all the thought that went into it) is debian's number 1 feature - it's even more important than the fact that debian as a whole is well designed and all the parts are generally much better integrated with each other than on other distributions. As far as I am concerned, Debian is dpkg/dselect + base. All other packages are optional plug-in modules to add various types of functionality to the base system... this is not meant to put down the efforts of all the package developers (including myself)...it's just an explanation of what i think is a good way to look at what debian is. > > There is no reason why we need to freeze the stuff in buzz, apart from > > the `1.1 must mean 1.1' idea, which has no practical benefit. > > It does for CD manufacturers and Consultants like myself: > > Client: "I have a problem with my system." > Me: "Which version of Debian do you have?" > Client: "Debian 1.1" > Me: "Yeah, but which version of Debian 1.1?" > > What a headache. It would be better for them to be able to say: > > Client: "I've got Debian 1.1, and I've upgraded the following packages..." Client: I've got Debian 1.1, and I've upgraded the following packages... You:"debian 1.1" doesn't really tell me much. Can you type: dpkg -l | mail -s "versions" [EMAIL PROTECTED] Client: OK. done. You:aha. i see you have foo-1.2-3. Your problem was fixed in a later version. You need to upgrade to 1.2-5. I've attached a copy to this message, save it to a file and run 'dpkg -i' on it to upgrade. You've also got old versions of the following packages , which really should be upgraded. You can get them from . If you're doing this sort of thing on several machines it shouldn't be too hard to write a script to be run daily from cron which mails 'dpkg -l' to a custom database program on your machine...then you will always have an up-to-date summary of what is installed on all of your clients' debian machines. Craig
Re: perlconfig creates unnecessary/unusable files.
On Wed, 24 Jul 1996, Yves Arrouye wrote: > Package: perl > Version: 5.003-2 > > perlconfig (aka h2ph) really wants to make .ph files with Objective C > headers found under /usr/include... and fails! > > Yves. > it also runs h2ph in the foreground, when there's no good reason why it shouldn't run in the background and let dselect get on with the rest of the install process. Craig
Re: New Apache package (Was: Re: Q about making a package with a dedicated user?)
On Thu, 25 Jul 1996, Miquel van Smoorenburg wrote: Yves Arrouye <[EMAIL PROTECTED]> > You (Yves Arrouye) wrote: > > To anyone that read this message: your suggestions for features you > > want in the Apache package are welcome. > > Perhaps you could put in the SSL patches and make the apache-SLL package > available on a site outside of the US? excellent idea The one tiny problem with it, if i recall correctly, is that French laws regarding encryption are even worse than the US laws. They're not even allowed to possess encryption devices/software! (i may be wrong on this pointbut i do vaguely recall reading about it some time ago) Craig
Re: IP-aliasing
On Fri, 26 Jul 1996, Behan Webster wrote: > I've also written the following simple script for one of the machines > I manage that is used as a multi-homed web site (it has about 6 ip > addresses right now.) Just give it a list of ip addresses on the > command line. It's to be used once at boot time. > > >#!/usr/bin/perl > > [...script deleted...] > I hope this is helpful. it's certainly a great idea. Thanks, I can use something like that in my wetware collection of useful tricks! what i will never understand, though, is why people use perl for jobs that sh is much better suited to. perl is great if you want awk/sed/grep/kitchen sink all rolled into one scripting language. but there's a price - perl's slower and bigger and takes longer to load. here's the same thing in sh ---cut here--- #! /bin/sh device=eth0 # aliased device netmask=255.255.255.0 # your netmask interface=0 for i in $@ ; do broadcast=`echo $i | sed -e 's/[^.]$/255/'` ifconfig $device:$interface $i netmask $netmask broadcast $broadcast route add -host $i dev $device:$interface interface=$[interface + 1] done ---cut here--- (NB: this script should work BUT is untested) actually, i can see problems in this (and in your perl implementation). The netmask & broadcast address could be wrong in some (not uncommon) circumstances...it should be possible, however, to make the script generic by calculating the correct values for netmask and broadcast from an arg like '203.16.167.50/24'. it might also be worthwhile calculating the correct network address and doing 'route add -net $netaddr $device:$interface'...would help when the machine has ip alias addresses in multiple networks or subnets. (of course, this extra stuff probably make it worth the overhead of implementing it in perl :-) Craig
Re: Bug#3795: ae should not be essential
On Thu, 1 Aug 1996, Guy Maor wrote:
> > Christian Hudon writes ("Re: Bug#3795: ae should not be essential"):
> > > Isn't it that some of the packages that look at EDITOR fall back
> > > to ae if there are problems with EDITOR?
>
> vipw and vigr do this. They're in passwd which is essential, but won't
> be as soon as I upload a new version.
Actually, they default to ae unless you override it with "export
EDITOR=/usr/bin/vi". I wouldn't mind so much if they just had a fallback
to ae if vi wasn't available but running ae by default from a command
named after vi just doesn't make any sense.
it's really disconcerting when you type 'vipw' or 'vigr' on a freshly
installed system (where you've spent 20 mins in dselect selecting
packages, including unselecting nvi & elvis and selecting vim), start
typing vi commands into the type-ahead buffer before it's finished
loading, and then find that the first line of /etc/passwd or /etc/group
is mangled with or whatever.
I know this has been discussed before, but vipw does NOT mean ae.
maybe the best solution would be to have aepw & aegr as symlinks to vipw
& vigr. When, for example, vipw is executed, it checks for existence of
/usr/bin/vi. if vi doesn't exist, it either prints a message saying "vi
is not installed. try aepw" or just uses ae, or prints a warning message
before running ae.
Craig
Re: Bug#3990: xdm-errors location not what FSSTND says
On Thu, 1 Aug 1996, Michael Gaertner wrote: > Package: xbase > Version: 3.1.2-9 > > FSSTND R1.2 writes in chap. 5.3.5 to place xdm-errors in > /var/lib/xdm/. This is not the location xdm-errors get logged by default > in above package. > > Suggestion: change /etc/X11/xdm/xdm-config in line > "DisplayManager.errorLogFile:" to > > "DisplayManager.errorLogFile: /var/lib/xdm/xdm-errors" What's so special about xdm that it's error log files should go in /var/lib? Isn't /var/log (or subdirectories of /var/log) the right place for all log files? Craig
Re: IP-aliasing
On 3 Aug 1996, Rob Browning wrote: > Craig Sanders <[EMAIL PROTECTED]> writes: > > > what i will never understand, though, is why people use perl for > > jobs that sh is much better suited to. > > > > perl is great if you want awk/sed/grep/kitchen sink all rolled into > > one scripting language. but there's a price - perl's slower and > > bigger and takes longer to load. > > What I will never understand is why people assume that perl is so much > slower. For most things it's much faster since it doesn't have to > launch a separate program for most operations. sorry, my language was unclear - i implied that perl ran slower when all i really meant was that it takes longer to load and is overkill for many small tasks. perl RUNS faster, that's a fact. perl LOADS slower, that's also a fact. perl also requires much more memory, which on a 4mb or 8mb system will slow things down even further due to extra swapping. therefore tiny scripts are better done in sh, which is a) smaller and therefore loads faster, and b) almost always in memory/cache anyway. Of course, as you say, if you need to fork sed (or whatever) many times then perl is clearly a winner. my basic rule of thumb is: if the script is mostly a program launcher then use sh. otherwise use awk or perl or whatever language best suits the application. one big advantage to sh for me is that if i find that i am entering similar or repetitive commands at the prompt, i can easily cut and paste the command line into a text file. Add "#! /bin/sh", some extra line breaks to make it more readable, some comments to explain what it does and what arguments it takes, and i have a new script. I'd like to see a bourne-like shell with perl-like regexp stuff (mainly sed & grep) built in - i'd switch to that in a flash. As a built-in it would be extremely fast, and i'd still be able to test/debug/prototype my scripts interactively on the command line :-) Craig
Bug#4016: ref not in elvisctags
Package: elvisctags Version: 2.0-4 /usr/bin/ref is in elviscmn, rather than in elvisctags. Craig
epoch?? how to make squid-1.0.5 > squid-1.0beta16
I compiled squid 1.0.5 last night and made a new package for it, but when i installed it with dpkg on my system i got a warning message about "downgrading to earlier version due to --force". which means that dselect can't be used to upgrade this package because it won't do the forced "downgrade". I don't want to upload the new package until this is fixed. I seem to recall some discussion a few months back about an "Epoch" header or something like that which could be used to get around this problem. Was epoch implemented? How do I use it? (note for those waiting on a new version of squid: i probably wont get time to finish this off now until the end of the week.) Craig
/etc/sysconfig or /etc/hostconfig (was Re: /etc/default)
it seems to me that there are two types of "default" file being
discussed here.
The first is default options for executables - i.e. /etc/default. Most
discussion so far has concentrated on this. This will require massive
changes to the system so that binaries know how to use the default
information (e.g. tar has to be patched to use /etc/default/tar) unless
we have a way of converting these /etc/default/* files into the
relevant environment variables.
The second is boot time configuration information - information that
the system needs to boot up correctly...network address, what programs
to run, etc. This is probably a lot easier and simpler to implement as
we don't need to make any radical changes to the binaries to get the
benefits.
Some of the machines I use at work are FreeBSD, some are NextStep (my
personal workstation is Debian, of course...and is the most stable of
the lot. By example of my machine only i have convinced the boss that
debian linux is a damned good system :).
One thing I really like about BSD & NextStep is their /etc/sysconfig
(BSD) and /etc/hostconfig (NS) files. (I know debian is sysV and not BSD
but a good idea is a good idea :) I tend to prefer the hostconfig file
because it's just a list of simple variables, each containing one value
only.
These contain simple directives like:
BSD:
---cut here---extract of sample /etc/sysconfig---
hostname="host.domain.blah"
defaultdomainname=NO
tcp_extensions=YES
ipfirewall=YES
network_interfaces="ed0 lo0"
ifconfig_ed0="inet xxx.xxx.xxx.xxx netmask 255.255.255.0"
ifconfig_lo0="inet localhost"
route_loopback="${hostname} localhost"
defaultrouter=203.2.135.53
routedflags=NO
timedflags=NO
xntpdflags="NO"
tickadjflags="-Aq"
---cut here---sample /etc/sysconfig---
NextStep:
---cut here---sample /etc/hostconfig---
HOSTNAME=hostname
INETADDR=xxx.xxx.xxx.xxx
ROUTER=-ROUTED-
IPNETMASK=
IPBROADCAST=-AUTOMATIC-
NETMASTER=-YES-
YPDOMAIN=-NO-
TIME=-AUTOMATIC-
---cut here---sample /etc/hostconfig---
The nice thing about these types of files is that they're easily parsed in
sh. In fact, they can even be sourced in an /etc/init.d/* script to provide
environment variables (although that might have undesirable side-effects).
If we use something like this, we would need:
- an easy way for debian.{pre,post}{inst,rm} scripts to add, delete,
and extract individual entries. sed would do the trick for sh,
and perl should have no problems at all with this format.
When a usenet news related package is installed, it should
examine this file to see if NEWS_SERVER is defined. If it is, it
uses it.
If not, it should query the user and add a line like
"NEWS_SERVER=hostname.domain". We should provide a standard
script, which the postinst script calls to do this.
- a defined standard for how /etc/init.d scripts should use this
information. e.g. source the file or:
sed -n -e '/^NEWS_SERVER=/s/\([^=]*\)=\(.*\)/\2/p'
here's two simple examples of how this could be used:
---/etc/init.d/network---
#! /bin/sh
function extract_var() {
sed -n -e "/^$1=/s/\([^=]*\)=\(.*\)/\2/p" /etc/hostconfig
}
IPADDR=`extract_var IPADDR`
NETMASK=`extract_var NETMASK`
NETWORK=`extract_var NETWORK`
BROADCAST=`extract_var BROADCAST`
GATEWAY=`extract_var GATEWAY`
/sbin/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
/sbin/route add -net ${NETWORK} eth0
/sbin/route add -net ${NETWORK} netmask ${NETMASK} >/dev/null 2>&1
/sbin/route add default gw ${GATEWAY} metric 1
---/etc/init.d/network---
or
---/etc/init.d/netstd_init---
#!/bin/sh
#
# Start networking daemons.
function extract_var() {
sed -n -e "/^$1=/s/\([^=]*\)=\(.*\)/\2/p" /etc/hostconfig
}
NET="/usr/sbin"
ROUTER=`extract_var ROUTER`
case "$1" in
start)
if [ $ROUTER = ROUTED ] ; then
echo "Starting routed" ; start-stop-daemon --start --quiet --exec
${NET}/routed -- -q
;;
fi
if [ $ROUTER = GATED ] ; then
echo "Starting gated" ; start-stop-daemon --start --quiet --exec
${NET}/gated
;;
fi
stop)
start-stop-daemon --stop --quiet --oknodo --exec /usr/sbin/routed
start-stop-daemon --stop --quiet --oknodo --exec /usr/sbin/gated
;;
*)
echo "Usage: /etc/init.d/netstd_init {start|stop}"
exit 1
esac
exit 0
---/etc/init.d/netstd_init---
food for thought, anyway...
Craig
shells (was Re: IP-aliasing)
On Tue, 6 Aug 1996, Emilio Lopes wrote:
> >>>>> "CS" == Craig Sanders <[EMAIL PROTECTED]> wrote:
>
> CS> I'd like to see a bourne-like shell with perl-like regexp stuff
> CS> (mainly sed & grep) built in - i'd switch to that in a flash.
>
> People may say it's called ksh93. IMHO, it may seem somewhat
> interesting, but I really don't like it. Look likes tcl... :-)
zsh seems to have some of these features.
see http://www.mal.com/zsh/ for full details, but this looks useful:
and a substitution modifier:
% echo $name:s/foo/bar/
bar.c
% ls
foo.cfoo.hfoo.ofoo.pro
% for i in foo.*; mv $i $i:s/foo/bar/
% ls
bar.cbar.hbar.obar.pro
it's only simple substitution, though. no regexp.
(siva-cas) ~$ zsh
% fred=xyz.abc.zzz
% echo $fred
xyz.abc.zzz
lets try a regexp subsitution ala sed:
% echo $fred:s/\(...\).\(...\).\(...\)/\3\2\1/
xyz.abc.zzz
ok. that obviously doesn't work. lets try a different format:
% echo $fred:s/(...).(...).(...)/\3\2\1/
xyz.abc.zzz
nope.
you can string together multiple substitions, though:
% echo $fred:s/abc/111/
xyz.111.zzz
% echo $fred:s/abc/111/:s/xyz/222/
222.111.zzz
% echo $fred:s/abc/111/:s/xyz/222/:s/zzz/333/
222.111.333
zsh looks like it's got nice stuff out of sh/bash, ksh, and csh.
looks useful, but it doesn't get eliminate the need to fork sed and
grep.
hmmm...the substitution facility could be useful for standardising
responses in a case statement:
read yesno
case $yesno:l:s/yes/y/:s/no/n/ in
y) do_yes ;;
n) do_no ;;
*) do_error ;;
esac
it's probably too non-standard to use for debian.{pre,post}{rm,inst} scripts
but i might switch to it for my personal use.
Re: Bug#4133: Samba goes into busy loop?
On Wed, 14 Aug 1996, Andrew Howell wrote: > Support writes: > > Package: samba > > Version: 1.9.16alpha10-1 > > > > When left unattended, the smbd daemon (or several instances of > > such) seems to go into some sort of busy look that eats up all of > > the processor time of the computer. This seems to occur when no > > computers are actually accessing shares exported by samba (i.e. when > > the Win95 machines are turned off for the night), but may also occur > > at other times (i.e. the only share requested by a just turned on > > machine doesn't exist). > > Yes I've noticed this myself, I'm looking into it. I've noticed it on my machines too, but don't use it enough yet to have tracked down the exact circumstances which cause it. it seems to mostly happen when my (newly built from my "junk" parts pile) WfWG3.11 machine accesses directories which don't exist. I've also caused it to happen by running the telephone/chat program (whatever it's called) which came with WfWG and trying to 'phone' my linux machines. my 'fix' is to kill the runaway smbd processes, and also make sure that nmbd is killed on all my linux machines. I don't know why, but it seems as if unless nmbd is killed then the smbd processes will just be respawned about 5 minutes later and start eating up the CPU again. smbd reacting badly to a query from nmbd, perhaps?? Craig
Re: /etc/sysconfig or /etc/hostconfig (was Re: /etc/default)
sorry to take so long to reply to this...i've been too busy at work to even check my mailing lists. On 8 Aug 1996, Kai Henningsen wrote: > > discussion so far has concentrated on this. This will require > > massive changes to the system so that binaries know how to use the > > default > > I'd really prefer if people don't put up straw men to attack a > proposal. 1. i wasn't attacking ANY proposal. I happen to think that /etc/default is a great idea. 2. As mentioned in my message, i was concentrating on a side of the issue which seemed to be being ignored: boot time configuration rather than run-time defaults. > Nowhere at all has the /etc/default proposal asked for massive changes > to the system. > > Nowhere at all has someone asked that tar be changed to support > /etc/default/tar. tar was just one example. how is tar going to get its default options from /etc/default/tar if it isn't hacked to read that file? making changes to many programs to enable them to read /etc/default/* files seems to me to qualify as 'massive changes to the system'. > > - a defined standard for how /etc/init.d scripts should use this > > information. e.g. source the file or: > > > > sed -n -e '/^NEWS_SERVER=/s/\([^=]*\)=\(.*\)/\2/p' > > Why not simply source it? sourcing it is good. however, people seem to be shifting towards using perl rather than sh...sourcing a sh script in perl isn't going to be terribly useful. a file containing "token=value" lines, can be sourced by sh or the values can be easily extracted in just about any language. > Oh, I forgot - you lumped all of /etc/default together in one file. > > Unnecessary complication. Besides, it makes for name clashes. To tell the truth, it doesn't bother me too much whether there is one file containing all configuration information or multiple files...if debian ends up with multiple files in /etc/default, i'll just create a Makefile & set of m4 rules to generate them all from a single file. This will allow me to create my own config_info package which contains the configuration defaults for all packages I'm interested in. Then, when I build a new debian machine I can install my config_info package just after installing base, but before installing the rest of the system Craig
Re: New gawk and mawk packages uploaded, finally
On Thu, 8 Aug 1996, Chris Fearnley wrote: > Previously, I have tested mawk on the base disks and had no trouble. > But I recommend that others try this --- just to make sure. Any > suggestions on what we should do with the extra 300K on the base > disks? 888 888 888888 888 888 888 888 888 888 888 888 888 888 888 888 888 888 Y88b d88P 888 888 888 888 Y88b d88P888 888 888 888 Y88o88P 888 Y8P Y8P Y8P Y888P 888 " " " Y8P 888888 888 888 Craig
Bug#2964: lynx -dump fails through proxy.
On Sat, 28 Sep 1996, Christian Hudon wrote: > I'm the new maintainer for lynx... having just lynx 2.6, I'm currently > cleaning out its bug reports. Since I'm not using a proxy server, I > can't know it the new version fixes your problem with lynx -dump. > So you you please try out whatever you did with the new version of > lynx... and tell me if it fixes your problem or not. i tested it (i.e. 'lynx -dump' while using a proxy server) yesterday and it appears to work perfectly now. Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: virtual packages
On Sun, 25 May 1997, Christian Schwarz wrote: > I fully agree to what Manoj said. Since the dotfile generator will > probably get widely used by other packages we should put this package on > our list of "public virtual packages". > > Since I maintain this list, I suggest the following addition to section > "Miscellaneous": > > dotfile-module Anything that provides a module for the dotfile >generator > > Does someone have objections? No objections, just a query: what will this actually achieve? Will dselect automatically select new packages providing dotfile-module when they appear? As far as I know, it won't - at least not if dotfile only Suggests dotfile-module.and even if it does do it for Recommends, the behaviour of Recommends is obnoxious enough that it should NOT be used in this situation. the individual dotfile-modules should Depend upon dotfile but except for the initial install of dotfile, i can't see much benefit at all in having dotfile Suggest dotfile-module. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: anarchism_7.7-1.deb
On Fri, Sep 24, 1999 at 05:59:07PM -0400, Jaldhar H. Vyas wrote: > The criterion should be utility. wrong. we've had this censorship discussion many times before. the only criteria for inclusion in debian is: - is it free? - could someone be bothered doing the work of packaging it? if the answer to both questions is yes, then there is no justification for refusing the package. > The Bible as a literary and cultural foundation of Western > civilization will be useful to a lot more people than the Anarchism > package. 'utility' is a subjective thing. i personally would find the anarchist faq far more useful and interesting than (a bad translation of) religious texts. craig -- craig sanders
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Sat, Sep 25, 1999 at 02:51:36AM -0500, David Starner wrote: > On Sat, Sep 25, 1999 at 07:28:57AM +, Lars Wirzenius wrote: > > David Starner <[EMAIL PROTECTED]>: > > > Instead of each developer chose what packages are and aren't useful > > > to them, why don't we look at the popularity contest? A simple, bias-free > > > way of seperating programs on to the CD's, by actual use. That is what > > > it was made for. > > > > http://www.debian.org/~apenwarr/popcon/ says > > > > *** THIS IS EXPERIMENTAL!! *** Try not to get upset if the > > results are incorrect, but be sure to e-mail me if you think > > there's something funny going on. > > > > I wouldn't base decisions on it yet. i wouldn't base any decisions on it ever. that's not it's purpose. > > Is there any reason to think it's not correct? more to the point, is there any reason to think that it matters whether it is correct or not? the popularity contest is for informational (entertainment) purposes only, not for decision making. the usefulness of a package has nothing at all to do with it's popularity - it may be "unpopular" because it is an obscure and specialised tool but to those who know and need it, it is essential. the survey was never intended to be a means of deciding whether packages are useful or not. nor was it intended for deciding whether to include a package in debian or not. at most, it is a tool for *helping* to order packages on a CD (and even that is of limited use because it mostly shows the popularity of old packages in the last release but not new ones in the current unstable). craig -- craig sanders
Re: anarchism_7.7-1.deb
On Sat, Sep 25, 1999 at 09:10:19PM -0400, Jaldhar H. Vyas wrote: > > - is it free? > > - could someone be bothered doing the work of packaging it? > > > > if the answer to both questions is yes, then there is no > > justification for refusing the package. > > Yes but the maintainer should also ask > > - Does it enhance Debian? if it is useful or interesting to even one person then it enhances debian. in other words, this is not a useful question to ask - if it wasn't of value to at least one person then they would not have bothered to package it. many of the packages in debian are in debian because the maintainer felt that they were useful to them personallyif others benefit from it too, that is good but it is sufficient that the maintainer has, by their work, made debian that much more useful to themself. i, and i guess many other developers, originally joined debian so that some useful tool or program would become part of debian. this is one of the strengths of debian...all of us are here because we want to make debian better or more useful, and one of the prime motivators is to make it more useful to ourselves. our policy and technical standards are a framework which allows us all to do that without conflicting too much with each other. > Not because he has to but because he should want to. And other > developers and users should feel free to comment. yes, others are free to comment but there is no justification other than non-freeness for excluding a package from debian. > The reason is that we are not just shoveling packages on a CD but at > least trying to put together a finished product. and it is the maintainers job to create their package according to policy so that it becomes a smoothly integrated part of the whole that is debian. > > 'utility' is a subjective thing. i personally would find the > > anarchist faq far more useful and interesting than (a bad > > translation of) religious texts. > > I understand. But would the entire Debian constituency? (Which is > what? Just the developers? Developers + users? All Linux users...) > If we are interested we could find out. it's irrelevant whether other debian developers or users agree with me or disagree with me about the relative utility of these two packages. by not censoring packages, by refusing to censor packages, we create a distribution which is good and useful for everyone - not just those whose needs are the same as the censors. some find the bible package useful and i don't begrudge them that - if it makes debian more useful to them then it is a good thing that it is included. we should not be censoring, we should not be saying "the bible is good but the koran or bhagavid gita or even the anarchist faq is worthless". or vice-versa. if something is free and someone does the work to package it then we accept it in the distribution. > This has been a bit of a rant. Let me try and add something > constructive. It looks like we are going to 3 CDs. In the future > we will only get bigger. How do we manage that growth while not > irritating users (swapping CDs sucks) or censoring maintainers? most suggestions have been variations of the following idea: to put all doc and data packages (especially those not directly associated with a program) on a CD by themselves. that seems like a good idea to me. > One approach which has been suggested is to make extra cds by section. > So a data CD could include the bible, anarchy FAQ etc. Perhaps at some > point there will be a ham radio cd, electronics cd etc. This has the > advantage of being infinitely extensible but I worry that it narrows > the scope of Debian for the general user as most CD vendors especially > the cheap ones will probably not bother with the extra CDs. actually, it would increase the scope of debian as a general purpose distribution - there would be something in it for everyone. if we get to the point of having specialty CDs then those who want them will be able to purchase them from specialty vendors or download the packages for free from the net. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 01:10:51AM -0400, Raul Miller wrote: > Perhaps there are people who want a "service enabled by default" policy, > and perhaps we should accomodate them. However, I'm not one of them > and I don't want any services turned on on some of my machines without > my explicit ok. then don't install those services. installing a package *IS* an explicit OK. you've been using debian long enough to know that this is the way it worksand IMO, it is the way it should work. i don't want to have to fuck around with explicitly turning services on when i install them - if i didn't want them to run then i wouldn't have installed them. what you are proposing is more work, more hassle, more stupid questions to answer for every install. if you want something different from the default then you can implement in whatever way seems best to you for your systems - but don't force it on everyone else. craig -- craig sanders
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Mon, Sep 27, 1999 at 11:46:19AM +0200, Siggy Brentrup wrote: > Craig Sanders <[EMAIL PROTECTED]> writes: > > it's irrelevant whether other debian developers or users agree with me > > or disagree with me about the relative utility of these two packages. > > by not censoring packages, by refusing to censor packages, we create > > a distribution which is good and useful for everyone - not just those > > whose needs are the same as the censors. some find the bible package > > useful and i don't begrudge them that - if it makes debian more useful > > to them then it is a good thing that it is included. > > > > we should not be censoring, we should not be saying "the bible is good > > but the koran or bhagavid gita or even the anarchist faq is worthless". > > or vice-versa. > > Is it really censoring to keep all non-technical packages out of main? > I don't say don't package it nor don't make it available. that's a different question entirely, and not one that i'm addressing. my point is that if we accept one into main then we have no justification for not accepting all. if we decide that non-technical documents (i.e. anything which is not documentation or tutorial material for a program - literature, mythology, philosophy, etc) do not belong in main then that applies to all such packages. if it's free and it's packaged then we accept it into the dist in the location defined by policy - at the moment, that's debian main. we probably should, as has been discussed before, have an etexts and a data section for this kind of stuff. > > if something is free and someone does the work to package it then we > > accept it in the distribution. > > There should be one for the main distribution. Assume I want to go > into the CD business providing support for packages in the main > dist. No major problem with most of the packages, but I am not willing > to support packages with philosophical, political or religious > contents. that's ludicrous. what support is needed for texts? customer: i can't read foo-text. tech support: have you tried opening your eyes sir? craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Mon, Sep 27, 1999 at 03:21:34AM -0400, Raul Miller wrote: > On Mon, Sep 27, 1999 at 01:05:58PM +1000, Craig Sanders wrote: > > then don't install those services. installing a package *IS* an explicit > > OK. > > You're saying that packages reliably say when they provide daemons? no, but it should be pretty obvious from the description. e.g. a pop server package is going to install a pop server. a web server package is going to install a web server. etc. this should be self-evident. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 12:52:16AM -0400, Mark W. Eichin wrote: > > no, but it should be pretty obvious from the description. e.g. a pop > > server package is going to install a pop server. a web server package is > > going to install a web server. etc. this should be self-evident. > > True, but don't forget the case of an initial install - you pick some > profile, and get lots of stuff, with no hints. (In this case, I like > they idea of a debconf global flag of "prompt me about daemon > enablement", which is kind of the *reverse* of what most people want > debconf for...) IMO that's the price you pay for saying "install a whole bunch of random stuff i haven't personally selected". if you cared, you'd take the time to vet all selections yourself. if you don't care, accept whatever the selection set gives you. if you discover later that you actually DO care, then uninstall or disable the relevant package. (generic "you" used in above paragraph, not referring to you personally) > If you doubt that this is an issue, consider ipmasq: it was part of > one of the standard install profiles, I don't even know which one -- > but it badly confused one firewall and at least two laptop installs > that I know of personally, because it automatically enabled certain > safety rules that were wrong in the non-masq multiple-interface case. sounds like a bug in either the ipmasq package or in the selection set. or both. > The ipmasq maintainer has since made the rules for firing that much > more rational, we did work out some reasonable approach which I forget so it's solved. where's the problem? > at the moment - I just want to bring it up as a point of actual > experience with the initial install startup case... ok. i just don't think it's as big a deal as some people do. more to the point, i think that doing the opposite (i.e. not enabling services by default when a package is installed) will cause even more problems (and confusion and hassle) to everyone else. i.e. there's a tiny minority who are inconvenienced by daemons being enabled when a package is installed. there would be a huge majority who would be inconvenienced if the reverse were true. it looks to me like it's an either/or situation (i.e. no way of satisfying both parties at once - mutually exclusive needs) so it's a pretty easy choice to make...cause the minimum harm/hassle/inconvenience. craig -- craig sanders
Re: dhcp-dns problems
On Wed, Sep 29, 1999 at 12:58:08AM -0400, [EMAIL PROTECTED] wrote: > I have a small network @Home and use dhcp to dole out the ip's, I use > the dhcp-dns package so that I can refer to these boxen by name and > so that various network utilities will work. Recently I've started > getting emails to root from Cron saying "update packet failed". have you recently upgraded to the latest bind in potato (8.2.1-1 or later)? if so, then you need to be aware that the config file location changed from /etc/named.conf to /etc/bind/named.conf, and the zonefiles in /var/named now live in /var/cache/bind. make sure you edit /etc/bind/named.conf to include everything that was in /etc/named.conf BTW, your message should have been submitted as a bug report and not posted to debian-devel. debian-devel is for issues related to debian development, not user support. craig (package maintainer for dhcp-dns) -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 01:08:31PM -0400, Laurel Fan wrote: > Excerpts from debian: 29-Sep-99 Re: Packages should not Con.. by Craig > [EMAIL PROTECTED] > > IMO that's the price you pay for saying "install a whole bunch of > > random stuff i haven't personally selected". if you cared, you'd > > take the time to vet all selections yourself. > > In the initial install, is it possible to go in and unselect and > select packages after picking profile/tasks (Or just look at what it > wants to install)? yes. dselect is run immediately after the pre-selection stage. > The install program and the docs say "skip the Select step of > dselect"... Does it mean "skip it because you will confuse the > installer" or "you should skip it because it's already done"? it means "skip it because i don't want pre-selections". that option is to not run the pre-selection script, to jump straight into dselect. it's the option i always choose when building systems because i prefer to select all packages. crai -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 02:27:45PM -0400, Mark W. Eichin wrote: > > > it's an either/or situation (i.e. no way of satisfying both parties > > Actually, it isn't -- there's an easy way of giving users a choice, > and two people have suggested it already (debconf). This seems to be > the most Debianish way to handle it - technologically superior, and > avoids punishing one set of users at the expense of the other (even if > it is a small minority, you don't care about that when you're in it > :-) if that can be done, then fine. i'm against changing the default so that it only suits a tiny minority. i'm not against increasing choice. the default should remain as is, though - those who want it different should be the ones who have to take whatever action with debconf. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 04:30:45AM -0500, Francois Gurin wrote: > Minimun hassle/inconvenience is mutually exclusive of minimum harm. > Looking at the example set forth by some of the other distributions > (and more than a few operating systems), the reduced hassle of > installation and administration is traded for security (which I hope > most people will agree is harmful). this is a load of crap. enabling daemons by default is not a security problem. if a particular daemon is a security problem then it should be fixed or dropped from the distribution. if the default configuration of a daemon is a security problem then that config should be fixed or the package dropped from the distribution. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote: > The fantasy is over--WELCOME TO REAL LIFE! It turns out that some > people install linux without preexisting knowledge of how to securely > administer a unix machine. sorry, it's you who needs to wake up to the real world. if people don't know how to administer a unix machine then they need to learn fast. no amount of molly-coddling by the distribution authors (i.e. us) is going to obviate that essential requirement. maintaining security on your own systems requires personal knowledge and experience, it can not be done by proxy. the "we-know-better-than-you" attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or "would be nice" but absolutly required) > When we ship a system with a bunch of stuff enabled by default, > we're not only putting their machine at risk but we're also creating > problems for everyone else who's system is attacked by someone using > the debian machine as a jump-off point. That's bad. that's bad. it's also bullshit. enabling daemons by default is not inherently a security problem. see previous message. if a particular daemon is a problem then it needs to be fixed or replaced or dropped from the distribution. changing the default so that it is only enabled manually will NOT increase security at all. > It's really time to get away from the mentality that everyone needs to > have everything turned on all of the time; if a persone really *needs* > something enabled, they can figure out how to do it. (If they can't, > should they really be administering a network node?) if they don't need it then they shouldn't install the package. why run debian (with all it's useful tools like update-inetd and update-rc.d and so on) if you're going to throw away those advantages? > This isn't a UI issue, this is a matter of security and of us taking > responsibility for the state of quite a few systems out on the > internet which will be configured according to *our* defaults. it's not a matter of security, it's a matter of personal preference. enabling daemons when they are installed is not a security problem. it's damned annoying to see people trying to force their personal preferences on everyone else by making loud noises about trumped up nebulous and vague "security" issues. it would be nicer if such FUD were left behind in the proprietary software world. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 08:50:00PM -0400, Clint Adams wrote: > > the "we-know-better-than-you" attitude is what redhat and caldera > > (and microsoft, for that matter) does. it sucks. debian has always > > done better than that - our way is to encourage people to learn to > > do it for themself by not trying to hide the fact that knowledge and > > experience is required (not just optional or "would be nice" but > > absolutly required) > > You don't think that "you only can have one daemon for a particular > service and it's going to be turned on by default" is representative > of the "we-know-better-than-you" attitude? no, because debian doesn't fuck up configuration by forcing you to go though some stupid and limited GUI interface (try doing something non-standard with network interface setup on RH and you'll know what i mean - you can't do it...actually, you can if you spend enough time figuring out their setup but you risk that your custom mods will be blown away the next time someone runs the stupid GUI configurator). debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 09:26:39PM -0400, Clint Adams wrote: > > debian's attitude is: if you want something different, DIY. and more > > importantly, it lets you DIY. > > Err.. what Unix DOESN'T let you DIY? read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 11:45:13PM -0500, Francois Gurin wrote: > And why can't there be an option to determine this? You avoided that > point. no i didn't. i answered it in another message. to paraphrase: i am against messing with the current default. i am not against (indeed, i am in favour of) increasing choice. if it is possible to add that choice without screwing anything up and without being a pain in the arse then i am all in favour of it. > > if they don't need it then they shouldn't install the package. > > And if the package has a dependency? > There are many situations dealing with the package system that can > lead to daemons installing without your knowledge. mtools for potato > includes floppyd, if someone upgrades a slink machine to potato, > should floppyd be automatically started? if mtools needs floppyd to run and the user has chosen to install mtools then yes. the user want mtools to work, they don't want mtools to work ONLY if they do some weird and obscure thing (even if it IS documented in the debian changelog, it is still weird and obscure unless they happen to be aware of the fact that this major change has occurred) which they never needed to do in the past... in other words, mtools used to just work, it should continue to just work after an upgrade. > not all packages start daemons automatically. Some ask. Wouldn't it > be keen if Joe Bloe knew what to expect? those that ask, shouldn't. there are already way too many stupid questions in postinst scripts. if (via debconf or whatever) there is a way for users to voluntarily specify that they want daemon packages to ask then that would be fine...but it should take some deliberate action on the user's part before they get these annoying questions. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 10:38:34PM -0400, Clint Adams wrote: > > read the rest of my message. the bit that ranted about unix's that > > get in the way of DIY. RH is one. sun's Netra is another...both are > > examples of how NOT to do configuration management on unix. > > No. You're talking about doing something your way and then having > it wrecked by the RH/whatever way. And if you decide to do something > your way in conflict with the Debian way, Debian may wreck your work > too. debian provides methods of having your cake and eating it too. it provides tools for integrating your custom changes into the debian system so that you don't ever have to worry about the system screwing up your custom stuff. > If I'm running /usr/local/sbin/sillycommercialpop3d, or > /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck, > and I want to install php72-pop3 which Requires pop3-server, this is what the dummy package (or whatever it is called is for). fake up as many Provides: lines as you need. > and I naively apt-get install php72-pop3, not thinking it would > require a local pop server or thinking that my pop server should > be sufficient, if you suffer from this naivety then you need to cure it. expecting software to magically perform some miracle is not going to help you do anything but dig yourself into a much deeper hole. > I'd probably end up with a nice little tagalog pop server that > installs itself in inetd and steals the port. There are two simple > solutions to this. this would be a problem caused by insufficient knowledge/experience on the part of the operator. don't fix the symptom, it'll just come back again...fix the cause instead. > Either you do it the Debian way and package up sillycommercialpop with > a Provides pop3-server yep, this is another good way of doing it. like the dummy package you get to DIY and still retain the benefits of the packaging system. if you don't like that, then there distributions which don't provide such useful system administration tools. try slackware, for example. > When I recommend to people that they use kernel-package instead of > DIY, they are usually a bit shocked. kernel-package is a useful tool which helps to DIY. it doesn't conflict with the notion of DIY at all, it makes it easier...especially if you like to compile your kernels on your fastest machine and then ship them out with scp to wherever they are needed. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 08:34:48AM -0400, Raul Miller wrote:
> On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote:
> > to paraphrase: i am against messing with the current default. i am not
> > against (indeed, i am in favour of) increasing choice.
>
> There is currently no default -- it varies on a per-package basis.
update-inetd and update-rc.d pretty much establish what the current
default is. they are there to be used by the {pre,post}{inst,rm} to
enable and disable services at install/remove time.
craig
--
craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 09:21:09AM -0400, Clint Adams wrote: > > There is currently no default -- it varies on a per-package basis. > > I note that > > ### to run vtund as a server on port 5000, uncomment the following line: > #--server-- 5000 > > isn't uncommented by default. it isn't useful to run the vtund server until it is configured. there is no "standard" configuration which is suitable for shipping as a default - it MUST be customised for each site, each tunnel must be setup individually. given that, there is no point at all in running vtund until the user has configured it to meet their needs. other daemons, e.g. pop and imap, work with little or no configuration - install them and they start working immediately. it is useful to enable them at install time. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 07:02:44AM -0400, Michael Stone wrote: > On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: > > sorry, it's you who needs to wake up to the real world. > > > > if people don't know how to administer a unix machine then they need > > to learn fast. > > Not true. you discredit your argument with silly assertions like this. > Maintaining a unix-like machine for desktop or personal use requires > a different skill set than a machine used as a server. People using > linux as a windows replacement or because they want to see what linux > is *don't need* a bunch of services enabled *by default*. if they "*don't need* a bunch of services enabled *by default*" then they shouldn't install the packages that provide those services. most workstations do not need a pop or imap server, very few need an ftp server. those workstation users who install these packages have to take responsibility for their own actions, and they should be presumed to know what they are doing. > > no amount of molly-coddling by the distribution authors (i.e. us) is > > going to obviate that essential requirement. maintaining security on > > your own systems requires personal knowledge and experience, it can > > not be done by proxy. > > Agreed, for machines that need public services. But I'm talking about > defaults. Can you come up with a reason we *need* a bunch of stuff > enabled by default? if a service isn't needed then don't install the package that provides that service. what is so difficult to understand about that? it's not as if people are forced to install rsh or telnet servers any more. Anthony has done a great job of splitting up netbase so that these packages are now optional extras. > > the "we-know-better-than-you" attitude is what redhat and caldera > > (and microsoft, for that matter) does. it sucks. debian has always > > done better than that > > This is empty "we're better than them propaganda". Debian already > makes choices in what services are installed and enabled by default. > It does not follow that changing the *existing* list of services we > enable by default implies a "we-know-better-than-you" attitude. ok, i see the communication problem now...why we're going round in circles on this point. i think we're talking about completely different things here. i'm not talking about what debian chooses to have installed by default (i.e. base/required packages). i'm talking about the current practice of postinst scripts in various packages enabling the services that they provide (if any). i am not talking at all about which packages are base or required or extra or whatever - i'm talking specifically and ONLY about what the postinst scripts of packages do when they are installed. install a package which provides a daemon and it *should* be enabled in the postinst. if you don't want the service it provides then don't install the package. of course, if debconf or something can provide a mechanism for the system admin to globally choose whether to enable or not enable services when they are installed then that is even better. but until we have such a mechanism, such packages should do what they always done and enable themselves at install time. > A system with daemons disabled will always have a better guarantee of > security than one with daemons enabled. In the not-so-distant past we've > shipped systems with a vulnerable telnetd and a vulnerable ftpd enabled > *by default.* which is one of the reasons why they are now split off from the netbase package - so that people can choose whether they want these services installed or not. splitting netbase was the right solution to that problem...installing stuff but leaving it disabled is a PITA, not a solution to a problem. more to the point, it's a bigger and more annoying problem than the one it is purported to solve. > > why run debian (with all it's useful tools like update-inetd and > > update-rc.d and so on) if you're going to throw away those advantages? > > Why does changing default behavior throw away advantages? What prevents > you from using those tools if you want them? the advantage of these tools is that packages can enable the services they provide when they are installed. they don't provide much (if any) benefit to the casual command-line user - it's easier to edit inetd.conf manually than it is to remember the args for update-inetd. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 03:13:36AM -0500, The Doctor What wrote: > Excuse me. I work for TurboLinux. i don't give a damn who you work for. > We make it an EXPLICIT policy to disable all daemons, well, bully for you. i guess that must make you so proud. if someone doesn't want a service enabled then they should not install the package that provides that service. if they want the service, then install the appropriate package. simple. their choice to install or not install. now what is so fucking difficult to understand about that? > If it really bothers you, then maybe a global switch > that sets whether daemons should just start up or ask first. you must be some kind of genius to figure that out all by yourself. gee, i wish i had of thought of that. i wish several other people in this thread had thought of that. oh. that's right. we did. i guess you aren't such a genius after all. > I would beg to differ. In some environments, having an unconfigured > server running for 30 seconds is too much. And don't tell me to > pulling the net cable. What if it's being installed via the net? DON'T INSTALL THE DAEMON IF YOU DON'T WANT TO RUN IT. WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION? this argument has gone way beyond the point of being tiresome, it is tedious. it is especially tedious when some pompous cretin just spews out trivialities based on some misunderstanding of the thread which is explicable only by you not having read it. no regards, craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 10:20:41AM -0400, Clint Adams wrote: > > it isn't useful to run the vtund server until it is configured. there > > is no "standard" configuration which is suitable for shipping as a > > default - it MUST be customised for each site, each tunnel must be setup > > individually. > > When did "useful" enter this discussion? usefulness or utility has always been in this discussion. you should pay more attention. > pipsecd starts the daemon automatically even though no tunnel has > been set up, and even if userlink-modules hasn't been installed. > > And even though it is of absolutely no use to you, the daemon > starts running when you install the package. And if there's some > sort of exploitable back door in the code, you're vulnerable. > But fine, you think security is a non-issue. if pipsecd turns out to have a security hole then that MUST be fixed regardless of whether it is started at install-time or not. fixing the bug is the solution to the problem. merely not starting it is no solution at all, that's just hiding your head in the sand. > You seem to recognize at least one situation where it is > counterproductive for Debian to make an assumption about the > user's configuration. Why can you not recognize others? i have little interest left in this tedious thread, so i'll say this once and once only. i really hope you can manage to understand it: vtund was my package to create as i saw fit. I personally saw no need to have the vtund running when it wasn't yet configured, so I personally chose not to have it start until the user configured it. The maintainer of pipsecd, according to your report, made a different choice. that is their right. this is not a matter for policy, this is not a matter where a tiny minority of whiners can have artificial hysterics about fantasy security issues and other FUD. my package, my decision. if you feel that the way i manage my package is a problem, then file a bug report - i'll evaluate that bug report and take whatever action (if any) i feel is appropriate. ditto for the pipsecd package, Samuel can make up his own mind about how to look after his package. by the same token, packages containing other daemons belong to their respective maintainers. if there is any conflict between differing packages, then it is up to the relevant maintainers to sort out a solution - e.g. the emacs and xemacs conflict...until the people responsible for those packages put their heads together and figured it out, it was not possible to have both installed at the same time. now, it is no problem at all. what this means is that if there is a great desire to have several pop packages installed at once, then it is up to the maintainers of the pop packages (and other interested parties) to come up with a way that can be achieved without hassle, and without imposing stupid and onerous burdens on the maintainers of unrelated packages. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote: > I took care in my message above to remove anything offensive towards > Craig. Unfortunately Craig didn't do the same. garbage. you went out of your way to be offensive. to quote the opening line of your message: "Excuse me. I work for TurboLinux." the implication here is that you know what you are talking about because you work for a "real" (i.e. commercial) linux distribution. anyone should be able to guess that that particular attitude is not going to go down well in debian-devel. it's akin to saying that proprietary software is better because the programmers get paid to write it (and, by logical extension, that free software authors are just amateur bumblers). i find posturing based on your employer to be particularly annoying - it's a blatant attempt to cash in on borrowed status. it doesn't work that way here, it's not who you work for that's important, it's what you've done. > It is my hope that Craig Sanders reads this and thinks about what he > has done and why. very little of what i write is done without review and consideration of the effect of my words. i am a very deliberate writer. i presume that others are just as deliberate. if they're not, then they need to learn more caution and control over the language they use. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 11:38:47PM -0400, Steve Willer wrote: > When someone writes things like: > > > well, bully for you. i guess that must make you so proud. > > and > > > now what is so fucking difficult to understand about that? > > the word "deliberate" isn't the first that occurs to me. if you can't comprehend that someone might deliberately choose those words, then that is your problem not mine. such paucity of imagination is truly sad. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 11:52:59PM -0500, The Doctor What wrote: > You on the other hand show no thought for anyone else. i show no regard for those who demonstrate they are fools. i show contempt for those who demonstrate that they are annoying fools. guess which category you fall into. in short, say something merely stupid and i will ignore you. say something stupid and irritating and i will rub your nose in it. > And finally, just to make sure we're all clear on the matter > "no regards, craig" i had some doubts as to whether you might get the picture. in your case, i thought spelling it out was necessary. > or at least see that stabbing at people isn't productive. if it makes fools quit their yapping then it can be highly productive. this "discussion" is a waste of time. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Oct 02, 1999 at 04:36:04PM +0200, Piotr Roszatycki wrote: > I've install postgresql on my home computer. I need this daemon only > sometimes. I don't want to start it every time I reboot system. you need to do something non-standard, so you should do a little bit of work to accommodate your own needs. if i needed to do the above then i would edit /etc/init.d/postgresql and (in the case statement) change "start)" to "go)". this way, it would not get started at boot time, but i could easily start it by running "/etc/init.d/postgresql go". pros: simple. takes <20 seconds with vi. minimal change, so follows principle of least surprise. easy to remember. init.d scripts are conffiles so it won't be automatically replaced at the next upgrade. cons: you have to re-do the change if you ever upgrade and answer "Y" to dpkg's question about replacing /etc/init.d/postgresql. craig -- craig sanders
Re: Is this a bug in grep, or is it me...
On Fri, Oct 01, 1999 at 04:19:51PM +, Dale Scheetz wrote: > This leaves me with the unresolved problem of distinguishing between the > two package names. > > I just read through the grep manpage (again) looking for something that > will enforce an exact match, when I realised that I can simply skip this > step and do the selection in awk (which I was using before to peel off the > section name from the grep output), so the right command is: it seems to me that the word you are looking for (i.e. the package name) will always be the first word on a line, so: grep "^PACKAGENAME " override.potato will do the job, and is probably significantly faster than an awk script. craig -- craig sanders
Re: SSH never free
On Sat, Oct 02, 1999 at 10:06:24AM +1000, Herbert Xu wrote: > They use libssl, which begs the question why isn't libssl in > non-US/non-free? i thought that only copyright/license and *not* patent issues determined whether we considered something to be free or non-free. e.g. libssl is completely free software in the free world, but encumbered by a patent problem in the world's favourite police state. craig PS: the RSA patent expires in 2001 (or is it 2002?), anyway. -- craig sanders
Re: ITW/P: freecati
On Fri, Oct 01, 1999 at 11:22:11PM -0500, Chris Lawrence wrote: > For the unfamiliar, CATI programs are used to to conduct surveys over > the telephone (although they can also be used in other contexts). > Think of an "installation wizard" with a modem dialer and database > backend, and you've got the idea. The concept here is basically to > make it possible to turn mothballed 486es (or eMachines ;-) into > interviewing stations running Linux for the cost of a network card, a > good USR modem and a noise-cancelling headset (i.e. well under $200). IMO, this is morally akin to writing free software specifically to make spamming cheaper and easier. if you must write such obnoxious and evil software then please make sure that it maintains a list of phone numbers NOT to call, so that those who are sick and tired of market research jerks calling them just as they get home from work or sit down to dinner can say "PUT ME ON YOUR DO-NOT-CALL LIST IMMEDIATELY!". write the software so that it is trivially easy for the telemarketer to add numbers to that list. craig -- craig sanders
Re: ITW/P: freecati
On Sat, Oct 02, 1999 at 10:50:06PM -0500, Chris Lawrence wrote: > On Oct 03, Craig Sanders wrote: > > IMO, this is morally akin to writing free software specifically to make > > spamming cheaper and easier. > > No, it isn't. Survey research is an important part of the social > sciences. it may be an important tool, but that doesn't give you or anyone else the right to pester people in their own homes. it really does no good to apologise or even to promise not to call back - by that time, the damage has been done...the interruption/disturbance has been made, the invasion of peace, solitude and privacy has already been perpetrated. even opt-out lists are the wrong solution...because they don't work very well (especially when usage of them is optional). telephone pests should be limited to calling ONLY an opt-in list, people who are willing to receive unsolicited calls. > 1. Market research is only one use of computer assisted interviewing. >The purpose of this project is to make it possible for a survey lab >to be established cheaply by a university; existing solutions are >overpriced, especially considering the fact that taxpayers tend to >get hit with the startup costs for these things. cold calls are annoying regardless of their purpose. sales calls are especially annoying, but that doesn't excuse academic or market research surveys. i personally don't have a problem with existing solutions being overpriced - this is one area where an artificially high barrier to entry is unquestionably a Good Thing. the right to peace and quiet in your own home is far more important than the desire of universities to conduct surveys. > 2. Ethical researchers do not call back people who, having been >informed of the nature of a survey, choose not to participate. The >software will include this "refusal" marking capability. good. that was the main reason i replied to your message. if you are going to write software that makes it easier or cheaper to pester people in their own homes then that software should make it trivially easy to add new numbers to the do-not-call list, and it should be do-able by the operator who makes the call at the time that the victim complains. > 4. Software is a tool, it is neither evil nor good. Like any other >technology, it is a matter of responsible use. some technologies have little or no 'good' usage. some technologies have negative effects which greatly outweigh any positive ones. > Chris, who guesses he should have kept his mouth shut, made the > software proprietary, and saved everyone a world of grief. look, it's your software, your project. nobody can stop you from writing it, or packaging it for debian. the point of my message was to inform you that your work will have certain negative consequences and will end up being used to harass and pester people. little/startup telemarketing companies WILL use your software whether you market it as a "telemarketing solution" or not - this WILL increase the number of annoyance sources in the world. like it or not, you have to accept some of the moral responsibility for that. craig -- craig sanders
Re: ITW/P: freecati
On Mon, Oct 04, 1999 at 01:02:55AM +0200, Marcus Brinkmann wrote: > On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote: > > even opt-out lists are the wrong solution...because they don't work very > > well (especially when usage of them is optional). telephone pests should > > be limited to calling ONLY an opt-in list, people who are willing to > > receive unsolicited calls. > > opt-in lists will not lead to usable results, because the statistics > will be skewed, and you know that. yep. there's an inherent conflict between those who want to run surveys and those who don't want to be pestered. i happen to believe that an individual's right to privacy, right to not be pestered supercedes a researcher's desire to survey. so, it's a shame that stats might be skewed but that doesn't justify bothering people who don't want to be pestered. btw, if the opt-in list were large enough then there wouldn't be any skewing of results. most telesales, telemarketing, and tele-survey people don't want to use opt-in lists because they KNOW that most people don't want to be pestered by them...opt-in highlights the fact that what they are doing IS rude, and most people resent it. OTOH, many people don't mind being surveyed or called by salesdroids. i find that bizarre, but i guess it's horses for courses. > Nevertheless, I agree that calling random people is rude. that's it precisely. craig PS: all this is getting even further from relevance to debian-devel, so i guess we better stop here. -- craig sanders
Re: ITW/P: freecati
On Sun, Oct 03, 1999 at 07:29:15PM -0400, Raul Miller wrote:
> On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote:
> > it may be an important tool, but that doesn't give you or anyone else
> > the right to pester people in their own homes. it really does no good
> > to apologise or even to promise not to call back - by that time, the
> > damage has been done...the interruption/disturbance has been made, the
> > invasion of peace, solitude and privacy has already been perpetrated.
>
> Huh? I'd rate such (genuine survey) phone calls as more pleasant to
> deal with than any of your recent emails.
there is a huge difference in the nature of public spaces and private
spaces, and a huge difference in the acceptable uses of each.
debian-devel is a public forum, i.e. public space. an individual's phone
number is private space, for personal communication.
if you enter a public forum you have to expect to occasionally hear (or
read) things you'd rather not hear/see. e.g. i have a right to say what
i like in a public space...if you don't like what i say, then killfile
me or find another public forum more to your tastes. if what i say is
objectionable to enough other people then it is i who will have to find a
forum which tolerates me.
a person has the right to expect that they will not be pestered in their
private 'space'. e.g. i don't have any right at all to invade your
private space. if you don't want me there, i have to go. if i have no
reason to believe that i would be welcome then i shouldn't attempt to
enter it in the first place.
> I've gotten phone calls from telemarketers, and I've gotten phone
> calls from survey folks. The survey folks are incomparably more
> polite.
relative politeness is not relevant. what matters is that it is
unforgivably rude to invade someone's private space without invitation
or without reasonable belief that you will be welcome. it is not
reasonable for a tele-{marketing,sales,survey} caller to believe that a
complete stranger will welcome them without invitation.
tele-{marketing,sales,surveying} is organised and automated rudeness,
scheduled invasion of private space. it's a numbers game: call enough
people and you're bound to find a few who aren't annoyed. cold-callers
don't give a damn about the majority who are annoyed...they aren't any
use to them anyway. that callous disregard for people's private space is
highly objectionable.
> On the other hand, I've got a decent sized buffer (voice mail) on my
> phone and don't feel compelled to answer it if I'm in the middle of
> something else (which is most of the time).
part of my job is to be available for emergencies at any hour, i have
to answer calls just in case it is something that requires my immediate
attention.
these anecdotes aren't particularly relevant though. what is relevant is
that these unsolicited calls are an invasion of private space.
craig
--
craig sanders
Re: ITW/P: freecati
On Mon, Oct 04, 1999 at 12:08:59PM -0700, A.J. Rossini wrote: > Just for the record, some of us use CATI to get information from > subjects (voluntary participation) who can not come to a research site > for various reasons . i have no problem at all with voluntary participation in surveys or market research or even telesales. if someone wants to volunteer for these activities it's their right to make that choice. i object only to tele-anything which involves making unsolicited calls to complete strangers. > This is incredibly different from telemarketing; yep, it's completely different. not the same thing at all. > in fact, one could argue that not using CATI in such a situation > is unethical (discrimination in clinical/intervention trials > participation against those too sick to travel...). i don't know if i'd go as far as saying that not using it would be unethical, but i certainly agree that this usage IS an ethical and appropriate use of this kind of software. craig -- craig sanders
Re: Secret Holy Code revealed to Seekers of Truth!
On Thu, Mar 09, 2000 at 12:18:49AM -0500, Jaldhar H. Vyas wrote: > On Wed, 8 Mar 2000, it was written: > > > SECRET HOLY CODE REVEALED ALL GENUINE SEEKERS OF TRUTH. > > I don't know. Is this dfsg-compliant? it conflicts with the non-discrimination clause. the secret holy code should be available to non-genuine seekers of truth, and to seekers of falsehood (genuine or not) too. god told me to write this so you better believe it. craig -- craig sanders
Re: Danger Will Robinson! Danger!
On Sun, Mar 12, 2000 at 03:53:41PM -0600, Steve Greenland wrote: > On 12-Mar-00, 10:56 (CST), Ron Farrer <[EMAIL PROTECTED]> wrote: > > I disagree! (surprise ;) I personally know of about ~4 people who > > were turned away from slink because GNOME and KDE were so OLD. I > > personally got around this by running potato (unstable then), but > > most people don't WANT to run unstable! > > Which is it? Do your friends want the newest bleeding edge stuff, or > do they want stability? They can't have both at the same time! Oh, I > see, the want the newest, but they want us to call it "stable". > > Sigh. > > Why is is this basic distinction so hard to explain to people? Testing > and reliability take time. During that time, new features are going > to show up in various parts of the system. Along with those new > features come compatibility and reliability problems. You can either > have the new features, or you can have a tested, stable, reliable > *system*. *YOU* *CAN'T* *HAVE* *BOTH*. IMO, the "problem" (for want of a better term) is that unstable is not as accessible as the stable release - only those who have fast, reliable, and cheap internet connections can get it. functionally, "unstable" is every bit as good (if not better) than "stable"...it may not be as well tested, but there are rarely any major problems when keeping a machine, even a production server, in sync with the latest unstable. the solution, therefore, is two-fold. first is to have regular (monthly? bi-monthly? quarterly?) snapshot CD images of unstable. clearly label them as "unstable", "untested", whatever - the point is to make "unstable" much more accessible to everyone. (every 3 or 4 snapshots, do the full testing thing and come up with a "stable" release) the second part is user education - make sure that the users know what us developers already know...that "unstable" doesn't mean that the system is flaky or unreliable, it means that it is subject to rapid change - and that because of those rapid changes there are occasional problems requiring a bit of a clue to sort out, but mostly debian "unstable" is just more of the same only newer and better. i believe that this second stage will occur as a natural result of making the regular snapshot CDs. this will get our latest and greatest stuff in the hands of most end-users (rather than just developers and the most enthusiastic users). in addition, more users mean that each package will be tested more thoroughly. the overall effect of this is to take advantage of our biggest advantage - if you compare "unstable" with any of the other dists (commercial or otherwise), then we are way ahead of them for most programs/packages. the perception that debian is behind is only true for those stuck with stable. craig -- craig sanders
Re: Danger Will Robinson! Danger!
On Sun, Mar 12, 2000 at 08:59:30PM -0300, Nicolás Lichtmaier wrote: > We are all using potato, but we are shipping slink, keep that in mind. last year we were...but now i would bet that half of us (or more) are running woody, not potato. imo, that says a lot about the quality of debian "unstable" - many of us are willing to risk our important systems to it. rather than seeing that as a problem, we should be working to take advantage of "unstable"'s stability and quality. craig -- craig sanders
