Re: netstsd depends on cpp?
On Apr 26, Nicolás Lichtmaier wrote: Nothing shows up with: grep cpp $(cat /var/lib/dpkg/info/netstd.list) /var/lib/dpkg/info/netstd.* Why should netstd depend on cpp? rpcgen needs cpp. I forgot to remove the dependency when I moved rpcgen from netstd to netbase. The next netbase package will suggest cpp. Thanks, Peter -- Peter Tobias [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netstsd depends on cpp?
Why should netstd depend on cpp? rpcgen needs cpp. I forgot to remove the dependency when I moved rpcgen from netstd to netbase. The next netbase package will suggest cpp. Great, thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new boot-floppies with pkgsel tool
I have uploaded boot-floppies_2.0.5 to master's incoming. This version fixes (almost) all known bugs, and includes the package selection tool that has been mentioned here before. As it is know, only a few selections are defined, so it's not of much use. I ask you to send your favourite selections for inclusion in the next (and hopefully last before hamm release) version. Thanks, PS: This boot-floppies version also includes pppconfig for you lucky people with cheap phone rates. ;-) -- Enrique Zanardi [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt: HTTP transfer method does not use available bandwidth
[I originally thought this was a problem with apt, but it appears to be a problem with HTTP transfers in general, so I am putting it on the devel list.] Jason Gunthorpe wrote: The HTTP transfer method now used by apt is slow and does not use all the bandwidth available. By comparison, the ftp method uses all available bandwidth. First off, you are using unix.hensa.ac.uk for both of your tests? Yes. (Except for http://ftp.de.debian.org/debian-non-US for the non-us section.) I just performed a quick comparision here, I downloded the 1M file, ftp://unix.hensa.ac.uk/mirrors/debian/hamm/hamm/binary-i386/Packages http://unix.hensa.ac.uk/mirrors/debian/hamm/hamm/binary-i386/Packages I used lftp for the ftp method and apt's http method for http. lftp took 44 seconds (25.2 k/s) to download the file and the http method took 31 seconds (35 k/s) - this includes the time to establish the connection and send the request while ftp only included the time from first byte recived. As you can see not only is the bandwidth higher for http but the total overall transfer-rate is also much higher than ftp. OK, so I shouldn't be having a problem... Just for kicks I tried the same with wget, it got 27.60 kb/s on http and 30k/s on ftp (As you can see my connection to the UK varies quite a bit) I'm IN the UK; the very best I can get is 8k/s (one ISDN channel). I would try wget on the above two URL's and see what you get for speed, Recovering the same file, while apt is transferring data: unix.hensa.ac.uksunsite.doc.ic.ac.uk wget http: 1.97KB/s1.90KB/s wget ftp: 5.19KB/s5.42KB/s ftp:4.2 Kbytes/sec 4 Kbytes/sec (`wget URL' as opposed to `get file' inside an ftp session.) OK, so it's not apt, but http. if http is slower then perhaps your ISP is transparently running you through a proxy server - also check that you do not have http_proxy in your environment, you might be using an overloaded proxy server. (In which case complain to your ISP : ) Should running squid locally make a difference? (I shut it down, but it doesn't seem to have changed anything.) My ISP has a proxy-server, but you have to configure Netscape to use it, so presumably it is not transparent. I'm trying again with dselect+apt just now. This time I let it go past getting the packages files; it certainly seems to show a denser pattern on the monitor when getting the actual .deb files, though still not the solid black that I expect to see from ftp... ...now it's gone back to the original light pattern. Is there anything about the HTTP protocol which makes a difference if you are using a lower bandwidth? For example, if I cannot accept stuff at the rate at which the other end can push it out, will the other end reduce its attempted output rate? What packages are involved that might need investigating? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 Come to me, all you who labour and are heavily laden, and I will give you rest. Take my yoke upon you, and learn from me; for I am meek and lowly in heart, and you shall find rest for your souls. For my yoke is easy and my burden is light.(Matthew 11: 28-30) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt: HTTP transfer method does not use available bandwidth
Oliver Elphick olly@lfix.co.uk wrote: unix.hensa.ac.uksunsite.doc.ic.ac.uk wget http:1.97KB/s1.90KB/s wget ftp: 5.19KB/s5.42KB/s wget uses HTTP/1.0, so must establish a new connection for every file transfered via http, but can re-use the connection for ftp. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intent to package: gnus
Gnus lives a life of its own outside the various Emacsen. There seemingly isn't a version in a released Emacs package that isn't superseded nearly immediately. Furthermore, there is a new release with some features I'm interested in having access to. Therefore I intend to package it separately, to integrate with the various emacs. Hopefully it'sll work as a drop-in replacement. I don't have a lot of time at the moment, so this may take awhile. If this message inspires anyone to think about having a go themselves, please contact me. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cruft : great program ! everyone should use it !
On Sat, Apr 25, 1998 at 01:06:35PM +0200, Andreas Jellinghaus wrote:
i realy like cruft a lot ! i strongly suggest to all developers to check
their systems, and improve the packages.
Thanks :)
suggestion to the craft autor :
with MAKEDEV -I you can create device files in the local directory,
even within fakeroot. what about adding a list of the normal devices to cruft,
and report obsolete devices, strange permissions, etc. this would require
some cooperation with the makedev maintainer, but would be realy good.
I've already mentioned this to Andreas on irc, but I've got a first draft
of this implemented -- it currently checks that you have exactly those
devices listed in MAKEDEV's generic batch. Andreas also suggested that
it should allow, but not require, *any* device file MAKEDEV knows about,
which will require a little reworking of cruft, so I've left that until
I have a little time to think about it.
What I'm using at the moment is a new version of /usr/lib/cruft/explain/dev,
which looks something like:
---
#!/bin/sh
if [ -x /dev/MAKEDEV ]; then
/dev/MAKEDEV -In generic | grep -v '^l' | awk '{ print /dev/ $8 }'
/dev/MAKEDEV -In generic | grep'^l' | awk '{ print /dev/ $2 }'
fi
---
If you copy that into /etc/cruft/explain/dev, it will override the dev
explanation thingy that's distributed with cruft, without messing with
.deb'ed files, btw.
Just FYI.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
pgpE2SGMMNL2t.pgp
Description: PGP signature
Re: cruft : great program ! everyone should use it !
In article [EMAIL PROTECTED] you wrote: : with MAKEDEV -I you can create device files in the local directory, : even within fakeroot. what about adding a list of the normal devices to cruft, : and report obsolete devices, strange permissions, etc. this would require : some cooperation with the makedev maintainer, but would be realy good. WARNING WARNING WARNING The makedev maintainer (that's me) intends to change upstream code bases in a significant way for slink. Any work on device file consistency in cruft would be well-advised to wait a month or three, until this gets done. I'd hate to see a lot of work go into whacking around with the current MAKEDEV since I can't guarantee that the options will all be the same, etc... Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
On Sun, Apr 26, 1998 at 01:23:06PM -0400, Carl Mummert wrote: [added Cc: to debian-policy] Question: when does dpkg write the /var/lib/dpkg/info/*.list ??? When installing, when removing, and when purging, by the looks of things. ie, currently whenever dpkg adds or removes a file belonging to a package, it notes it down it its info/package.list file. Situation: Package X has something in the post-inst script which the developer knows will create file F, which dpkg will not know about (known problem). The current suggestion on how to deal with this is by using an extrafiles dpkg control file that the package includes which lists the files it could end up creating, either in the maintainer scripts, or in general operation. Example contents of extrafiles are the files in /usr/lib/cruft/filters/*, btw. The text of the proposal itself is at http://va.debian.org/~ajt/, the rationale c. are best found by looking through the -policy archives under the Subject: PROPOSAL: Extrafiles (was...). Suggestion: Package X could, if the files already exist at this point, include 'cat F /var/lib/dpkg/info/X.list ' in the post-inst list. This would associate the newly-created file with the newly-installed package, and would prevent the buildup of cruft which otherwise would develop when package X is removed. The postinst script is the perfect time to do this, because this script knows with 100% certainty which files it creates. A quick comparison of the two approaches: With the extrafiles approach, you don't know if the extrafile was just lying about before hand, and just *seems* to have been made by the package, or if it really was. Also, extrafiles doesn't provide any mechanism for dpkg to automatically remove extrafiles. (This is seen by some to be a Good Thing(tm), though) With the above approach, odd things might happen if two packages want to share a file (/usr/bin/vi, for example is shared between the various vi clones by using the alternatives interface) Also, the above doesn't provide any convenient way to specify groups of files, for example /var/spool/news/comp/os/linux/announce/2600 would be difficult to associate with inn. I've probably missed some points in the above. I have tried this by adding (by hand) a new package to (...)/status and a corresponding lists file to the info dir. When I ran dpkg --remove on the package, the files listed went away. Not a particular problem with your proposal, but please note that Klee and/or Ian apparently plan on changing those data structures significantly in the future. Apparently they'll still be text though. (yay! :) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``It's not a vision, or a fear. It's just a thought.'' pgpQ00wId8Rud.pgp Description: PGP signature
Re: apt: HTTP transfer method does not use available bandwidth
On Sun, 26 Apr 1998, Raul Miller wrote: Oliver Elphick olly@lfix.co.uk wrote: unix.hensa.ac.uksunsite.doc.ic.ac.uk wget http: 1.97KB/s1.90KB/s wget ftp: 5.19KB/s5.42KB/s wget uses HTTP/1.0, so must establish a new connection for every file transfered via http, but can re-use the connection for ftp. First off, I assume Oliver is testing single files. Secondly wget must recreate a data channel when using ftp anyhow so the fact that wget is only using HTTP/1.0 would not be relavent. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cruft : great program ! everyone should use it !
Bdale Garbee [EMAIL PROTECTED] wrote: a significant way for slink. Any work on device file consistency in cruft would be well-advised to wait a month or three, until this gets done. I'd hate to see a lot of work go into whacking around with the current MAKEDEV since I can't guarantee that the options will all be the same, etc... That should just be a configuration detail, though. No? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt: HTTP transfer method does not use available bandwidth
Jason Gunthorpe [EMAIL PROTECTED] wrote: First off, I assume Oliver is testing single files. Secondly wget must recreate a data channel when using ftp anyhow so the fact that wget is only using HTTP/1.0 would not be relavent. Oh. How.. tacky. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rescue disk crashes with mem=128M or mem=32M or mem=64M
Hi, Fortunately I got you mail an hour before the install and I was able to try your ideas! Copying ldlinux.sys resulted in not a boot device (or somesuch) error. Running the latest syslinux on /dev/fd0 resolved the problem. Thanks! On Fri, Apr 24, 1998 at 05:38:21PM +0100, Enrique Zanardi wrote: On Fri, Apr 24, 1998 at 11:53:19AM -0400, Chris Fearnley wrote: Hi, The April 11th boot disk crashes when I enter the kernel command line option mem=128M (I also tried mem=32M and mem=64M -- all crashed in the same way (see below)). This system has 128M of RAM, but the BIOS only reports 16M to Linux. When I try to correction this on the boot disk command-line, I get the following crash: linux mem=128M (manually entered at boot disk prompt) Loading root.bin... Loading Linux... (I didn't record number of dots here or above) Decompressing Linux... (exactly 3 dots) crc error -- System halted Using the March boot disks this procedure works (boy am I glad I kept a copy of those March boot disks!!!). And using lilo (with the same kernel as is on the boot disk), the mem=128M line works (I even built a kernel and ran lots of memtests to verify that the memory works fine. It does.) Conclusion: the April boot disks are broken wrt the mem kernel command line option. That may be syslinux fault. Can you copy the file ldlinux.sys from March rescue disk to April rescue disk and try again? Or even better, install syslinux_1.37 (now in incoming), put the April rescue disk in the floppy disk drive, run syslinux /dev/fd0 (or fd1) and try installing with that disk, to see if the bug has been fixed. -- Christopher J. Fearnley | Internet21 Network Engineering [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naïve -- Bucky Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cruft : great program ! everyone should use it !
On Sun 26 Apr 1998, Joey Hess wrote: Andreas Jellinghaus wrote: with MAKEDEV -I you can create device files in the local directory, even within fakeroot. No you can't. Making such files requires root permissions. Fakeroot emulates making them, but from outside fakeroot, they look like normal 0 byte files. you are right. but the idea was to get a list of all devices and their security informations, and for this fakeroot is sufficient. andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why not mingetty??
On Sat 25 Apr 1998, Shaleh wrote: I also like that mingetty clears the screen when you log out. It is very professional looking. Reminds me of the suns at school. This is of course trivial to do by putting a clear screen escape sequence at the top of /etc/issue. Make it 25 blank lines if you don't want terminal-type dependencies... Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands Support Randal Schwartz! See http://www.lightlink.com/fors/ or send empty email to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
Raul Miller [EMAIL PROTECTED] writes: (b) The authors of ncftp writing a workalike for readline. [This course of action has also been taken by a few authors of other pieces of software.] I believe I've said this before, but ... A workalike (or, rather, `linkalike') for `readline' has been around for *years*. It is called `editline' and was written by Rich $alz of INN fame (among other things). It has the added advantage of being a fraction of the size of libreadline, but then of course it doesn't do everything that libreadline does. Anselm -- Anselm Lingnau . [EMAIL PROTECTED] The entrenched priesthood of C and C++ may poo-poo the Perl programmers all they want. After all, it's the same thing that the assembly programmers did to *them* before. --- Tom Christiansen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
Hi, Huh? If the maintainer wanted the file to be known to dpkg, they could have added a zero byte file to the paclkage (getting it listed), and then manipulated it in the post inst. *NO* need to muck around in /var/lib/dpkg. The cat idea is a really bad idea. How come no one pointed this out already? The reason some packages handle some files entirely in post inst is because they do *not* want dpkt to lay its grubby little fingers on them. Don't even think about changing dpkg internal files using anything but dpkg. manoj -- It's very hard for anything to make it out of Hollywood these days without a lame-ass wimpout ending tacked on at the whining request of test audiences selected from the most puerile of the Nielsen families, who are, as we all know, chosen on the basis of the number of cousin-cousin marriages in their family over the last ten generations. Nix Thompson ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
rescue1440.bin
It may be a very simple question, how can i make the rescue1440.bin file from my floppy disk (because on this disk i have put the kernel 2.0.33) -- Julien Ortega -- EXTERN e-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
locales default setup for first installs
Some time ago it was suggested (here or at [EMAIL PROTECTED], I can't remember) that the installation system should create a LANG=locale line in /etc/profile, /etc/environment or any other file alike, that would define the default locale for the system, and may be overruled in the users' ~/.whatever-your-shell-uses. I would like to implement that for hamm's boot-floppies, as that would make Debian the first Linux distribution that supports Latin1 out of the box. The question is, where should I put that line? /etc/profile : Not every shell uses it. (And I'm not sure that setting root's locale to anything other than C won't cause problems with daemons, cron scripts and anything else that runs automatically). /etc/environment : Which program/s use that? (same concerns about root's locale). /etc/skel/.whatever That may be tricky, as it may mean other packages should be aware of that line, and don't overwrite it. Suggestions? -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Hi Austin, Incidentally, simply rebuilding the acct package against the new header files is a little tricky, since the ./configure script uses sys/acct.h in preference to linux/acct.h Did you manage to build a acct package for 2.1.96? If so, could I get it from you? Cheers, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acct: process accounting and 2.1.96
(Please excuse me for omitting the subject line in my previous mail) Hi Austin, Incidentally, simply rebuilding the acct package against the new header files is a little tricky, since the ./configure script uses sys/acct.h in preference to linux/acct.h Did you manage to build a acct package for 2.1.96? If so, could I get it from you? Cheers, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.9 (source all) uploaded to master
-BEGIN PGP SIGNED MESSAGE- On Sun, 26 Apr 1998, Richard Braakman wrote: Changes: base-files (1.9) frozen unstable; urgency=low * nsswitch.conf: Use compat instead of db files for passwd, group and shadow (Bug #10896). I think this is a bad time to make changes to the default nsswitch.conf in hamm. Historically the configuration of nsswitch has been quite tricky; its current contents are the result of much experimentation and bughunting. I reviewed bug #10896, and it does not list any specific bad effects of having nsswitch the way it is now. You have to change it for nis to work. Debian policy is to have good default values. A good default value is one that has not to be changed. Therefore, compat is better that db files. I strongly recommend against this change, unless it can be shown to fix something that is broken. compat is the default value used by glibc when you have no nsswitch.conf file. If using compat is wrong, glibc would be wrong also. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNURw8yqK7IlOjMLFAQFgAAP/YBy1Gz7UHv/jRN7hudnuLX62CvRu2/iK Pj3cfHtYgVm7Am6DBYPza9iRHdkNsEO1D8S+4VvFOjEXSJY0Jnl3XBQvTVhbdb3S cs2MgAvXToTgPBULNneNGMOkmjZgG58lDAi7o8IP7Uz+ec9/tVM2x+6XoSPhe1BT EWTamB4h3cw= =QkL2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do with /bin/perl symlink?
On Sun, 26 Apr 1998, Enrique Zanardi wrote: On Sun, Apr 26, 1998 at 02:50:49PM +0200, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Sun, 26 Apr 1998, Enrique Zanardi wrote: Currently the base system comes with that symlink, but I plan to remove it for the next boot-floppies release. Objections? None. Just a question: Are there more files (still) in the base system but not in any package? Files from packages not in the base system: - /usr/bin/ftp and /usr/bin/telnet (from netstd, they should be moved to netbase) - /usr/lib/perl5/Net/DirHandle.pm (from perl, it should be moved to perl-base) [snip] Please file wishlist bug-reports--if you haven't done so already. Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License advice
[EMAIL PROTECTED] (Marcus Brinkmann) wrote on 23.04.98 in [EMAIL PROTECTED]: On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: As far as I can tell this license is DFSG-free; please let me know if you disagree. This is weird, especially because of point 3. I can see nothing weird there. He means the right thing, but he doesn't mention modification, redistribution of modificated versions and selling. Huh?! First, not mentioning selling is *good*. Second, he does mention all the other stuff - to alter == to modify. Please point him kindly to Debian, the dfsg and to a more explicit license we require to put it in main. This would mean, that you point him to Artistic License, GPL, Xfree's and so on. Don't. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
[EMAIL PROTECTED] (Charles Briscoe-Smith) wrote on 24.04.98 in [EMAIL PROTECTED]: The gist is this: most of the obnoxious advertising clauses in BSD-ish software specify a different sentence which must be mentioned on advertising mentioning the software. This means that if I build a distribution with lots of BSD software in it, there are likely to be a lot of different sentences I must include on my advertisements (or I must restrict myself as to how many features I mention in any one advertisement, so as to reduce the number of sentences I must include). RMS says he counted 75 different sentences in one of the BSD distributions. And this is a problem because ...? Good advertizing doesn't try to mention 75 features, anyway. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License advice
[EMAIL PROTECTED] (Adrian Bridgett) wrote on 23.04.98 in [EMAIL PROTECTED]: On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: As far as I can tell this license is DFSG-free; please let me know if you disagree. Copyright (c) 1997-1998 by Armin Biere. Author: Armin Biere. Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, ^^ Hmmm - which version of free is this - ethically or financially? It's quite obviously without restrictions. As the part of the sentence you cut out makes clear. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
[EMAIL PROTECTED] (Santiago Vila) wrote on 26.04.98 in [EMAIL PROTECTED]: I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at least) in /etc/skel/.bashrc. Would it be against policy? Policy 3.3.7 '/etc/skel' should be as empty as we can make it. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
[EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in [EMAIL PROTECTED]: Enrique Zanardi [EMAIL PROTECTED] wrote: I'm not a dpkg expert, but AFAIK modifying directly the dpkg databases (yes, almost everything under var/lib/dpkg are dpkg databases) is a Wrong Thing (TM) In the current implementation those databases are ASCII files, but that may change (and surely _will_ change) in the future, so relying in that format will cause compatibility problems. The right way to solve that issue is by adding an(other) option to dpkg. Um... I don't like the idea of making dpkg itself yet more complicated. I think that's the only acceptable way, though (as long as we take dpkg to mean dpkg_*.deb). Ian has in the past said (and I agree, FWIW) that tampering with the dpkg database is extremely evil. This very idea has come up before, incidentally, should be in the archives. I may even have been the one to suggest it. Anyway, Ian was very firmly convinced that this was an extremely bad idea, either way. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
[EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in [EMAIL PROTECTED]: Alex Yukhimets [EMAIL PROTECTED] wrote: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; Note that Sections 1 and 2 do NOT require that all the source be licensed under the same terms. So what? You can't pick just the parts of the license you like. I don't see any requirement that all code be relicensed under the GPL, only a source code available requirement (and even then not always, for proprietary operating systems). [I've taken the liberty of not quoting the rest of the stuff which basically just re-makes this point.] Ah, no. That was the part that made the point that *if you distribute binaries*, you have additional obligations. And Motif only fits if it's part of the OS. Which, for Debian, it isn't. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt: HTTP transfer method does not use available bandwidth
olly@lfix.co.uk (Oliver Elphick) wrote on 27.04.98 in [EMAIL PROTECTED]: unix.hensa.ac.uksunsite.doc.ic.ac.uk wget http:1.97KB/s1.90KB/s wget ftp: 5.19KB/s5.42KB/s ftp: 4.2 Kbytes/sec 4 Kbytes/sec Should running squid locally make a difference? (I shut it down, but it doesn't seem to have changed anything.) My ISP has a proxy-server, but you have to configure Netscape to use it, so presumably it is not transparent. If shutting down squid doesn't make a difference, this makes me suspect you weren't using it. Otherwise, you'd need to reconfigure to get _anything_ working. If you were using it, it should speed up repeated gets of the same URL. Anyway, do a netstat --ip in another console/window while you're downloading, to see what connection you are using; fuser yourport/tcp can show you the process id of the process holding your end of the connection. Is there anything about the HTTP protocol which makes a difference if you are using a lower bandwidth? For example, if I cannot accept stuff at the rate at which the other end can push it out, will the other end reduce its attempted output rate? Both ftp and http do the main data transfer the same way, just pushing a large block of data through a tcp connection. And if different programs show the same effect, it's probably not the programs. It could be that your ISP penalizes http connections that *don't* use his proxy. From westfalen.de, I happen to know that http connections make for the largest part of the bandwidth by far, so much that there are ISPs that outright block any http not through their cache. There's one more thing you can do. Run tcpdump -i interface on your connection and look at the packets, and see if there's anything different between ftp and http you can spot. What packages are involved that might need investigating? I suspect it's your ISP, not any package. Or otherwise, it could be the kernel. Hardly anything else. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ftp.debian.org mirroring seems busted
[EMAIL PROTECTED] (Kai Henningsen) wrote on 04.04.98 in [EMAIL PROTECTED]: It looks like it's fixed again. Thanks to whoever did it! And now it's broken again: 803 14.04 [EMAIL PROTECTED] Mirror mismatch 925 15.04 [EMAIL PROTECTED] Mirror mismatch 619 16.04 [EMAIL PROTECTED] Mirror mismatch 619 17.04 [EMAIL PROTECTED] Mirror mismatch 619 18.04 [EMAIL PROTECTED] Mirror mismatch 619 19.04 [EMAIL PROTECTED] Mirror mismatch 1 62k 20.04 [EMAIL PROTECTED] Mirror mismatch 1 62k 21.04 [EMAIL PROTECTED] Mirror mismatch 1 62k 22.04 [EMAIL PROTECTED] Mirror mismatch 1 62k 23.04 [EMAIL PROTECTED] Mirror mismatch 518 24.04 [EMAIL PROTECTED] Mirror mismatch 60k 25.04 [EMAIL PROTECTED] Mirror mismatch 129k 26.04 [EMAIL PROTECTED] Mirror mismatch 142k 27.04 [EMAIL PROTECTED] Mirror mismatch 1 was when master was broken. As you can see, this went away on the 24th, but it looks like that one was manual and automatic mirroring is still stuck. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
[EMAIL PROTECTED] wrote on 24.04.98 in [EMAIL PROTECTED]: of the old wording in the policy manual, which mentioned onerous conditions (of which this is one, IMHO) as a reason for things going Nope. I really don't think it is. MfG Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why not mingetty??
Paul Slootman [EMAIL PROTECTED] wrote: This is of course trivial to do by putting a clear screen escape sequence at the top of /etc/issue. Make it 25 blank lines if you don't want terminal-type dependencies... Conceptually, you probably don't want to clear the screen for new serial connections (makes problem analysis hard -- imagine talking over the phone to a casual user and asking What kind of connect message did you get?). Probably the right thing to do is issue \027e at the bottom of the loop, after the point where a serial line would be dropped. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Kai Henningsen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in [EMAIL PROTECTED]: Alex Yukhimets [EMAIL PROTECTED] wrote: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; Note that Sections 1 and 2 do NOT require that all the source be licensed under the same terms. So what? You can't pick just the parts of the license you like. Please read what you just quoted. See where it says or executable form under the terms of Sections 1 and 2 above? That's where it's talking about the license required. Most of the rest is talking about the source disclosure requirement. In other words, I didn't pick just the parts of the license I like. The license explicitly refers to the definitions presented in sections 1 and 2. Or did you have some other point? I don't see any requirement that all code be relicensed under the GPL, only a source code available requirement (and even then not always, for proprietary operating systems). [I've taken the liberty of not quoting the rest of the stuff which basically just re-makes this point.] Ah, no. That was the part that made the point that *if you distribute binaries*, you have additional obligations. And Motif only fits if it's part of the OS. Which, for Debian, it isn't. The additional obligation is that you be wiling to redistribute the source. There is *NO* obligation that you re-license Motif under the GPL. Any license which allows unrestricted access to the Motif source is fine. Thus, any DFSG compliant license is fine. Yes, there is a special exception to this rule, to make it legal for someone to distribute binaries for proprietary OSes. And, yes, it's clear that Motif on linux doesn't qualify. And, yes, I had earlier made a mistake and said that I thought it would be ok to distribute an emacs linked against Motif statically. There were really two issues brought up in this thread: (1) That the GPL required that other linked in software also be GPL licensed. This is false. (2) That the GPL prohibitted distribution of emacs binaries linked against Motif, with the current Motif license. This is true. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
[EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in [EMAIL PROTECTED]: I don't like the idea of making dpkg itself yet more complicated. Kai Henningsen [EMAIL PROTECTED] wrote: I think that's the only acceptable way, though (as long as we take dpkg to mean dpkg_*.deb). I was taking dpkg to be the program named dpkg and was suggesting that this functionality remain outside that program. Of course, putting the utility into the dpkg suite is a good (essential) idea. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
Manoj Srivastava [EMAIL PROTECTED] wrote: Huh? If the maintainer wanted the file to be known to dpkg, they could have added a zero byte file to the paclkage (getting it listed), and then manipulated it in the post inst. *NO* need to muck around in /var/lib/dpkg. The cat idea is a really bad idea. How come no one pointed this out already? This only works if the name of the file can be anticipated at package creation time, and where it's not confusing to do so. But, yes, in that case it's a much better approach. Then again, the only case I can think of where this approach doesn't work very well is magicfilter, and those should probably be treated as conffiles. The reason some packages handle some files entirely in post inst is because they do *not* want dpkt to lay its grubby little fingers on them. Of course, this would still be possible. Don't even think about changing dpkg internal files using anything but dpkg. dpkg, the package suite, or dpkg the binary executable? [Even there, until dpkg has a track record of getting the installation right and not messing up, it's perfectly reasonable for the *system administrator* to muck with these files. I know we're talking about package maintainer activities at the moment, but I think this point has been made incorrectly, too many times.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
Kai Henningsen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Santiago Vila) wrote on 26.04.98 in [EMAIL PROTECTED]: I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at least) in /etc/skel/.bashrc. Would it be against policy? Policy 3.3.7 '/etc/skel' should be as empty as we can make it. This doesn't apply. There's already a .bash_profile (and a .bashrc) in /etc/skel/. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Constitution - formal proposal (v0.7)
Please see http://www.chiark.greenend.org.uk/~ian/debian-organisation-0.7.html http://www.chiark.greenend.org.uk/~ian/debian-organisation-formal.html http://www.chiark.greenend.org.uk/~ian/debian-organisation.html for the latest draft constitution. If there are no more significant comments and amendents I shall call for a vote in two weeks [4.2(4), A.2]. I call on Manoj to formally withdraw [A.4, 4.2(5)] his proposed amendment, as I believe based on public and private email I've answered all of the concerns it addressed. I hereby propose and accept an amendment to my motion, for the changes from 0.6, at ...-0.6.html, to this version. Changes since 0.6, most significant first: * Debian's property in s.9 (SPI) changed to Property held in trust for purposes related to Debian, to avoid possible tax liability and other legal problems. This is a significant substantive change ! * Person who calls for a vote must collate motions, amendments, etc., though Secretary doesn't have to use their collation. * Proposer of a resolution can suggest wording changes to amendments, to take effect if amender agrees as well and no seconders (of the amendment) object. * Technical Committee member can't vote on motions to overrule themselves as a developer, unless they're the Chairman (who only gets a casting vote anyway). * Technical Committee has a quorum, of two _including_ the chairman (who can not otherwise vote, usually, having only a casting vote). * Section on withdrawing (A.4) is now clearer and (probably) has more sensible effect. * `Decision body of last recourse' sentence about SPI clarified. * Decisionmakers listed in rough order of precedence. (No substantive change, though.) * Typo and numbering fixes. Ian. (Please honour the `Reply-To: debian-devel' header.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
-BEGIN PGP SIGNED MESSAGE- On 27 Apr 1998, Kai Henningsen wrote: Santiago Vila wrote on 26.04.98: I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at least) in /etc/skel/.bashrc. Would it be against policy? Policy 3.3.7 '/etc/skel' should be as empty as we can make it. Ok, Only if the program doesn't support a site-wide default configuration and the package maintainer doesn't have time to add it should a default per-user file be placed in /etc/skel. In this case, /etc/profile *may* be used (by checking whether $SHELL is /bin/bash). Moreover, policy says: Ideally the sysadmin should not have to do any configuration other than that done (semi-)automatically by the postinst script. Well, I'm sure than 99% of people dislike current default bash prompt in /etc/profile. At least we could put the current dir, and maybe that 99% would decrease a lot. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNUSaBiqK7IlOjMLFAQH+9QQAnWoSQMRCk0xaD9mr836Odj7FO+f8V4o2 0er8moXKSKPUSWr+W7D/442woj8U/bnqdBI0QG4Wa77tsR2mQvmCGb7qe84mPHNl MBImtKu5l8BTZdS5U1QVG3yGxepg4MgOjx4xX7fR/Hrh0TEohTDaxJKkBOVx1475 qnMa33ZxRaE= =l9/d -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Looking for xemacs20 user wishing to help
Hi there, I've uploaded some days ago a NMR of tm (Tools for MIME). However, as I'm quite short of bandwidth, I only have emacs19 and emacs20 installed, and could not get from xemacs20 the list of files to byte-compile. I'd be grateful to an xemacs20 user (with bbdb and mailcrypt installed if possible) who would like to run some elisp code for me, and send me back the list of those files. Thanks by advance, -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
There were really two issues brought up in this thread: (1) That the GPL required that other linked in software also be GPL licensed. This is false. Well, GPL or less restrictive as far as source code redistribution is concerned. Right? Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Alex Yukhimets [EMAIL PROTECTED] wrote: Well, GPL or less restrictive as far as source code redistribution is concerned. Right? Unless you want to discuss the particulars of license details, yes. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to handle troff sources
Hello, I'm busy to build the wordnet package. After some problems in the beginning I think the build process works so far and I get the packages as I like them. The wordnet sources contain some troff formatted documents. The maintainer of the former wordnet release decided to support them in Postscript. This isn't the best way I think. I want to ship the troff sources including a reasonable Makefile. Now my questions: 1) Would you think that it is a good idea to chip the troff sources in the *.deb package? 2) If yes what would you include in the Makefile? 1. troff - ps (of course) 2. troff - what else Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
At 12:08 26-04-98 -0400, Raul Miller wrote: Raul Miller [EMAIL PROTECTED] wrote: You're probably thinking of xemacs. [Or, as other people have pointed out, emacs for systems where you don't need a special license to be legally entitled to use motif.] But you did need a special license to compile for Motif. Shaya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
At 04:14 PM 4/26/98 -0400, Raul Miller wrote: Shaya Potter [EMAIL PROTECTED] wrote: As an aside, I am beggining to think that we need a better license, from a legal perspective, because with all the issues of shared libraries, essential parts, and who knows what else, if someone would really try to challange the GPL in a court, I don't know if it would stand up. FUD. Why is this FUD? Shaya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Richard Braakman wrote: Shaya Potter wrote: What defines a standard linux installation. Each dist. in reality is it's own OS. Red Hat ships Motif, would it be legal for them to distribute a GPL'd program linked with Motif, and not for debian? The GPL specifically forbids the OS vendor from making use of the shipped-with-the-OS clause. (This closes a large loophole). So if Motif is considered a standard part of the Red Hat OS, then everyone *except* Red Hat can distribute such a program. I apologize in advance for anyone who thinks I'm trolling, but wouldn't that fail the discrimination part of the DFSG? Shaya (who likes what the GPL is trying to do, but thinks it has some problems) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
man 2 intro - SVID (fwd)
Hello, I sent it to debian-user, and didn't get any feedback (except for BTW2). I'm not subscribed to this list (yet? (read BTW3)), so please send any replys to me too. TIA, Liran Zvibel. --- http://www.math.tau.ac.il/~liranz/ -- Forwarded message -- Date: Sun, 26 Apr 1998 00:32:08 +0300 (GMT+0300) From: Liran Zvibel [EMAIL PROTECTED] To: Debian Mailing List debian-user@lists.debian.org Subject: man 2 intro - SVID Hello, I have to hand in a CS (OS) exercise that uses the SYS V sys. calls. I tried the intro manpage that says: SVID System V Interface Definition, as described in The System V Interface Definition, Fourth Edition, available at ftp://ftp.fpk.novell.com/pub/unix- standards/svid in Postscript files. this domain doesn't seem to exist... I think that the maintainer of the manpages should be notified. BTW: At my Uni. I tried intro(2) and it was MUCH more informative (It is SunOS). BTW2: What do you think about Stevens' book Advanced Programming in the Unix Environment? Should I buy it? BTW3: What do I have to know to contribute to Debian? I know C, C++ (I know Pascal, Scheme and Java too, but I don't think those will be needed...). What documentation should I read? TIA, Liran Zvibel. --- http://www.math.tau.ac.il/~liranz/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Shaya Potter [EMAIL PROTECTED] wrote: As an aside, I am beggining to think that we need a better license, from a legal perspective, because with all the issues of shared libraries, essential parts, and who knows what else, if someone would really try to challange the GPL in a court, I don't know if it would stand up. At 04:14 PM 4/26/98 -0400, Raul Miller wrote: FUD. Shaya Potter [EMAIL PROTECTED] wrote: Why is this FUD? Only the courts get to decide what would stand up in court. [And then usually in a limited context.] Giving up on the GPL before it's been tested because you don't know if it would stand up in court is explicitly based on doubt, uncertainty and/or fear. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Shaya Potter [EMAIL PROTECTED] wrote: But you did need a special license to compile for Motif. Good point. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
Richard Braakman wrote: The GPL specifically forbids the OS vendor from making use of the shipped-with-the-OS clause. (This closes a large loophole). So if Motif is considered a standard part of the Red Hat OS, then everyone *except* Red Hat can distribute such a program. Shaya Potter [EMAIL PROTECTED] wrote: I apologize in advance for anyone who thinks I'm trolling, but wouldn't that fail the discrimination part of the DFSG? Richard has oversimplified that clause. It really says that you can't distribute such a binary with the commonly available non-free component. In any event, the discrimination isn't on who gets to use the software, but on what exceptions are being made to the source code availability is required when you distribute binaries clause. In all cases where it's ok to distribute, you can distribute to anyone. The discrimination part of the DFSG is about making sure that you can distribute to anyone. [If you already understood that then, yes, you were trolling.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: man 2 intro - SVID (fwd)
--On Mon, Apr 27, 1998 8:02 pm +0300 Liran Zvibel [EMAIL PROTECTED] wrote: Hello, I have to hand in a CS (OS) exercise that uses the SYS V sys. calls. I tried the intro manpage that says: SVID System V Interface Definition, as described in The System V Interface Definition, Fourth Edition, available at ftp://ftp.fpk.novell.com/pub/unix- standards/svid in Postscript files. this domain doesn't seem to exist... I think that the maintainer of the manpages should be notified. That would be a bug. File a bug report. Although it has to be said, it doesn't sound like a very important one :) BTW: At my Uni. I tried intro(2) and it was MUCH more informative (It is SunOS). Lucky SunOS. Anything actually interesting there? If so, you could file a wishlist bug report, or you could try putting into man format yourself the things you think are appropriate to Debian's intro(2). Be careful - that stuff is almost certainly copyright Sun... BTW3: What do I have to know to contribute to Debian? I know C, C++ (I know Pascal, Scheme and Java too, but I don't think those will be needed...). What documentation should I read? Programming languages aren't that useful for general project contributions - although they're certainly generally useful. Perl will stand you well - lots of odd-end scripts are written it. Bash scripting knowledge would probably be even more useful. In terms of what you should read, that depends how you want to help. If you feel debian is missing some useful software that you happen to know exists, then you could read the packaging manuals and package it. Browse around the web site, looking for wishlists. At this time of imminent release of hamm, if you're a competent coder, you could have a look at the outstanding bugs, and fix some. Alternatively, we are missing a fair few man-pages, so if you're good with the -man macros, you could write some man-pages. Cheers, Jules Bean /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Constitution - formal proposal (v0.7) (comments)
Ian Jackson - Debian Project Leader wrote: Please see http://www.chiark.greenend.org.uk/~ian/debian-organisation-0.7.html http://www.chiark.greenend.org.uk/~ian/debian-organisation-formal.html http://www.chiark.greenend.org.uk/~ian/debian-organisation.html for the latest draft constitution. All three looked the same to me; I hope they were :-) I had trouble understanding the second paragraph of section 1: This document describes the organisational structure for formal decisionmaking in the Project. It does not describe the goals of the Project or how it achieves them, or contain any specific nontechnical policies not directly related to the decisionmaking process. There were too many negations in that last sentence. I suggest to drop the words specific nontechnical (it doesn't contain any technical policies either, so that's ok), and replace not directly related with other than those directly related. I also have a more substantive comment. The Constitution seems to contain no provision for a developer to leave the Project, other than by expulsion. I think that s.3.2 should state that a developer may leave the Project at any time, by stating so publicly or by informing the Project Secretary (who will presumably make a public statement). I assumed that the Project Secretary would keep the authoritative list of Debian developers, but s.7.1 makes no mention of that. Perhaps it should? Determining the current set of developers is a non-trivial task. In addition, I am still not sure about the role of SPI. s.9.2 says SPI have made the following undertakings and then gives a list. Is this currently true? I think it should be true before a vote is called, at least. The introduction to s.9 also says Debian's developers are currently members of SPI by virtue of their status as developers. Is this true? It would seem to depend on SPI's charter, not Debian's, and we don't have that. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian According to the proposed constitution, the policy documents do Ian not of themselves have any power to override a developer's Ian decisions. I think that to allow this would be to hand far too Ian much power to the policy editor(s), so I think this situation Ian should be preserved. The policy editor is supposed to be someone who starts discussions about policy, and incorporates the consensus into the document itself. I suppose a formal process could be worked out, but, by and large, this works quite well. There also is a process to get policy amended, in case the developers feel the policy editor has exceeded their authority. In the light of this, I find the statement about too much power to the policy editor, umm, unconvincing. Ian If Christian or anyone else disagrees they should take the matter Ian up on debian-devel, where the proposed constitution is being Ian discussed. I have copied the developers list on this. Ian The question then arises: what does it mean when something is Ian policy ? Answer: policy is a set of technical specifications and Ian procedures which developers are expected to use to make Ian decisions, which people reporting bugs can refer to as Ian authoritative, and which bodies like the Technical Committee will Ian refer to (though not unquestioningly) when asked to adjudicate. So, people may report bugs for policy violations, and when it comes to adjuducation the Technical committee refers to this, but apart from that, Policy has as much relevance as Wodehouse? Ian So what power does a policy document have, in and of itself ? Ian Answer: just the power to declare what is and is not policy. I find the intent quite unclear. Is policy like a standards document? Are individual maintainers at liberty to flout, say, the WWW standard, of the file system standard? Can my package start modifying /var/lib/dpkg/status at will? I mean, if policy has no power whatsoever exept say this does not conform, where exactly does that leave us? I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. manoj -- I asked you not to have a spaz attack in tx.general, BUT NO Karl, via John Belushi Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Ian didn't mention an enforcement policy, because that is already clearly mentioned in the constitution---the technical committee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Mark == Mark Baker [EMAIL PROTECTED] writes: Mark On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava Mark wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Mark Ian didn't mention an enforcement policy, because that is Mark already clearly mentioned in the constitution---the technical Mark committee. Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). I still find the wording confusing. All that policy can say is whether something conforms to or does not conform to policy. And while we are picking nits, there is not statement anywhere that policy ought to (should) be followed (is that not an oxymoron?). I am not required to follow it, and yet it is authoritative to bug filers; I an see a lot of contention developing there. (and again, the tech committee is brought in.) I guess I mistrust an unknown set of powers-that-be rather more than a known quantity. [I am aware this is irrational]. manoj who likes the quiet certitude of the ISO standards -- It turned out that the worm exploited three or four different holes in the system. From this, and the fact that we were able to capture and examine some of the source code, we realized that we were dealing with someone very sharp, probably not someone here on campus. Dr. Richard LeBlanc, associate professor of ICS, quoted in The Technique, Georgia Tech's newspaper, after the computer worm hit the Internet Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
I'm not a debian developer, merely an interested lurker (I will almost certainly become a developer sometime). Apologies if you think I'm speaking out of turn. --On Mon, Apr 27, 1998 2:47 pm -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Mark == Mark Baker [EMAIL PROTECTED] writes: Mark On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava Mark wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Mark Ian didn't mention an enforcement policy, because that is Mark already clearly mentioned in the constitution---the technical Mark committee. Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). I still find the wording confusing. All that policy can say is whether something conforms to or does not conform to policy. And while we are picking nits, there is not statement anywhere that policy ought to (should) be followed (is that not an oxymoron?). I am not required to follow it, and yet it is authoritative to bug filers; I an see a lot of contention developing there. (and again, the tech committee is brought in.) No contention at all. Developers are not required to follow policy. But, reports are filed for policy deviations, thus putting pressure on to adapt either policy or the developer ;) as necessary. The reports will remain until someone closes them - so they are a reminder of all extant violations (rather, all extant violations that bother people). Indeed, if I (as a hypothetical developer) were to violate policy, I might even, at the same time, file a bug report against myself, explaining why I did it, and what changes to either the world at large or debian-policy would fix it. This system makes sense to me. I guess I mistrust an unknown set of powers-that-be rather more than a known quantity. [I am aware this is irrational]. In effect, in means that the first level of enforcement of policy is the general Debian community. I think this is good. If things get out of hand, then presumably the leader or the committee step in to give a definitive answer. manoj who likes the quiet certitude of the ISO standards Jules Bean who likes the bright future of a communal democracy... /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do with /bin/perl symlink?
On Apr 26, Enrique Zanardi wrote: On Sun, Apr 26, 1998 at 02:50:49PM +0200, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Sun, 26 Apr 1998, Enrique Zanardi wrote: Currently the base system comes with that symlink, but I plan to remove it for the next boot-floppies release. Objections? None. Just a question: Are there more files (still) in the base system but not in any package? Files from packages not in the base system: - /usr/bin/ftp and /usr/bin/telnet (from netstd, they should be moved to netbase) No, netstd is the right place for them. netbase only provides the tools to configure the network (ifconfig/route/...) and to get other networking services up and running (inetd/portmapper). Thanks, Peter -- Peter Tobias [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpm and time after hamm upgrade
Corey == Corey Miller [EMAIL PROTECTED] writes: Corey After upgrading to hamm, I have experienced the two Corey following problems. First, gpm no longer seems to work with Corey my mouse. I have a PS/2 M$ Intellimouse, which used to work Corey fine as type ps2. I tried that setup, under which it only Corey moves the cursor erratically and seems to randomly select Corey text. I tried setting the mouse to type ms3, but that Corey produced nothing at all. I have tried setting the mouse as Corey /dev/psaux and /dev/mouse, and have tried closing x windows Corey completely before starting gpm, but nothing seems to Corey help. I am using gpm 1.13-4. Bob already answered the time problems, so I'll pick up the mouse one... gpm 1.13-4 General Purpose Mouse Interface xbase 3.3.2-2Local clients and configuration required by xserver-svga3.3.2-2X server for SVGA graphics cards and my M$ Intellipoint mouse works just fine From /etc/X11/XF86Config: Section Pointer ProtocolBusMouse Device /dev/gpmdata Emulate3Timeout 50 Emulate3Buttons EndSection From /etc/gpm.conf device=/dev/psaux responsiveness=20 type=ps2 append=-l a-zA-Z0-9_.:/root/00-2630-6670-77 -R Try that see how you go. Of course make sure you have PS/2 mouse support in the kernel somewhere (module/compiled-in/whatever) -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Cc: Debian Developers list debian-devel@lists.debian.org, Debian policy list debian-policy@lists.debian.org From: Manoj Srivastava [EMAIL PROTECTED] Date: 27 Apr 1998 14:47:23 -0500 Lines: 44 Hi, Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). Exactly. I think the problem has arisen because 1) the policy documents have not sufficiently delineated the difference between prescriptive (shall, must) provisions and (strong) recommendations (should, must), and 2) because some (many?) developers disagree with some policy provisions and feel that they have had insufficient input in the process of formulating policy. Christian has started the process of rectifying the first item. I believe the remedy for the second point is _not_ to make policy some vague advisory document. I believe the remedy is to establish a more formal policy making process. It would probably be necessary to provide for some type of super-majority to establish prescriptive policy provisions, with, perhaps less support required for suggestive provisions. In some cases it seems that some developers have failed to read the lists for some lengthy period of time, then found that policy provisions had been adopted that they find objectionable. A formal policy making process should provide for a process to change it when the developer community agrees it is desirable. Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle troff sources
Hello, according to the hints I wrote a Makefile which I woul ship with the paper sources so that per default troffcvt is used to produce HTML output. Invoking make ps/txt/dvi/asc produces ps/latin1-text/ dvi/ASCII. My problem is, that the sources use pic commands and troffcvt isn't able to handle some tabular code produced by pic. The other formats created by groff work well with this code. Should html be the default despite this fact. I havn't any knowledge about troff so I'm unable to fix the bug. Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: dpkg and handling of the Unconfigured state
Hi there, Currently, the unconfigured state for a Debian package is AFAIK only reflected by its state in dpkg's status files. This leads to programs that are installed in the system, thus can be lauchned by some user, even if their run cannot complete, either for an obvious reason like a missing shared lib, or for any other reason that will have justified the dependency which caused the package to be left unconfigured. Running a program in such a package may lead to unpredictable results, though in the most simple case the user just gets an error from the dynamic linker. A solution I see to this situation would be to have all executable permissions unset when a package is unpacked, and then set as specified in the package when the package has been configured. It seems to me that all cases of dependencies would be fulfilled with such a mechanism: a package would only get its X bits set when all packages it depends on would be configured (ie, when it applies, with their own X bits set). Note that this would advocate for essential packages to be configured immediately after being unpacked, or the pakcaging system may break. Or maybe essential packages may be given special treatment in this case, in that they would not be subject to these manipulations. This proposal only concerns executables. Maybe other things can be done, eg. for shared libs, but I'm no expert here. Any comments on this ? -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
acct and 2.1.96
On Mon, 27 Apr 1998, Thomas Gebhardt wrote: Hi Austin, Incidentally, simply rebuilding the acct package against the new header files is a little tricky, since the ./configure script uses sys/acct.h in preference to linux/acct.h Did you manage to build a acct package for 2.1.96? If so, could I get it from you? I did in the end. I'm not sure what the best way of releasing it is, however. My version has exactly the same version number as the original I built it from. I'll put it up at: http://www.cl.cam.ac.uk/~and1000/acct_6.3.2-2_i386.deb for a few weeks, but I'll only be able to get it there sometime tomorrow. Austin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposed Constitution
I suggest that Section B. Use of language and typography be amended to include a statement similar to Where the context permits, the masculine shall include the feminine, and the singular shall include the plural. Then all of the clumsy constructions using plural pronouns (they, their) to refer to singular entities (Leader, Secretary, etc.) should be changed to use singular masculine pronouns (him, his). Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I have a question about Debian
Can you use windows 95 and debian on the same PC at the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hamm upgrade and /usr/local.
Hi I just upgraded to hamm. I have a link from /usr/local to /mnt/c/local, because it is on a different disk. For some reason the link was removed and a directory created. it also created /usr/local/share/octave and /usr/local/share/emacs. I thaught packages weren't supposed to touch /usr/local? Anyway, It shouldn't delete links imho. is this a bug? Regards -- Robbie Murray -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Constitution - formal proposal (v0.7)
Hi, After reading the seventh revision of the proposed constituion, I find that all my concerns and changes encapsulated in my proposed amendment have been addressed, and I formally withdraw the amendment. manoj -- A good dinner sharpens wit, while it softens the heart. -- Doran Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy suggestion (seeking discussion)
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul Manoj Srivastava [EMAIL PROTECTED] wrote: Raul This only works if the name of the file can be anticipated at Raul package creation time, and where it's not confusing to do Raul so. But, yes, in that case it's a much better approach. Hmm. You have a point. I did not consider the case where the file name would eb determined at install time. Raul Then again, the only case I can think of where this approach Raul doesn't work very well is magicfilter, and those should probably Raul be treated as conffiles. Well, in order to be a conffile, one would need the name a priori, I think. Don't even think about changing dpkg internal files using anything but dpkg. Raul dpkg, the package suite, or dpkg the binary executable? Either, though I would only feel comfortable woth something in the dpkg package itself, not extraneous add-on packages. Raul [Even there, until dpkg has a track record of getting the Raul installation right and not messing up, it's perfectly reasonable Raul for the *system administrator* to muck with these files. I know Raul we're talking about package maintainer activities at the moment, Raul but I think this point has been made incorrectly, too many Raul times.] Oh, sure, their machine, their rules. They are perfectly free to do rm -rf / as well; who are we to argue? But no program should ever have the temerity to do so; unless it has been blessed by the dpkg consortium. Personally, on my machine, I refrain from ever modifying the /var/lib/dpkg/ directory outside of dpkg/dselect. I also do not do rm -rf /; but that is just me. Other people may well be more daring. manoj -- The President of these overly-united States was shaking hands with the NY Yankees one day -- apparently during summer. When he got to Babe Ruth, the Bambino opened with, Hot as Hell, ain't it, Prez? Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hamm upgrade and /usr/local.
On Mon, Apr 27, 1998 at 10:37:19PM +0100, [EMAIL PROTECTED] wrote: I just upgraded to hamm. I have a link from /usr/local to /mnt/c/local, because it is on a different disk. For some reason the link was removed and a directory created. it also created /usr/local/share/octave and /usr/local/share/emacs. I thaught packages weren't supposed to touch /usr/local? Anyway, It shouldn't delete links imho. is this a bug? Aha. This happened to me recently too; my link /usr/local - /local/local was removed. I couldn't find anything by looking through the postinst etc scripts that would do it though. I don't recall it happening on another box of mine though, which has the same link. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago Well, I'm sure than 99% of people dislike current default Santiago bash prompt in /etc/profile. At least we could put the Santiago current dir, and maybe that 99% would decrease a lot. Only if you truncate the string when it gets too long. There is nothing more annoying than to be in a directory deep in the tree root:/usr/local/src/Work/graphics/png/full_color/logos/Linux/open/.xv/(32): See wht I mean? If you must have the path name, arrange to chop componenets from the left until you are under a set number of characters. I have code that does this; email me if you need this. manoj -- You say I'm cool, I'm no fool, but then you wind up applying to grad school... Matt Groening Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago -BEGIN PGP SIGNED MESSAGE- On 27 Apr 1998, Kai Santiago Henningsen wrote: Santiago Ok, Only if the program doesn't support a site-wide default Santiago configuration and the package maintainer doesn't have time Santiago to add it should a default per-user file be placed in Santiago /etc/skel. Well, if the package maintainer does not have time to do the right thing, should he not be looking for another person to take over the load? There was this heartfelt appeal from someone not so long ago who was having trouble finding a package to maintain. This is not a flame, and I am not pointing fingers; this is a volunteer effort, and the real world does tend to intrude, and few of us have the time we would like for this. However, that is no excuse for sloppiness. manoj -- What! shall this speech be spoke for our excuse? Or shall we on without apology? -- Shakespeare Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I have a question about Debian
Debian is a distribution of Linux, which is a UN*X clone for the PC. It is also and operating system. Windows95 is also considered and operating system by some. The operating system controls things like memory, disk, and other hardware. You can have two operating systems installed on a computer, but you can not run them at the same time. Many peaple configure their systems for multiple operating systems, using a boot manager. One must reboot to switch between two operating systems, such as Debian Linux and Win95. There is a lot of documentation available on this subject, you should check out www.debian.org for the list of documents available. Another good site is www.linux.org. -Matt On Mon, 27 Apr 1998, Collins Family wrote: Can you use windows 95 and debian on the same PC at the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed Constitution
On Mon, Apr 27, 1998 at 06:05:51PM -0400, Bob Hilliard wrote: include the plural. Then all of the clumsy constructions using plural pronouns (they, their) to refer to singular entities (Leader, Secretary, etc.) should be changed to use singular masculine pronouns (him, his). They is not only a singular, it is also widely accepted as a singular pronoun, and has been used as such by not only ordinary people but also great writers for hundreds of years. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Jules == Jules Bean [EMAIL PROTECTED] writes: Jules I'm not a debian developer, merely an interested lurker (I will Jules almost certainly become a developer sometime). Apologies if Jules you think I'm speaking out of turn. Jules --On Mon, Apr 27, 1998 2:47 pm -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Jules No contention at all. Developers are not required to follow Jules policy. But, reports are filed for policy deviations, thus Jules putting pressure on to adapt either policy or the developer ;) Jules as necessary. The reports will remain until someone closes Jules them - so they are a reminder of all extant violations (rather, Jules all extant violations that bother people). Hmm. I do think this leads to a dilution of technical discipline. And we already have way too many open bug reports; people do not seem to want to fix ``real'' bugs, and ``mere'' policy reports would be seen as fluff. I guess I am leaning mre towards a codification of laws (like hammurabi [I am unsure of the english spelling of his name]), while the opposition is opting for the chinese predeliction of trusting humans rather than laws; and trusting on the selection process to ensure that the people chosen shall be more adaptive and can adjust to cases on merit; historically, that has been subject to abuse; and even bodies of good men (soryy, ladies) have been know to decay; a codified system of rules is more stable against the ravages of time. manoj -- What matters is not the length of the wand, but the magic in the stick. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Directory for dictionary databases
In earlier discussions, it was agreed that the proper location
for dictionary databases under the FHS would be
/usr/share/dict/pkgname.
Subsequently, I have obtained a copy of the FHS, and have
discussed this subject with the upstream author of the dictd package.
An abbreviated extract from the FHS follows is appended to this
message.
It appears that the FHS considers the /usr/share/dict directory
to be for word lists, such as those used for spell checkers, not for
dictionaries in the wider sense.
Rik Faith [EMAIL PROTECTED], the author of dictd, says:
I argue that dictd is an application which stores read only information in
a proprietary[1] format which is not easily used by other applications, and,
as such, the data should be stored in the top level directory:
/usr/share/dictd
After reviewing the FHS, I agree with Rik, and will build the
dictionary packages that I expect to upload tomorrow to install in
/usr/share/dictd.
I suggest that you consider /usr/share/wordnet for your packages.
Bob
[1] This does not mean proprietary in the non-free sense. Rik means
unique to the dictd package.
--
_
|_) _ |_ Robert D. Hilliard[EMAIL PROTECTED]
|_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9
Abbreviated extract from the
Filesystem Hierarchy Standard -- Version 2.0
4.8 /usr/share : Architecture-independent data
/usr/share -- Architecture-independent data
|
+-dict Word lists
. . . . .
Any program or package which contains or requires data that doesn't need
to be modified should store that data in /usr/share (or
/usr/local/share, if installed locally). It is recommended that a
subdirectory be used in /usr/share for this purpose.
. . . . .
4.8.1 /usr/share/dict : Word lists
Recommended files for /usr/share/dict:
{ words }
Traditionally this directory contains only the English words file, which
is used by look(1) and various spelling programs.
. . . . .
Word lists for other languages may be added using the English name for
that language, e.g., /usr/share/dict/french
. . . . .
Other word lists, such as the web2 dictionary should be included here,
if present.
BEGIN RATIONALE
The reason that only word lists are located here is that they are the
only files common to all spell checkers.
END RATIONALE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PROPOSAL: Services, inetd and xinetd
Hi I'm a rather new and very happy Debian user, and some time ago while testing hamm/unstable I came trough a problem I thought deserved some time. I like better xinetd than inetd, so I installed. Despite of it trying hard to xlate inetd.conf, new services added won't correctly install into new xinetd.conf, and thus you lose consistency and have to add them by hand (not a pain for somebody who knows what's up, but a big pain for a newbie). I know xinetd is non-free and not too much people uses it, but it's *good* and secure, and it may happen sometime a new free xinetd comes up ... Well, what I'd like to propose is something like or update-menus, but for network services. Then a series of update-XXX scripts would xlate a global services database to inetd.conf, xinetd.conf or whatever and restart the desired daemon. My proposal'd look something like this: /etc/services[generated] /etc/services.d [better name?] 000-SERVICE000 [from package which provides it] 001-SERVICE001 ... . . services.in [skeleton /etc/services file] inetd.conf.in [from inetd package] xinetd.conf.in [from xinetd package] YOUR-DAEMON.conf.in [from YOUR-DAEMON package] . . update-services [update /etc/services] update-inetd[from inetd package] update-xinetd [from xinetd package update-YOUR-DAEMON [from YOUR-DAEMON package] . . /sbin/update-services[calls update-* on /etc/services.d] Each update-DAEMON script would xlate the service files to it's daemon configuration file format by replacing a cookie in the .in file [let's say @[EMAIL PROTECTED], installing it correctly [owner and permissions] and saving old one in some fashion. Then it'd restart or reload the daemon. The `update-services' program would do the same, but actualizing /etc/services For the service file entries: they'd be sorted using a three number prefix in the file name and then a service name, separated with a dash, for the sake of readability. I'd bet for allowing any kind of chars on the name [such as spaces and stuff], though I wouldn't recommend it. The file would have some sort of format, I bet for something like menufile's but with multi-line and comments and would at least add as many fields as xinetd.conf recognizes, with option to add more dinamically as need arises [scripts would ignore unknown fields, just warn]. For internal services, the update-*inetd scripts just should ignore the entries that refer to an external program and set to it's own internal stuff. There should be some sort of defaults. Think xinetd allows specifying them, no idea about inetd. So this is my idea. I'd like to hear flames/sugerences, as I'm thinking of starting it to kill time when I'm bored of doing the rest of things I do :) I think it'd be a nice addition to `slink' ... what do you think? -- Linux-USB! http://peloncho.fis.ucm.es/~inaky/USB.html - - Inaky Perez Gonzalez -- PGP pubkey fingerprint - [EMAIL PROTECTED] -- 8E 34 3A 62 64 99 E2 44 - http://peloncho.fis.ucm.es/~inaky -- AD 7B 30 D9 DD FF 3E 4C - - -- --- - The loneliness of the long distance runner . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
Avery == Avery Pennarun [EMAIL PROTECTED] writes: Avery Why not /etc/profile? Or is that against policy? Avery Incidentally, I've always wondered why there is no /etc/bashrc Avery and /etc/bash_profile. They would be ideal for this. My suggestion is there should be an all-sh profile [/etc/profile], an /etc/environment and per-sh rcs [/etc/bashrc, cshrc...] and such. I'd suggest to always source these ones and the the user ones ~/.profile, ~/.bashrc, ~/.environment ... CU! Linux-USB! http://peloncho.fis.ucm.es/~inaky/USB.html - - Inaky Perez Gonzalez -- PGP pubkey fingerprint - [EMAIL PROTECTED] -- 8E 34 3A 62 64 99 E2 44 - http://peloncho.fis.ucm.es/~inaky -- AD 7B 30 D9 DD FF 3E 4C - - -- --- - The loneliness of the long distance runner . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
